HL7 DTM Data Type: Date/Time

The DTM (Date/Time) data type was introduced in HL7 v2.5 (initially under the name TSComponentOne as the first component of TS) and was promoted to the primary timestamp primitive in v2.5.1. From v2.5.1 onwards, DTM is the canonical type for every field that carries a combined date-and-time value — message timestamps, event recorded times, observation date/times, order date/times, encounter admit and discharge times, and hundreds of others. It is the single most commonly used data type in modern HL7 v2 messages.

Purpose

DTM exists to carry a precise point in time with explicit precision and an explicit timezone offset. Earlier versions used TS, which started as a primitive and was later restructured into a composite — DTM cleanly separates the primitive timestamp value from the surrounding metadata, making it suitable as a first-class field type. The primitive is precision-aware: every DTM value implicitly carries the precision at which it was captured (year only, year+month, ..., year+month+day+hour+minute+second+fraction).

Format and constraints

The DTM format is YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ], where:

YYYY — four-digit Gregorian year, always present.
MM — optional two-digit month, 01–12.
DD — optional two-digit day, 01 through the last day of the indicated month.
HH — optional two-digit hour, 00–23.
MM — optional two-digit minute, 00–59.
SS — optional two-digit second, 00–59.
.S to .SSSS — optional fractional second, 1 to 4 digits.
+/-ZZZZ — optional timezone offset from UTC as a four-digit HHMM. +0000 is explicit UTC.

Only digits, an optional decimal point, and an optional sign are allowed. No T separator, no hyphens, no colons. ISO 8601 (2026-06-24T10:15:00Z) is not legal DTM.

The precision-truncation rule is critical and is the rule most senders get wrong: 202606 means "month known, day and time unknown" — it does not mean 20260601000000. Padding with zeros silently asserts midnight of the first of the month and corrupts time-sensitive workflows. The same applies to every level: 2026062410 means "hour known, minute unknown," not 20260624100000.

Timezone offset is optional but strongly recommended. A DTM without an offset is interpreted in the receiver's local zone — which causes 5–17 hour errors when messages cross sites or cross DST boundaries.

Where it's used

DTM is the default timestamp type in HL7 v2.5+ and appears in nearly every segment. Common examples:

MSH-7 — Date/Time Of Message.
EVN-2 — Recorded Date/Time (event recorded).
EVN-6 — Event Occurred (when the event actually happened, distinct from when it was recorded).
PID-7 — Date/Time of Birth (DTM from v2.5+, replacing earlier DT).
PID-29 — Patient Death Date and Time.
OBR-7 / OBR-8 — Observation Date/Time # / Observation End Date/Time.
OBR-14 — Specimen Received Date/Time.
OBX-14 — Date/Time of the Observation.
OBX-19 — Date/Time of the Analysis.
ORC-9 — Date/Time of Transaction.
ORC-15 — Order Effective Date/Time.
PV1-44 / PV1-45 — Admit Date/Time / Discharge Date/Time.
SCH-11 — Appointment Timing Quantity (start date/time component).
RXA-3 / RXA-4 — Date/Time Start of Administration / End of Administration.

In a typical v2.8.1 ADT message, eight to twelve fields are DTM-typed.

Version differences

v2.1 through v2.4 — DTM does not exist; timestamps use TS as a primitive.
v2.5 — DTM introduced under the name TSComponentOne as the first component of a restructured TS composite.
v2.5.1 — TSComponentOne renamed to DTM and promoted to the primary date/time primitive. TS retained as a composite (TS.1 = DTM, TS.2 = degree of precision indicator) for backwards compatibility.
v2.7+ — Many fields that were typed TS in earlier standards (MSH-7, EVN-2, OBR-7, OBX-14, ORC-9, dozens of others) were retyped to DTM. Conforming senders on v2.7+ profiles should not emit TS in these fields.
v2.8 / v2.8.1 / v2.8.2 — No structural changes to the primitive.

Common mistakes

TZ stripping. Routing engines that drop the offset to "normalize" timestamps silently convert UTC values to the receiver's local zone, producing 5–17 hour errors across sites.
Padding YYYYMM to YYYYMM01000000. Asserts midnight of the first when the source said "month known, day and time unknown." Decision support that filters on time-of-day produces wrong results.
Sending ISO 8601 (2026-06-24T10:15:00Z) instead of HL7 (20260624101500+0000). The T separator, the hyphens, and the Z are all illegal in DTM.
More than 4 fractional digits. .SSSSSS is non-conformant; the standard caps at 4 decimal places.
Confusing DT with DTM. Sending 20260624 into a DTM-typed field is tolerated by most parsers (it is a valid DTM at day precision) but loses time precision permanently. If the source had a time, it must be carried.
Local time without offset across DST. A DTM of 20260307020000 without an offset is ambiguous in zones that spring forward at 2:00 AM — the timestamp may or may not exist.

