The QRD (Original-Style Query Definition) segment carries the core parameters of a legacy HL7 v2 query. It states when the query was issued, how the response should be formatted, how urgently it should be processed, and which subjects and data the requester is interested in. QRD is the lead segment of the original-style query mechanism and is almost always followed by a QRF (Original-Style Query Filter) segment that further narrows the request. Together QRD and QRF form the request side of the legacy query group used throughout pre-2.4 HL7 messaging.
Purpose
QRD answers the question "what is being asked, and how should the answer come back?" Its required fields establish the identity and shape of the query: the Query Date/Time (QRD-1), the Query Format Code (QRD-2), the Query Priority (QRD-3), and a sender-assigned Query ID (QRD-4) that the responding system echoes so the requester can correlate the response. The Quantity Limited Request (QRD-7) bounds how much data is returned, and the Who Subject Filter (QRD-8) and What Department Data Code (QRD-9) describe the subjects and data domain in scope. Optional deferred-response fields (QRD-5, QRD-6) allow a system to ask for the answer later rather than immediately.
QRD does not, by itself, express fine-grained selection criteria such as date ranges or status qualifiers. That responsibility belongs to the companion QRF segment. The two are designed to be read as a pair.
Used in
QRD is one of the two original-style query segments used in legacy HL7 v2 query messages. It appears at the head of the query definition in QRY query messages and is paired with QRF to complete the request. The same QRD/QRF pair also appears on the response side of the original query mechanism, in DSR (Display Response) and UDM (Unsolicited Display Message) responses, where the responding system echoes the query parameters back to the requester.
See the QRY message page for the full message structure, and the companion QRF segment for the filter that accompanies QRD.
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (QRD) for sequence, name, data type, and repetition. Length is not published in the javadocs (—); Required and Table # are filled from the HL7 v2.5.1 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| QRD-1 | Query Date/Time | ts | — | R | — | — | Date and time the query was generated |
| QRD-2 | Query Format Code | id | — | R | — | HL70106 | Format requested for the response data |
| QRD-3 | Query Priority | id | — | R | — | HL70091 | Deferred or immediate processing priority |
| QRD-4 | Query ID | st | — | R | — | — | Sender-assigned identifier for correlation |
| QRD-5 | Deferred Response Type | id | — | O | — | HL70107 | Before or after the requested date/time |
| QRD-6 | Deferred Response Date/Time | ts | — | O | — | — | When a deferred response is expected |
| QRD-7 | Quantity Limited Request | cq | — | R | — | — | Maximum amount of data to return |
| QRD-8 | Who Subject Filter | xcn | — | R | Y | — | Identifies the subject of the query |
| QRD-9 | What Subject Filter | ce | — | O | Y | — | Nature of the data requested |
| QRD-10 | What Department Data Code | ce | — | R | Y | HL70048 | Department or data domain in scope |
| QRD-11 | What Data Code Value Qual. | vr | — | O | Y | — | Value range qualifying the data code |
| QRD-12 | Query Results Level | id | — | O | — | — | Level of detail requested in results |
Note: in the HL7 v2.5.1 original query, the well-established required fields are QRD-1, QRD-2, QRD-3, QRD-4, QRD-7, QRD-8, and QRD-9 (the department/data-domain code), reflecting the minimum needed to issue a meaningful query.
Most-used fields
In practice, integration engines spend most of their time on a handful of QRD fields:
- QRD-2 Query Format Code drives how the responder packages results (for example, a tabular display versus record-oriented output) and must be agreed between trading partners.
- QRD-3 Query Priority distinguishes immediate from deferred processing and feeds straight into the responder's scheduling.
- QRD-4 Query ID is the correlation key. The response echoes it, so engines key their pending-request tracking on this value.
- QRD-7 Quantity Limited Request protects responders from unbounded result sets and is frequently used to implement paging.
- QRD-8 Who Subject Filter is the patient or person identifier in a patient query and is the field most often populated with real-world identifiers.
Version differences (2.3 to 2.8.2)
QRD is part of the original (pre-2.4) query mechanism. In v2.3 and v2.3.1, QRD and QRF were the standard way to express a query, paired inside QRY and answered by DSR/UDM responses. Beginning with v2.4, HL7 introduced the modern query infrastructure built on QPD (Query Parameter Definition), RCP (Response Control Parameter), and the QBP/RSP message pair. From v2.4 onward the original-style QRD/QRF mechanism is retained for backward compatibility but is largely deprecated in favor of QPD/RCP/QBP. The field structure of QRD itself is stable across v2.3 through v2.5.1; later releases (through v2.8.2) carry it forward unchanged but steer new development toward the conformance-based query model. The Query Response Instance segment, QRI, was added later to support tabular responses and belongs to the newer mechanism, not to QRD.
Common mistakes
- Omitting QRD-4 Query ID, or reusing the same value across concurrent queries, which breaks response correlation.
- Treating QRD as self-sufficient and forgetting the companion QRF segment, leaving selection criteria such as date ranges unexpressed.
- Confusing QRD-8 Who Subject Filter (the subject identity) with QRD-9 What Subject Filter (the nature of the data). They answer different questions.
- Leaving QRD-7 Quantity Limited Request empty when the responder expects a bound, producing oversized result sets.
- Sending an immediate priority in QRD-3 while also populating the deferred-response fields (QRD-5, QRD-6), which contradict one another.
- Negotiating no shared value set for QRD-2 Query Format Code, so the requester and responder disagree on result packaging.
Examples
Minimal valid segment (only the well-established required fields populated):
QRD|20260610142530|R|I|Q0001||| ^^^^^^^^Q&PATIENT|||DEPT001
Fully-populated segment:
QRD|20260610142530|R|D|Q0001|B|20260611080000|10^records|PX0042^Sample^Patient^^^^^^HOSP^^^^MR|RES^Result data^HL70048|LAB^Laboratory^HL70048|0&999|S
Annotated breakdown:
QRD|20260610142530|R|D|Q0001|B|20260611080000|10^records|PX0042^Sample^Patient|RES|LAB|0&999|S
| | | | | | | | | | | |
| | | | | | | | | | | +-> QRD-12 Query Results Level (S = summary)
| | | | | | | | | | +-------> QRD-11 What Data Code Value Qual. (range 0..999)
| | | | | | | | | +-----------> QRD-10 What Department Data Code (LAB)
| | | | | | | | +---------------> QRD-9 What Subject Filter (RES = results)
| | | | | | | +--------------------> QRD-8 Who Subject Filter (patient PX0042)
| | | | | | +-----------> QRD-7 Quantity Limited Request (10 records)
| | | | | +----------------------------> QRD-6 Deferred Response Date/Time
| | | | +------------------------------> QRD-5 Deferred Response Type (B = before)
| | | +------------------------------------> QRD-4 Query ID (Q0001)
| | +--------------------------------------> QRD-3 Query Priority (D = deferred)
| +----------------------------------------> QRD-2 Query Format Code (R = record-oriented)
+-------------------------------------------------------> QRD-1 Query Date/Time
In-context excerpt 1 — QRD with its QRF filter inside a QRY^A19 patient query request:
MSH|^~&|REQAPP|REQFAC|RESPAPP|RESPFAC|20260610142530||QRY^A19^QRY_A19|MSG00021|P|2.5.1
QRD|20260610142530|R|I|Q0001|||10^records|PX0042^Sample^Patient^^^^^^HOSP^^^^MR|DEM^Demographics^HL70048|ADT^Admissions^HL70048
QRF|HOSP||20260101000000|20260610000000
In-context excerpt 2 — a deferred QRD/QRF pair requesting laboratory data for a single patient:
MSH|^~&|REQAPP|REQFAC|RESPAPP|RESPFAC|20260610150000||QRY^A19^QRY_A19|MSG00022|P|2.5.1
QRD|20260610150000|R|D|Q0002|B|20260611080000|25^records|PX0099^Roe^Jordan^^^^^^HOSP^^^^MR|RES^Results^HL70048|LAB^Laboratory^HL70048
QRF|LAB||20260601000000|20260610000000|||CURRENT
FHIR mapping
There is no segment-level ConceptMap published in the v2-to-FHIR Implementation Guide for QRD. The original-style query mechanism is messaging infrastructure with no direct FHIR resource equivalent: FHIR expresses queries through RESTful search (query parameters on a resource type endpoint) and returns matches as a searchset Bundle. Conceptually, QRD-8 Who Subject Filter corresponds to a search parameter such as patient or subject, QRD-7 Quantity Limited Request corresponds to the _count paging parameter, and QRD-2 Query Format Code has no FHIR analogue because content negotiation in FHIR is handled by the Accept header. These are conceptual parallels for understanding only, not a normative mapping.
Engine considerations
- Correlation: persist QRD-4 Query ID against the outbound request so the inbound DSR/UDM (or RSP, if bridged) can be matched back. Treat duplicate Query IDs from the same sender as a conflict.
- Priority handling: route QRD-3 deferred queries (priority D) to a queue and immediate queries (priority I) to synchronous processing. If QRD-5/QRD-6 are present but QRD-3 says immediate, flag the contradiction rather than silently choosing one.
- Paging: enforce QRD-7 Quantity Limited Request as a hard cap when generating responses, and surface it to downstream systems so they can request subsequent pages.
- Repetition: QRD-8, QRD-9, QRD-10, and QRD-11 may repeat. Parsers must handle the repetition separator and not assume single-valued fields.
- Pairing: never process a QRD without checking for a following QRF; many trading-partner agreements require both, and dropping QRF silently widens the query.
- Bridging: when translating legacy QRY traffic to the modern model, map QRD/QRF onto QPD/RCP rather than attempting a field-for-field passthrough.
How Vorro parses and produces QRD
When Vorro ingests a legacy QRY message, it parses QRD into a normalized query-definition object: QRD-1 and QRD-6 are converted to normalized timestamps (internally we call this the primary timestamp form), QRD-4 is captured as the correlation key, and the repeating QRD-8 through QRD-11 fields are expanded into lists. The paired QRF is parsed alongside and the two are held together as a single logical request so that no selection criteria are lost.
When producing QRD, Vorro enforces the well-established required fields (QRD-1, QRD-2, QRD-3, QRD-4, QRD-7, QRD-8, QRD-9 department/data-domain) and validates QRD-2, QRD-3, and QRD-5 against their code tables before emission. Quantity limits from QRD-7 are honored when Vorro itself acts as a responder, and Query IDs are guaranteed unique per sender within a configurable correlation window. Where a downstream endpoint speaks only the modern query model, Vorro maps the parsed QRD/QRF pair onto QPD/RCP automatically.
Related pages
- QRF segment — the original-style query filter paired with QRD
- QID segment — query identification in the modern query model
- QRY message — the legacy query message that carries QRD and QRF
