Healthcare has spent the better part of two decades wiring itself together, and the work has paid off. Records that once sat trapped in silos can now be queried through standard interfaces. By 2024, roughly 81% of US hospitals let patients reach their records through apps, and about 70% supported access through apps built to the FHIR specification, according to federal data. On paper, the interoperability project is nearly finished.
And yet the daily experience of running a hospital or a medical group has barely changed. A physician still completes around 40 prior authorizations a week and loses roughly 13 hours to them. A nurse still re-keys the same patient for details into three systems. A revenue cycle analyst still sits on hold with a payer.
The data moves, but not the work.
That gap is worth examining closely, and the argument is more precise than it first sounds. FHIR standardized access to healthcare data, including the ability to write it, not just read it. What healthcare still lacks is a standard way for an AI agent to find out what a given system can actually do, and call it safely, when the agent is deciding what to do next. That gap has a name now, the Model Context Protocol. Understanding what MCP actually is, and is not, matters more than the usual narrative allows.
Connected, but Not Automated
Prior authorization is the workflow that best exposes the gap. The data needed to approve most requests already exists in structured form. The clinical record is queryable. The payer rules are published. Standards bodies have defined the exact transactions involved.
CAQH found that the industry-wide shift from manual to electronic administrative transactions helped avoid roughly 222 billion dollars in spending in 2024. That figure reflects the move from phone calls and faxes to electronic transactions across the industry as a whole. It predates the current wave of AI agents and should not be read as evidence of what AI has delivered so far. Even so, only about 35% of medical prior authorizations are conducted fully electronically, and the rest still run on phone calls, faxes, and portal logins, at an average of sixteen to twenty-four minutes a piece.
And, that is the paradox. The pipes are in place. The water is not flowing on its own. Healthcare has connectivity. It does not yet have a standard way to let an AI agent act on that connectivity across systems that were never built to talk to one another.
What FHIR Actually Does
FHIR is not a read-only standard. It defines a full set of RESTful operations: read, search, create, update, delete, patch, and system-specific operations.
A FHIR API can submit a claim, create a referral, or update a care plan just as easily as it can return a lab result. The Prior Authorization API required under CMS-0057-F is itself built on FHIR resources that get created and submitted, not merely queried.
The real limitation is narrower and less often stated. FHIR standardizes what healthcare data looks like and how a single system exposes it.
What MCP Actually Is
What MCP actually does is narrower than the “action layer” suggests. It standardizes how a model discovers which tools are available, what each one does, and how to call it, using a shared schema instead of a bespoke integration for every pairing of model and system. Anthropic has described the problem it solves as an “N times M” problem: without a shared protocol, every AI application needs a custom connector for every data source or tool it touches, and that multiplies fast as both numbers grow. MCP replaces the custom connector with a common interface. A system exposes its capabilities through an MCP server. A model reaches those capabilities through an MCP client. The protocol governs that handshake, nothing more.
What MCP does not do is submit the prior authorization, book the appointment, or hold the claim. Those actions are performed by the backend application or workflow system behind the MCP server, the same systems that performed them before MCP existed. MCP does not own business logic, does not orchestrate a sequence of steps across systems on its own, and does not execute a workflow by itself. It exposes what a system can do, in a form a model can understand and call. Work still happens where it always happens. What changes is how much custom code it takes to let an agent reach it.
How This Differs From the Middleware Healthcare Already Runs
None of this is the first attempt healthcare has made at automating a task. Hospitals have run integration engines and workflow orchestration for years: Mirth and Cloverleaf for interface engines, Boomi and MuleSoft for integration platforms, Camunda for business process orchestration, ServiceNow for IT and clinical workflow automation. These systems already move data and trigger actions across applications, and they will keep doing that work.
The honest question is what MCP adds on top of infrastructure that already exists, and the answer is specific. That existing middleware orchestrates systems, built and configured by engineers, one integration at a time, for a defined and largely fixedworkflow. MCP does not replace that orchestration. It standardizes how an AI agent, rather than a hardcoded workflow step, discovers and calls the capabilities that middleware, backend systems, and FHIR APIs already expose. An integration engine still moves the message. MCP is what lets a model decide, in the moment, which of those already-built capabilities to invoke, without an engineer having written that specific decision path in advance. That is a narrower and more useful claim than saying healthcare lacks an action layer, and it is the one worth making.
The Layers, Correctly Divided
It helps to separate the pieces cleanly, because loose language here is exactly what a technical reader checks first.
FHIR is the data standard. It defines what a clinical or administrative fact looks like and how systems exchange it.
Middleware and backend applications are where execution actually happens. They hold the business logic and submit the transaction, and they existed before any of this and will keep running the work.
MCP is the access layer for AI agents specifically. It standardizes how a model finds out what a backend system, a FHIR API, or a piece of middleware can do, and how to call it, without a custom integration written for that one model and that one system.
The agent is the reasoning layer. Given the data and the tools it can now discover through MCP, it decides what should happen next.
Humans remain the oversight layer, reviewing and approving the calls that carry the most risk.
Each layer depends on the others, but not in the way a flatter framing implies. An agent with strong reasoning and no standardized access to tools still needs a bespoke integration for every system it touches, which is exactly the cost MCP is built to remove. A backend system with no agent calling it keeps doing exactly what it did before, on the schedule a person or a script gives it. And none of this replaces the human review that higher-risk actions still require. Skip a layer, and the stack does not fail dramatically. It simply reverts to how healthcare IT has always worked: capable, but expensive to connect to anything new.
Prior Authorization, Without the Shortcuts
Return to prior authorization with the corrected layers in view, and a fuller picture starts to emerge.
FHIR supplies the diagnosis, the procedure code, the clinical evidence, and, where the payer supports it, the resources to submit the request itself. MCP gives an agent a standard way to see which of the payer-facing actions are actually available to call: check whether authorization is required, assemble documentation, submit, poll for status, escalate.
None of that removes the real complexity underneath. Submission still runs through payer-specific APIs that vary by payer. The HL7 Da Vinci implementation guides, Coverage Requirements Discovery, Documentation Templates and Rules, and Prior Authorization Support, still define the sequence a request has to follow.
Authentication and scope management still have to be negotiated per system. Payers still respond on their own timeline through asynchronous callbacks rather than a single synchronous call. And a meaningful share of requests still need a person to review before anything is submitted.
What an agent actually does inside that reality is read the requirements, gather what the rules demand, decide whether the case is clean enough to submit on its own or needs a person, and then call the appropriate tool through MCP rather than through a hand-built integration written for that one payer. The workflow is exactly as complicated as payer variability makes it. What is different is how much custom integration work it takes to give an agent access to the pieces it needs to navigate that complexity.
What Most Healthcare Automation Conversations Get Wrong
More APIs do not equal more automation. Adding a fifth or a fiftieth integration expands what a system can see. It does nothing about what a system, or an agent, can do with it.
AI alone is not automation. A model that drafts a flawless appeal letter has produced a document, not an outcome. The outcome requires the letter to be attached to the right case, routed to the right payer, tracked, and recorded. As Farooq Ajmal, chief information officer at Ryan Health, has observed, doing automation in increments often just means taking a manual workflow and translating it digitally.
Standardizing tool access is not the same as building the workflow. MCP does not decide what “done” looks like for a given process, does not write the business rules, and does not design the escalation path. Those remain engineering and operational decisions, made by the people who build the MCP server and the agent that calls it, not by the protocol itself.
Access and execution were always different problems, and agent access is a third one. Solving interoperability did not solve execution, and standardizing how an agent reaches existing systems does not, by itself, solve either of the other two. Each layer still has to be built.
The Compliance Gap the Protocol Does Not Close
This is the gap most healthcare-specific writing about MCP skips entirely, and it is the one a security or compliance reader will ask about first.
MCP is a general-purpose communication protocol. It was not designed with HIPAA in mind, and nothing in the specification makes a deployment compliant by default. There is no built-in requirement for encryption, no enforcement of the minimum-necessary standard, and no audit logging that comes free with the protocol.
Whether an MCP-based deployment is HIPAA compliant depends entirely on what gets built around it. Authentication and authorization still have to be enforced, and this is where SMART on FHIR’s scope model does real work, defining exactly what an app or an agent is allowed to see and do within a given launch context.
Encryption in transit and at rest still has to be implemented by whoever builds the MCP server. Audit logging, so that every tool call is attributable and reviewable, is the responsibility of the server and the surrounding infrastructure, not a feature of MCP itself. And if a tool call passes patient information into a model’s context, someone in the organization has to be able to answer where that data goes, whether it is retained, and whether the deployment needs to run on infrastructure the organization controls directly, with a business associate agreement covering anyone who hosts the server or the model in between.
Why This Matters Now
The pressure is not abstract. The AAMC projects a shortage of up to 86,000 physicians by 2036, and more than four in ten active physicians will be 65 or older within the decade. Burnout, while down to about 43% of physicians reporting at least one symptom in 2024 from roughly 53% in 2022, is still driven heavily by administrative load, with a workweek near 58 hours that includes some 13 hours of indirect work such as documentation, order entry, and results. When there aren’t enough clinicians to meet growing demand, automating routine tasks is no longer just helpful. It’s essential to keeping the workforce effective.
Where This Pays Off
The best opportunities for AI agents using MCP are high-volume, rule-based workflows that use structured data and can recover from small errors. Several healthcare use cases meet these criteria, each with clear benefits and its own set of challenges.Here are a few of the use cases:
Prior authorization: Prior authorization creates a huge administrative burden and follows clear rules. AI agents can check requirements, collect the required documents, submit requests, track their status, and handle routine cases. This helps clinicians spend less time on paperwork and gets patients access to care faster. The need is significant: 94% of physicians say prior authorization delays care, and 82% report that patients sometimes abandon treatment because of these delays.
Care coordination: Care coordination is another strong use case because patients often fall through the cracks when moving between providers or care settings. AI agents can track referrals, identify care gaps, and remind care teams about the next steps. The value comes from helping patients complete the care they already need. The biggest challenge is that the process often spans multiple organizations, where data may be incomplete, outdated, or unavailable.
Patient outreach: Patient communication is a high-volume task with results that are easy to measure. AI agents can send appointment reminders, follow-up messages, care instructions, and reschedule missed visits. This reduces no-shows and improves patient engagement. The main challenge is that contact information is often inaccurate, and the timing and tone of communication can greatly affect patient response.
Scheduling and referrals: Scheduling and referral management are good candidates for automation because the workflows follow predictable rules and have clear outcomes. AI agents can book appointments, reschedule visits, and direct referrals to the right provider. This reduces administrative work while making the experience smoother for patients. The difficulty is that many scheduling rules exist only in staff knowledge rather than in scheduling systems, making automation more complex.
Revenue cycle management: Revenue cycle processes involve repetitive administrative work that costs healthcare organizations billions of dollars each year. AI agents can verify insurance eligibility, check claim status, identify denied claims, and manage follow-up activities. These improvements help organizations recover revenue while reducing manual effort.
According to CAQH, moving the remaining manual administrative transactions to electronic workflows represents an annual opportunity of roughly $20 billion. This estimate reflects the remaining manual work that can be digitized, not savings already achieved through AI. The challenge is that payer requirements vary widely, creating many exceptions that AI systems must handle.
Clinical documentation: Clinical documentation remains one of the biggest sources of after-hours work for clinicians. AI-powered ambient documentation tools are already being used widely to capture conversations during patient visits and automatically create structured clinical notes. The more difficult step is going beyond documentation to support clinical decisions, such as suggesting medical codes or recommending treatments. These tasks require clinical judgment, where even a small mistake can have serious consequences.
Across all of these examples, the same pattern emerges. AI agents using MCP deliver the fastest value in workflows that follow clear rules, rely on structured data, have well-defined outcomes, and can recover from occasional errors. They are less effective in workflows that depend on clinical judgment, involve highly variable information, or lack a clear definition of success. Capturing information and taking action may happen within the same workflow, but they require different levels of intelligence and oversight.
The Part Most AI Discussions Miss
Many AI pilots succeed in controlled environments but struggle when they move into production. That’s because several real-world challenges are often underestimated.
Production data is messy. Test environments contain clean, well-structured data. Production systems don’t. Records are often incomplete, inconsistent, or stored in unexpected formats. AI agents built for perfect data quickly run into problems.
Legacy systems still matter. Much of the information healthcare organizations need lives in older systems that don’t support modern standards like FHIR. Any AI solution must work with these systems instead of assuming they will disappear.
Workflows aren’t standardized. Even within the same health system, two clinics may follow different processes for the same task. Building automation around documented workflows isn’t enough. It must reflect how work actually happens.
EHR integrations take time. Gaining write access through SMART on FHIR isn’t an overnight process. Organizations must secure the right permissions, approval scopes, and vendor certifications. These approvals often take weeks, so they need to be factored into project timelines.
Governance can’t be an afterthought. Every action an AI agent takes should be secure, traceable, and auditable. The MCP protocol doesn’t provide governance by itself. Organizations must build authentication, authorization, logging, and compliance into the systems that use it.
Humans remain part of the process. The best AI deployments clearly define where automation ends and where people take over. Staff who perform these workflows every day know where the exceptions occur, making them essential to designing reliable automation.
Change management matters as much as technology. Most AI projects don’t fail because of the technology. They fail because people aren’t prepared for new ways of working. As Craig Joseph has observed, AI is increasingly becoming part of the clinical team rather than simply another technology tool.
The Regulatory Momentum
Healthcare’s move toward AI-enabled automation is also being supported by regulation.
The CMS-0057-F requires impacted payers to implement FHIR-based APIs, including Prior Authorization APIs, by January 1, 2027. Earlier operational requirements, such as faster authorization decisions and public reporting, began in January 2026.
The rule also recommends the HL7 Da Vinci Implementation Guides, which provide standardized workflows for determining whether prior authorization is required, collecting supporting documentation, submitting requests, and tracking their progress.
At the same time, Trusted Exchange Framework and Common Agreement is expanding secure data sharing across healthcare organizations through Qualified Health Information Networks, while SMART on FHIR provides the authorization model that allows applications and AI agents to securely access and update patient information.
Together, these initiatives create the standardized foundation that AI agents need. Regulations are making healthcare data more accessible through consistent APIs. MCP provides a standardized way for AI agents to use those APIs safely.
Where Healthcare Organizations Should Start
Organizations often want to automate their biggest pain points first. In practice, it’s better to begin with workflows that have clean data, clear rules, and measurable outcomes.
Start here: Eligibility verification and appointment reminders are ideal first projects. They rely on structured data, follow predictable workflows, and produce measurable improvements with relatively low clinical risk.
Next: Prior authorization and care gap outreach offer larger returns but require stronger infrastructure because they involve multiple organizations and more complex workflows.
Continue expanding: Ambient clinical documentation is already widely deployed across healthcare organizations. Rather than treating it as an experimental technology, organizations should use it as a foundation for broader AI initiatives.
Leave for later: Clinical decision support and complex appeal generation require much stronger governance because they directly influence clinical judgment. These use cases become appropriate only after organizations have established reliable AI operations and oversight.
As Erin Weber has noted, healthcare continues to evolve. The goal isn’t to automate everything immediately. It’s to build confidence by automating lower-risk workflows first, creating the foundation needed for more advanced use cases.
The Future Is About Work, Not Just Connectivity
Healthcare has spent decades solving interoperability. FHIR standardized how systems exchange healthcare data, including how that data can be updated. The remaining challenge isn’t simply connecting systems. It’s enabling AI agents to safely use the capabilities those systems already expose.
MCP helps solve this by giving AI agents a standard way to discover and use tools, whether those tools are FHIR APIs, middleware, or legacy applications. It doesn’t replace workflow engines, governance, or clinical judgment. Instead, it reduces the effort required to connect AI agents to the systems healthcare organizations already rely on.
Organizations that build this foundation won’t simply have better interoperability. They’ll make it far easier to deploy AI across their existing technology landscape, enabling automation to scale while maintaining the governance and human oversight that healthcare requires.
Take the SMART on FHIR Advisor Assessment to identify gaps in security, interoperability, and authorization before scaling AI-driven healthcare workflows.