EHR integration
Last reviewed: 2026-06-28 — see the freshness policy.
Learning objectives
After this chapter you will be able to:
- Map the ways to integrate with an EHR and choose the right one per use case.
- Describe how Epic and Oracle Health (Cerner) expose data and apps.
- Design an EHR integration that respects the vendor's model and the clinical workflow.
The EHR is the center of gravity
In provider settings, the EHR (Epic, Oracle Health/Cerner, MEDITECH) is the system of record and the clinician's primary workspace. Almost every provider-facing solution must integrate with it. The architecture question is how — the options range from real-time messaging to modern APIs to launching inside the EHR itself, and the right choice depends on whether you are reading, writing, or embedding.
flowchart LR
subgraph EHR["EHR (Epic / Oracle Health)"]
DB["System of record"]
end
DB -->|"HL7v2 (MLLP)"| Eng["Interface engine"]
DB -->|"FHIR R4 API"| API["App / analytics"]
DB -->|"Bulk $export"| Lake["Analytics lakehouse"]
EHR -->|"SMART launch"| App["Embedded app"]
App -->|"CDS Hooks"| EHR
The integration options
| Mechanism | Use it for | Notes |
|---|---|---|
| HL7v2 over MLLP | Real-time events (ADT, ORU, ORM) | The operational backbone; via an interface engine. See HL7v2. |
| FHIR R4 API | App reads/writes, patient access | Mandated for certified EHRs (ONC § 170.315(g)(10)). See FHIR. |
Bulk Data $export |
Analytics / population extracts | Async NDJSON to object storage; feed the lakehouse. |
| SMART on FHIR launch | Embedding an app in the EHR | OAuth2 + launch context. See SMART on FHIR. |
| CDS Hooks | In-workflow decision support | EHR fires a hook at a clinical event; your service returns a card. |
| Vendor app program | Distribution + deeper access | Epic and Oracle Health run app marketplaces with their own onboarding. |
Epic and Oracle Health specifics
- Epic exposes a large FHIR R4 API and supports SMART on FHIR and CDS Hooks; third-party apps are distributed via Epic's app program (Showroom/Connection Hub) and often need patient or health-system authorization. Many Epic deployments run on Azure (relevant for co-locating your integration — see Azure for HLS).
- Oracle Health (Cerner) similarly exposes FHIR and SMART on FHIR via its developer program (code console).
- Both still emit HL7v2 for real-time downstream feeds — modern API access and legacy messaging coexist; you will usually use both.
Design guidance
- Read vs write vs embed. Reading population data → Bulk
$export. Real-time reaction to events → HL7v2/FHIR Subscriptions. Acting in the clinician's flow → SMART launch + CDS Hooks. Pick the mechanism that matches the interaction, not the newest one. - Respect the workflow. Adoption fails if clinicians must leave the EHR. Prefer SMART/CDS Hooks for clinician-facing features.
- Authorization is per-vendor and per-health-system. Plan for the EHR's app-onboarding and the health system's approval — these are lead-time items, not afterthoughts.
- Least-privilege scopes and full audit (HIPAA) on every integration.
This chapter covers point-to-point integration with one EHR you have a direct relationship with. For sharing data among many unaffiliated organizations at once, see HIE architecture — a different, hub-based design.
Lab
hls-fhir-interop covers HL7v2→FHIR ingestion and a SMART on FHIR app — the two most common EHR-integration patterns.
Check yourself
- You need to react in real time to patient admissions and also extract a nightly population dataset. Which two mechanisms fit, and why not use one for both?
- Why are SMART on FHIR and CDS Hooks preferred for clinician-facing features over a standalone app?
- What lead-time items does EHR integration introduce beyond writing code?