A patient with weeks of unexplained itching asks a large language model about their symptoms. It suggests chronic urticaria, mentions histamine pathways, recommends an antihistamine, and counsels on when to see a doctor. The patient takes the antihistamine. The itching improves.
Did the AI diagnose anything?
No. And that gap is the whole point of this post.
One number is hiding three different questions
When we evaluate medical AI — or doctors, for that matter — we tend to collapse everything into a single notion of "being right." But clinical reality runs on three separate questions that are constantly confused for each other:
- Actionability — Can we make a defensible next decision? (Treat, test, watch, or refer.)
- Response — Did the intervention actually help?
- Etiology — Have we established why the patient is sick?
These are independent. Wildly independent. A treatment can be completely justified without knowing the cause (medicine has done this forever — it's called empiric therapy). A patient can improve dramatically while the underlying cause stays unknown. And an AI can produce a correct-seeming diagnosis while silently treating missing data as negative data — a completely different failure.
I've been developing a framework that forces these three outcomes apart. I call it ARE — Actionability, Response, Etiology. The one rule that makes it work: these three must be measured and reported separately, always. No composite score.
If you're a developer, you already know why. A single number that blends "unit tests pass rate," "p95 latency," and "user satisfaction" would tell you nothing about any of them. Medicine has the same problem, except the composite scores have had a couple of centuries to fossilize into how we talk about "diagnosis and treatment."
The histamine fallacy
Here's the example I keep coming back to. A patient's itching improves after an antihistamine. Consider four claims:
- "The itching improved after treatment." ✅ Directly observed.
- "The response is compatible with histamine involvement." ⚠️ An inference, supported but not proven.
- "The patient has a specific histamine-mediated disorder." ❌ Not established.
- "We found the cause." ❌ Not even close.
Only the first claim is actually known. But in practice — and in current AI outputs — these four slide into each other constantly. The fluency of a well-written answer makes the slide feel seamless.
This isn't a hypothetical concern for AI specifically: in chronic urticaria, whether a patient responds to omalizumab is associated with their underlying pathophysiological subtype, but a response doesn't prove the subtype, and plenty of patients improve for reasons we still can't fully explain. Response is evidence. It is never proof. In Bayesian terms: response updates the odds, it doesn't replace the evidence standard.
The bug that most medical AI silently ships with: "missing" ≠ "negative"
Ask any backend engineer about the difference between null, false, and "field doesn't exist." Medicine has exactly the same problem, except the field names are things like "medication allergy." These are three different states:
- "No medication allergy reported." — nothing was collected.
- "Medication allergy explicitly denied." — someone asked, the answer was no.
- "Medication allergy not assessed." — nobody asked.
An AI system (or a tired human) that reads the third state as the first or second has invented a patient fact out of thin air. My framework makes this a hard rule: absence of evidence must never be silently converted into evidence of absence. Every piece of patient information carries an explicit assertion state — present, denied, never asked, can't recall, withheld, inaccessible, contradictory, or AI-inferred — and no component of the system is allowed to map one state onto another.
Nice detail for the devs here: this doesn't have to be invented from scratch. The FHIR standard already defines data-absent-reason — a standard vocabulary for why expected clinical content is missing (never asked, declined, unknown, unavailable). The framework just extends it with two states health data has been avoiding: contradictory (patient says two different things) and AI-inferred (the model generated it, nobody verified it).
That second one matters more than it sounds. AI-generated content should never be presented in the same channel as verified patient facts. I call provenance violations what they are: a defect class, with a measurable rate — like a data-integrity bug, but the integrity is clinical.
What an AI system under this framework actually does
Not "make diagnoses." Closer to a very disciplined evidence organizer:
| Stage | What happens |
|---|---|
| 1. Data integrity audit | Flag missing, stale, contradictory, and unverified information — before any reasoning |
| 2. Hypothesis generation | Differential diagnosis with supporting and opposing evidence for each candidate |
| 3. Actionability assessment | Is there a safe next step — treatment, testing, watchful waiting, or referral — given what's actually known? |
| 4. Response evaluation | Measure what changed: magnitude, onset, duration, reproducibility, specificity |
| 5. Etiological reassessment | Update causal hypotheses with new evidence — without letting improvement count as proof |
And crucially, every conclusion carries one of four epistemic labels: observed, supported inference, unresolved hypothesis, or unsupported. A model that hides which bucket it's speaking from isn't calibrated — it's just confident.
Abstention is a feature
The most underrated safety capability in medical AI is the ability to say:
- "The available data are insufficient."
- "This case is outside my validated scope."
- "This symptom pattern requires urgent human assessment — now."
The current incentive gradient in AI products pushes the opposite way: always answer, always sound helpful. But in the domains where being wrong is expensive, knowing when to shut up is a measurable, testable skill — selective prediction, risk–coverage curves, abstention rates at matched coverage. The framework treats a well-calibrated "I don't know, and here's what information would change that" as a positive score on the scoreboard, not a failed query.
Wait — how do you know any of this works?
Honest answer: currently, it's a proposed framework, not a validated standard. It builds on existing reporting guidelines for AI in medicine (DECIDE-AI, CONSORT-AI, PROBAST+AI, TRIPOD+AI) — it doesn't replace them. What it adds is the thing they presuppose but never define: a three-axis outcome taxonomy, an adjudicated "etiologically unresolved" outcome category, and a missing-data taxonomy wired into the evaluation itself.
The next step is a prospective, multicenter evaluation I've designed a protocol for: real patients (chronic urticaria — perfect test bed, since it has validated response scores, an international diagnostic guideline, and a famously stubborn unresolved fraction), the same incomplete case snapshots assessed by a physician alone, an AI alone, and a physician-with-AI — all three scored independently against a blinded panel, across the three outcome axes, with no composite score anywhere.
Preregistered hypotheses, calibration metrics reported separately from discrimination, unresolved cases reported as a first-class outcome instead of being quietly dropped from the denominator. You know — the stuff you'd demand from any benchmark you were asked to trust.
The one-sentence version
Clinical actionability, therapeutic response, and etiological certainty are three different dimensions of medical knowledge — and the goal isn't certainty before every decision; it's never mistaking a working treatment for a discovered cause.
If you build LLM products that touch health data, the cheapest improvement available today might be this: stop letting "missing" masquerade as "negative," stop blending inference with observation, and give your users the abstention option. That's a subset of the framework you could ship this quarter.
Feedback on the formal specification and the study protocol is genuinely welcome — that's a large part of why I'm posting this here.
Author :Seyed Alireza Alhosseini Almodarresieh
mysite :https://almodarresieh.github.io/
