HL7 LCH Segment: Location Characteristic

The LCH (Location Characteristic) segment carries a single characteristic of a location, expressed as a coded identifier paired with a coded value. Characteristics describe properties of a location such as whether it is a smoking room, whether it has negative-pressure isolation, or whether it is wheelchair accessible. LCH is one of the detail segments in the location master-file group, used alongside LCC (Location Charge Code), LDP (Location Department), and LRL (Location Relationship).

Purpose

The purpose of LCH is to attach typed, coded characteristics to a location so that downstream systems can match patients to appropriate locations. Because each LCH instance carries one characteristic ID and one value, a location with several characteristics is described by repeating the LCH segment within the message rather than by repeating fields inside a single segment.

LCH 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 LCH is the detail segment that decorates that anchor with a characteristic facet.

Used in

LCH 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, LDP, LRL). 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/LCH.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
LCH-1	Primary Key Value - LCH	pl	—	R	—	—	Location this characteristic describes
LCH-2	Segment Action Code	id	—	O	—	—	Add, update, or delete action
LCH-3	Segment Unique Key	ei	—	O	—	—	Unique key for this characteristic row
LCH-4	Location Characteristic ID	ce	—	O	—	HL70324	Coded characteristic being described
LCH-5	Location Characteristic Value-LCH	ce	—	O	—	—	Value of the named characteristic

Most-used fields

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

LCH-4 Location Characteristic ID identifies which characteristic this row carries, drawn from HL7 Table 0324 (Location Characteristic ID). It is the key that tells the receiver how to interpret LCH-5.

LCH-5 Location Characteristic Value-LCH holds the value of the characteristic named in LCH-4. The pairing of LCH-4 and LCH-5 is the core payload of the segment.

LCH-2 Segment Action Code and LCH-3 Segment Unique Key support incremental master-file maintenance, letting a sender add, update, or remove a specific characteristic row without resending the whole location.

Version differences (2.3 to 2.8.2)

The LCH segment has a stable five-field shape across versions: primary key, segment action code, segment unique key, characteristic ID, and characteristic value. This layout is consistent from 2.3 through 2.8.2.

The notable evolution is in the coded data types. In 2.3 through 2.5.x the characteristic ID and value use CE; later releases move the same fields to CWE. The Segment Action Code (ID) and Segment Unique Key (EI) are unchanged in role. Table 0324 governs LCH-4 across these versions. When integrating with a newer-version partner, confirm whether coded fields arrive as CE or CWE so component parsing stays correct.

Common mistakes

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

Populating LCH-5 without a matching LCH-4. A value with no identifier is uninterpretable; the receiver does not know which characteristic it represents.

Misusing LCH-2 Segment Action Code during a full snapshot. Action codes are meant for incremental updates; mixing them into a full replacement load can cause inconsistent state on the receiver.

Assuming LCH repeats its fields. It does not — each LCH carries one characteristic. Multiple characteristics require multiple LCH segments.

Examples

Minimal LCH (primary key plus one characteristic ID and value):

LCH|W^389^01^FACILITYA^^N|||SMK^Smoking Status^HL70324|N^Non-Smoking^FACVAL

Fully populated LCH (with action code and unique key):

LCH|W^389^01^FACILITYA^^N|A|LCHKEY00451^FACILITYA|ISO^Isolation Capability^HL70324|NEG^Negative Pressure^FACVAL

Annotated breakdown:

LCH | W^389^01^FACILITYA^^N | A | LCHKEY00451^FACILITYA | ISO^Isolation Capability^HL70324 | NEG^Negative Pressure^FACVAL
 |          |                  |             |                          |                                    |
 |          |                  |             |                          |                                    +-> LCH-5 Characteristic Value
 |          |                  |             |                          +--------------------------------------> LCH-4 Location Characteristic ID (HL70324)
 |          |                  |             +-------------------------------------------------------------------> LCH-3 Segment Unique Key (EI)
 |          |                  +---------------------------------------------------------------------------------> LCH-2 Segment Action Code (ID)
 |          +------------------------------------------------------------------------------------------------------> LCH-1 Primary Key Value - LCH (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|MSG000461|P|2.5.1
MFI|LOC^Location Master^HL70175|||UPD|20260610091500|AL
MFE|MAD|EVT000461|20260610091500|389^01^FACILITYA|CE
LOC|W^389^01^FACILITYA^^N|Bed 389-01|B^Bed^HL70260|CARD^Cardiology^DEPT
LCH|W^389^01^FACILITYA^^N|||SMK^Smoking Status^HL70324|N^Non-Smoking^FACVAL

Second in-context excerpt (a second characteristic on the same location):

LCH|W^389^01^FACILITYA^^N|A|LCHKEY00462^FACILITYA|ADA^Wheelchair Accessible^HL70324|Y^Yes^FACVAL

FHIR mapping

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

Engine considerations

Interface engines model LCH as a repeating detail segment inside the MFN^M05 location group. Because each LCH carries exactly one characteristic, the engine must iterate every LCH occurrence and keep each associated with the LOC that precedes it via the primary key in LCH-1.

When the sender uses incremental maintenance, the engine should honor LCH-2 Segment Action Code and LCH-3 Segment Unique Key so updates and deletes target the right characteristic row. Coded fields should be passed through with code system intact for correct resolution against Table 0324.

How Vorro parses and produces LCH

Vorro parses LCH by resolving LCH-1 to the location anchor, then capturing each characteristic as an ID/value pair from LCH-4 and LCH-5. When present, the Segment Action Code and Segment Unique Key are used to apply incremental changes against the existing characteristic set for that location rather than overwriting it.

When producing LCH, Vorro emits one segment per characteristic, always leading with the primary key, and includes the action code and unique key only when the destination expects incremental maintenance. Coded elements are escaped and emitted with their source code system so the receiver can normalize them against Table 0324.

Sources

← Back to HL7 v2 Guide