The LDP (Location Department) segment describes the department that owns a location, along with the services offered there, the specialties involved, the patient classes the location accepts, and its activation status. It is the richest of the location master-file detail segments and is used alongside LOC (Location Identification), LCC (Location Charge Code), LCH (Location Characteristic), and LRL (Location Relationship).
Purpose
The purpose of LDP is to associate a location with an owning department and to record the operational attributes of that department-location pairing: which services and specialties it supports, which patient classes it can admit, when it is active, and how to reach it. A single location can be described by more than one LDP segment when it is shared across departments, and several of LDP's fields repeat to capture multiple services, specialties, and patient classes.
LDP 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 LDP is the detail segment that decorates that anchor with the department facet.
Used in
LDP 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, 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/LDP.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 |
|---|---|---|---|---|---|---|---|
| LDP-1 | Primary Key Value - LDP | pl | — | R | — | — | Location this department entry describes |
| LDP-2 | Location Department | ce | — | O | — | — | Department owning the location |
| LDP-3 | Location Service | is | — | O | Y | HL70069 | Services offered at the location |
| LDP-4 | Specialty Type | ce | — | O | Y | — | Clinical specialties for the location |
| LDP-5 | Valid Patient Classes | is | — | O | Y | — | Patient classes the location accepts |
| LDP-6 | Active/Inactive Flag | id | — | O | — | — | Whether the location is active |
| LDP-7 | Activation Date LDP | ts | — | O | — | — | Date the location became active |
| LDP-8 | Inactivation Date - LDP | ts | — | O | — | — | Date the location became inactive |
| LDP-9 | Inactivated Reason | st | — | O | — | — | Reason the location was inactivated |
| LDP-10 | Visiting Hours | vh | — | O | Y | — | Visiting hours for the location |
| LDP-11 | Contact Phone | xtn | — | O | — | — | Contact phone for the location |
| LDP-12 | Location Cost Center | ce | — | O | — | — | Cost center for the location |
Most-used fields
LDP-1 Primary Key Value - LDP is read first by every receiver. It is the normalized link back to the LOC segment and to the location being described.
LDP-2 Location Department names the owning department and is the field that gives the segment its identity within the master file.
LDP-3 Location Service is a repeating field, drawn from HL7 Table 0069, that lists the services available at the location. It is heavily used for routing and matching.
LDP-6 Active/Inactive Flag, together with LDP-7 Activation Date and LDP-8 Inactivation Date, governs whether the location-department pairing is currently usable. Receivers commonly key bed-availability logic off these fields.
Version differences (2.3 to 2.8.2)
The LDP segment grew over time. Earlier versions carried the core department, service, specialty, patient-class, and activation fields; later releases added the visiting-hours, contact-phone, and cost-center fields seen in the 2.5.1 twelve-field layout. The twelve-field shape is stable through 2.5.x.
As with the other location detail segments, coded fields that use CE in 2.3 through 2.5.x are expressed as CWE in later releases, and the VH (visiting hours) composite for LDP-10 should be confirmed against the negotiated version since some implementations omit it. Table 0069 governs LDP-3 Location Service across these versions. When integrating with a newer partner, verify the field count and coded-element flavor before mapping.
Common mistakes
Sending LDP without LDP-1. The department information cannot be associated with any location and the segment is dropped.
Collapsing repeating fields. LDP-3, LDP-4, LDP-5, and LDP-10 all repeat; flattening them to a single value loses services, specialties, patient classes, or visiting-hours blocks.
Ignoring the Active/Inactive Flag. Treating every LDP as active leads downstream systems to route patients to closed or decommissioned locations.
Confusing LDP-2 Location Department with the LCC-2 charge-code department reference. They point at the same concept but live in different detail segments and should be reconciled, not assumed identical.
Examples
Minimal LDP (primary key plus department and one service):
LDP|W^389^01^FACILITYA^^N|CARD^Cardiology^DEPT|MED
Fully populated LDP (repeating services, specialties, patient classes, status, visiting hours, phone, cost center):
LDP|W^389^01^FACILITYA^^N|CARD^Cardiology^DEPT|MED~CCU|CAR^Cardiology^SPEC~TEL^Telemetry^SPEC|I~O|A|20240101000000||||MON-FRI 1400-2000|^PRN^PH^^^1^5550101234|CC1001^Cardiology Cost Center^COST
Annotated breakdown:
LDP | W^389^01^FACILITYA^^N | CARD^Cardiology^DEPT | MED~CCU | CAR^...~TEL^... | I~O | A | 20240101000000 | ... | MON-FRI 1400-2000 | ^PRN^PH^... | CC1001^...
| | | | | | | | | | |
| | | | | | | | | | +-> LDP-12 Location Cost Center
| | | | | | | | | +----------------> LDP-11 Contact Phone
| | | | | | | | +-------------------------------------> LDP-10 Visiting Hours (repeats)
| | | | | | | +-------------------------------------------------------> LDP-7 Activation Date
| | | | | | +----------------------------------------------------------------> LDP-6 Active/Inactive Flag
| | | | | +---------------------------------------------------------------------> LDP-5 Valid Patient Classes (repeats)
| | | | +-----------------------------------------------------------------------------------> LDP-4 Specialty Type (repeats)
| | | +------------------------------------------------------------------------------------------------> LDP-3 Location Service (repeats, HL70069)
| | +-------------------------------------------------------------------------------------------------------------------> LDP-2 Location Department
| +-------------------------------------------------------------------------------------------------------------------------------------------> LDP-1 Primary Key Value - LDP (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|MSG000471|P|2.5.1
MFI|LOC^Location Master^HL70175|||UPD|20260610091500|AL
MFE|MAD|EVT000471|20260610091500|389^01^FACILITYA|CE
LOC|W^389^01^FACILITYA^^N|Bed 389-01|B^Bed^HL70260|CARD^Cardiology^DEPT
LDP|W^389^01^FACILITYA^^N|CARD^Cardiology^DEPT|MED|CAR^Cardiology^SPEC|I|A|20240101000000
Second in-context excerpt (a second location-department detail in the same notification):
MFE|MAD|EVT000472|20260610091500|412^03^FACILITYA|CE
LOC|W^412^03^FACILITYA^^N|Bed 412-03|B^Bed^HL70260|ICU^Intensive Care^DEPT
LDP|W^412^03^FACILITYA^^N|ICU^Intensive Care^DEPT|MED~CCU|CCM^Critical Care^SPEC|I|A|20240101000000|||| |^PRN^PH^^^1^5550109876|CC2002^ICU Cost Center^COST
FHIR mapping
LDP is not mapped at the segment level. No segment-level ConceptMap is published in the v2-to-FHIR IG for LDP. Conceptually, the location master data that LDP decorates maps to the FHIR Location resource, with the owning department aligning to Location.managingOrganization or a related Organization, and operational status aligning to Location.status; however, no normalized published mapping exists for this segment. Treat any LDP-to-FHIR transformation as a local design decision.
Engine considerations
Interface engines model LDP as a repeating detail segment inside the MFN^M05 location group, kept associated with the preceding LOC via the primary key in LDP-1. Because a shared location can have more than one LDP, the engine must iterate all occurrences rather than assuming one per location.
Repeating fields (LDP-3, LDP-4, LDP-5, LDP-10) must be preserved on parse and round-trip. Date and timestamp fields should be normalized to a consistent precision, and the Active/Inactive Flag should drive any availability logic the engine derives.
How Vorro parses and produces LDP
Vorro parses LDP by resolving LDP-1 to the location anchor, then capturing the department, the repeating service, specialty, and patient-class lists, the activation status and dates, and the contact and cost-center details into a normalized department record. The Active/Inactive Flag and date fields are used to compute a derived availability state.
When producing LDP, Vorro emits the primary key first, then the department and its repeating lists in the configured order, followed by status, dates, visiting hours, phone, and cost center. Repetitions are preserved, timestamps are formatted to the destination's expected precision, and coded elements are escaped and emitted with their source code systems, including Table 0069 for Location Service.
Related pages
- LOC Segment: Location Identification
- LCH Segment: Location Characteristic
- MFN Message: Master File Notification
