What it is
The EHR Downtime and Business-Continuity Plan is a practical playbook for keeping a clinic or hospital running when the EHR goes dark — whether the cause is a planned upgrade, an unplanned outage, or a ransomware event. Its premise is that when charting, ordering, and results stop, patient safety depends on tested downtime procedures, not improvisation. The plan covers downtime classification, read-only and paper fallbacks, the Business Continuity Access (BCA) toolkit, and the recovery and reconciliation steps that bring you back to a clean record once the system returns.
The plan is organized into downtime classification and response, the BCA toolkit, a downtime-to-recovery sequence, and a continuity-plan stress test. Classification matters because the response to a planned two-hour upgrade is nothing like the response to a multi-day ransomware lockout, and the plan scales procedures to the type and expected duration of the event. The BCA toolkit is the concrete kit each unit needs: a read-only downtime viewer on dedicated workstations refreshed on a regular cadence, local copies of recent meds, allergies, problem lists, and schedules, pre-printed downtime forms (progress notes, order sheets, MAR, results logs, registration), and a downtime label/wristband and manual MRN assignment procedure.
Crucially, the plan doesn't stop at surviving the outage — it covers getting back to a clean, reconciled record afterward. The downtime-to-recovery sequence and the reconciliation steps address how data captured on paper during downtime is back-loaded, and the stress-test questions probe whether the plan actually works: has every clinical area run a downtime drill in the last 12 months, does the read-only viewer survive the same failure that takes down the EHR, is there a defined process to reconcile downtime MRNs back to the master patient index, and do your RTO/RPO targets match what a ransomware event actually requires.
What it's used for
Healthcare organizations use this plan to prepare for EHR unavailability before it happens, replacing improvisation with rehearsed procedures. Its value is highest when treated as a living document that's drilled and stress-tested, not filed away.
- ✓ Classifying downtime events by type and expected duration so the response scales from a planned upgrade to a multi-day ransomware lockout.
- ✓ Standing up the BCA toolkit per unit — a read-only downtime viewer on dedicated workstations, local copies of recent clinical data, and pre-printed downtime forms.
- ✓ Establishing manual processes — downtime MRN assignment, labels/wristbands, paper orders, results logs, and MAR — so care continues when the EHR is unavailable.
- ✓ Defining the downtime-to-recovery sequence so the transition back to the live system is orderly rather than chaotic.
- ✓ Reconciling data captured on paper during downtime and mapping downtime MRNs back to the master patient index for a clean record.
- ✓ Stress-testing the plan — confirming every clinical area has drilled it recently and that the read-only viewer survives the same failure that downs the EHR.
- ✓ Setting RTO and RPO targets that match the reality of a ransomware event, not just a brief planned outage.
Who uses it
Business continuity for an EHR is owned by IT and emergency management but executed by every clinical unit, and the plan is built to coordinate them around tested, drilled procedures.
Context & good to know
EHR downtime has become a patient-safety and operational issue of the first order, in large part because of ransomware. A modern hospital that loses its EHR loses charting, computerized order entry, results review, and medication administration records simultaneously, and a multi-day outage of the kind ransomware causes can paralyze care if the only fallback is improvisation. The plan's classification scheme exists precisely because the response must scale — a planned two-hour upgrade needs a light contingency, while a ransomware lockout demands manual processes that can sustain full operations for days, which is a fundamentally different posture.
The BCA toolkit is the heart of practical survivability, and its design details matter enormously. A read-only downtime viewer is only useful if it survives the same failure that takes down the EHR — a viewer that runs on the same infrastructure as the primary system fails at the exact moment it's needed, which is why the stress-test question about independent survival is non-negotiable. Combined with local copies of recent meds, allergies, problem lists, and schedules, plus pre-printed downtime forms and a manual MRN process, the toolkit lets a unit keep functioning with the clinical context it needs even when the live system is completely unreachable.
Recovery and reconciliation are where many downtime plans quietly fail, because surviving the outage is only half the job. Everything captured on paper during downtime — orders, notes, MARs, registrations under manually assigned MRNs — must be back-loaded into the EHR and the downtime MRNs reconciled to the master patient index, or the record ends up fragmented and unsafe. The plan's RTO (recovery time objective) and RPO (recovery point objective) targets must reflect what a real event requires, and the drill requirement — every clinical area running a downtime exercise within the last 12 months — is what keeps the whole plan from being a binder nobody has actually tested. Whether the underlying EHR is Epic in a hospital or eClinicalWorks across a clinic group, an untested continuity plan is a liability, not an asset.