HL7 PL Data Type: Person Location

The PL (Person Location) data type was introduced in HL7 v2.3 to give physical-location fields enough structure to survive across facilities, EHRs, and downstream FHIR Location resources. A PL composite carries the point of care, room, bed, facility, location status, location type, building, floor, a free-text description, and a comprehensive location identifier with its assigning authority. It is the canonical encoding for every location-shaped field in PV1 — Assigned Patient Location, Prior Patient Location, Temporary Location, Pending Location, Prior Temporary Location — and shows up in OBR and several other segments wherever a physical location must be named with structure.

Purpose

A single free-text location string ("3 West Bed 301A") is unparseable across facilities. PL forces the sender to split that string into typed slots so the receiver can join against its own master location list, route the patient to the right care team, and (for FHIR consumers) populate a structured Location resource without natural-language parsing. The structure also makes location semantics — is this a ward, a clinic, an ambulance? — explicit via the Person Location Type code, instead of leaving the receiver to infer it from the name.

Component reference

Source: HAPI HL7v2 v2.8.1 javadocs — PL. PL has 12 components separated by ^. Length is not published in the javadocs (—).

The first three components are the human-readable address; the next five qualify the location's place in the facility hierarchy; the last four make the location globally identifiable.

Most-used components

• PL.1 Point of Care — the nursing unit or department code; in inpatient ADT this is the field downstream routers join on.
• PL.2 Room — the room number.
• PL.3 Bed — the bed identifier within the room (A, B, 01, 02).
• PL.4 Facility — disambiguates the location when the same room number exists at multiple facilities (a real concern in multi-hospital systems).
• PL.6 Person Location Type — declares what kind of location this is. Receivers should always populate this for non-inpatient locations (ED, clinic, OR) so consumers don't infer the wrong location type from the name.

Where it's used

• PV1-3 Assigned Patient Location — the canonical use; the patient's current location at the time of the message.
• PV1-6 Prior Patient Location — where the patient was before this admission/transfer.
• PV1-11 Temporary Location — used during transient moves (off-unit procedures).
• PV1-42 Pending Location — where the patient is scheduled to go next.
• PV1-43 Prior Temporary Location — the previous temporary location.
• OBR-19 Placer Field 1 / OBR-44 in some profiles where the order's location is captured.
• Various Z-segments in vendor specifications that elected PL for richer location structure.

PL is overwhelmingly an ADT data type, with secondary use in Orders.

Version differences

• v2.3 — PL introduced with 9 components (through PL.9 Location Description).
• v2.4 / v2.5 / v2.5.1 — structurally stable; coding-system table memberships refined.
• v2.6 — added PL.10 Comprehensive Location Identifier and PL.11 Assigning Authority for Location to give the location a globally unique identifier in its own right.
• v2.7 / v2.7.1 — minor table-membership clarifications.
• v2.8 / v2.8.1 / v2.8.2 — PL.12 added in the v2.8.x line as a coded companion to PL.6 for profiles requiring a richer vocabulary.

Field-level PL retypes (e.g. PV1-3 PL components growing additional sub-components) happened independently of PL itself; the composite shape has been stable since v2.6.

Common mistakes

• Concatenating the whole address into PL.1 — 3W-301-A^^^MERCY. Receivers cannot route on a stuffed string; the room and bed must occupy PL.2 and PL.3.
• Leaving PL.4 empty in multi-facility deployments. The same room number exists at multiple hospitals; without PL.4 the receiver routes the patient to the wrong building.
• Sending PL.6 = N (nursing unit) for ED or clinic locations. The type code drives downstream workflow; mis-typing an ED visit as inpatient cascades into the wrong census reports.
• Using free-text values in PL.1 / PL.2 / PL.3 instead of the site's IS table codes. The receiver's master location list joins on the codes; free-text values silently fall through.
• Omitting PL.10 / PL.11 when the facility has a global location ID. FHIR consumers depend on PL.10 to resolve Location resources without natural-language parsing.

