Planned and unplanned downtime are different problems
EHR downtime procedures fail most often because hospitals write one plan for two very different events. Planned downtime — a version upgrade, a database maintenance window, a data centre migration — is scheduled, announced, and usually short. You know when it starts, roughly when it ends, and you can move elective activity away from it.
Unplanned downtime is defined by uncertainty. Nobody knows whether the system returns in ten minutes or ten hours, so the first decision is not technical but clinical: at what point does the ward stop waiting and switch to paper? A plan that omits that trigger leaves each unit to decide independently, and you get half the hospital on paper and half still waiting.
There is a third category worth naming: degraded operation, where the EHR responds but slowly, or one interface is down while the rest works. This is the most dangerous state because staff keep using a system that is silently failing to deliver orders. Your plan needs a declaration path for partial failure, not only for total outage.
The read-only shadow copy is the highest-value control
If a hospital invests in exactly one downtime capability, it should be a read-only copy of essential clinical data that remains available when the main system does not. Being unable to write a new note is inconvenient; being unable to see the current medication list, known allergies, recent results, and active problems is a patient-safety event.
The shadow copy should live on separate infrastructure with a separate failure path, refresh frequently enough to be clinically current, and be reachable from a small number of designated terminals on each floor that staff have actually used before. It does not need to be pretty. It needs to be there, and people need to know where it is.
Decide the content deliberately. A reasonable minimum is active medications, allergies, problem list, recent vitals and results, current census with bed assignment, and the last discharge or admission summary. HealUDoc deployments can schedule that extract as a routine job so the fallback dataset is produced continuously rather than assembled during an emergency.
Minimum contents of a downtime read-only dataset
- Current inpatient census with bed and consultant assignment
- Active medication orders and administration times
- Allergies and adverse reaction history
- Recent laboratory and imaging results with critical flags
- Active problem list and most recent clinical summary
Paper fallback packs that people can actually use
Downtime forms should mirror the electronic workflow closely enough that back-entry afterwards is mechanical rather than interpretive. If the paper medication chart uses different fields from the electronic order, someone has to make clinical judgements while transcribing a backlog, at the end of a difficult shift, which is exactly when errors occur.
Store packs where they will be found under stress: a sealed, labelled box at each nursing station and in each department, with a contents list and a date on the seal. Check them on a schedule and record the check. Packs stored centrally in the IT department are, in practice, packs that do not exist.
Every paper form used during downtime must carry patient identifiers, date, time, and the author's name and designation, because these documents become part of the legal medical record. Pre-printed patient label sheets, produced during normal operation and kept with the census, remove a large source of misidentification.
Communication: who declares, who is told, in what order
The communication tree should fit on one laminated page. It names who is authorised to declare downtime and to declare recovery, which is a single named role with a defined deputy, not a committee. It lists the notification order, the channel used, and the fallback channel when the primary one depends on the same infrastructure that has failed.
Do not rely on hospital email or an internal messaging module for downtime alerts. Use a channel with an independent failure path — SMS, a phone cascade, or a public address announcement — and test it. The number of hospitals whose downtime notification plan depends on the system that is down is not small.
Include external parties who will notice before you tell them: referring clinics, diagnostic partners, scheme portals, and insurers whose pre-authorisation queues are about to stall. A short pre-written message that goes out early costs nothing and prevents a queue of individual calls that occupies the same staff who are managing the incident.
What the one-page comms sheet must contain
- Named declaring authority and deputy, with contact numbers
- Notification order across clinical, support, and executive roles
- Primary and independent fallback communication channels
- Standard message templates for start, update, and recovery
- External contacts including partners, payers, and referrers
Recovery and back-entry: the part everyone underestimates
Recovery is not the moment the system comes back. It is the period, often longer than the outage itself, during which paper activity is entered into the record, orders are reconciled, and results captured on paper are matched to the electronic chart. This phase carries more risk than the outage because the hospital is running two records at once.
Decide the back-entry policy in advance and write it down. Which document types must be transcribed in full, which are scanned and attached, and which are simply filed as originals? Who enters them — the original author, a designated team, or ward clerks? What is the deadline, and who confirms completion for each unit? Ambiguity here produces records that are permanently incomplete.
Every back-entered item must be identifiable as such, with the original time of the clinical event and the actual time of entry both recorded. A medication administration entered six hours late but timestamped as if it were contemporaneous corrupts the record and misleads the next clinician. HealUDoc activity logs distinguish event time from entry time so the reconstruction remains transparent to anyone reviewing it later.
Drills that find gaps instead of confirming assumptions
A downtime drill announced a week in advance, run for twenty minutes on a Tuesday morning on a quiet ward, proves almost nothing. Useful drills happen at shift change, on a busy unit, without the informatics team standing by to help, and they run long enough that the second-order problems appear — the ones about who fetches the pack, who prints labels, and how the pharmacy receives an order.
Debrief on process, not on individuals. The output should be a short list of specific fixes with named owners and dates, and the next drill should verify them. A drill that produces a report nobody actions is worse than no drill because it creates false confidence.
Include a recovery drill at least once a year, because the back-entry process is the least practised and most error-prone part of the whole plan. NABH assessments will ask about business continuity, but the reason to do this well is that the plan will be used, and probably at an inconvenient hour.
“Our first honest drill lasted forty minutes and produced eleven fixes. The one before that, which we had scheduled and rehearsed, produced a certificate.”
Keeping the plan alive between incidents
Downtime plans decay quietly. Staff turn over, wards move, phone numbers change, forms are revised in the EHR but not on paper, and the sealed box on ward four now contains a version of the medication chart that no longer matches the electronic one. Assign an owner and review on a fixed schedule rather than after the next outage.
Tie the review to change management. Any EHR configuration change that alters a clinical form should trigger a check of the corresponding downtime form, and any new department or ward should trigger creation of its pack and its entry in the comms tree. Making this a step in the change process is more reliable than an annual audit.
Finally, capture what actually happened during real incidents. A short, blame-free record of each outage — duration, what was declared, what worked, what did not — becomes the most useful training material the hospital has, and it is considerably more persuasive to clinical staff than a policy document.
