Emergency Access (Break-Glass)

In one sentence

Emergency (“break-glass”) access lets a pre-approved outside provider open one patient’s chart, in read-only mode, for 30 minutes, after passing multi-factor authentication — and every step is recorded in a tamper-evident audit log.

Who can use it

Emergency access is not something a normal user can turn on for themselves.

• An administrator must first create the person as an External User (for example: a locum physician, an on-call consultant, a cross-location specialist, or an auditor).
• That external user is placed in the “External Users” group, which is the single source of truth for “this person is allowed emergency access.”
• The capability has an expiration date set by the admin, and the admin can revoke or extend it at any time.

If someone is not in the External Users group, the system refuses the request.

What has to be true before access is granted

When an external user tries to open a chart, the system checks all of the following. If any check fails, access is denied and the denial is logged:

1. The user exists and is a current member of the External Users group.
2. The user has multi-factor authentication (MFA) enabled — no MFA, no access. See the MFA documentation for the full implementation.
3. The patient they asked for actually exists.

Only when all checks pass does the system create an emergency session.

How a session works (the 30-minute window)

1. The provider searches for a patient and selects one.
2. They must enter a reason (a category plus free-text — e.g. “On-call cross-coverage, patient in ER”).
3. The system creates a single-patient, read-only session that lasts 30 minutes. The clock starts at that moment, not when the account was set up.
4. The session is stored in a fast in-memory store (Redis) with a hard expiry (30 minutes by default; configurable by the operator via the EMERGENCY_SESSION_TTL_MINUTES environment setting). When the time runs out, the session disappears automatically — the provider cannot extend it.
5. A secure one-time link to the chart is emailed to the provider’s own email address. They must already be logged in (and MFA-verified) to use it. This is a deliberate extra confirmation step.
6. One session per patient. If the provider already has a live session for the same patient, they are returned to it rather than starting a second one — so the audit trail stays clean and the timer is not reset.

Key limits:

• Read-only. Emergency users can view the chart but are not given edit, save, or delete capability.
• One patient at a time. Each patient requires its own session, its own reason, and its own audit entry.
• No self-extension. The 30-minute cap is enforced by the server, so a user’s device clock cannot be used to stretch it.

What gets recorded (the audit trail)

Nothing about emergency access is silent. The system writes audit entries for:

Each audit entry captures who, which patient, the reason, the time, the IP address, and the device/browser. These records are sent to a dedicated audit service where they are time-stamped against a trusted clock (NTP) and hash-chained — meaning a record cannot be altered or deleted after the fact without breaking the chain. Session records are additionally stored in an operational table that powers the admin dashboard.

How administrators see emergency access

Administrators have a dedicated Emergency Access section in the admin panel. At the top of the staff/user management dashboard, two summary tiles give an at-a-glance picture:

• Active Break Glass — the number of emergency sessions live right now.
• Total Break Glass — the total number of break-glass sessions on record, counting both active and already-expired sessions.

Below the tiles, admins can open the full break-glass list, which is scoped to their own organization and can be filtered by status (all / active / expired) and searched by provider, patient, MRN, reason, or session ID. Each row shows the provider, the patient, the reason, the time, the IP/device, and whether the session is still live.

In addition to this in-panel view, an email notification is sent to administrators when a session is created, so the access is also surfaced in near real-time and not only discoverable later in a log.

How an administrator stays in control

• Provision: create the external user with a type, an expiration date, and the locations they’re allowed to cover. The user receives an invite email and a temporary password (the admin never sees the password); they must set up MFA before any patient data is reachable.
• Revoke capability: immediately expire the account’s emergency-access capability. The person can still sign in, but can no longer open new sessions.
• Revoke a live session: kill an in-progress session instantly; it ends across all of the user’s open tabs at once.
• Extend / renew: push the expiration date forward to restore access for a user whose capability has lapsed.

Why it is designed this way

• Least privilege: outside providers get the minimum — one patient, read-only, for a short window.
• Server-enforced limits: the 30-minute cap and the read-only scope are enforced on the server, not in the browser, so they can’t be bypassed by tampering with the client.
• Accountability: the mandatory reason, the admin notification, and the tamper-evident audit log mean every emergency access can be reviewed and attributed to a named individual after the fact.