HL7 v2 → FHIR: the mental model
Pipes and segments vs. resources and references — the one mapping mindset that makes every v2-to-FHIR project make sense.
The answer in one paragraph
HL7 v2 is a message: a pipe-delimited telegram announcing an event ("patient admitted", "result ready"), built from segments like PID and OBX, meaningful mostly in the moment it is sent. FHIR is a graph of resources: persistent, individually addressable records (Patient, Observation, Encounter) linked by references. Mapping between them is therefore not field-renaming — it is converting event telegrams into facts about entities. Get that shift, and every PID-to-Patient table you ever read becomes obvious; miss it, and v2's quirks will fight you on every interface.
Reading a v2 message without fear
MSH|^~\&|HIS|GH|LIS|GH|202606121030||ADT^A01|MSG0001|P|2.5
PID|1||MRN-1042^^^SIDHI^MR||Sharma^Priya||19980412|F
PV1|1|I|3W^301^A
Three rules decode 90% of it: segments are lines with three-letter names (MSH =
header, PID = patient identity, PV1 = visit, OBX = an observation); fields are
split by | and counted from 1 (PID-3 is the third field — patient identifiers);
components split fields by ^ (inside PID-3: the ID, then its assigning
authority). The message type (ADT^A01 = admit) tells you which segments to expect.
The mapping mindset, concretely
| v2 thinks… | FHIR thinks… |
|---|---|
| Event message (ADT^A01 happened) | State + event resources (Patient, Encounter) |
| Segment in this message | Resource with its own identity and URL |
PID-3 with assigning authority SIDHI | Patient.identifier with system as a URI |
| OBX segment inside a result message | Observation referencing Patient & Encounter |
| Implicit context (sender knows) | Explicit references and code systems |
Two conversions trip everyone first time. Identifiers: v2 carries ID + authority in
components; FHIR demands the authority become a globally unique identifier.system
URI — leaving it empty is the classic mapper warning. Codes: v2 fields often hold
local codes; FHIR bindings expect proper systems (LOINC for OBX-3, SNOMED CT for
problems) — so mapping projects are terminology projects in disguise.
Why v2 refuses to die (and why that's fine)
v2 runs the world's hospital interfaces: ADT feeds, lab results, billing triggers — decades of working plumbing. Realistic architectures convert at the boundary: an integration engine listens to v2 (often over the MLLP socket protocol), transforms, and posts FHIR — the official v2-to-FHIR Implementation Guide now standardises those segment-to-resource mappings so you are not inventing them per project.
Where to go next
Resources, profiles & references — the FHIR side's grammar in depth. And when the FHIR Mapper lab opens, this exact ADT message is the one you will map, hands-on.