The DR (Date/Time Range) data type carries a temporal interval — a start instant and an end instant, both DTM-typed. DR has shifted between primitive and composite definition across HL7 v2 versions: it was treated as a primitive in earlier specifications, was firmly defined as a composite of two DTM components by v2.5, and remains so in HL7 v2.8.1. DR is the right type wherever the field semantics are "from this datetime until that datetime" — effective periods, coverage spans, encounter intervals, audit-window slots.
Purpose
DR exists to express a closed temporal interval in a single field without splitting "start" and "end" across two adjacent fields. Where two DTM fields can drift apart over a profile's evolution, DR keeps both endpoints atomically bound and locally validatable (start ≤ end, timezone consistency). It maps directly to FHIR's Period type.
Components
Source: HAPI HL7v2 v2.8.1 javadoc (DR).
| Comp | Name | Sub-type | Length | Required | Description |
|---|---|---|---|---|---|
| DR.1 | Range Start Date/Time | dtm | — | O | Inclusive start of the interval, full DTM precision with optional timezone offset. |
| DR.2 | Range End Date/Time | dtm | — | O | Inclusive end of the interval, full DTM precision with optional timezone offset. |
Both components are DTM in HL7 v2.8.1 — earlier versions specified TS sub-components; the migration from TS to DTM happened alongside the v2.5/v2.6 DTM consolidation and is firm by v2.8.1.
Most-used components
- DR.1 Range Start Date/Time — almost always populated; the anchor instant.
- DR.2 Range End Date/Time — populated for closed intervals; empty (or open) for ongoing periods in profiles that allow it.
Where it's used
- Effective/expiration ranges in coverage and authorization fields where the field's data type is bound to DR rather than two separate DTMs.
- Insurance coverage start/end fields in payer profiles using DR (some IN1 profile variants).
- Encounter periods in PV1-44 / PV1-45 patterns where the local profile collapses admit/discharge into a single DR.
- Authorization-validity windows in referral and pre-cert messages.
- Master-file (MFN) effective-period fields bound to DR.
- Audit/event-window slots in ARV and IAM segments where temporal scope is itself a range.
- Repeating quantity/timing TQ1 explicit-range patterns in profiles that bind DR instead of two DTMs.
- Withdrawn or deprecated effective ranges on legacy XPN.10 and XAD.12 components in older profiles still in production.
Version differences
- HL7 v2.2 / v2.3 — DR present but loosely specified; some implementations treated it as a primitive concatenation of two timestamps.
- HL7 v2.5 — DR firmed as a two-component composite of TS sub-components; this is the first version where DR has a fully specified shape.
- HL7 v2.6 / v2.7 — TS sub-components migrate to DTM as part of the broader DTM consolidation; DR.1 / DR.2 become DTM-typed.
- HL7 v2.8 / v2.8.1 — structure stable; HAPI v2.8.1 javadoc shows two DTM components.
- HL7 v2.8.2 — no structural changes; narrative clarifications only.
The "primitive vs composite" wobble in DR's history is the single most common reason older bridges misparse it; v2.5+ implementations should treat DR strictly as a composite of two DTMs.
Common mistakes
- DR.2 earlier than DR.1 — end-before-start ranges break duration math and downstream temporal queries; engines should validate and reject (or warn) at the boundary.
- Using DT (date-only) instead of DTM in components — pre-v2.5 implementations sometimes emit DT for DR.1/DR.2, which drops time-of-day precision and can shift effective windows by up to 24 hours.
- Missing timezone offset on one endpoint but not the other — produces silent duration drift across DST boundaries; both endpoints should carry the same explicit offset.
- Confusing DR with two adjacent DTM fields — DR is a single field whose value is
start^end; splitting the two across fields is non-conformant. - Emitting only DR.1 for an "ongoing" period — HL7 v2 has no formal "open-ended interval" convention for DR; profiles vary, so a missing DR.2 may be interpreted as "unknown end" by some receivers and "interval not yet started" by others.
Examples
Minimal value — June 2026 in US Central time:
20260601000000-0500^20260630235959-0500
Multi-component value — encounter span:
20260601083000-0500^20260605120000-0500
Fully populated edge case — sub-second precision across UTC:
20260615120000.500+0000^20260615123000.250+0000
In context — an effective-period field bound to DR:
IN1|1|BCBS001|BCBS^Blue Cross^L|...|...|20260101000000-0500^20261231235959-0500|...
In context — encounter period using DR (profile that collapses admit/discharge into a single DR):
PV1|1|I|3W^301^A^RIVERBEND||||9988^Reyes^Marta^L^^^MD|||...|...|20260601083000-0500^20260605120000-0500
Common pitfall — end before start:
20260630235959-0500^20260601000000-0500 <- WRONG; DR.2 must be >= DR.1
20260601000000-0500^20260630235959-0500 <- CORRECT
Common pitfall — date-only sub-components dropping time-of-day:
20260601^20260630 <- WRONG (in v2.5+); DR sub-components are DTM
20260601000000-0500^20260630235959-0500 <- CORRECT
FHIR mapping
The v2-to-FHIR Implementation Guide publishes two per-shape ConceptMaps for DR:
- DR → Period — the standard mapping: DR.1 →
Period.start, DR.2 →Period.end. - DR → dateTime — the degenerate single-endpoint mapping, used where the target FHIR element is a single
dateTimeand only DR.1 is populated.
For Period mapping, both endpoints carry their HL7 timezone offset into the FHIR instant representation. FHIR Period permits an open-ended range (omit Period.end) when DR.2 is empty, but consuming systems should be aware that HL7 v2's semantics for an absent DR.2 are profile-defined and not universally "open-ended".
Engine considerations
- Timezone preservation: both endpoints must carry a consistent offset, or the engine must normalise both to UTC at the boundary. Mixed-offset DR values silently drift across DST.
- Start ≤ end validation: validators should reject end-before-start at parse time; downstream temporal queries assume monotonicity.
- Pre-v2.5 compatibility: engines bridging legacy systems may receive DR with TS sub-components or with date-only precision; profile-aware parsers should upcast to DTM with explicit-zero time-of-day plus a soft warning rather than failing outright.
- HAPI HL7v2 v2.8.1 generates
ca.uhn.hl7v2.model.v281.datatype.DRwith two DTM accessors; both exposegetValueAsDate()/getValueAsCalendar()and preserve the source offset. - Open-ended intervals: confirm the profile's stance on absent DR.2 before producing it — silent emission of a half-populated DR is a frequent integration defect.
How Vorro parses and produces DR
On inbound, Vorro parses DR into a typed {start: OffsetDateTime, end: OffsetDateTime?} pair. Both endpoints preserve their explicit offset (no silent normalisation to UTC at the parse boundary). The start ≤ end invariant is checked; violations are raised as hard errors for coverage and authorization fields and as soft warnings for audit-window fields where descending ranges occasionally legitimately occur in legacy data. Pre-v2.5 inputs with TS sub-components are upcast to DTM, and date-only sub-components are widened to T000000 / T235959 with a provenance note.
On outbound, Vorro always renders DR with both endpoints carrying the same explicit timezone offset, full DTM precision (down to the second), and no implicit UTC conversion. Open-ended intervals are produced only when the target profile is explicitly configured to permit an absent DR.2.
