Skip to content

Consent, Privacy and Record Integrity

Introduction

This part of the guide covers what a patient has said may be done with their record, and what they can require be done to it. Those are one subject here, not two, because they are one resource type: a clinic's note that the patient agreed to be emailed, a patient's grant of access to a third-party app, and a patient's instruction that a record be withheld are all Consent, all in one store, all returned by one search, and all read the same way.

On the consent side, that is the preferences a clinic records for a patient — email, SMS, an AI scribe — and the access a patient grants a named application.

On the privacy side, it is what an individual can require of a health information custodian under Ontario's Personal Health Information Protection Act (PHIPA): give them access to their record, restrict it, correct it, and — where a correction is refused — have their disagreement carried with it. Two mechanisms make those requirements operable: the record of an override, and the labels that travel on a resource to say what may be done with it.

None of these controls is enforced yet. Read this before anything else.

This release defines how a consent decision, a restriction, an override, an access request, a correction, a disagreement and a disclosure label are recorded. It does not enforce any of them. That includes the consent families: nothing in this estate checks an item consent before a message goes out, or an app consent before an application is answered.

Concretely, today: a patient can place a lockbox and the record is released anyway; a break-glass is neither bounded nor reviewed; an access request can be logged and nothing answers it or watches its deadline; a correction does not propagate; a statement of disagreement does not travel with the information it disputes; a record labelled not-to-be-transmitted transmits; and "who has already seen this" cannot be answered.

A consumer of this API is therefore the enforcement point. Nothing upstream will filter a restricted resource out of a response, label it, or refuse a disclosure on your behalf. If your application displays, prints, exports or forwards clinical data, the obligations described here land on your code.

Each page ends with a What is not implemented section listing the specific surfaces. They are accurate and they are worth reading in full.

Every page in this section, and what each one answers

This table is the section's index. It runs from what the patient decided to what a custodian must do about it, which is also the order of the pages in the sidebar.

Question Where it is answered
Does the clinic have consent to email, text, or scribe this patient? Item consent
May this named application receive this patient's record? App consent
Has the patient restricted collection, use or disclosure (lockbox)? Privacy directives
May a restriction be set aside lawfully (break the glass)? Consent override
How does an individual get access, and be given reasons for a refusal? Access requests
How is a record corrected, and what links to what it replaced? Corrections
What attaches where a correction was refused? Statements of disagreement
How is a record marked not-to-be-transmitted, or purpose-limited? Security labels
How is a recipient told their copy of the record is incomplete? Security labels

The first three rows are the three Consent families, and they are the same three explained below. The remaining rows are PHIPA obligations on the custodian, and each of those pages names the surfaces that do not yet meet them.

Four ideas that are easy to conflate

Most of the mistakes available in this area come from treating one of these as another. They have different actors, different lifecycles, and different consequences.

A directive is an instruction. The patient says what may not be done. It is a Consent, it is authored by the patient or their substitute decision-maker, and it persists until withdrawn or replaced.

An authorization decision is a ruling. At the moment of a request, something decides whether this requester may have this data for this purpose. A directive is one input to that ruling; it is not the ruling, and it does not make itself.

A disclosure is an event. Data actually left. It is an AuditEvent, and it is the only record from which "who has already seen this" could be answered — which matters because the obligation to notify prior recipients of corrected or disputed information depends entirely on it. The AuditEvent profile is itself a first pass, and no disclosure trail is queryable today, so that question currently has no answer at all.

Provenance is authorship. How a record came to be, from what inputs, under whose supervision. It is written selectively, so its absence is inconclusive — which is exactly why a disclosure report cannot be built from it.

None of the four substitutes for another. A system that answers "was this disclosed?" from Provenance will be wrong, and a system that answers "may this be disclosed?" from an AuditEvent will be wrong in the more dangerous direction.

Consent carries three families in this guide. They all state their decision the same way, and they differ in what that decision governs — widening from one catalogue item, to one application, to the whole record:

Family Governs
item Email, SMS and AI-scribe preferences
app Whether a named third-party application may have the record
privacy-directive Restriction on the collection, use or disclosure of the record

Each family has its own page; the index above links all three, so they are not linked again here.

