How AI Agents Integrate with EHR Systems: AI Agent EHR Integration Guide (2026)

Short answer: AI agents integrate with EHR systems through three main routes: FHIR APIs for reading and writing chart data, HL7 v2 feeds for events such as admissions and results, and CDS Hooks with SMART on FHIR for help inside the clinician's screen. The agent never calls these directly. It calls a small set of approved tools, and separate software handles login, permissions, patient checks, human approval and the audit record.

Updated October 2026. Standards and vendor documents were read on 30 October 2026.

This guide is for the engineering lead or integration architect sizing an AI agent EHR integration. If you want a team to build it with you, see our custom AI agents for healthcare. If the EHR has no API for the step you need, our guide to EHR automation without API access covers that case, so this one stays on API and interface routes.

How do healthcare AI agents integrate with EHRs? Three routes compared

Healthcare AI agents integrate with EHRs by reading through FHIR, reacting to HL7 v2 or FHIR events, and appearing in the chart through CDS Hooks or a SMART app. Choose by what starts the work and where the person who needs the answer is sitting.

EHR integrated AI agents can use more than one. A discharge follow-up agent might start from an HL7 v2 ADT message, read the Encounter through FHIR, and show its proposed outreach to a care manager in a SMART app. Build the route the first workflow needs and leave the others until a second workflow asks for them.

What does AI agent EHR integration include beyond the API call?

A working integration has five layers between the model and the record: tools, policy checks, an EHR adapter per vendor, human approval and an audit trail. Healthcare agent data integration is the smallest part of the job, and these other layers are what a hospital's security team will ask about when it reviews EHR integration agents.

The tool definition below is illustrative. This one can only propose work, so a bad model decision produces a bad suggestion in a queue and leaves the chart unchanged.

{
  "name": "propose_followup_task",
  "description": "Propose a follow-up task for a care manager. Does not write to the EHR.",
  "input_schema": {
    "type": "object",
    "properties": {
      "encounter_id": {"type": "string"},
      "reason": {"type": "string"}
    },
    "required": ["encounter_id", "reason"]
  }
}

The Model Context Protocol (MCP) is one way to expose tools like this. It is a general open protocol for connecting AI applications to tools, it is not an HL7 standard, and its 25 November 2025 specification says the protocol itself cannot enforce its security principles. Your policy layer still has to do that. Our Agent on FHIR guide goes further into the tool-calling loop.

How do healthcare AI agents connect to FHIR data?

Healthcare AI agents connect to FHIR data through a server-side client that gets a short-lived token, then reads or searches only the resources its approved scopes allow. Use SMART Backend Services when no person is signed in, and a SMART app launch when the agent acts in a clinician's session.

The Backend Services specification and its client authentication page settle these details:

• The server should not issue a refresh token. The client signs a new assertion when it needs a new access token.
• The recommended expires_in is 300 seconds, and the spec says it should not go higher. Plan for five-minute tokens, and read the actual value from each response.
• Clients have to support both RS384 and ES384 signing. A server has to validate at least one of them.
• The assertion's exp can be at most five minutes ahead, and each jti is one use only, so a replayed assertion gets rejected.
• The scopes you get back can differ from the scopes you asked for. Check the response before the agent assumes it can do something.

Scope spelling also varies. SMART 2 uses forms like system/Patient.rs, while Oracle Health's Millennium R4 documentation lists both patient/Observation.read and system/Observation.crs. Take the exact strings from the target server. For the failures we would test first, read SMART on FHIR authentication: 6 things that break.

# fhir_client.py: illustrative SMART Backend Services client an agent's tools call
import requests, jwt, time, uuid

