Three U.S. health systems lost the electronic record to ransomware and ran on pen and paper for weeks. Different EHRs, different attackers, the same failure mode. Prevention did not keep care running. A continuity layer would have.
EHR that went down
Epic. Phone and email went down with it.
Epic. MyChart, phone, email down with it. The core database was never breached; the Windows environment around it was.
Oracle Cerner. The core EMR was never breached. Systems were taken offline to contain the attack, and EHR access was lost across roughly 100 facilities in 13 states.
Days of
Downtime
9
days to Epic restoration. Clinics reopened Mar 2, 2026.
37
days, detection to network-wide
restoration, Jun 14, 2024.
38
days to majority restoration (Nov 9, 2022). Most sites back in 2–3 weeks; a few lagged past a month.
Financial
Impact
Not publicly disclosed. For a large academic system, downtime runs $1M–$8M per day.
Industry composite, hospital financial disclosures
$1.8B FY24 operating loss, ~$1.1B net loss, with the attack a major contributor. 5.6M records involved.
Ascension FY24 results; HHS OCR portal
$160M confirmed cost (up from a $150M estimate). Major factor in a $1.4B operating loss; cash reserves fell $741M. 623,774 notified.
CommonSpirit filings, 2023; HHS OCR portal
Patient Care Affected
All 35 clinics statewide closed. Chemotherapy infusions, ambulatory surgery, and imaging cancelled. ED and hospitals stayed open on paper.
Delayed and lost labs, medication errors, no automated safety checks. A NICU narcotic dosing near-miss was reported. Staff described an ER patient death after a 4-hour lab wait; Ascension did not confirm it. Volumes fell 8–12% YoY.
Ambulances diverted across states. Surgeries delayed, including a Tacoma patient’s cancerous tongue-tumor removal pushed several days.
Contingency
Plan
Paper downtime procedures. Three forensics and recovery vendors engaged; FBI and CISA on site. Daily public updates.
Paper protocols network-wide. Ascension declined to pay the ransom.
Manual and paper processes under existing outage protocols. Drew on a working-capital line of credit while billing caught up.
What the Three Events Have In Common
01
The EHR is the first system reached, not the last. In every case it went offline within hours of detection. Plans that assume the EHR survives day one are planning for a window that does not exist.
02
The EHR vendor is rarely the failure point. At Ascension and CommonSpirit the core record was never breached. The EHR went dark anyway, from containment or from the environment around it being encrypted.
03
Patient-harm reports cluster in week one. Ascension and CommonSpirit both saw documented medication-administration risk events during the early days of paper operation.
Why backup and disaster recovery did not keep care running
In each event the attacker reached the EHR within hours. Traditional disaster recovery sits inside the same domain on the same credentials, so it goes down with production. In two of the three events the core EMR was never breached, yet the EHR went offline anyway, as a containment step or because the environment around it was encrypted. Backups that survive are often suspect, since a system compromised before the snapshot can carry the infection into the restore. Recovery ran in days at best, weeks at worst. Paper was the only fallback that worked, and paper is not a continuity plan.
Where Spare Tire fits, alongside DR
Day to Day
Spare Tire runs continuously on a separate, independent external cloud, outside the hospital network and on separate credentials. It stays current with the EHR through a bidirectional HL7 interface (Full Integration). No change to clinician workflow.
During the Event
When the EHR is unreachable, clinicians keep working from IT-cleared devices across ten clinical modules: Encounter, Vitals, Clinical Notes, Patient Snapshot, Chart Review, Medication, Orders, Results, ADT and Bed Status, and Facility Management.
After Restore
A validation layer screens records before they sync back, so a system showing signs of compromise is not fed contaminated data. Records reconcile to the primary EHR automatically.
Lateral movement from a compromised domain has nowhere to reach, because the continuity layer is not in the same network, on the same credentials, or in the same location as the EHR it protects. It is additive. Nothing existing comes out.
Your backup vendor is the tow truck. Spare Tire is the spare tire in the trunk. You need both. Only one of them means clinicians never stop treating patients.
On attribution. No ransomware group was ever publicly identified in the CommonSpirit incident, and none claimed responsibility. The attacker remains unnamed in public reporting.
Sources. Company financial filings and cybersecurity disclosures; HHS Office for Civil Rights breach portal; Ascension FY2024 results (Sep 17, 2024); CommonSpirit filings and updates (Nov 2022–2023); BleepingComputer, Becker’s Hospital Review, HIPAA Journal; Michigan Public / KFF Health News / NPR (Jun 2024); KING-TV (Oct 2022); Cybersecurity Dive, Mississippi Today (Feb–Mar 2026); Sophos State of Ransomware in Healthcare. Every figure traces to a public primary source. Frontline-staff patient-harm accounts are flagged as such and were not independently confirmed by the named systems.
FAQ
How long does EHR downtime typically last after a ransomware attack?
Based on three documented ransomware events, EHR downtime after a hospital cyberattack ranged from 9 to 38 days. The University of Mississippi Medical Center (UMMC) restored Epic access in 9 days after a February 2026 Medusa ransomware attack. Ascension Health operated without its EHR for 37 days following a May 2024 Black Basta attack. CommonSpirit Health — the second-largest nonprofit health system in the U.S. — spent 38 days reaching majority restoration after an October 2022 ransomware incident. Total combined downtime across these three events: 84 days.
What does EHR downtime cost a hospital?
EHR downtime costs hospitals anywhere from $1 million to $8 million per day, based on industry composite figures and hospital financial disclosures. At the system level, the numbers are far larger. Ascension Health reported a $1.8 billion operating loss in FY2024, with the ransomware attack a major contributing factor. CommonSpirit Health confirmed $160 million in direct incident costs, and its cash reserves fell by $741 million during the recovery period — a key driver of a $1.4 billion operating loss. These figures do not include long-term reputational damage, regulatory penalties, or the cost of litigation tied to patient harm events.
Does ransomware actually breach the EHR database itself?
Not always — and that distinction matters for how hospitals plan. In two of the three events examined here, the core EHR database was never breached. At Ascension Health, the Epic core database remained intact; the Windows environment surrounding it was encrypted. At CommonSpirit Health, the Oracle Cerner EMR was also never breached — EHR access was lost because systems were taken offline as a containment measure across roughly 100 facilities in 13 states. The EHR goes dark regardless of whether it was directly compromised, because the environment around it cannot be trusted.
Why doesn't standard backup and disaster recovery keep a hospital running during an EHR outage?
Traditional disaster recovery fails during ransomware attacks for three structural reasons. First, DR typically sits inside the same domain on the same network credentials as production — so when production goes down, DR goes with it. Second, the EHR goes offline within hours of detection, not days, which means there is rarely time to spin up a DR environment before clinicians lose access. Third, backups that survived the attack are often suspect: if the system was compromised before the snapshot, the restore carries the infection with it. In all three cases studied, paper was the only fallback available. Paper is not a continuity plan.
What patient safety risks occur during EHR downtime?
Patient harm risks concentrate in the first week of paper operation, when staff are least adapted to manual workflows. During the Ascension Health outage, clinicians reported delayed and lost lab results, medication errors, absent automated safety checks, and a documented narcotic dosing near-miss in a NICU. Staff also described an emergency department patient death following a four-hour lab delay — Ascension did not confirm the account. During the CommonSpirit outage, ambulances were diverted across multiple states, and surgeries were delayed, including a cancer patient in Tacoma whose tumor-removal procedure was pushed back several days. At UMMC, all 35 statewide clinics closed, and chemotherapy infusions, ambulatory surgery, and imaging were cancelled.
How does an EHR continuity solution differ from backup and disaster recovery?
Backup and disaster recovery is designed to restore the EHR after the incident ends. An EHR continuity solution is designed to keep clinicians working while the incident is still active. Spare Tire® by ShelterZoom runs continuously on a separate, independent external cloud — outside the hospital network, on separate credentials, with no path for lateral movement from a compromised domain. It stays current with the primary EHR via a bidirectional HL7 interface. When the EHR goes unreachable, clinicians keep working from IT-cleared devices across ten clinical modules without changing their workflow. After the EHR is restored, a validation layer screens records before syncing back, so contaminated data from a compromised system isn’t fed into the primary record. Backup and DR is the tow truck. Continuity is the spare tire. Hospitals need both; only one of them keeps patients being treated.
What clinical functions are available during EHR downtime with Spare Tire?
During an active EHR outage, Spare Tire® provides access to ten clinical modules: Encounter, Vitals, Clinical Notes, Patient Snapshot, Chart Review, Medication, Orders, Results, ADT and Bed Status, and Facility Management. These modules run from IT-cleared devices with no dependency on the hospital’s compromised network environment.
How quickly can ransomware reach a hospital's EHR after initial network compromise?
In every case examined in this study, the EHR went offline within hours of attack detection — not days. This means any continuity plan that assumes the EHR will survive long enough to activate a manual response is planning for a window that doesn’t exist. The practical implication: EHR downtime procedures must already be live and running before an incident occurs, not activated in response to one.
What are HIPAA implications of an EHR ransomware attack?
When protected health information (PHI) is exposed during a ransomware event, health systems are required to notify affected individuals and report to the HHS Office for Civil Rights (OCR). Ascension Health notified 5.6 million individuals following its 2024 breach. CommonSpirit Health notified 623,774 individuals. Both incidents are documented in the HHS OCR breach portal. Failure to maintain adequate security controls and contingency planning can result in regulatory penalties on top of recovery costs. HIPAA’s contingency planning standard (45 CFR § 164.308(a)(7)) requires covered entities to have data backup, disaster recovery, and emergency mode operation plans — a standard that paper-only downtime procedures may not satisfy during multi-week outages.
What should a hospital's EHR downtime procedure include?
Effective EHR downtime procedures should cover: (1) a pre-positioned continuity system accessible from a network independent of the primary EHR; (2) role-specific clinical workflows for each department operating without electronic records; (3) medication administration and verification processes that don’t rely on automated safety checks; (4) lab result communication protocols when LIS-EHR integration is severed; (5) ADT and patient tracking processes to maintain situational awareness across units; and (6) a structured reconciliation process to merge paper or continuity records back into the primary EHR once it’s restored — without introducing data from a potentially compromised period. Paper downtime binders address some of these gaps. An integrated EHR continuity layer addresses all of them.