All three fix scope to patient-privacy. A single GET Consent?patient={id} returns them mixed, which is why category is required and searchable — but reading a decision no longer depends on telling them apart.

One rule reads every family

Every Consent profile in this guide states its decision in the same element: provision.type on the root provision. permit grants, deny restricts. status says only whether the record is operative.

Read provision.type. A deny restricts something. status = active means the record is in force, and nothing more.

Family provision.type status Means
Item consent permit active Patient agreed to email / SMS / AI scribe
Item consent deny active Patient declined, or withdrew
App consent permit active Patient agreed to share with this application
App consent deny active Patient refused
Privacy directive deny active A restriction is in force
any any inactive / entered-in-error Not operative — carries no decision

A Consent that does not deny has not granted you anything either. It has failed to restrict, which is a different fact: what authorises a disclosure is the applicable policy and the purpose, and this resource is one input to that decision.

This is a change, and it is the point of it. Item consent used to carry its answer in status alone — active meant yes, rejected meant no — while the other families carried theirs in the provision tree. That made status mean opposite things across families sharing one resource type, one scope and one search, so a consumer that read status first read a lockbox as permission. The fix was not a better warning; it was to stop item consent being the exception.

Discriminating on category

category tells you what a decision governs — an application, a catalogue item, or the record itself. It no longer tells you how to read the decision, because that is the same everywhere.

The discriminator is the Consent Family code system. It is required on every family and it is searchable, and it remains the only reliable selector: scope will not separate them, since all three carry patient-privacy, and neither will the shape of the provision tree.

There is deliberately no fourth family for an override. Break-glass is an exception inside a directive, and the record that somebody used it is an AuditEvent. The consent override page explains why.

A privacy notice or privacy agreement that a patient accepted or declined is a Consent, not an audit entry and not a flag on Patient. It is a standing decision with an author, a date, a piece of evidence behind it, and a version of a document it refers to — the same shape as every other family here.

HL7 already publishes the code that identifies it: npp, "Notice of Privacy Practices", from http://terminology.hl7.org/CodeSystem/consentcategorycodes, defined as "acknowledgement of custodian notice of privacy practices" and covering the permitted collection, access, use and disclosure that the notice describes. Nothing needs minting.

Presentation and acceptance are two different acts, and they land in two different places. Showing somebody a notice is an event: an AuditEvent, like any other thing that happened at a moment. Their answer is a decision that persists until it is replaced, which is a Consent. A system that records only the presentation can say the notice was displayed and cannot say what the patient said; one that records only the acceptance cannot say which version of the notice they were looking at.

This family is not modelled in this release, and a consumer should not expect one. No profile exists, and no npp code has been added to the Consent Family code system — adding a family code before there is a profile behind it would put a value in a required, searchable element with no contract saying how to read it, which is the one thing that element exists to prevent.

What is undecided is whether it becomes a fourth family in this guide's own discriminator or is carried directly on HL7's category code; whether the notice version is a sourceReference to a DocumentReference or a policy.uri; and whether a declined notice is provision.type = deny or has no persistent record at all. What would decide it: a surface that captures the answer and something that reads it. Until both exist, the position stated here is the whole of the model — a privacy agreement acceptance is a Consent, npp identifies it, and the presentation is audit.

What this guide adopted rather than invented

The model follows published prior art closely, and says where it does not:

  • IHE Privacy Consent on FHIR (PCF) 1.1.0 — the directive's shape, including the root provision.type convention and the nested-permit break-glass pattern. This guide diverges on provision.action, which PCF prohibits and Ontario requires.
  • IHE Basic Audit Log Patterns (BALP) 1.1.4 — the authorization and disclosure audit patterns.
  • HL7 Patient Request for Corrections 1.0.0 — the correction workflow vocabulary. Its profiles are not adopted; the reasoning is on the corrections page.
  • HL7 v3 ActCode / ActReason — every security label, purpose of use and override ground. No local code was minted where a standard one exists.

Ontario's Provincial Consent Override Interface is the designated standard for overriding blocks on provincial EHR data, and is deliberately not modelled here as an exchange profile. What this guide models is the local half. The reasoning is on Consent override.