The TQ (Timing/Quantity) data type was introduced in HL7 v2.3 to carry the full schedule, dose, priority, and conjunction of an order in a single field. It was the payload of ORC-7 (Quantity/Timing) in v2.3 and v2.4 and continues to appear in countless production interfaces. ORC-7 was withdrawn in v2.5 in favor of the dedicated TQ1 (Timing/Quantity) and TQ2 (Timing/Quantity Relationship) segments, but TQ remains in the HAPI v2.8.1 model so engines can still parse legacy traffic.
Purpose
TQ exists because an order is rarely "just a number" — it is a quantity to administer, on an interval, for a duration, between two dates, at a priority, possibly conditional on observations, possibly chained to another order via a conjunction. Cramming all of that into a single composite kept v2.3 messages compact, at the cost of components nested several levels deep. The replacement TQ1/TQ2 segments give each concept its own field, which is why TQ is now considered legacy.
Component table
Source: Caristix HL7 v2.8.1 definition (TQ). Length is shown as — because v2.7+ deprecated fixed maximum lengths in favour of conformance-profile constraints.
| Comp | Name | Sub-type | Length | Required | Description |
|---|---|---|---|---|---|
| TQ.1 | Quantity | cq | — | O | Quantity to administer per occurrence (numeric + units). |
| TQ.2 | Interval | ri | — | O | Repeat pattern + explicit times (e.g. Q6H^0600,1200,1800,0000). |
| TQ.3 | Duration | st | — | O | Duration of each occurrence using ISO-style codes (1H, P1D). |
| TQ.4 | Start Date/Time | dtm | — | O | First occurrence start. |
| TQ.5 | End Date/Time | dtm | — | O | Last occurrence end (stop date). |
| TQ.6 | Priority | st | — | O | Order priority: STAT, ASAP, ROUTINE, P (preop), etc. |
| TQ.7 | Condition | st | — | O | Free-text or coded condition that gates execution. |
| TQ.8 | Text | tx | — | O | Free-text instruction to the performer. |
| TQ.9 | Conjunction | id (HL70472) | — | O | S = sequential, A = actuated, C = concurrent. |
| TQ.10 | Order Sequencing | osd | — | O | Composite linking this order to a predecessor for cyclical / sequenced orders. |
| TQ.11 | Occurrence Duration | cwe | — | O | Coded duration of a single occurrence. |
| TQ.12 | Total Occurrences | nm | — | O | Total number of occurrences (caps the schedule). |
Most-used components
- TQ.1 Quantity — how much to give per occurrence.
- TQ.2 Interval — how often, including explicit clock times.
- TQ.4 / TQ.5 Start / End — bound the schedule in time.
- TQ.12 Total Occurrences — caps the run so the schedule does not extend forever.
Where it's used
- ORC-7 Quantity/Timing — the canonical home of TQ in v2.3 and v2.4 (withdrawn in v2.5+).
- OBR-27 Quantity/Timing — same shape on the observation-request side.
- RXO-21 (legacy quantity/timing in pharmacy orders, where present).
- Any v2.3/v2.4 message still in production that has not migrated to TQ1/TQ2.
Version differences
- HL7 v2.3 — TQ introduced with the 12-component layout.
- HL7 v2.4 — minor refinements to conjunction (HL70472) and order-sequencing semantics.
- HL7 v2.5 — ORC-7 (the main carrier of TQ) withdrawn; replaced by the TQ1 and TQ2 segments. TQ itself remains defined for backward compatibility.
- HL7 v2.6 / v2.7 / v2.8 / v2.8.1 — TQ is retained in the data-type catalog and the HAPI v2.8.1 model; new conformance profiles should not specify it. Fixed maximum lengths deprecated.
Common mistakes
- Sending TQ in ORC-7 against a v2.5+ profile — receivers that expect TQ1 will reject or ignore the field.
- Forgetting TQ.12 Total Occurrences when an upper bound is required — open-ended schedules can be interpreted as "until cancelled."
- Mixing TQ.4/TQ.5 (a date window) with TQ.12 (a count) inconsistently — the two together must agree, otherwise the receiver picks one and silently drops the other.
- Putting plain English into TQ.2 ("every 6 hours") instead of an RI composite (
Q6H) — downstream scheduling engines cannot parse the prose. - Using TQ.9 conjunction
S(sequential) without an OSD in TQ.10 — sequential chains require the predecessor link, otherwise the order stands alone.
Examples
Minimal — quantity and interval only:
1^mg^UCUM^Q6H
Populated — full schedule with start/end and total occurrences:
1^mg^UCUM^Q6H^1H^20260624080000^20260628080000^R^^Take with food^^^^^20
In context — legacy ORC-7 carrying a four-day Amoxicillin course:
MSH|^~&|EHR|MERCY|PHARM|MERCY|20260624075500||OMP^O09^OMP_O09|MSG0210|P|2.4
PID|1||MR884412^^^MERCY^MR||TESTPATIENT^ALEX^Q||19720508|F
ORC|NW|ORD-5501^MERCY|||IP|^^^20260624080000^20260628080000^^^Amoxicillin 500 mg^^^^4
RXO|309029^Amoxicillin 500 mg oral capsule^RXNORM|500^mg^UCUM||CAP^Capsule^HL70162|PO^Oral^HL70162
The ORC-7 above declares the order runs from 24-Jun 08:00 to 28-Jun 08:00 with 4 total occurrences and the instruction "Amoxicillin 500 mg" in TQ.8.
Common pitfall — TQ inside ORC-7 against a v2.5.1 profile:
MSH|^~&|EHR|MERCY|PHARM|MERCY|20260624075500||OMP^O09^OMP_O09|MSG0211|P|2.5.1
ORC|NW|ORD-5501^MERCY|||IP|^^^20260624080000
In v2.5+ the ORC-7 field is withdrawn; conforming receivers will not look there. Move the schedule into TQ1 segments.
FHIR mapping
The v2-to-FHIR IG does not publish a single TQ-to-Timing ConceptMap; instead, TQ is mapped per consuming resource so the timing semantics fit the host:
| TQ component | FHIR target (typical) | Notes |
|---|---|---|
| TQ.1 Quantity | Dosage.doseAndRate.dose or ServiceRequest.quantityQuantity | Resource-dependent. |
| TQ.2 Interval | Timing.repeat (via RI mapping) | Frequency, period, and explicit times. |
| TQ.3 Duration | Timing.repeat.duration + durationUnit | ISO-style codes parsed into UCUM time units. |
| TQ.4 / TQ.5 | Timing.repeat.boundsPeriod.start / .end | |
| TQ.6 Priority | *.priority on the host resource | STAT/ASAP/ROUTINE values map to FHIR priority codes. |
| TQ.9 Conjunction + TQ.10 OSD | Task.basedOn / Task.partOf chains | Sequenced orders become linked Tasks. |
| TQ.12 Total Occurrences | Timing.repeat.count |
Per-context ConceptMaps: tq-to-appointment, tq-to-medicationrequest, tq-to-servicerequest, tq-to-task.
Engine considerations
- Version-aware routing: an engine must know the sender's v2 version. The same byte pattern in ORC-7 is TQ in v2.3/v2.4 and an illegal field in v2.5+.
- Round-trip preservation: legacy partners may continue to send TQ for years after the standard withdrew it. Parse it, normalize internally to a TQ1-shaped model, but be prepared to emit TQ on outbound when the receiver only speaks v2.4.
- Conjunction / OSD chains are easy to drop on the floor. If TQ.9 is non-null, the engine must materialize the link to the predecessor order, not just persist the literal value.
- Priority synonyms: TQ.6 is plain ST in v2.3, so partners ship variants like
STAT,S,Stat. Normalize to HL70485 priority codes on inbound.
How Vorro parses and produces TQ
Vorro decomposes TQ into a typed internal schedule object — a quantity, an RI-shaped interval, a bounded period, a priority enum, an optional conjunction, and an optional total-occurrences cap. Inbound TQ from a v2.3/v2.4 ORC-7 is parsed into the same shape as TQ1 segments from a v2.5+ partner, so downstream FHIR mapping sees one model regardless of the wire format. Free-text priority and conjunction values are normalized against HL70485 and HL70472 with provenance tagged when a translation is applied.
On outbound, Vorro emits TQ only when the receiver's profile is v2.3 or v2.4 and the field is ORC-7 (or OBR-27). For every other target, the same internal schedule is serialized as TQ1 (and TQ2 when sequencing is present). Total Occurrences and the start/end window are emitted together when both are known so the receiver cannot pick the wrong terminator.
Related pages
- RI data type — Repeat Interval
- CQ data type — Composite Quantity with Units
- ORC segment — Common Order
