Physician Explanations
Status: vision — a separate model, deliberately outside the pattern-recognition path.
When consensus fires, someone has to tell the physician — and a fired billing code is not a message. In the production design, a separate explanation model turns each consensus suggestion into a short physician-facing narrative, and it lives entirely outside the recognition path.
Why a separate model
The ensemble models are deliberately broken specialists: trained until continuing a six-column claims table is the only thing they can do. That narrowness is the design — it is what makes their independent agreement meaningful — and it also means they cannot explain themselves. Asking them to would mean un-breaking them, trading recognition quality for eloquence. The two jobs pull in opposite directions, so they belong to different models.
The explanation model has the opposite profile: a general medical-language model that never votes, never trains on a pool, and has no influence on whether a suggestion fires. The decision is complete before it is ever invoked. It is a communication layer, not evidence — a well-written narrative cannot create a suggestion, and a clumsy one cannot suppress it. Nothing it writes adds to or subtracts from the consensus it describes.
Strictly limited inputs
The explanation model receives exactly four things:
| input | what it contributes |
|---|---|
| the suggested test | what the narrative is recommending the physician consider |
| the patient timeline that led to consensus | the same anonymized six-column claims history the ensemble saw — the pattern it must describe |
| the vote count | how many independent models agreed, stated plainly as a flag |
| general knowledge of the target condition | enough clinical framing to say why the pattern and the test belong together |
It never sees laboratory values, test results, clinical notes, imaging, or anything from a medical record. It works from the same anonymized billing view as the recognition ensemble, so the privacy boundary holds end to end: no part of PRISM, including the part that writes prose, ever handles clinical data.
How the narrative reads
The language is pattern-based, not probabilistic. No confidence percentages, no risk scores, no diagnosis — consensus is a flag, not a probability, and the narrative must not dress it up as one. The tone is suggestion, never directive. An example of the intended register:
This patient's recent history shows a recurring pattern: repeated visits for symptoms that have not resolved, escalating medication adjustments without a settled answer, and laboratory work circling the same system more than once. Four of five independent models, each trained on a different patient population, continued this history toward the same screening test. Patterns like this one have preceded conditions this test can detect early. It may be worth considering; whether it is appropriate for this patient is, as always, your judgment.
Note what is absent: no percentage, no urgency, no instruction. The narrative names a pattern, states the vote count plainly, and hands the decision to the person who can actually see the patient. That posture — physician autonomy, primary-care-only delivery, information rather than imperative — is covered in full in clinical decision support, and the narratives travel through the existing insurer channels those suggestions already use.
Honest limits
None of this exists yet. The 2026 synthetic prototype reported raw fires and vote counts; no narrative layer was built or needed. And a generative model writing fluent prose is a known hazard: fluency can imply more certainty than the evidence carries. The design's two guards are the strictly limited inputs above and the structural fact that the narrative carries no evidential weight — the suggestion is identical whether the explanation is graceful or not.