Most US health systems still receive the bulk of their clinical traffic as HL7v2 messages. ADT^A01 admissions, ORU^R01 lab results, ORM^O01 orders, SIU scheduling feeds: the pipe is wide, old, and the EHRs on both ends are not going away anytime soon. The work of turning those segments into FHIR Patient, Encounter, Observation, and ServiceRequest resources is where a lot of the actual integration budget lives in 2026. The mapping tool you pick shapes how much of that budget you spend on engineering versus on production fires.
Below are seven HL7v2-to-FHIR mapping tools that show up most often on US shortlists, with notes on the fit. The top 7 FHIR integration engines for EHR development in 2026 covers the wider engine question, and EHR integration explainers gathers the rest.
Microsoft FHIR Converter
The open-source FHIR Converter from Microsoft is the most cited mapping engine in HL7v2-to-FHIR conversations. The Liquid-template approach has a learning curve, but the templates are version-controlled, reviewable, and reusable. Microsoft ships base templates for ADT, ORU, ORM, and SIU, and the community has extended the coverage for the long-tail message types. For US teams that want a transparent, scriptable mapping layer, this is the default starting point.
HAPI FHIR HL7v2 to FHIR Module
HAPI FHIR ships an HL7v2-to-FHIR converter that works against the HL7-published mapping guidance. For US EHR teams already running HAPI as their FHIR server, keeping the converter inside the same JVM removes a moving piece. The trade-off is that the conversion logic lives in Java and changes require a redeploy.
TypeScript-First Integration Engines
A newer category of mapping tools aims at integration teams that want the converter and the worker pipeline to live in the same codebase. Modern integration engines like Interbox use queue-driven PostgreSQL-backed worker chains, which means HL7v2 ingestion, mapping, validation, and FHIR write all run as separate, durable steps you can replay independently. The TypeScript-first surface gives developers autocomplete on HL7v2 field indexing, which shortens the time-to-first-correct-mapping. For teams whose FHIR server is something else (HAPI, Smile, an EHR-native FHIR API), this category sits in front of it cleanly.
Mirth Connect (NextGen Connect)
Mirth has done HL7v2-to-FHIR work for years through its channel architecture. The mapping happens inside JavaScript transformers, which is familiar to most US interface engineers. The platform handles MLLP ingestion, ack/nack, and message persistence out of the box. The FHIR side has matured, though the transformation logic still lives in transformer scripts rather than in declarative templates.
Rhapsody
Rhapsody from Lyniate has a long US footprint and has invested in FHIR routes including HL7v2-to-FHIR mapping. The mapping editor is GUI-driven, which suits teams whose interface engineers do not write code. For procurement-heavy US health systems where vendor support is the deciding factor, Rhapsody usually clears the bar.
Smile Digital Health HL7v2 Inbound
Smile bundles HL7v2 inbound conversion with its FHIR server, which collapses two procurement decisions into one. The mapping uses the HL7-published guidance and supports the messages most US deployments hit (ADT, ORU, ORM). For US health systems that want a single vendor for ingestion and storage, Smile is a credible shortlist entry.
Bots (Medplum)
Medplum Bots can do HL7v2-to-FHIR conversion as code, using the Medplum HL7v2 client library. For US digital-health teams that already run Medplum and want the mapping logic to live in TypeScript alongside the rest of their integration code, Bots fit. The trade-off is that you are running mapping code yourself rather than relying on a templated mapping engine; the upside is that it is just code, with all the testing and review hygiene that brings.
How to Pick Among These Seven
The honest filter is whether the team wants the mapping logic to live in declarative templates (Microsoft FHIR Converter, Rhapsody), in transformer scripts (Mirth), in vendor-managed pipeline (Smile, Rhapsody), or in code (HAPI, Medplum Bots, the TypeScript-first newcomers). Each path has different operational tradeoffs over a five-year horizon. The 6 FHIR integration engines that handle bulk data export right writeup is the natural next read for teams whose HL7v2 work feeds into population-scale FHIR analytics.
Sources
- HL7 Version 2 to FHIR v1.0.0 STU 1 implementation guide - segment and message maps