Examples

Minimal — point of care only:

3W

Three-component — unit / room / bed:

3W^301^A

Multi-component — full inpatient location with facility, building, floor:

3W^301^A^MERCY^^N^TOWER3^3

Reads: 3 West, room 301, bed A, facility MERCY, location type N (nursing unit), building TOWER3, third floor.

Operating room — location type drives interpretation:

OR-5^^^MERCY^O^OR^MAIN^2

With comprehensive location identifier and assigning authority:

3W^301^A^MERCY^^N^TOWER3^3^^LOC-12345&MERCY&2.16.840.1.113883.19.9&ISO^MERCY&2.16.840.1.113883.19.5&ISO

In context — PV1-3 Assigned Patient Location:

PV1|1|I|3W^301^A^MERCY^^N^TOWER3^3|||||||||||||||V0001

In context — PV1-3 followed by PV1-6 Prior Patient Location:

PV1|1|I|3W^301^A^MERCY^^N^TOWER3^3||| |||||||||||ED^TRIAGE^^MERCY^^E

Common pitfall — free-text point of care:

PV1|1|I|Three West Room 301 Bed A|||||||||||||||V0001

The receiver's location master joins on the IS code 3W, not the free-text phrase; the patient falls into an unrouted bucket.

FHIR mapping

The HL7 v2-to-FHIR Implementation Guide publishes ConceptMap-datatype-pl-to-location, which maps PL into a Location resource (typically a chain of nested Locations linked by partOf).

The output is typically a chain of four to six nested Location resources, not a single flat one. Engines that flatten the chain lose the partOf semantics that FHIR consumers expect.

Engine considerations

• IS table joins — PL.1 / PL.2 / PL.3 / PL.5 / PL.6 / PL.7 / PL.8 are IS codes drawn from site-defined tables. Engines must validate against the receiver's master location list at the boundary, not pass codes through unchecked.
• Facility scoping — PL components are scoped by PL.4. The same 3W at two facilities is two different locations. Engines that strip PL.4 collapse the namespace and create routing collisions.
• Nested Location chains for FHIR — the v2-to-FHIR ConceptMap expects PL to expand into a chain of Locations via partOf. Engines that emit a single flat Location with a stuffed name string break downstream FHIR consumers.
• Status semantics — PL.5 is the location's status (occupied / unoccupied / housekeeping), not the patient's status. Confusing the two leads to wrong census reports.
• HAPI typing — ca.uhn.hl7v2.model.v281.datatype.PL exposes getPl1_PointOfCare() through getPl12_LocationType(), returning IS / HD / ST / EI / CWE as appropriate.

How Vorro parses and produces PL

On inbound, Vorro parses PL into a typed Location record with explicit slots for point-of-care, room, bed, facility, status, type, building, floor, description, and comprehensive identifier. We validate PL.1 / PL.2 / PL.3 / PL.6 against the site's master location list at the boundary; codes that don't resolve are preserved (we never silently drop) but flagged so downstream routers know not to treat them as canonical.

On outbound, Vorro emits PL with PL.4 always populated for multi-facility deployments — the facility namespace is the single biggest source of routing collisions, and our default is to refuse to emit a bare unit code without its facility. For FHIR-sourced messages we expand a nested Location.partOf chain back into PL.1 / PL.2 / PL.3 / PL.7 / PL.8 by walking the partOf chain and reading the physicalType on each link, so the round trip through FHIR doesn't lose hierarchical structure.

Related pages

• HD data type — Hierarchic Designator
• EI data type — Entity Identifier
• PV1 segment — Patient Visit

Sources

• HAPI HL7v2 v2.8.1 javadoc — PL datatype
• HAPI HL7v2 v2.8.1 apidocs index
• HL7 v2 product brief
• HL7 v2-to-FHIR IG — PL to Location ConceptMap