Executive Summary: HL7 v2.x messages such as ADT and ORU still drive admissions, lab results, and clinical events across hospital and laboratory systems. FHIR R4 is becoming the interface layer for modern APIs. Redix bridges HL7 v2.x into FHIR R4 so organizations can modernize at the edge without replacing the clinical message infrastructure underneath. ADT and ORU conversions are validated through an automated FHIR audit, and the same engine extends to the broader HL7 message set.
HL7 v2.x Is Not Going Away
For all the momentum behind FHIR, the day-to-day clinical world still runs on HL7 v2.x. Admissions, discharges, transfers, lab orders, and lab results move between EHRs, LIS, RIS, and ancillary systems as pipe-delimited HL7 v2 messages. These interfaces are deeply embedded, heavily tested, and expensive to rip out.
So the realistic question for most organizations is not "HL7 v2 or FHIR?" It is: how do we expose FHIR R4 at the interface layer while the systems that generate HL7 v2.x keep running unchanged?
Why FHIR, and Why a Bridge
FHIR R4 is the format external partners, patient apps, and API gateways increasingly expect. Regulatory and interoperability pressure (including the CMS interoperability program) keeps pushing FHIR toward the front door.
But "adopt FHIR" does not have to mean "replace HL7 v2." A bridge converts HL7 v2.x messages into FHIR R4 resources at the boundary. Internal clinical systems continue to speak HL7 v2; the outside world gets FHIR. This is the lowest-risk path to FHIR interoperability because it leaves the proven message infrastructure in place.
The Real Mapping Challenge
HL7 v2.x and FHIR are not the same kind of standard, and that mismatch is where naive conversions fail.
- HL7 v2 is positional and segment-based. Data lives in ordered segments and fields (MSH, PID, PV1, OBR, OBX, and so on), separated by delimiters. Meaning depends on position.
- FHIR is resource-based and profiled. Data lives in structured resources (Patient, Encounter, Observation, DiagnosticReport) that must satisfy a schema and, often, an implementation guide profile.
The translation is rarely one-to-one. A single HL7 v2 message can fan out into several linked FHIR resources, and FHIR enforces rules that HL7 v2 does not. FHIR R4 has required fields: for example, Encounter.class is a required element. If a source message lacks the data a required field expects, a careless converter will emit FHIR that looks plausible but fails validation. Getting these edge cases right - required cardinality, code systems, resource references, and timing semantics - is the difference between "FHIR-shaped JSON" and FHIR that actually validates.
Why Clean HL7 Parsing Matters
Naive HL7-to-FHIR conversion can produce technically shaped JSON that still fails real-world use: composite HL7 fields may be copied forward as raw strings instead of being parsed into the right FHIR elements. Provider identifiers, assigning authorities, phone numbers, coded observations, and facility identifiers often need field-level cleanup before they become usable FHIR resources. Redix validates ADT and ORU output through an automated FHIR audit so these issues are caught before the result is trusted.
What Redix Converts Today
Redix runs a native C conversion engine for HL7 v2.x to FHIR R4. Two message families are validated through our automated FHIR audit, with the rest of the HL7 message set handled by the same rules-driven engine and brought through the same validation discipline:
| HL7 v2.x Message | Clinical Purpose | FHIR R4 Output | Status |
|---|---|---|---|
| ADT | Admit, discharge, transfer, patient demographics | Patient, Encounter | Validated via automated FHIR audit |
| ORU | Observation and lab results | DiagnosticReport, Observation | Validated via automated FHIR audit |
| ORM | Orders | ServiceRequest | Roadmap, same engine |
| MDM | Clinical documents | DocumentReference | Roadmap, same engine |
| SIU | Scheduling | Appointment | Roadmap, same engine |
| RDE | Pharmacy and medication orders | MedicationRequest | Roadmap, same engine |
| VXU | Immunization | Immunization | Roadmap, same engine |
We are deliberate about the word "validated." ADT and ORU pass our automated FHIR audit; we do not describe a message type as production-ready until it also clears representative FHIR validator testing. That is a discipline, not a certification claim.
Validation Is the Hard Part: Our Automated FHIR Audit
Producing FHIR JSON is easy. Producing FHIR that holds up under validation, on real messages, is the hard part - and it is the part most conversion tools quietly skip.
Redix runs every HL7 v2.x to FHIR conversion through an automated FHIR audit before we trust the output. The audit checks, at minimum:
- FHIR R4 schema conformance - the output is structurally valid R4, using R4 element forms (not older DSTU2/STU3 shapes).
- Required fields per resource type - resources actually carry the elements their profile requires, so they do not fail downstream validation.
- No placeholder data - a regression scan rejects telltale dummy values (example.org hosts, localhost, hardcoded sample dates) so test scaffolding never leaks into real output.
- Internal time consistency - timestamps across the bundle make sense relative to each other.
This is a useful way to think about the two layers of FHIR quality assurance. A reference validator is the court of law - the final, authoritative ruling on conformance. Our audit is the factory QA line - it catches defects before the output ever reaches the courtroom. Both matter, and the audit is what keeps the conversions honest as we extend coverage to more message types.
Data Fidelity: Non-Invasive by Default
By default, the engine runs in a non-invasive mode: it does not silently modify or reject your source data. If a message is messy, the engine converts what is there rather than guessing or discarding. For organizations that want stricter behavior, a validation layer can be added with rules you define. The default favors fidelity and transparency; the stricter mode is a deliberate, configured choice, not a hidden one.
How It Fits the Rest of the Stack
HL7 v2.x to FHIR is part of a broader conversion engine, not a one-off script:
- It runs on the Redix native C engine for HL7 v2.x to FHIR conversion, so it is fast and deployable on-premises.
- It is reachable through the Redix REST API for application integration.
- It is exposed as a tool through the Redix MCP Server for AI-agent workflows.
- It shares the rules-driven mapping approach of the AnyToAny conversion engine, so the same discipline applies across formats.
- It deploys on-premises, keeping protected health information under your control.
Key Takeaways
- HL7 v2.x still powers core clinical messaging; FHIR R4 is becoming the interface layer.
- A bridge lets you expose FHIR without replacing HL7 v2.x systems.
- HL7 v2 (positional) and FHIR (resource-based, profiled) are not a one-to-one mapping; required fields and code systems are where conversions break.
- Redix converts ADT to Patient/Encounter and ORU to DiagnosticReport/Observation, validated through an automated FHIR audit, with more message types on the same engine.
- The automated audit (R4 conformance, required fields, no placeholders, time consistency) is what keeps the output trustworthy.
- Runs on a native C engine, on-premises, non-invasive by default, with PHI under your control.
Frequently Asked Questions
Which HL7 v2.x message types does Redix convert to FHIR?
ADT (admit, discharge, transfer) maps to FHIR Patient and Encounter, and ORU (observation results) maps to DiagnosticReport and Observation. Both are validated through an automated FHIR audit. The same declarative engine extends to additional message types such as ORM, MDM, SIU, RDE, and VXU, which are being brought through the same validation discipline.
Do I have to replace my HL7 v2.x interfaces to adopt FHIR?
No. The bridge approach keeps your existing HL7 v2.x message infrastructure in place and converts messages to FHIR R4 at the interface layer, so you can expose FHIR APIs without rebuilding the clinical systems that produce HL7 v2.x.
How does Redix make sure the FHIR output is valid?
Conversions are checked with an automated FHIR audit that verifies FHIR R4 schema conformance, required fields per resource type, the absence of placeholder data, and internal time consistency. This is a validation discipline, not a certification claim.
What FHIR version and profiles does the output target?
Output targets FHIR R4 and is aligned to US Core profiles for clinical resources such as Patient, Encounter, Observation, and DiagnosticReport.
Can HL7 v2.x to FHIR conversion run on-premises with PHI staying in our environment?
Yes. The engine deploys on-premises so protected health information stays under your control. It also runs in a non-invasive mode that does not modify or reject your source data by default, with an optional validation layer if you want stricter handling.