Every integration discussion in a hospital reaches the same fork: should this interface be HL7 v2 or FHIR? The honest answer is that most working hospitals need both for years, and the useful question is which to use where.
What each is good at
HL7 v2 is an event notification format. Something happened — a patient was admitted, an order was placed, a result was verified — and a message announces it. It is pipe-delimited, decades old, universally implemented, and almost every device and legacy system in your building can speak it today.
FHIR is a resource API. You ask for a patient, an observation, an imaging study, and receive structured JSON over HTTP. It is far better for applications that need to query data rather than react to events, and it is what any modern application developer expects.
A working rule
Use HL7 v2 for machine-to-machine event flows inside the hospital, especially where a vendor already supports it: ADT feeds, order messages, result delivery, analyser interfacing. Fighting a vendor to build a FHIR endpoint they do not have is a project with no clinical payoff.
Use FHIR at the edges: mobile apps, patient portals, partner integrations, analytics pipelines, anything built new. These are the consumers that benefit from query semantics and structured resources.
The pattern that works
Run an integration engine that ingests HL7 v2 events, normalises them, and exposes a FHIR facade over the result. Internal systems keep speaking the protocol they already implement. New applications get a modern API. Neither side blocks the other, and you can replace legacy feeds one at a time without a coordinated migration.
What decides success
Not the protocol. The edge cases.
- What happens to a malformed segment at 2am?
- How is a duplicate result message detected and suppressed?
- Can a message be replayed after a downstream outage?
- Who is paged when a feed goes silent, and how quickly?
An interface without message-level tracing, replay and alerting will fail quietly, and you will learn about it from a clinician. Build the observability before you build the second interface.
Terminology is the harder half
Protocol is the easy part. Agreeing that this lab code means the same thing as that one — LOINC for observations, SNOMED CT for clinical findings, ICD-10 for diagnoses — is the work that determines whether the data is actually usable once it arrives. Budget for it explicitly.
Filed under Interoperability, HL7, FHIR