FHIR vs HL7 vs MCP: Connecting AI Agents to Your EHR

By Jude Lee · · Custom

Office manager and IT consultant reviewing EHR integration options on a laptop in a small clinic back office

Why integration became the hard part

For two years the interesting question about AI in practices was “can the model do the task?” That question is mostly settled for admin work — drafting, summarizing, classifying, checking one record against another. The question now is whether the agent can reach your systems at all, what it is permitted to do once it’s there, and what you can prove afterward.

That’s a different engineering problem than the one most health IT plumbing was built for. Interfaces designed to move a known message between two known systems on a schedule behave differently when the requester is an agent that decides, at runtime, what to ask for. The permission model stops being “this feed carries these fields” and starts being “this actor may take these actions.” That is the gap worth your attention.

For an independent practice, the practical translation is simple: the demo always works. The connection is what you’re actually buying.

(g)(10)
ONC certification criterion requiring a standardized FHIR-based API in certified EHRs
ASTP/ONC Health IT Certification Program
270/271
HIPAA-standard eligibility inquiry and response transaction pair
CMS / ASC X12
BAA
Required with any vendor creating, receiving, or maintaining PHI on your behalf
HHS Office for Civil Rights

The four connection paths, in plain terms

HL7 v2 interfaces are the established plumbing — message feeds that push events (a new appointment, a lab result, an ADT update) from one system to another. They’re everywhere and they’re reliable, but they’re largely one-directional and brittle. An HL7 feed is great for telling an agent something happened. It is a poor way for an agent to ask a question or take an action. There’s also a cost reality that rarely shows up in technical comparisons: a new interface is usually a paid engagement with your EHR vendor or an integration-engine vendor, scheduled into their queue. Ask for the interface fee and the lead time in writing before you evaluate HL7 on merit. In our opinion, the binding constraint on this path is almost always the quote and the queue, not the standard.

FHIR APIs are the modern standard: structured, queryable resources (Patient, Appointment, Coverage, Encounter) over a normal web API. Under the ASTP/ONC Health IT Certification Program, certified EHRs are required to support a standardized FHIR-based API for patient and population services — the criterion usually referenced as §170.315(g)(10). Confirm the current requirements and your specific product’s certification at HealthIT.gov rather than taking a vendor’s word for it. In practice, “we support FHIR” and “you can get a production API key with write scopes in under a quarter” are very different statements. Ask about both.

MCP — the Model Context Protocol — is an open standard for exposing tools and data to an AI assistant in a governed way. It does not replace FHIR; it sits above it. You build (or buy) a small MCP server that defines a short list of named operations — get_tomorrows_schedule, check_eligibility, draft_recall_message — and the assistant can only do what those operations allow. MCP is published as a public specification and is supported by multiple major assistant vendors rather than tied to one; because adoption is moving quickly, check the specification site (modelcontextprotocol.io) for the current state as of 2026 rather than trusting a summary. We walk through an end-to-end version of this in connecting Claude to your EHR via MCP.

RPA / screen automation drives the user interface like a human would. It’s the only option for legacy systems with no API, and it is genuinely useful. It’s also the most fragile: a UI change breaks it silently. Our comparison of agents, RPA, and plain rules covers when each wins.

FHIR API versus a custom MCP server

Direct FHIR API integration
Best when one system holds the data and one developer owns the code. You write the queries, you control the payloads, there’s no extra layer to maintain. Downside: every new use case means new code, and the permission model is whatever your API scopes happen to allow — usually coarser than you want. An agent with a read scope can read everything in that scope.
Custom MCP server over your systems
Best when you want several AI workflows against the same systems, or when the data lives in three places (EHR, PM, clearinghouse, spreadsheet). You define a narrow menu of operations, each with its own minimum-necessary field list and its own audit log entry. Downside: it’s a component you now own, and a badly scoped MCP server is just a wide-open API with better branding.

Most small practices build neither themselves — a third path, buying a hosted integration layer, is covered at the end. The useful part of knowing the difference is that it changes the questions you ask: Which standard do you read from? What scopes do you request? Can you show me the list of actions the agent can take, and the log of actions it took last Tuesday?

An agent you cannot audit is not an automation — it’s an unsupervised employee with no timesheet.

A worked example: eligibility checks the day before

