HL7 LOC Segment: Location Identification

The LOC (Location Identification) segment carries the master-file definition of a healthcare location — a clinic, ward, room, bed, or any physical place where care is delivered or resources are tracked. It anchors a location record with a primary key, a human-readable description, and one or more location types, and it acts as the parent record to which the more detailed location segments (LDP, LCH, LRL) attach. LOC is the backbone of the Location Master File and is what downstream systems read to keep their facility directories synchronized.

Purpose

The LOC segment exists to define and maintain location records in a master file. It establishes the primary key that uniquely identifies a location across systems, describes what the location is, classifies it by type (for example, nursing unit or operating room), and records administrative attributes such as the organization that owns it, its address, phone numbers, license numbers, equipment, and the services offered there. When a master file message adds, updates, or deactivates a location, the LOC segment is the record that carries the identifying and descriptive payload.

Used in

LOC appears in MFN^M05 messages (Patient Location Master File Notification). In an M05 message it is the lead segment of the location detail group and is typically followed by LCH (Location Characteristic), LRL (Location Relationship), and one or more LDP (Location Department) groups that further qualify the location defined by LOC.

Field-by-field reference

Source: HAPI HL7v2 v2.5.1 javadocs (LOC) 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
LOC-1	Primary Key Value - LOC	pl	—	R	—	—	Unique key identifying this location record
LOC-2	Location Description	st	—	O	—	—	Human-readable description of the location
LOC-3	Location Type - LOC	is	—	O	Y	HL70260	Functional classification of the location
LOC-4	Organization Name - LOC	xon	—	O	Y	—	Organization that owns or operates the location
LOC-5	Location Address	xad	—	O	Y	—	Physical address of the location
LOC-6	Location Phone	xtn	—	O	Y	—	Telephone or contact number for the location
LOC-7	License Number	ce	—	O	Y	—	Regulatory license number for the location
LOC-8	Location Equipment	is	—	O	Y	HL70261	Fixed equipment available at the location
LOC-9	Location Service Code	is	—	O	—	HL70442	Service category provided at the location

Most-used fields

LOC-1 Primary Key Value - LOC: the required identifier that ties the location to LDP, LCH, and LRL records and to references elsewhere in the system. Every consumer keys on this.
LOC-2 Location Description: the plain-text label most user interfaces display, so it is almost always populated even though optional.
LOC-3 Location Type - LOC: drives routing and filtering logic; integration engines frequently branch on the location type code.
LOC-4 Organization Name - LOC: used to attribute the location to an owning facility or enterprise in multi-entity systems.
LOC-8 Location Equipment: relevant for bed and room records where equipment availability affects scheduling and assignment.

Version differences (2.3 to 2.8.2)

The LOC segment was introduced as part of the master files chapter to support location master synchronization and has remained remarkably stable. In v2.3 the core fields (primary key, description, type, organization, address, phone, license number, equipment) were already present. Through v2.4 and into v2.5.1 the field roster is unchanged; v2.5.1 is the version documented here and matches the HAPI javadocs above, including the nine fields with LOC-9 Location Service Code. Later releases (2.6, 2.7, 2.8.x) retain the same nine fields without structural change — refinements in those versions are confined to table content and data-type clarifications rather than added or removed fields. As a result, a parser written against v2.5.1 LOC will interoperate cleanly with neighboring versions.

Common mistakes

Omitting LOC-1 or leaving its component structure flat: LOC-1 is a PL (Person Location) data type with structured components; treating it as a simple string breaks downstream key matching.
Treating LOC-3 Location Type as single-valued: it is optional-repeating, so a location can carry several type codes; consumers that read only the first repetition lose information.
Confusing the LOC location key with the LDP department key: LOC defines the location, LDP defines the department-level detail; mixing the two produces orphaned records.
Sending free text in LOC-3, LOC-8, or LOC-9 instead of coded values from the bound HL7 tables.
Assuming LOC-5 address and LOC-6 phone are single instances; both repeat, and dropping repetitions discards alternate contact paths.

Examples

A minimal valid segment (only the required primary key):

LOC|WEST-3B^^^MERCYGEN

A fully-populated segment:

LOC|WEST-3B^^^MERCYGEN|West Wing 3B Med-Surg Unit|N~ICU|1234^Mercy General Hospital^^^^NPI^XX^^^1093817465|500 Riverside Dr^^Cedar Falls^IA^50613^USA|^^^^^319^5550148|RX-44219^State Pharmacy Board^STBOARD~LAB-90871^State Lab Board^STBOARD|VENT~MON|MED

