HL7 GTS Data Type: General Timing Specification

The GTS (General Timing Specification) data type was introduced in HL7 v2.5 to give v2 messages access to the richer timing vocabulary of HL7 v3. It carries a single string that follows HL7 v3 GTS syntax — typically an ISO 8601 interval, period, or repeating expression — and is the underlying type for TQ1-3 Quantity/Timing in profiles that have adopted the v2.5+ timing model.

Purpose

Earlier v2 messages encoded order-and-administration timing through TQ1's structured components (interval, duration, priority, condition). GTS is the escape hatch for expressions those components cannot represent cleanly: complex repeating schedules, calendar-aligned events, periods bounded by external triggers. Receivers that understand v3 GTS can parse the string directly; receivers that do not should treat it as opaque text and fall back to TQ1's structured fields.

Format and constraints

GTS is a primitive with no components or sub-components. Content is a single string conforming to HL7 v3 GTS syntax.

Common forms:
- ISO 8601 interval: 2026-06-24T08:00:00/PT4H — start instant followed by a duration.
- Repeating interval: R5/2026-06-24T08:00:00/P1D — repeat 5 times, starting at the given instant, one-day period.
- Open-ended repetition: R/2026-06-24T08:00:00/P1D — daily, no end.
- Calendar expression: <Y2026M06D24> — v3 calendar literal.
- Period only: P1D, PT8H, P1W — duration without an anchor.
The literal characters |, ^, ~, &, `` must be escaped as F S R T E if they appear in the value. In practice they should not.
Whitespace is not significant inside ISO 8601 expressions; receivers may reject embedded spaces.
Length: governed by conformance profile. HAPI v2.8.1 imposes no cap at the type level.
The expression is a single token; multiple alternative timings should be repeated at the field level (~) rather than concatenated inside one GTS value.

Where it's used

TQ1-3 Quantity/Timing — Explicit Time (GTS in v2.5+ profiles that have adopted the v3 timing model).
TQ2-3 Sequence/Results — relative timing expressions in some implementations.
ORC-7 deprecated TQ field in messages migrating from TS/CQ-based timing to GTS-based.
RXE-1 Quantity/Timing (deprecated) replaced by TQ1 with GTS in modern pharmacy flows.
RXG-2 Give Sub-ID Counter timing extension in some profiles.
RXA-3 Date/Time Start of Administration where a repeating administration is needed.
Vendor Z-segments that mirror TQ1-3 for site-specific scheduling.
Research/protocol messages where a study schedule must travel intact.

Version differences

v2.1 through v2.4: GTS does not exist. Timing is carried in TS/CQ-based composites.
v2.5: GTS introduced as a single-string primitive to align v2 timing with v3 GTS syntax.
v2.6 through v2.8.1: definition unchanged; GTS remains a primitive whose internal grammar is governed by the v3 specification.

Because GTS is "new" in v2 terms, support is uneven. Many receivers in production still parse only the structured TQ1 components and ignore GTS strings.

Common mistakes

Sending a v2 DTM-style string (20260624080000) inside a GTS field. The receiver expects ISO 8601; the bare digits are not a valid GTS expression.
Concatenating multiple schedules into a single GTS value with commas or semicolons. Use field-level repetition (~) instead.
Mixing time zones inconsistently — 2026-06-24T08:00:00 (local) versus 2026-06-24T08:00:00Z (UTC) versus 2026-06-24T08:00:00-05:00. Pick one strategy per interface and document it.
Embedding spaces (R5 / 2026-06-24T08:00:00 / P1D) — strict parsers reject the value.
Sending a GTS expression while leaving the structured TQ1 components populated with a different schedule. The two must agree, or the receiver behaviour is undefined.

Examples

Minimal — a single duration:

PT4H

ISO 8601 interval (start instant plus duration):

2026-06-24T08:00:00/PT4H

Repeating expression (five daily occurrences starting at the given instant):

R5/2026-06-24T08:00:00/P1D

Open-ended daily repetition:

R/2026-06-24T08:00:00/P1D

v3 calendar literal:

<Y2026M06D24>

In context — TQ1 carrying a GTS expression in TQ1-3:

TQ1|1|1^each^UCUM|R5/2026-06-24T08:00:00/P1D|||||20260624080000|20260628080000|R^Routine^HL70485

In context — repeating GTS values at the field level for two alternative schedules:

TQ1|1|1^each^UCUM|R5/2026-06-24T08:00:00/P1D~R5/2026-06-24T20:00:00/P1D

Common pitfall:

WRONG:  TQ1|1|1^each^UCUM|20260624080000|...
        A bare DTM is not a GTS expression; conformant receivers reject it.
RIGHT:  TQ1|1|1^each^UCUM|2026-06-24T08:00:00/PT4H|...

FHIR mapping

GTS maps to FHIR Timing. There is no published per-datatype ConceptMap in the v2-to-FHIR IG because the mapping is grammar-driven: the GTS expression is parsed and projected onto Timing.repeat (period, periodUnit, frequency, count, boundsPeriod) or Timing.event (an array of explicit DateTime values).

R5/2026-06-24T08:00:00/P1D → Timing.repeat.count = 5, Timing.repeat.period = 1, Timing.repeat.periodUnit = "d", Timing.event[0] = "2026-06-24T08:00:00".
A bare interval 2026-06-24T08:00:00/PT4H → Timing.repeat.boundsPeriod.start and .end derived from the duration.
v3 calendar literals (<Y2026M06D24>) generally collapse to a single Timing.event entry.

Engine considerations

Validate GTS strings against an ISO 8601 / v3 GTS parser at the boundary; do not relay un-parsed values into downstream systems that assume well-formed input.
Decide whether to canonicalize time zones at ingress (e.g. always normalize to UTC) and apply the policy uniformly.
Keep the original GTS string alongside any parsed structured form; legal v3 grammars include constructs that have no clean FHIR Timing round-trip, and the source string is the ground truth.
When TQ1 carries both structured components and a GTS expression, log the disagreement rather than silently picking one — the producer almost certainly has a bug.
HAPI v2.8.1 models GTS as a plain string primitive; no built-in grammar validation is provided.
Be defensive about character case in v3 calendar literals; <y2026m06d24> is not valid GTS.

How Vorro parses and produces GTS

Vorro keeps the GTS string verbatim in its canonical model and lazily parses it into a structured timing tree on demand. The parser covers the ISO 8601 interval, repeating-interval, period, and v3 calendar-literal forms; expressions it cannot fully parse are retained as opaque text with a typed "unparsed GTS" marker so downstream FHIR mappers can decide whether to fail, fall back, or pass through.

On outbound, Vorro emits the canonical string form rather than reconstructing from the parsed tree. This guarantees that a GTS value received from an upstream system survives the round-trip byte-for-byte, which matters in regulated pharmacy and clinical-trial flows where the original schedule string is part of the audit record.

Sources

← Back to HL7 v2 Guide