Say you want tomorrow’s schedule checked for coverage problems before patients arrive.

  1. Define the job narrowly

    One output: a list of tomorrow’s appointments flagged red (no active coverage), yellow (plan changed, needs a call), or green. Not “handle eligibility.”

  2. Decide the data path

    Appointments usually come from FHIR Appointment or a PM report; coverage status comes from your clearinghouse’s 270/271 transaction. Two sources, two integrations — this is where projects stall, so confirm access before anything else.

  3. Expose only what's needed

    Through MCP or a service account, the agent gets appointment time, patient ID, payer, member ID, and plan status. Not the chart. Minimum necessary isn’t a nicety; it’s how the HHS Office for Civil Rights frames the standard.

  4. Keep writes gated

    Start read-only. If the agent will eventually update coverage fields, decide the permission model deliberately — see read-only vs. approval vs. full auto.

  5. Name the failure modes before launch

    Two are specific to the agent, not the plumbing. First, misreading the 271: the response carries an active plan with a benefit-level caveat, and the agent flags it red — the front desk cancels a visit that was fine. Second, silent staleness: the clearinghouse times out, the agent falls back to the last cached status, and returns green on a terminated plan with no indication it never got a fresh answer. Catch the first by requiring every red and yellow flag to carry the raw payer response text next to it, so staff verify against the source, not the summary. Catch the second by requiring a response timestamp and payer trace number on every row — any row without one is treated as unchecked, not as green.

  6. Log, review, and set a stop rule

    Log every call and every flag, timestamped. Spot-check a sample weekly for the first month — and decide the threshold in advance, before you have a reason to rationalize. A reasonable approach: pick a miss rate you’d consider unacceptable for a human clerk doing the same task, and hold the agent to it. If the sample exceeds it, narrow the scope (one payer, one clinic day); if it still exceeds it after narrowing, revert to read-only suggestions a human re-runs; if the errors are unpredictable rather than patterned, kill the workflow. “Review” with no stop condition is decoration.

To size the value, don’t borrow anyone’s percentage. Use your own: (minutes per verification × verifications per day × working days) × loaded hourly rate, plus whatever you’d recover from the yellow-flag appointments that currently become write-offs, minus the time staff now spend verifying flagged rows. Plug in your real numbers. If the arithmetic doesn’t clear the integration cost in a year, that’s a legitimate answer.

What people are really asking when they ask for the “best” AI

There is no best AI for a medical practice, because “practice” isn’t one job. The honest decomposition: ambient documentation is a mature, well-served category; clinical reference tools and general assistants are for clinician research and should never be treated as diagnostic authorities; admin agents are where independent practices usually find the fastest payback. Our job-by-job buyer’s map splits these out properly. If you want a free starting point, a general assistant working on de-identified or synthetic data costs nothing and teaches you a lot about where your workflows are actually ambiguous — just don’t put PHI into any tool without a signed BAA and a documented review.

You’ll also see people cite a “30% rule for AI.” It isn’t a standard from any regulatory or standards body, and the versions floating around mean different things — leave 30% of a task to humans, expect 30% of output to need rework, start with 30% of volume. Treat it as folk wisdom, not a benchmark. The defensible version, stated as opinion: pilot on a slice of volume you can fully review, and only widen when your own error log says you should. The roles that hold up are the ones where the hard part is judgment, relationship, or accountability — a verification clerk’s keystrokes are automatable; knowing which rep at which payer actually answers is not.

How to choose without over-engineering it

Three paths, in rough order of how often they’re the right call. Use what you already have if your EHR ships a usable agent for the job and you’re not fighting it — that’s covered in agentic practice management: switch or layer. And if the job is deterministic (send a reminder 48 hours out), a rule in your existing software beats an agent on cost and predictability.

Buy a hosted integration layer when you want agentic workflows across systems but have no appetite to own a component. What to look for: which standard they read from and whether they’ll show you a live action log, not a screenshot; per-action permissions you can see and change without filing a ticket; and a clear statement of where inference runs and whether your data is retained. Then ask the question most buyers skip — who are their subcontractors, and does their BAA flow down to the model provider and any hosting layer that touches PHI? Under HHS Office for Civil Rights guidance, a business associate is responsible for its subcontractors; ask to see that chain in writing and have counsel confirm it covers the actual data path.

Build your own MCP layer when you have two or more AI workflows spanning systems nobody has connected, and you need per-action permissions and an audit trail you control. And whichever path you take: if a vendor can’t tell you which standard they read from or show you an action log, that’s your answer about whether the integration is real yet.

Not sure where to start?

Get a free automation audit: we map your scheduling, intake, insurance, billing, and patient communication and show you what's worth automating — before you spend a dollar.

Get a free automation audit

Related guides