Privacy Directive Profile

Canonical	../StructureDefinition/nexus-privacy-directive
Status	draft (experimental) · 1.26.0
Base	Consent (constraint)
Source	FSH · JSON

A patient's standing restriction on the collection, use or disclosure of their own personal health information -- the instruction PHIPA calls a lockbox.

Overview

The decision is provision.type on the ROOT provision -- deny for a lockbox -- and status says only whether the record is operative. That is the same reading as every other Consent profile in this guide, so a consumer does not need to know which family it holds to read a decision.

Required on the root, which diverges from R4's element text. R4 says type is "not permitted in root rule". IHE Privacy Consent on FHIR and Ontario's Provincial Consent Override Interface both require it there anyway, because a consent whose base rule states no decision states none where a reader looks first. A directive carrying no root type is malformed: do not infer permit, fail closed.

category carries a required, searchable family code. It says WHAT a decision governs -- an application, a catalogue item, or the record itself -- and is no longer needed to read the decision itself.

⚠ FIRST PASS. This profile defines how a restriction is RECORDED. It does not implement one: no release path in this estate currently consults a directive before disclosing. What a consumer must do with a directive is set out in the handbook.

Handbook: Privacy Directives

Privacy Directive Profile

Overview

A privacy directive is the patient's standing instruction restricting what may be done with their own personal health information — the thing Ontario law calls a lockbox. It is a Consent resource, and it is the first profile in this guide to model a restriction rather than a permission.

The profile is #draft and experimental = true. It defines how a restriction is recorded. It does not implement one: no release path in this estate currently consults a directive before disclosing. Read the enforcement section below before assuming otherwise.

THE effective date is provision.period.start, falling back to dateTime.

Read this before you read status

An active privacy directive means the restriction is in force — the patient said no.

An active item consent means the patient said yes.

Both are Consent. Both fix scope to patient-privacy. A single GET Consent?patient={id} returns them mixed together. A consumer that reads status without first discriminating will read a lockbox as permission and disclose information the patient restricted — which is a privacy breach, not a display bug.

The rule, and it holds everywhere in this guide:

Discriminate on category, then read.

category carries a required code from the Consent Family code system. It is searchable, it is required on every family, and it is the only safe selector:

GET Consent?patient={id}&category=../CodeSystem/nexus-consent-family|privacy-directive&status=active

Do not discriminate on scope; three families share patient-privacy. Do not discriminate on the shape of the provision tree; it is not a reliable signal.

Worked examples

• Whole-record lockbox with a standing break-glass exception
• Single-document lockbox
• The audit entry for an actual break-glass

Where the decision lives

Not in status. status says whether the directive is operative. The decision is provision.type on the root provision — deny for a lockbox.

This follows IHE Privacy Consent on FHIR and Ontario's Provincial Consent Override Interface, both of which constrain the root type to 1... It diverges from R4's own text, which says of Consent.provision.type: "Not permitted in root rule, required in all nested rules."

The divergence is deliberate and it is upstream's inconsistency rather than a local preference. A consent whose base rule states no decision states none where a reader looks first, and every reader of this family looks there. Two consequences:

• A directive carrying no root type is malformed. A consumer must not infer permit; fail closed.
• Every Consent profile in this guide takes the same side of that divergence. App consent and item consent both carried their decisions elsewhere before 1.25.1 and both moved to the root type, so there is one convention to learn rather than one per family.

Break-glass is an exception inside the directive

There is no separate override profile, and that is a modelling decision worth stating plainly, because it is the one most likely to surprise.

A directive denies at the root and carries nested permit provisions describing what the restriction does not reach. A standing break-glass carve-out is one of those:

provision.type                = deny
  provision.provision.type    = permit
  provision.provision.actor   = the users who may break the glass
  provision.provision.purpose = BTG

That is IHE PCF's shape, adopted rather than reinvented. It says who MAY break the glass. It never says that anybody did.

The record that a named clinician actually invoked it — when, on what lawful ground, reaching what — is an AuditEvent, following IHE BALP's authorization pattern. The ground goes on agent.purposeOfUse, from the Consent Override Grounds value set.

Keeping the two apart is the point. A Consent that accumulated override events would rewrite the patient's instruction every time somebody acted on it, and would make "what did the patient actually ask for" unanswerable without filtering out everything that has happened to them since.

