Skip to content

Break-Glass Disclosure Workflow

Emergency-access process — instantiates Role-Scoped Disclosure Minimization

Grants a normally-forbidden disclosure in a genuine emergency through a deliberate, high-friction override that time-boxes the access and notifies the data's steward — so the exception stays available but never quiet, routine, or free.

Break-Glass Disclosure Workflow is the sanctioned exception path for the moment when minimization would otherwise block a legitimate, urgent need. Ordinarily the narrow role-scoped view holds; but sometimes a person with no standing entitlement genuinely must see more, now, and waiting for normal approval would cause harm. The defining move is that the override is available but deliberately loud and costly: breaking the glass grants access first and accounts for it after — the invocation is recorded, the grant is time-boxed and auto-revoked, and a notice fires to the data's steward for after-the-fact review. It converts a hard denial into an accountable, reviewable grant, trading prevention of the exception for detectability of its misuse.

Example

An unconscious patient arrives in the emergency department. The attending physician is not on this patient's care team, so the normal role-based view denies the full chart — exactly as it should for an unrelated clinician on an ordinary day. But this is a code, and the allergy and medication history could decide the next five minutes. The physician invokes break-glass: an explicit "I am declaring an emergency" action, with a typed reason, that opens the record immediately, flags the session as an override, starts a countdown, and pages the privacy office and the patient's assigned data steward.

The access closes automatically at the end of the shift; nobody has to remember to revoke it. The next morning the privacy office reads the justification against the audit trail. If the emergency was real, the override is closed as warranted. If the "emergency" turns out to have been idle curiosity about a name on the news, it is flagged for follow-up — and because every break-glass event is reviewed, that outcome is likely enough to deter the curiosity in the first place.

How it works

Default-deny stays in force; break-glass does not widen anyone's standing access. Instead it offers a deliberate, high-friction override — assert an emergency, give a reason, sometimes re-authenticate or summon a second party — that grants access immediately rather than after approval. What makes the grant safe is everything bolted to it: it is logged as an override, it expires on a timer instead of persisting, and it emits a notification to a steward (and, where the law requires, to the subject). Normal escalation asks permission before acting and is therefore too slow for an emergency; break-glass acts first and forces the accounting to happen after. Its entire design goal is to make an unwarranted invocation visible, not impossible.

Tuning parameters

  • Friction level — how many hoops (typed justification, second approver, step-up re-authentication) stand before the glass breaks. More friction deters casual misuse but costs precious seconds in a real emergency.
  • Grant scope — the whole record vs. an emergency-relevant subset. Narrower is safer but risks withholding the one field that mattered; wider is faster but re-opens the surplus problem.
  • Time-box — how long the emergency grant lasts before it auto-revokes. Shorter limits exposure; too short interrupts care mid-task.
  • Notification targets and latency — who is told and how fast — a real-time page vs. a next-day digest. Faster notice catches misuse while the trail is warm.
  • Review stance — every invocation reviewed vs. a risk-weighted sample, and what threshold counts as an unjustified break.

When it helps, and when it misleads

Its strength is resolving a genuine deadlock: the minimization scheme can stay tight and still bend for a real emergency, without anyone carrying a permanent broad grant "just in case." The exception becomes rare, visible, time-limited, and accountable rather than a standing hole in the design.

The failure mode is symmetric and unforgiving. Make invoking it too easy or leave the reviews unread, and break-glass quietly becomes the everyday back door — staff break glass by reflex to dodge the friction of proper access, and the whole minimization scheme is gutted from within. Make it too hard, and people are blocked in real emergencies, which is its own harm. The classic misuse is invoking emergency access as a routine convenience, or as cover for snooping on a record one has no business seeing. The discipline that keeps it honest is that the account must actually be read: the notification and after-the-fact review have to carry real consequences, or the availability decays back into a silent standing grant. This is the "break the glass" pattern[1] — cheap to use, expensive to misuse, and worthless if nobody checks the broken glass.

How it implements the components

  • exception_and_escalation_path — it is the sanctioned path for a disclosure the ordinary rules forbid: a deliberate, high-friction override that escalates the decision and grants access under declared emergency conditions.
  • subject_or_steward_notification_rule — every invocation fires a notice to the data's steward (and, where required, to the subject), so no emergency disclosure ever happens silently.

It does not set the ordinary, non-emergency view — that role-and-field decision is Attribute-Based Access Policy and API Response Projection; and it does not itself keep the tamper-evident record its accountability rests on — the durable, immutable trail is the Disclosure Audit Log, which this workflow writes to and depends on but does not implement.

Notes

Break-glass is a last resort, and its legitimacy depends entirely on being rare. A rising rate of invocations is itself the signal that the normal access design is too tight for real work — the right response is usually to widen a legitimate role or add a purpose to the Attribute-Based Access Policy, not to let the override quietly absorb the shortfall.

References

[1] "Break-glass" access — named for the emergency alarm you smash — is the established pattern of permitting a normally-blocked action in a declared emergency on the condition that the override is logged and reviewed afterward. It is widely used for emergency access to electronic health records. ↩