HL7 v2 to FHIR Conversion and Mapping Services
HL7 to FHIR conversion lets organizations keep their proven HL7 v2 interfaces while giving modern applications, mobile apps and analytics platforms FHIR-based access to the same data. Taction Software provides HL7 FHIR integration services that map v2 segments to FHIR resources, translate local codes to LOINC and SNOMED CT, and handle the custom segments automated converters miss. We are honest about the effort: tools get you part of the way, and clinical mapping finishes the job. Discuss your conversion project with our team.
Why Organizations Convert HL7 v2 to FHIR
Most hospitals still run hundreds of HL7 v2 interfaces, and replacing them is neither practical nor necessary. Instead, many organizations convert HL7 to FHIR at the integration layer, so existing feeds keep running while new consumers receive FHIR resources. This approach protects investment in stable interfaces and supports new API-driven products. It also aligns with wider healthcare interoperability consulting strategies focused on standards-based data access across organizations. Here are the main drivers we see.
API-First Applications
Modern applications expect RESTful APIs and JSON rather than MLLP feeds. Converting HL7 v2 events into FHIR resources lets developers build on familiar tools without learning legacy messaging protocols. Onboarding gets faster.
Mobile and Patient-Facing Apps
Patient apps need secure, on-demand access to data like results and appointments. FHIR resources, protected by SMART on FHIR authorization, suit these use cases far better than raw HL7 messages.
Analytics and Data Platforms
Analytics teams benefit from consistent FHIR resources instead of many message variations. Converted data can feed warehouses, quality reporting and AI projects using a single, well-understood data model. Data quality improves as well.
Partner and Payer Data Sharing
Regulations and partnerships increasingly expect FHIR-based data exchange. Conversion lets organizations meet these expectations using data already flowing through existing HL7 v2 interfaces, without rebuilding source systems. No source replacement needed.
Protecting Existing Interfaces
Conversion adds FHIR output without disrupting working v2 feeds. Downstream systems that depend on HL7 v2 keep receiving it, while new consumers use FHIR from the same source events. Risk stays low throughout.
HL7 v2 to FHIR Mapping, Segment by Segment
HL7 v2 to FHIR mapping is more than reformatting. HL7 v2 messages describe events, while FHIR resources describe current state, so one message can create or update several resources. The HL7 v2-to-FHIR Implementation Guide provides recommended mappings, which we use as a starting point, then adapt to your sources. Each mapping below needs clear rules for identifiers, references and updates, so resources stay consistent as new messages arrive over time.
PID to Patient
PID maps to the Patient resource, including identifiers, names, birth date, gender, address and contact details. Identifier systems must be defined carefully, so patients match correctly across sources and updates.
PV1 to Encounter
PV1 maps to Encounter, including class, location, attending practitioner and admission and discharge times. ADT events then update the same Encounter rather than creating new ones each time. Visit history stays accurate.
ORC and OBR to ServiceRequest
ORC and OBR map to ServiceRequest for orders, carrying order numbers, requested tests, priority and requester. These references later connect results back to the original request for complete clinical context.
OBX to Observation
Each OBX becomes an Observation with code, value, units, reference range, interpretation and status. Grouped results under one OBR also create a DiagnosticReport that references each individual Observation. Status updates revise existing resources.
AL1, DG1 and IN1 Segments
AL1 maps to AllergyIntolerance, DG1 to Condition, and IN1 to Coverage. These mappings often need extra logic, because source systems send incomplete or inconsistently coded data in these segments. Expect data cleanup.
Terminology Translation and What Does Not Map
Structure is only half of HL7 to FHIR conversion. Codes inside messages must be translated into standard terminologies, and some content has no clean FHIR equivalent at all. Automated converters get you perhaps 70 percent of the way. The remaining work is clinical and terminology mapping, handling local extensions and validating output against profiles like US Core. Planning for this upfront prevents surprises and keeps project timelines and budgets realistic.
Lab Codes to LOINC
Local lab test codes must map to LOINC for FHIR Observations to be interoperable. This requires clinical review, because specimen, method and units determine the correct code for each test.
Diagnoses and Problems to SNOMED CT
Diagnoses may arrive as ICD-10 or local codes. We map them to SNOMED CT where required by profiles, while preserving original codes, so no information is lost during translation. Both codes coexist.
Medications to RxNorm
Medication orders and administrations often use local formulary codes. Mapping them to RxNorm makes medication data usable across systems and supports clinical decision support in receiving applications. Unmapped codes are flagged for review.
Z-Segments and Local Extensions
Custom Z-segments have no standard FHIR mapping. We document each one, decide whether it maps to existing elements or needs a FHIR extension, and agree rules with data owners. Nothing is silently dropped.
Profile Validation
Converted resources should validate against US Core or your target implementation guide. We run automated validation in testing and production, so malformed resources are caught before consumers receive them. Errors are logged centrally.
Frequently Asked Questions
What is HL7 to FHIR conversion?
HL7 to FHIR conversion transforms HL7 v2 messages, such as ADT and ORU, into FHIR resources like Patient, Encounter and Observation. It lets organizations keep existing HL7 v2 interfaces while giving modern applications FHIR-based access. Conversion includes structural mapping, terminology translation and validation against profiles like US Core.
Can HL7 v2 messages be converted to FHIR automatically?
Partly. Automated converters and the HL7 v2-to-FHIR Implementation Guide handle common segments well, often around 70 percent of the work. The rest requires human decisions: mapping local codes, handling Z-segments, managing identifiers and validating output. Fully automated conversion without review usually produces incomplete or inconsistent FHIR resources.
Does converting to FHIR replace our HL7 v2 interfaces?
No. Conversion usually runs alongside existing HL7 v2 interfaces. Current receivers keep getting HL7 v2, while new applications consume FHIR from the same source events. This protects stable, working interfaces and lets you adopt FHIR gradually, without the cost and risk of replacing source systems.
Which HL7 v2 segments map to which FHIR resources?
Common mappings include PID to Patient, PV1 to Encounter, ORC and OBR to ServiceRequest, OBX to Observation, grouped results to DiagnosticReport, AL1 to AllergyIntolerance, DG1 to Condition and IN1 to Coverage. The HL7 v2-to-FHIR Implementation Guide documents recommended mappings, which should be adapted to your source systems.
How are Z-segments handled in FHIR conversion?
Z-segments are custom and have no standard FHIR mapping. Each one must be analyzed to decide whether its data fits existing FHIR elements, needs a FHIR extension, or can be safely excluded. These decisions should be documented and agreed with data owners, so no important clinical information is lost.
How long does an HL7 to FHIR conversion project take?
A conversion covering one or two message types, such as ADT and ORU from a single source, often takes six to twelve weeks. Projects with many sources, heavy Z-segment use or large terminology mapping needs take longer. Source message assessment gives an accurate timeline before development starts.
Ready to Convert HL7 v2 to FHIR?
Our integration engineers are ready to help. Free consultation, no obligation.