Break-glass access is a controlled override: a documented, deliberately noisy procedure that lets an authorized clinician reach a chart the EMR would normally deny them, when withholding it could harm a patient — in exchange for heavy logging and a mandatory after-the-fact review. It is not a hole in your role-based access control. It is the safety valve that makes strict RBAC survivable, because the alternative — over-provisioning everyone just in case — is how a medical assistant ends up able to open every restricted chart in the database. And under HIPAA it is not a nice-to-have: 45 CFR 164.312(a)(2)(ii) makes an emergency access procedure a Required implementation specification of the Access Control standard.
What break-glass access actually is
The name comes from the fire alarm: the glass makes the action possible but conspicuous. In an EMR, a user hits a chart they are not entitled to see, the system stops them, and instead of a dead end they are offered an override — one that requires re-authentication, a stated reason, and an acknowledgement that the access will be reviewed. Three properties separate real break-glass from a badly configured permission:
- It is an exception, not a path. If staff use it weekly, it is not break-glass — it is your access model leaking, and the fix belongs in RBAC, not in the override.
- It is self-incriminating by design. The user knows, at the moment of use, that the event is logged and will be read by a human.
- It is reviewed. An override nobody reads is functionally identical to giving everyone the access in the first place, minus the paperwork.
HIPAA marks it Required, not Addressable
Administrators tend to know that the Security Rule labels some technical specifications Addressable. Emergency access is not one of them. Here is the Access Control standard at 45 CFR 164.312(a), verbatim in structure:
| Implementation specification | Citation | Status |
|---|---|---|
| Unique user identification | 164.312(a)(2)(i) | Required |
| Emergency access procedure | 164.312(a)(2)(ii) | Required |
| Automatic logoff | 164.312(a)(2)(iii) | Addressable |
| Encryption and decryption | 164.312(a)(2)(iv) | Addressable |
The text is short: "Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency." Note the two verbs. Establish is unconditional — the procedure must exist, in writing, whether or not you ever use it. Implement as needed is what happens in the emergency itself.
Design the procedure before you configure it
The configuration is the easy half. Write the policy first, because the EMR settings are just an encoding of decisions you should have already made.
- Define the qualifying circumstances. Be concrete: an unconscious patient, a restricted chart needed for an active clinical decision, a covering provider without the usual care-team relationship, an outage that strips a clinician of their normal role. Vague criteria produce vague usage.
- Name who may break glass. Usually licensed clinical staff with direct patient-care responsibility. Front desk and billing rarely belong here.
- Decide what break-glass grants. Full chart? Read-only? Everything except records carrying separate legal protection? An override that hands over more than the emergency requires is a minimum-necessary problem waiting to happen.
- Set the duration. Time-box the elevated access — a single session, or a fixed window — and make it expire automatically rather than relying on someone to release it.
- Define the review workflow and its owner. Who reads the report, on what cadence, and what happens when a use looks wrong. Then write the sanction policy consequence, which 45 CFR 164.308(a)(1)(ii)(C) already requires you to have.
Configuring it in the EMR
Vendors implement this under different names — break-the-glass, emergency access, override access, confidential-chart override — and the capability varies. Work through this list with your vendor's documentation open, not from memory:
- Force a reason. A free-text box alone invites "emergency" and "needed it." Use a structured reason-code list with an optional free-text field, so reasons are reportable.
- Re-authenticate at the moment of override. Password or second factor. It converts a reflex click into a decision.
- Show the warning. The interstitial should state plainly that the access is recorded and will be reviewed. This is the glass.
- Flag the chart. The event should surface in the patient's access history, not only in a back-end log.
- Alert in near real time. Route break-glass events to the security officer or compliance inbox on occurrence, not just into a monthly report.
- Test it in the sandbox. Confirm an override actually produces a log entry containing everything below. A break-glass button that logs nothing is worse than no button.
What a break-glass event must capture
The Audit Controls standard at 45 CFR 164.312(b) requires mechanisms that "record and examine activity in information systems that contain or use electronic protected health information." An override record must answer every question a reviewer will ask:
| Field | Why a reviewer needs it |
|---|---|
| User identity and role | Was this person even eligible to break glass? |
| Timestamp (start and end of elevated access) | Establishes duration and lets you cross-check the schedule |
| Patient / record accessed | The core question: whose chart, and was there a care relationship? |
| Reason code and free text | The user's own stated justification, on the record |
| What was actually viewed or changed | Distinguishes "opened the allergy list" from "read the whole chart" |
| Workstation / IP / access channel | On-site at 2 a.m. reads very differently from remote from an unknown IP |
Reviewing every use
This is where break-glass programs fail, and it is also the part HIPAA is most explicit about. 45 CFR 164.308(a)(1)(ii)(D) makes Information system activity review a Required specification: "Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports." A break-glass report is the highest-yield access report you have. Read it.
- Review on a fixed cadence — weekly is realistic, and every event gets looked at. Volume should be low; if it is not, that is itself the finding.
- Corroborate against clinical reality. Was the patient on the schedule, in the ED, on the user's panel? A break-glass on a coworker, a family member, or a local public figure is the classic snooping signature.
- Ask the user when it is ambiguous — promptly, and neutrally. Treating clinicians as suspects teaches them to avoid the override and share logins instead, which is far worse.
- Document the review itself. "We reviewed 4 break-glass events on 2026-07-06; 3 corroborated, 1 escalated" is the evidence that turns a policy into a program.
- Escalate under your sanction policy when a use is not justified, and follow the breach-assessment process if PHI was accessed impermissibly.
Common failure modes
- The shared break-glass account. A generic "emergency" login destroys attribution and violates the unique user identification specification in the same paragraph of the rule. Never.
- Logging without reviewing. The most common finding, and the one that reads worst in an investigation: you built the control and never looked at its output.
- No procedure for the outage case. Emergency access is not only about restricted charts. If your identity provider or SSO is down, clinicians still need the record. That path belongs in the same policy and in your contingency plan.
- Untested after upgrades. Vendor updates change access-control behavior. Re-test the override — and that it still logs — after every major release.
Common questions
Is break-glass access required by HIPAA?
An emergency access procedure is Required. 45 CFR 164.312(a)(2)(ii) directs covered entities and business associates to "establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency." HIPAA does not dictate an in-application break-glass button — that is the common implementation, not the mandate — but the procedure itself must exist and be documented.
How often should break-glass events be reviewed?
The rule says "regularly" and leaves the cadence to you. Review every event, on a schedule frequent enough that you could still reconstruct the clinical context — weekly for most practices. What matters is that the review happened, was documented, and produced action when warranted.
Should break-glass grant access to behavioral health or substance-use records?
Scope it on purpose. Some records carry protections beyond HIPAA — substance use disorder records under 42 CFR Part 2 are the standard example — and your override design must account for that rather than sweeping it into a blanket grant. Decide with counsel, then configure to match.
What if our EMR has no break-glass feature?
You still owe the procedure. Document the manual path — who the clinician calls, who can temporarily elevate access, how the action is logged and reviewed — and record the gap in your risk analysis with a remediation plan. Then ask the vendor, in writing, when the capability is coming.
Common questions
Is break-glass access required by HIPAA?
An emergency access procedure is Required. 45 CFR 164.312(a)(2)(ii) directs covered entities and business associates to establish, and implement as needed, procedures for obtaining necessary electronic protected health information during an emergency. HIPAA does not mandate a specific in-application break-glass button, but the documented procedure itself is not optional.
How often should break-glass events be reviewed?
The Security Rule says regularly and leaves the cadence to you. Review every event, on a schedule frequent enough that the clinical context can still be reconstructed — weekly works for most practices. 45 CFR 164.308(a)(1)(ii)(D) makes information system activity review a Required specification, so the review must be real and documented.
Can we use a shared emergency login for break-glass access?
No. A shared or generic emergency account destroys attribution and conflicts with the unique user identification specification at 45 CFR 164.312(a)(2)(i), which is Required. Every override must be traceable to one named human.
What if our EMR does not have a break-glass feature?
You still owe the procedure. Document the manual path — who is called, who elevates access, how it is logged and reviewed — record the gap as a finding in your risk analysis with a remediation plan, and ask the vendor in writing when the capability is coming.