Break the glass, break the evidence: what an emergency-access record actually proves
Breaking the glass is the right thing to do. A patient is in front of you, the chart is restricted, and waiting for an access request to route through three approvals is not medicine. The problem is not the override. The problem is what the override leaves behind: a row, written by your system, about your system, asserting that the override was justified.
What does an emergency-access record actually prove?
That your own system wrote a row about itself. Break-the-glass lets a clinician into a restricted chart in seconds, which is correct and necessary, and the record it leaves is the weakest thing you can hand an investigator: an account, a timestamp and a free-text reason.
- Break-the-glass is required by the HIPAA Security Rule at 45 CFR §164.312(a)(2)(ii). Nothing in the rule says how strong the resulting evidence has to be, so nobody built it strong.
- The record is written by the custodian of the data — the same organisation that would be the defendant in a snooping allegation. That is the weakest evidentiary position available.
- A signed break-glass statement, carrying a hash of the justification text the clinician actually saw and typed, turns an assertion into something a third party can check.
Part of Hospital and clinical identity
Start with what the control is for
Think of break-the-glass like the little red box on a wall with a hammer beside it. The box is there because sometimes the normal route — the door, the key, the person with the key — is too slow to matter. You accept that anyone can smash the glass, and you accept it because the alternative costs more.
Clinical systems work the same way. A chart is flagged restricted: a colleague's record, a public figure, a family member of staff, a sensitive diagnosis. A clinician who genuinely needs it clicks through a warning, types a reason, and gets in. Care continues. That is the design working.
The part nobody examines is what happens afterwards. Because the whole point of the control is that it does not stop you, its entire security value lives in the record it creates.
What the rule actually requires
The HIPAA Security Rule requires a covered entity to establish procedures for obtaining necessary electronic protected health information during an emergency — 45 CFR §164.312(a)(2)(ii). Separately, §164.312(b) requires audit controls: hardware, software or procedural mechanisms that record and examine activity in systems containing that information.
Read both clauses carefully and notice what is absent. Neither specifies the evidentiary strength of the resulting record. A database row satisfies both. So a database row is what every major clinical system produces, and no vendor has been under any pressure to produce more.
The three questions an investigator asks
When a break-glass access is contested — by a patient, a regulator, or a clinician who says it was not them — three questions decide the outcome. Your current record answers none of them independently.
| The question | What your record says | Why that is not enough |
|---|---|---|
| Who accessed the chart? | A user id from the application session | Sessions on clinical workstations are inherited across badge taps; the id names the last authenticated account, not the human at the keyboard |
| Were they shown the patient identity they claim? | Nothing | The record stores the patient id it resolved, not the screen the clinician read. Wrong-patient break-glass is a known, ordinary error |
| What justification did they give at the time? | Free text in a column | Free text is editable by anyone with database access, and was written by your organisation's own system |
That last point is the one that matters most and gets discussed least. In a dispute, your audit log is a statement made by the accused party about their own conduct. Courts and regulators accept it, routinely, because there is no alternative on offer — not because it is strong.
Why quarterly review does not close the gap
Most health systems handle this with sampling. A privacy analyst pulls the break-glass report, reviews a percentage of events, correlates against the scheduling system and badge logs, and escalates anomalies.
That process finds patterns. It is genuinely useful for catching a repeat snooper. It does not help at all with the specific event that becomes contested, because correlation is not attribution: a clinician who was scheduled on that unit, whose badge opened that door, and whose account was logged into that workstation, still has a plausible account of not being the person who typed.
Analysts know this. Ask one how many ambiguous events they closed as appears legitimate last quarter and you will get a wince.
What a stronger record looks like
You do not need to change the workflow. The clinician still clicks through, still types a reason, still gets in within the same two seconds. What changes is that the moment of confirmation produces a signed statement instead of — or as well as — a row.
The statement carries five things, and each one closes a specific question above:
- The rendered patient identity — name, medical record number and date of birth exactly as displayed, hashed. This is what makes wrong-patient access visible rather than deniable.
- The restriction category — why this chart was flagged, so the seriousness of the override is on the record.
- The justification text — hashed, so it cannot be edited afterwards by anyone, including your own administrators.
- A hardware-backed signature — from the clinician's enrolled credential with user verification, so the principal is a human rather than a session.
- A countersignature and timestamp — so the statement verifies offline against a published key, with no callback to any vendor.
None of that contains protected health information. Hashes are one-way: they let someone confirm that a specific name and number were on screen if they already know what to check, and reveal nothing otherwise. The receipt can leave your perimeter, or sit in your archive, without moving a single patient record.
The Break-Glass Evidence Scorecard
You can score your current implementation before changing anything. Nine criteria, drawn from what authentication of an electronic record actually requires, answered yes or no against your own system.
| # | Criterion | Typical EHR answer today |
|---|---|---|
| 1 | Does the record name a human, independently of session state? | No |
| 2 | Does it capture the patient identity as rendered on screen? | No |
| 3 | Is the justification immutable after the fact? | No — it is a database column |
| 4 | Can a third party verify the record without trusting your systems? | No |
| 5 | Does it prove human presence at the moment of access? | No |
| 6 | Does it record the restriction category being overridden? | Sometimes |
| 7 | Is it verifiable if the vendor no longer exists? | No |
| 8 | Does it survive a database administrator with intent? | No |
| 9 | Can the clinician themselves use it to be exonerated? | No |
Most health systems score one or two. That is not a scandal; it is the state of the field. But knowing the number before an investigation starts is materially better than discovering it during one.
What it costs, honestly
The gesture costs the clinician about a second — the same touch that unlocks their phone. The integration work sits at the break-glass confirmation dialog, which is a single, well-defined point in the workflow. The storage is negligible: a receipt is a few hundred bytes.
The real cost is organisational. Once you can prove what happened, you will occasionally prove something uncomfortable. Some health systems would genuinely rather not know. That is a legitimate position to hold privately and an indefensible one to hold in front of a regulator, which is why it is worth deciding deliberately rather than by default.
Where this helps the clinician
It is worth being clear that this control cuts in the clinician's favour at least as often as against. Today, a nurse accused of accessing a chart they did not open has no way to demonstrate it; the only evidence is the log that names them. With a signed record, the absence of their signature is itself evidence. The control that makes snooping provable also makes false accusation refutable.
Who asks about break-glass, and what they want
| Asker | Question |
|---|---|
| Privacy office | Was this access appropriate? |
| Patient | Who looked at my record, and why? |
| Regulator | How do you monitor emergency access? |
| Litigation | Prove this clinician accessed it for this reason |
The first three can be answered from a log. The fourth cannot, because a log entry is a statement the covered entity made about itself, and the opposing party knows who can write to it.
Objections and honest limits
“We review every break-glass access.” Reviewing reads the same weak record. A review adds a second opinion about an artefact that cannot establish who acted.
“Any extra step delays emergency care.” A biometric gesture on a device the clinician already holds adds no meaningful time and replaces a free-text box that adds none of the evidence.
Making emergency access evidential
- Keep the speed. One gesture, not a workflow.
- Bind the clinician, not the account. A credential with user verification.
- Render what is being accessed. Patient, restriction type, and the reason category.
- Use structured reasons. So monitoring can trend them rather than read them.
Terms used here
- Break-the-glass
- Emergency override granting access to a restricted record, justified after the fact.
- Covered entity
- An organisation subject to HIPAA, and the party whose own systems produce the access record.
- Structured reason
- A selected category rather than free text, which makes monitoring and trending possible.
Frequently asked questions
Does this slow down emergency access? No. The clinician performs the same confirmation they already perform, with a device gesture attached. Nothing is blocked, nothing waits for approval, and the control is designed so that a failure to sign never prevents access to the chart — it only changes the strength of the record.
Does the receipt contain protected health information? No. It carries one-way hashes of the rendered identity and the justification text, not the values themselves. Someone who already knows what was on screen can confirm it; nobody else learns anything.
How is this different from our existing audit log? The audit log is written by the system being audited. A signed receipt is produced by a credential under the clinician's sole control and verifies against a published key, so it does not depend on trusting the custodian of the data.
What if the clinician's device is unavailable? Enrol at least two authenticators per clinician, and keep a documented fallback path that still grants access and records the exception. A control that blocks emergency care has failed, whatever its evidentiary properties.
Why is a break-glass log weak evidence? It is a row the covered entity's own system wrote, naming an account. In litigation the opposing party knows who can write to it.
Does reviewing break-glass access help? It adds a second opinion about the same weak artefact. It cannot establish who acted.
Does this slow emergency care? No. A gesture on a device the clinician holds replaces a free-text box, and adds no meaningful time.
Where this fits in Manav
Manav binds the clinician to the exact order, note or access being authorised, with a gesture short enough for the bedside and a record an investigator can verify without the EHR.
Sources and further reading
- 45 CFR §164.312 — HIPAA Security Rule technical safeguards
- HHS Office for Civil Rights enforcement actions and resolution agreements, 2023–2026.
- Federal Rule of Evidence 902 — Evidence That Is Self-Authenticating
- Clinical access-management vendor documentation describing shared-workstation behaviour on user switch.
- ONC / ASTP — health IT safety resources