The Morning the EHR Will Not Load: A Continuity Plan You Can Actually Run

It is 7:50 on a Monday. The first patient arrives at 8:00, and the schedule that says who that is lives in the EHR — along with their phone number, the note from last week, and the authorization count you are supposed to be tracking. The login page spins. Somewhere, a status page you have never bookmarked is turning yellow. What your practice does in the next ten minutes was decided months ago, or it was not decided at all — and “not decided” looks like a lobby filling with families while the front desk refreshes a browser tab.

Moving your practice to a cloud EHR moved the servers; it did not move the responsibility. When the system is unreachable — a vendor outage, your own internet failing, a ransomware incident on either side, or a vendor relationship ending badly — the sessions still happen, the documentation obligation still applies, and the recovery still lands on you. This article is the plan for that: what the rules already require, the downtime procedure to run when the login fails, the paper kit and export cadence that make the procedure possible, and the contract clause that decides how bad the worst case is allowed to get.

Continuity planning in healthcare is not a discretionary best practice, because the HIPAA Security Rule names it. The contingency-plan standard at 45 CFR 164.308(a)(7) requires covered entities and business associates to establish policies and procedures for responding to an emergency or other occurrence — the regulation’s own examples are fire, vandalism, system failure, and natural disaster — that damages systems containing electronic protected health information. Under that standard, three implementation specifications are marked Required: a data backup plan (procedures to create and maintain retrievable exact copies of ePHI), a disaster recovery plan (procedures to restore any loss of data), and an emergency mode operation plan (procedures to keep the critical business processes that protect ePHI running while you operate in emergency mode). Two more are Addressable, which means you must assess them and either implement them or document why an alternative is reasonable: periodic testing and revision of the plan, and an analysis of which applications and data are most critical to have back first.

There is also a well-built free tool for exactly this exercise. The SAFER Guides — self-assessment guides for safe EHR use published by ASTP/ONC, the federal health-IT office — include a Contingency Planning guide with recommended practices for planned and unplanned EHR unavailability, each rated on a scale from “not implemented” to “fully implemented.” The 2025 update added practices aimed at ransomware and at partial downtime, where the system is technically up but too slow or too broken to use. It is written with hospitals in mind, but a small practice can walk the same checklist in an afternoon and come out with an honest gap list.

Planning goes wrong when “the EHR is down” is treated as one scenario. It is at least three, and they threaten different things. The first is the short outage — the vendor has an incident, or your internet or power does, and the system is back the same day. What it threatens is today: knowing who is coming, reaching them, running sessions, and documenting them. The second is the long outage — a multi-day incident, most plausibly ransomware on the vendor’s side or a disaster on yours. It threatens the week: authorizations tick down, claims age toward timely-filing windows, and paper accumulates faster than anyone will enjoy back-entering it. The third is not an outage at all: the vendor relationship ends — a shutdown, an acquisition, a dispute, a migration you chose — and the question becomes whether years of records come out in a form another system can use. The downtime kit and procedure answer the first two. Only the export cadence and the contract answer the third.

The Addressable criticality analysis sounds like paperwork, but for a therapy practice it collapses into one useful question: what would you need in the first hour that only the EHR knows? For most practices the honest list is short — today’s and this week’s schedule, patient and caregiver contact information, the safety-relevant clinical facts (allergies, precautions, behavioral notes), where each patient stands against their authorization, and what has been billed but not yet paid. That list, not the whole database, is what the standing export exists to keep within reach.

This is the plan to write down, print, and put where the front desk can reach it without a working computer. It assumes the kit and export cadence described below already exist. The whole thing should fit on one page — a procedure nobody can hold in their head during a stressful morning is a procedure that will not be followed.

1. 01

   Declare downtime and start the log

   Name in advance who can make the call — the owner, or whoever opens the clinic — so nobody burns twenty minutes wondering if it is “really” down. Write the start time on the incident log sheet from the kit. From this moment, every workaround gets a line on that log: it becomes the worklist for recovery, and the record that explains any late documentation.

2. 02

   Open the kit and confirm the day

   Pull the most recent schedule export and work the day from paper. If the outage is yours — power or internet rather than the vendor — a phone on cellular data can often still reach the EHR; check that before assuming full downtime, because a partial workaround changes everything about the morning.

