Most production healthcare systems use both FHIR R4 and HL7 v2. They are not competing standards where you choose one and discard the other. They serve different purposes, have different strengths, and in most real-world integration projects, you will encounter both. Understanding when each standard applies is fundamental to building healthcare integrations that work in production.
What HL7 v2 Is and Why It Still Matters
HL7 v2 (version 2) is the dominant healthcare messaging standard. It was introduced in 1987 and has gone through multiple revisions (v2.1 through v2.9), with v2.5.1 being the most widely deployed version today. If you have ever seen a healthcare data integration project involving an older hospital system, you have almost certainly worked with HL7 v2 messages.
HL7 v2 uses a pipe-delimited text format. A message looks like this at its simplest:
MSH|^~\&|SendingApp|SendingFacility|ReceivingApp|ReceivingFacility|20260115120000||ADT^A01|MSG00001|P|2.5.1 PID|||123456^^^Hospital^MR||Smith^John^M||19800115|M
Each segment (MSH, PID, etc.) contains specific data fields separated by pipe characters. The format is compact and widely supported by legacy systems. Essentially every EHR, LIS, RIS, and hospital information system built before 2015 communicates via HL7 v2.
Common HL7 v2 Message Types
- ADT (Admit-Discharge-Transfer): Patient registration, admission, discharge, transfer, and demographic updates. ADT A01 (admit), A08 (update patient information), and A11 (cancel admission) are the most common.
- ORM/ORU (Orders and Results): Lab orders, radiology orders, and their results. This is the primary message type for lab result integration.
- MDM (Medical Document Management): Clinical document exchange, including transcription results and clinical notes.
- SIU (Scheduling Information Unsolicited): Appointment scheduling events.
- DFT (Detailed Financial Transaction): Billing and financial transaction data.
What FHIR R4 Is and Why It Matters
FHIR (Fast Healthcare Interoperability Resources) R4 was published by HL7 International in 2019 and became the required standard for ONC-certified EHR APIs in 2022. FHIR R4 represents a fundamentally different approach to healthcare data exchange: instead of messages that describe events, FHIR defines resources that represent clinical concepts.
A FHIR resource is a JSON or XML document representing a patient, observation, medication, encounter, or other clinical entity. REST APIs expose these resources through standard HTTP methods (GET, POST, PUT, DELETE). This makes FHIR integrations more accessible to developers familiar with modern API patterns.
Core FHIR R4 Resources Used in Production
- Patient: Patient demographics and identifiers
- Encounter: A clinical visit or hospitalization
- Condition: Diagnoses and problems
- Observation: Lab results, vital signs, assessment responses
- MedicationRequest: Medication orders
- DocumentReference: Clinical documents including clinical notes
- DiagnosticReport: Structured diagnostic results
- Appointment: Scheduling data
- ServiceRequest: Orders for services or referrals
When to Use HL7 v2
Use HL7 v2 when:
Integrating with Legacy Systems That Do Not Have FHIR APIs
Many hospital systems, laboratory systems, and ancillary clinical systems communicate only via HL7 v2. If the source or destination system does not have a FHIR API, you integrate via HL7 v2 or not at all. This is the most common reason HL7 v2 remains in active use: the other system simply does not support FHIR.
Real-Time Event Notifications
HL7 v2 ADT feeds push notifications when patient events occur: admission, discharge, transfer, registration update. These are true event-driven feeds that notify downstream systems immediately when something happens. FHIR has FHIR Subscriptions as the equivalent mechanism, but many EHR vendors have more mature and reliable HL7 v2 ADT feeds than FHIR Subscription implementations.
Lab Results Interfaces
Laboratory information systems (LIS) predominantly communicate via HL7 v2 ORU messages. While FHIR DiagnosticReport covers similar ground, most LIS systems in production today use HL7 v2 for result delivery to EHRs and downstream systems.
When the Integration Team Has HL7 v2 Expertise
HL7 v2 has more integration engineers with production experience than FHIR. For point-to-point integration projects where the goal is to get data from A to B reliably, a team with deep HL7 v2 expertise is often faster and more reliable than a team building their first FHIR integration.
When to Use FHIR R4
Use FHIR R4 when:
Integrating with ONC-Certified EHR APIs
Epic, Cerner, Athenahealth, and other ONC-certified EHRs are required to expose FHIR R4 APIs for patient data access. This is the intended integration mechanism for third-party applications connecting to modern EHR platforms.
Building Patient-Facing Applications
SMART on FHIR, which uses FHIR R4 with OAuth 2.0, is the standard framework for patient-facing and provider-facing applications that launch within or connect to EHR platforms. If you are building an app that needs to access patient data in context within the EHR workflow, SMART on FHIR is the mechanism.
Health Information Exchange That Needs Structured, Queryable Data
FHIR resources are queryable in ways that HL7 v2 messages are not. You can query a FHIR server for all conditions for a patient, all observations in a date range, or all patients with a specific diagnosis. HL7 v2 messages are push-based and do not support this type of resource query.
Bulk Data Export for Analytics
FHIR Bulk Data Export (the $export operation) is the standard mechanism for large-scale clinical data extraction for analytics and population health purposes. Most major EHRs support Bulk FHIR Export for pulling large datasets.
New Health Tech Product Development
If you are building a new health tech product, starting with FHIR R4 gives you the most future-proof foundation. FHIR is the direction the industry is moving, regulatory requirements increasingly mandate FHIR APIs, and the developer ecosystem (libraries, tools, documentation) is much more actively maintained for FHIR than HL7 v2.
When You Need Both: The Reality of Production Healthcare Integrations
Most non-trivial healthcare integration projects involve both standards. A common real-world scenario:
- Patient registration and ADT events come in via HL7 v2 from the hospital's ADT feed.
- Lab results arrive via HL7 v2 ORU messages from the LIS.
- Clinical notes and medication lists are retrieved via FHIR R4 from the EHR's FHIR API.
- Updated patient data is written back to the EHR via a FHIR DocumentReference POST.
The practical response is an integration architecture that handles both: an HL7 v2 listener that parses incoming messages and maps them to your internal data model, and a FHIR client that queries FHIR APIs and handles FHIR resource creation. These are standard components in any mature healthcare integration platform.
FHIR Conversion: Mapping HL7 v2 to FHIR
A common integration requirement is converting HL7 v2 messages to FHIR resources. HL7 International publishes v2-to-FHIR mapping tables that document the official guidance for this conversion. The maps are comprehensive but require significant implementation work. Key conversion challenges include:
- HL7 v2 local coding systems (local lab codes, local facility identifiers) must be mapped to standard terminology systems (LOINC, SNOMED CT) to produce valid FHIR resources.
- HL7 v2 allows significant variation in field usage across sites. The same segment can carry different data in different implementations.
- FHIR requires referenced resources to exist before a resource that references them can be created. Building a Patient resource before creating an Observation that references it requires sequencing that HL7 v2 batch processing does not require.
For help with FHIR R4 and HL7 v2 integration projects, review our EHR integration service or schedule a technical consultation.
Futureaiit
AI & Technology Experts
