HL7 TQ2 Timing/Quantity Relationship
HL7 field reference TQ2 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 |
|---|---|---|---|---|---|
| TQ2.1 | Set ID - TQ2 | No | No | SI | |
| TQ2.2 | Sequence/Results Flag | No | No | ID | 0503 |
| TQ2.3 | Related Placer Number | No | Yes | EI | |
| TQ2.4 | Related Filler Number | No | Yes | EI | |
| TQ2.5 | Related Placer Group Number | No | Yes | EI | |
| TQ2.6 | Sequence Condition Code | No | No | ID | 0504 |
| TQ2.7 | Cyclic Entry/Exit Indicator | No | No | ID | 0505 |
| TQ2.8 | Sequence Condition Time Interval | No | No | CQ | |
| TQ2.9 | Cyclic Group Maximum Number of Repeats | No | No | NM | |
| TQ2.10 | Special Service Request Relationship | No | No | ID | 0506 |
TQ2 is the companion segment to TQ1. TQ1 says when this service request should happen. TQ2 says how this service request depends on another service request. That might be a simple sequence, a cyclic pattern, a taper, a simultaneous administration, or one of those pharmacy/treatment situations where the plain text instruction is not enough.
Most ordinary HL7 interfaces will go a long time without using TQ2. That is not a failure. It is a specialist segment for the moments where the relationship between orders matters. The standard examples are very pharmacy-flavoured: alternating IVs, multi-vitamins in every third bottle, PRN conditions, compound preparations, tapering doses, exclusive alternatives, and simultaneous drugs.
The big value of TQ2 is that it points to related service requests using real order identifiers. In order messages, that usually means ORC-2 for the placer order number, ORC-3 for the filler order number, and ORC-4 for the placer group number. This is why identifier hygiene matters. A TQ2 relationship is only as good as the order numbers it refers to.
The big warning is that relationships are operational. If order B follows order A, what happens when order A is cancelled, held, or discontinued? The HL7 chapter notes that later orders in the chain can inherit that same status. That is very sensible, but it is also a big behaviour to assume silently. If you use TQ2, write examples into the interface agreement and test the lifecycle events, not just the happy-path new order. This is the kind of chained-order behavior I would model explicitly in Integration Soup, with enough logging to explain why a child order moved when the parent changed.
First, know when it is worth using
The everyday order pattern is simple: send ORC, send the order detail, send TQ1 if there is timing. That covers an enormous amount of real-world work. TQ2 becomes interesting when the order cannot be understood on its own. "Start this after that finishes", "repeat this cycle", "give these together", or "choose one of these alternatives" are relationship statements, not simple frequencies.
Pharmacy and treatment systems are the natural home for it because medication logic often has dependencies. A taper is really several timed orders stitched together. Alternating IVs are a cycle. A compound order has multiple ingredients but one administered product. Simultaneous orders need to stay together. Exclusive PRN alternatives need to make clear that only one of the options is meant to be given at a dosing time. When reviewing an example in HL7 Soup Web, check the TQ2 relationship fields against the ORC identifiers before trusting the chain.
Lab and imaging interfaces can still encounter the idea, especially with serial procedures, reflex workflows, timed collections, and service dependencies, but many profiles either omit TQ2 or leave it optional. If the receiver has not built support for it, a beautiful TQ2 segment may be ignored. This is one of those places where standards support and product support are not the same thing.
So let's go through each of the TQ2 fields and talk about the real integration choices behind them.
Like most set IDs, this is a sequence number for the TQ2 segments in the current group. The first relationship instruction is 1, the second is 2, and so on.
It is not the relationship identifier. The real relationship is carried by the related order numbers and the condition code. If a message is rebuilt or a relationship is added, the set ID can change without changing the order identities.
This flag says what kind of timing relationship is being described. In v2.5.1 the useful values are S for sequential and C for cyclical, with S treated as the default when the field is empty. The reserved result-style value is there in the table, but the practical behaviour most people discuss is sequence and cycle.
Sequential is the easier idea: this service depends on another one starting or ending. Cyclical is the harder idea: a set of service requests repeats in a loop, like alternating IV solutions. If you set this to cyclic, the cyclic entry/exit fields and repeat maximum start to matter. If you are not actually modelling a cycle, do not call it one just because the orders repeat.
This points to the placer order number of the related service request. For orders, that means the value from ORC-2. It repeats, so the current order can relate to more than one placer order.
Use the complete EI identifier, not just the visible order number if your interface uses assigning authorities. ORD-2001^^^EHR is a better reference than ORD-2001 when multiple systems are involved. At least one of related placer, related filler, or related placer group must be present, so this is one of the fields that makes the relationship real rather than decorative.
Sometimes the filler order number is the identifier the receiving side actually trusts. That belongs here, usually from ORC-3 of the related order. It also repeats for relationships to multiple filler orders.
Placer and filler numbers answer different ownership questions. The placer created the request. The filler performs it and may assign its own number once accepted. If the relationship is being sent before the filler has assigned an ID, this field may be empty. If you are sending a later update and the filler number exists, including it can make matching much cleaner.
A group number lets you point to a group of related orders rather than one individual order. In order messages, this is the ORC-4 style placer group number. That is useful when a set of child service requests belongs to a parent or bundled order.
Group identifiers are tempting, but they need disciplined use. If the sender reuses group IDs loosely, the receiver cannot safely work out which orders are really part of the relationship. Use this when the group has a real lifecycle and both sides know what belongs in it.
The relationship logic lives here. The standard codes are SS for start-start, SE for start-end, ES for end-start, and EE for end-end. ES is the classic "when the related order ends, start this order" pattern.
Either this field or the special service request relationship in TQ2-10 should be present. If both are missing, the segment has order numbers but no useful relationship logic. If both are present, make sure they tell the same story. "Start after order A ends" and "simultaneous" are not the same idea.
Cycles need a way to say where the loop starts and stops. HL7 uses * for the first service request in a cyclic group and # for the last service request. If the field is empty, the current request is neither the first nor the last in that cycle.
Only use this when TQ2-2 says the relationship is cyclic. A random asterisk in a non-cyclic relationship is not charming, it is confusing. For alternating IVs or rotating treatment components, this field lets the receiver know how to get back to the beginning of the cycle.
Delays and gaps go in this field. For example, you might start the current order thirty minutes after the related order ends, or end it ten minutes after the related order starts.
If this field is empty, the usual reading is no intentional gap between the related condition and the current action. That can be exactly right, but it can also hide an omitted delay. Use a clear time unit, preferably one the receiver can map safely, such as minutes, hours, or days.
A cycle still needs a limit somewhere, and this field can provide one. It gives the maximum number of times a cyclic group should repeat, and it only really makes sense when TQ2-2 is C.
There may also be an end date/time on the current or parent order, and the standard notes that those limits can stop the cycle before the repeat maximum is reached. That is another reason cycles need testing. It is not enough to check the first pass through the loop; you need to know how it stops.
HL7 names a few practical relationship patterns here. N is nurse prerogative, C is compound, T is tapering, E is exclusive, and S is simultaneous. These are especially useful in medication administration and treatment orders.
The examples make the field easier to understand. A compound order might be a mixed preparation dispensed as one product. A taper might step the same medication down over several days. Exclusive alternatives mean pick one of the options at a dosage time. Simultaneous means two or more items are intended to be given together. Nurse prerogative means the caregiver can choose or combine within an agreed set. These are not small display labels; they can change administration behaviour.
If you use this field, be generous with examples in the interface spec. Receivers may not implement all five behaviours, and some will only display them. That is still useful if everyone knows it is display-only. It is dangerous if the sender thinks it is executable and the receiver quietly treats it as text.