FHIR vs HL7v2: which to use, and when

If you're connecting a system to a hospital, you'll run into both standards fast: HL7v2 and FHIR. They're often described as competitors, but in practice they solve different problems and almost always coexist. Here's how we think about choosing between them — and why the real answer is usually "both."

What HL7v2 actually is

HL7 version 2 is a messaging standard that has run hospital integration since the late 1980s. Systems emit pipe-delimited messages when an event happens — a patient is admitted, a lab result is ready, an order is placed:

MSH|^~\&|LAB|HOSPITAL|EHR|HOSPITAL|20260624143000||ORU^R01|MSG001|P|2.6
PID|1||12345^^^HOSPITAL^MR||DOE^JANE
OBR|1|||CBC^Complete Blood Count
OBX|1|NM|718-7^Hemoglobin^LN||11.2|g/dL|12-16|L|||F

Each message type covers a workflow — ADT for admissions, ORU for results, ORM/OMG for orders, SIU for scheduling. Messages move over MLLP (a thin TCP wrapper) and every receiver replies with an acknowledgment (ACK).

It's old, terse, and quirky — but it is everywhere. Effectively every EHR and lab system speaks HL7v2, and it remains the backbone of real-time clinical messaging inside the hospital.

What FHIR actually is

FHIR (Fast Healthcare Interoperability Resources, R4) is a modern, API-first standard. Instead of event messages, it models healthcare as resources — Patient, Observation, Encounter, MedicationRequest — exposed over a normal REST API in JSON:

{
  "resourceType": "Observation",
  "status": "final",
  "code": { "coding": [{ "system": "http://loinc.org", "code": "718-7" }] },
  "subject": { "reference": "Patient/12345" },
  "valueQuantity": { "value": 11.2, "unit": "g/dL" }
}

Because it's REST + JSON, FHIR is what you reach for when an app, a patient portal, or an AI assistant needs to read or write discrete data on demand. It also underpins SMART on FHIR, the OAuth 2.0 framework that lets third-party apps launch securely inside Epic, Cerner, and others.

When to use each

A simple heuristic: HL7v2 for system-to-system event messaging inside the hospital; FHIR for apps and APIs that read and write specific data.

In reality, you'll use both

The two aren't mutually exclusive — most production integrations bridge them. A typical pattern we build looks like this:

1. A device or app writes discrete data as FHIR to a canonical store (e.g., a HAPI FHIR R4 server).
2. A FHIR Subscription fires a webhook when new data lands.
3. An integration engine (we use Mirth Connect) translates the FHIR resource into an HL7v2 ORU^R01 result message.
4. That message is delivered over MLLP to the hospital's interface engine and lands in the EHR.

This is exactly the shape of our Vysio platform: a wearable streams readings in as FHIR, and the same reading goes out as HL7v2 to Epic, Oracle Health (Cerner), or any EMR that expects v2 — plus a direct FHIR write-back where the EHR supports it.

Practical advice

• Don't pick a standard in a vacuum — ask the receiving system. The EHR or interface engine on the other side usually dictates the answer.
• Map your codes once. LOINC, SNOMED, and local codes need to line up across FHIR and HL7v2, or results land in the wrong place. Get the terminology mapping right early.
• Keep a canonical source of truth. Storing data as FHIR and translating outward keeps you flexible: you can add a new EMR target without re-plumbing the source.
• Plan for acknowledgments and retries. HL7v2 ACKs and FHIR webhook failures both need handling — silent drops are how data goes missing.

Interoperability rarely comes down to "FHIR or HL7v2." It comes down to knowing which one each system on the other end expects, and building the translation layer that lets them all work as one.

Working on a device, app, or EHR integration? Tell us about it — interoperability is one of the things we do most.