The LCC (Location Charge Code) segment carries the charge codes associated with a single location in the location master file. It links a physical location, expressed as a primary key, to the accommodation types and billing charge codes that apply when a patient occupies that location. LCC is one of the detail segments in the location master-file group, sitting alongside LDP (Location Department), LCH (Location Characteristic), and LRL (Location Relationship).
Purpose
The purpose of LCC is to publish the billing and charge information for a location so downstream systems can apply the correct charges when the location is used. A single location can carry multiple accommodation types and multiple charge codes, which is why LCC-3 and LCC-4 repeat. The segment is descriptive rather than transactional: it describes how a location should be billed, not an individual billing event.
LCC always refers back to the parent LOC segment through its primary key value. The location-master terminology used throughout these pages treats LOC as the location anchor and LCC, LCH, LDP, and LRL as detail segments that decorate that anchor with specific facets.
Used in
LCC 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 (LCH, 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/LCC.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 |
|---|---|---|---|---|---|---|---|
| LCC-1 | Primary Key Value - LCC | pl | — | R | — | — | Location this charge entry describes |
| LCC-2 | Location Department | ce | — | O | — | — | Department owning the location charges |
| LCC-3 | Accommodation Type | ce | — | O | Y | — | Accommodation level the charge applies to |
| LCC-4 | Charge Code | ce | — | O | Y | — | Billing charge codes for the location |
Most-used fields
LCC-1 Primary Key Value - LCC is the field every receiver reads first. It is the normalized link back to the LOC segment and to the location being charged, and without it the rest of the segment has no anchor.
LCC-4 Charge Code is the payload most billing systems care about. It is a repeating field, so a single location can be associated with several charge codes at once.
LCC-2 Location Department ties the charge entry to the owning department, which matters when charges are routed or reconciled by department.
LCC-3 Accommodation Type qualifies the charge by accommodation level (for example a private versus semi-private room), allowing the same location to bill differently by accommodation.
Version differences (2.3 to 2.8.2)
The LCC segment was introduced as part of the location master-file detail group and has been remarkably stable across versions. The four-field structure (primary key, location department, accommodation type, charge code) seen in 2.5.1 is consistent from 2.3 onward. The repetition on Accommodation Type and Charge Code is present across these releases.
Across 2.3 through 2.8.2 the practical differences are confined to the underlying data types rather than the field layout: the CE data type used for LCC-2, LCC-3, and LCC-4 is the coded element of the 2.3 through 2.5.x era, while later releases lean on CWE for the same coded fields. The segment's role within MFN^M05 is unchanged. Always confirm the coded-element flavor against the negotiated version when interfacing with a partner on a newer release.
Common mistakes
Sending LCC without a populated LCC-1 primary key. The receiver cannot associate the charge information with any location, so the segment is effectively discarded.
Treating LCC-4 Charge Code as a single value. It repeats, and collapsing multiple charge codes into one repetition loses billing detail.
Confusing LCC-2 Location Department with the LDP segment. LCC-2 is a coded reference to a department; LDP is a separate detail segment describing the department facet of the location. They are related but not interchangeable.
Reusing the same component separators inside CE fields without escaping. Charge codes that contain reserved characters must be escaped or they will fragment the field.
Examples
Minimal LCC (primary key plus a single charge code):
LCC|W^389^01^FACILITYA^^N|||ROOMCHG^Daily Room Charge^FACCHG
Fully populated LCC (department, repeating accommodation types, repeating charge codes):
LCC|W^389^01^FACILITYA^^N|CARD^Cardiology^DEPT|PVT^Private^ACCT~SEMI^Semi-Private^ACCT|ROOMCHG^Daily Room Charge^FACCHG~TELCHG^Telemetry Charge^FACCHG
Annotated breakdown:
LCC | W^389^01^FACILITYA^^N | CARD^Cardiology^DEPT | PVT^...~SEMI^... | ROOMCHG^...~TELCHG^...
| | | | |
| | | | +-> LCC-4 Charge Code (repeats)
| | | +----------------------> LCC-3 Accommodation Type (repeats)
| | +---------------------------------------------> LCC-2 Location Department
| +------------------------------------------------------------------------> LCC-1 Primary Key Value - LCC (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|MSG000451|P|2.5.1
MFI|LOC^Location Master^HL70175|||UPD|20260610091500|AL
MFE|MAD|EVT000451|20260610091500|389^01^FACILITYA|CE
LOC|W^389^01^FACILITYA^^N|Bed 389-01|B^Bed^HL70260|CARD^Cardiology^DEPT
LCC|W^389^01^FACILITYA^^N|CARD^Cardiology^DEPT|PVT^Private^ACCT|ROOMCHG^Daily Room Charge^FACCHG
Second in-context excerpt (a second location detail in the same notification):
MFE|MAD|EVT000452|20260610091500|412^03^FACILITYA|CE
LOC|W^412^03^FACILITYA^^N|Bed 412-03|B^Bed^HL70260|ICU^Intensive Care^DEPT
LCC|W^412^03^FACILITYA^^N|ICU^Intensive Care^DEPT|SEMI^Semi-Private^ACCT~PVT^Private^ACCT|ICUCHG^ICU Daily Charge^FACCHG~MONCHG^Monitoring Charge^FACCHG
FHIR mapping
LCC is not mapped at the segment level. No segment-level ConceptMap is published in the v2-to-FHIR IG for LCC. Conceptually, the location master data that LCC decorates maps to the FHIR Location resource; the charge codes themselves align more naturally with ChargeItemDefinition concepts, but no normalized published mapping exists for this segment. Treat any LCC-to-FHIR transformation as a local design decision rather than a standardized mapping.
Engine considerations
Most interface engines model LCC as a repeating detail segment within the MFN^M05 location group. When iterating the group, the engine should keep LCC associated with the LOC that immediately precedes it, because the primary key in LCC-1 is the only link back to the location.
Engines that flatten repeating fields must preserve repetition on LCC-3 and LCC-4; flattening to a single occurrence silently drops charge data. Coded elements should be passed through with their code system intact so the receiver can resolve the charge codes against the correct table.
How Vorro parses and produces LCC
Vorro parses LCC by first resolving LCC-1 to the location anchor, then collecting the repeating Accommodation Type and Charge Code occurrences into a normalized list keyed by that anchor. The Location Department in LCC-2 is captured as a coded reference and cross-checked against the corresponding LDP detail when one is present in the same message.
When producing LCC, Vorro emits the primary key first, then department, then the repeating accommodation and charge-code lists in the order configured for the destination. Component separators inside coded elements are escaped automatically, and empty repetitions are suppressed so the outgoing segment stays compact and standards-compliant.
Related pages
- LOC Segment: Location Identification
- LDP Segment: Location Department
- MFN Message: Master File Notification