class FHIRClient:
    def __init__(self, base_url, client_id, private_key, kid, scope):
        self.base, self.client_id = base_url, client_id
        self.pk, self.kid, self.scope = private_key, kid, scope
        self.token, self.token_exp = None, 0

    def _assertion(self, token_url):
        now = int(time.time())
        return jwt.encode({
            "iss": self.client_id, "sub": self.client_id, "aud": token_url,
            "exp": now + 240,            # the spec allows at most five minutes
            "jti": str(uuid.uuid4()),    # one use only
        }, self.pk, algorithm="RS384", headers={"kid": self.kid})

    def _new_token(self):
        # Backend Services issues no refresh token, so sign a new assertion each time.
        cfg = requests.get(f"{self.base}/.well-known/smart-configuration",
                           headers={"Accept": "application/json"}, timeout=10).json()
        r = requests.post(cfg["token_endpoint"], timeout=10, data={
            "grant_type": "client_credentials",
            "scope": self.scope,         # only what was approved, for example "system/Patient.rs"
            "client_assertion_type": "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
            "client_assertion": self._assertion(cfg["token_endpoint"]),
        })
        r.raise_for_status()
        body = r.json()
        self.token = body["access_token"]
        self.token_exp = time.time() + body.get("expires_in", 300) - 30

    def call(self, method, path, **kw):
        if time.time() >= self.token_exp:
            self._new_token()
        headers = kw.pop("headers", {})
        headers.update({"Authorization": f"Bearer {self.token}",
                        "Accept": "application/fhir+json"})
        return requests.request(method, f"{self.base}/{path}", headers=headers, timeout=30, **kw)

This skeleton is small on purpose. Production code adds backoff on 429 responses, paging through the next link in search bundles, redacted logs, and a limit on token retries. The planner never touches this client. It only calls named tools that wrap it.

Which FHIR resources should each agent read?

Start from the workflow and request the fewest resources it needs, because HIPAA's minimum necessary standard asks for reasonable efforts to limit PHI to the intended purpose. These are starting points to test against the target server.

Can an AI agent write to an EHR?

Yes, where the vendor exposes that write, your app is approved for it, and the customer has turned it on. Read access is much more dependable, because the ONC (g)(10) certification criterion covers responding to read and search requests for patient data and does not require create or update.

So a certified FHIR API tells you little about writes. Epic's API catalog names write interactions such as Observation.Create and AllergyIntolerance.Create, and Oracle Health documents each interaction per resource. athenahealth has separate certified FHIR and athenaOne APIs, so check its developer portal to see which family carries the booking or document step you need. Before you design a write, check three things on the target system: the server's CapabilityStatement at /metadata, the scopes granted to your app, and a test in that customer's non-production environment.

Our Epic workflow integration page covers the Epic-specific path. If the write does not exist, send the result to a work queue, or see the no-API guide linked above.

Two details in that flow need extra care. Retries can create duplicates after a timeout, so use a conditional create where the server supports it, or check for your own identifier before you send again. A 200 or 201 response also does not prove the record shows up where staff work, so read it back, and have someone check the receiving screen during the pilot.

How do HL7 v2 feeds and FHIR events start an agent?

An interface engine such as Mirth Connect or Rhapsody routes messages like ADT, ORM, ORU and SIU to your service, which queues them and starts the agent. Many hospitals already run these feeds, so ask for this route early.

HL7 v2 can also carry data back into the EHR, for example results or documents. There is no general-purpose write API here, though. Each inbound interface has to be agreed, mapped and tested with the site's team. Acknowledge the message and queue it first, then run the agent, so a slow model cannot hold up the interface. We have delivered 350+ Mirth Connect interfaces, and each site's message mapping has to be confirmed before the agent relies on it.

FHIR Subscriptions are the API alternative. Topic-based subscriptions are in the core of FHIR R5, and R4 servers can adopt a subset through the Subscriptions Backport guide. Support varies, and the spec says channel support cannot be found through the CapabilityStatement, so ask the vendor directly.

How do EHR platforms incorporate AI in clinical workflows?

Inside the clinical workflow, the usual standards route is CDS Hooks: the EHR calls your service at a set point, and your service returns cards. The CDS Hooks 2.0 specification says services should respond on the order of 500 ms, which rules out a long agent loop inside the hook.

So prepare the answer ahead of time, or return a quick card and let a background agent do the rest. The spec defines hooks such as patient-view, order-select, order-sign, appointment-book, encounter-start and encounter-discharge, but it does not require any set of hooks, so confirm what your EHR fires. A card's suggestion can carry a create, update or delete action on a FHIR resource, and the clinician chooses whether to accept it. A card can also link to a SMART app for work that needs a full screen, such as reviewing a drafted note.

