When the ED AI Goes Dark: Build the Downtime Drill Before Go-Live

At 02:17 on a night shift, the triage workstation stops showing the risk score the department has been using for six months. The vendor status page says “investigating.” The waiting room is full. A patient with vague weakness is next in line, and the charge nurse is asking whether the usual escalation path still applies.

That moment is not an IT problem. It is a clinical transition. The team has moved from assisted work to unaided work, whether anyone declared the change or not. If the department has no tested fallback, the tool can keep shaping decisions even while it is unavailable: people wait for a result, assume a missing result is reassuring, or copy yesterday’s output into today’s chart.

An ED that uses AI needs a downtime drill before it needs another feature. The drill should answer five questions: How do we know the tool is not trustworthy right now? What do we do instead? Who can override it? How do we repair the record when service returns? Can the team do all four under pressure?

Treat AI as a clinical dependency, not a feature

Health systems already know that an electronic health record outage can disrupt care. AHRQ’s contingency-planning work describes downtime as a patient-safety hazard and focuses on strategies that keep care moving when the record is unavailable (AHRQ, Evidence-based Contingency Planning for Electronic Health Record Downtime). A review of patient-safety reports found that downtime can interfere with ordering, medication processes, imaging, and documentation (JAMIA analysis of EHR downtime safety events).

FDA guidance is useful here. Software that supports clinician decisions should be designed so the health professional can independently review the basis for the recommendation and not rely on the software as a substitute for judgment (FDA, Clinical Decision Support Software guidance). That principle applies during normal service and during a partial outage. A safe fallback is not “wait until the score comes back.” It is a known way to make the decision without it.

Test 1: Can the team recognize the failure?

Start with a named owner for each tool. The owner does not need to be the person who fixes the vendor’s servers. The owner needs authority to declare the tool unavailable for clinical use, notify the charge nurse and attending, and start the fallback. For a triage tool, that may be the ED medical director and charge nurse. For an ambient scribe, it may be the physician lead and health-information team. For a prediction embedded in the EHR, it may be the clinical informatics lead with an ED physician as the operational partner.

Write the trigger in language a busy clinician can act on. “Vendor investigating” is a trigger. So is a missing timestamp, a queue that has not refreshed, a mismatch between the tool’s input and the current chart, or an output that conflicts with a critical bedside finding. The trigger should name the next action: stop using the output, tell the clinical lead, and switch to the fallback.

Test 2: Does care continue without the output?

Build one fallback for each clinical use case. Do not write one broad sentence that says “use clinical judgment.” That is true and not enough.

For an acuity or triage model, define the manual triage process, the reassessment interval, and the escalation route. For an AI-generated handoff, use a direct clinician-to-clinician handoff and the department’s standard handoff fields. For documentation assistance, return to the normal note workflow and make the responsible clinician clear. For a disposition aid, require the physician to review the same risk factors and uncertainty that would have been reviewed without the tool. The fallback should fit on a page and be usable without a network connection if the outage reaches the EHR or identity service.

State what not to do. Do not reuse an old score as if it were current. Do not let a missing alert become a negative finding. Do not paste a draft into the legal medical record without the normal review. Those rules are small, but they close the shortcuts people take when the department is busy.

Test 3: Can the clinician see the basis and override it?

A tool that cannot show where its recommendation came from is difficult to use safely. The clinician needs enough information to check the inputs, understand the intended use, identify the time of the output, and decide whether the result fits this patient. The FDA’s guidance centers independent review of the basis for clinical decision support, and the ONC’s HTI-1 rule added transparency requirements for predictive decision support in certified health IT (ONC, HTI-1 Final Rule).

Make the override path explicit. The attending can reject the output. The charge nurse can stop a triage recommendation from controlling the queue. The physician documenting an encounter can delete or correct a generated sentence. The person who overrides the tool should not have to hunt for permission in a policy folder.

Test 4: Can you reconcile the record after recovery?

Assign a reconciliation owner before the drill. The owner checks the outage window, identifies patients touched during that window, confirms which inputs and outputs were lost or delayed, and makes sure the final note states what was actually reviewed. If the tool drafts documentation, compare the draft with the signed note. If it produces a queue or alert, compare the patient list with the manual process used during the outage. If it feeds a handoff, confirm that the receiving team received the human handoff rather than assuming a later-generated summary repaired the gap.

