You Don’t Need a New Taxonomy for Clinical AI Failure

AI can fail technically in genuinely new ways. But when those failures reach patient care, they usually become very familiar clinical failures. That distinction matters if we want to measure whether AI is actually making care safer.

By Paulius Mui, MD

Consider a 58-year-old patient with three weeks of rectal bleeding.

The underlying technologies are very different. The clinical failure is identical.

That is the basic argument of this piece. We should not build one vocabulary for measuring errors made by clinicians and another for measuring errors made by AI. We should measure both against the same clinical standard, then separately record what role the AI played and why it failed.

In practice, that means separating three questions that are often collapsed into one:

Those are three different layers of information. Treating them as one is making clinical AI evaluation much harder than it needs to be.

Start with what happened to the care

Medicine already has a mature way of reviewing decision-makers.

When we review a physician’s care, we generally don’t begin by classifying the physician’s internal cognitive process. We begin with the observable care.

• Was an indicated test ordered
• Was an abnormal result followed up
• Was a medication appropriate for the patient’s kidney function
• Was an uncontrolled chronic condition addressed
• Was the patient given an appropriate follow-up plan

Peer review, chart audit, quality improvement, and morbidity and mortality review all work this way. The useful unit of analysis is not what happened inside the decision-maker. It is what happened in the care.

Then AI enters the workflow and we often reverse the order. We start with hallucination. Prompt sensitivity. Insufficient context. Retrieval failure. Automation bias. Drift. Poor reasoning.

Those concepts are useful. But they answer a different question. They tell us something about why a system behaved the way it did. They do not tell us what clinical failure resulted.

A patient does not experience insufficient context. A patient experiences a workup that didn’t happen.

The same error should have the same name

Suppose we define a clinical code: DX-1 — Missed indicated workup. A symptom, sign, or risk finding warranted diagnostic evaluation that was not performed.

Now consider three cases.

There are important differences among these cases. But the underlying clinical gap is the same, and that common denominator is enormously useful. Now an organization can ask:

• How frequently do clinicians miss indicated workups?
• How frequently does the AI miss those same gaps?
• Which clinical failures does AI catch reliably, and which does it rarely recognize?
• Where is the model correct but the workflow fails to change care?
• Does deploying the tool actually reduce DX-1 events over time?

You cannot answer those questions if clinicians are measured in clinical language while AI is measured in engineering language. A hallucination rate cannot be compared with a diagnostic-error rate. A missed-workup rate can.

There are really three axes

A useful clinical AI review system should separate three layers.

1. Clinical failure: what went wrong?

This should be the primary code. For example:

Notice what these codes have in common. They describe things that somebody responsible for care can actually fix. “Diagnostic error” is too broad. “Poor reasoning” is too causal. “Missed indicated workup” tells you what happened.

2. AI involvement: what did the tool do?

Once the clinical issue has been identified independently, ask what role the AI played. For a real care gap, the possibilities are straightforward:

This distinction prevents a common category error.

Imagine an AI system correctly identifies that a patient taking methotrexate has not had appropriate laboratory monitoring. The recommendation appears in an inbox nobody routinely checks. The patient receives no monitoring. Calling this a “model failure” sends the engineering team off to improve a model that was already correct. The failure lives in workflow.

Now take the opposite case. The AI incorrectly recommends a contraindicated drug, the clinician follows the recommendation, and the prescription reaches the patient. The resulting clinical code might be MED-1: drug–disease contraindication, and AI attribution tells us the tool contributed to it. Those two pieces of information together are much more actionable than labeling both cases “AI safety events.”

3. Mechanism: why did it happen?

Only now do the familiar AI failure categories enter. Perhaps the model lacked medication history. Perhaps retrieval returned the wrong encounter. Perhaps the prompt caused it to overweight one fact. Perhaps the model generated an unsupported statement. Perhaps the interface truncated the relevant recommendation. Perhaps the clinician over-trusted the output.

These are valuable mechanism tags. They tell engineering, product, and implementation teams where to intervene. But they should sit on top of the clinical classification rather than replace it. The structure becomes:

That record tells three different teams three useful things. The clinical quality team knows what went wrong. The product team knows where AI entered the pathway. The engineering team knows why the system may have failed. That is much richer than “insufficient context.”

Why omissions make this especially important

AI safety discussions naturally gravitate toward bad outputs. A fabricated diagnosis. A dangerous recommendation. An incorrect dose. Those matter because there is something visible to inspect.

But some of the most important failures produce no output at all. A high-risk drug interaction the AI never mentions. A red-flag symptom it never connects to the indicated workup. A medication-monitoring gap it never surfaces. There may be no bad recommendation to audit because there was no recommendation.

That creates a measurement problem. If you only examine AI outputs, you can measure precision: when the system said something was wrong, how often was it right? You cannot measure coverage: of all the clinically important things it should have identified, how many did it find?

