HL7 PL Person Location
HL7 datatype components PL components from HL7 v2.5.1 Hide components
These are the generated components for the version selected at the top of the page. The article stays practical, and this panel follows the chosen HL7 version.
Components
| Pos | Component | Name | Type | Table | Description |
|---|---|---|---|---|---|
| 1 | PL.1 | Point of Care | IS | 0302 | Point of Care; Type IS; HL7 table 0302. |
| 2 | PL.2 | Room | IS | 0303 | Room; Type IS; HL7 table 0303. |
| 3 | PL.3 | Bed | IS | 0304 | Bed; Type IS; HL7 table 0304. |
| 4 | PL.4 | Facility | HD | 0300 | Facility; Type HD; HL7 table 0300. |
| 5 | PL.5 | Location Status | IS | 0306 | Location Status; Type IS; HL7 table 0306. |
| 6 | PL.6 | Person Location Type | IS | 0305 | Person Location Type; Type IS; HL7 table 0305. |
| 7 | PL.7 | Building | IS | 0307 | Building; Type IS; HL7 table 0307. |
| 8 | PL.8 | Floor | IS | 0308 | Floor; Type IS; HL7 table 0308. |
| 9 | PL.9 | Location Description | ST | Location Description; Type ST. | |
| 10 | PL.10 | Comprehensive Location Identifier | EI | Comprehensive Location Identifier; Type EI. | |
| 11 | PL.11 | Assigning Authority for Location | HD | Assigning Authority for Location; Type HD. |
PL is the HL7 v2 datatype for a person location. In everyday interface work, that usually means a patient location: facility, point of care, room, bed, and some extra pieces for type, status, building, floor, description, and location identity.
You see PL most often in PV1-3 Assigned Patient Location, but it also appears in prior, temporary, pending, scheduling, provider, contact, order, dispense, death, and location master workflows. If the receiving system cares where someone is, PL is usually nearby.
The biggest PL trap is treating location as a pretty string. ICU 214 bed B is useful to a person, but it is weak for matching, routing, bed management, census, and transfer processing. PL gives you separate components so the receiver can tell the difference between a unit, a room, a bed, a facility, and a descriptive label.
This example says the point of care is ICU, the room is 214, the bed is B, the facility is CITYHOSP, the location type is nursing unit, the building is TowerA, the floor is 2, and there is both a human description and a comprehensive location identifier. Real feeds are often shorter, but the order of the parts matters.
PL-1 to PL-4: Point of Care, Room, Bed, and Facility
PL-1 is the point of care: a nursing unit, clinic, department, ward, service area, or other local care location code. PL-2 is the room. PL-3 is the bed. PL-4 is the facility, using HD so the location can be tied to the site that owns it.
The standards text describes the location identifiers from general to specific as facility, building, floor, point of care, room, and bed. The PL component order is not quite that natural hierarchy, so mapping teams need to be explicit. Do not assume ICU^214^B is globally unique unless the facility and local bed dictionary make it so.
Facility is easy to skip in a single-hospital pilot and painful to add later. Multi-site organizations often reuse ward, room, and bed codes. Also, MSH-4 Sending Facility, PV1-39 Servicing Facility, and PL-4 Facility can mean different things. Keep that agreement written down.
PL-5 to PL-6: Location Status and Person Location Type
PL-5 is the location status. Sites use it to distinguish active, inactive, occupied, closed, or other locally governed states depending on the table agreement. It is operational data, so a stale value can be worse than an empty one.
PL-6 is the person location type. The local v2.5.1 table includes values such as clinic, department, home, nursing unit, provider office, phone, and skilled nursing facility. This is where a home-care or phone encounter can avoid pretending it has a room and bed.
These two components are not substitutes for the actual location path. A nursing-unit type does not tell you which nursing unit. A status value does not tell you whether the patient is currently there, pending there, or was previously there. The surrounding field still matters.
PL-7 to PL-9: Building, Floor, and Description
PL-7 and PL-8 add building and floor detail. They are very useful in campuses where a unit code is not enough to find the patient, or where the same clinic service exists in more than one building.
PL-9 is the location description. Use it as a description, not as the primary key. A description like ICU 214 bed B is helpful for displays, labels, and manual review, but it should not be the only thing a receiver uses for matching.
Descriptions are text, so they need normal HL7 delimiter safety. If a location description comes from a free-text source and might contain ^, &, |, or line breaks, write it through encoded setters or helpers such as HL7Encode(). Better yet, keep the coded location components clean and let the description be optional decoration.
PL-10 to PL-11: Comprehensive Location Identifier and Assigning Authority
PL-10 is a comprehensive location identifier using EI. It is useful when the location dictionary has a durable location ID, especially in enterprise bed management, master location feeds, scheduling resources, and systems that need a key stronger than the visible room-bed code.
PL-11 is the assigning authority for the location, using HD. If PL-10 is populated from a location master, PL-11 should say whose location master minted that identifier. That matters when a central integration engine receives locations from more than one ADT, scheduling, facilities, or EHR platform.
Do not use PL-10 as a place for another display string. If there is no durable location ID, leave it empty or agree one. A fake comprehensive location identifier creates the same matching problem as a fake patient identifier, just with fewer obvious alarms.
Where PL Shows Up Most
In ADT work, PL is a core part of PV1: current location in PV1-3, prior location in PV1-6, temporary location in PV1-11, pending location in PV1-42, and prior temporary location in PV1-43. Those fields are different on purpose.
Scheduling messages use PL for appointment/contact/resource locations, especially around SCH and AIL-style workflows. Orders and pharmacy feeds may use it for enterer location, orderable-at location, or dispense-to location. Provider and contact segments use it when the location of a person or organization is operationally relevant.
Current, Prior, Temporary, and Pending Locations
PL only describes a location value. The field tells you what kind of location it is. PV1-3 is the current assigned location. PV1-6 is the previous assigned location relevant to the event. PV1-11 is temporary. PV1-42 is pending. Mixing those up is how patients appear in two beds, disappear from the bed board, or get routed to the wrong printer, team, or work queue.
A transfer message should usually make both sides obvious: where the patient is now and where they came from. A pending transfer should not look like a completed transfer unless the receiver has explicitly agreed to treat it that way.
Practical Implementation Advice
Start by agreeing the location dictionary. Which system owns facility codes, unit codes, room numbers, bed IDs, building names, floor codes, and comprehensive location IDs? Then map PL from that dictionary instead of scraping display text.
In Integration Soup transformations, lookup tables are usually more useful for PL than string prettifying helpers. Use helpers such as Default() cautiously: a harmless display fallback for PL-9 is one thing, but defaulting an empty current location to a real unit or bed can make operational data dangerously wrong.
If the source sends one mixed value, split it only when you have a reliable pattern or lookup. Guessing that the last character is always a bed works right up until room names, surge beds, hallway beds, virtual locations, or clinic rooms turn up.
In HL7 Soup Web, the interpretation view can help you follow a PL value back to the exact facility, point of care, room, bed, type, or status component in the raw message. That is especially helpful when PV1-3, PV1-6, PV1-11, and PV1-42 all appear in the same workflow and the difference between current, prior, temporary, and pending location really matters.
Official Description and References
The HL7 v2+ PL definition describes this datatype as specifying a patient location within a healthcare institution, with the valued components depending on site needs. It also notes that PL may refer to other healthcare-setting locations, and that location identifiers should be thought of from most general to most specific: facility, building, floor, point of care, room, and bed.
For formal reference, compare the generated component panel above with the HL7 v2+ PL logical model and the HL7 v2+ PL detailed definitions.
Related Datatypes and Segments
For nearby datatype work, look at HD for facility and assigning authority, EI for comprehensive location identifiers, XAD for postal addresses, and XTN for location contact details. For common segment uses, start with PV1-3, PV1-6, PV1-11, PV1-42, SCH, ORC-13, and location-master segments such as LOC, LCH, LCC, LDP, and LRL.