The accountability layer: what buying an EHR does not settle

Brian K. Hudes, MD

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 those principles are the beginning of the accountability question, not the end.

Choosing an electronic health record (EHR) does not establish who evaluates each AI tool, what evidence supports its use, or who must act when it falls short. Once the technology is drafting a note, suggesting a code, proposing an order, or flagging a patient, those questions stop being abstract.

The Epic–Oracle rivalry is consequential. It is not a substitute for examining the arrangements around the intelligence running inside either system. The question is not simply which company supplies the software. It is whether responsibility is matched by the information, authority, and resources needed to exercise it.

Accountability is infrastructure, not a sentiment

On September 30, 2026, six national physician organizations — the American Medical Association, American Academy of Family Physicians, American Academy of Pediatrics, American College of Obstetricians and Gynecologists, American College of Physicians, and American College of Surgeons — reaffirmed that AI should support, not displace, physician expertise. Agreement on that principle does not settle how responsibility should be divided when a system fails.

As a physician, I should be accountable for how I use an AI-assisted recommendation. That does not make me responsible for every decision that put the recommendation on my screen. At the bedside, I may not be the person who selected the training data, validated the model, configured its inputs, approved its deployment, or authorized its latest update. Those decisions need identifiable owners too.

The organizing principle I propose is that responsibility should follow control. Clinicians should answer for their clinical decisions. Institutions should answer for deployment, local implementation, and ongoing oversight. Developers should answer for the systems they build, the claims they make, and the changes they introduce. A physician's signature should not make those other responsibilities disappear.

For that principle to mean anything, I need relevant evidence about a tool's intended use and limits, a real opportunity to question its output, and a reliable way to escalate a concern. A name attached to an output is not enough. Accountability is infrastructure, not a sentiment.

Hadas Bitran, in her October 9 essay "AI and Human Accountability", emphasizes the responsibility of the person who reviews and approves AI-generated work. Her practical advice includes reading the generated content, checking what supports it, and deciding whether one can explain and defend it. That is a real professional duty, not a clerical step.

I would add two limits. Approval does not erase a document's provenance, and it does not absolve the institution or developer of responsibilities within their control. Individual discipline is necessary. It is not sufficient.

Disclosure is not the same as assurance

The federal rule known as HTI-1 established source-information requirements for covered predictive decision-support interventions supplied as part of certified health IT. These include information about development, validation, intended use, and maintenance. Access to that information is not the same as independent confirmation that a tool performs acceptably in a particular hospital.

In December 2025, ONC proposed HTI-5, which would remove the AI model-card requirements from the decision-support-interventions certification criterion. At the time of this review, ONC continues to list HTI-5 as a proposed rule, not an enacted repeal. The proposal is a reason for institutions to specify the evidence they require rather than assume that certification will answer every purchasing question.

It also helps to distinguish the instruments buyers are being offered. A model card gives a structured account of a system. But CHAI's registry terms place responsibility for submitted information on its authors, disclaim any guarantee of accuracy, and state that inclusion is not an endorsement. A disclosure can organize a buyer's questions without independently resolving them.

The Joint Commission's voluntary Responsible Use of AI in Healthcare certification addresses a different question: whether an organization has governance, safeguards, monitoring, and education in place for responsible AI use. The Joint Commission explicitly states that the program does not validate or certify individual AI products or tools.

These are four different things: a developer's disclosure, an organization's governance certification, an independent evaluation of a particular tool, and ongoing monitoring of that tool in use. Each answers a different question. None should be mistaken for the others.

Independent assurance cannot be assumed

In the discussion beneath Doherty's essay, a commenter posting as Dr Nik asked who provides independent evidence of how AI behaves after deployment across institutions. It is the question I would put to a hospital purchasing these systems.

The answer is not that no one is building this. On November 18, 2024, the American College of Radiology launched Assess-AI, a registry designed to monitor imaging AI in clinical use and compare local results with aggregated benchmarks. Its stated functions include tracking changes in algorithm inputs and comparing AI results with radiology reports.

That is a concrete example of post-deployment oversight, not an empty promise. Its measurement approach also illustrates why buyers need to examine scope. Agreement with a radiology report is not, by itself, proof of independently adjudicated clinical accuracy or improved patient outcomes. The measure is useful, but it does not answer every question about a tool's safety or benefit.

