US hospitals in 2026 still run a substantial HL7 v2 footprint alongside their growing FHIR surface. The question for hospital IT teams is rarely "FHIR or HL7 v2" in absolute terms; it is "where does each one belong in the integration stack, and what should the runtime for each look like." A FHIR server and an HL7 v2 integration engine solve overlapping problems with very different operational profiles, and the right answer is usually a combination rather than a pick. For more on FHIR for medical software, the broader coverage walks through the surrounding patterns.
What a FHIR Server Brings to Hospital Workflows
A FHIR server exposes a REST API on top of the FHIR resource model, with searchable resources, terminology operations, subscriptions, and bulk export. For hospital workflows, the value shows up in three places: SMART on FHIR clinical app launches against the EHR data, modern third-party integrations that expect REST and JSON, and population-level analytics that benefit from the FHIR resource graph.
A FHIR server fits naturally on top of an existing clinical data store, often as a read-mostly endpoint that surfaces FHIR resources derived from the underlying EHR. The hospital IT team gets a clean integration surface for new applications without having to teach those applications how to speak HL7 v2.
What an HL7 v2 Integration Engine Still Covers in 2026
An HL7 v2 integration engine (Mirth Connect, Rhapsody, Cloverleaf, InterSystems Ensemble, and the like) routes ADT, ORU, ORM, and SIU messages between the hospital's existing systems. In 2026 that traffic remains substantial: the lab system, the radiology PACS, the OR scheduling system, the pharmacy system, and the bed management system mostly still speak v2.
A v2 integration engine is built for that exact workload. It handles message acknowledgments, retries, routing logic, and the kind of detail-level field manipulation that v2 message formats require. A FHIR server cannot replace this layer cleanly, because the upstream systems do not speak FHIR natively.
Where Each Belongs in the Hospital Stack
The right architecture in 2026 hospital deployments is usually a layered one: HL7 v2 messages flow between the existing internal systems via the integration engine, the integration engine writes the canonical clinical record into a FHIR-shaped store, and the FHIR server exposes that store for new applications. The FHIR server faces outward to apps; the v2 engine faces inward to legacy systems.
A hospital IT team that tries to replace the v2 engine with a FHIR server tends to underestimate the operational complexity of v2 message routing. A team that tries to expose v2 messages directly to new applications tends to underestimate how much glue code the apps end up needing.
The most useful framing for hospital IT teams in 2026 is: keep the v2 engine for system-to-system internal traffic, layer a FHIR server on top for everything outward-facing, and budget a translation layer that converts the most-used v2 message types into the corresponding FHIR resources. That translation layer is the single most-discussed integration component in 2026 hospital deployments, because it is where the operational complexity of the two protocol families collides.
The FHIR server complete guide covers the FHIR-side picks. The hospital IT FHIR server roundup walks through the FHIR layer in this specific architecture, and the FHIR API tools roundup covers the tooling used at the application boundary above both the FHIR server and the v2 engine.
Sources
- HL7 Version 2 Product Suite - canonical reference for HL7 v2 messaging - HL7 International
- FHIR-side conformance baseline for the FHIR layer - HL7 US Core IG STU 6.1.0
- launch flow used by outward-facing clinical apps above the integration stack - HL7 SMART App Launch IG v2.2.0
