Top 5 HL7 v2 to FHIR Conversion Engines for US Hospitals

HL7 v2 messaging is still the backbone of intra-hospital clinical communication in 2026, and the path from v2 to FHIR runs through a conversion engine rather than a rip-and-replace. The engines below are the ones US hospitals choose for sustained v2-to-FHIR work, where the goal is a clean FHIR surface backed by the v2 feeds the hospital already runs. For more EHR connectivity work, see additional EHR connectivity walkthroughs.

The conversion layer rarely stands alone; it feeds a FHIR server selected against the criteria in the FHIR server buyer's guide.

The Engines That Anchor v2-to-FHIR Conversions

InterSystems IRIS for Health. The dominant choice among hospital systems already running InterSystems interface engines. Native v2 parsing, native FHIR emission, and the same operational tooling that the hospital already has staffed for.

NextGen Connect (formerly Mirth Connect). The open-source default for v2 routing, extended with FHIR transformation through channel scripts. Hospitals running v2 on Mirth typically layer FHIR onto the existing channel set rather than introducing a new engine.

Lyniate Rhapsody. A commercial interface engine with strong v2 origins and a maturing FHIR transformation surface. Used by hospital systems where Rhapsody is already the centerpiece of integration.

Smile Digital Health. The commercial HAPI distribution that includes an HL7 v2 input pipeline. Hospitals running Smile as their primary FHIR server and looking to consolidate the v2 path inside the same vendor often land here.

NotificationHub by Redox. The cloud-side conversion service used by hospital systems that prefer to outsource the v2-to-FHIR translation rather than run an interface engine.

What Conversion Engines Actually Have To Solve

Three problems shape the engine choice. The first is segment-to-resource mapping. ADT messages map to several FHIR resources rather than one, and the engine has to handle the fan-out cleanly so that a single admission produces a coherent set of Patient, Encounter, and Coverage updates downstream.

The second is identifier reconciliation. Hospitals usually have at least three identifier systems in their v2 traffic, and the conversion engine has to land them in FHIR with consistent `Identifier` slicing rather than letting them fragment the downstream patient record.

The third is throughput under burst. ADT message volume spikes during admission peaks and lab-result returns; an engine that handles average traffic cleanly can still drop messages under burst. The FHIR API tools for real-time clinical workflows walkthrough covers the downstream-side handling of the same surge pattern.

How US Hospitals Land On A Choice

The decision tracks the existing interface engine more than the FHIR strategy. Hospitals on InterSystems stay on IRIS. Hospitals running Mirth lean on the open-source path and self-host the FHIR side. Hospitals modernizing the full stack at once often pick Smile for the consolidated vendor relationship. Hospitals where the FHIR surface is consumed primarily by payer-side counterparties tend to look at the patterns in the top FHIR servers for payer-provider data exchange walkthrough, where the conversion engine sits inside a different business contract than the clinical one.