HL7 QRY_R02 Query for Results of Observation

Ask a result source for observations that already exist.
HL7 message structure QRY_R02 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

SegmentNameRequiredRepeatable
MSH
 Message Header Yes No
SFT
 Software Segment No Yes
QRD
 Original-Style Query Definition Yes No
QRF
 Original style query filter Yes No

QRY_R02 is a query for observation results. Instead of waiting for an unsolicited ORU_R01, the requester asks a result source for existing observations that match a patient, order, date range, department, or other local filter.

This is an older QRD/QRF-style query. It is useful in legacy lab, radiology, and clinical-data retrieval workflows, especially where a receiver needs to resynchronize or request a known result set on demand.

A small QRY R02 example

MSH|^~\&|EHR|CITYHOSP|LAB|CITYHOSP|20260717103000||QRY^R02^QRY_R02|QRY020001|P|2.5.1 QRD|20260717103000|R|I|QRY020001|||10^RD|123456^^^CITYHOSP^MR|RES|LAB QRF|LAB|20260701000000|20260717235959|CBC^Complete blood count^L

What workflow it represents

The sender is asking for results that the receiver already has. That receiver might be a LIS, RIS, EHR repository, or integration engine with access to historical results. The expected response is commonly ORF_R04, which returns patient, order, observation, and status information.

Use this message for retrieval, not creation. A QRY_R02 should not place a new order, update a result, or trigger fresh testing. It asks for existing observation data.

How to read the structure

The structure is MSH, optional SFT, QRD, and required QRF. QRD describes the query identity, quantity, subject, and what data is being requested. QRF filters the request by source, date range, and additional criteria.

The filter contract needs to be local and explicit. A date range might mean specimen collection time, observation time, result status time, or report release time. Those are not interchangeable when someone is reconciling missing results.

Implementation traps

The biggest trap is ambiguity in dates and identifiers. If the requester uses patient ID and a date range, the receiver must know whether to return all observations, only final observations, corrected results, cancelled orders, or only a specific service.

Also be careful with large result sets. A "give me everything for this month" query can turn into a transport and UI problem if continuation or quantity limits are not agreed up front.

Reference notes

HL7 observation-query guidance describes solicited observation reporting as a request/response workflow for existing results, with QRD and QRF defining the query and filter. See the HL7 v2.4 observation chapter mirror at HL7 Europe Chapter 7 and the R02 event mirror at VICO R02.