10 Jul
Key takeaways
- HL7v2 and FHIR R4 are not just different formats. They are built on different assumptions about how clinical data should move and be consumed.
- An integration engine handles HL7v2 to FHIR R4 conversion at the structural level. It does not standardize the clinical content inside those resources.
- A normalization layer is what sits between conversion and usable FHIR data, handling terminology mapping, patient identity validation, and data quality checks.
- Without normalization, FHIR R4 produces cleaner packaging around the same data quality problems that existed in HL7v2 environments.
- Organizations running Rhapsody or Mirth Connect already have the transport layer. Normalization is what makes the FHIR output on the other side actually interoperable.
HL7v2 vs FHIR R4: What Your Integration Engine Actually Does and What It Cannot Do Without a Normalization Layer
Most healthcare IT teams running an integration engine assume it is handling the hard part. Messages come in as HL7v2, the engine parses them, maps the fields, and delivers something on the other side that looks like FHIR R4. The connection works. The data moves. On paper, the integration is done.
What often goes unexamined is what that FHIR data actually looks like when a downstream system tries to use it. Whether a lab result carries a LOINC code or a local identifier that only the sending system understands. Whether a patient record has the right identifiers to be matched reliably. Whether a diagnosis is coded in ICD-10 or came through as a free-text description that no system downstream can process automatically.
That gap between data moving and data being usable is exactly where HL7v2, FHIR R4, and the normalization question all come together. And it is a gap that most integration engines, however capable, cannot close on their own.
Table of contents
What HL7v2 is and how it works
HL7 Version 2 has been the backbone of healthcare data exchange since the late 1980s, and it remains deeply embedded in how most hospitals, labs, and health systems move clinical data today. It works through a pipe-delimited message format where each message type, an ADT for admissions and discharges, an ORU for lab results, an ORM for orders, carries a defined segment structure that sending and receiving systems agree to interpret.
The reason HL7v2 has lasted this long is that it works. Messages get from point A to point B, the data arrives in a predictable structure, and the thousands of existing HL7v2 interfaces across healthcare have been routing clinical information reliably for decades. The limitation is not in the transport. It is in the flexibility the format allowed over time, particularly around how clinical content is coded inside those messages.
HL7v2 does not enforce standard terminology. A lab result can come through with a LOINC code, a local lab code, or a free-text description in the same OBX segment, and the message is equally valid from a structural standpoint regardless of which one is used. That flexibility made adoption easier in the 1990s. It is what makes the data unpredictable when downstream systems try to consume it in a standardized way thirty years later.
What FHIR R4 is and how it differs
FHIR R4, released by HL7 in 2019, is built on a completely different set of assumptions about how healthcare data should move. Where HL7v2 is a message-based standard designed for point-to-point interfaces, FHIR is a resource-based standard designed for API-driven data exchange, where each clinical concept, a patient, a condition, a medication, an observation, is a discrete structured object that can be created, read, updated, and queried independently.
The practical difference is significant. In a FHIR environment, a lab result is a structured Observation resource with defined fields for the patient it belongs to, the test that was ordered, the result value, the unit, and the code from a standard terminology like LOINC. That structure is not a suggestion. It is what makes the resource usable by any system that consumes FHIR data, because the consuming system knows exactly what fields to expect and what the codes in those fields mean.
FHIR R4 also assumes authenticated, secure API access rather than the bilateral interface agreements that HL7v2 depends on. SMART on FHIR adds the authorization layer that lets applications request access to specific clinical resources on behalf of specific users, which is what makes FHIR the foundation for patient-facing applications, payer APIs, and population health platforms in a way that HL7v2 never was.
What an integration engine actually does
An integration engine, whether that is Rhapsody, Mirth Connect, Infor Cloverleaf, or any other platform in the integration engine category, handles the mechanics of receiving, parsing, transforming, and routing healthcare messages. In practical terms, it listens for incoming HL7v2 messages from EHRs, labs, and other source systems, parses the segment structure, applies transformation logic that the integration team has configured, and sends the transformed output to a destination system.
When that transformation includes conversion from HL7v2 to FHIR R4, the engine maps HL7v2 segments to the corresponding FHIR resource fields. The PID segment in an HL7v2 ADT message maps to the FHIR Patient resource. The OBX segment in an ORU message maps to a FHIR Observation resource. The integration engine handles that structural translation correctly, and in that sense the conversion is real and the output is technically valid FHIR.
What the integration engine does not do is evaluate the quality of the data it is translating. If the source HL7v2 message carries a local lab code in the OBX-3 field rather than a LOINC code, the engine maps that local code to the FHIR Observation resource’s code field and delivers a valid FHIR Observation that carries a code no downstream system outside that sending organization can interpret. The structure is right. The clinical content is not standardized.
Where the integration engine stops
This is the point where most healthcare IT teams discover a gap they were not expecting. The integration is built and tested, messages are flowing, FHIR resources are being produced, and then a consuming application, a payer API, a population health platform, or an HIE, starts returning errors or producing analytics that do not make sense.
The errors usually trace back to one of three places. First, terminology inconsistency, where clinical codes in the FHIR resources do not match the standard code sets the consuming system is using to interpret them. A payer running analytics against FHIR Observation resources expects LOINC codes. If those resources carry local lab codes, the analytics either fail or produce results that cannot be compared across organizations. Second, patient identity problems, where the patient identifiers in the FHIR resources do not reliably match the identifiers in the consuming system’s records, producing duplicate or unmatched patient entries. Third, missing or malformed data elements, where required FHIR fields that were not populated in the source HL7v2 message come through as null or empty in the FHIR resource, failing validation rules on the receiving end.
An integration engine can be configured to catch some of these issues through mapping rules and transformation logic, but that configuration only works for problems the integration team anticipated when building the interface. Problems rooted in inconsistent coding practices across source systems, or in data quality issues that predate the integration, are not solvable at the engine level without a layer specifically designed to address them.
What a normalization layer adds
A normalization layer sits between the integration engine’s raw conversion output and the FHIR resources that consuming systems receive. Its job is to evaluate the clinical content of converted resources against defined quality standards and apply the transformations needed to bring that content into conformance before it reaches any downstream application.
Terminology normalization is the most important function. When a FHIR Observation resource arrives with a local lab code in the code field, the normalization layer looks up that local code in a terminology mapping table, finds the corresponding LOINC code, and replaces or supplements the local code with the standard one before the resource is stored or forwarded. The same process applies to diagnosis codes that need ICD-10 mappings, medication identifiers that need RxNorm codes, and procedure codes that need CPT or SNOMED mappings. This work requires maintaining and updating terminology mapping tables, but once those tables are in place the normalization runs automatically across every message that comes through.
Patient identity normalization is the second major function. A normalization layer can query an enterprise master patient index or patient matching service to verify that the patient identifier in an incoming FHIR resource resolves to a known, unique patient record before the resource is stored or forwarded. When duplicate records or unresolvable identifiers are found, the normalization layer can flag those resources for review rather than allowing bad identity data to propagate into consuming systems.
Data quality validation is the third function, where the normalization layer checks that required FHIR fields are populated, that value ranges are within clinically plausible bounds, and that relationships between resources, the link between an Observation and the Patient it belongs to, are intact and resolvable. Resources that fail validation can be quarantined and flagged rather than delivered to consuming systems in a broken state.
Why this matters now more than before
For most healthcare organizations, the answer to “why deal with this now” comes from two directions. CMS interoperability regulations, specifically the Interoperability and Patient Access Final Rule and the requirements coming from TEFCA, are pushing organizations to make FHIR-based patient data available through standardized APIs on a compliance timeline. Meeting that requirement with technically valid FHIR resources that carry non-standard clinical codes is not actually meeting the requirement, because payers and patients requesting that data through the API will not be able to use it reliably.
The second direction is value-based care contracting. ACOs, payer-provider partnerships, and population health programs all depend on standardized clinical data to calculate quality metrics, identify care gaps, and attribute patient populations correctly. When the FHIR data feeding those analytics carries inconsistent terminology, the metrics are wrong and the care gap identification is unreliable. Organizations in value-based contracts with quality bonuses tied to those metrics have a direct financial stake in whether their FHIR data is normalized, not just converted.
Conclusion
The most useful starting point for most healthcare IT teams is an honest assessment of what their integration engine’s FHIR output actually looks like when a downstream system consumes it. Running a sample of converted FHIR resources through a terminology validation tool against the LOINC, SNOMED, and RxNorm code sets that consuming systems expect is a fast way to understand the scope of the normalization gap. Organizations using Rhapsody or Mirth Connect can typically add normalization logic as a processing step within existing workflows, without rebuilding interfaces.
For organizations at an earlier stage, where HL7v2 to FHIR R4 conversion is still being planned, building normalization into the architecture from the start is significantly less work than retrofitting it later. Defining the terminology mapping tables, patient identity validation steps, and data quality rules before interfaces go live means the normalization layer catches problems at the point of conversion rather than after consuming systems that have been running against bad data for months.
The organizations handling this well are not necessarily the ones with the most sophisticated integration infrastructure. They are the ones that understood early that moving data and normalizing data are two different problems, and that their integration engine was designed to solve the first one, not both.
FAQs
HL7v2 is a message-based standard that routes clinical data through pipe-delimited messages using point-to-point interfaces. FHIR R4 is a resource-based standard that exposes discrete clinical data objects through RESTful APIs. The format and transmission model are different, but the more important difference is that FHIR R4 assumes standardized clinical terminology in a way that HL7v2 never enforced.
An integration engine parses the segment structure of incoming HL7v2 messages, applies configured mapping rules, and produces FHIR resources with the correct structural format. It handles the translation of message syntax and field mapping. It does not validate or standardize the clinical content inside those fields.
Conversion is a structural process that maps one format to another. Normalization is a content process that evaluates and standardizes the clinical data inside the converted format. An integration engine is built for the first problem. A normalization layer is what addresses the second.
Downstream systems receive FHIR resources that are structurally valid but may carry non-standard clinical codes, unreliable patient identifiers, and missing required data elements. Payer APIs reject records, population health analytics produce distorted results, and patient identity problems propagate across systems that trust the incoming FHIR data.
Yes. Organizations using Rhapsody, Mirth Connect, and similar platforms can typically add terminology mapping and data quality validation as processing steps within existing interface workflows. The normalization layer does not require replacing the integration engine.
FHIR R4 clinical resources expect LOINC codes for lab observations, SNOMED CT for clinical findings and procedures, RxNorm for medications, and ICD-10 for diagnoses. These are not enforced at the API level in every implementation, but consuming systems that depend on standard codes for analytics, patient matching, and care gap identification will not function reliably without them.
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.