Examples

Minimal value:

20260624                 ; date only, time unknown

Precision-truncated examples:

2026                     ; year only
202606                   ; year and month
20260624                 ; full date
2026062410               ; hour known, minute unknown
202606241015             ; minute precision

Fully populated with fractional second and offset:

20260624101530.250-0500   ; June 24 2026, 10:15:30.25 US Eastern
20260624101530+0000       ; same instant in UTC notation

In context — MSH-7 message timestamp:

MSH|^~&|EMR|MERCY^2.16.840.1.113883.19.5.99999.1^ISO|LIS|MERCY|20260624101530-0500||ADT^A04^ADT_A01|MSG-ADT-9120|P|2.8.1
EVN|A04|20260624101530-0500|||9988^Reyes^Marta^L^^^MD|20260624101000-0500

In context — OBR-7/8 observation window and OBX-14 observation time:

OBR|1|ORD-441|RES-882|24356-8^Hemoglobin A1c^LN|||20260624083000-0500|20260624083500-0500
OBX|1|NM|4548-4^Hemoglobin A1c^LN||6.8|%|4.0-5.6|H|||F|||20260624090000-0500

Common pitfall — ISO 8601 leaked through:

MSH-7: 20260624101500-0500             ; correct
MSH-7: 2026-06-24T10:15:00-05:00       ; WRONG: hyphens, T, and colon are not legal
MSH-7: 20260624101500Z                 ; WRONG: Z is not legal; use +0000

FHIR mapping

The v2-to-FHIR Implementation Guide publishes two per-datatype ConceptMaps for DTM:

datatype-dtm-to-datetime — DTM → FHIR dateTime. The default conversion. Precision and timezone offset are preserved; HL7 YYYYMMDDHHMMSS+ZZZZ becomes YYYY-MM-DDTHH:MM:SS+ZZ:ZZ. Partial-precision DTM values map to partial-precision dateTime values (FHIR dateTime accepts YYYY, YYYY-MM, YYYY-MM-DD, and full forms).
datatype-dtm-to-annotation-time — DTM → Annotation.time when the source field drops into a note/annotation backbone element.

When two DTMs are combined into a range via the v2 DR (Date/Time Range) composite, the pair maps to FHIR Period (with start and end both dateTime).

The conversion is mechanical: insert hyphens and a T separator, insert a colon into the offset, and preserve the fractional seconds and precision exactly. Converters that pad missing components or drop the offset are non-conformant.

Engine considerations

Local-time vs UTC normalization. Decide once, at ingress, whether the canonical internal store is UTC or zoned. Whichever is chosen, the offset must be preserved through to egress — don't normalize to UTC on the way in and emit naive local time on the way out.
Precision preservation. Store DTM with an explicit precision tag. Padding with zeros to reach a uniform width destroys information.
DST transitions. Timezone-naive DTM values are ambiguous during fall-back hours (a value can refer to two distinct instants) and impossible during spring-forward hours. Reject or flag naive DTM values that fall in these windows.
TS into a DTM-typed field. Conforming senders on v2.7+ profiles should not emit TS where DTM is expected. Receivers commonly accept it for compatibility by reading TS.1 (which is itself a DTM) as the value; emitters should never reciprocate.
Fractional-second cap. Validate at most 4 fractional digits; truncate-and-warn rather than silently rounding.
Cross-system comparisons. Comparing two DTM values requires that both have offsets, or that both are anchored to the same implicit zone. Mixed-offset comparisons without explicit offsets produce silent errors.

How Vorro parses and produces DTM

Vorro treats DTM as a precision-tagged, offset-aware instant. On inbound, every DTM is parsed into an internal representation that carries the original precision (YEAR, MONTH, DAY, HOUR, MINUTE, SECOND, FRACTION) and the original offset; values without an explicit offset are accepted but tagged with a soft warning and resolved against the configured facility-local zone. Fractional seconds beyond 4 digits are truncated and warned. DTM values in DST-ambiguous local-time windows are flagged and routed to a curation queue rather than guessed.

On outbound, Vorro emits DTM at the exact precision originally captured — a record sourced as 202606 is never padded to 20260601000000. Offsets are always emitted when known; UTC is rendered as +0000 (never Z, which is illegal). When converting to FHIR dateTime, the precision tag governs the output format so round-trips are lossless across HL7 v2, FHIR R4, and back. DR ranges are decomposed into paired DTM start/end and re-emitted as a FHIR Period with both components carrying their original precision and offset.

Sources

← Back to HL7 v2 Guide