The Core Buyer Question: What Should We Build Around?
If you are a Series A–C digital health founder or a CTO inside a healthcare IT vendor, the question is rarely academic. It’s operational:
- How do we integrate with Epic, Oracle Health (Cerner), or PointClickCare quickly?
- How do we stay aligned with ONC Certified API requirements?
- How do we support event-driven clinical workflows, longitudinal data access, and analytics?
Most organizations face a hybrid reality. Their customers run legacy interfaces based on HL7v2 (ADT, ORM, ORU). At the same time, regulatory and ecosystem forces—from the 21st Century Cures Act to ONC’s API Conditions of Certification—prioritize standardized FHIR-based APIs.
The practical decision is not “either/or.” It’s architectural positioning.
Protocol Philosophy: Message Bus vs Resource API
HL7v2: Event-Centric Messaging
HL7v2 is a pipe-delimited messaging standard dating to the late 1980s. It is:
- Transport-oriented (MLLP over TCP common in hospital networks)
- Event-driven (ADT^A01, ORM^O01, ORU^R01)
- Loosely specified, locally profiled
When an admission occurs in Epic, an ADT message is emitted. When a lab result finalizes, an ORU is sent. Downstream systems subscribe and update their records.
This works extremely well for near–real-time intra-enterprise workflows.
FHIR: Resource-Centric APIs
FHIR R4 defines structured resources like Patient, Observation, Encounter, and MedicationRequest exposed over RESTful APIs. It supports:
- HTTP(S) + OAuth2 / SMART on FHIR
- JSON or XML representations
- Search parameters (_lastUpdated, patient, category)
- Subscriptions for event notifications
Rather than pushing events, FHIR enables clients to query a patient’s longitudinal record across resource types.
Four Architectural Approaches
| Approach | Primary Standard | Best For |
|---|---|---|
| Hospital Interface Engine Model | HL7v2 | ADT feeds, lab routing, billing triggers |
| SMART on FHIR App | FHIR R4 | In-EHR apps, patient data access, CDS |
| FHIR Data Platform | FHIR R4 + Bulk Data | Analytics, risk scoring, quality reporting |
| Hybrid Canonical Layer | HL7v2 → FHIR normalization | Enterprise interoperability, vendor-agnostic scaling |
1. HL7v2-Centric Integration
Typical inside acute hospitals. An interface engine (Rhapsody, Cloverleaf, Mirth Connect) routes ADT, ORM, and ORU messages. Mapping is custom, often site-specific. Segment-level transformations (PID, PV1, OBX) are maintained per trading partner.
Strength: Mature, ubiquitous, low-latency.
Limitation: Semantic inconsistency and heavy maintenance burden.
2. SMART on FHIR App Model
Apps authenticate via OAuth2 against Epic or Oracle Health FHIR endpoints. They request scopes (patient/*.read), retrieve resources like:
- GET /Patient/{id}
- GET /Observation?patient=123&category=laboratory
- GET /MedicationRequest?patient=123&status=active
This model aligns directly with ONC’s standardized API requirements under 45 CFR §170.315(g)(10).
Strength: Standards-aligned, scalable, portable.
Limitation: Performance constraints and variable implementation depth across EHR vendors.
3. FHIR-Based Data Platform
Organizations ingest clinical data via Bulk FHIR ($export) for population-level processing. Data is normalized into canonical FHIR resources and stored in a FHIR server (HAPI, Azure API for FHIR, Google Cloud Healthcare API).
Used for:
- Care gap analytics
- Risk adjustment modeling
- Quality measure calculation (eCQMs)
4. Hybrid Canonical Layer (Most Common at Scale)
HL7v2 messages are ingested, parsed, and transformed into FHIR resources internally. For example:
- ADT^A01 → Patient + Encounter
- ORU^R01 → Observation
- ORM^O01 → ServiceRequest or MedicationRequest
This creates a vendor-neutral canonical layer while preserving compatibility with legacy production feeds.
Operational Reality Across Major EMRs
Epic: Robust SMART on FHIR marketplace; production-grade ADT feeds remain HL7v2.
Oracle Health (Cerner): Early public FHIR adoption; Millennium still heavily HL7v2 for core messaging.
PointClickCare: Strong API ecosystem, but long-term care integrations frequently blend flat files and HL7v2.
Compliance and Regulatory Alignment
The 21st Century Cures Act and ONC’s Cures Final Rule require certified EHRs to support standardized APIs “without special effort.” In practice, this means FHIR R4-based APIs for patient and population services.
Checkpoint considerations:
- SMART Backend Services authorization for system-level access
- AuditEvent logging for traceability
- US Core Implementation Guide conformance
- Information blocking compliance documentation
HL7v2 alone does not satisfy modern ONC API certification requirements. It remains operational infrastructure—not a regulatory hedge.
Decision Framework for Founders and CTOs
- Map Your Primary Workflow Determine whether you are reacting to real-time enterprise events (admissions, orders, results) or querying longitudinal patient data.
- Assess Customer Environment Identify which feeds are readily available today: ADT over MLLP, FHIR R4 endpoints, or both.
- Design Your Canonical Model Use FHIR resources internally whenever feasible to future-proof analytics and API layers.
- Plan for Write-Back Early If you need to create MedicationRequest or DocumentReference resources, validate production permissions—not just read APIs.
- Align With ONC and US Core Ensure your integration meets regulatory expectations to avoid late-stage enterprise security reviews failing.
Frequently Asked Questions
Need Help With Your Integration Strategy?
AST builds production-grade FHIR interfaces, EMR integrations, and clinical AI systems.
