Key Takeaways
- EHR downtime is a clinical continuity problem before it is an IT problem, and the recovery workload usually exceeds the outage itself.
- Most unplanned downtime traces to the infrastructure beneath the EHR rather than the application: storage, database, network, or an expired certificate.
- The HIPAA Security Rule requires contingency planning, so a documented downtime procedure is a compliance artifact as well as an operational one.
- A workable procedure is short, printed, and rehearsed. A 40-page plan nobody has read does not survive a 3am outage.
Why EHR Downtime Costs More Than the Outage Window
When the EHR is unreachable, clinicians move to paper. Orders are written by hand, medication administration is recorded on downtime forms, and results are phoned rather than posted. Care continues, but every one of those actions creates a record that has to be reconciled into the system afterward.
That reconciliation is the expensive part. A two-hour outage across a busy department can generate a day of back-entry, performed by clinical staff who were already fully committed, and every manual transcription is an opportunity for a discrepancy. This isn’t a hypothetical: a peer-reviewed study of two mid-Atlantic hospitals found that laboratory result turnaround was delayed by an average of 62% compared with normal operation during EHR downtime events, published in Applied Clinical Informatics (Larsen et al., 2019).
The outage is measured in minutes. The recovery is measured in shifts.
There is a patient safety dimension too. During downtime, allergy checks, interaction warnings, and dosing calculations that normally happen automatically are done by a person under time pressure. This risk is best documented, unsurprisingly, in the most severe electronic health record outages: University of Minnesota research published in JAMA Health Forum found that at hospitals hit by ransomware-driven outages specifically, in-hospital mortality for hospitalized Medicare patients rose from roughly 3 in 100 during normal periods to about 4 in 100 during the attack, an estimated 42 to 67 additional deaths across the 2016 to 2021 study period. Most EHR downtime isn’t caused by an attack, but the study is a clear illustration of what “clinical continuity problem before an IT problem” actually means in the worst case.
Where Unplanned EHR Downtime Actually Comes From
In our experience the application itself is rarely the first thing to fail. The failure is usually underneath it.
- Storage exhaustion on a database volume, which is entirely predictable and entirely preventable with monitoring
- Database performance collapse under load, often after a growth threshold nobody was watching
- Network path failure between a site and the data center, with no automatic failover configured
- Expired certificates, which take down access cleanly and are trivially avoidable
- A failed patch or update applied without a rollback path
- Backup jobs consuming resources during clinical hours because a schedule was never revisited
The pattern is that most of these announce themselves before they cause an outage. A disk fills gradually. A database slows before it stops. Certificates have expiry dates known months ahead. What turns a signal into an outage is nobody watching, or somebody watching only during office hours. This is the layer our managed hosting and cloud monitoring is built around, watching the infrastructure underneath the application rather than waiting for the application itself to fail.
EHR Downtime Solutions: What Actually Reduces Unplanned Downtime
Monitor the Layer Beneath the Application
Monitoring the EHR’s own availability tells you it is already down. Monitoring the storage, database, network path, and certificate estate underneath it tells you before. Thresholds should trigger action, not just an alert into a queue nobody reads overnight.
Make Routine Failures Self-Resolving
Where a failure type is understood, the response can be automated: capacity added when a volume approaches its threshold, traffic failed over when a primary link drops, a failed job re-run automatically. The objective is that the common causes never reach a person at all.
Test Restores Rather Than Trusting Backup Reports
A backup job reporting success is not evidence of a recoverable backup. The only evidence is a restore that worked. This is the single most common gap we find in a first assessment.
Inventory What Is Unsupported
Clinical environments accumulate devices and systems on operating systems that stopped receiving patches years ago. They cannot always be replaced quickly, but they can be identified and segmented. The risk is not knowing.
EHR Downtime Procedure: What a Workable Plan Actually Looks Like
The HIPAA Security Rule requires contingency planning under 45 CFR § 164.308(a)(7), including a data backup plan, a disaster recovery plan, and an emergency mode operation plan. HHS publishes both the requirement and guidance material, including the Security Risk Assessment Tool aimed at small and medium practices, updated as recently as September 2025.
The compliance requirement and the operational reality point in the same direction, but a plan written only to satisfy an auditor tends not to work at 3am. What works has a few properties:
- It is short enough to be read during an incident, not after it.
- It exists on paper, on the unit, because a plan stored only in the system that is down is not a plan.
- It names roles rather than people, so it survives staff turnover and night shifts.
- It specifies the first five minutes explicitly: who declares downtime, who notifies whom, and which forms come out.
- It covers the recovery, not just the outage, because back-entry is where the real workload sits.
- It has been rehearsed at least once, ideally on a night shift rather than a Tuesday morning.
Emergency mode operation plan: the HIPAA Security Rule term for the procedures that let you continue protecting electronic protected health information while operating in emergency conditions. In practice, it is your downtime procedure.
If You’re on Epic: Business Continuity Access (BCA)
Most regional health systems and hospitals in this ICP run Epic, and Epic’s own downtime framework is worth building your procedure around rather than reinventing. Business Continuity Access (BCA) is Epic’s built-in strategy for maintaining access to patient data across server, network, or power-related downtime, and it typically has a few layers:
- Shadow Read Only (SRO), which gives read-only access to Hyperspace so staff can still view patient information, allergies, and recent orders even when they can’t document new ones
- BCA-Web, a browser-based portal for viewing downtime reports from any device, useful when a full data center outage takes local BCA workstations offline too
- BCA workstations, dedicated devices on each unit preloaded with critical reports (active patients, recent orders, medication lists) so staff aren’t relying on memory or a binder
The properties above still apply. A hospital with excellent Epic BCA configuration but no rehearsed process for who declares downtime and who notifies which department hasn’t actually solved the problem, it’s just delayed where the gap shows up.
Planned Downtime Deserves the Same Rigor
Most organizations plan maintenance windows carefully and then treat them as low risk. The failures we see during planned windows are usually the same two: no tested rollback, and a window that was not communicated to every affected department.
Common Planned-Downtime Failure | What Prevents It |
Update applied with no rollback path | Rollback tested in a non-production environment first, with a defined abort point |
Window overruns into clinical hours | Hard stop time agreed in advance, with the abort decision pre-delegated |
A dependent system nobody mapped also goes down | Dependency map maintained as part of the estate inventory |
Departments not told, so no downtime forms ready | Communication list treated as part of the change record |
Client case card
Client environment: a large hospital. Outcome: problem management time reduced by 80%, and 100% availability achieved through proactive and predictive alerts. The mechanism was moving from reactive ticket handling to mapped failure types with automated response, so recurring causes stopped producing incidents.
FAQs
1 How long does typical EHR downtime last?
It varies far too much for an average to be useful. What is more predictable is the recovery workload, which is driven by how many clinical transactions occurred during the outage rather than by its length. A short outage in a busy period can generate more back-entry than a longer one overnight.
2 Is a downtime procedure a HIPAA requirement?
Contingency planning is part of the Security Rule, including a data backup plan, disaster recovery plan, and emergency mode operation plan. A documented downtime procedure is how most organizations satisfy the operational side of that.
3 Can downtime be prevented entirely?
No, and any provider claiming otherwise is overselling. What can be substantially reduced is unplanned downtime from predictable causes, which is most of it. Storage exhaustion, expired certificates, and unmonitored database growth are preventable.
4 Should we test our downtime procedure?
Yes, and preferably not during a weekday morning. A rehearsal on a night shift with reduced staffing is where procedures actually get stress-tested, and it is when real outages disproportionately happen.
