HL7 TM Data Type: Time

The TM (Time) data type has been part of HL7 v2 since v2.1 and represents a time of day with optional sub-second precision and an optional timezone offset. It is the type used by time-only components of scheduling segments (notably the time portion of SCH appointment fields where a profile splits date and time), pharmacy administration windows, and a handful of legacy fields where time-without-date is meaningful.

Purpose

TM carries a wall-clock time independent of any calendar date. When a field needs both date and time, the standard uses DTM; when only a time is meaningful — a daily recurrence ("administer at 09:00"), a shift boundary, or a time-of-day window — TM is the correct primitive. The optional offset lets implementers anchor the time to a specific zone where ambiguity matters.

Format and constraints

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

HH — two-digit hour, 00–23, always present.
MM — optional two-digit minute, 00–59.
SS — optional two-digit second, 00–59 (leap second 60 is not supported by most parsers).
.S to .SSSS — optional decimal fraction of a second, 1 to 4 digits. Five or more decimal digits is non-conformant.
+/-ZZZZ — optional timezone offset from UTC, expressed as a four-digit HHMM. +0000 is the explicit UTC marker; -0500 is US Eastern Standard Time; +0530 is India Standard Time. Note that the offset is HHMM, not HH:MM — no colon.

Only digits, the decimal point, and the optional sign are allowed. No colons inside the time portion. No AM/PM. Hours use the 24-hour clock.

The precision-truncation rule applies: 09 means "9 AM, minute and second unknown," not "09:00:00." Padding with zeros loses precision information permanently.

Where it's used

TM is comparatively rare because most clinical events need a date too — but it appears in:

SCH-11 / SCH-12 — Appointment Timing Quantity sub-components where a profile carries the recurrence time separately from the date.
TQ1-8 — Start time / End time bounded recurrence patterns (in implementations that split out time-of-day).
RXA-3 time-of-day component in some legacy administration profiles.
PD1-12 time-only fields in patient additional demographic profiles (rare).
STF-23 / STF-24 office hours / on-call time-of-day in staff profiles.
Custom Z-segments and profile-specific extensions where a daily recurrence time is carried independently.

In practice, most time-of-day data in modern v2.5+ messages is carried as part of a DTM; pure TM fields are far less common than DT or DTM.

Version differences

v2.1 through v2.4 — TM defined as HHMM[SS[.SSSS]] with optional offset.
v2.5+ — Standard clarified to permit fractional seconds up to 4 decimal places and confirmed the offset is +/-ZZZZ with no colon.
v2.5 through v2.8.2 — No structural changes. The primitive is unchanged in v2.8.1.

Common mistakes

Sending ISO 8601 (10:15:30) where TM is expected. Colons are not legal in TM. The value must be 101530.
Including AM/PM. TM is strictly 24-hour; 0915 is 9:15 AM and 2115 is 9:15 PM.
Sending more than 4 fractional-second digits (.123456). The standard caps fractional precision at 4 digits.
Stripping the timezone offset during routing. A TM of 0900+0900 (Tokyo morning) silently becoming 0900 and being interpreted in the receiver's local zone produces a 9-, 14-, or 17-hour error.
Confusing +0000 (UTC) with empty offset. An absent offset means "unspecified zone, infer from context"; +0000 explicitly asserts UTC.

Examples

Minimal value:

1015          ; 10:15, seconds unknown

Hour-only:

10            ; 10 AM, minute and second unknown

Fully-populated with fractional seconds and offset:

101530.5+0000     ; 10:15:30.5 UTC
094512.2500-0500  ; 09:45:12.25 US Eastern Standard

Precision-truncated examples:

09            ; hour only
0915          ; hour and minute
091500        ; hour, minute, second
091500.5      ; with one-decimal fractional second

In context — a SCH segment carrying a time-of-day recurrence:

SCH|APT-99231|||1|||||30|min^minute^UCUM|^^30^20260625090000-0500^^^^^090000-0500

Common pitfall — colon-separated and AM-marked:

0915                ; correct
09:15               ; WRONG: colons are not legal in TM
0915AM              ; WRONG: TM is 24-hour, no AM/PM marker

FHIR mapping

The v2-to-FHIR IG does not publish a per-datatype ConceptMap for TM. The mapping is implicit: TM maps to the FHIR time primitive, which uses the form HH:MM:SS[.sss]. The conversion is mechanical — insert colons between HH/MM/SS and shift the decimal accordingly:

09 ↔ 09:00:00 (with a precision-loss caveat — FHIR time requires HH:MM:SS at minimum)
0915 ↔ 09:15:00
091530.5 ↔ 09:15:30.5

FHIR time does not carry a timezone offset. When a TM has an explicit offset (091500-0500), the converter must either drop the offset, move it to a sibling timezone field on the parent resource, or promote the value to a dateTime if a date is available.

Engine considerations

Precision preservation — store TM with an explicit precision flag (HOUR, MINUTE, SECOND, FRACTION) so downstream code does not silently pad to HH0000.
Timezone offsets — preserve the offset across the routing pipeline. Engines that strip offsets to "normalize" times destroy information that cannot be recovered.
24-hour clock — TM is always 24-hour; reject AM/PM markers at parse time rather than guessing.
Fractional seconds cap — validate at most 4 fractional digits; truncate-and-warn rather than silently rounding when senders exceed this.
TM into a DTM-typed field — when a sender places a TM where a DTM is expected, most engines will reject the field. Do not synthesize a date.

How Vorro parses and produces TM

Vorro's HL7 parser stores TM as a precision-tagged time-of-day with an optional explicit offset. On inbound, the parser validates that the value contains only digits, an optional single decimal point, and an optional +/-HHMM offset; non-conformant inputs route to a curation queue. Fractional seconds beyond 4 digits are truncated and a soft warning is logged against the source. Offsets are always preserved — Vorro does not "normalize away" timezone information at the boundary because doing so corrupts cross-site scheduling.

On outbound, Vorro emits TM in the exact precision originally captured. When the source had an explicit offset, the outbound TM carries the same offset; when the source did not, no offset is invented. When converting to FHIR time, Vorro inserts colons mechanically and, if an offset is present, moves it to a paired timezone extension on the surrounding resource rather than dropping it.

Sources

← Back to HL7 v2 Guide