Lumenly
Back to Blog
downtime plandowntime checklistEHR downtime preparednessEHR outage planhospital downtime proceduresrecovery plandowntime readiness assessmentclinical informaticsransomware recovery hospital

Your Epic Downtime Plan Isn't Ready Until It Can Answer These 12 Questions

A practicing CMIO's field checklist for pressure-testing whether your Epic downtime and recovery plan would actually hold. 12 questions, most fail 3+

Ivan Ip, MDIvan Ip, MD· CMIO, Lumenly Health·4 min read·August 19, 2026
Your Epic Downtime Plan Isn't Ready Until It Can Answer These 12 Questions

Most Epic downtime plans are thorough about going down and nearly silent about coming back up. I know, because I've read a lot of them — and because I led my own health system through a ransomware recovery where the return was harder than the outage itself.

A downtime plan feels ready when it's thick. It is ready when it can survive contact with the specific, unglamorous questions below. In my experience, most organizations pass the first few and stall somewhere in the middle. That's not a failing — it's just where the field's blind spot sits. The point of this checklist is to find your gaps while they're cheap to fix.

Work through these with your downtime committee. If you can't answer one crisply, that's your next tabletop.

1. Do we know exactly when to activate downtime procedures — and who calls it?

Not "leadership decides." A named role, a threshold, and a communication tree that works when email is down. Ambiguity here costs you the first hour, and the first hour matters most.

2. Can our clinicians actually find and use downtime flowsheet forms?

Paper forms that mirror your EHR flowsheets, current with your build, printed or reachable offline, and familiar because staff have seen them before. Outdated forms from five years ago are forms no one knows how to use.

3. What's our MRN and encounter strategy in downtime mode?

How you assign identifiers on paper, how downtime CSNs get created, and — critically — how those map back to real encounters later. Get this wrong and you poison the backfill before it starts.

4. Do we have a census reconciliation plan for the moment Epic returns?

During an extended outage, ADT drifts from reality. When you cut back over, your system's view of who's in which bed can be days stale. Reconciling that is the foundation everything else in recovery stands on. If your plan doesn't name how you'll rebuild an accurate census, it isn't a recovery plan yet.

5. Have we separated Tier 1 from Tier 2 backfill — on paper, before the incident?

Tier 1 is the first day back: the narrow set of access, reporting, billing, and clinical restoration that makes users functional. Tier 2 is the 7–8 week marathon of full clinical re-documentation and revenue recovery. Teams that treat these as one task consistently under-resource the second.

6. Do we know which PRD batch jobs to disable before cutover?

There are dozens that can misfire during recovery — advancing ADT incorrectly, dropping charges, sending erroneous patient notifications, mis-coding encounters. Knowing the list before you need it is the difference between a clean cutover and a mess you spend weeks unwinding.

7. Who backfills the clinical documentation, and when do they do it on top of their day jobs?

This is the question that quietly breaks recovery timelines. Re-documenting days of care is enormous, and it lands on clinicians already back to a full census. Name the staffing model now.

8. What's our revenue cycle recovery sequence?

Charges generated on paper have to be captured, reconciled, and dropped correctly — including for patients who were discharged during the outage. Revenue leaks in recovery are slow, silent, and large.

9. How do we handle patients discharged during downtime?

They're gone from the building but not from your obligations — documentation, charges, and continuity all still have to be reconciled for them, and they're easy to lose track of precisely because they've left.

10. What requires our Epic Technical Coordinator, and have we pre-briefed them?

Re-enabling VPN, Care Everywhere certificate handling, and a number of other recovery actions are TC-side. If the first time your TC hears your recovery plan is during the incident, you've already lost time.

11. When did we last run a recovery tabletop — not a downtime drill?

Downtime drills rehearse going down. Recovery tabletops rehearse coming back up: census, backfill, batch jobs, staffing. Almost everyone does the first. Almost no one does the second. Guess which phase actually breaks people.

12. If the outage started today, could we hand a new incident commander a document that runs the recovery for them?

The real test. Not whether you know what to do — whether your plan does, when the person holding it is tired, improvising, and it's 3am on day four.

Where most plans land

If you answered 1–3 confidently and slowed down after that, you're in the majority — and it maps almost exactly to the field's blind spot: strong on operating during downtime, thin on preparing to recover. That's the gap that turns a two-day outage into a two-month operational drag.

The fixes aren't exotic. They're the unglamorous readiness work — current downtime forms, a written backfill sequence, a named staffing model, a rehearsed census reconciliation — done before you need them instead of invented under stress.

That readiness work is exactly why I built Lumenly Health, and why the free tier generates downtime flowsheet forms from your own Epic configuration: so that even if we never speak, you can close question #2 this week. If the rest of this list gave you a short to-do, that's the whole point.