How to Add Break the Glass in Epic
To learn how to add break the glass in epic, you set up an emergency prompt on sensitive patient profiles. When staff open these charts, the app asks for a reason and a password. Hospital IT teams often start with broad user roles to avoid care delays. Broad roles let too many people read private data without a real clinical need. How to add break the glass in epic workflows The native emergency feature works by placing a lock on specific chart types. Admins define which patients need extra c
Break-Glass Access Procedures + Just-in-Time Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To learn how to add break the glass in epic, you set up an emergency prompt on sensitive patient profiles. When staff open these charts, the app asks for a reason and a password. Hospital IT teams often start with broad user roles to avoid care delays. Broad roles let too many people read private data without a real clinical need.
How to add break the glass in epic workflows
The native emergency feature works by placing a lock on specific chart types. Admins define which patients need extra care, such as VIPs or staff members. You also flag records linked to restricted care units or sensitive health issues. Next, the security team maps user roles to these protected groups.
Normal care teams open standard charts with no extra prompts. When a nurse or doctor outside the care team clicks a locked chart, a prompt appears. The user must pick a valid reason from a preset list. They also type in their password again to prove who they are.
Once the user submits the form, the app opens the chart right away. It does not wait for a manager to approve the request first. In emergency care, waiting for a human to approve a request can cost lives. Instead, the system writes an event to the audit log for later review.
Privacy officers read these audit logs every day to check for misuse. They match the stated reason against the work schedule and patient location. If a user opens a chart out of curiosity, the privacy team steps in.
What the native setup solves and what it misses
This built-in workflow solves front-end chart privacy inside the clinical app. It stops casual snooping by doctors, nurses, and billing staff. Every emergency chart view leaves a clear trail for the audit team.
Still, the native tool only guards the clinical user interface. Hospital IT staff, data analysts, and support engineers often work outside the front-end app. They log in directly to reporting databases, cache servers, and Linux hosts. When a backend system breaks at night, engineers need fast emergency access to fix it.
Break-Glass Access Procedures + Just-in-Time Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
App-level prompts do not cover direct database queries or shell sessions. Once an engineer logs into a database, role rules do not inspect individual queries in flight. A single query can return thousands of emails, phone numbers, and national IDs at once. Native app logs will not show what raw database commands the engineer ran.
Securing backend data and emergency support sessions
To close this gap, engineering teams must govern direct database and server sessions. You need a way to approve emergency backend tasks and log every action. Good controls inspect queries and commands as they run, rather than just checking who logged in.
Data masking also plays a key part during backend support work. When an engineer runs a query to fix a bug, masking rewrites matched fields in results. The tool replaces emails, phone numbers, card numbers, and national IDs with safe placeholders. Engineers can still see row counts and system errors to fix the issue.
Adding peer approval to high-risk commands also cuts down on mistakes. If an admin needs to run an update script during an outage, a peer can approve it in chat. This brings the same audit trail from the clinical app down to the database layer.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Does break the glass wait for a manager to approve chart access?
No, the clinical app opens the chart right after the user enters a reason and password. Waiting for a manager in a medical emergency would delay patient care. The privacy team reviews the event log after the fact.
Who reviews the audit logs after an emergency override?
Hospital privacy officers and compliance teams review these audit reports on a set schedule. They check that the staff member had a real clinical or billing reason to view the record.
Does the clinical override protect backend reporting databases?
No, the native prompt only works inside the front-end clinical software. Engineers who query reporting databases or log into servers bypass the app interface and need separate database access controls.