HL7 LRL Segment: Location Relationship

The LRL (Location Relationship) segment describes a relationship between a location and another location or an organization. It is how the location master file expresses hierarchy and association, such as which nursing unit a bed belongs to or which organization operates a clinic. LRL is one of the detail segments in the location master-file group, used alongside LOC (Location Identification), LCC (Location Charge Code), LCH (Location Characteristic), and LDP (Location Department).

Purpose

The purpose of LRL is to connect a location to a related entity through a typed, coded relationship. The relationship type is named in LRL-4, and the related entity is carried either as an organization in LRL-5 or as a location in LRL-6 depending on the nature of the relationship. This lets receivers build location hierarchies and resolve which organizational or physical parent a location reports to.

LRL refers back to the parent LOC segment through its primary key value. Consistent with the location-master terminology used across these pages, LOC is the location anchor and LRL is the detail segment that decorates that anchor with relationship facets.

Used in

LRL appears in location master-file detail messages, specifically the MFN^M05 (Master File Notification - Location) message. Within that message it follows the LOC segment that establishes the location identity, together with the other detail segments (LCC, LCH, LDP). See MFN for the full message structure.

Field-by-field reference

Source: HAPI HL7v2 v2.5.1 javadocs (https://hapifhir.github.io/hapi-hl7v2/v251/apidocs/ca/uhn/hl7v2/model/v251/segment/LRL.html) for sequence, name, data type, and repetition. Length is not published in the javadocs (—); Required and Table # are filled from the HL7 v2.5.1 standard where well-established.

Seq	Name	Data Type	Length	Req	Repeat	Table #	Description
LRL-1	Primary Key Value - LRL	pl	—	R	—	—	Location this relationship describes
LRL-2	Segment Action Code	id	—	O	—	—	Add, update, or delete action
LRL-3	Segment Unique Key	ei	—	O	—	—	Unique key for this relationship row
LRL-4	Location Relationship ID	ce	—	O	—	HL70325	Coded type of the relationship
LRL-5	Organizational Location Relationship Value	xon	—	O	Y	—	Related organization for the relationship
LRL-6	Patient Location Relationship Value	pl	—	O	—	—	Related location for the relationship

Most-used fields

LRL-1 Primary Key Value - LRL is read first by every receiver. It is the normalized link back to the LOC segment and to the location whose relationship is being described.

LRL-4 Location Relationship ID names the relationship type, drawn from HL7 Table 0325. It tells the receiver how to interpret the related entity in LRL-5 or LRL-6.

LRL-6 Patient Location Relationship Value carries the related location when the relationship is location-to-location, for example a bed that belongs to a nursing unit.

LRL-5 Organizational Location Relationship Value carries the related organization when the relationship is location-to-organization, and it repeats to express more than one organizational association.

Version differences (2.3 to 2.8.2)

The LRL segment has a stable six-field shape across versions: primary key, segment action code, segment unique key, relationship ID, organizational relationship value, and patient location relationship value. This layout is consistent from 2.3 through 2.8.2.

The coded relationship ID uses CE in 2.3 through 2.5.x and CWE in later releases, and the XON used for LRL-5 is consistent in role across these versions. Table 0325 governs LRL-4 throughout. When integrating with a newer-version partner, confirm whether the coded relationship ID arrives as CE or CWE so component parsing stays correct.

Common mistakes

Sending LRL without LRL-1. The relationship cannot be associated with any location and the segment is dropped.

Populating both LRL-5 and LRL-6 ambiguously. The relationship value belongs in the field that matches the relationship type in LRL-4; placing an organization in the location field, or vice versa, breaks hierarchy resolution.

Treating LRL-5 as single-valued. It repeats, so collapsing multiple organizational relationships into one loses associations.

Misusing LRL-2 Segment Action Code during a full snapshot load. Like the other detail segments, action codes are for incremental maintenance and should not be mixed into full replacement loads.

Examples

Minimal LRL (primary key plus relationship type and a related location):

LRL|W^389^01^FACILITYA^^N|||PAR^Parent Location^HL70325||3W^^^FACILITYA^^N

Fully populated LRL (action code, unique key, organizational relationship value):

LRL|W^389^01^FACILITYA^^N|A|LRLKEY00451^FACILITYA|ORG^Operating Organization^HL70325|1001^Riverside Cardiology Group^^^^FACILITYA^XX^^^1001|

Annotated breakdown:

LRL | W^389^01^FACILITYA^^N | A | LRLKEY00451^FACILITYA | ORG^Operating Organization^HL70325 | 1001^Riverside Cardiology Group^... | (empty)
 |          |                  |             |                          |                                       |                          |
 |          |                  |             |                          |                                       |                          +-> LRL-6 Patient Location Relationship Value (PL)
 |          |                  |             |                          |                                       +----------------------------> LRL-5 Organizational Relationship Value (XON, repeats)
 |          |                  |             |                          +------------------------------------------------------------------> LRL-4 Location Relationship ID (HL70325)
 |          |                  |             +-----------------------------------------------------------------------------------------------> LRL-3 Segment Unique Key (EI)
 |          |                  +---------------------------------------------------------------------------------------------------------------> LRL-2 Segment Action Code (ID)
 |          +------------------------------------------------------------------------------------------------------------------------------------> LRL-1 Primary Key Value - LRL (PL)
 +-----------------------------------------------------------------------------------------------------------------------------------------------> Segment ID

In-context excerpt inside an MFN^M05 message, following MFI/MFE and the LOC segment:

MSH|^~&|FACADM|FACILITYA|LOCMGR|FACILITYA|20260610091500||MFN^M05^MFN_M05|MSG000481|P|2.5.1
MFI|LOC^Location Master^HL70175|||UPD|20260610091500|AL
MFE|MAD|EVT000481|20260610091500|389^01^FACILITYA|CE
LOC|W^389^01^FACILITYA^^N|Bed 389-01|B^Bed^HL70260|CARD^Cardiology^DEPT
LRL|W^389^01^FACILITYA^^N|||PAR^Parent Location^HL70325||3W^^^FACILITYA^^N

Second in-context excerpt (an organizational relationship on the same location):

LRL|W^389^01^FACILITYA^^N|A|LRLKEY00482^FACILITYA|ORG^Operating Organization^HL70325|1001^Riverside Cardiology Group^^^^FACILITYA^XX^^^1001|

FHIR mapping

LRL is not mapped at the segment level. No segment-level ConceptMap is published in the v2-to-FHIR IG for LRL. Conceptually, the location master data that LRL decorates maps to the FHIR Location resource, where location-to-location relationships align with Location.partOf and location-to-organization relationships align with Location.managingOrganization; however, no normalized published mapping exists for this segment. Treat any LRL-to-FHIR transformation as a local design decision.

Engine considerations

Interface engines model LRL as a repeating detail segment inside the MFN^M05 location group, kept associated with the preceding LOC via the primary key in LRL-1. Because a location can participate in several relationships, the engine must iterate all LRL occurrences.

The engine should route the relationship value to the correct field based on the relationship type in LRL-4, preserve repetition on LRL-5, and honor the Segment Action Code and Segment Unique Key when incremental maintenance is in use. Coded fields should be passed through with code system intact for resolution against Table 0325.

How Vorro parses and produces LRL

Vorro parses LRL by resolving LRL-1 to the location anchor, reading the relationship type from LRL-4, and capturing the related entity from LRL-5 or LRL-6 according to that type. Repeating organizational values are collected into a normalized list, and the action code and unique key are used to apply incremental changes when present.

When producing LRL, Vorro emits the primary key first, then the relationship type, and places the related entity into the organization or location field that matches the type. Repetitions on the organizational value are preserved, action code and unique key are emitted only for incremental maintenance, and coded elements are escaped and emitted with their source code systems, including Table 0325 for Location Relationship ID.

Sources

← Back to HL7 v2 Guide