Healthcare runs on two interoperability standards built decades apart. HL7 v2, first released in 1989, still carries the overwhelming majority of hospital data exchange — ADT feeds, lab results, orders. FHIR (Fast Healthcare Interoperability Resources), released by HL7 International in 2014, reimagines health data as RESTful resources for the API era. Choosing between them — or more realistically, deciding how to run both — is a core architectural decision for any health IT project.
Message Format: Pipes vs JSON
HL7 v2 messages are delimited text: segments separated by carriage returns, fields by pipes (|), components by carets (^). A PID segment packs dozens of patient fields into one line — compact, but positional and hard to read without a parser.
FHIR represents the same data as JSON or XML resources — Patient, Observation, Encounter, MedicationRequest — each with named, self-describing fields. A FHIR Patient is readable by any developer without a spec sheet.
Transport: MLLP vs REST
HL7 v2 typically travels over MLLP (Minimal Lower Layer Protocol) — raw TCP sockets with start/end block characters — or via file drops and integration engines like Mirth Connect or Rhapsody. It is push-based, event-driven, and point-to-point.
FHIR is a REST API standard: resources are created, read, updated, and searched over HTTPS with OAuth 2.0 / SMART on FHIR authorization. This makes it a natural fit for patient-facing apps, EHR vendor APIs (Epic, Cerner/Oracle Health), and regulatory mandates like the US 21st Century Cures Act and CMS interoperability rules.
When to Use Which
- HL7 v2: real-time ADT feeds, lab/radiology result delivery, interfaces between hospital systems (HIS, LIS, RIS, EHR) where v2 interfaces already exist.
- FHIR: patient-facing apps, payer/provider data exchange, population health analytics, new integrations where a REST API is available, regulatory compliance (US Core, IPS).
- Both: most real deployments — v2 feeds inside the hospital, FHIR APIs at the boundary, with an integration engine or FHIR facade translating between them.
Migration Considerations
A wholesale v2-to-FHIR rewrite is rarely justified — v2 interfaces are stable, well-understood, and embedded in clinical workflows. The pragmatic path is a FHIR facade: keep v2 internally, expose FHIR endpoints for external consumers, and map resources incrementally (Patient and Encounter first, then Observation and DiagnosticReport). Watch for semantic mismatches: v2's repeating fields and Z-segments (custom extensions) do not always map cleanly to FHIR profiles.
Inspect Real Messages — Free Tools
Working with either standard means debugging real payloads. Both tools below run entirely in your browser — PHI never leaves your machine:
- HL7 v2 Message Parser — paste a raw message and get a segment/field/component breakdown with labels for MSH, PID, PV1, OBR, OBX and more.
- FHIR Resource Viewer & Validator — validate FHIR R4 JSON resources (Patient, Observation, Bundle, Encounter, MedicationRequest) with required-field checks and a flattened field view.
Frequently Asked Questions
Is HL7 v2 being replaced by FHIR?
Not soon. v2 remains dominant for intra-hospital messaging and will persist for years. FHIR is the standard for new API-based exchange — the two coexist, connected by integration engines and FHIR facades.
What is the difference between FHIR R4 and R5?
R4 (2019) is the first normative release and the version mandated by US regulations — use it unless a partner requires otherwise. R5 adds new resources and refinements but has less implementation support.
What are Z-segments in HL7 v2?
Custom, vendor-defined segments prefixed with Z (e.g., ZPD, ZIN). They carry site-specific data not covered by the standard — a common source of integration bugs when migrating or mapping to FHIR.
