FHIR vs HL7 v2: A Technical Comparison for Integration Teams

HL7 v2 and FHIR both come from HL7 International, but they solve different problems. HL7 v2 is a messaging standard: when something happens (a patient is admitted, a result is finalized), the source system builds a message describing the event and pushes it to subscribers. FHIR is primarily a resource and API standard: data lives as addressable resources on a server, and clients read, search and write them when they need to.

That difference shapes everything else, from error handling to security to how you test. If you need the broader context of how HL7's standards relate, see HL7 vs FHIR.

A v2 message is a sequence of segments, each on its own line (separated by carriage returns on the wire). The first three characters name the segment. Fields are separated by |, components by ^, repetitions by ~, with \ as the escape character and & for subcomponents. The MSH segment declares those encoding characters, the message type, the sending and receiving applications and the v2 version.

MSH|^~\&|ADT_APP|GENHOSP|LAB_APP|GENHOSP|202611121030||ADT^A01^ADT_A01|MSG00001|P|2.5.1
EVN|A01|202611121030
PID|1||004512^^^GENHOSP^MR||Rivera^Ana||19840719|F|||12 Elm St^^Springfield^IL^62701
PV1|1|I|4WEST^412^B^GENHOSP||||1234^Patel^Raj^^^Dr|||MED||||7|||1234^Patel^Raj^^^Dr|IN||||||||||||||||||||||||||202611121015

Meaning depends on position: PID-3 is the patient identifier list, PID-5 the name, PID-7 the birth date, PV1-2 the patient class, PV1-3 the assigned location, PV1-44 the admit date/time. Every receiving system has to know those positions, and in practice each site has its own variations in which fields are populated and how.

FHIR expresses the same facts as named elements on separate resources that reference one another. The admission becomes, at minimum, a Patient and an Encounter:

{
  "resourceType": "Encounter",
  "id": "enc-7781",
  "status": "in-progress",
  "class": {
    "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
    "code": "IMP",
    "display": "inpatient encounter"
  },
  "subject": { "reference": "Patient/004512" },
  "participant": [
    { "individual": { "reference": "Practitioner/1234", "display": "Dr Raj Patel" } }
  ],
  "period": { "start": "2026-11-12T10:15:00-06:00" },
  "location": [
    { "location": { "reference": "Location/4west-412-b" } }
  ]
}

The Patient resource carries PID data (identifier with the MRN, name, gender, birthDate, address). Practitioner and Location resources represent the attending physician and bed. Self-describing element names and explicit code systems make FHIR easier to consume, at the cost of larger payloads.

FHIR is not only pull. R4 includes a Subscription resource, and R5 redesigned subscriptions around topics, with a backport implementation guide that brings topic-based subscriptions to R4. FHIR messaging (Bundles with a MessageHeader) also exists for event-style exchange. In practice, however, EHR support for FHIR subscriptions varies, so many teams still rely on v2 feeds or vendor-specific event mechanisms for real-time triggers and use FHIR to fetch the details.

HL7 has published v2-to-FHIR mapping guidance that defines how common message structures, segments and data types translate into FHIR resources. It is the right starting point, but plan for these realities:

• One message, many resources. An ADT^A01 can yield Patient, Encounter, Practitioner, Location, RelatedPerson (NK1), Coverage (IN1) and AllergyIntolerance (AL1).
• Identity resolution. You must decide whether an incoming PID matches an existing Patient, typically using identifier systems, and handle merges (ADT^A40) carefully.
• Event semantics. A08 (update), A03 (discharge) and A11 (cancel admit) translate into updates of existing resources, not new ones, so you need stable, deterministic resource ids.
• Z-segments and local conventions. Custom segments and repurposed fields need extensions or local profiles and a documented decision for each.
• Terminology. Local codes in OBX-3 or PV1-10 must be mapped to standard systems such as LOINC or to agreed value sets.

Few organizations can retire v2. The common patterns are:

• FHIR facade: an integration layer consumes v2 feeds and keeps a FHIR server or cache current, so apps and partners query FHIR while upstream systems keep sending v2. See FHIR server architecture for design options.
• Dual interfaces: the EHR's native FHIR API serves apps, while v2 continues to feed departmental systems that only speak v2.
• Trigger plus fetch: a lightweight v2 event or notification tells a service that something changed; the service then calls the FHIR API for authoritative data.
• Gradual migration: new consumers are onboarded on FHIR, and v2 interfaces are retired as downstream systems gain FHIR support. The FHIR migration service page outlines this work.

If your roadmap involves both, an experienced FHIR integration partner can help decide where a translation layer pays off and where direct v2 interfaces are still the simplest answer.