Thalix Health
Book a demo

Interoperability

HL7 v2 vs FHIR: what's the difference?

Short answer

HL7 v2 is HL7's first exchange standard: event-driven messages built from re-usable segments, still prominent in inpatient settings around the world. FHIR is HL7's newer standard, built from modular "resources" on web standards such as HTTP, JSON and OAuth, and it supports REST, messages and documents. Most hospitals run both, so the practical question is usually how to connect them, not which one to pick.

Sources checked October 2026 · General information, not legal, regulatory or clinical safety advice

How HL7 v2 works

HL7's own comparison describes v2 as messages composed of re-usable segments, sent from one system to another to share information and to trigger behaviour such as a patient transfer or a lab order. It also supports one-way notifications and queries. Each message has a type, for example ADT for patient administration events, ORU for observation results, OML for laboratory orders, SIU for scheduling and MDM for documents.

Segments group into repeating or optional "groups" that make up a business object. A pharmacy order, for example, combines an ORC segment for the workflow, an RXO segment for the pharmacy details, optional timing segments and notes. When sites need something the standard doesn't carry, they add Z-segments, whose meaning is opaque unless the sender explains it.

How FHIR works

FHIR's building block is the resource: Patient, Encounter, Observation, MedicationRequest, Task and so on. Every resource shares a common way of being defined, common metadata and a human-readable part. Resources are combined by reference to meet a use case, then tightened for local needs with profiles and extensions. An extension's meaning can be discovered by resolving the URI that defines it, so two sites' extensions don't collide the way two Z-segments with the same name can.

FHIR uses web standards (XML, JSON, HTTP, OAuth) and supports RESTful APIs as well as messages, documents and services. R4 (4.0.1) is the release the NHS's UK Core builds on; R5 (5.0.0) is HL7's current published version.

The differences that matter in a hospital

  • Granularity. A v2 segment roughly corresponds to a FHIR resource, but segments can't be handled independently and many lack their own identity. FHIR resources can be read, updated and referenced on their own.
  • Readability. v2 messages generally carry no human-readable version. FHIR requires a human-readable narrative in each resource.
  • Updates. v2 usually sends a full snapshot, but some segments use action codes and a "delete indicator" (two double quotes) to change or remove single fields. FHIR works in snapshot mode, or with the Patch operation.
  • Profiles. Both standards can be profiled, but HL7 notes the v2 mechanism was not widely used, while FHIR profiles are built into the tooling.

Why mapping v2 to FHIR is never just a lookup table

HL7 is candid about this. Because v2 is implemented so differently from site to site, even in similar settings, consistent mapping rules at an international or even regional level are "not terribly realistic", and mappings generally have to be done implementation by implementation. One v2 message can become tens or hundreds of FHIR resources, and the converter has to decide when two parts of a message refer to the same clinician or clinic.

HL7 publishes a V2 to FHIR implementation guide (STU 1) with concept maps as a starting point: for example PID maps to Patient, PV1 to Encounter, OBR to DiagnosticReport or ServiceRequest, and OBX to Observation. Your local feeds still decide the details.

What it does not mean

  • It doesn't mean FHIR replaces v2 overnight. HL7 describes FHIR as an evolutionary path from v2, and says the standards can co-exist and work alongside each other.
  • It doesn't mean v2 is legacy you can ignore. HL7's own comparison calls it one of its most widely adopted standards and prominent in inpatient settings.
  • A FHIR API doesn't guarantee consistent data. Base resources are deliberately loose; profiles such as UK Core and local agreements do the tightening.

Where Thalix fits

Thalix takes both. Its hl7v2 driver receives HL7 v2 (ADT, ORU for labs and monitor vitals, orders, scheduling and documents) and maps it to FHIR R4; its fhir driver talks to FHIR R4 servers by polling, R4B/R5 subscriptions and SMART Backend Services. Senders are acknowledged only after an event is durably logged, the raw message is kept, and anything that can't be mapped becomes a dead letter you can replay after fixing the mapping, rather than being silently dropped.

Thalix is at pilot stage. Demos run on synthetic data, and a hospital deployment needs its own clinical safety case, information governance approval and security review. We don't claim any certification or assessment result the product doesn't have.

Questions people ask

Is FHIR replacing HL7 v2 in hospitals?

Not as a switch-over. HL7 describes FHIR as an evolutionary path from v2 and says the two can co-exist; v2 remains prominent in inpatient settings, so most hospitals run both and connect them.

Which FHIR version does the NHS use?

The NHS's UK Core is based on FHIR R4, and the UK Core governance standard (DAPB4020) lists HL7 FHIR R4 as its base. HL7's current published version is R5 (5.0.0).

Can HL7 v2 be converted to FHIR automatically?

Partly. HL7's V2 to FHIR guide gives concept maps for messages, segments and data types, but HL7 also says mappings generally need to be done implementation by implementation because v2 usage varies so much.

Sources

Each source below is an official page, read and checked in October 2026. Where a page and this guide differ, the official page wins.

General information only, written for hospital digital, IT, operations and clinical safety teams. It isn't legal, regulatory, information governance or clinical safety advice, and it doesn't replace your own organisation's processes or the official guidance linked above.

InteroperabilityHL7 v2 ADT messages explained: A01, A02, A03, A08 and moreADT messages tell hospital systems when a patient is admitted, transferred, discharged or updated. What the common trigger events mean, and where they fail. InteroperabilityWhat is an integration engine in a hospital?An integration engine receives, transforms and routes messages between hospital systems. What it does, why mapping lives there, and what to ask of yours. InteroperabilityWhat is FHIR UK Core?UK Core is the UK's set of FHIR R4 profiles and extensions, governed by NHS England standard DAPB4020. What it covers, who it applies to and what it doesn't. InteroperabilityInteroperability standards in the NHS: a map for hospital teamsFHIR and UK Core, HL7 v2, SNOMED CT, the NHS Number, PDS and the clinical safety standards: what each does and how they fit together in a hospital.

All guides

Thalix Health

See Thalix on a demo hospital.

A conversation with us is 45 minutes and free: the work you want to hand to agents, the systems involved, and where Thalix would and wouldn't fit. Demos run on synthetic patients.

Book a demo or email hello@thalixhealth.com