At 8:07 on a fully booked Tuesday, the schedule screen stops loading. One receptionist starts a spreadsheet. A medical assistant takes a phone photo of yesterday’s list. A clinician writes on the back of a referral. The outage is now three record systems, and recovery will be worse than the downtime.
An EHR downtime plan stops that split. In the first 30 minutes, confirm the outage, put one person in charge, switch every role to approved forms, protect patient identity and urgent information, and create a reconciliation queue. The plan covers care continuity and ePHI protection alongside IT recovery.
The working rules
- One incident lead declares the operating state and owns the clock.
- Keep a printed or otherwise approved downtime packet outside the unavailable EHR.
- Separate clinical continuity from vendor recovery. Both need owners.
- Recovery ends only after every paper note, order, result, charge, and message is reconciled.
An outage is an operating state, not a blank screen
The HIPAA Security Rule’s contingency-plan standard requires covered entities to prepare for emergencies or occurrences that damage systems containing electronic protected health information. HHS breaks that standard into data backup, disaster recovery, emergency-mode operations, testing and revision procedures, and application and data criticality analysis (HHS audit protocol).
That legal frame matters, but it does not tell the receptionist which schedule to trust at 8:09. The 2025 ASTP/ONC SAFER contingency guide fills the operational gap. It treats planned and unplanned EHR unavailability as a patient-safety problem and calls for clinician participation in substitute workflows.
A small practice therefore needs two linked plans:
- the technical response that diagnoses, contains, restores, and verifies the system; and
- the clinical operating response that manages patients while the system is unavailable.
The same person may coordinate both in a tiny clinic. The responsibilities are still different.
Use the HIPAA app-architecture checklist to connect this operating plan to access, logging, backup, and vendor controls. The EHR data-migration guide covers a different continuity event: moving records deliberately rather than working through an outage.
The first 30-minute card
Print this card, tailor it to the practice, and keep it with approved downtime forms. A plan trapped inside the unavailable EHR is decorative.
| Clock | Incident lead | Front desk | Clinical team | IT or vendor contact |
|---|---|---|---|---|
| 0-5 minutes | Confirm scope, record start time, declare the downtime state | Stop unsanctioned workarounds and use the approved schedule source | Finish any immediately time-sensitive action under the clinical escalation policy | Open the approved support path and preserve incident details |
| 5-15 minutes | Assign one communication channel and set the next update | Verify each patient’s identity against the downtime source | Use approved forms; record author, date, time, encounter, decisions, and orders | Determine whether the event is local, vendor-wide, security-related, or power/network related |
| 15-30 minutes | Decide whether the patient day continues, narrows, or pauses | Mark arrivals, cancellations, calls, and reschedules in one queue | Flag orders, results, medications, referrals, and follow-ups that need later reconciliation | Give an evidence-based status, not an invented restoration time |
| Recovery | Open the reconciliation log and retain the incident record | Re-enter or route schedule changes once | Reconcile every signed note and outstanding clinical item through the approved process | Verify availability, integrity, access, and any security response before closure |
The AAFP’s 2026 outpatient downtime guidance makes the same practical point: procedures should cover paper scheduling, visit documentation, billing, communications, prescriptions, orders, results, and referrals (AAFP Family Practice Management). A single blank SOAP form is not a downtime plan.
Build one approved packet before the outage
The packet should be boring. That is a compliment.
Start with a role sheet. It names who may declare downtime, who leads, who contacts each vendor, who makes clinical continuation decisions, and who owns reconciliation. Include alternates. The person who wrote the policy may be on a flight when the router dies.
Then add approved forms for the work the clinic has chosen to continue. At minimum, the practice should decide how it will handle:
- patient identification and the current schedule;
- encounter documentation with author, date, and time;
- allergies, medications, urgent history, and other information the clinical policy requires;
- orders, results, referrals, prescriptions, and follow-up tasks;
- charges and coverage information if those processes continue; and
- custody of every paper or offline artifact until reconciliation.
Do not print a full patient database merely because printing is possible. The risk analysis should decide what minimum information must remain available, where it is kept, who can reach it, and how stale copies are replaced. HHS requires protection of ePHI during emergency-mode operations, not unlimited copies in an unsecured drawer.
Patient identity is the hard part
Most downtime errors start before anyone writes a note. The wrong chart label, yesterday’s schedule, two patients with similar names, or a handwritten callback number can poison the recovery queue.
Make identity verification explicit on every downtime form. Pick the identifiers and exception path in advance. Assign one temporary encounter or packet number if the practice needs it. Never let individual staff invent numbering systems at different desks.
The packet also needs a visible version date. When the practice changes locations, vendors, phone trees, or EHRs, old copies should be removed. A flawless 2024 plan with a disconnected support number is not a plan in 2026.
Downtime may also be a security incident
An outage does not prove a cyberattack. It also does not rule one out.
Staff need a separate escalation cue for suspicious events: ransom messages, unexpected account lockouts, altered data, unusual login prompts, or vendor notices. The incident lead should preserve evidence and follow the approved security response instead of repeatedly rebooting devices or moving PHI into personal email. HHS notes that contingency planning supports availability during ransomware and other emergencies, while incident response addresses containment and recovery (HHS ransomware guidance).
Write the rule plainly: normal outage troubleshooting stops when the security escalation path begins.
Recovery is a queue, not an announcement
“The EHR is back” is the midpoint.
Open one reconciliation log. Each downtime artifact gets an owner and a terminal state. The practice decides how the source document is retained, how the electronic record identifies a delayed entry, and which person confirms completion. Do not hide the gap by copying text into a chart with a false encounter time.
| Recovery item | Minimum check before closure |
|---|---|
| Encounter note | Correct patient, author, service date, actual entry time, signature, original artifact retained per policy |
| Order or referral | Correct destination, transmission confirmed, duplicate risk checked |
| Result | Routed to the responsible clinician, acknowledgment and follow-up handled |
| Medication or prescription | Authorized clinician review complete; duplicate or conflicting action checked |
| Appointment or message | Final schedule and callback queue agree |
| Charge | Service, date, clinician, and supporting record match |
Close the incident only when the log reaches zero or an accountable owner accepts each remaining exception. Keep the after-action note short: what failed, what nearly failed, the owner, and the deadline.
What to make a vendor demonstrate
Cloud hosting does not erase the practice’s continuity responsibility. Ask the EHR or practice-software vendor to run a synthetic outage in front of you.
Request the actual support route, status communication, backup and recovery commitments, export options, access logs, and restoration testing described in the contract. Then test the practice side: schedule access, identity checks, documentation, pending results, order status, and reconciliation. A slide that says “99.9%” cannot show what Tuesday morning looks like.
Patient Square is an AI clinical platform. Practice Copilot brings the whole practice under one AI copilot: an ambient AI Medical Scribe that hands back a structured SOAP note, ICD-10 suggestions, and a prescription draft minutes after the visit, plus Patient Square EHR from the Copilot tier or an alongside path for an existing EHR, with scheduling and messaging as you move up the plan. Public scope does not promise automatic failover, an offline chart mirror, or write-back to another EHR. Those are discovery questions.
Use the security page to inspect current data-handling claims, then read the Practice Copilot scope. During a product evaluation, bring a downtime scenario and ask the presenter to show the boundary, the failure, and the recovery evidence. A polished happy path can wait.
Run a 20-minute drill next Friday
Pick five synthetic patients: one routine follow-up, one same-name identity risk, one prescription question, one pending result, and one referral. Disable normal access for the drill. Watch where staff reach for personal devices, stale lists, or memory.
The result is not a pass or fail grade. It is a repair list. Update the packet, name the owners, and schedule the next test. The HHS audit protocol explicitly examines testing and revision, and the SAFER guide treats maintenance as continuing work. A downtime plan improves when it has embarrassed the practice safely, before a real outage gets the chance.