— May 15, 2026 · 10 min read
FHIR R5 vs HL7 v2.5.1: what to choose in 2026?
The question shows up in every hospital integration RFP: should we keep going on HL7 v2.5.1 or switch to FHIR R5? The right answer is neither "all v2" nor "all FHIR" but an explicit split of use cases. Five angles to decide.
Two standards, one organisation
HL7 v2 and FHIR are published by the same body, Health Level Seven International, founded in 1987 in Ann Arbor (Michigan). HL7 v2 was released in 1989; the most widely deployed minor version is still 2.5.1 (2007), although the official branch continued through 2.9.1 (2023). FHIR, started in 2011 by Grahame Grieve, went through DSTU (2014), STU2 (2015), STU3 (2017), R4 (2019), R4B (2022) and reached normative R5 in March 2023.
The two-catalogue setup is no accident: HL7 v3, released in 2005, never convinced clinically (too academic, too verbose), and the body chose to relaunch a pragmatic approach, keeping v2 as the historical rail while building FHIR alongside as the modern rail — without officially deprecating v2.
In 2026, HL7 v2.5.1 remains massively deployed: a 2024 HIMSS Analytics study estimated that more than 80% of North American hospitals still run integration engines on v2. FHIR keeps rising steadily, accelerated by the CMS Interoperability rules in the US and the European Health Data Space in Europe.
Syntax: reading both side by side
An HL7 v2.5.1 message is a sequence of segments separated by \r; inside
each segment fields are separated by |, components by ^,
sub-components by &. A typical patient admit (ADT^A01):
MSH|^~\&|HIS|HOSPITAL|EDI|GENERAL|20260515102000||ADT^A01|MSGID12345|P|2.5.1
EVN|A01|20260515102000
PID|1||4567890^^^HOSPITAL^MR||DUPONT^MARIE^J^^MRS||19851210|F|||12 MARKET ST^^PARIS^^75001^FRA
The same case in FHIR R5 becomes a POST to /Patient with body:
{
"resourceType":"Patient",
"identifier":[{"system":"urn:oid:1.2.250.1.213.1.4.8","value":"4567890"}],
"name":[{"family":"DUPONT","given":["MARIE","J"],"prefix":["MRS"]}],
"gender":"female",
"birthDate":"1985-12-10",
"address":[{"line":["12 MARKET ST"],"city":"PARIS","postalCode":"75001","country":"FRA"}]
}
The contrast is striking — and misleading. Both carry exactly the same clinical information. The difference is one of abstraction level: v2 serialises down to the character, FHIR serialises down to the JSON or XML schema. It is the difference between a binary protocol and an application API.
Exchange paradigm: messaging vs REST
Beneath the syntax, the exchange paradigm differs. HL7 v2 is a messaging protocol driven by events: the source system detects a fact (admission, discharge, prescription, result) and emits an ADT, ORM, ORU, MFN message to one or several configured receivers. The historical transport is MLLP (Minimal Lower Layer Protocol) over TCP — a very simple binary framing — usually wrapped inside an integration engine (Mirth Connect, Rhapsody, Cloverleaf, InterSystems Ensemble).
FHIR is, from birth, a REST API: GET/POST/PUT/DELETE over
individual resources, with special operations such as $everything or
$expand for terminologies. The FHIR server — HAPI, Smile CDR,
Microsoft FHIR Server, AWS HealthLake — exposes a single HTTPS endpoint for every
resource. The default interaction is pull: the consumer asks, unlike v2
where the sender pushes.
FHIR also supports messaging (FHIR Messaging) and Subscriptions (push via webhook or WebSocket since R4), but the canonical use case remains the REST API.
Profiling: FHIR IGs vs Z segments
The two standards share a common problem: bridging the gap between the generic spec and local needs. The way to solve it differs radically.
In HL7 v2, you add Z segments: ZIN (extended insurance info), ZBE (specific stay movements), and so on. These segments are not part of the standard; they are defined bilaterally between sender and receiver. The well-known risk: two hospitals using a different ZIN to store the same information, hence two mappings.
In FHIR you publish Implementation Guides (IG): US Core, IPS (International Patient Summary), Interopérabilité Santé France (published by ANS), CARIN BB for US payers, and so on. An IG is a set of profiles (StructureDefinition) constraining resources, plus ValueSets and CapabilityStatements. The whole thing is versioned, packaged as an NPM-like package, and downloadable from HL7.org. FHIR servers can validate a resource against an IG, unlike v2 engines that must embed Z-segment logic in application code.
Practical consequence: a FHIR IG is a shareable contract; a Z segment remains a bilateral convention.
SMART on FHIR and the application ecosystem
Another divergence point is the application ecosystem. Since 2014, FHIR has defined SMART on FHIR: an OAuth 2.0 + OpenID Connect authentication layer letting a third-party application (web, mobile) access patient data from an EHR (Electronic Health Record) with the patient's or clinician's explicit consent. This ecosystem spawned over 700 certified applications (diabetes management, medication adherence, clinician dashboards) that plug-and-play on any compliant FHIR server.
HL7 v2 has no equivalent. A v2 engine does not "plug in": each integration is hand-coded inside the interface engine (Mirth, Rhapsody). The third-party clinical app market has therefore organised around FHIR, not around v2.
Where v2 still wins
Three use cases where HL7 v2.5.1 remains the right choice in 2026:
- Legacy intra-hospital communication. A hospital information system is typically a cluster of applications (HIS ADT, laboratory LIS, radiology RIS-PACS, pharmacy PIS) that have talked to each other in v2 for fifteen or twenty years. Migrating the whole ecosystem to FHIR is prohibitively expensive, and the clinical gain is marginal. v2 remains the internal language.
- High-volume, low-latency events. An ADT^A08 (patient update) fanned out to twenty internal receivers within the same minute is more efficient in v2 over MLLP than as a FHIR POST over HTTPS at comparable throughput. The HTTPS overhead (TLS handshakes, headers) matters at hospital scale.
- Imaging / observation streams. ORU^R01 (observation result) in
v2 is widely deployed for LIS→HIS flows and remains faster than
Observationin FHIR for typical routine-lab volumes.
Where FHIR R5 is the better fit
Three symmetric cases where FHIR R5 should be preferred:
- External exposure / patient API. Any interface aimed at a third-party app, at a patient (shared medical record, mobile app), or at an external partner (insurer, research) must be FHIR. The v2-to-FHIR translation overhead at the external boundary becomes untenable over time.
- Cross-border exchange. The EHDS (European Health Data Space) adopted in 2025 designates FHIR R4/R5 plus the IPS IG as the foundation for cross-border patient-summary and prescription sharing. v2 is not an option here.
- Analytics and data platforms. Modern data pipelines (data lake, lakehouse, cloud vendors) ingest JSON natively; FHIR JSON plugs in directly, whereas a v2 message must first be parsed and re-serialised.
The coexistence strategy
In 2026, the operational consensus is stratified coexistence. Inside the hospital, HL7 v2.5.1 stays — not out of conservatism but because it works and migration is not economically justified. At the external boundary (toward patient apps, payers, health authorities, research partners), a FHIR R5 layer is exposed. The interface engine (Mirth Connect, Rhapsody, Smile CDR) bridges the two worlds with bidirectional transformations.
That strategy requires rigorous mapping discipline — which is exactly the topic of the FHIR introduction page. Classic pitfalls: v2 0..* cardinalities collapsing into FHIR 0..1, v2 identifiers without an explicit system URI, v2 codes not mapped to FHIR terminologies (LOINC, SNOMED, ICD-10).
Choosing means making the case explicit
The question "v2 or FHIR?" is the wrong question. The right question is "which flow concerns which actor, at what throughput, with what sharing need?". For stable legacy intra-hospital flows, v2 still wins. For everything that leaves the hospital, FHIR R5 wins. The interface engine is where the two worlds meet, and a good bidirectional mapping — tested, versioned, monitored — is the real deliverable.
To dig further on FHIR and its ecosystem, see the FHIR R5 ediverse page and the HL7 v2.x page on the legacy side.