How do voice, call center, referral and claims agents connect?

These agents use the same routes with different tools, and the main difference is where the data sits outside the EHR.

How does a voice agent AI platform integrate with Epic, athenahealth, or other major EHRs?

A voice agent turns the call into tool calls: find the patient, list open slots, book or change the appointment. Patient lookup and slot reads may work through FHIR. Booking often needs a vendor-specific API, so confirm that step for each EHR first. Confirm identity before the agent reads anything back to a caller.

What does agent consoles EHR integration involve?

In a call center, the agent console is the screen staff use. EHR integration there usually means reading patient and appointment details by caller match and showing them to staff, so an AI agent or a person handles the call with the same context. Log every lookup, since browsing a console is still access to PHI.

How to integrate AI referral tools with existing EHR systems

Treat the referral order as the trigger, read the order and coverage, draft the packet, and put it in a staff queue. Writing the status back is the step to confirm per EHR. Keep the queue as the fallback.

How do I build a production-ready AI agent that can query EHR and claims data?

Give the agent separate read tools for each source, because claims usually live outside the EHR, in a billing system, clearinghouse or data warehouse. Match patients with a tested rule, keep both sources read-only at first, and log which source supplied each fact. Fields, dates and identifiers will differ, so test the match on real workflows before anyone relies on the answer. If the agent checks eligibility or claim status, it will often go through X12 270/271 or 276/277 transactions.

How do you connect an EHR agent without disrupting operations?

Run the agent read-only beside the current process, compare its output with what staff did, and add writes one action at a time. Staff keep working as they do now during that period, so a wrong answer costs a review and leaves the chart alone.

This is also how you add AI features to an existing EHR without rebuilding it: the EHR stays the system of record, and the agent sits beside it behind the same permissions model.

How can healthcare AI agents securely access EHR data through APIs?

Give each agent its own client identity, narrow scopes, short-lived tokens and a full audit record, and put a business associate agreement (BAA) in place with every service that sees PHI, including the model provider. The HIPAA Security Rule asks for audit controls and authentication of the person or entity seeking access, which applies to a software agent as well.

Treat text in the chart as untrusted input too. A note or faxed document can contain instructions, so the model should never decide alone what a tool may do. Our guide to building HIPAA compliant AI agents covers the BAA chain, data boundaries and security review in full.

Should you buy an agent platform with pre-built EHR integrations or build your own?

Buy when a product already covers your workflow and EHR. Build when the workflow is what makes your product different, or when you have to control the data path. Lists of the best healthtech platforms with agent-ready integration for EHRs change quickly, so test each claim with the questions in the table.

What agentic AI platforms for health systems have pre-built EHR integrations?

Several agent platforms advertise pre-built EHR connectors, and EHR vendors are adding their own AI features. Ask which of those connectors write, and on which EHR versions, because a connector can be read-only.

Where can health systems buy call center AI agents that integrate with their EHR?

Start with your EHR vendor's developer or partner program and your contact center vendor, then healthcare voice agent vendors. Ask each one to show the booking step working against your EHR version.

If you are building, our EHR integration services team helps with the interfaces and approval work.

What we can show for this work

You can check most of this yourself. We are ISO 27001:2022 certified and we sign BAAs. Our SMART on FHIR app demo runs against the Epic and Oracle Health developer sandboxes, which are sandbox results and do not show a customer production go-live. Our open-source headless EHR passed 47 of 47 ONC (g)(10) SMART App Launch standalone patient app tests on 27 October 2026. That is the SMART group only, and not a full (g)(10) result. We also publish open-source Da Vinci CRD, DTR and PAS servers tested with Inferno, the kind of prior authorization service an agent would call. Anonymized agent work is on our AI agent page.

Where to start

Pick one workflow, name the person who reviews the result, and check the target EHR's CapabilityStatement before you estimate anything. To go through it with us, send the EHR, the workflow and the step you are unsure of to our healthcare AI agent team, and we will tell you which route fits and where the write risk sits.