EHR Integration for AI Agents: Epic, Cerner, and FHIR, Explained

TL;DR

• The law guarantees the API exists. Getting activated at each health system is the slow part. The 21st Century Cures Act and ONC's certification rules require every certified US EHR to expose a FHIR R4 API with SMART on FHIR authorization. Epic, Oracle Health (Cerner), Meditech, athenahealth, eClinicalWorks, NextGen and AdvancedMD all do.
• Authorization at scale is the hard part. Every health system is its own tenant, with its own FHIR base URL, app activation, credentials, and granted scopes. For an agent vendor, that's a matrix of EHR vendor × health system × environment, and it grows with every customer you sign.
• Use SMART on FHIR user-context (delegated) authorization for anything a clinician would do. Save SMART Backend Services (system-level) for population jobs like bulk export. An agent that writes to a chart as a service account will struggle in a healthcare audit.
• Write-back is narrow and vendor-specific. Epic documents create operations for vitals, notes, allergies, problems and a few others. Medication orders go through CDS Hooks as unsigned orders a clinician must sign. Plan your agent's actions around what the API actually allows.
• Scalekit's position: the protocol is standardized, but the tenancy isn't. The engineering you should buy rather than build is the layer that discovers each server, binds tokens to the right audience, refreshes them on each vendor's schedule, enforces scope before every call, and logs every action against the clinician who authorized it.

Why EHR integration is the bottleneck for healthcare AI agents

Healthcare AI started with documentation. Ambient scribes were the first breakout category, at roughly $600M of 2025 spend according to Menlo Ventures. The next wave acts on the record: prior authorization, medication reconciliation, chart prep, care-gap closure, scheduling. Menlo put prior-auth spend growth at roughly 10x year over year.

Every one of those workflows starts with a call to the EHR, and in the US that mostly means Epic and Oracle Health. Epic runs 43.7% of US acute care hospitals, Oracle Health 21.9%, and Meditech 14.7%.

Once the demo is over, EHR work usually goes wrong in the same places:

• The agent works against the Epic sandbox, then fails against the first customer's production instance because the app was never activated there.
• Tokens expire mid-task, because each vendor handles lifetimes and refresh differently.
• The agent assumes it has scopes that the clinician or the server didn't actually grant.
• The first security questionnaire asks who performed each write, and the only answer is "our service account."

None of these are FHIR problems. They're authorization and tenancy problems, and that's what the rest of this guide covers.

FHIR in five minutes: what agent builders need to know

FHIR (Fast Healthcare Interoperability Resources) is HL7's REST standard for clinical data. Records are resources such as ^Patient, ^Encounter, ^Condition, ^Observation, ^{MedicationRequest}, ^{AllergyIntolerance}, ^{DocumentReference} and ^Appointment, served as JSON over HTTPS.

The four facts that matter for agents:

1. Build against FHIR R4 (4.0.1). R4 is the only version that matters in US production. R5 is trial-use and not required for certification. R6 is still in ballot.
2. US Core defines what "standard" means. Under ONC's HTI-1 rule, certified EHRs had to support US Core 6.1.0 (USCDI v3) and SMART App Launch 2.0.0 by December 31, 2025.
3. Reads are guaranteed; writes are not. The certified API criterion, 170.315(g)(10), mandates read, search and bulk export. Any write capability is the vendor's choice.
4. Every health system has its own FHIR base URL. There is no single "Epic API" endpoint. Each hospital's Epic instance is a separate server with its own configuration.

SMART on FHIR: the authorization layer every EHR supports

SMART on FHIR is HL7's authorization framework for clinical data, built on OAuth 2.0 and OpenID Connect. It's what turns "the EHR has an API" into "this app may read this patient's medications, on behalf of this clinician."

Discovery

SMART clients don't hardcode OAuth endpoints. They ask the FHIR server at ^{[fhir-base]/.well-known/smart-configuration} (older servers also publish them in the ^/metadata capability statement). The response lists the authorize and token URLs, supported scopes, PKCE methods and client authentication methods.

For agents, this means one integration pattern can work against any compliant server, if your auth layer discovers configuration per tenant rather than copying it from docs.

Launch types: standalone vs. EHR launch

Scopes (SMART v2)

SMART v2 scopes use the format ^{context/ResourceType.permissions}. Permissions are the letters c r u d s (create, read, update, delete, search), always in that order.

