HL7^® Reference Guide

HL7 TQ1 Timing/Quantity

Examine the usage of every TQ1 field from experience.

HL7 field reference TQ1 fields from HL7 v2.5.1 Show fields

These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.

Fields

Field	Name	Required	Repeatable	Type	Table
TQ1.1	Set ID - TQ1	No	No	SI
TQ1.2	Quantity	No	No	CQ
TQ1.3	Repeat Pattern	No	Yes	RPT	0335
TQ1.4	Explicit Time	No	Yes	TM
TQ1.5	Relative Time and Units	No	Yes	CQ
TQ1.6	Service Duration	No	No	CQ
TQ1.7	Start date/time	No	No	TS
TQ1.8	End date/time	No	No	TS
TQ1.9	Priority	No	Yes	CWE	0485
TQ1.10	Condition text	No	No	TX
TQ1.11	Text instruction	No	No	TX
TQ1.12	Conjunction	No	No	ID	0427
TQ1.13	Occurrence duration	No	No	CQ
TQ1.14	Total occurrence's	No	No	NM

TQ1 is the segment that says when an ordered thing should happen. It can tell the receiver how much to do, how often to do it, when to start, when to stop, how long the whole service should continue, how long each occurrence takes, and how urgent it is. That is a lot of quiet machinery hiding behind a three-letter segment.

You will normally see it living in order-style messages, close to ORC and the order detail segment such as OBR, RXO, RXE, or a scheduling service. ORC is the order control and identity, OBR or RXO says what was ordered, and TQ1 says the timing instructions. Older interfaces often squeezed this into ORC-7 or OBR-27 as the old TQ data type, but in v2.5 and later TQ1 gives the timing its own proper segment.

The common trap is to send a nice human phrase like "daily for five days" and hope every downstream system will understand it. People do. Computers often do not. TQ1 is trying to turn that phrase into smaller parts: repeat pattern, explicit times, duration, start and end dates, priority, condition text, and count. The more of that you can encode cleanly, the less the receiver has to guess. HL7 Soup Web is handy here because you can inspect the timing pieces field by field before deciding whether your receiver can execute them or only display them.

In practice, the fields to pay closest attention to are TQ1-2 for the amount per occurrence, TQ1-3 for the repeat pattern, TQ1-4 and TQ1-5 for clock times and intervals, TQ1-6 to TQ1-8 for the service window, and TQ1-9 for priority. TQ1-10 and TQ1-11 are still useful, but they are text, so I treat them as human guidance rather than executable rules unless the interface agreement says otherwise.

First, think in order timing

Pharmacy and treatment orders are where TQ1 feels most natural. Doses like every 8 hours, twice daily, PRN, tapering schedules, one dose now and then maintenance doses, infusion duration, and stop dates all need more than one field to describe them. If the order is actually a set of related orders, TQ2 may also come into play. In Integration Soup, I would keep timing transforms conservative and loudly logged; a quiet timing mistake can become a missed dose or an impossible schedule.

Lab orders use timing differently. A one-off blood test might not need much more than a requested time, but serial tests, timed urine collections, fasting collections, drug troughs, glucose tolerance testing, and future scheduled collections can all benefit from cleaner timing. Many lab implementation guides keep TQ1 optional or leave it out for simple orders, so check the profile rather than assuming the segment will always be there.

Scheduling messages can also carry TQ1 because appointments and recurring services have the same basic timing problem: what, when, how often, and for how long. SCH describes the appointment activity, but timing can still need repeat patterns, start and end windows, and priority.

The main integration pain is not the existence of the fields. It is the local meaning of the codes. BID and TID are institution-specified times. Q8H is more precise, but it still needs a start. PRN tells you "as needed", but not the condition. A receiver that schedules nursing tasks, lab draws, or pharmacy administrations needs those details to be agreed, not merely present.

So let's go through each of the TQ1 fields and talk about how they tend to behave in real interfaces.

When there is only one timing instruction, this is almost always 1. If the order needs more than one TQ1 segment, the set IDs count upward so people and systems can keep the instructions in order.

Do not treat it as a timing identifier. It is just the sequence number inside this group. If an order changes and the message is rebuilt, the set ID may be reshuffled even though the clinical timing intent is the same.

The amount here is for each occurrence of the service, not the number of times the service happens. In medication-style examples it may be one tablet, 500 mg, 10 mL, one bag, or two puffs. In a non-medication order it might be one treatment, one unit, one collection, or another locally agreed amount.

The CQ data type gives you a number plus units. That sounds simple, but units are where interfaces get messy. If you can use UCUM-style units, do it. A quantity of 1 without units may be understandable to a human, but it is weak for automation. Also keep this separate from TQ1-14. "Take one capsule every eight hours for fifteen doses" means quantity is one capsule and total occurrences is fifteen.

Frequency is the heart of this segment. You will see values such as Q8H for every eight hours, BID for twice a day at institution-specified times, TID, QID, QAM, QPM, QHS, QOD, PRN, Once, and the Q<integer> family for minutes, hours, days, weeks, months, and seconds. The field can repeat, because real instructions can be more complicated than one neat code.

The difference between calendar language and interval language matters. BID means twice daily at the organisation's normal times, which might be 09:00 and 21:00 in one place and something different somewhere else. Q12H means every twelve hours and depends on the start time. Those are not always clinically equivalent. If exact administration time matters, use the explicit time and start fields rather than hoping the receiver's default schedule matches yours.