NIST’s 2024 Generative AI Profile gives organizations a risk-management structure that includes identifying, measuring, and managing risks across the system’s life cycle (NIST AI 600-1, Generative Artificial Intelligence Profile). For an ED, the downtime log is part of that evidence. It tells you what the system did under stress, what the team did without it, and which control needs work.

Test 5: Does the drill change behavior?

A policy is not a fallback until the team can use it at 02:17. Run a short, announced simulation. Pick one tool. Tell the team that its output is unavailable. Start the clock. Watch who notices, who declares the outage, who tells the attending, and whether the manual process starts without a meeting.

Simulation is a natural place to connect this work to EM-Sim, especially when an ED is training residents and staff to recognize automation bias, make an override, and hand off during degraded operations. The objective is not to make clinicians distrust every tool. It is to make trust conditional on current inputs, visible limits, and a working alternative.

Dr. Chet's Take

I have spent 25 years in emergency medicine, and I have watched technology fail in every setting where people depend on it. HEMS taught me to ask what happens when the radio goes quiet. The National Guard taught me to name the alternate plan before the primary plan breaks. An ED AI tool deserves the same treatment. If it influences a triage decision, a handoff, or a disposition, it is part of the operational system. The question is not whether the vendor has an uptime page. The question is whether my team can recognize a bad output and keep caring for the patient.

That being said, I do not want another binder that nobody opens. I want a short trigger, a clear owner, a manual fallback, and a reconciliation step that we practice. I want the attending to be able to say, “Stop. We are working without this tool,” without asking permission from three committees. If you are leading an emergency department, pick the one AI tool that would create the most confusion during an outage. Run the drill this month. Fix the first point where the team hesitates. Safe AI is not a promise from a vendor. It is a practiced clinical response.

Key Takeaways

• Treat an AI outage as a clinical transition, not only a technical incident.
• Name one person who can stop use of the tool and start the fallback on every shift.
• Write a use-case-specific fallback for triage, handoff, documentation, and disposition.
• Make the override path visible and record the reason in language the team can review.
• Reconcile the patient list, inputs, outputs, and signed record after service returns.
• Drill the process with the real team, then fix the first hesitation you observe.

FAQ

What should an emergency department do when an AI clinical tool goes down?

Declare the tool unavailable for clinical use, notify the operational owner, and start the written fallback for that use case. Do not reuse stale outputs or treat a missing alert as a reassuring result. The fallback should keep care moving while preserving a clear record of what clinicians reviewed.

How often should an ED practice an AI downtime drill?

Practice after the first deployment and after any major workflow, vendor, or model change. Repeat the drill when an outage, near miss, or debrief shows that the fallback is unclear. EHR downtime readiness work supports treating continuity as an ongoing process, not a one-time document (EHR downtime readiness process).

Should clinicians trust AI-generated handoff notes?

They should treat them as drafts that require clinical review, not as the source of truth. A 2024 study evaluated large-language-model-generated emergency medicine handoff notes, but the attending and receiving clinician still own the accuracy, context, and transfer of responsibility (JAMA Network Open handoff-note study). A direct human handoff remains the fallback when the generator is unavailable.

If you're an emergency physician (or any clinician treating patients daily) trying to understand how AI will actually impact your clinical practice — not just the hype — I put together a free practical guide. You can download it here: AI in EM Survival Guide.

Sources

• Agency for Healthcare Research and Quality. Evidence-based Contingency Planning for Electronic Health Record Downtime
• PubMed. Implications of electronic health record downtime: an analysis of patient safety event reports
• U.S. Food and Drug Administration. Clinical Decision Support Software: Guidance for Industry and Food and Drug Administration Staff
• Office of the National Coordinator for Health Information Technology. Hospital Trends in the Use, Evaluation, and Governance of Predictive AI (Data Brief 80)
• Office of the National Coordinator for Health Information Technology. HTI-1 Final Rule
• PubMed. Electronic health record downtime responses: One health system’s process for ongoing readiness
• JAMA Network Open. Developing and Evaluating Large Language Model-Generated Emergency Medicine Handoff Notes
• National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
• Shermer C. How Running a Telehealth Network Prepared Me for the AI Integration Challenge
• Related simulation training: EM-Sim
• Books by Dr. Shermer