Annotated breakdown:

LOC|WEST-3B^^^MERCYGEN|West Wing 3B Med-Surg Unit|N~ICU|...
    |                 |                            |
    |                 |                            +--> LOC-3 Location Type (repeats: N, ICU)
    |                 +-------------------------------> LOC-2 Location Description
    +-------------------------------------------------> LOC-1 Primary Key Value (PL)

LOC|...|1234^Mercy General Hospital^...|500 Riverside Dr^^Cedar Falls^IA^50613^USA|...
        |                               |
        |                               +--> LOC-5 Location Address (XAD)
        +------------------------------------> LOC-4 Organization Name (XON)

LOC|...|^^^^^319^5550148|RX-44219^State Pharmacy Board^STBOARD|VENT~MON|MED
        |                |                                     |        |
        |                |                                     |        +--> LOC-9 Location Service Code
        |                |                                     +-----------> LOC-8 Location Equipment (repeats)
        |                +-----------------------------------------------> LOC-7 License Number (CE, repeats)
        +----------------------------------------------------------------> LOC-6 Location Phone (XTN)

In-context excerpt inside an MFN^M05 message:

MSH|^~&|FACMGR|MERCYGEN|ADT|MERCYGEN|20260610142500||MFN^M05^MFN_M05|MSG00012|P|2.5.1
MFI|LOC^Location Master^HL70175|MERCYGEN|UPD|20260610142500|20260610142500|AL
MFE|MUP|CTRL-0001|20260610142500|WEST-3B^^^MERCYGEN|PL
LOC|WEST-3B^^^MERCYGEN|West Wing 3B Med-Surg Unit|N|1234^Mercy General Hospital|500 Riverside Dr^^Cedar Falls^IA^50613^USA|^^^^^319^5550148
LCH|WEST-3B^^^MERCYGEN|||SMOK^Smoking^HL70260|Y^Yes^HL70136

A second in-context excerpt with a department detail group following LOC:

MSH|^~&|FACMGR|MERCYGEN|ADT|MERCYGEN|20260610150000||MFN^M05^MFN_M05|MSG00013|P|2.5.1
MFI|LOC^Location Master^HL70175|MERCYGEN|UPD|20260610150000|20260610150000|AL
MFE|MAD|CTRL-0002|20260610150000|EAST-201^^^MERCYGEN|PL
LOC|EAST-201^^^MERCYGEN|East Tower Room 201|N~ICU|1234^Mercy General Hospital|500 Riverside Dr^^Cedar Falls^IA^50613^USA|^^^^^319^5550199|RX-44219^State Pharmacy Board|VENT~MON|ICU
LDP|EAST-201^^^MERCYGEN|ICU^Intensive Care^HL70069|||A|||20260601

FHIR mapping

No segment-level ConceptMap is published in the v2-to-FHIR IG for LOC. Conceptually, a LOC record corresponds to a FHIR Location resource, which models a physical place — a building, ward, room, or bed — where services are provided or resources are stored. Fields such as LOC-1 map naturally to Location.identifier, LOC-2 to Location.name or description, LOC-3 to Location.type, LOC-5 to Location.address, and LOC-6 to Location.telecom, but these correspondences are conceptual rather than a published transform.

Engine considerations

Integration engines treat LOC as a keyed master record, so the dominant concern is stable, deterministic handling of LOC-1. Engines should parse the full PL component structure, not just the first component, and use the combined key for matching against existing location records. Because LOC-3, LOC-4, LOC-5, LOC-6, LOC-7, and LOC-8 all repeat, engine mappings must iterate repetitions rather than reading a single occurrence. When transforming to a downstream directory, preserve the location type codes verbatim so receiving systems can re-apply their own table lookups. Engines that flatten LOC into a relational store typically normalize the repeating address and phone fields into child tables keyed on LOC-1.

How Vorro parses and produces LOC

When Vorro ingests an MFN^M05 message, it reads LOC-1 as the primary location key and indexes the record under it, retaining every component of the PL so re-emission is lossless. Repeating fields (LOC-3 through LOC-8) are parsed into ordered collections, and coded fields are validated against the configured HL7 tables with unknown codes flagged but passed through rather than dropped. On the production side, Vorro composes LOC from a normalized location model: it writes the primary key, fills LOC-2 from the location label, emits each location type as a separate repetition in LOC-3, and serializes address, phone, license, and equipment collections back into their repeating fields. Empty optional fields are emitted as empty positions to preserve field alignment for strict downstream parsers.

Sources

← Back to HL7 v2 Guide