By Robin Roberts (PointClickCare), Vice Chair, EHR Association AI Workgroup, and Lukasz Kowalczyk, MD (Provation), Member, HIMSS Physician Committee

This is the first of a 5-part joint blog series from the EHR Association and the HIMSS Physician Committee exploring AI governance in healthcare.

Most of the conversation about AI in healthcare has centered on one question: is the answer correct? That made sense when the technology’s output was a draft or a suggestion for a person to evaluate.

It’s no longer the primary question.

The critical shift with agentic AI is not that it can reason better. It’s that AI can now move from recommending an action to executing a sequence of actions. A chatbot responds. An agent acts toward a goal. As such, healthcare must now govern the pathway an AI system takes, not just the answer it gives.

The Agentic AI Difference

An agent pursues a goal in a loop: it plans, acts, observes what happened, adjusts, and repeats until it finishes the task, escalates it, or stops. That loop separates agentic AI from other AI tools, such as predictive and generative AI, by adding goal-directed execution. An agent can call tools, maintain state across steps, observe the result of its action, adapt, and continue until the task is complete, halted, or handed to a person.

A system does not need unrestricted autonomy to be “agentic,” and most of the near-term value in healthcare will come from systems that are narrowly and deliberately bounded rather than fully autonomous. But even a tightly scoped agent changes what governance must account for.

Agentic AI is a spectrum. A system does not need unrestricted autonomy to be “agentic,” and most of the near-term value in healthcare will come from systems that are narrowly and deliberately bounded rather than fully autonomous. But even a tightly scoped agent changes what governance must account for. While a generative assistant might draft a scheduling message for a colonoscopy referral, an agent could identify the eligible patient, verify the required information, contact the patient, offer available slots, book one, and trigger preparation instructions—all without a human in the loop unless it flags something for escalation.

The Time is Now for This Conversation

Agentic functionality already exists in health IT, often as automation or assistance. It frequently sits in administrative workflows that aren’t formally classified as clinical. Health systems and developers increasingly have the infrastructure to connect models to APIs, scheduling systems, messaging platforms, and patient data, which means the operative question is shifting from what models can say to what systems should be allowed to do.

Recent research illustrates how far this can go: a 2026 study published in Nature described MIRA, an agent operating in a sandboxed EHR environment that could take patient histories, order and interpret tests, generate differential diagnoses, and formulate treatment plans. The authors were explicit that this was a simulation and called for real-world validation, safety review, and governance work before anything like it reaches practice, illustrating the gap between technical capability and deployment readiness.

That is one more reason to establish shared vocabulary now, before agentic deployment outpaces the governance built to oversee it.

Regulatory and policy frameworks are moving, albeit unevenly, though most of what exists today still describes systems that produce output for an “expert” person to weigh. ONC’s proposed HTI-5 rule and pending decision support criteria, the FDA’s January 2026 clinical decision support guidance, and a growing patchwork of state AI laws are still catching up to systems that act rather than advise. That is one more reason to establish shared vocabulary now, before agentic deployment outpaces the governance built to oversee it.

What’s on the Agentic AI Horizon

The highest-value near-term use cases for clinical agents are unlikely to be autonomous diagnosis. They are more likely to target the fragmented, repetitive, multi-step workflows where staff already move among EHR screens, payer portals, scheduling systems, and work queues: referral intake, prior authorization, utilization management, care-gap outreach, and registry follow-up. Many of these actions are reversible and can be constrained by explicit policy, which is part of why they make sensible targets for the next wave of agentic AI.

Prior authorization is a useful test case for why that caution matters. It delays care, exhausts staff, and looks like a good candidate for automation: an agent could monitor orders that require authorization, pull supporting documentation, check payer criteria, submit the request, track its status, and escalate when it stalls.

The need is real, but so is the exposure. If nobody reviewed the submission—because not reviewing it was the entire point of building the agent—who owns the denial that arrives a week later, and does the care team learn about it while there is still time to act? One recent evaluation of long-horizon, policy-rich healthcare workflows, including prior authorization, found agents completed the task end to end only a fraction of the time, despite having the tools, policies, applications, and data available. Further, when asked to complete tasks multiple times in a row, performance declined even more.

Capability and reliability are both essential. However, agents have so far demonstrated only the first.

Capability and reliability are both essential. However, agents have so far demonstrated only the first.

Governing the Workflow

When an AI model’s output was the endpoint, it made sense to evaluate that output for accuracy or whether the summary was faithful to the chart. However, once software can execute multi-step actions, evaluation must shift from “Did it produce the right answer?” to “Did it complete the right workflow, using permitted actions, under policy, with appropriate escalation, at an acceptable level of reliability?” That means governing the tools an agent can call, the systems it can write to, the preconditions and escalation triggers attached to each action, and whether the organization can reconstruct what happened afterward.

Reconstruction matters because supervising an agent does not work like supervising a person. A person can be observed; an agent’s steps happen faster than anyone can watch, so the record itself becomes the supervision mechanism. This is why it is important to observe both an agent’s flow and early trajectories, since achieving the right outcomes often requires traversing a risky path.

Health IT already has much of the underlying capability this requires; audit logging is one of the few capabilities essentially every certified product has, and its content standards are well established. What must extend is the shape of the record—from a single entry showing who touched which record and when—to a sequence that also captures the goal the agent was pursuing and the permissions it held while acting.

What must extend is the shape of the record—from a single entry showing who touched which record and when—to a sequence that also captures the goal the agent was pursuing and the permissions it held while acting.

Existing frameworks already point in this direction. The NIST AI Risk Management Framework organizes lifecycle governance around four functions: govern, map, measure, and manage. HIMSS’s own AI Global Policy Principles call for safety, transparency, accountability, and continuous monitoring.

Agentic systems don’t require new principles so much as they make existing ones operational rather than aspirational.

The practical implication is that autonomy should be earned in stages rather than assumed on day one. First, sandbox or shadow deployment, then recommend-only, then low-risk reversible execution, then broader bounded autonomy, with evidence gates between each stage rather than a single go-live decision.

Looking Ahead

Each stakeholder group has a role in that staging process, and each will get fuller treatment later in this series:

• Clinicians need to be involved before a system is built, defining what “unsafe” and “must escalate” mean in context.
• Health system leaders need an inventory of which agentic systems are already running, tiered by consequence, reversibility, and scale, with workflow-level validation required before production use.
• Developers need to make explicit what an agent is permitted to touch and expose enough of its trace for a clinical reviewer—not just an engineer—to make sense of it.
• Policymakers need to anchor obligations to what a function is permitted to do and what happens when it is wrong, rather than to the label “AI” itself.

This is the first of five articles in this joint EHRA and HIMSS Physician Committee series. Blog 2 takes up governance and accountability once software can initiate actions on its own. Blog 3 turns to privacy and state law as agents touch more systems and more data over time. Blog 4 looks at what agentic tools mean for clinical workflow design and workforce roles. Blog 5 addresses the technical standards and interoperability architecture that determine what an agent can actually see and do.

None of this argues against building agentic systems in healthcare. Rather, it argues for building oversight alongside them. Healthcare has done this kind of system-level safety work before. The patient safety movement concluded decades ago that safer outcomes come from designing systems around fallible workers rather than expecting flawless performance from any one of them.

The worker has changed. The design obligation has not. This series seeks to make a system’s level of action authority proportional to the evidence behind it, the risk it carries, and the safeguards built around it. In doing so, healthcare governs the pathway an agent takes, not only the answer it produces.