Anyone who has to connect a product to a hospital system soon meets two names: HL7 v2 and FHIR. Both come from the same standards organization, both move health data between systems, and both are alive in production. They are not rivals competing for the same slot, though. They reflect different eras of design, and a healthcare product often has to deal with both. This article compares them and sets out how to choose an approach for a given integration.
Two ways of moving health data
HL7 v2 is message based. A sending system emits a message when something happens, such as a patient being admitted, a lab result being finalized or an order being placed, and a receiving system parses it. Messages are made of segments, and segments are made of delimited fields. The trigger events and message types are well known to anyone who has worked in hospital interfacing, and many hospital systems still exchange data this way.
FHIR, Fast Healthcare Interoperability Resources, is the newer HL7 standard. It organizes health data into resources with their own identity, such as Patient or Observation, and exposes them through a RESTful API with JSON or XML payloads. The HL7 comparison of FHIR and v2 notes that FHIR also supports event-based messaging in the manner of v2, through a MessageHeader resource, as well as documents, REST and other service models. FHIR therefore covers more interaction styles than v2, not only a replacement format.
Where the two differ in practice
The comparison page lays out the structural differences, and four of them affect engineering decisions.
Granularity. A v2 segment roughly corresponds to a FHIR resource, but segments cannot be handled independently. A FHIR resource has an identity of its own and can be fetched, updated and referenced directly.
Extensibility. v2 implementations add local Z-segments, whose meaning is opaque without a manual explanation. FHIR extensions can appear at any level, and each one is defined at a URI, so a developer can look up what it means.
Variation. According to the same page, v2 implementations vary widely enough that consistent mapping rules are not realistic, and mapping is usually done per implementation. Anyone who plans to integrate with ten v2 feeds should expect ten mapping exercises.
Updates. v2 can send partial changes by action codes. FHIR works with full snapshots by default, with Patch as an alternative, so converting between the two means deciding how to turn partial updates into complete resources.
A decision framework
No single answer fits every product. The following questions usually settle the choice.
What does the other side expose? This question outweighs the others. If a hospital’s lab system only emits v2 messages, the integration will consume v2, whatever the product team would prefer. If an EHR offers a FHIR API for the data in question, that is generally the more convenient route for a new application.
Does the product read on demand or react to events? An application that fetches a patient’s records when a clinician opens it fits the request and response model of FHIR. A workflow that must react as soon as an admission or result occurs fits the event model of v2, or FHIR messaging, or subscriptions where the server supports them.
Does the product need to be understood by outsiders? FHIR’s discoverable structure, public specification and tooling make onboarding of new developers easier. A v2 interface often depends on documents specific to one site.
How much data is involved? Single-record exchange and bulk movement call for different mechanisms. Bulk export of populations is a separate concern from interactive reads, and it should be planned separately.
Who maintains it? Whichever route is chosen, someone has to own the mapping, the monitoring and the response to version changes.
The usual answer is both
Many healthcare products end up with a hybrid architecture. Legacy systems and departmental feeds, such as lab, radiology and admissions, continue to emit v2. Newer interfaces and patient-facing or clinician-facing applications use FHIR. An integration layer in the middle translates between them, normalizes identifiers and gives the product one internal model to work with.
This layer is where much of the engineering lives. It has to handle duplicate messages, out-of-order events, identity matching and the conversion rules described above. Teams that treat it as a side detail often find that it governs the reliability of the whole product.
JetRuby’s offer in this area is EHR and EMR integration engineering: the engineering side of connecting products through FHIR, HL7 and payer and provider APIs. Clinical and insurance questions belong to the clinical and compliance people who own the product.
A practical sequence
A sequence that keeps the decision grounded:
Start by listing the systems that must be connected and, for each, the interface the owner actually offers: v2 feed, FHIR API or something else. Take this from documentation and from the system owner, not from assumption.
Next, check what the FHIR server declares about itself. The capabilities interaction of the FHIR R4 RESTful API requires a server to provide a capability statement, so a team can see which resources and interactions are supported before writing code.
Then define the product’s internal model, and map each source into it once. Keep the mapping in code that can be tested with sample messages and sample resources.
Finally, plan for change. Interfaces get upgraded, local extensions appear and feeds are retired. Versioned mappings and monitoring turn those events from emergencies into routine maintenance.
Conclusion
HL7 v2 and FHIR are tools for different situations, and healthcare products rarely get to choose only one. The decision follows from what the connected systems expose, how the product uses the data and who will maintain the integration over time. A team that answers those questions up front can pick an approach per interface and avoid rebuilding it later.
