In a recent essay on Epic and Oracle, Eric Doherty argued that health care leaders should not pick a side. They should demand AI that is trustworthy, portable, and patient-centered. I agree.
But that is the beginning of the accountability question, not the end. Once the technology is in use (drafting the note, suggesting the code, proposing the order, flagging the patient), who verifies that it keeps performing as expected? Who can intervene when it does not? And what responsibility belongs to the clinician, to the institution, and to the company that built it? The rivalry everyone is watching, Epic’s integrated system against Oracle’s ambition to automate the whole industry, has surprisingly little to say about any of that.
On September 30, 2026, six national physician organizations (the American Medical Association, the American Academy of Family Physicians, the American Academy of Pediatrics, the American College of Obstetricians and Gynecologists, the American College of Physicians, and the American College of Surgeons) reaffirmed that AI should support, not displace, physician expertise. That is an important principle. It does not answer how responsibility should be divided when a system fails.
Here is the principle I would propose: Responsibility should follow control. Clinicians should answer for their clinical decisions. Institutions should answer for the systems they deploy, the conditions under which they are used, and the oversight they provide. Developers should answer for the systems they build, the claims they make, and the changes they introduce. A physician’s signature should not be allowed to absorb the responsibilities that belong to the institution and the vendor.
Real physician voices, twice a week
Free, and one click to unsubscribe.
Accountability is not a sentiment. It is infrastructure. For a clinician to genuinely own an AI-assisted decision, three things have to be true: She needs enough information to know where the tool should and should not be trusted, she needs real authority to override it, and she needs institutional support (monitoring, investigation, a way to escalate) behind her. A name attached to an output, with none of that, is not accountability. It is a liability address.
The transparency scaffolding for this is thinner than it looks, and getting thinner. HTI-1, the federal rule, established source-information requirements for certain predictive decision-support tools in certified health IT: a disclosure of how a tool was trained, tested, and maintained. HTI-5, proposed in December 2025, would remove those AI model-card requirements from the certification criterion. It is a proposal, not an enacted repeal; but it is a reason for institutions to be more explicit about the evidence they require, not less.
It also helps to be precise about what the available instruments certify. A model card, of the kind the Coalition for Health AI (CHAI) popularized, organizes the questions a buyer should ask, but CHAI’s own registry places responsibility for the submitted information on its authors and states that inclusion is not an endorsement. In June 2026, the Joint Commission introduced a voluntary “Responsible Use of AI in Healthcare” certification, but it certifies an organization’s governance processes, and explicitly not individual AI products. A disclosure, an organizational certification, and evidence that a particular tool still performs on your patients are three different things. None should be mistaken for the others.
Which points to the deepest gap. In the discussion beneath Doherty’s essay, a commenter posting as Dr Nik raised the question of who provides independent evidence of how AI behaves after deployment, across institutions. That is the question I would put to every hospital buying these systems. Vendor monitoring should be part of the evidence, not the only evidence. A hospital needs results it can interrogate, a way to investigate concerns outside the vendor’s own reporting process, and the authority to act on what it finds, because the organization selling the system should not be the only one deciding whether it is working. A hospital should not assume that purchasing an AI-enabled system also purchases independent, ongoing assurance of its performance.
So whichever system you choose, remember that you are buying an EHR, not an accountability system, and write the second one into your requirements. Demand a model card, and treat it as the floor, asking who stands behind its claims. Insist that every AI-assisted action trace to a named human who has a real path to override it and to flag a bad output. And budget for independent evaluation of how each model performs on your own patients over time, because that assurance does not come bundled with the license, and the federal requirement that once encouraged it may not survive.
Which EHR a hospital chooses matters; it will shape where our data lives for a decade. But it does not settle who evaluates the AI, who can intervene when it fails, or who must answer for the consequences. Those responsibilities have to be made explicit, not inferred from the presence of a physician somewhere in the workflow. The patient in front of me does not care whose logo is on the screen. She cares that a human being is responsible for what the machine suggested, and that someone is paying close enough attention to catch it when the machine is wrong.
Dr. Hudes has a commercial interest in how clinical AI is governed and monitored.
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 more than 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 is an assistant professor of medicine at Florida State University College of Medicine.
Those two halves of a career shape the way he writes about medicine and clinical technology. Outpatient practice and hospital-based care fail their clinicians differently, and many systems are designed without a meaningful understanding of both environments.
Dr. Hudes has been building clinical software alongside his medical practice for decades. In 1995, during his gastroenterology fellowship, he co-developed one of the first Windows-based endoscopy reporting systems in the United States. He is now founder and chief executive officer of AiMOS Systems Corporation, where he is developing an AI-native clinical platform for outpatient and hospital-based care. AiMOS has been accepted into NVIDIA’s Inception program.
He writes about 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 health care technology industry builds. He also publishes The Renaissance Physician, an independent publication examining medicine, technology, physician workforce, and the structure of modern clinical practice.
