Radinode
Get started
All docs
HL7

HL7 v2 vs FHIR: what’s the difference?

HL7 v2 and FHIR both move clinical data but rest on different assumptions. A practical comparison of format, transport, mapping, and when to use each.

HL7 v2 vs FHIR: what’s the difference?

"Should this interface be HL7 v2 or FHIR?" comes up on almost every integration project. They are both HL7 standards and they often move the same clinical data, but they are built on completely different assumptions. This guide explains the practical differences so you can pick the right one — and understand why, in reality, most health systems run both.

The one-sentence version

HL7 v2 is an event-driven messaging standard: when something happens, a system fires a message. FHIR is a resource-oriented API standard: systems expose data as resources you request over HTTP. v2 pushes; FHIR is usually pulled.

Format

HL7 v2 messages are pipe-delimited text, parsed by position — compact, but unreadable without a spec in hand:

PID|1||12345^^^HOSP^MR||DOE^JOHN^A||19700101|M

FHIR represents the same patient as a structured JSON (or XML) resource with named fields:

{
  "resourceType": "Patient",
  "identifier": [{ "system": "HOSP", "value": "12345" }],
  "name": [{ "family": "Doe", "given": ["John", "A"] }],
  "gender": "male",
  "birthDate": "1970-01-01"
}

The FHIR version is self-describing: a developer can read it without knowing that "the fifth field is the name." That readability is a big part of why FHIR adoption has been fast among newer, web-native teams.

Transport and interaction model

  • HL7 v2 typically flows over a persistent TCP connection using MLLP (Minimal Lower Layer Protocol), through an interface engine that routes and transforms messages. It is asynchronous and event-triggered.
  • FHIR uses ordinary HTTPS with a REST API — GET /Patient/12345, POST /Observation. It also supports subscriptions and bulk export, but the mental model is a web API.

How they map to each other

Much of the day-to-day work is translating between the two. Concepts line up loosely:

HL7 v2Rough FHIR equivalent ADT message (PID, PV1)Patient + Encounter ORM / OMG orderServiceRequest ORU result (OBR, OBX)DiagnosticReport + Observation SIU schedulingAppointment

The mapping is rarely one-to-one. A single ORU^R01 result message can expand into a DiagnosticReport plus several Observation resources, and reconciling identifiers and code systems across the boundary is where most of the real effort goes.

Which should you use?

  • Choose v2 when you are integrating with existing hospital systems — EHRs, LIS, RIS, PACS. It is battle-tested, universally supported, and almost always what the legacy system on the other end already speaks.
  • Choose FHIR for new applications, patient-facing apps, mobile, analytics, and anything that benefits from a modern API — especially where SMART on FHIR or regulatory interoperability mandates apply.

In practice it is not either/or. A typical modern environment ingests v2 from its clinical systems and exposes FHIR outward to apps and partners, with an integration layer translating between them.

Where Radinode fits

Because real projects span both standards, documenting an integration means capturing which connections are v2 messaging and which are FHIR resources, and how fields map across each hop. Making that boundary explicit in the workflow is what lets the team building it avoid the identifier- and code-mapping surprises that show up late in a go-live.

HL7 v2 vs FHIR: what’s the difference? — Radinode Docs