The practical question is whether the hospital buying a particular tool can obtain the evidence and oversight that tool requires. A program may cover one specialty, one class of algorithms, or one measure of performance. Its existence does not settle responsibility for the other systems already shaping care.

Vendor monitoring should be part of the evidence, not the only evidence. A hospital needs results it can interrogate and a way to investigate concerns outside the vendor's own reporting process. Independence should be judged by the arrangement, not the label. Who chooses the cases? Who defines acceptable performance? Who can see the failures? Can an evaluator report an unfavorable finding without the vendor's permission? Who has the authority to require a change?

Those questions should apply to every developer, including companies led by physicians, mine included. They should also be asked of an outside evaluator: who pays for the work, what interests might influence it, and what can it actually establish?

What accountability would require in practice

Before an AI tool becomes part of routine care, I would expect an institution to answer four questions.

What exactly has been evaluated? "The AI" is not a precise description. The evidence should identify the version, intended task, relevant patient population, and conditions of use. A reassuring result from a different setting is a reason to ask a question, not to end the discussion. The hospital should know whether the evidence applies to the tool and workflow it is actually deploying.

What counts as acceptable performance here? The answer depends on the task. For a risk score, I would ask about missed cases, false alarms, calibration, and the consequences of acting on the score. For a documentation tool, I would ask about clinically important omissions, unsupported statements, and the work required to correct them. "It saves time" and "it performs safely" are different claims. Acceptable limits and the findings that would trigger investigation should be specified before routine use, not improvised after a problem.

Who is responsible for acting on a problem? Oversight needs more than someone who receives reports. It needs designated people with the authority to investigate, restrict use, require a fix, or suspend the tool. A clinician should be able to reject an inappropriate recommendation and report a concern without having to discover the escalation chain while also caring for the patient. Overriding one recommendation and suspending a system across the hospital are different decisions; both need clear authority.

What happens after something changes? Changes to a model, its inputs, the workflow, or the population served should trigger a documented review of whether the existing evidence still applies. The depth of re-evaluation should be proportionate to the clinical risk and the likely effect of the change. Approval is not a permanent credential detached from the conditions under which it was granted.

None of this asks every physician to become a data scientist. It asks the institution to make its assurance process inspectable and its responsibilities explicit.

It is also harder than "budget for monitoring" makes it sound. Someone has to fund the evaluation. Someone has to provide usable data. Disagreements about findings have to be adjudicated. Smaller hospitals without dedicated analytics teams need a way to participate. A policy that assigns obligations without resources has not solved the problem; it has moved it.

One practical approach would be shared evaluation through professional societies or regional collaborations, with local responsibility for interpreting the findings and acting on them. Contracts should specify what evidence the developer supplies, how changes are communicated, and what access is available for investigation. No single arrangement will fit every tool. The point is to make the arrangement explicit before anyone mistakes a purchase for an assurance of safety.

What a renaissance physician should actually demand

For me, the point of The Renaissance Physician is to examine the connections between clinical practice, technology, institutions, and the incentives shaping all three. Clinical AI cannot be judged in only one of those domains.

I would ask for an accountability record that connects the tool's intended use and evidence to named responsibilities, a review process, and the authority to intervene. It should distinguish the clinician's decision from the institution's deployment decision and the developer's technical responsibilities. It should also make clear which questions the available evidence does not answer.

Which EHR a hospital chooses matters. But it does not settle who evaluates the AI, who can intervene when it fails, or who must answer for the consequences. Those responsibilities need to be explicit, not inferred from the presence of a physician somewhere in the workflow.

The next question after "Which EHR?" should be: "Show me the accountability arrangement." Show me the evidence, the people responsible for evaluating it, and the authority they hold when the system falls short.

The work does not end when someone signs off on the purchase — or on the note. Accountability exists only when responsibility is matched by the information, authority, and resources needed to exercise it, and those conditions are maintained as the system changes.

Brian K. Hudes, MD, is a practicing gastroenterologist and GI hospitalist and writes The Renaissance Physician. Disclosure: He is the founder and CEO of AiMOS Systems Corporation and has a commercial interest in clinical AI.