Home / Insights
Healthcare AI Downtime Drills: Test the Manual Workflow Before You Need It
Learn how healthcare AI downtime drills test manual handovers, approved fallbacks, queue preservation and reconciliation without interrupting live patient care.
Healthcare AI Downtime Drills: Test the Manual Workflow Before You Need It By Eunoia Consulting Co. Editorial Team Approval status: Awaiting approval A healthcare organisation should be able to continue the limited, authorised work that an AI tool supports when that tool is unavailable, without improvising, losing the work queue, or quietly creating a second record of the same task. The practical way to find the gaps is a controlled downtime drill: rehearse the manual workflow, the handover, and the restoration checks before an outage creates pressure. Do not switch off a live AI tool during patient care. Start with a tabletop, then use a sandbox or synthetic data where authorised. The drill should prove the outage boundary, permitted fallback, work preservation, and reconciliation, not claim certification or universal compliance. Five takeaways Test the manual workflow and handover , not merely whether a technical failover screen appears. Treat an AI outage differently from an EHR outage . The information and safeguards available may be very different. Define the smallest authorised information set and fallback action for each affected task before the drill. Give named operational, technical, privacy, and clinical owners a role in the exercise, with clinical sign off where the workflow could affect care. Make reconciliation measurable: show what was queued, completed, deferred, duplicated, or missing before normal service resumes. First, define what is unavailable An AI tool can be unavailable while the EHR remains available. For example, a generative assistant that helps staff prepare a non clinical appointment follow up may be inaccessible even though staff can still view the authorised record in the EHR. The continuity question is then narrow: what manual action is allowed, what information may be used, and where is work recorded until the AI supported process is restored? An EHR outage is different. It can limit access to records, orders, results, documentation, and the systems that support communications. The ASTP/ONC SAFER Contingency Planning Guide is explicitly about planned or unplanned EHR unavailability and calls for continuity processes, clinician participation, staff training and testing, independent communications, and orderly interface recovery. [1] The AHRQ funded research report also describes disruption across laboratory work, medication administration, registration, hand offs, documentation, and other care processes during EHR downtime. [4] Do not collapse these scenarios into one drill. If the EHR is available, the fallback may use authorised EHR information and established queues. If it is unavailable, use separate EHR contingency arrangements. State the scope at the outset and do not assume a workaround for one outage is safe or permitted for the other. The continuity handover is the centre of the drill What work is permitted without AI? List tasks the tool supports and classify each fallback. A task may continue manually under a written procedure, be deferred, or be referred to the designated operational or clinical lead. The fallback is the action the organisation has approved for that workflow and risk tolerance, not simply the fastest route around a tool. For a patient access or administrative workflow, the permitted fallback might be a staff member completing an approved contact or routing step manually and recording the action in the designated system of record. A workflow that could affect clinical assessment, prioritisation, diagnosis, treatment, or medication should have explicit local clinical governance and sign off before any manual process is rehearsed or used. Do not treat an AI downtime drill as clinical direction. What is the minimum information set? Specify the smallest set of information a role needs to complete its permitted fallback. In a low risk administrative example, that could include a verified appointment request identifier, an authorised contact route, the service or administrative reason for follow up, the current status, and the staff member responsible. It does not mean copying a broad patient record into an ad hoc spreadsheet or personal notes. HHS describes contingency planning as backup, restoration, and continuation of critical business processes while protecting electronic protected health information. It also links controls to risk probability and criticality. [2] Identify where the minimum information sits, who may use it, how access is logged, and how temporary records are protected, transferred, or disposed of under local policy. Who owns each decision? A drill should identify a drill lead, the workflow owner, the technical or vendor contact, the information security and privacy contacts as relevant, and the clinical approver where patient facing work could affect care. Staff who carry out the work must have a practical route to ask whether a case is in scope for the fallback or should be deferred. NIST frames AI risk management through GOVERN, MAP, MEASURE, and MANAGE, with GOVERN as a cross cutting function. It emphasises documented roles, communication, training, accountability, and iterative management. [3] The named people should set the exercise limits and own the corrections. How will work be preserved and restored? Map the queue before starting. Note the task identifier, originating system, time received, current owner, status, and planned next action. During the drill, use one designated temporary record or queue rather than multiple informal lists. Decide how staff mark an item as completed, deferred, cancelled, or handed over. Capture enough information to locate the original item when the AI system returns. The restoration handover needs equal attention. Reconcile the temporary queue against the original queue and the system of record. Look specifically for duplicate work, missing tasks, mismatched status, work performed twice, and work that was started manually but not closed. Do not bulk import notes or mark a queue complete until the accountable owner has reviewed the reconciliation result under the organisation's approved process. A suggested four stage downtime drill Eunoia would typically design this as a proportionate, local exercise rather than a one size fits all programme. The four stages below are a starting structure for healthcare organisations to adapt through their authorised continuity governance. 1. Tabletop Walk the team through a short scenario: the AI tool is unavailable, the EHR is available, and an administrative queue is approaching a service target. Confirm the outage boundary, roles, communications route, permitted fallback, minimum information set, and stop conditions. Ask each role to describe their next action and who receives the handover. This stage should surface vague ownership and policy gaps without touching production data or live patient care. 2. Dry run Use a sandbox or synthetic dataset to run representative, low risk tasks through the temporary queue. Time handovers and observe information gaps or ambiguity. AHRQ funded work found that computer simulation can assess alternative EHR downtime plans without negatively affecting clinical operations. [4] Apply that principle to the AI workflow. 3. Reconciliation Restore the simulated normal workflow and perform the queue comparison. Evidence should show the number of items introduced, completed, deferred, handed over, duplicated, missing, and unresolved. Review representative entries for whether the correct minimum information was used and whether the system of record is coherent. A clean technical restoration is not enough if staff cannot demonstrate the fate of each item. 4. Review and improve Hold a short review while observations are fresh. Capture specific gaps such as a communications channel tied to the same sign in service, no transfer field in the manual queue, or unclear authority to defer. Assign an owner, due date, and acceptance evidence. HHS says measures and documentation must be reviewed and modified as needed, while NIST describes continuous, context specific risk management. [2] [3] A low risk hypothetical example Consider an AI tool that drafts a suggested, non clinical message for patients who have asked to reschedule an appointment. It does not triage symptoms, set clinical urgency, or make treatment decisions. In a sandbox drill, the patient access lead declares the tool unavailable. Staff move five synthetic requests to a designated temporary queue, use an approved template without AI, record only the permitted details, and route unusual requests to the existing operational process. The EHR remains available throughout. When the tool is restored in the sandbox, the lead compares the five temporary records to the original request list. One request was assigned twice, so it is marked as a duplicate and investigated. One was deferred because the approved template did not fit, so its handover is confirmed. The evidence is not that the team sent messages faster. It is that every synthetic request has an accountable status, no unauthorised information was used, and the manual procedure made the exception visible. FAQs How often should a healthcare organisation run an AI downtime drill? There is no universal statutory frequency for AI downtime drills. Set and document a proportionate cadence through local authorised governance, considering the workflow's risk, change rate, reliance on the tool, prior drill findings, and relevant organisational requirements. Re run a focused drill after a material workflow, integration, vendor, or policy change where it could alter the fallback or reconciliation process. Should a team disable an AI tool in production to test the fallback? Not as a default. Do not interrupt live patient care to create a test. Begin with a tabletop, then a sandbox or synthetic data dry run under authorised local continuity governance. Any production activity should be subject to the organisation's own approved change, safety, privacy, and operational controls. Is an AI downtime drill the same as EHR downtime planning? No. An AI downtime drill addresses the loss of an AI supported function while other systems may remain available. EHR downtime planning addresses broader loss of EHR access and the resulting continuity procedures. The scenarios can inform each other, but each should have its own scope, information assumptions, and authorised fallback. What good evidence looks like A useful drill pack is modest but complete: the authorised scenario and scope, participant roles, the fallback decision, training or briefing confirmation, timestamps for handovers, the temporary queue, the reconciliation result, issues found, and an improvement log with named owners. Keep the record proportionate to the workflow and protect it appropriately. The ONC SAFER guide recommends trained and tested downtime and recovery procedures, independent communications, and written processes that support safe care and critical operations. [1] It also cautions that its recommended practices are informational and do not guarantee legal compliance. [1] That is a helpful standard for the tone of the exercise: test, learn, document, and improve without overstating what the result proves. If you are defining AI continuity controls, Eunoia's AI governance services can help align the workflow, accountability, evidence, and improvement process to your operating context. For a discussion of your current controls, contact Eunoia. For the companion topic of preparing the wider response around an AI event, read Healthcare AI Incident Response Playbook. This article was produced by the Eunoia Consulting Co. Editorial Team. Eunoia Consulting Co. specialises in AI governance, healthcare operations, and data strategy for healthcare and veterinary organisations. References [1]: https://healthit.gov/wp content/uploads/2025/06/SAFER Guide 2. Contingency Planning Final.pdf "SAFER Guide: Contingency Planning" [2]: https://www.hhs.gov/hipaa/for professionals/security/laws regulations/index.html "Summary of the HIPAA Security Rule" [3]: https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100 1.pdf "Artificial Intelligence Risk Management Framework 1.0" [4]: https://digital.ahrq.gov/sites/default/files/docs/citation/r21hs024350 wernz final report 2018.pdf "Evidence Based Contingency Planning for Electronic Health Record Downtime"