Two good arguments about clinical AI have appeared here recently, and between them they have accounted for almost everything except the part that matters most.
Harvey Castro has argued that the real limitation is not the model but the context, pointing to the blood pressure entered three minutes ago and the allergy buried in yesterday’s note that the system cannot see. Miguel Venereo has argued that the record itself is fragmented, that the chart in front of you is only whatever happened to land in your instance of the EHR, and that an incomplete chart never announces itself as incomplete. Both are right. Castro wants the record reachable. Venereo wants it complete.
Grant them both. Imagine the problem solved tomorrow: every encounter from every system, retrieved without the patient logging into six portals, gaps flagged where data is genuinely missing. A complete chart, fully reachable, delivered to whatever model you like.
It will still be close to unusable for clinical reasoning, and the reason has nothing to do with completeness.
Real physician voices, twice a week
Free, and one click to unsubscribe.
What the record was actually built to do
The modern chart is not a clinical document that happens to be used for billing. It is a billing and compliance document that clinicians are permitted to reason from.
Its organizing unit is the encounter, because the encounter is the unit of payment. Its content is shaped by what must be documented to justify a level of service, satisfy a quality measure, or survive an audit. Its most reliable elements are the ones tied to reimbursement. Its least reliable are the ones that carry the actual clinical story: what we thought was happening, what we tried, what changed our minds.
Nothing in that structure represents the course of an illness. There is no object in the chart that corresponds to “this patient’s cirrhosis over four years.” There is a pile of encounters, each one a snapshot written for a different purpose, from which a physician reconstructs the trajectory by reading and remembering.
We are extraordinarily good at that reconstruction. It is most of what expertise consists of. We are also almost never given credit for it, because it happens silently, and because the interface presents the pile as though it were already the story.
Why this defeats a model specifically
Hand an encounter-structured record to a language model and it will do exactly what the structure invites. It will summarize encounters.
Ask it about a patient with decompensated cirrhosis and it will faithfully report what each note said. What it will not do is notice that the ascites became refractory over eleven months, that two paracenteses were deferred for scheduling reasons rather than clinical ones, that the diuretic dose has been unchanged since a creatinine bump nobody revisited, and that the trajectory has been pointing at transplant evaluation for half a year while every individual note read as stable.
That reasoning is not in any encounter. It exists only across them, and only in a form the record has never been asked to represent. A complete chart does not contain it. A complete chart contains the raw material from which a physician generates it, and then throws away the generated version, because there is nowhere to put it.
This is why better retrieval will disappoint. Give a model perfect access to a pile and it reasons over a pile.
Why a layer on top cannot become the thing
The standard response to all of this is that we do not need to rebuild anything, because we can put intelligence on top of what exists. Connect a model to the EHR, give it good retrieval, and let it do the reconstruction the physician has always done.
This misunderstands what a layer can do. Any system built on top of another can only reason over objects the system underneath represents. If nothing in the schema corresponds to a problem tracked across time, with its own assessment and its own history of what was considered and rejected, then the layer above cannot retrieve one. It can only infer it, from scratch, on every query.
That is the failure worth naming precisely. The reasoning evaporates. A model asked about the cirrhotic patient on Tuesday derives a trajectory, produces something useful, and then discards it, because there is nowhere in the underlying record to put a conclusion of that kind. On Thursday it derives it again, possibly differently, with no memory of what it concluded, no record of who corrected it, and no way for the next clinician to see either. Nothing accumulates. Every query starts from wreckage.
Contrast that with what medicine actually does. An attending’s understanding of a patient is cumulative and correctable. It gets revised on rounds, challenged by a consultant, updated by a study. Our records have never had a place to store that understanding, so it lives in the physician’s head and dies when the service changes.
It is worth remembering how old these foundations are. Epic and Cerner were both founded in 1979, and the database underneath the market leader is written in a language developed at Massachusetts General in 1968. But age is not the charge, and anyone who makes it that way deserves to lose the argument. The engineering is formidable, and it would be wrong to say these systems cannot hold longitudinal data. They were designed to.
The real argument is not that the software is old. It is that it was optimized for a purpose that is not reasoning, and every layer since has inherited that choice. Forty years of reimbursement rules, documentation requirements, and regulatory programs were stacked onto that foundation, and each one shaped what the record contains and how it is arranged. What emerged is a superbly engineered system for a purpose that was never clinical reasoning.
A system built today with the same data model would fail the same way.
You do not get to a different purpose by adding a layer. You get there by changing what the system represents.
We knew this before we had the machines
Lawrence Weed proposed the problem-oriented medical record in 1968, on the argument that a chart organized by source and encounter cannot support reasoning about a patient, and that the organizing unit should be the problem, tracked over time. He was right, the profession broadly agreed, and then the reimbursement architecture of the following decades ensured that what got built was organized around the visit instead.
The problem-oriented record lost to the billing-oriented record. We have spent fifty years working around the outcome, and we are now handing that outcome to systems that do not have the human capacity to work around anything.
What the solution actually has to be
Retrieval and completeness are necessary. They are not the deliverable. The deliverable is a representation of the patient that is organized the way clinical reasoning is organized:
The problem, not the visit, as the primary object, with its own timeline, its own evolving assessment, and its own history of what was considered and rejected. Trajectory as a first-class element, so that direction of travel is stored rather than reconstructed each time. Provenance on every element, so both physician and model know where a fact came from and how old it is. Explicit representation of absence, so the system can state what it does not know rather than reasoning confidently over a hole. And clinical reasoning captured as reasoning, not compressed into a note field shaped by documentation requirements.
That is not a layer on top of the EHR. You cannot bolt a longitudinal problem-oriented representation onto a database whose primary key is the encounter and whose content model was designed to defend a claim. It is a different substrate.
Which is the uncomfortable part, and the reason this argument gets made less often than the other two. Better retrieval can be sold to a health system as a module. Completeness can be sold as an integration. What I am describing cannot be sold as an add-on to the thing it replaces, and so the incentive to make the argument publicly is weak.
Make it anyway. The next several years will produce a great deal of clinical AI reasoning over complete, reachable, billing-structured records, and the results will be blamed on the models. They will not be the models’ fault. We will have given these systems the same document we have been quietly compensating for since 1968, and then expressed surprise that they could not do what we never taught the record to support.
Completeness is not usability. Reachability is not usability. The chart has to be rebuilt around the illness, or everything we put on top of it inherits a filing system designed by an accountant.
Brian Hudes is a board-certified gastroenterologist and hepatologist with more than thirty years of clinical experience and a recipient of his specialty board’s thirty-year certification award. He built and ran a private gastroenterology practice for twenty years, then spent over a decade in hospital-based gastroenterology, most recently as chief of gastroenterology and medical director of GI and endoscopy at a 550-bed Level I trauma center in Pensacola, Florida. He holds a faculty appointment as assistant professor of medicine at Florida State University College of Medicine.
Those two halves of a career are the reason he writes about clinical software the way he does. The outpatient practice and the inpatient service fail their clinicians differently, and most people building for one have never worked in the other.
Dr. Hudes has been building the tools alongside the practice for just as long. In 1995, during his GI fellowship, he co-developed one of the first Windows-based endoscopy reporting systems in the United States, written because nothing on the market had been designed by anyone who had performed a procedure. He is now founder and chief executive officer of AiMOS Systems Corporation, where he is building an AI-native clinical platform for both settings, intended to replace the encounter-based electronic record rather than layer intelligence on top of it. AiMOS has been accepted into NVIDIA’s Inception program.
He writes on the architecture of clinical information, administrative cost growth, physician workforce shortages, board certification policy, and the widening gap between what clinicians need and what the industry builds. Professional updates are available on LinkedIn.