To calculate that denominator, somebody has to independently determine what should have been found. In other words, you need the clinical codebook first. The chart review defines the universe of care gaps. Then the AI can be compared against it.

The boring part is the important part

Building that clinical codebook is less glamorous than inventing a new vocabulary for AI. It is also much more useful.

A list of categories is not enough. A usable code needs:

• One fixable behavior. “Medication error” is a domain. “Missing required medication monitoring” is actionable.
• Explicit boundaries. If monitoring was never ordered, that might be MED-4. If it was ordered and the abnormal result was ignored, that is CRD-1.
• Routing rules. Similar cases should not be decided from scratch every time.
• Anchor cases. Definitions tell reviewers what a category means. Cases show them what it means at the boundary.

Consider two deceptively similar events.

The difference is one objective question: was the test ordered?

Again, one question resolves it: was there a triggering symptom or finding?

The reliability of a codebook is largely determined by these edges. The center of each category is easy. The boundaries are the instrument.

A working slice of ours

Here is what that looks like written out. Each code sits on an existing, published taxonomy rather than on our own judgment — DEER for diagnostic error, Choosing Wisely for overuse, Beers and STOPP/START for prescribing, NCC MERP for medication harm, USPSTF and HEDIS for prevention, ICD-10-CM for coding specificity. Very little is novel, and that is deliberate. Novelty is what makes a taxonomy incomparable.

Read it as a demonstration, not a census. No code set is a complete accounting of everything that can go wrong in a clinic, and any document claiming to be should worry you. What is worth copying is the shape of each entry: one fixable behavior, a definition someone else can apply, explicit routing to its neighbors, an anchor case that settles the edge.

What about AI errors that never reach the patient?

This is the important exception.

Suppose an AI system recommends stopping an essential medication, but the physician recognizes the mistake and ignores it. No clinical failure occurred. But clearly the AI failed, and that event should not disappear from safety monitoring simply because the clinician caught it.

The same clinical vocabulary still works. Code the potential clinical consequence, and separately record that the recommendation was intercepted.

This is familiar safety logic: near misses belong in a safety system even when harm was prevented. We don’t need an entirely different vocabulary to describe them.

What this lets us measure

Once humans and AI share a clinical axis, much more interesting questions become possible.

Imagine reviewing 10,000 encounters and independently identifying every qualifying clinical gap. You may discover that an AI system detects:

Those numbers would tell us something operationally important. The tool may be excellent at checklist-shaped omissions and much weaker at judgment-shaped omissions.

That is actionable. Maybe you deploy it aggressively for medication monitoring. Maybe you require additional human review for diagnostic reasoning. Maybe you redesign training around the categories in which clinicians and AI fail together.

And because the underlying categories are clinical, you can measure something even more important: did the rate of the care failure actually fall after the AI was introduced? That is a clinical outcome of deploying the technology.

“Hallucinations decreased 22%” may be an interesting model metric. “Unclosed abnormal-result loops decreased from 4.8% to 1.9%” is a quality metric. Healthcare ultimately needs the second one.

AI can fail in new ways. Patients generally cannot.

There is an obvious objection to this argument. Modern AI can fail through mechanisms that have no real human analogue: retrieval failures, context-window problems, model drift, prompt injection, tool-call errors, corrupted embeddings, stale data, or interface defects.

Absolutely. Engineering teams should classify those failures. The point is not that AI introduces no new technical failure modes. The point is that technical novelty does not require a new clinical outcome vocabulary.

A retrieval failure can lead to a contraindicated prescription. A context-window failure can lead to missed medication monitoring. A hallucination can lead to unnecessary testing. A workflow defect can lead to an abnormal result remaining unaddressed. The upstream causes may be novel, but not downstream failures.

That gives us a useful architecture:

Put the durable thing first. Let the rapidly changing technology live in the layers underneath it.

The payoff: one scoreboard

The most important advantage is not taxonomic elegance. It is that clinicians and AI can finally be put on the same scoreboard.

Not human diagnostic error rate versus AI hallucination rate. But this:

Of every indicated workup that should have happened, how many did the clinician miss, how many did the AI miss, and how many did the combination of the two ultimately close?

That is a question a chief medical officer can act on. It is a question a quality committee can monitor. It is a question a payer or malpractice carrier can understand. And eventually it is a question organizations can compare with one another.

That comparability disappears if every AI vendor invents a proprietary language for failure.

The takeaway

Clinical AI may fail technically in novel ways. But when those failures affect care, they usually enter pathways medicine already knows how to describe.

The workup wasn’t ordered. The abnormal result wasn’t chased. The drug was inappropriate. The monitoring never happened. The uncontrolled condition wasn’t addressed. The patient wasn’t brought back.

Start there.