Epic's FHIR API is the most widely-supported integration surface in US healthcare. Seven patterns cover essentially all third-party integration work.
Pattern 1: SMART app registration and launch. Register app in Epic App Orchard; users launch via SMART on FHIR. Standard OAuth 2.0 flow.
Pattern 2: Patient context via launch. Epic launches app with patient=, encounter=, user= context. App reads these Patients via FHIR.
Pattern 3: US Core-conformant reads. Epic exposes US Core profiles for Patient, Encounter, Observation, Condition, MedicationRequest, and more.
Pattern 4: Bulk data export for population analytics. Epic supports Bulk Data IG $export for Groups and Patients.
Pattern 5: CDS Hooks integration. Third-party CDS services registered with Epic; fire at patient-view, order-select, order-sign.
Pattern 6: SMART Backend Services for system-scope access. Server-to-server integrations without user context. JWT assertion + client credentials.
Pattern 7: FHIR write via SDC extraction. SDC-based form results extracted into Observation, Condition; written back to Epic chart.
Common Epic integration mistakes
1. Assuming write access from day one — read/write scopes require Epic-side configuration. 2. Not registering CORS domains — SMART launch silently fails. 3. Testing against sandbox with different scopes than production. 4. Missing rate limit handling — Epic returns 429. 5. Skipping App Orchard security review — required for external distribution.
Epic FHIR API details
Epic's FHIR API supports R4 with US Core profiles. Documentation at fhir.epic.com. Sandbox for development; production requires signed App Orchard agreement.
Rate limits (typical production)
| Scope | Rate limit |
|---|---|
| patient/* | 60 req/min |
| user/* | 100 req/min |
| system/* | 1000 req/min |
| Bulk export | 1 concurrent |
Epic FHIR integration is well-defined but has vendor-specific quirks. Get through App Orchard once; then future integrations use the same pattern.