Why does a health system run HL7 V2, V3 and FHIR at the same time?

The standards did not replace one another. They accumulated. Architecture in this domain is a coexistence problem, not a selection problem.

Three standards, none retired

Ask an outsider how health data exchange works and you will usually get a version of "there's a standard called FHIR". Ask someone who has integrated a hospital and you will get a longer, wearier answer, because the real system runs at least three standards at once and has done for years.

Start with the oldest. HL7's Version 2 messaging standard was first released in October 1987 as an Application Protocol for Electronic Data Exchange in Healthcare Environments. HL7 itself describes V2 as the workhorse of electronic data exchange in the clinical domain and arguably the most widely implemented standard for healthcare in the world, supporting the majority of common interfaces used in the industry globally [1]. Version 2.7 arrived in 2011 [1]. This is a standard older than the commercial web, and it is still moving admissions, orders and results in production today.

Then Version 3, which took a fundamentally different approach. The V3 Normative Edition is a suite of specifications based on HL7's Reference Information Model, using a model-driven methodology that produces messages and electronic documents expressed in XML syntax, built around subject domains that provide storyboard descriptions, trigger events, interaction designs, domain object models derived from the RIM and hierarchical message descriptors [2]. The 2015 Normative Edition was the seventh publication of the complete suite [2].

Then FHIR, the current generation: a standard for health care data exchange published by HL7, currently at v5.0.0 (R5), organised into five maturity levels running from a foundation layer through administration, clinical records and workflow up to clinical reasoning, and released under an open CC0 licence [3]. Alongside it, R4 remains the version a great many production systems actually speak [4].

The crucial detail people miss

Here is the sentence that reframes the whole problem. In its own V2 product brief, HL7 states that due to its widespread use, Version 2 will continue to play an integral part in healthcare messaging even with the V3 Normative Edition, and that HL7 is committed to supporting and extending Version 2 in parallel with Version 3, providing continuity for current installations [1].

That is not a vendor's excuse for legacy debt. That is the standards body saying, in writing, that parallel operation is the design assumption. The question "when do we finish migrating off V2?" has an uncomfortable answer: possibly never, and the standards organisation has already planned for that.

Once you accept that, a lot of architectural anxiety dissolves and is replaced by a more tractable engineering problem.

Why each standard entered, and why it stayed

V2 stayed because it works and because it is everywhere. Its looseness - segments, fields, and a great deal of site-specific negotiation - is the very thing critics cite, but it is also why it could be deployed against wildly heterogeneous systems in the 1990s. HL7's own brief lists among its benefits that it provides a framework for negotiations of what is not in the standard [1]. That is an unusually honest description: V2 standardises the frame and leaves the local agreement to the two parties.

V3 entered to fix exactly that. If every interface requires bilateral negotiation, you do not have interoperability, you have a phrasebook. Deriving every message from a single Reference Information Model [2] means two systems built to the model should agree without negotiating. The cost is that implementing a model-driven specification requires modelling expertise, and the benefit only lands when both ends have paid it. V3 consequently took hold most strongly in jurisdictional and registry programmes, where a central authority could mandate the model, rather than at the messy edges where V2 lives.

FHIR entered by making a different trade. It kept a defined resource model but delivered it through a REST API with JSON and XML representations and an open licence [3], meeting developers where they already were. Its maturity-level structure [3] is an explicit admission that different parts of the specification are at different degrees of stability - a piece of realism the earlier standards did not offer as plainly.

What this means for the architecture

If all three persist, then the design question is not "which standard do we adopt". It is "what is our internal model, and how does each external standard map onto it".

Three consequences follow, and they are the ones that separate a durable integration from a brittle one.

The internal model must be canonical and standard-independent. Systems that adopt whichever standard arrived first as their internal representation end up rewriting their core when the second one arrives. A canonical internal model, with adapters at the boundary, turns each new standard into an adapter rather than a migration.

Version migration must be a mapping exercise. R4 to R5 is the live example [3][4]. Done against a canonical model, it is a boundary change. Done against a codebase that treats FHIR resources as its domain objects, it reaches into every layer - and in clinical software, "reaches into every layer" means revalidating workflows that are carrying real patients.

Translation has to be explicit and testable. Every mapping between a V2 segment, a RIM-derived element and a FHIR resource attribute is a place where clinical meaning can quietly shift. These mappings deserve to be first-class artifacts with their own tests, not helper functions buried in an integration script.

There is a fourth consequence that is less technical and more organisational. Because the three standards arrived in different eras, they usually arrived with different teams, different vendors and different contracts. The V2 interfaces are often maintained by whoever has been there longest; the V3 work tends to sit with a jurisdictional programme; the FHIR work is typically the newest team with the newest tooling. The translation layer therefore crosses not just formats but organisational boundaries, and the failures show up at exactly those seams. An architecture diagram that shows three protocols and one integration box is hiding the part that will actually cost money.

The Canadian multiplier

Everything above is true anywhere. Canada adds a structural complication on top of it: there is no single national health system to integrate with. Delivery and the regulation of health care providers are provincial and territorial responsibilities [5], which means the timing decisions, vendor choices and standards commitments were made independently across thirteen jurisdictions.

So the coexistence problem is not merely temporal - old standard beside new standard - it is also geographic. Two provinces can be at different points on the same migration curve, and a system operating across both has to speak to each on its own terms. That is why "we're a FHIR shop" is not an architecture in this country. It is, at best, a statement about what you prefer to write.

The practical posture is unglamorous and correct: assume coexistence, invest in the canonical internal model, treat every boundary mapping as a tested artifact, and target the version your partner can actually receive rather than the one the specification recommends. MapleTriage is being built in Moncton, New Brunswick on that assumption. It is in development and not generally available.

By Joel Gathercole · Published 2026-06-07