The DLT (Daily Deductible) data type was introduced in HL7 v2.5 to model a class of insurance benefits that flat-amount deductibles cannot express: a per-diem cost-share that begins after a delay period, runs for a bounded number of days, and rolls up to an accumulated maximum. DLT appears in insurance coverage detail fields where a plan needs to declare, for example, "after the first three inpatient days, the patient pays $200 per day for up to thirty days, capped at $6,000." A single MOP cannot carry this - DLT exists precisely because the daily structure is a payer-policy primitive.
Purpose
US-style Medicare-supplement and indemnity plans frequently structure inpatient cost-share as a daily amount with a delay (a waiting period before the deductible kicks in), a duration (how many days it applies), and a total cap. Encoding any one of those numbers alone misrepresents the benefit: a flat "$200 deductible" is wrong because it is per day; "$6,000 deductible" is wrong because the patient only owes it if they stay the full duration. DLT bundles all four facts - delay days, daily amount, number of days, total amount - so a receiver can compute patient liability for any given length of stay without consulting the plan document.
Components
Source: HAPI HL7v2 v2.8.1 javadoc (DLT).
| Comp | Name | Sub-type | Length | Required | Description |
|---|---|---|---|---|---|
| DLT.1 | Delay Days | nm | - | O | Number of days that must elapse before the daily deductible begins to apply (e.g. 3 means the deductible starts on day 4). |
| DLT.2 | Monetary Amount | mo | - | O | The deductible amount charged per day once the delay has elapsed. |
| DLT.3 | Number of Days | nm | - | O | The number of days over which the daily deductible applies. |
| DLT.4 | Total Amount | mo | - | O | The accumulated maximum the patient can be charged under this daily deductible. |
Most-used components
- DLT.2 Monetary Amount - the per-day figure receivers post to patient ledgers.
- DLT.3 Number of Days - bounds the exposure; without it, a daily charge is open-ended.
- DLT.4 Total Amount - the cap; receivers stop accruing patient liability once this is reached.
Where it's used
- IN2 daily-deductible benefit fields in coverage-detail messages.
- IN1 deductible overlay fields when the plan's deductible is structured per-diem rather than flat.
- IN3-23 Daily Charge fields where per-diem patient share interacts with per-diem plan charge.
- Custom Z-segments emitted by US-payer EDI bridges that translate Medicare-supplement daily deductible loops.
- Outbound 271 (Eligibility Response) generators that derive per-diem benefit lines from DLT.
Version differences
- HL7 v2.5 - DLT introduced with the four-component layout (delay, daily amount, days, total).
- HL7 v2.6 through v2.8 - no structural changes; MO sub-type tightened in line with the broader MO refinement (ISO 4217 alpha-3 in MO.2).
- HL7 v2.8.1 - HAPI javadoc confirms the four-component definition unchanged.
- HL7 v2.8.2 - no structural changes; table refreshes only.
Common mistakes
- Putting the daily amount in DLT.4 and leaving DLT.2 empty - receivers see a single total and treat it as a flat deductible, materially understating patient liability for short stays.
- Conflating DLT.1 Delay Days with DLT.3 Number of Days -
3^200^30(3-day delay, $200/day for 30 days) is very different from30^200^3; ordering matters. - Omitting DLT.4 Total Amount on plans that have a cap - without the cap, receivers either compute unbounded liability or invent one from the daily × days product, which is wrong when the cap is lower than that product.
- Using DLT.2/.4 as plain NM and dropping the MO currency sub-component - without ISO 4217 the amount is ambiguous across multi-country payer feeds.
- Treating DLT.1 =
0as "missing" -0is the meaningful value "no delay, starts on day 1" and must round-trip distinct from a truly empty DLT.1.
Examples
Minimal value - $200/day for 30 days, $6,000 max, no delay:
0^200.00^USD^30^6000.00^USD
Populated - $200/day with a 3-day delay, 30 days, $6,000 max:
3^200.00^USD^30^6000.00^USD
In context - IN2 daily-deductible field carrying a per-diem benefit:
IN2|1||||||||||||||||||||||0^200.00^USD^30^6000.00^USD||||||||||||||||||||||||||
Common pitfall - daily amount placed in the total slot:
^^^^200.00^USD <- WRONG; reads as a $200 flat total, not $200/day
0^200.00^USD^30^6000.00^USD <- CORRECT
FHIR mapping
The v2-to-FHIR Implementation Guide does not publish a per-datatype ConceptMap for DLT. The mapping target is Coverage.benefit with category set to a deductible code and the daily structure decomposed across the benefit's value, limit, and a small extension for the delay:
| DLT component | FHIR target |
|---|---|
| DLT.1 Delay Days | Coverage.benefit.extension[delay-days].valueUnsignedInt |
| DLT.2 Monetary Amount | Coverage.benefit.limit.value (per-day) with Coverage.benefit.unit = day |
| DLT.3 Number of Days | Coverage.benefit.limit.code carrying days; or a duration extension |
| DLT.4 Total Amount | Coverage.benefit.value[x] as Money representing the accumulated max |
In claim contexts the same content surfaces on ExplanationOfBenefit.benefitBalance.financial with allowed and used Money values.
Engine considerations
- Slot ordering: DLT is positional and easy to mis-emit; engines should validate that DLT.2 is the per-day amount and DLT.4 the cap, with DLT.4 ≥ DLT.2 (a one-day daily deductible can equal its cap, but never exceed it).
- Currency consistency: DLT.2.2 and DLT.4.2 must use the same ISO 4217 code; engines that allow mixed currencies (USD daily, CAD cap) produce nonsense ledgers.
- Cap reconciliation: when DLT.4 < DLT.2 × DLT.3, the cap binds first and receivers must honour the cap; engines should compute and surface this as a derived fact rather than re-deriving on the fly.
- BigDecimal precision: amounts carry minor units and require
BigDecimal; days are integers and must be parsed as such even though NM permits decimals. - Empty vs zero: DLT.1 =
0(no delay) and DLT.1 empty (unknown) must round-trip distinct - engines that normalise empty to zero on inbound corrupt the meaning.
How Vorro parses and produces DLT
On inbound, Vorro parses DLT as a structured DailyDeductible value object with delayDays: Optional<Int>, dailyAmount: Optional<Money>, numberOfDays: Optional<Int>, and totalAmount: Optional<Money>. Empties are preserved as None rather than coerced to zero. Currency is validated against ISO 4217 on both .2 and .4, and a same-currency invariant is enforced; violations route to a curation queue with provenance.
On outbound, Vorro emits DLT components in canonical order with explicit currency on every MO sub-component. Caps are emitted only when the source benefit record carries one - never synthesised from dailyAmount × numberOfDays. Where the source daily deductible is open-ended (no cap, no day count), Vorro emits only DLT.1 and DLT.2 and leaves DLT.3/.4 empty rather than fabricating sentinel values.
