HL7 DLD Data Type: Discharge to Location and Date

The DLD (Discharge to Location and Date) data type was introduced in HL7 v2.3 to carry the two facts that close an inpatient encounter: where the patient is being discharged to and the date or timestamp on which that disposition takes effect. It is the data type behind PV1-37 Discharged to Location, the field every ADT^A03 (Discharge) message uses to communicate disposition to billing, quality reporting, and post-acute coordination systems.

Purpose

Discharge disposition drives downstream behavior far beyond a single message. It determines DRG payment grouping under Medicare, triggers post-acute referrals (skilled nursing facility, home health, hospice), populates HEDIS and quality measures, and feeds readmission-risk models. DLD exists to transmit disposition as a coded value with effective timestamp — not as free text — so that "home", "skilled nursing facility", "left against medical advice", and "expired" are unambiguous categories that downstream systems can route on without text-matching guesswork.

Component table

Source: HAPI HL7v2 v2.8.1 javadocs (DLD).

Most-used components

• DLD.1 Discharge to Location — the coded disposition; the field every downstream consumer routes on.
• DLD.2 Effective Date — the timestamp at which the patient physically left under that disposition; used to compute length-of-stay and to anchor 30-day readmission windows.

Where it's used

• PV1-37 Discharged to Location — the canonical DLD field, present on every ADT^A03 Discharge message.
• PV2-?? — some site-specific PV2 profiles surface DLD as an extension field to carry pre-admission planned-discharge dispositions.
• DRG and quality-reporting extension segments in custom profiles often re-use DLD where the planned discharge disposition needs to be communicated alongside the actual.

Version differences

• HL7 v2.3 — DLD introduced with two components: Discharge to Location as IS (HL70113), Effective Date as DT.
• HL7 v2.5 — DLD.1 promoted from IS to CWE to carry full coding-system metadata (allowing senders to declare which version of HL70113 they used and to send local extensions).
• HL7 v2.5.1 / v2.6 — DLD.2 promoted from DT to DTM to carry the time-of-day along with the discharge date, supporting same-day-readmission analytics.
• HL7 v2.7 / v2.8 / v2.8.1 — no further structural change; HAPI v2.8.1 javadoc reflects the CWE + DTM pairing.

Common mistakes

• Sending DLD.1 as free text ("Home with home health") instead of a HL70113 code — downstream DRG and quality engines cannot categorize the disposition and fall back to "Other", suppressing the message from reports.
• Populating DLD.2 with a DT value in a v2.7+ profile — receivers expecting DTM parse a zero time-of-day and same-day readmission rules misfire.
• Confusing DLD.1 with PV1-36 Discharge Disposition — PV1-36 carries the disposition (the discharge status code), PV1-37 (DLD) carries the location to which the patient was discharged. They are related but not interchangeable.
• Omitting the coding-system component of the CWE on DLD.1 — receivers cannot tell whether the code came from HL70113, a local table, or an HL7-defined update.
• Sending DLD.2 set to admission date because the discharge timestamp wasn't yet known at message build — receivers compute a zero-length encounter and reject it.

Examples

Minimal value (location code only):

HOME

Coded discharge to home with effective timestamp:

HOME^Home^HL70113^20260605120000

Discharge to skilled nursing facility with timestamp:

SNF^Skilled Nursing Facility^HL70113^20260605143000

Against medical advice:

AMA^Left Against Medical Advice^HL70113^20260605091500

In context — PV1-37 on an ADT^A03 Discharge message:

MSH|^~&|ADT|MERCY^2.16.840.1.113883.19.5^ISO|EHR|MERCY|20260605143000||ADT^A03^ADT_A03|MSG00415|P|2.8.1
EVN|A03|20260605143000
PID|1||MR884412^^^MERCY&2.16.840.1.113883.19.5&ISO^MR|TESTPATIENT^ALEX^Q||19720508|F
PV1|1|I|3W^315^A^MERCY|||||1234567890^SMITH^JANE^^^DR^MD^^^^^NPI|||MED|||||SELF|||V0000172||||||||||||||||||||||MERCY|||||20260601073000|20260605120000|||||||HOME^Home^HL70113^20260605120000

Common pitfall — free-text location:

PV1|1|I||||||||||||||||||V0000172||||||||||||||||||||||MERCY|||||20260601|20260605|||||||Home with family

Downstream DRG grouping cannot categorize "Home with family" and the encounter is filed under "Other" disposition, suppressing it from CMS quality reports.

FHIR mapping

The v2-to-FHIR IG publishes a DLD ConceptMap at ConceptMap-datatype-dld-discharge-to-location. DLD decomposes into two FHIR elements on the Encounter resource.

Where the disposition references a downstream organization (transfer to a specific SNF or hospice), the mapping also produces an Encounter.hospitalization.destination reference to a Location or Organization resource.

Engine considerations

• DLD.1's promotion from IS to CWE between v2.3 and v2.5 is a quiet breaking change for parsers — v2.5+ messages carry coding-system metadata that v2.3 parsers discard, causing round-trip data loss when bridging versions.
• DLD.2's promotion from DT to DTM similarly affects parsers: a v2.3 message has no time-of-day, so the receiver must default to facility-local end-of-day before computing 30-day readmission windows.
• PV1-37 vs PV1-36 must not be conflated by the engine — they are two distinct fields and downstream consumers depend on both being populated independently.
• HAPI HL7v2 v2.8.1 generates ca.uhn.hl7v2.model.v281.datatype.DLD with two typed accessors (getDischargeLocation returning CWE, getEffectiveDate returning DTM).

How Vorro parses and produces DLD

Vorro normalizes DLD.1 against HL70113 plus a curated set of CMS Patient Discharge Status codes (so that a HOME from one partner and 01 from another both resolve to the same internal disposition). DLD.2 is normalized to a UTC instant with facility-local time-zone provenance preserved, so that same-day readmission analytics work correctly across multi-time-zone hospital systems.

On outbound, Vorro always emits a fully populated CWE in DLD.1 — code, display, coding-system, and (where required) coding-system version — and always emits DLD.2 as a DTM with second precision so that v2.5+ receivers can compute length-of-stay accurately. For partners stuck on v2.3 profiles, Vorro down-converts DLD.1 to a bare IS code and DLD.2 to a DT date, flagging the loss in message provenance metadata.

Related pages

• CWE data type — Coded With Exceptions
• PV1 segment — Patient Visit
• PV2 segment — Patient Visit Additional Information

Sources

• HAPI HL7v2 v2.8.1 javadoc — DLD data type
• HAPI HL7v2 v2.8.1 apidocs index
• HL7 v2 product brief
• v2-to-FHIR ConceptMap — DLD to Discharge to Location