How hospital IT and security leaders keep clinical work moving through a multi-week EHR outage.
Every hospital that made national news for a ransomware outage had backups. Ascension, CommonSpirit, UHS, Change Healthcare, and AnMed all held recoverable copies of their data, and every one of them still reverted to paper while recovery ran for weeks. The gap that closed their facilities was not a missing backup. It was the absence of a way to keep clinicians working while the electronic health record was dark.
This guide covers that gap end to end. It defines EHR downtime continuity and separates it from the backup and disaster-recovery capabilities it is often confused with. It walks through what actually happens during a hospital ransomware outage, the continuity workflows that hold care together across a two-week event, the decision criteria for choosing backup and continuity solutions, the recovery safeguards that keep a restore from reinfecting production, and the standards a surveyor will hold you to. Every figure here carries its source inline.
What This Guide Covers
The short answer.
EHR downtime continuity keeps clinical work moving while the primary EHR is unavailable. It sits alongside two other jobs that get sold under the same label: backup keeps a recoverable copy of the data, and disaster recovery restores the systems. A hospital needs all three, and continuity is the one most downtime plans are missing. The evidence is the outage record: health systems with strong backups and disaster-recovery plans still closed facilities for weeks, because neither capability keeps electronic health record access alive for the clinician at the bedside. A working continuity plan has four properties. It is live before the outage, not stood up during it. The infrastructure and credentials sit apart from the EHR, so the same attack cannot take both down. Clinicians can read and document care in it, not just view a snapshot. And records are validated before they sync back, so a contaminated restore does not reinfect production.
Key figures
95% of healthcare ransomware attacks tried to compromise backups, and 66% succeeded.
Sophos, State of Ransomware in Healthcare 2024.
10 to 24 days is the average length of a ransomware-related EHR outage.
Accountable, 2026; CybelAngel, 2026.
37 days at Ascension across roughly 140 hospitals in 2024; 38 days at CommonSpirit in 2022.
Public reporting; Ascension FY2024 disclosures.
Roughly $900,000 per day in downtime cost, and about $10.9M per hospital ransomware attack before fines.
Accountable, 2026.
36% of affected organizations reported more medical complications and 28% reported higher patient mortality during the disruption.
ORDR, Healthcare Cybersecurity Statistics 2026 Report.
What EHR downtime continuity is.
Downtime continuity is the capability that keeps clinical workflows running at the application layer while the primary EHR is being restored. A clinician can read a chart, record vitals, write a note, place an order, and check a result, from devices that do not depend on the compromised network. It is a separate job from the two capabilities it usually gets bundled with, and the difference is the whole point.
Backup keeps a copy.
Backup captures patient records, imaging, order sets, and configuration so the data survives an event that encrypts or damages the primary EHR. It answers one question: did we lose the data. By itself it does nothing to keep clinicians working during the outage. The copy has to exist, and it is not continuity.
Disaster recovery restores the systems.
Disaster recovery is the plan and infrastructure for bringing systems back after they go down. It sets a recovery point objective, meaning how much data you can afford to lose, and a recovery time objective, meaning how long restoration should take, then provisions the failover and replication to hit those targets. The question it answers is a different one: how fast can we restore. All of this works at the infrastructure layer, on a clock measured in days.
Continuity keeps care moving.
Continuity answers the question the other two do not: can care keep moving while we recover. It is the capability a surveyor and a patient both feel, and it is the one most downtime plans leave out. The three are complementary, not substitutes. The buying mistake that fills the paper carts is treating a strong backup, or a fast disaster-recovery plan, as if it also covers continuity.
| Dimension | Backup | Disaster recovery | Downtime continuity |
|---|---|---|---|
| Question it answers | Did we lose the data | How fast can we restore | Can care keep moving now |
| Layer it works at | Storage | Infrastructure | Clinical application |
| When it acts | Before and after the event | After the event | During the outage window |
| Clinician experience | None during outage | None until restored | Reads and documents care live |
| What it leaves uncovered | The outage window itself | The outage window itself | Long-term data retention |
Why backup and disaster recovery leave a gap during an outage.
The clearest specification for a continuity plan comes from the outage record. Look at what happened to health systems that had backup and disaster recovery but no working continuity layer, and read each pattern as a condition your plan has to withstand.
Backups get hunted first.
Sophos found that 95% of ransomware attacks on healthcare organizations tried to compromise the victim’s backups, and 66% of those attempts succeeded (Sophos, State of Ransomware in Healthcare 2024). Attackers hunt backup repositories, connected storage, and cloud backup accounts as an early step, to remove the option of restoring without paying. A backup reachable with the same domain credentials as production sits inside the blast radius. Continuity has to sit outside it.
The EHR goes dark within hours.
In documented events, EHR access was lost within hours of detection, often because systems were taken offline to contain the attack rather than because the core database was breached. At Ascension, the Epic core database stayed intact while the surrounding Windows environment was encrypted. The EHR went dark anyway. Any capability that has to be spun up in response to the incident is planning for a window that does not exist. Continuity has to be live before downtime hits.
Recovery runs for weeks.
Ransomware-related EHR outages average somewhere between 10 and 24 days depending on the study (Accountable, 2026; CybelAngel, 2026). Ascension ran 37 days across roughly 140 hospitals in 2024. CommonSpirit ran 38 days in 2022. The University of Mississippi Medical Center restored Epic after a nine-day clinic closure in February 2026 (Healthcare Dive, 2026). AnMed restored full read-write EHR access on day 16 in 2026, and outpatient sites stayed closed past that. That multi-week span is the window a continuity plan has to cover, far longer than most paper-only plans were built for.
The cost lands on operations, not just IT.
US healthcare downtime is estimated at roughly $900,000 per day, and the average hospital ransomware attack now runs about $10.9 million in downtime and recovery before regulatory fines (Accountable, 2026). Ascension reported a $1.8 billion operating loss for FY2024, with the attack a major contributing factor. The mean cost to recover from a healthcare ransomware attack reached $2.57 million in 2024, up from $2.20 million in 2023 (Sophos, 2024). The clinical toll is harder to sit with: among affected organizations, 36% reported increased medical complications and 28% reported higher patient mortality during the disruption (ORDR, 2026).
| Health system | Year | Disclosed downtime | Scope and note |
|---|---|---|---|
| CommonSpirit Health | 2022 | ~38 days | Multi-state system. EHR and scheduling disruption. |
| Ascension | 2024 | ~37 days | ~140 hospitals. Epic core intact, environment encrypted. $1.8B FY2024 operating loss, attack a major factor. |
| Univ. of Mississippi Medical Center | 2026 | 9-day clinic closure | Epic restored after clinic closures (Healthcare Dive, 2026). |
| AnMed | 2026 | 16 days to EHR restore | 83 of 106 facilities closed initially. Outpatient sites stayed closed past day 16. |
Building the continuity workflow.
A continuity plan is not one product. It is a set of workflows that assign people, tools, and evidence to the hours and days of an outage. HHS’s 405(d) program publishes an Operational Continuity-Cyber Incident (OCCI) checklist for exactly this, and it assigns roles rather than tasks: an incident leader, departmental leads, superusers, scribes, runners, and a communications lead. Build the workflow around those roles, then decide what each one works in.
The first 12 hours: activate roles, not just paper.
The 405(d) OCCI checklist governs the opening window. Name the incident leader in advance and give departmental leads a standing instruction for when the EHR is unreachable, so the shift does not spend its first hour deciding who is in charge. Superusers move to the floor. Scribes and runners carry orders and results while the primary path is down. The plan that works is the one staff have seen before the day they need it.
Paper is the floor, not the plan.
Every hospital needs current, tested paper kits: pre-staged chart packets, wristbands, pre-numbered labels, order sets, and medication administration records, so staff keep working without inventing a format mid-shift. Paper is the universal fallback and it has a hard limit. It is drilled for outages measured in hours. Across many departments for more than two weeks, it produces a backlog of paper records that has to be re-entered into the restored EHR by hand, which is slow and error-prone at exactly the wrong time.
A live continuity layer covers the days paper cannot.
Between the paper floor and the restored EHR sits the capability most plans are missing: a system clinicians can authenticate to and document in while production is down, live from the first hour, on separate infrastructure. It carries the reads and the documentation that paper handles badly at scale, and it produces structured records that can be validated back into the EHR instead of retyped. The workflow question is not whether to keep paper, it is what carries the load once the outage passes the 72-hour mark that paper was designed for.
Design target, not a measured cohort. No public dataset splits outage-hit hospitals into audited groups with and without a continuity layer. The events named in this guide all had backups, disaster recovery, or paper, and none had a running continuity layer. The continuity properties described here are what the standards require and what the failure modes call for, stated as a design target rather than a controlled comparison.
Backup and continuity decision criteria.
Two decisions sit inside a downtime plan: how the copy is protected, and how continuity is delivered. Handle the copy with the backup rule the sector has moved to, then score continuity against the criteria the outage record rewards.
Protecting the copy: the 3-2-1-1-0 rule.
Healthcare and its cyber-insurers have largely moved from 3-2-1 to 3-2-1-1-0: three copies of data, two media types, one offsite, one immutable or air-gapped, and zero restore errors confirmed by testing (AvePoint, 2026; Central Data Storage). The immutable copy is write-once and read-many, with a retention window an attacker cannot shorten even with stolen admin credentials. This protects the data. It does nothing for electronic health record access during the outage, which is why the copy decision and the continuity decision are separate.
Choosing continuity: six criteria the outage record rewards.
Score any continuity solution against six criteria. The full buyer’s guide, Choosing EHR Downtime Backup Solutions for Hospitals, works each one with vendor questions and red flags. The scorecard below is the summary.
| Criterion | What a 0 looks like | What a 3 looks like | Weight |
|---|---|---|---|
| Survivability / separation | Same domain and credentials as the EHR | Separate infrastructure and credentials, no path from hospital domain compromise | Critical |
| Clinical usability in outage | Read-only or IT-only restore | Clinicians document care live, no retraining | Critical |
| Integrity on recovery | Restores whatever it holds | Validates and time-stamps before write-back, blocks contaminated ingestion | Critical |
| Integration footprint | Rip-and-replace or write path into production | HL7 alongside existing EHR, read-only in steady state | High |
| Compliance fit | Generic security posture | Maps to EC.02.01.01, §482.24, §164.308(a)(7) with survey evidence | High |
| Operational proof | Untested until a real outage | Provable in a planned downtime window, produces evidence | High |
Weight by what your environment can least afford to lose, then compare totals. A solution that scores zero on survivability or integrity is disqualified regardless of its total, because those two are the criteria the outage record punishes hardest.
Recovery safeguards on write-back.
The outage does not end cleanly when the EHR comes back. Restoring is where a second failure hides. 73% of healthcare organizations restore from backups after an attack (Sophos, 2024), and backups are frequently the thing the attacker touched. Two safeguards keep the restore from becoming the next incident.
Validate before write-back.
Records created during downtime should be time-stamped and validated before they sync into the primary EHR. A restore that pushes contaminated records into a recovered system reintroduces the infection. Ingestion from a still-compromised environment should be blocked, and conflicts should surface for clinical review rather than overwrite silently. The safeguard is a gate that sits between downtime records and production and decides what is allowed through.
The days of care delivered on paper or in a continuity system have to land back in the EHR accurately. Hand re-entry of a two-week paper backlog is where reconciliation errors concentrate. Structured records from a continuity layer can be validated and written back rather than retyped, which removes the error surface that manual reconciliation creates. Plan the write-back before the outage, not during the scramble to reopen.
Mapping the plan to compliance.
Ransomware readiness runs through requirements you already carry, not beside them. Treat the standards below as a floor, and note that continuity, not just backup, is what several of them actually test.
| Standard | What it requires | Where continuity shows up |
|---|---|---|
| HIPAA 45 CFR §164.308(a)(7) | Data backup, disaster recovery, and emergency-mode operation plans | Emergency-mode operation is the continuity clause, not backup |
| Joint Commission EC.02.01.01 | Accurate clinical documentation during downtime | Documentation has to keep flowing across a multi-week outage |
| CMS 42 CFR §482.24 | Safe medication management and accurate records | Medication administration records maintained through the outage |
| HHS 405(d) OCCI checklist | Assigned incident roles for the first 12 hours | The activation workflow continuity plans are built on |
A surveyor asking how you keep medication administration records accurate through a two-week outage is asking about continuity. Paper-only procedures may not satisfy that standard across a multi-week event. Cyber-insurance carriers increasingly condition coverage on the immutable-copy and tested-restore additions to the backup rule, which puts compliance and insurability on the same track. A plan that produces survey-ready evidence for downtime documentation and medication management is worth more than one that only satisfies a generic security checklist, because the first covers a requirement you will be audited against.
Where a dedicated continuity layer fits.
To show the criteria in use, here is how one dedicated continuity solution, Spare Tire by ShelterZoom, maps to them. The point is the method. Run any candidate through the same grid.
Separation and integration.
Spare Tire is externally hosted on ShelterZoom’s cloud under its own credentials, architecturally separated from the EHR it protects, so a compromise of hospital domain credentials has no path to it. It runs alongside Epic, Oracle Cerner, MEDITECH, or any HL7-capable EHR through an HL7 interface, read-only in normal operation, so there is no write path into production for an attacker to exploit.
Clinical use and integrity.
During an outage, clinicians authenticate to the separate system and keep documenting encounters, recording vitals, writing notes, placing orders, and checking results in real time, from IT-cleared devices, without changing workflow. On the way back, the CyberVault validation layer gates the write-back, so records from a still-compromised environment are blocked and conflicts surface for clinical review.
Compliance and proof.
The solution targets the EC.02.01.01 and 482.24 downtime requirements directly and operates under a Business Associate Agreement with US-based data residency. Because it is built to be activated and tested during planned downtime windows, a hospital can prove it before the unplanned outage, and the test doubles as training.
A hospital evaluating it, or any competitor, should still run its own activation test during a planned window before trusting it in an unplanned one. The framework is what protects the decision. The product is what has to pass it.
Frequently asked questions.
What is EHR downtime continuity?
EHR downtime continuity is the ability to keep clinical work moving while the primary electronic health record is unavailable. It is distinct from backup, which keeps a recoverable copy, and disaster recovery, which restores the systems. Continuity operates at the application layer during the restore window, so clinicians can read records and document care while IT works to bring the EHR back.
How is downtime continuity different from backup and disaster recovery?
Backup answers whether the data survived. Disaster recovery answers how fast the systems come back. Continuity answers whether care can keep moving while they are still down. A hospital can hold a perfect backup and run disaster recovery on schedule and still close facilities for weeks, because neither keeps clinicians working during the outage. Downtime plans most often lack the continuity piece.
How long do hospital EHR outages last?
Ransomware-related EHR outages average roughly 10 to 24 days depending on the study (Accountable, 2026; CybelAngel, 2026). Ascension ran 37 days across about 140 hospitals in 2024. CommonSpirit ran 38 days in 2022. AnMed restored full EHR access on day 16 in 2026. That multi-week span, not a few hours, is the window a continuity plan has to cover.
Does HIPAA require an EHR downtime plan?
The HIPAA Security Rule contingency-planning standard, 45 CFR 164.308(a)(7), requires data backup, disaster recovery, and emergency-mode operation plans. Joint Commission standard EC.02.01.01 and CMS Condition of Participation 42 CFR 482.24 separately require accurate clinical documentation and safe medication management during downtime. Paper-only procedures may not satisfy those standards across a multi-week outage, which pushes the plan toward a tested continuity layer.
Why do paper downtime procedures fail past 72 hours?
Paper kits, runner protocols, and manual order sets are built and drilled for outages measured in hours, on the assumption of a few affected units and a return to normal within a shift or two. Stretched across many departments for more than two weeks, they generate a backlog of paper records that has to be re-entered by hand, and the reconciliation error rate climbs at exactly the wrong time.
What recovery safeguards keep a restore from reinfecting the EHR?
A validation gate between the records created during downtime and the production EHR. Because 73% of healthcare organizations restore from backups after an attack (Sophos, 2024) and backups are frequently compromised, records should be time-stamped and validated before write-back, ingestion from a still-compromised environment should be blocked, and conflicts should surface for clinical review rather than overwrite silently.
What is the most important criterion when choosing a downtime solution?
Architectural separation. The recurring failure in hospital ransomware incidents is a continuity or backup tool that shares the EHR’s domain and credentials, so it is encrypted alongside production. A solution on separate infrastructure and credentials, with no path from a hospital domain compromise, is the one still available when it is needed. It is the criterion the outage record punishes hardest.
Sources.
Sophos, “The State of Ransomware in Healthcare 2024” https://www.sophos.com/en-us/blog/the-state-of-ransomware-in-healthcare-2024
Accountable, “2026 Healthcare Ransomware Statistics: Incidents, Costs, Downtime, and Trends” https://www.accountablehq.com/post/2026-healthcare-ransomware-statistics-incidents-costs-downtime-and-trends
CybelAngel, “Ransomware in Healthcare 2026: The Attack Timeline” https://cybelangel.com/blog/ransomware-in-healthcare-attack-timeline/
ORDR, “Healthcare Cybersecurity Statistics 2026 Report” https://ordr.net/blog/healthcare-cybersecurity-statistics-2026-report
Healthcare Dive, “University of Mississippi Medical Center reopens clinics after ransomware attack” (2026) https://www.healthcaredive.com/news/university-of-mississippi-medical-center-ransomware-attack/812823/
AvePoint, “What Is the 3-2-1 Backup Rule? A Complete 2026 Guide” https://www.avepoint.com/blog/backup/3-2-1-backup-rule
Central Data Storage, “3-2-1-1-0 Backup Rule for Healthcare” https://centraldatastorage.com/3-2-1-1-0-backup-rule-for-healthcare/
HHS 405(d) Program, Health Industry Cybersecurity Practices and OCCI Checklist https://405d.hhs.gov/cornerstone/hicp
Joint Commission standard EC.02.01.01; CMS Condition of Participation 42 CFR 482.24; HIPAA Security Rule 45 CFR 164.308(a)(7).
Spare Tire® by ShelterZoom is an EHR downtime resilience layer, architecturally separated from the systems it protects. Learn more at sparetire.io or reach the team at Info@shelterzoom.com.