What can be restricted

Element	Restricts by	Absent means
provision.action	The act: collect, access, use, disclose	Every action
provision.actor	The recipient or class of recipients	Everyone
provision.data	Named records	The whole record, including future information
provision.securityLabel	Sensitivity class	Nothing restricted by label

Every "absent means" above is the fail-closed reading, and each is stated on the element rather than left to inference. The opposite reading — that an unnamed dimension is unrestricted — fails open, and a privacy control that fails open is not a control.

provision.action is a deliberate divergence from IHE PCF, which prohibits the element entirely (0..0 in all three of its tiers). PCF targets document-sharing, where disclosure is effectively the only act in play. A primary-care EMR is the case it does not cover: restricting internal use of a record by staff who already hold it is a different instruction from restricting disclosure of it outward, and Ontario requires both to be expressible. A directive exported toward a PCF-conformant system loses this element, and what it meant must be carried some other way or declared unsupported at the boundary.

Two traps worth knowing before you write one

Security labels match by high-water mark, not equality. R4 is explicit: "If the consent specifies a security label of 'R' then it applies to all resources that are labeled 'R' or lower. E.g. for Confidentiality, it's a high water mark." So a directive written to restrict only restricted material also restricts normal, moderate, low and unrestricted — which, in a chart where most resources carry no elevated label, is close to restricting everything.

That error over-restricts rather than over-discloses, so it will not cause a breach. It will cause a clinician to be denied information they are entitled to, possibly at a bad moment. Prefer explicit provision.data selectors until subsumption behaviour has been tested against a classification both above and below the one named.

Data selectors enumerate records that exist now. A directive meant to cover future information — "nothing from this clinic, ever" — cannot be expressed as a list, and this release defines no criteria-based selector. Express a whole-record restriction by naming no data at all; that reading extends to future records. A directive naming a data list does not.

policyRule is not used, and that is a correction

Earlier releases of the two existing consent profiles fixed policyRule to consentpolicycodes#cric. That code is 45 CFR 46 — the United States Common Rule for informed consent in human-subjects research. It is not a privacy policy, and the code system it belongs to contains no Canadian concept at all: its 27 codes are US federal and state instruments plus three European ones.

A privacy directive cannot inherit it, and rather than substitute another wrong code this profile requires policy.uri — the actual governing instrument, named by URI. That satisfies R4's ppc-1 invariant ("Either a Policy or PolicyRule"), stays machine-readable, and says something true. Should a Canadian policy code system emerge, policyRule becomes available without this element changing.

What is NOT implemented

The profile records a restriction. Nothing enforces one. Specifically, as of this release:

• No FHIR read, search, _include or history path consults a directive.
• No document or referral packet assembly consults one.
• The attachment download endpoint does not re-evaluate a directive at retrieval time, so a URL issued before a restriction was recorded still resolves.
• No SMART application authorization consults one.
• Nothing invalidates a cached authorization when a directive changes.

Each of those is a place a restriction has to be honoured for the model to mean anything. Read the privacy directives handbook page for the evaluation contract a release path must implement.

Substitute decision-makers

performer accepts RelatedPerson, and a substitute decision-maker must be recorded as one — never flattened onto the Patient. The requirement is that rights over the record be exercisable by an individual and their substitute decision-makers, and recording an SDM's instruction as though the patient gave it destroys the fact that authority was delegated. That fact is exactly what gets examined when the instruction is later challenged.

SMART on FHIR exposure

Read-only, matching the other Consent profiles, and the constraint is structural: a SMART scope names a resource type, not a profile. consent:read granted for app or item consent already reaches every Consent in the store, including directives. There is no way to expose one family and withhold another.

Two consequences an integrator should know. An application holding consent:read can see that a patient has restricted their record — arguably necessary, since an application that cannot see a restriction cannot honour one. Write is granted by no scope, and that is load-bearing: an application able to write a Consent could post a permitting exception for itself.

Terminology bindings

Path	Strength	Value set
Consent.status	required	consent-state-codes
Consent.scope	required	consent-scope
Consent.category	required	Consent Families Value Set
Consent.provision.type	required	consent-provision-type
Consent.provision.action	extensible	Privacy Restriction Actions Value Set
Consent.provision.provision.purpose	extensible	Privacy Exception Purposes Value Set