Validating healthcare AI
Explainability in Medical AI: A Real Explanation vs a Reassuring Story
Explainable medical AI means a clinician can see the reasons behind a recommendation well enough to check them against the patient and decide whether to trust them, not merely receive a confident sentence that sounds right. A true explanation exposes what actually drove the output, so a clinician can catch the case where the tool latched onto the wrong thing.
Explainable medical AI means a clinician can see the reasons behind a recommendation well enough to check them against the patient and decide whether to trust them, not merely receive a confident sentence that sounds right. A true explanation exposes what actually drove the output, so a clinician can catch the case where the tool latched onto the wrong thing. A reassuring story is a fluent account, generated after the fact, that makes the output feel reasonable whether or not it had anything to do with how the answer was reached. Both read well on a screen. Only one protects the patient.
Here is a definition worth keeping. An explanation in clinical AI is faithful when it reflects the factors that genuinely moved the model's output, and useful when a clinician can act on it: confirm it, doubt it, or override it. Fluency is not faithfulness. A sentence can be perfectly clear and still be a polite fiction about why the machine said what it said.
What does "explainable" really mean for a clinical tool?
It means the clinician can answer one question without taking the answer on faith: why this patient, why now, why this recommendation. The test is not whether the tool produces words. It is whether those words let a trained person reconstruct the case for the suggestion and find the place where it might be wrong.
Medicine already has a working model of this. When a colleague proposes a plan, you do not want a lecture on their internal neurology. You want the load-bearing facts: this value, this history, this contraindication, weighed this way. A good explanation from a tool has the same shape, pointing at the specific things about this patient that drove the recommendation, in a form you can verify against the chart and your own read of the person. That rules a few things out. Explainability is not a page of model internals, and it is not a heat map for its own sake. A clinician with eight minutes needs the short, checkable reason, and needs to trust that the reason is real.
What is the difference between a true explanation and a reassuring story?
A true explanation is causally honest about the model. A reassuring story is rhetorically satisfying about the case. The gap between them is where a lot of clinical AI quietly fails.
Consider how some explanations are produced. The model reaches an output by one process, and a second process is then asked to describe why that output is reasonable. When those two are tightly coupled, the description is trustworthy. When they are loosely coupled, you can get a fluent, guideline-flavored paragraph that would have sounded just as convincing if the model had returned the opposite answer. The story tracks what a clinician expects to hear, not what the model actually did. That failure mode worries me most, because it fools careful people precisely when they are being careful. The danger is not that the story is wrong. It is that it is comforting, lowering your guard at the moment your guard is the only safeguard left. If the explanation would have fit any answer, it explained nothing while feeling like diligence.
How can you tell a faithful explanation from a fluent one?
Ask whether the explanation could have come out differently. A faithful reason changes when the inputs that mattered change. Alter the value the tool says it relied on, and the recommendation and its stated reason should both move. If you can perturb the supposed driver and the answer holds steady while the story stays the same, the story was decoration. That is the spirit behind serious interpretability work: not to make the model talk, but to check that what it says lines up with what actually shifts its output. There is a clinical version that needs no engineering. When the tool surfaces its reason, ask whether you could have reached a different decision with that same reason in front of you. If the explanation only ever licenses agreement, it is not informing your judgment. It is recruiting it.
Why does a clinician need to understand the reasoning at all?
Because the clinician, not the model, is answerable to the patient, and you cannot defend a decision whose basis you never saw. A recommendation a clinician cannot explain is one they cannot stand behind when a colleague, a family, or their own conscience asks why. Understanding the reasoning is what turns a suggestion into something a professional can own.
There is a sharper, safety-driven reason underneath that one. The cases where a model is most likely to be wrong are the unusual ones, the patients at the edge of what it learned from, and those are exactly where a faithful explanation earns its keep. It lets the clinician see that the tool is leaning on a feature that does not apply here, or ignoring the one detail that changes everything. An opaque correct answer and an opaque wrong answer look identical on the screen. The reasoning is how you tell them apart before it reaches the patient.
I held to this while building decision support. As Head of Medical and Science I co-developed EASY Diabetes, an AI clinical decision-support system for type 2 diabetes, and the rule was that the tool suggested and the clinician decided. A suggestion is only decidable if the clinician can see the grounds for it. The EASY-1 randomized controlled trial (NCT03258268) evaluated the tool against standard of care across multiple clinics. A trial like that is how you test whether the tool helps in the real world. The explanation is what lets an individual clinician know whether it is helping the patient in front of them today.
What does a useful explanation look like inside a real visit?
Short, specific, and tied to things the clinician can check without leaving the chart. The format that survives a busy schedule is roughly: this recommendation, because of this finding in this patient, weighed against this guideline. It names patient-specific factors rather than the generic top-line guidance the clinician already carries in their head, and it is honest about uncertainty. A well-built tool working outside what it was validated for, or from thin data, should say so and step back rather than manufacture a smooth reason for a shaky answer. A model that always has a confident explanation is more dangerous than one that knows where its competence ends.
This connects to how these tools are governed, not only how they feel. The frameworks I studied while earning training in medical device regulations, covering software as a medical device and AI and machine learning, keep returning to intended use and human oversight. An explanation is part of that oversight, because oversight that cannot inspect the reasoning is oversight in name only.
What should builders and buyers do about it?
Treat the explanation as a feature to be validated, not a label to be claimed. The honest question for any tool is not whether it produces explanations but whether those explanations are faithful, and that is something you can probe. Check that the stated reasons move when the inputs that supposedly drive them move. Check that the tool can say it does not know. Be wary of explanations that always flatter the output, because an account that fits every answer is a story, not a reason.
A common trap is to measure explainability by clinician satisfaction surveys, which reward fluency and comfort, the very things a reassuring story is best at. Comfort is not the goal. A good explanation should sometimes make a clinician uncomfortable, because it shows them a reason they want to argue with, and that argument is the human judgment doing its job. Plenty of thoughtful teams are working hard on this, and faithful explanation is genuinely difficult, so the point is not blame. It is that we should hold the word "explainable" to the standard a patient would want it held to.
This article is educational and is not medical advice. Decisions about your care should be made with your own clinician, who can weigh your full history.
So when a tool explains itself, do not ask only whether the explanation makes sense. Ask whether it is true to how the answer was reached, and whether you could have disagreed with it. A reassuring story makes you feel safe. A real explanation makes you able to keep the patient safe, which is the only kind worth building.
References and sources
How this was researched. This explainer is built from the primary sources listed above and reflects Dr. Tojjar's own critical appraisal of that evidence. It explains and evaluates research and does not provide medical care.
This article is for general education and is not medical or professional advice. For guidance about your own health, talk with a qualified clinician.
Cite this article
Tojjar, D. (2025). Explainability in Medical AI: A Real Explanation vs a Reassuring Story. Dr. Damon Tojjar. https://readingtheevidence.org/articles/explainability-in-medical-ai/
This article is part of Dr. Tojjar's guide to Validating healthcare AI.