Editorial illustration in constructivist-poster style depicting a constructivist PID vs Patient mapping panel with red mapped and grey unmapped rows
by: Lillian ChenPosted on:

PID vs Patient: What Maps and What Doesn't

The PID segment in HL7v2 and the Patient resource in FHIR describe the same person and disagree about how to say so. Most PID fields map cleanly to Patient fields; a subset maps with judgment; a handful does not map at all. Naming the categories up front is what separates a v2-to-FHIR bridge that works from one that quietly drops data.

Naming the mapping is the discipline. For related walkthroughs, related FHIR walkthroughs collects the surrounding material.

The Clean Mappings

Most of PID maps directly:

  • PID-3: patient identifier → Patient.identifier.
  • PID-5: patient name → Patient.name.
  • PID-7: date of birth → Patient.birthDate.
  • PID-8: administrative sex → Patient.gender.
  • PID-11: address → Patient.address.
  • PID-13: home phone → Patient.telecom.

These fields have clean semantics on both sides and translate mechanically. A pass through the site's HL7 v2 segment → FHIR mapping tool surfaces the field-by-field mapping.

The Fields That Need Judgment

Several PID fields require judgment during translation:

  • PID-4: alternate patient identifier. FHIR handles this as a second identifier entry with a different system. Multiple alternate IDs need explicit systems assigned.
  • PID-6: mother's maiden name. FHIR has an extension for this; the base spec does not carry it as a first-class field.
  • PID-10: race. US Core defines a specific extension; other IGs use different representations.
  • PID-22: ethnic group. Same story as race.

These fields have historical friction in FHIR modeling. The disciplined pattern is to use the most widely-adopted extension (US Core in the US context) and document the choice.

The Fields That Don't Really Map

A few PID fields have no clean FHIR home:

  • PID-24: multiple birth indicator. FHIR has Patient.multipleBirthBoolean and Patient.multipleBirthInteger, and the mapping is not obvious.
  • PID-25: birth order. Same as above.
  • PID-26: citizenship. Requires extensions.
  • PID-27: veteran military status. Requires extensions.

Every one of these fields carries real data in some workflows. Silent drops during translation lose that data. The v2-to-FHIR mapping project publishes canonical patterns for these; using them is more durable than inventing a house pattern. For the wider v2 anatomy, reading an HL7v2 message when you only know FHIR covers the shape.

The Merge Case Is Where It Gets Interesting

When two patient records get merged in the source system, downstream FHIR needs to reflect the merge. FHIR's approach is to keep both Patient resources and link them via Patient.link. The retired resource has Patient.active set to false.

The merge case is where a bridge earns its keep. Getting it right requires cooperation between the ADT event handling and the Patient mapping. For the specific ADT framing, the ADT event types you meet first in an integration covers the events that trigger merges.

The Language of Death

PID-29 and PID-30 report death indicators. FHIR expresses death through Patient.deceasedBoolean or Patient.deceasedDateTime. Mapping the death indicators is often the last thing a bridge implements and often the field a compliance officer notices first.

Downstream Impacts

Patient identity flows through to Observations, Encounters, and every resource that references the patient. A stale or wrong Patient mapping ripples across the entire FHIR archive. For the Observation side of the story, OBX segments and where they end up in a FHIR Observation covers the interaction.

Every v2 integration eventually meets the PID-vs-Patient conversation. Meeting it deliberately saves the postmortem later.

Constructivist-poster diagram of a two-column PID vs Patient field mapping with red mapped rows, blue partial rows, and grey unmapped rows arranged diagonally on a warm cream background

Sources