3. 03

   Check the vendor before you diagnose yourself

   One person — not everyone — checks the vendor’s status page and support line, both listed in the kit, and reports back. Note what the vendor says and any estimated recovery time on the log. This is also the moment to resist a common failure the SAFER guidance warns about: half-working systems. If the EHR is up but unusably slow or erroring, declare downtime anyway and stop splitting the team between two workflows.

4. 04

   Communicate on the channels you planned

   The front desk works the printed schedule: confirm who is coming, reschedule what cannot happen, and tell arriving families plainly that systems are down and care is continuing. Keep protected health information off personal texting apps in the scramble — the downtime plan should name the channel staff use, and “whatever app was handy” is how a system outage becomes a privacy incident.

5. 05

   Run sessions and document on paper

   Treat the visit as normal and the note as portable: the kit’s paper daily-note form should mirror your usual note structure — appearance and response, what was worked on, objective data, plan — so nothing has to be reinvented mid-session. Date and sign each page, mark it “documented during EHR downtime,” and keep every sheet with the log. Billing waits; treatment and documentation do not.

6. 06

   Recover deliberately, not casually

   When the system returns, do not let the paper drift back in “as people get to it.” Work the log line by line: enter or scan each paper note under your practice’s late-entry convention, re-verify anything scheduled or changed during the outage, and release held claims. Recovery is finished when the log is empty, and someone should own saying so.

7. 07

   Debrief within the week

   Thirty minutes, everyone who worked the outage, three questions: what did the kit not have, what did people improvise, and what will we change in the plan? The Security Rule marks testing and revision as Addressable — an outage you already survived is the cheapest test you will ever run, and wasting it is how practices get to relive it.

The procedure above only works if the kit exists before the outage, is stored where a locked-out computer cannot trap it, and is treated as containing what it contains: protected health information. A physical folder in a locked drawer, or an encrypted drive plus a thin printed layer, both work — a folder taped to the front desk in the open does not.

Everything in the kit decays. A schedule export from six weeks ago is a list of people who used to have appointments; contact information ages; the caseload turns over. So the real design decision is not what to export once — it is the standing cadence. A workable default for a small practice: the operational layer (upcoming schedule, active-caseload contacts, safety flags) refreshed weekly, on a named day, by a named person, with the calendar reminder doing the remembering; and the deep layer — a fuller export of records, evaluations, and billing data in whatever portable formats your EHR offers — refreshed monthly or quarterly, depending on how fast your documentation accumulates and how painful re-creating an interval of it would be.

Two rules keep the cadence from quietly failing. First, the export is ePHI and must live like it: encrypted, access-controlled, and inside your practice’s systems — not on a personal laptop or a consumer drive, and disposed of properly when superseded. The Security Rule’s backup specification asks for retrievable exact copies, and “retrievable” is doing real work in that sentence. Second, open the file. An export nobody has ever opened is a hope, not a backup — once a quarter, confirm the download actually contains what the label says, that it opens, and that a person other than the one who made it can find it. If your EHR can schedule reports or exports automatically, automate the run and keep the human check; if it cannot, that is worth knowing about your EHR.

Downtime ends. The scenario that does not resolve on its own is the third one: the vendor is acquired and sunsets the product, raises prices past what the practice can carry, or the relationship simply ends — and years of clinical and billing records are on the other side of a login you are about to lose. Whether that is an inconvenience or a crisis was settled the day the contract was signed, in clauses most buyers never read: who owns the data, what export you get, in what format, on what timeline, at what cost, and how long the vendor retains anything after termination.

Federal policy helps here, but less completely than practice owners tend to assume, and the gap is worth understanding before you rely on it. EHR products certified under the ONC Health IT Certification Program must, under the Electronic Health Information export criterion at 45 CFR 170.315(b)(10), let a user export a single patient’s EHI on demand without the developer’s help, and export the full patient population’s EHI — the criterion written for switching systems — in an electronic, computable format with the format documentation publicly available. The federal information-blocking rules at 45 CFR Part 171 separately prohibit practices likely to interfere with access, exchange, or use of electronic health information — and they bind health care providers, health information networks and exchanges, and developers of certified health IT.