At 09:10, a fictional outpatient clinic loses access to its AI assistant. One clinician has a consultation underway. Another has reviewed a draft but cannot tell whether it reached the record. A third expects a generated letter that has not appeared.
The clinical record itself is still available. Appointments continue. The immediate challenge is therefore not simply a technical outage: it is knowing which work must continue manually and which apparently completed tasks remain uncertain.
This scenario is invented for planning purposes. It is not an account of an incident involving Tandem or another supplier. It turns a question raised by sovereign healthcare AI into something concrete: what independence does the clinic retain when its normal assistance stops?
Identify the failure before choosing the workaround
"The AI is down" can describe several different situations. The model may be unavailable while the application remains accessible. The clinic may have lost its internet connection. Authentication may have failed. The record integration may be unavailable even though drafting still works.
Those failures create different options. Retrying a model request will not repair a local network outage. Switching to another online assistant will not necessarily solve a shared login problem. Continuing to generate documents is not enough when nobody can confirm their transfer.
The first operational message should identify what is known, what remains available and what staff should stop doing. It should not announce a recovery time that the organisation has no basis to promise.
A named incident lead can coordinate updates while clinicians concentrate on the patients and tasks in front of them.
Map the work that depends on the service
A clinic may think it uses AI only for notes, then discover during an outage that staff also rely on it for letters, coding suggestions, visit summaries or finding information.
Create a dependency map before the interruption. For each task, identify the normal input, expected output, place where completion is recorded and approved alternative.
| Task in the fictional clinic | Immediate continuity question | What must remain visible |
|---|---|---|
| Consultation documentation | Can the clinician write directly in the record? | The actual assessment and agreed plan |
| Pending generated letter | Must it be prepared manually now? | Who owns it and when it is needed |
| Reviewed note awaiting transfer | Did the record receive the approved version? | Confirmed versus uncertain filing status |
| Suggested clinical code | Can coding proceed through the usual record workflow? | The evidence and authorisation for the code |
| Clinical information lookup | Which approved sources remain accessible? | The question, source and limits of the answer |
| Patient communication | Has anything already been sent? | Recipient, content and confirmed transmission |
This table is an original service-planning example. It does not assert that every AI product performs all six functions.
Keep the consultation moving without creating shadow records
In the opening scenario, staff can continue documenting in the available clinical record. The substitute should capture the necessary clinical information, not reproduce every stylistic feature of the generated note.
The organisation should specify an approved alternative when the record is also unavailable. Staff should not have to invent a personal-device recording process or send patient information to an unapproved application under pressure.
NHS guidance for health and care professionals using ambient scribes places use within organisational arrangements. An outage does not turn an unrelated personal account into an approved clinical system.
Explain the interruption to the patient when it affects the encounter. A straightforward statement that the clinician will document in the usual record is more useful than a speculative account of the supplier's technical problem.
Local capture is not the same as offline clinical operation
A product might retain an input locally while waiting for a connection. That does not establish that it can transcribe, generate, review and file a complete output without the remote service.
Ask which stages work during each relevant failure. Does capture continue? Where is the information held? Can the clinician inspect it? What happens if the device closes before reconnection?
These are questions for the actual deployment, not capabilities to infer from the words "local", "sovereign" or "on device".
The NCSC's shared-responsibility account of cloud services is a useful reminder that responsibilities vary with the service arrangement. Neither a European supplier nor a managed cloud removes the need to understand the customer's operational dependencies.
Treat uncertain completion as a separate state
The second clinician in the fictional clinic has reviewed a note, but the transfer confirmation is missing. Two possibilities remain: the transfer failed, or it succeeded and the acknowledgement was lost.
Blindly submitting again risks duplication. Assuming success risks leaving the encounter undocumented.
The approved recovery process should inspect the receiving record and reconcile the expected version with what is present. Where the status cannot be established immediately, allocate the unresolved task rather than allowing it to disappear from the list.
This principle extends beyond notes. A letter generated, a letter sent and a letter received are different events. Their status should not be inferred from the last reassuring sentence shown by an assistant.
Recovery creates work of its own
When the service returns, the clinic may have a mixture of manual records, queued requests and newly generated outputs referring to encounters already completed.
Do not import everything automatically. Reconcile the queue against the work done during the interruption. Confirm whether a draft is still needed, whether its content reflects the latest plan and whether an action has already occurred elsewhere.
Assign an owner and deadline to each remaining task. A service being technically available again does not mean the clinical backlog has been resolved.
Also consider the information held during the outage. The relevant retention, access and incident arrangements still apply. Recovery should not create unnecessary copies in emails or support tickets simply because troubleshooting is easier that way.
Run a short exercise before relying on the plan
NHS England publishes an information and information-systems disruption exercise resource. A clinic can also conduct the following original, bounded tabletop exercise using fictional material.
Spend the opening five minutes identifying an interrupted encounter and the functions still available. Use the next five to allocate pending drafts and uncertain transfers. Introduce recovery, including a duplicated item and a changed plan, during the next five. Close by identifying the unresolved ownership or access problem that the exercise exposed.
These timings describe a proposed twenty-minute team exercise, not a requirement or a claim about how quickly an actual service should recover.
Include administrative staff and technical support, not only the clinicians who usually open the AI interface. An apparently simple clinical workaround may depend on a task another team performs.
Distinguish a second supplier from genuine resilience
A second online service can provide useful redundancy for some failures. It can also share the same internet connection, device, identity provider or underlying model service.
The relevant question is which failure the alternative addresses. Buying two applications does not demonstrate independence if both rely on the component that has stopped working.
The same caution applies to clinical knowledge. Ask-iatroX may provide a separate reference route for an appropriate general question, but it is not an offline replacement for a record system or a guarantee against every shared infrastructure failure.
Maintained clinical understanding, access to suitable sources and a workable documentation process remain different parts of continuity. The organisation should know which it can rely on under each scenario.
Measure readiness by whether staff can recover the work
A continuity plan is useful when another authorised colleague can identify what happened, what remains open and what to do next. A policy stored where nobody can access it during an outage offers little practical reassurance.
Review the plan when dependencies or functions change. The model-change guide addresses that maintenance question; the exit-planning guide addresses a longer interruption in the supplier relationship.
Sovereignty becomes operationally meaningful when it leaves the clinic with choices it can actually exercise. Continuing care and recovering unfinished work are stronger tests than the presence of an independence claim on a product page.
Frequently asked questions
Does European-owned hosting mean the service works without the internet?
No. Ownership and offline operation are different properties. Ask which components remain available during a particular network, model or application failure.
Should staff immediately resend everything that lacked a success message?
No. Some actions may have succeeded without confirmation. Reconcile the receiving system's state before repeating an action that could create duplicate records or communication.
Is another online AI tool an adequate business-continuity plan?
Not by itself. Its permissions, dependencies, available functions and information-handling arrangements must fit the failure being addressed and the work that needs to continue.
Prepare the supplier questions that expose continuity dependencies