The DT-Range (Date Range) data type carries a calendar-day interval — a start date and an end date — as a single composite field. It is the date-only sibling of DR, which uses DTM (date-time) precision on each end of the interval. DT-Range exists for the many real-world intervals in healthcare where the time-of-day is either unknown or irrelevant: insurance coverage periods, license validity ranges, eligibility windows, reporting periods, and billing cycles all align to calendar days and do not need second-precision endpoints.
Purpose
A great deal of healthcare data is bounded by date intervals rather than instants. An insurance card is valid from one date through another. A license is in good standing for a year. A reporting period runs from the first of a month to the last. Encoding these as two separate DT fields invites bugs where one end is populated and the other is not, or where the start and end are mixed up. DT-Range packages both endpoints into one composite so that the interval is transmitted (and validated) as a unit. The use of DT — not DTM — keeps the data honest: senders are not pretending to know a time-of-day that has no operational meaning.
Component table
Source: HL7 v2 spec product brief and HAPI HL7v2 v2.8.1 javadocs. DT-Range mirrors DR but with DT-precision endpoints.
| Comp | Name | Sub-type | Length | Required | Description |
|---|---|---|---|---|---|
| DT-Range.1 | Range Start Date | dt | — | R | First calendar day included in the interval (YYYYMMDD). |
| DT-Range.2 | Range End Date | dt | — | O | Last calendar day included in the interval (YYYYMMDD); omitted for open-ended ranges. |
Most-used components
- DT-Range.1 Range Start Date — anchors the interval; receivers treat the entire start day as included.
- DT-Range.2 Range End Date — closes the interval; omission means an open-ended range (still in effect).
Where it's used
- Insurance coverage period fields where date-only precision is sufficient (some IN1 / IN2 profile variants).
- License and credential validity ranges in custom STF / PRA extensions.
- Eligibility and benefit windows in financial messages.
- Reporting-period fields on aggregate batch headers.
- Site-specific extension fields wherever a calendar-day interval is required and DR's DTM precision would be misleading.
Version differences
- HL7 v2.3 — DR (Date/Time Range) introduced as the general-purpose interval type; integrations needing date-only semantics used two DT fields side by side.
- HL7 v2.5+ — date-only interval semantics became more common as profiles distinguished "calendar day" intervals from "timestamp" intervals; DR remained the canonical composite but the spec recognized date-only usage.
- HL7 v2.7 / v2.8 / v2.8.1 — no new dedicated DT-Range class is shipped by HAPI in v2.8.1; implementations either reuse DR with date-only string values or model DT-Range as a logical alias for DR. The semantic distinction is preserved in profile documentation rather than in a separate generated class.
Common mistakes
- Sending DTM strings (
20260101120000) in a DT-Range field — receivers expectingYYYYMMDDeither reject the value or silently truncate, losing the time-of-day intent that should not have been there in the first place. - Inverting start and end (
20261231^20260101) — most engines flag inverted ranges but a few accept them and compute a negative duration that breaks downstream analytics. - Treating an omitted end date as an error — open-ended ranges (still-active coverage, license that has not yet been renewed) legitimately omit DT-Range.2; receivers must tolerate the omission.
- Mixing DT-Range with DR in the same profile without documentation — downstream developers cannot tell whether time-of-day matters for a given field.
- Sending a single date instead of a range (
20260101) — receivers parse the start but find no end and may default to the same date, producing a one-day range when the sender meant open-ended.
Examples
Calendar-year coverage period:
20260101^20261231
Calendar month reporting window:
20260601^20260630
Open-ended coverage (still in effect):
20260101
Single-day eligibility window (start equals end):
20260605^20260605
In context — an insurance coverage period carried in an IN1 extension field (site-specific profile that uses DT-Range rather than DR for date-only coverage):
MSH|^~&|ADT|MERCY^2.16.840.1.113883.19.5^ISO|EHR|MERCY|20260610105500||ADT^A08^ADT_A01|MSG00172|P|2.8.1
EVN|A08|20260610105500
PID|1||MR884412^^^MERCY&2.16.840.1.113883.19.5&ISO^MR|TESTPATIENT^ALEX^Q||19720508|F
IN1|1|HMO|BCBS-OH|Blue Cross Blue Shield of Ohio|PO BOX 1234^^COLUMBUS^OH^43215||||||||20260101^20261231|||TESTPATIENT^ALEX^Q|01|19720508|||||||||||||||||X9988776655
Common pitfall — DTM precision in a DT-Range field:
IN1|1|HMO|BCBS-OH||||||||||20260101120000^20261231235959
The sender included a time-of-day that has no operational meaning for coverage. Receivers parsing strictly as DT-Range reject the value; receivers parsing leniently silently truncate, hiding the upstream error.
FHIR mapping
The v2-to-FHIR IG does not publish a dedicated per-datatype ConceptMap for DT-Range; mapping is handled at the segment level by emitting a FHIR Period resource element with date-only precision on each endpoint.
| DT-Range component | FHIR element | Notes |
|---|---|---|
| DT-Range.1 | Period.start | Emitted as a date (not dateTime) — FHIR's Period permits date-precision values via its element type rules. |
| DT-Range.2 | Period.end | Emitted as a date; omitted when the interval is open-ended. |
Note that FHIR Period.start and Period.end are typed as dateTime, but date-only values are valid because dateTime accepts YYYY-MM-DD. Implementations that round-trip back to v2 should preserve the date-only precision so that an inbound DT-Range round-trips as DT-Range rather than as DR.
Engine considerations
- HAPI HL7v2 v2.8.1 does not ship a dedicated
DTRangeclass —ca.uhn.hl7v2.model.v281.datatype.DRis the closest analog. Engines that need to enforce date-only semantics typically build a thin wrapper around DR that validates each endpoint matchesYYYYMMDDand rejects DTM strings. - The omission of DT-Range.2 is operationally significant — it means "still in effect" rather than "missing data". Engines that treat omitted end dates as errors will reject valid open-ended messages.
- Inverted ranges should be rejected at parse time — silently swapping start and end hides upstream data quality problems that the sender needs to fix.
- Round-tripping to FHIR and back loses the DT-vs-DTM distinction unless explicitly preserved — FHIR
dateTimeis the same type whether populated with a date or a timestamp, so the precision metadata must be carried as an annotation.
How Vorro parses and produces DT-Range
Vorro models DT-Range as a LocalDateRange distinct from InstantRange (which it uses for DR). On inbound, each endpoint is validated against YYYYMMDD and rejected if a time-of-day component is present — the message is routed to a review queue with a precise diagnostic rather than silently coerced. Inverted ranges are likewise flagged.
On outbound, Vorro always emits DT-Range fields with date-only precision, omits DT-Range.2 (rather than emitting a sentinel like 99991231) when the interval is open-ended, and ensures that single-day ranges are emitted with start equal to end so receivers do not confuse them with open-ended ranges. When down-converting to a partner that only supports DR, Vorro pads each endpoint to a documented time-of-day (typically 000000 for the start, 235959 for the end) so that operational semantics are preserved.
