HL7 v2 or FHIR — which one should your integration actually use?
Every healthcare integration eventually hits this fork: the source system speaks HL7 v2, everyone talks about FHIR, and you have to decide what your interface should actually use. The honest answer is that it is rarely either/or. HL7 v2 still moves the overwhelming majority of real-time clinical messages inside hospitals, while FHIR is the standard for modern APIs, apps, and external data exchange. This guide explains what each is genuinely good at, why they will run side by side for years, and how to bridge them without pretending one has replaced the other.
Two standards, two jobs
HL7 v2 is a messaging standard: it was built in the late 1980s to push event notifications between systems inside a hospital over a persistent connection — an admission happened, an order was placed, a result came back. FHIR is a resource-and-API standard: it was built decades later to expose healthcare data as RESTful resources that apps, portals, and partners can query on demand. They solve different problems, which is exactly why one did not simply replace the other.
- HL7 v2 answers "tell me the moment something happens" — push, event-driven, real-time, internal.
- FHIR answers "let me ask for the data I need" — pull, request/response, on-demand, often external.
Where HL7 v2 still wins
Inside a hospital, HL7 v2 remains dominant for a simple reason: it is already there, running thousands of live interfaces between the EHR, lab, radiology, pharmacy, billing, and every ancillary system. It is event-driven and battle-tested for real-time flows — an ADT feed updating a dozen downstream systems the instant a patient is admitted, an ORU delivering a lab result seconds after it verifies. Replacing a working v2 interface with FHIR polling usually adds latency and cost for no clinical benefit.
Where FHIR is the right choice
- External access: patient apps, third-party developers, and partners expect a REST API, not an MLLP socket into your network.
- Regulatory interoperability: US Core, CMS payer APIs, and TEFCA are anchored on FHIR R4 — you cannot meet them with v2.
- Query-shaped needs: "give me this patient's active medications" is a natural FHIR read; expressing it in v2 is awkward.
- Structured, richly-typed data with formal profiles and validation, versus v2's pipe-delimited positional fields.
Why they coexist (and will for years)
The realistic picture in almost every health system is a v2 core with a FHIR edge. The internal nervous system — ADT, orders, results — keeps running on v2 because it works and rewriting it is enormous risk for little gain. FHIR sits at the boundary, exposing that same data to apps, patients, and external partners. An interface engine or FHIR facade translates between the two. Anyone who tells you FHIR has "replaced" HL7 v2 has not maintained a real hospital interface.
How to bridge v2 and FHIR
- Use an interface engine (Mirth, Rhapsody, Cloverleaf) to receive v2 and transform to FHIR resources, or vice versa.
- Map deliberately at the field level — an ADT^A01 becomes an Encounter plus Patient; an ORU^R01 becomes DiagnosticReport plus Observations. The mapping is where correctness lives.
- Keep the v2 feed as the real-time trigger and let FHIR be the queryable representation — event in v2, state in FHIR.
- Preserve identifiers across the boundary so the same patient and encounter resolve consistently in both worlds.
A practical decision rule
If the data stays inside the hospital and needs to move the instant an event occurs, HL7 v2 is almost certainly the right transport — don't fight what already works. If the data leaves your walls, powers an app, or has to satisfy US regulatory interoperability, it needs a FHIR surface. Most mature architectures do both: v2 internally, FHIR at the edge, and a well-tested translation layer in between.
