Consent Override (Break the Glass)¶

Introduction¶

A consent override is a custodian setting aside an individual's restriction on a lawful ground permitted by PHIPA — most often because the individual's health is at immediate risk and consent cannot be obtained in time.

There is no override resource. This surprises people, so the reasoning comes first.

No service in this estate grants access on the strength of a break-glass exception, and no override is bounded or reviewed. See What is not implemented at the foot of this page before building against any of it.

An override has two halves, and they are different kinds of fact:

Who MAY break the glass is a standing rule. It belongs in the individual's own directive, as a nested permit provision naming the users it applies to, with purpose = BTG:

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.

That somebody DID break the glass is an event. It belongs in the AuditEvent, following IHE BALP's authorization pattern, with the lawful ground on agent.purposeOfUse.

Modelling the second as a Consent was considered and rejected. A Consent that accumulated override events would mix the individual's instruction with the custodian's acts against it, would grow without bound, and would make "what did the patient actually ask for" unanswerable without filtering out everything that has happened to them since. It would also mean the individual's directive was rewritten every time somebody acted on it.

The audit entry¶

Element	Carries
`agent.who` / `agent.altId`	The clinician who invoked it — a person, not a system
`agent.purposeOfUse`	The lawful ground — see below
`entity`	The patient, and the directive that was overridden
`recorded`	When
`outcome`	Whether the override was granted

The grounds¶

From the consent override grounds value set. The ground is what a privacy office reviews, so the categories have to match what actually happens rather than what sounds serious.

Code	Ground	The case it is for
`TREAT`	Providing care to this patient	The routine case: a covering clinician who needs to see or treat the patient now
`BTG`	Urgent or emergency care	A genuinely emergent, safety-related situation
`PATRQT`	Patient requested	The patient, or someone they have authorized, is asking for access now
(uncoded)	Other	Free text on `purposeOfUse`, no coding. Required to be filled in

Why TREAT is first, and why this is not an emergency vocabulary. Most practices this guide serves are family health organizations, not emergency departments. The ordinary legitimate override is a covering clinician treating the patient in front of them. A vocabulary offering only emergency grounds would force every routine override into a framing that does not fit, and a reason field everybody fills in dishonestly is useless for the review it exists to support.

COC (coordination of care) is deliberately absent even though it is a real code beneath TREAT. Routine care coordination is too broad a justification for overriding a patient's own restriction; a need that broad should go through an administrator lifting the restriction rather than through an individual override.

"Other" is not a code. It is purposeOfUse carrying free text and no coding. A report counting grounds must treat an uncoded purpose as its own category rather than dropping it — an override nobody could classify is exactly the one worth reading.

The provincial crosswalk¶

Ontario's Provincial Consent Override Interface uses a different subset of the same code system, because it covers a different act: overriding a block on data held in the provincial EHR, not on a chart this custodian authored.

PCOI ground	Meaning there	Nearest local ground
`PATRQT`	Express consent from the individual	`PATRQT` — same code, same meaning
`SUPNWK`	Express consent through a substitute decision-maker	`PATRQT` locally, with the substitute named
`OVRER`	Emergency / patient-harm override	`BTG`
`OVRTPS`	Third-party safety override	(uncoded) — no local equivalent

Keeping the local vocabulary inside the same code system is what makes a future provincial integration a mapping exercise rather than a rebuild. It is not a claim that the two sets are interchangeable: OVRTPS has no local equivalent, and mapping SUPNWK onto PATRQT loses the fact that a substitute decided, which has to be carried separately.

The bound the model does not carry¶

PCF's standing-rule pattern says who may break the glass. It does not express "and only for the next four hours".

That bound is real and it matters — an override without an end is a permanent removal of the individual's wish wearing the name of a temporary one.

The window is a property of the granting service, not a modelled element. The product grants a fixed 12 hours, to the individual user who broke the glass, not selectable by them and not extended by anything they do afterwards. A different user needing access breaks the glass themselves. Nothing in the FHIR record states that window; it is inferable from the span of audit entries, which is weaker than stating it.

A service MUST evaluate authority at the moment of each request rather than at the moment the override was granted — an override valid when a session opened is not valid for the rest of that session.

Whether the window should become a modelled element is open. The release that builds enforcement is the one that will know what shape it needs.

Breaking the glass does not change the directive. The restriction stays in force however many times, and by however many users, it has been overridden, until somebody with the authority to lift it lifts it. That is the property which makes the pattern safe, and it is why an implementation must never implement break-the-glass by setting the directive inactive: a flipped directive does not come back.

The provincial boundary¶

Ontario designates the Provincial Consent Override Interface as the standard for overriding an individual's block on provincial EHR data, and the programme requires it to be reached as a launched application rather than a back-end exchange.

So overriding a provincial block is not this estate's act. The clinician is handed off, the province decides, and what comes back is a disclosure the province authorized. No PCOI exchange profile is modelled here, because modelling a contract before there is an exchange to conform to would be inventing one.

What is this estate's job is the local half: overriding a restriction on this custodian's own records, and — separately and importantly — labelling data that arrives having been obtained under a provincial override. That labelling requirement is on the security labels page, and it is easy to miss: records ingested under an override must be identified as subject to a consent directive, so that later users know they may be used and disclosed only for the purpose they were collected for.

Notice to the most responsible provider¶

Where an override happens and the patient has a most responsible provider on file, that provider is told: a clinical Task is raised against them under the privacy-notice bin in Task code, naming who overrode, when, and the reason given.

privacy-notice is a different bin from privacy-request deliberately. A request is work an individual asked for and it carries a statutory clock — recorded on Task.restriction.period, whose end is the deadline, as on any other task. A notice is raised by the system, carries no deadline and so leaves that element empty, and completing it means the clinician has read it rather than that anything was done. The clock and what it is for are covered on access requests.

No notice is raised where the patient has no most responsible provider, or where the person who overrode is that provider — there is nobody else to tell. The override is fully recorded in either case; the audit entry is the record, and the task is only the prompt.

What is not implemented¶

No service grants access on the strength of a break-glass exception in a directive.
No override window exists, because no enforcement path exists to hold one.
The individual is not told that their restriction was overridden, and no review is scheduled.
Nothing labels records ingested under a provincial override.