• ^{patient/MedicationRequest.rs}: read and search medication requests for the patient in context
• ^{user/Observation.rs?category=...|laboratory}: read lab observations the user can access
• ^{system/Patient.rs}: backend read with no user
• ^{openid fhirUser}: returns an ID token whose ^fhirUser claim identifies the actual Practitioner or Patient who authorized
• ^{offline_access}: a refresh token that outlives the user's session. The user is consenting specifically to persistence.

The (g)(10) criterion requires certified servers to support v1 and v2 syntax, category-level scopes for ^Condition and ^Observation, and per-resource patient choice.

The line that matters for agents: the server may grant fewer scopes than you requested, and the spec requires clients to inspect what was actually granted. An agent that assumes its full requested scope set will call tools that return 403.

Audience binding (^aud)

The authorize request must include ^aud, the FHIR base URL the token is for. A token granted for one hospital's server can't be replayed against another's. Oracle Health rejects requests without it.

In a multi-tenant agent, every token must stay bound to the ^iss/^aud that issued it. Never let a tool router pick "the Epic token" for a user who works at two health systems.

SMART Backend Services

Backend Services uses the OAuth ^{client_credentials} grant with a signed JWT client assertion (private_key_jwt, RS384 or ES384) against a pre-registered JWKS. The spec says access tokens "SHOULD NOT exceed 300" seconds and refresh tokens "SHOULD NOT be issued."

It's the right tool for ^$export jobs and population workflows. It's the wrong tool for an agent acting for a clinician, because the EHR's audit trail records the app and not the person.

Epic: what agent builders need to know

How app registration and activation work

• Register on Epic on FHIR. Registration issues a production and a non-production client ID. Sandbox sync takes about an hour.
• Once an app is marked ready for production, it can't be edited. Scope and redirect changes mean a new app record, so get them right first.
• Activation happens per health system. Each Epic customer searches your client ID, downloads the app, and must have signed the open.epic API Subscription Agreement. The client record then syncs to that organization's environments.
• Backend apps need keys per customer and per environment. Public keys or JWK Set URLs must be uploaded, and they must differ across customers and environments.
• Patient-facing apps with refresh tokens need a client secret per customer instance.
• Vendor Services and Showroom are commercial programs, not technical requirements. Vendor Services is a paid membership with extra documentation, a larger sandbox and Epic support. Showroom (launched January 2024) replaced the App Market and has Connection Hub, Toolbox and Workshop tiers.

What Epic's OAuth server supports

Epic's sandbox ^{smart-configuration} advertises:

• EHR and standalone launch
• Public, confidential-symmetric and confidential-asymmetric clients
• SMART v1 and v2 permissions, including offline access
• The ^{authorization_code}, ^{refresh_token}, ^{client_credentials}, JWT bearer and token exchange (RFC 8693) grants
• PKCE with S256

Individual customer instances can differ by Epic version and configuration, so discover per tenant.

What an agent can write to Epic

Epic doesn't publish a public FHIR rate limit that we could find. Treat limits as per-customer, and build for HTTP 429 with backoff.

Does Epic have an MCP server?

Not for third-party agents. Epic's agent strategy is on-platform: the Art (clinician), Emmie (patient) and Penny (revenue cycle) assistants announced in 2025, and Agent Factory, a no-code builder previewed at HIMSS26 with wider availability planned for 2027. The "Epic MCP servers" in community lists appear to be third-party wrappers over the FHIR API. Epic hasn't announced one.

For an independent agent vendor, the integration surface is still the certified FHIR API plus SMART, and your product has to work alongside Epic's own agents rather than through them.

Oracle Health (Cerner): what agent builders need to know

Oracle Health's Millennium platform documents its behavior more concretely than Epic does, and it's less forgiving.

• Registration is through Code Console, with a free CernerCare account. Confidential and system apps get a system account managed in Cerner Central.
• Provisioning is heavier than Epic's. The customer requests a tenant ID and files Service Requests to provision your app. Remote-hosted and customer-hosted customers differ, and there are regional production hosts for AU, CA and the UK.
• Access tokens last 570 seconds, about ten minutes.
• Refresh has rules. Refresh no more than once a minute. A refresh response does not include a new refresh token, so keep the original. ^{offline_access} tokens die after three months unused.
• ^aud is mandatory. Requests without it are rejected.
• Backend JWTs are signed with RS384 or ES384.
• Writes (create or update) are documented for ^{AllergyIntolerance}, ^Appointment, ^{Communication}, ^Condition, ^{DocumentReference}, ^Encounter, ^Immunization, ^{MedicationRequest}, ^Observation, ^Patient and others. Per-resource pages restrict which types are writable.
• Bulk export supports Group and Patient export. Throttling returns 429, and bulk jobs share production services.

