Ask a conference panel and the answer is FHIR. Ask the integration engine at a working hospital and the answer is that 80% of what flows through it is still HL7v2 over MLLP — and will be for years. Both answers are true, which is why “which standard?” is the wrong question. The right question is: for this interface, who consumes the data, and what do they already speak?
The checklist we actually use
Choose HL7v2 when the consumer is a clinical system that already runs on it. ADT feeds, lab results into the EHR, orders out to the LIS — these paths are v2 today at nearly every site. Building a FHIR facade in front of a system that natively ingests ORU messages adds a translation layer, a failure mode, and zero clinical value.
Choose FHIR when the consumer is an application. Patient-facing apps, dashboards, analytics, anything mobile — these teams speak REST and JSON, and handing them a v2 feed means every app team writes its own parser badly. One FHIR API amortizes that cost across every future consumer.
Device data specifically tends to split. Observations destined for the chart usually travel the v2 path because that’s what the EHR interface accepts on the receiving end. The same observations destined for monitoring dashboards, fleet analytics, or research are better served as FHIR Observation resources from the start.
The trap: migrating for its own sake
The most expensive interface projects we see are v2-to-FHIR migrations with no new consumer. If nothing new reads the data, the migration bought risk and spent budget. Migrate when a consumer needs FHIR, not when a roadmap slide does.
What this means for your architecture
Design the boundary, not the standard: device and departmental data lands in one place where both representations can be produced. Then each interface picks its representation by consumer. That’s the architecture we build in our EHR Integration Accelerator — the engine owns the translation once, and no downstream team ever writes an HL7 parser again.