HL7 v2 Retirement: What Hospitals Should Actually Be Planning For

The Reality of HL7 v2 in Hospitals Today

HL7 v2 is the plumbing of clinical messaging. Admit/discharge/transfer events, orders, results, and discharge summaries — the core of daily hospital operation — run on HL7 v2 in the vast majority of hospital environments. Radiology, lab, and pharmacy systems still use it as their primary clinical messaging standard. So do most third-party vendors whose products sit at the edge of the clinical environment.

FHIR has not replaced this, and the reason is architectural rather than a failure of adoption. HL7 v2 and FHIR solve slightly different problems. HL7 v2 is event-driven: something happens in a clinical system, and a message is pushed downstream immediately. FHIR is API-driven: a consuming system requests data when it needs it, or subscribes to a topic. These are not the same pattern, and the replacement of one with the other is not a one-for-one swap.

The integration engines that process HL7 v2 at scale — InterSystems HealthShare and IRIS for Health, Rhapsody, Mirth Connect — are built and optimised for it. HL7 v2 routing, transformation, and acknowledgement handling is well-understood operationally. FHIR processing has different operational characteristics: REST endpoints, authentication flows, FHIR resource validation, and profile conformance all require different skills and patterns to manage reliably.

What "Retirement" Actually Means in Practice

There are two distinct concepts that get conflated in most discussion of HL7 v2 retirement: standards body deprecation and operational retirement. HL7 International has effectively ceased active development of HL7 v2, with v2.9 representing the last major release. That is standards body deprecation. It means no new message types, no new event triggers, no new official guidance.

Operational retirement — hospitals actually stopping the use of HL7 v2 in production — is on a very different timeline. For most hospital estates, the realistic coexistence period is 10 to 15 years at minimum, not the 3 to 5 years that is sometimes floated. The reason is straightforward: the consuming systems on the other end of HL7 v2 feeds have not been replaced, and many of them will not be replaced on any short timeline. Until those systems are replaced with FHIR-capable alternatives, the feeds that serve them cannot be migrated.

This means migration is not "swap HL7 v2 for FHIR across the estate". It requires interface-by-interface decisions based on the use case, the capability of the consuming system, and a genuine assessment of what value the migration actually delivers. Many high-volume stable clinical feeds — lab results from a mature LIS, ADT events to a downstream alerting system — have no compelling driver to migrate to FHIR. Forcing migration in those cases creates complexity without clinical or operational benefit.

The risk of premature migration is real. Organisations that pursue FHIR adoption on use cases where HL7 v2 is more appropriate end up maintaining two integration patterns for the same data flow, with the FHIR layer adding overhead rather than replacing the existing mechanism. The cleaner path is selective migration driven by genuine use case fit, not by a strategy document that declares a FHIR-only future without a credible plan for the existing estate.

How to Prepare Your Interface Estate Now

The most valuable thing most organisations can do right now has nothing to do with FHIR. It is a complete, accurate inventory of every HL7 v2 feed in the environment. For each feed: what message types are sent, from which source system, to which destination, at what volume, how clinically critical the data is, and — critically — who would know if it stopped working.

That last point matters more than it sounds. In many hospital environments there are HL7 v2 feeds that have been running for years with no active owner. If the interface fails, it may not be caught until a clinician reports missing data days later. Knowing who owns what is a prerequisite for any migration planning, and it is equally valuable as a risk reduction exercise regardless of any migration timeline.

Once the inventory exists, categorise feeds by migration candidacy. Some are FHIR-ready now: new application integrations, connections to national APIs that already mandate FHIR, modern clinical apps built on FHIR-native architectures. Some are FHIR-ready with significant work: complex clinical workflows where the FHIR resource model fits the data well but the transformation and testing effort is substantial. And some are HL7 v2 for the foreseeable future: stable, high-volume clinical feeds where there is no compelling driver to change and the migration risk outweighs any benefit.

Governance is a separate and equally urgent priority. Every active HL7 v2 feed should have a versioned specification — what the message looks like, what the Z-segment extensions mean, what the valid value sets are. Most do not. This documentation work has value immediately, regardless of migration timeline. It reduces operational risk, enables regression testing, and provides the baseline from which any future migration can be planned. Starting this work now, rather than as a precursor to a migration that may be years away, is the right approach.

The practical recommendation on FHIR capability: build it now alongside HL7 v2, not as a replacement programme. Apply FHIR where it is the right tool — new use cases, national connectivity, modern application integration — while maintaining and governing the existing HL7 v2 estate properly. A big-bang migration away from HL7 v2 is not going to happen. The organisations that handle this transition well will be the ones that run both well simultaneously.

The Transition Risks Nobody Talks About

The skills question is underestimated. Integration engineers who manage HL7 v2 estates exceptionally well have deep knowledge of message routing, transformation logic, acknowledgement handling, and the idiosyncratic behaviour of specific vendor implementations. That expertise does not automatically translate to FHIR. FHIR profiling, FHIR conformance testing, SMART on FHIR authentication flows, and FHIR subscription management are different disciplines. Teams that assume their HL7 v2 engineers can absorb FHIR without investment in training and tooling are taking a risk.

Clinical informatics must be in the room, not just technical teams. FHIR-based workflows expose data differently than event-driven HL7 v2 messaging. An ADT event pushed via HL7 v2 arrives at the destination system immediately and triggers downstream processes automatically. A FHIR-based patient location service requires the consuming system to query for updates, or to subscribe and handle notifications. These are different interaction models, and the clinical workflows built around them need to be understood and tested before migration, not after go-live.

Testing coverage is a significant operational challenge. Regression testing an HL7 v2 interface requires capturing real message traffic, replaying it through a test environment, and verifying that the output matches expected behaviour. Most organisations have some capability for this, however informal. Regression testing a FHIR integration requires different tooling — FHIR validators, test servers that can simulate FHIR endpoints, conformance testing against published profiles — and most organisations do not have this capability yet. Building it takes time and deliberate investment.

Vendor readiness is uneven. Clinical system vendors vary considerably in the maturity of their FHIR implementations. A vendor may have a FHIR API for patient demographics but not for orders, results, or documents. Before committing to a FHIR migration path for any use case, the actual capability of the vendor's FHIR implementation should be verified against the specific data and workflows required — not against marketing collateral or a generic FHIR conformance statement.

A Practical Planning Framework

Do now, regardless of migration timeline: complete interface inventory with clinical criticality ratings, versioned specifications for every active feed, monitoring baselines so you know what normal looks like before something breaks, and active investment in FHIR capability development in your team. None of this requires a migration to start. All of it reduces risk today.

In the next 2 to 3 years: identify migration candidates where there is a clear business driver — new system procurement with FHIR requirements, national API connectivity mandates, new clinical app integrations where FHIR is the right fit. Pilot FHIR for those use cases. Build regression testing capability for both HL7 v2 and FHIR. Document the lessons from each pilot and apply them to the next one.

What to avoid: declaring a FHIR-only strategy without a credible plan for the existing HL7 v2 estate. Migrating high-volume stable feeds on a theoretical timeline without clinical and operational justification. Treating FHIR adoption as a technology project owned entirely by integration teams without clinical informatics and operational governance involvement. Assuming the migration timeline will be 3 to 5 years when the realistic answer, for most estates, is much longer.

The organisations that manage this transition well will not be the ones that moved to FHIR fastest. They will be the ones that knew their HL7 v2 estate thoroughly, governed it well, introduced FHIR incrementally where it delivered value, and ran both standards competently for as long as the clinical environment required.

Frequently Asked Questions