Epic integration
Epic FHIR Integration
Epic exposes a FHIR R4 surface with SMART on FHIR launch for clinician-facing apps and backend services for unattended workflows. The app that launches inside Epic via SMART uses Epic's token to read and write Epic's FHIR endpoint, and a separate OAuth/OIDC token from the customer's identity provider to read and write Fire Arrow as its own backend. Fire Arrow itself does not implement the SMART app launch profile.
What you can build
- Standards-based connectivity to Epic
Epic-side: SMART on FHIR launch and FHIR R4 read/write through Epic's published API. No proprietary protocol required.
- Fire Arrow as the app's own FHIR backend
OAuth/OIDC against the customer's identity provider (typically Microsoft Entra ID), with rule-based authorization, GraphQL, and audit on every call. Fire Arrow does not implement SMART app launch.
- Per-environment configuration
Epic environments differ; client registration and scope assignments are handled per environment without changes to the Fire Arrow rules.
How it works
- 1 Register the app with Epic
App registration through Epic on FHIR; client id and SMART scopes assigned per environment.
- 2 User launches the app from Epic
Epic-triggered SMART launch hands the app a context (patient, encounter, user) and an Epic-scoped access token.
- 3 App reads patient context from Epic
Standard FHIR R4 reads against Epic's API with the Epic token, scoped by the SMART scopes the user granted.
- 4 App authenticates the user against Fire Arrow
Separate OAuth/OIDC flow against the customer's identity provider (typically Microsoft Entra ID). The resulting Fire Arrow token is independent of the Epic token and is bound by Fire Arrow's rule chain.
- 5 App reads and writes Fire Arrow
Outcomes, Tasks, Communications, and any other resources the product owns live in Fire Arrow. Standard FHIR REST or GraphQL on the Fire Arrow side.
Who this is for
Integration teams connecting their Fire Arrow-based product to Epic environments at hospitals or at Epic-hosted customers.
Two integration shapes
The clinician-facing pattern is a SMART on FHIR app that launches inside the Epic container. The launch is an Epic-side event: Epic authenticates the user, hands the app context (patient, encounter, user), and issues an Epic-scoped access token. The app uses that token against Epic's FHIR API. To talk to Fire Arrow, the same app authenticates the user against Fire Arrow's OAuth/OIDC provider (typically the customer's Entra ID tenant) and uses the resulting Fire Arrow token on every Fire Arrow call. Fire Arrow itself is not a SMART app endpoint; it is an OAuth-protected FHIR backend the app talks to alongside Epic.
The backend service pattern uses a SMART backend services flow on the Epic side: the integration registers as a backend client with Epic, gets a service identity, and reads or writes on a schedule or in response to events. The Fire Arrow side uses standard OAuth 2.0 / OIDC client credentials, an Entra ID service principal, or an admin-issued API token for the corresponding service identity. Both sides log the calls they served against the service identities they each authenticated.
Where Fire Arrow holds the data
Fire Arrow typically holds the app's own data: outcomes the app collects, custom Tasks and Communications the app generates, and any FHIR resources the app needs to query in shapes Epic does not natively expose. Epic remains the source of truth for the EHR-side data; Fire Arrow is the source of truth for the app-side data.
Synchronization patterns vary by use case. Some apps re-read from Epic on each launch; others cache key resources in Fire Arrow with a refresh schedule. Both fit the standard FHIR access model. The two access boundaries (Epic-side and Fire Arrow-side) are independent, which is also the boundary auditors expect: each FHIR server logs the access it served.
Related docs
FAQ
Do I need an Epic agreement?
App listing and connectivity require Epic's app program participation and per-customer agreement at the Epic site. The technical integration is FHIR R4 plus SMART on FHIR; the business relationship is between the app vendor and Epic and between the app vendor and the Epic customer.
What about EpicCare Link or Hyperspace integration?
Out of scope for FHIR integration. EpicCare Link and Hyperspace use Epic's own protocols; the FHIR API is the supported integration surface for third-party apps.
Can I write back to the Epic chart?
DocumentReference, Communication, and certain other resources are writeable to Epic in standard configurations; the exact set depends on the Epic version and the customer's enablement. Read access is broader than write access in most deployments.
How does Fire Arrow's authorization interact with Epic's?
Each side has its own authentication and authorization. Epic authenticates the user via SMART and issues an Epic token bound by SMART scopes. Fire Arrow authenticates the same user via the customer's OAuth/OIDC provider and issues its own token bound by Fire Arrow's rule chain. The two boundaries are independent on purpose: each FHIR server logs the access it served against the identity it resolved.
Does Fire Arrow accept the SMART access token Epic issues?
No. Fire Arrow only accepts tokens from its configured OAuth/OIDC provider. The Epic token is valid against Epic's FHIR endpoint; the Fire Arrow token is valid against Fire Arrow. The app holds both for the duration of the session.