Oracle is also building agents natively. Its Clinical AI Agent expanded to order creation, coding, dictation and chart review during 2026. We found no public MCP server for third-party agents.

Other EHRs at a glance

What FHIR doesn't cover

FHIR is the certified surface, not the whole integration. Production healthcare agents usually touch at least one of these:

• HL7 v2 feeds (ADT, ORU, SIU, MDM) are still the real-time event backbone inside hospitals. If your agent needs to react when a patient is admitted or a lab result lands, you'll likely depend on v2 feeds or vendor eventing rather than FHIR polling.
• CDS Hooks puts an agent's suggestion inside the clinician's workflow (^patient-view, ^order-select, ^order-sign) as cards and unsigned orders.
• Proprietary APIs (Epic private APIs, athenaOne, NextGen Enterprise) go deeper, but they're ordinary platform APIs with ordinary platform risk. Build your core data path on the certified surface.
• Integration networks and aggregators such as Redox, Health Gorilla and Particle Health normalize many EHRs behind one contract. They're data and network layers, and many teams use them alongside an agent authorization layer.
• TEFCA has 11 designated networks (QHINs), including Epic Nexus and Oracle Health Information Network. Exchange is still mostly C-CDA documents, and the FHIR roadmap runs through 2027.
• Payer APIs. CMS-0057-F requires payers to stand up FHIR Prior Authorization APIs by January 1, 2027. Until then, prior-auth agents also need portals, fax and X12.

The eight problems specific to AI agents on EHRs

These are what separate an agent that demos from one that passes a hospital go-live.

1. The credential matrix

Every combination of EHR vendor × health system × environment has its own base URL, client registration, activation state, keys, and granted scopes. Ten health-system customers, each with production and non-production, is already 20 configurations before you count individual users, and more when customers run different EHRs. This is the core reason a managed authorization layer exists.

2. Token lifetimes differ by vendor

A long-running agent (a prior-auth chase that spans days, say) needs per-vendor refresh scheduling and must handle ^{invalid_grant} by prompting the user to re-authorize, not by failing silently. More on this in token refresh for long-running agents.

3. Granted ≠ requested

Patients can deselect resource types, and servers can down-scope. Your agent's tool list should be built from the granted scope string, not the requested one.

4. Audience binding across tenants

A clinician who works at two health systems has two tokens bound to two audiences. The tool router must resolve the tenant first, then the token.

5. Revocation within the hour

HTI-1 requires certified EHRs to be able to revoke an app's access within one hour. Agents must tolerate mid-task revocation and fail closed.

6. Write-back needs a human gate

Writes are narrow, and orders go through unsigned CDS Hooks suggestions. Beyond that, health systems often require clinical review before enabling note or observation write-back. Design approval gates in from the start. Our human-in-the-loop tool calling guide covers the queue-then-execute pattern and why the credential valid when a call pauses may not be valid when it resumes.

7. Patient matching

Agents running with backend or system context don't get a patient from launch context. They have to resolve identity via ^{Patient.$match}, identifier search, or network record locators. A mismatch is a patient-safety issue and a HIPAA issue.

8. Attribution

With ^system/ tokens, the EHR's audit log shows the app. With ^user/ tokens, it shows the clinician. The HIPAA Security Rule's audit controls standard (45 CFR 164.312(b)) is why the second passes review and the first stalls it. We covered this in detail in why a service account fails a healthcare audit.

Our take: delegated by default, system-level by exception

The pattern we recommend, and the one we built Scalekit's SMART on FHIR support around:

1. Use user-context SMART on FHIR for anything a person would do. Reading a chart, drafting a note, updating an allergy, checking medications. The agent acts with the clinician's scopes, and every action is attributable to them via ^fhirUser.
2. Use Backend Services only for population work. Bulk export to warm a governed store, quality measures, nightly cohort refreshes. Keep these jobs separate from the interactive agent, with their own credentials.
3. Treat write-back as an approval-gated capability. Separate read tools from write tools, and expose write tools only to the agent configurations and roles that need them.
4. Keep PHI out of the auth layer. The layer that brokers tool calls should process request and response payloads in memory and log metadata only: who authorized, which agent, which tool, which scope, status, latency.
5. Discover everything per tenant. No hardcoded endpoints, no shared tokens across audiences.

The protocol is standardized. The tenancy, lifecycle and attribution aren't, and that's where teams lose quarters.

