FHIR vs HL7 v2: practical differences

HL7 v2 messages and FHIR resources compared for developers: format, transport, the same lab result in both, translation pitfalls, and where Anpheros accepts v2.

HL7 v2 is the message format hospital systems have exchanged since the late 1980s — pipe-delimited events such as "patient admitted" or "lab result ready" pushed between systems over a network connection — while HL7 FHIR is a web API standard where applications read and write resources such as Patient and Observation over HTTPS in JSON. They are not alternatives you pick once: most hospitals still run on v2 internally, new applications and patient-facing APIs use FHIR, and integration work is often translating one into the other. This page compares them on the points that matter when you write code, shows the same data in both, and explains where Anpheros accepts v2.

Side by side

	HL7 v2	HL7 FHIR R4
Style	Messages triggered by events (admit, order, result)	Resources you create, read, update, search
Format	Text segments separated by line breaks, fields by `\\|`, components by `^`	JSON (or XML)
Transport	Usually MLLP over TCP inside the hospital network	HTTPS REST
Query	Limited; systems mostly push	Search parameters, `_include`, history
Security	Network-level (VPN, private links)	OAuth 2.0 / SMART on FHIR, TLS, scopes
Flexibility	Many optional fields and local Z-segments; every interface is negotiated	Base resources plus profiles (US Core, IPS, European IGs)
Typical users	EHR, lab, radiology, billing systems inside a hospital	Apps, patient-access APIs, cross-organisation exchange, AI

The most common v2 messages:

Message	Meaning	Closest FHIR resources
ADT^A01, A03, A08	Admit, discharge, update patient	`Patient`, `Encounter`
ORM / OML	Order a test	`ServiceRequest`
ORU^R01	Result ready	`Observation`, `DiagnosticReport`
SIU	Scheduling	`Appointment`
MDM	Document	`DocumentReference`

The same lab result in both

An ORU^R01 result line (OBX segment):

OBX|1|NM|2093-3^Cholesterol^LN||212|mg/dL|<200|H|||F|||20261002074500

The same result as an HL7 FHIR R4 Observation, as Anpheros stores it after importing that message:

{
  "resourceType": "Observation",
  "status": "final",
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "laboratory"}]}],
  "code": {"coding": [{"system": "http://loinc.org", "code": "2093-3", "display": "Cholesterol [Mass/volume] in Serum or Plasma"}], "text": "Cholesterol"},
  "effectiveDateTime": "2026-10-02T07:45:00Z",
  "valueQuantity": {"value": 212.0, "unit": "mg/dL"},
  "interpretation": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation", "code": "H"}]}],
  "referenceRange": [{"high": {"value": 200.0, "unit": "mg/dL"}}]
}

Field by field: OBX-3 becomes code, OBX-5 and OBX-6 become valueQuantity, OBX-7 referenceRange, OBX-8 interpretation, OBX-11 status, OBX-14 effectiveDateTime. HL7 publishes an official HL7 Version 2 to FHIR implementation guide with mappings for segments, data types and vocabularies.

Where translations go wrong

Time zones. v2 timestamps such as 20261002074500 often carry no offset; you must know the sender's zone. FHIR requires a zone whenever a time is present. (Anpheros reads an unzoned v2 time as UTC; send the offset if you have it.)
Local codes. Many labs put their own codes in OBX-3 instead of LOINC. A good translation keeps the local code and maps it to LOINC when it can, rather than dropping it.
Repeated sends. v2 senders retransmit on timeouts. Without a stable identifier per result, a FHIR store fills with duplicates.
Optional everything. The same field can be empty, repeated or used differently by two senders. Validate the FHIR side; the FHIR R4 validator shows what a translated resource is missing.
Corrections. v2 result status C (corrected) should update the existing Observation and keep its history, not create a second one.

When to use which

Inside a hospital, between existing systems: v2 is usually what the systems speak. An integration engine routes and transforms messages.
Building an app, a patient-access API or anything that crosses organisations: FHIR, with OAuth and consent.
Feeding AI or analytics: FHIR, because it is queryable, coded and versioned.
Both: the common real-world pattern — receive v2 from the lab or EHR, store FHIR, serve FHIR to applications.

Where Anpheros fits

Anpheros stores patient records as FHIR R4 and accepts one HL7 v2 message type: ORU^R01 lab results, sent over HTTPS to the lab connector (POST /v1/patients/{id}/labs/import with Content-Type: x-application/hl7-v2+er7). Each OBX becomes a laboratory Observation with LOINC code, reference range and interpretation; the report id is kept in provenance and resent reports are skipped. A corrected result (OBX-11 = C) with a new value is stored as a new Observation with status amended; the original stays as it was, so if your source sends corrections, mark the earlier Observation entered-in-error or update it through the FHIR API. A worked example is Lab results API.

It does not accept other v2 messages (ADT, orders, scheduling), does not listen on MLLP and does not send v2. For those, an integration engine in front of Anpheros translates to FHIR and writes through the API.

Frequently asked questions

Is FHIR replacing HL7 v2?

Not soon. v2 remains the backbone inside most hospitals because it works and is built into existing systems. FHIR is growing around it — in apps, patient access and exchange between organisations — and the two coexist, often with translation between them.

What is MLLP?

The Minimal Lower Layer Protocol: a simple way of framing v2 messages over a TCP connection, with start and end characters around each message and an acknowledgement (ACK) back. FHIR uses HTTPS instead.

Can I convert HL7 v2 messages to FHIR automatically?

Mostly. HL7's v2-to-FHIR implementation guide gives standard mappings, and integration engines implement them. Expect manual work for local codes, Z-segments, time zones and how each sender uses optional fields.

Does Anpheros accept HL7 v2?

Yes, for lab results: ORU^R01 messages posted over HTTPS to the lab connector become FHIR Observations. Other v2 message types and MLLP connections are not supported.