HL7 v2/v3 to FHIR R4 Migration
Retire your legacy HL7 v2 interfaces and migrate to FHIR R4 — with production-tested transformation pipelines, terminology mapping, and zero-downtime cutover strategies.
The Challenge
HL7 v2 Was Designed for a World Without the Internet
HL7 version 2, developed in the 1980s, was designed for point-to-point messaging between systems in the same facility. It was not designed for patient-facing applications, mobile access, cloud architectures, API economies, or the CMS interoperability mandates that now require patient data to be accessible via FHIR R4 APIs. Legacy HL7 v2 interfaces are expensive to maintain — each interface is a bespoke configuration in an integration engine (Mirth Connect, Rhapsody, Cloverleaf) that requires specialist knowledge, breaks when sending systems update their message format, and provides no standard way to query data. FHIR R4 is the mandated standard for CMS interoperability compliance, ONC health IT certification, and modern healthcare API ecosystems. The migration from HL7 v2 to FHIR R4 is not a simple data conversion — it requires clinical terminology mapping, structural transformation from HL7's segment-based format to FHIR's resource-based model, and handling the significant variance in how different EHR vendors implement HL7 v2. I have designed and built HL7 v2 to FHIR transformation pipelines at scale — processing millions of ADT, ORM, and ORU messages — and understand the edge cases and terminology mapping complexity that make this migration harder than it appears.
Deliverables
HL7 to FHIR Migration Services
- HL7 v2 message parsing and FHIR R4 resource mapping — ADT (A01/A03/A08/A11/A28/A31) to FHIR Patient, Encounter; ORM (O01) to ServiceRequest; ORU (R01) to Observation, DiagnosticReport; MDM (T02) to DocumentReference
- HL7 v3 CDA document conversion to FHIR R4 — CCD, Referral Note, Discharge Summary, Progress Note to equivalent FHIR resource bundles conforming to US Core profiles
- Clinical terminology translation — local code systems to SNOMED CT, LOINC (lab and vitals), RxNorm (medications), ICD-10-CM (diagnoses), CPT (procedures), using ConceptMap resources and standardised terminology services
- Transformation pipeline design and implementation — scalable, event-driven transformation using Azure Functions or .NET worker services, with dead-letter queues and full audit trails
- Migration strategy and parallel-run design — running HL7 and FHIR systems in parallel during transition, validating FHIR output fidelity against source HL7 data before cutover
- Interface inventory and rationalisation — catalogue all existing HL7 v2 interfaces, prioritise migration order, identify interfaces that can be retired versus those requiring FHIR equivalents
- FHIR R4 conformance validation — validate transformed resources against US Core R4 profiles using the official FHIR validator and Inferno test suite
- Integration engine migration — migrate Mirth Connect transformers to a modern FHIR-native integration architecture, or upgrade existing Mirth Connect to FHIR channels
- Legacy interface monitoring through transition — maintain visibility on HL7 v2 interface reliability during the parallel-run period, ensuring no messages are lost
Stack
Technology Stack
Process
Migration Delivery Process
A clear, predictable engagement model with no surprises.
HL7 Interface Inventory & Analysis
Catalogue every HL7 v2 interface: message types, sending and receiving systems, message volumes, and criticality. Analyse a sample of production messages to understand the actual field population, local extensions, and deviation from the standard — HL7 v2's flexibility means every EHR vendor uses it differently.
Terminology Mapping Design
The hardest part of any HL7-to-FHIR migration. Map every local code system — local lab codes, local medication names, local procedure codes — to standardised SNOMED CT, LOINC, RxNorm, ICD-10-CM, or CPT codes. This requires clinical subject matter expertise and iterative validation with clinical staff.
Transformation Pipeline Development
Build the transformation engine — parsing HL7 segments, applying terminology mappings, constructing FHIR resource bundles, and validating output against US Core profiles. Full test suite against real (de-identified) production message samples.
Parallel Run & Fidelity Validation
Run the FHIR transformation in parallel with existing HL7 processing. Compare outputs for a representative sample of messages. Validate clinical meaning is preserved — not just that the FHIR is structurally valid, but that the clinical information it conveys is accurate.
Phased Cutover
Migrate interfaces in priority order, with rollback capability maintained until each interface's FHIR replacement is proven stable. Full monitoring through cutover and a defined stabilisation period before retiring HL7 interfaces.
FAQ
Frequently Asked Questions
Ready to Modernise Your HL7 Interfaces?
Book a free 30-minute call. We'll review your current HL7 landscape and design a migration path to FHIR R4.
Response within 24 hours · No commitment required