How to Request Break the Glass on Epic
To understand how to request break the glass on epic, users open a restricted chart. They then enter a valid reason and their password in the prompt. Care teams use this step during urgent clinical cases or technical problems. Still, broad emergency roles often grant far too much data access at once. Once inside, a user might read or change records beyond the single case. How to request break the glass on epic workflows Epic uses break the glass to protect charts that need extra privacy. High
Break-Glass Access Procedures + Access Request Workflows: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To understand how to request break the glass on epic, users open a restricted chart. They then enter a valid reason and their password in the prompt. Care teams use this step during urgent clinical cases or technical problems. Still, broad emergency roles often grant far too much data access at once. Once inside, a user might read or change records beyond the single case.
How to request break the glass on epic workflows
Epic uses break the glass to protect charts that need extra privacy. High profile patients, staff members, and sensitive cases often have this lock enabled. When a clinician or support engineer selects the locked record, a window appears. The system blocks normal chart views until the user finishes this extra step.
First, the user picks a reason from a preset list in the window. Common reasons include emergency care, consulting on a case, or fixing a system bug. Next, the user types brief notes to explain the urgent need in detail. Then, the user enters their system password to confirm their identity and intent. Once submitted, Epic opens the chart and writes an alert to the audit log. Privacy teams later read these logs to check if the request followed policy.
What native emergency access solves and where it falls short
This native workflow works well inside the main clinical app interface. It stops casual snooping by forcing staff to pause and state their intent. It also gives compliance officers a clear list of every override event. Hospital leaders can match each chart view against shift schedules and assigned patients.
Yet this front door check has limits for technical and database teams. IT staff often need emergency access to back end servers or reporting databases. When engineers respond to an outage, they do not use the clinical screen. Instead, they log in to database tools or command lines using shared admin roles. Native app prompts cannot control what happens inside those direct database sessions. Once an engineer logs in with an emergency role, every command runs unchecked. The system checks who logged in, not what individual queries do in flight. A single broad query can pull thousands of emails, phone numbers, or national IDs. Reviewing an audit log days later will not undo a bad command.
Break-Glass Access Procedures + Access Request Workflows: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing technical emergency sessions with finer controls
Technical teams need a safer way to handle urgent back end work. Rather than granting full server roles, teams should scope permissions to specific tasks. Each request should link to an active ticket and require quick peer approval. Time limits must also close the session as soon as the fix finishes.
Data privacy also matters during live database work and support fixing. Support staff rarely need raw personal details to fix a slow query. Rewriting sensitive fields like card numbers or phone numbers in results lowers risk. This approach lets engineers fix urgent bugs while keeping private records safe.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What happens after a user triggers break the glass in Epic?
The system grants immediate chart access for that session and logs the event. Privacy auditors receive an alert to check if the stated reason was valid.
Who reviews break the glass audit logs in a healthcare system?
The hospital privacy team or compliance department checks these logs on a regular schedule. They verify that the user had a real clinical or support duty.
Why do IT teams need different controls than clinical staff for emergencies?
Clinical staff view one patient chart at a time through the standard app. IT staff query large databases where one command can affect thousands of records.