Reference architecture: an agent tool call against an EHR

How Scalekit handles EHR integration

Scalekit AgentKit is the authorization and tool-calling layer between your agent and the EHR. You keep your backend and your agent; we handle auth, access and audit in the path.

• Generic SMART on FHIR connector. Point it at any EHR's FHIR base URL. Scalekit reads the server's published configuration and sets up the authorize URL, token URL and ^aud for you. It ships with tools for patient records (including ^$everything), medication requests, allergies, care plans, goals, diagnostic reports and immunizations.
• Pre-built AdvancedMD connector mapped to AdvancedMD's FHIR API.
• Delegated by default. Every tool call runs as the clinician or patient who authorized it, never a shared service account. Connected accounts can be created mid-session, when the agent first needs access.
• Scoped before every call. Requests outside the user's granted scopes never reach the EHR. Virtual MCP Servers let you give a read-only chart-prep agent a different tool surface from a write-back agent, whose write tools your application can put behind an approval step. Scalekit holds the credential state while a call waits.
• PHI stays out of Scalekit. Tool-call payloads are processed in memory and never written to disk. Credentials are AES-256 encrypted with a per-customer key, and you can bring your own key from your own KMS.
• Metadata-only audit logs, streamed to Datadog, Splunk or any SIEM.
• Deploy where the data must stay: our cloud with a signed BAA, your VPC, your customer's infrastructure, or air-gapped.
• Compliance: SOC 2 Type II, ISO 27001, HIPAA BAA on Enterprise.

What we don't do: Scalekit supports standalone launch, the agent-initiated flow most agent products use. EHR launch from inside the hospital's UI isn't currently covered. We also don't normalize FHIR payloads into a proprietary schema, because agents reason better on the native resource structure.

For the wider build (BAAs, PHI data paths, the security review), see the Healthcare AI Agent Builder's Guide. For deployment inside a customer's boundary, see Self-Hosted Agent Infrastructure for Healthcare.

Frequently asked questions

Does Epic have a public API for AI agents?

Yes. Epic exposes a certified FHIR R4 API with SMART on FHIR authorization, as federal certification rules require. You register on Epic on FHIR, and each health system activates your app in its own environment. There is no single production endpoint: every Epic customer has its own FHIR base URL.

Can an AI agent write data back to Epic?

Partly. Epic documents create operations for vital-sign Observations, clinical notes (DocumentReference), AllergyIntolerance, Condition, QuestionnaireResponse and a few others. New medication orders are created as unsigned orders through CDS Hooks for a clinician to sign. Delete is generally unavailable.

What's the difference between FHIR and SMART on FHIR?

FHIR is the data standard: resources like Patient and Observation over a REST API. SMART on FHIR is the authorization framework on top of it: OAuth 2.0 with endpoint discovery, audience-bound tokens, a clinical scope grammar like ^{patient/MedicationRequest.rs}, and the ^fhirUser identity claim.

Should my agent use SMART Backend Services or user-context SMART on FHIR?

Use user-context SMART on FHIR when the agent acts for a clinician or patient, so every action is attributable to that person. Use Backend Services for population jobs like bulk export, where no user is present. An agent that writes to charts with backend credentials will struggle in a HIPAA audit, because the EHR records only the app.

How long do Oracle Health (Cerner) access tokens last?

570 seconds. Oracle Health allows a refresh at most once a minute, doesn't rotate the refresh token on refresh, and expires offline refresh tokens after three months of non-use.

Does Epic support MCP?

Epic hasn't announced a public MCP server for third-party agents. Its agent strategy is on-platform (Art, Emmie, Penny, and Agent Factory). Third-party agents integrate through the certified FHIR API and SMART on FHIR. "Epic MCP servers" in community lists appear to be third-party wrappers.

Is EHR API access for AI agents protected by law?

Yes, for the certified API surface. The 21st Century Cures Act's information-blocking provisions allow penalties of up to $1M per violation against EHR developers and networks. ONC's HTI-5 proposal (not final) would add automated access, including autonomous AI systems, to the definitions of access and use, and ONC FAQs say interference with agentic AI can count as information blocking.

Do I need Redox or Health Gorilla if I use SMART on FHIR directly?

Not necessarily. Aggregators help when you need many EHRs behind one contract, HL7 v2 feeds, or network-sourced records. Direct SMART on FHIR is enough when you're connecting to specific health systems' certified APIs. Many teams use both: a network for data aggregation and an authorization layer for per-user agent actions.