HL7 QRD Original-Style Query Definition
HL7 field reference QRD 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 |
|---|---|---|---|---|---|
| QRD.1 | Query Date/Time | Yes | No | TS | |
| QRD.2 | Query Format Code | Yes | No | ID | 0106 |
| QRD.3 | Query Priority | Yes | No | ID | 0091 |
| QRD.4 | Query ID | Yes | No | ST | |
| QRD.5 | Deferred Response Type | No | No | ID | 0107 |
| QRD.6 | Deferred Response Date/Time | No | No | TS | |
| QRD.7 | Quantity Limited Request | Yes | No | CQ | 0126 |
| QRD.8 | Who Subject Filter | Yes | Yes | XCN | |
| QRD.9 | What Subject Filter | Yes | Yes | CE | 0048 |
| QRD.10 | What Department Data Code | Yes | Yes | CE | |
| QRD.11 | What Data Code Value Qual. | No | Yes | VR | |
| QRD.12 | Query Results Level | No | No | ID | 0108 |
QRD is the older query-definition segment used before QPD/RCP became the cleaner pattern.
The standard describes QRD this way: The QRD segment is used to define a query. This segment is not carried forward to the recommended queries for v 2.4.
Query segments define what the sender is asking for, how the receiver should format the answer, and how a multi-message response is continued or limited.
A query is an interface contract. The tag, parameters, row definitions, sort/filter rules, and continuation pointers must match exactly or the receiver may return technically valid data that is not what the requester expected.
The v2.5.1 structures show QRD in ADR_A19 - Patient query, DOC_T12 - Document query, DSR_Q01 - Query sent for immediate response, and DSR_Q03 - Deferred response to a query, and 32 other message structures. That tells you where it can appear, but the implementation guide still decides which optional fields are meaningful.
For practical interface work, read the generated field panel for datatype, required, repeatable, and table details, then use the notes below to decide what the field should mean in the receiving workflow.
QRD-1 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
QRD-2 identifies the Query Format Code for this query workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0106; many real interfaces narrow that list further, so follow the receiver's implementation guide.
QRD-3 qualifies the query workflow rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
Use the agreed value set, starting from HL7 table 0091. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
QRD-4 names the query, event, stored procedure, virtual table, or profile being invoked. This is the semantic switch for the query, so both sides need to agree on the allowed names and their parameter rules.
QRD-5 qualifies the query workflow rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
Use the agreed value set, starting from HL7 table 0107. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
QRD-6 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
QRD-7 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
The generated panel links this to HL7 table 0126; many real interfaces narrow that list further, so follow the receiver's implementation guide.
QRD-8 carries the criteria or parameters that narrow the query. Keep each parameter in the expected datatype shape and avoid relying on display text that the receiver cannot evaluate.
Repeats should represent separate criteria or parameters in the order the query profile expects, not a free-form pile of search terms.
QRD-9 carries the criteria or parameters that narrow the query. Keep each parameter in the expected datatype shape and avoid relying on display text that the receiver cannot evaluate.
Repeats should represent separate criteria or parameters in the order the query profile expects, not a free-form pile of search terms.
QRD-10 identifies the What Department Data Code for this query workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
If there are several identifiers, use repetitions deliberately and make each repeat self-explanatory rather than relying on position alone.
QRD-11 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
This field can repeat. Use repetitions for separate real-world values, not as a workaround for putting several unrelated ideas in one field.
QRD-12 qualifies the query workflow rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
Use the agreed value set, starting from HL7 table 0108. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.