23 Jul
Key takeaways
- FHIR’s maturity as a standard has not eliminated the practical difficulty of converting HL7v2 data into it. The two problems are related but not the same.
- The third annual State of FHIR survey, conducted by HL7 International and Firely in 2025, found that fragmented version use and inconsistent implementation still slow adoption, even among organizations that have committed to FHIR.
- Structural translation from HL7v2 to FHIR is the easier part of the work. Mapping local clinical codes to standard terminologies is where most conversion projects lose time.
- LOINC, SNOMED CT, and RxNorm each cover a different category of clinical data, and each is maintained on its own update schedule, which means a mapping table built once will drift out of date without upkeep.
- Hospitals cannot simply turn off HL7v2, since it remains embedded in core operational workflows that were never designed with replacement in mind.
- Government funding and regulatory enforcement remain uneven across regions, which the 2025 State of FHIR survey identified as a real constraint on full-scale adoption.
- Teams that treat conversion as a mapping and governance problem, not just an engineering task, are the ones actually closing this gap.
FHIR has been around for years, backed by federal regulation and adopted by nearly every major EHR vendor. HL7v2 is decades old, built on a messaging format that predates the modern internet. By most measures, this should already be a settled question.
It is not. Most hospitals still run HL7v2 underneath the surface for orders, results, and admissions, even after investing heavily in FHIR-based interfaces on top of it. Converting from one to the other has turned out to be a much longer project than the age gap between the two standards would suggest.
This article looks at why that gap persists, what actually makes HL7v2 to FHIR conversion difficult, and what the most recent industry survey data says about where the real barriers sit.
Table of contents
Why has FHIR adoption not solved the HL7v2 conversion problem already?
FHIR was designed to fix real limitations in HL7v2: rigid message formats, inconsistent field usage, and no real support for modern web-based data exchange. On paper, adopting FHIR should retire those problems.
In practice, adopting FHIR and converting existing HL7v2 data into it are two separate projects. A hospital can stand up FHIR-based APIs for new applications while the clinical systems generating lab results, admissions, and orders keep speaking HL7v2 underneath, because those systems were built decades ago and were never going to be replaced in one step.
What does converting HL7v2 to FHIR actually involve?
Conversion happens in two distinct stages, and most of the public conversation about FHIR focuses on only the first one.
The first stage is structural translation: taking an HL7v2 message segment and mapping it to the corresponding FHIR resource field. A PID segment becomes a FHIR Patient resource. An OBX segment becomes an Observation. Integration engines handle this part reliably, and it is fairly well understood at this point.
The second stage is making sure the clinical content inside those fields actually means what a receiving system expects. A lab result converted into a valid FHIR Observation resource still needs the correct LOINC code attached to it, or the receiving system has no way to interpret what test was actually performed.
Why is mapping the hardest part, not the API itself?
An HL7v2 message can carry a local lab code, a locally defined procedure code, or free text that was never standardized in the first place, because HL7v2 never enforced a single terminology across sending systems. FHIR assumes standardized codes are already there.
That mismatch means someone has to build and maintain a mapping table connecting each local code to its standard equivalent, across every source system feeding into the conversion. A hospital with several legacy systems, each with its own local code sets built up over years, is looking at a mapping project with real scope, not a configuration setting.
What did the 2025 State of FHIR survey find about ongoing barriers?
HL7 International and Firely conducted their third annual State of FHIR survey in April 2025, gathering input from 82 FHIR experts across 52 countries, including HL7 affiliates and national standardization bodies, according to Firely’s published findings. The survey confirms FHIR is no longer an early-adopter technology, but it also documents specific, ongoing barriers.
Structural barriers identified in the 2025 State of FHIR survey
Barrier | What it means in practice |
Fragmented version use | Different institutions, even within the same country, run different FHIR versions, complicating cross-organization exchange |
Inconsistent implementation and communication | National bodies and implementers sometimes give contradictory guidance, even within the same country |
Uneven government funding and enforcement | Adoption depends heavily on regulatory pressure, which varies widely by region |
Uneven technical and workforce readiness | Some organizations, particularly in lower-resource settings, lack the specialized staff conversion projects require |
Why do terminology standards make conversion harder than expected?
FHIR data has to align with specific terminology systems to be usable across organizations, and each one covers a different category of clinical information.
The terminology standards a conversion project has to account for
| Standard | What it covers | Maintained by |
| LOINC | Laboratory tests and clinical observations | Regenstrief Institute, with distribution support from the National Library of Medicine |
| SNOMED CT (US Edition) | Clinical terms, diagnoses, and findings | National Library of Medicine |
| RxNorm | Medications and drug products | National Library of Medicine |
Each of these is maintained separately and updated on its own release schedule. A mapping table that is accurate at go-live can drift out of alignment within a year if nobody owns keeping it current, which is a maintenance responsibility conversion projects frequently underestimate at the planning stage.
Why can't hospitals just replace HL7v2 overnight?
HL7v2 is not a legacy artifact sitting untouched in a server closet. It is actively running the interfaces behind admissions, lab orders, and results delivery in most hospitals today, often across systems that have been in place for decades and touch dozens of downstream applications.
Replacing that infrastructure in one move means replacing every interface that depends on it at the same time, with no fallback if something breaks. Most healthcare IT teams instead run HL7v2 and FHIR in parallel, converting data at the boundary between them, which is exactly why the conversion challenge persists rather than getting solved once and closed out.
What should healthcare IT teams actually do about it?
- Treat terminology mapping as an ongoing responsibility, not a one-time project milestone, since LOINC, SNOMED CT, and RxNorm all update independently.
- Build a normalization layer separate from the integration engine, so structural conversion and content quality are handled as distinct steps.
- Assign clear ownership of mapping tables, since drift happens quietly when nobody is specifically responsible for catching it.
- Plan for HL7v2 and FHIR to coexist indefinitely, rather than treating the older standard as something to fully retire on a fixed timeline.
- Track version fragmentation across your own systems, since the same inconsistency the 2025 survey found industry-wide often exists inside a single health system’s own department-by-department implementations.
Where does this leave healthcare IT teams still running HL7v2?
The gap between HL7v2 and FHIR was never going to close just because FHIR matured as a standard. The 2025 State of FHIR survey confirms what many healthcare IT teams already know from experience: fragmented versions, inconsistent implementation, and uneven governance are structural conditions across the industry, not isolated project failures.
Closing that gap for any single organization comes down to treating terminology mapping and data governance as ongoing work, not a milestone to check off during a migration project, since the underlying standards on both sides keep changing long after go-live.
FAQs
Eventually, in new implementations, but HL7v2 remains embedded in core hospital operations that were built around it for decades. Most organizations expect to run both standards in parallel for the foreseeable future.
Because LOINC, SNOMED CT, and RxNorm are each updated independently, on their own schedules. A mapping table accurate today can be outdated within a year if nobody is responsible for revisiting it.
It gathered qualitative input from 82 FHIR experts across 52 countries, including HL7 affiliates and standardization bodies, to assess real-world adoption progress and the barriers still slowing it down.
Both. The structural conversion from HL7v2 to FHIR is a largely solved technical problem. Terminology mapping, governance ownership, and inconsistent implementation across institutions are more organizational than technical.
Not immediately, and often not for years. Those interfaces typically support live clinical operations that cannot be replaced without a carefully managed transition.
Treating the project as finished once structural conversion works. The terminology and identity mapping underneath the conversion is what determines whether the resulting FHIR data is actually usable by other systems.
ISO 27001:2022 Certified
Aigilx health specializes in developing Interoperability solutions to create a healthcare ecosystem and aids in the delivery of efficient, patient-centric and population-focused healthcare.
