HL7 DT Data Type: Date

The DT (Date) data type has been part of HL7 v2 since v2.1 and represents a calendar date with no time-of-day and no timezone offset. It is the type used by PID-7 (Date/Time of Birth in the earliest versions, narrowed to a date in many real-world profiles), OBR-6 Requested Date/Time, ROL-5 / ROL-6 Role Begin/End Date, and dozens of other date-only fields where time-of-day would be meaningless or unknown.

Purpose

DT exists to carry a calendar date — and only a calendar date. The HL7 v2 standard deliberately separates dates from times: when a field truly cannot carry a time (a birth year, a coverage start date, a credential expiry), DT is the correct primitive. When the field needs both, DTM is used instead. Using DT signals to downstream systems that no time was ever known, so they must not synthesize one.

Format and constraints

The DT format is YYYY[MM[DD]], where:

YYYY — four-digit Gregorian year, always present. Years before 1000 are not supported by most parsers.
MM — optional two-digit month, 01–12.
DD — optional two-digit day, 01 through the last day of the indicated month.

Only the digits 0–9 are allowed. No hyphens, no slashes, no separators of any kind. A DT value is always 4, 6, or 8 characters long.

The precision-truncation rule is the rule people get wrong most often: YYYYMM means "year and month are known, day is unknown" — it does not mean YYYYMM01. Padding a missing day with 01 changes the meaning permanently and corrupts downstream systems that respect precision. The same applies to YYYY vs YYYY0101.

DT does not carry a timezone offset. If the date is meaningful only in a specific timezone (e.g. a billing date governed by a facility's local calendar), the timezone is implicit in the surrounding context, not in the DT itself.

Where it's used

DT is the type for date-only fields throughout the HL7 v2 catalogue. Common examples:

PID-7 — Date/Time of Birth (DT in v2.1–v2.4, DTM from v2.5+; many profiles continue to send DT for DOB because the time of birth is unknown).
PID-29 — Patient Death Date and Time (legacy DT in older profiles).
OBR-6 — Requested Date/Time (DT in early versions, DTM in v2.5+).
ROL-5 / ROL-6 — Role Begin Date/Effective Date and Role End Date.
IN1-12 / IN1-13 — Plan Effective Date / Plan Expiration Date.
STF-11 — Staff date of birth.
PRA-7 — Practitioner certificate effective and expiration dates.
AL1-6 — Identification Date for an allergy.
CSR-7 — Registration Date for a clinical study.
GT1-30 / GT1-31 — Guarantor Date/Time Patient Began Care and Stopped Care.

Version differences

v2.1 through v2.8.2 — DT format and semantics are unchanged. Four-digit-year was clarified in v2.3 (two-digit years were tolerated in earlier dialects); since v2.3 a conformant DT always begins with a four-digit year.
DT has never been promoted to or demoted from a composite — it has always been a primitive.
Several fields originally typed DT were retyped to DTM in v2.5+ (notably PID-7, EVN-3, EVN-4) to allow time-of-day where it is known. DT remains the type for fields where time is genuinely never known.

Common mistakes

Padding YYYYMM to YYYYMM01. The day component is now lying — it says "first of the month" when the source said "month known, day unknown." Decision-support engines that age patients off DOB will produce incorrect ages on the 1st.
Sending ISO 8601 (2026-06-24) where DT is expected. Hyphens are not legal in DT. The value must be 20260624.
Sending a DTM (20260624101500) where DT is expected. Some parsers will silently truncate to the leading 8 characters; others reject the field.
Two-digit years (260624). Tolerated by some parsers as a YYMMDD form, but ambiguous and rejected by strict v2.3+ profiles.
Treating DT as carrying a timezone. A DT cannot be "in UTC" — it has no offset. Converting it across timezones is a category error.

Examples

Minimal value:

20260624

Precision-truncated examples:

2026          ; year only — month and day unknown
202606        ; year and month — day unknown
20260624      ; full date

Fully-populated date in PID-7:

PID|1||MR884412^^^MERCY^MR||TESTPATIENT^ALEX^Q||19720508|F

In context — ADT^A04 patient registration carrying DT in several fields:

MSH|^~&|EMR|MERCY|REG|MERCY|20260624101500||ADT^A04^ADT_A01|MSG-ADT-9120|P|2.8.1
EVN|A04|20260624101500
PID|1||MR884412^^^MERCY^MR||TESTPATIENT^ALEX^Q||19720508|F
AL1|1|DA|7980^Penicillin G^RXNORM|SV|Anaphylaxis|20210304
IN1|1|BCBS001|BCBS^Blue Cross^MERCY|BLUE CROSS||||||||20260101|20261231

Common pitfall — padded month to a first-of-month date:

PID|1||MR99^^^MERCY^MR||DOE^JANE||197205|F           ; correct: month known, day unknown
PID|1||MR99^^^MERCY^MR||DOE^JANE||19720501|F         ; WRONG: silently asserts the 1st as the birth day

FHIR mapping

The v2-to-FHIR IG does not publish a per-datatype ConceptMap for DT. The mapping is implicit: DT maps to the FHIR date primitive, which itself supports YYYY, YYYY-MM, and YYYY-MM-DD precision. The conversion is mechanical — insert hyphens between year, month, and day components and preserve precision exactly:

2026 ↔ 2026
202606 ↔ 2026-06
20260624 ↔ 2026-06-24

A converter that pads 202606 to 2026-06-01 is non-conformant; FHIR's date was specifically designed to carry the same partial-date semantics as HL7 v2 DT so that round-tripping is lossless.

Engine considerations

Precision preservation — do not pad missing components with zeros. A 6-character DT and an 8-character DT have distinct meanings; the parser, internal model, and emitter must all preserve length.
Locale-independent parsing — DT is always YMD; never apply MDY or DMY parsing even if local format conventions differ.
No timezone math — DT values must never be shifted by a timezone offset, even when normalizing surrounding DTM values. A DOB is the same calendar date regardless of where the patient is currently located.
Validation — reject DT values that contain non-digit characters, are not 4/6/8 chars long, or that encode invalid calendar dates (Feb 30, month 13).
Mixed-precision aggregations — when aggregating DT-typed fields across records (e.g. computing patient age distributions), exclude or annotate records with reduced precision rather than coercing them to a default day.

How Vorro parses and produces DT

Vorro's HL7 parser stores DT as a precision-tagged date — internally, every DT value carries an explicit precision flag (YEAR, MONTH, DAY) so that downstream code, FHIR converters, and emitters cannot accidentally pad. On inbound, DT fields are validated as 4/6/8 digit strings; invalid lengths or non-calendar dates route to a curation queue rather than coercing to a default. Two-digit-year inputs from legacy senders are accepted but flagged with a soft warning and re-emitted as four-digit-year.

On outbound, Vorro emits DT in the exact precision originally captured — a record sourced as 202606 is emitted as 202606, not 20260601. When converting to FHIR date, the precision tag governs hyphen placement so that round trips are lossless across HL7 v2, FHIR R4, and back.

Sources

← Back to HL7 v2 Guide