HL7 v2 vs FHIR: which to use for your healthcare integration
If you're connecting a healthcare system, you'll meet two standards from the same organisation — HL7 v2 and FHIR. They aren't really competitors; they're tools for different jobs. Here's how to choose.
HL7 v2: the workhorse of hospital messaging
HL7 version 2 is the pipe-and-hat, event-driven messaging standard that has run inside hospitals for three decades. When a patient is admitted, a result is ready, or an order is placed, a v2 message (ADT, ORU, ORM, SIU, DFT and friends) is pushed between systems in near real time. It is terse, battle-tested, and almost universally supported by EHRs, lab systems, and legacy applications — but it is also famously loose: the same field can be used differently by two vendors, so real interfaces live or die on careful mapping.
FHIR: a modern API for healthcare data
FHIR (Fast Healthcare Interoperability Resources) takes the same clinical concepts and exposes them as web-friendly resources — Patient, Observation, Encounter, MedicationRequest — over a RESTful JSON (or XML) API. It's built for the way software is written today: request the data you need, when you need it, with OAuth-based security and patterns like SMART on FHIR for app authorisation. That makes it the natural choice for apps, patient access, and third-party integrations.
When HL7 v2 is the right choice
- You're integrating with an existing hospital interface engine or EHR that already speaks v2.
- You need real-time, event-driven flow — admissions, transfers, results as they happen.
- The system on the other end simply doesn't offer a FHIR endpoint (still common for older platforms).
When FHIR is the right choice
- You're building a new application, portal, or public API.
- You need on-demand, query-style access rather than a firehose of events.
- You want patient-facing access, mobile support, or standardised OAuth security via SMART on FHIR.
In practice, most teams need both
The realistic answer is rarely "one or the other." A modern integration often ingests HL7 v2 events from clinical systems, transforms them into FHIR resources for a product or analytics layer, and exposes a FHIR API outward — while still speaking v2 back to the hospital. An interface engine such as Mirth Connect sits in the middle doing exactly this translation, with validation and error handling on both sides. Get the mapping layer right and you can modernise the edges without ripping out the systems that already work.
Working on something similar? We build and run these systems for healthcare and software teams. Talk to an engineer →