PRN is another place to be careful. PRN says as needed, but it does not say "for pain", "for nausea", "if temperature above 38.5", or "if blood glucose under 4". That condition belongs in TQ1-10 if you only have text, or in a more structured relationship if both systems support it. Sending PRN alone is often not enough for safe downstream scheduling.

Sometimes the frequency is not enough and you need actual clock times. A twice-daily medication might be due at 08:00 and 20:00, a lab draw might be required at 06:00, or a timed collection might need to start at a specific hour. This repeatable TM field is where those times can be carried.

Clock time is wonderfully precise until time zones, daylight saving, and local policy walk into the room. HL7 TM is only a time of day, so it needs the start date/time and the implementation context to make it meaningful. For one-off or very precise events, I prefer to send a proper start date/time as well. Explicit times are best when you are saying "on the days this order is active, do it at these clock times."

Intervals and offsets live here. The common pattern is a number and a time unit, such as eight hours, thirty minutes, or two days. It is useful when the instruction is more naturally expressed as "every N units" or "N units after the previous event" than as a named repeat pattern.

Do not let this fight with TQ1-3. If TQ1-3 says Q8H and TQ1-5 says 6^h, the receiver now has to choose which truth to believe. Use the repeat pattern for the human-friendly frequency code, and use relative time where the receiving system expects a numeric interval. If both are sent, make sure they agree.

Think of this as the length of the whole service request. "For five days", "for two weeks", or "for six hours" belongs here. It is different from the duration of each individual occurrence.

A common example is an antibiotic ordered every eight hours for five days. TQ1-3 says every eight hours, TQ1-6 says five days, and TQ1-14 may say fifteen doses if the prescriber has expressed the count that way. If you put the five days in text only, a receiving system may display it, but it probably cannot calculate the stop point reliably.

Here we get the moment the timing instruction becomes active. It can be the first dose time, first draw time, appointment start, or the beginning of a service window, depending on the order type.

Do not quietly default this to the message date unless that is the actual intent. MSH-7 is when the message was created; ORC-9 is the order event time; TQ1-7 is when the service timing should start. For future orders, delayed starts, scheduled collections, and medication regimens, those are very different dates.

This gives the stop boundary for the timing instruction. It may be a calculated stop date, an explicit order end, or the end of a scheduled service window.

Leaving it empty can be perfectly valid for open-ended orders, but it can also create accidental immortal orders if the receiver assumes "no end" instead of "unknown end". If the order should stop after five days, either send the duration, total occurrences, end date/time, or an agreed combination. The worst version is "for five days" buried in free text while the structured fields imply no stop.

Priority tells the receiver how urgently or specially to handle the service. Common values include routine, ASAP, stat, callback, preop, PRN, and timing critical. This is not the same as order status. A stat order can be active, completed, cancelled, or on hold; priority only says how it should be treated.

Be careful when mapping local priority names. One hospital's "urgent" may map to ASAP, another may treat it like STAT, and a lab may have its own turnaround-time categories. If priority drives routing, queue position, labels, pages, courier behaviour, or billing, the codes need to be agreed in the interface spec. A pretty display value is not enough.

Free-text conditions land here. PRN orders are the obvious use: for pain, for nausea, if fever above a threshold, if glucose below a threshold, before meals, after dialysis, or when clinically indicated.

Text is helpful for people and fragile for computers. If the receiver only displays the instruction, text may be fine. If it has to automate tasks, enforce limits, or decide whether something may be administered, then free text is risky. TQ2 exists partly because this free-text condition was not enough for fully encoded sequencing or result-driven instructions.

Here you can put human-readable timing instructions that do not fit neatly into the structured pieces. Examples include "take with food", "draw before next dose", "patient must be fasting", "collect over 24 hours", or "administer slowly".

I like this field as supporting text, not as the only source of truth. If the receiver needs to schedule, route, calculate, or validate the timing, encode the timing in the structured fields and use the text instruction to make it clear to humans. When the text contradicts the structured fields, support calls are not far away.

When multiple TQ1 segments are used, this field tells the receiver how to connect them. HL7 Table 0472 defines asynchronous, actuation time, and synchronous styles of conjunction. In plain terms, it helps say whether the repeated timing specifications are independent, aligned to an actuation point, or meant to be considered together.

You will not see this often in everyday simple orders, but it matters when you are building more complex timing patterns from multiple TQ1 segments. If you are using it, make sure both sides have examples in the interface guide. It is too subtle to leave to assumption.

Each occurrence can have its own length. An infusion over thirty minutes, a treatment session lasting twenty minutes, or a collection window lasting two hours can be expressed here.

It is easy to confuse this with TQ1-6. Service duration is the overall length of the whole order. Occurrence duration is the length of one occurrence inside that order. "Every day for five days, each session thirty minutes" needs both ideas if the receiver is scheduling resources or staff.

Use this when the instruction is counted. A prescription might be fifteen doses. A lab order might be three serial draws. A treatment might be six sessions.

Use this when count is the controlling instruction, or when it usefully confirms the duration. If the duration, end date, and total occurrences disagree, the receiver may stop too soon, keep going too long, or reject the order. Counts are simple, but only when they agree with the rest of the timing story.