What another hospital needs from an AI incident report

Imagine a hospital discovering that an AI-assisted appointment letter names the wrong building. The outpatient service moved, but an older directory still appeared among the material available to the application. A colleague catches the mistake before the letter leaves. Another hospital uses a different supplier but also draws on several location directories. What would help its team decide whether this warning matters locally?

This example is fictional. The useful thing to exchange would be an account detailed enough to examine the possible failure: which information was available, what the application produced, where someone noticed the discrepancy and what remains unexplained. Sending the original letter would introduce a separate question about patient information. Sharing only “AI gave the wrong address” would leave the receiving team with little to investigate.

Start with the decision another organisation faces

A June 2026 Stanford conversation with DJ Patil, Matthew Lungren and Justin Norden about AI in healthcare prompted this question for me: how can experience become useful beyond the organisation that acquired it? [1]

As a physician and founder developing AI for clinical work, I see a practical reason to make that question precise. A supplier needs enough information to examine a problem, while a hospital needs to understand whether the same conditions exist in its own work. An external report should let both parties state what they know, what they suspect and what they will examine next.

The proposal below concerns this exchange. It has not been evaluated as a complete safety programme. Immediate local protection, investigation and any applicable reporting duties require their established channels; preparing a shareable account should never delay them.

Keep the number of reports in its proper place

WHO’s 2020 guidance cautions that differences in report totals can reflect differences in reporting. It also separates understanding an event from demonstrating that subsequent action reduces risk. This is guidance on patient safety, with no evaluation of the AI-specific proposal here. [2]

Suppose, again hypothetically, one hospital records twelve AI-related concerns and another records three. The first may use AI more often, seek concerns more actively or make reporting easier. The second may have fewer problems or recognise fewer of them. The totals alone leave these explanations unresolved. A league table would force an answer the data cannot supply.

Adding the number of uses improves the description, but the reporting process still matters. Dividing twelve reports by ten thousand uses produces a report-to-use ratio. Without knowing how concerns were detected and selected, calling that ratio an error rate would overstate its meaning. Near misses caught before use should also remain distinguishable from events with observed consequences.

FDA makes the measurement limit explicit for its US medical-device reporting database: incomplete reporting and missing use information prevent incidence estimates from that system alone; a report also does not establish causation. Those cautions provide no statement of German reporting requirements. [3]

Describe a failure that someone can investigate

For the fictional letter, I would prepare a short learning account around the receiving team’s questions. What task was the application meant to perform? Which directory versions could it access? Did the wrong location appear in the generated draft or enter during a later edit? How was the discrepancy found? What had happened by that point?

These questions prevent a convenient explanation from becoming a settled cause. The older directory may be relevant, but its presence alone does not establish which material produced the address. If the relevant record is unavailable, the account should say so. “The output used an obsolete address; the precise retrieval path remains unconfirmed” gives another team a more usable starting point than an unsupported diagnosis of the model.

OECD’s February 2025 framework describes information for interoperable AI-incident reporting, including the system, harm and supporting material. It distinguishes harms from hazards and does not prescribe corrective procedures. This reporting framework establishes no clinical effectiveness. [4]

My proposed learning account would add a practical transfer question: under which conditions could a comparable failure arise elsewhere? For this example, the relevant combination is multiple available directories, inconsistent validity dates and an output whose address appears authoritative. Another organisation can examine that combination even when its software and supplier differ.

Share the mechanism at an appropriate level of detail

I would keep the material required for the authorised local investigation separate from the account approved for wider learning. The first may need original records and restricted technical detail. The second should include only information justified by its purpose and approved for its recipients. Removing names alone does not settle whether a distinctive case or technical detail can safely be shared.

For the appointment example, a constructed letter with invented names and locations could demonstrate the conflict between a current directory and a retained older copy. It must be labelled as a reconstruction. Any simplification that might change the explanation belongs beside it. This lets the receiving team inspect the mechanism without assuming that it has received the original evidence.

Patient safety, data protection and information security colleagues should agree the appropriate route and audience for the particular material. A restricted supplier investigation, a professional learning group and a public article can require different information. A public summary should remain candid about withheld detail and unresolved questions. Confidentiality should be handled explicitly, with no promise that an attractive template makes disclosure lawful.

Give the receiving hospital a concrete next step

The second hospital first examines applicability. Does its system also retrieve location information from several sources? Who determines which directory is current? Is the address selected automatically, copied into a draft or changed by a member of staff? An account of these differences can justify a narrower or broader local investigation.

If the condition appears relevant, the responsible team can examine it with synthetic or otherwise authorised cases in an appropriate test setting. The question is specific: when conflicting directory versions are available, what reaches the appointment letter? The required evidence and any decision about continued use belong to the local responsible functions. A reassuring result on a few constructed cases would leave the frequency and clinical consequences in ordinary use unresolved.

I would ask the recipient to return a brief response: relevant conditions found, conditions absent with reasons, or insufficient information to decide. Where action follows, record what was changed and how its effect was examined. This creates an exchange that can improve the original account. For example, the second hospital might discover that validity dates existed but were invisible at the point of review.

Keep the account open to correction

Give the shared account a stable identifier, a responsible contact and dated revisions. If several people report the same event, link those accounts while preserving any meaningful disagreement. If later investigation changes the proposed explanation, notify earlier recipients. A new version should show which finding changed and which earlier recommendation may therefore need reconsideration.

For leadership, I would review whether important reports reached the right teams, whether applicability was examined and whether proposed changes received an appropriate follow-up. These are observations about the learning process. Claims about fewer harms need separate outcome evidence and a defensible comparison.

The value of this exchange lies in helping another organisation ask a better, testable question about its own work. A candid account can carry that value while its cause is still uncertain. It needs enough context to make investigation possible, enough restraint to protect people and enough continuity for a correction to reach those who relied on the first version.