HL7 OSQ Messages: Order Status Query

HL7 OSQ messages allow a placer system to query the current status of one or more orders without waiting for an unsolicited result. An OSQ message is a point-in-time inquiry: the sender names the order or orders it wants to check, and the receiver replies with an OSR that reports the ORC order control status for each matching order — whether it is still active, completed, cancelled, or on hold. This page explains what an OSQ message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an OSQ query relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an OSQ message represents

An OSQ message — OSQ stands for Order Status Query — is a solicited inquiry from a placer system to the filler that holds an order. Where unsolicited status updates arrive when the filler chooses to send them, an OSQ gives the placer a way to ask on demand. The query carries the order identifier or identifiers in QRD, and the filler responds with an OSR^Q06 that echoes the query and then reports the current ORC order control code for each match.

The sender is typically a placer system — an EHR, order management application, or clinical workstation — and the receiver is the system that filled or is filling the order, such as a laboratory information system, radiology system, or pharmacy. OSQ is deliberately lightweight: it carries no clinical detail about the order itself, only the identifiers needed to locate it. The clinical content returns in the OSR response.

When an OSQ message is sent

An OSQ message is sent whenever a placer needs to check order status on demand rather than waiting for a filler-initiated update. Common scenarios include: a clinician checking whether a stat order has been received, a reconciliation process confirming which orders are still active after an interface outage, or an order management system verifying that a cancellation was processed.

Trigger event

The OSQ message type carries a single trigger event:

• OSQ^Q06 – Query for the current status of one or more orders.

The corresponding response is OSR^Q06. Because OSQ has one trigger event, the receiver's handling turns on the contents of QRD — specifically the order identifier in QRD-8 and the query datetime in QRD-1 — rather than on the trigger code in MSH-9.

Integration topology

The diagram shows the placer system issuing a status query through the integration engine to the filler and receiving an OSR response.

{{diagram: placer system → OSQ^Q06 → integration engine → filler system → OSR^Q06 → integration engine → placer system}}

Typical senders: EHR order management module, clinical workstation, order reconciliation process, or integration engine polling for status.

Typical receivers: laboratory information system, radiology information system, pharmacy information system, or any filler application that accepts HL7 v2 order queries.

Direction: request–response. The placer sends OSQ and receives OSR; traffic is bidirectional within a single logical transaction.

Segments in an OSQ message

The OSQ_Q06 message is compact: a required MSH header, the required QRD Original Query Definition that identifies the order or orders to look up, and an optional QRF Query Filter that narrows the result set by additional criteria such as a date range. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.

[ ] = optional, { } = repeating

Because OSQ carries no patient demographics, visit data, or order detail, the message structure is intentionally minimal. All clinical content about the matching orders is returned by the filler in the OSR^Q06 response. The canonical segment pages carry the full field-by-field detail.

Sample OSQ message

Note. Constructed for illustration. Patient identifiers, order numbers, dates, and names are fictional.

MSH|^~&|ORDERAPP|MERCYGEN|LIS|MERCYGEN|20260604093000||OSQ^Q06^OSQ_Q06|MSG00047|P|2.5.1
QRD|20260604093000|R|I|QRY00031|||1^RD|ORD445566^ORDERAPP|STS
QRF|LIS|||20260601000000|20260604235959

What this sample shows

The OSQ^Q06 in MSH-9 marks an order status query. The QRD carries the query timestamp 20260604093000 in QRD-1, query format R (record-oriented) in QRD-2, immediate priority I in QRD-3, and unique query id QRY00031 in QRD-4. QRD-7 identifies the subject of the query, and QRD-8 names the order ORD445566 from application ORDERAPP that the placer wants status on. The QRF adds a date window — orders placed between 20260601000000 and 20260604235959 — so the filler limits its search to that range. The filler's OSR^Q06 will echo both segments and then report the current ORC order control code for each matching order.

Working with OSQ messages

QRD-8 is the lookup key

The filler locates orders using the what subject filter in QRD-8. Each repetition of QRD-8 can carry a single order identifier encoded as a CWE (coded with exceptions) component, so a single OSQ can request the status of multiple orders in one query. Confirm with the filler how it expects identifiers encoded — some systems expect the placer order number, others the filler order number, and others an application-scoped composite — rather than assuming the base standard's flexibility is fully implemented.

Correlate response on QRD-4

The unique query id in QRD-4 is echoed in the OSR response and is the reliable correlation key when multiple outstanding OSQ messages may be in flight simultaneously. Use QRD-4 rather than MSH-10 alone to tie each OSR to its originating OSQ, since MSH-10 identifies the response message, not the query it answers.

Use QRF to limit result size

When querying a filler with a large order history, sending QRD-8 without a QRF date window can return more rows than the placer can process. Use QRF-2 and QRF-3 to bound the search to a clinically meaningful window, and use QRD-6 to set a quantity limit if the filler honours it.

Polling versus event-driven design

OSQ is a polling mechanism. For high-frequency status needs, an event-driven design — receiving unsolicited ORR or ORL updates — is more efficient. Use OSQ for on-demand checks, reconciliation after outages, or when the filler does not send unsolicited status updates.

Vendor variance. Support for OSQ^Q06 varies widely across filler systems. Some laboratory and pharmacy systems implement their own proprietary query mechanism instead of, or in addition to, OSQ. Confirm that the filler accepts and responds to OSQ^Q06 before building an integration that depends on it, and test the QRF date filter specifically — many implementations accept the segment but ignore its fields.

FHIR equivalent

An order status query conceptually corresponds to a FHIR RESTful search on the ServiceRequest resource filtered by status — for example, GET /ServiceRequest?identifier=ORD445566&status=active,completed,cancelled,on-hold.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for OSQ_Q06 and no ConceptMap for the QRD or QRF segments. A FHIR equivalent is approximated manually: the order identifier from QRD-8 maps to a ServiceRequest.identifier search parameter, and the date window from QRF maps to an authored date range filter. The FHIR response — a Bundle of matching ServiceRequest resources — carries the same information that the OSR response would return in ORC order control codes.

Common pitfalls

Pitfall. Assuming the filler supports OSQ^Q06. Many filler systems in common deployment — particularly older laboratory and radiology systems — do not implement the OSQ trigger event. Verify support before building an integration that relies on it, and have a fallback strategy such as polling the HL7 feed or using a proprietary query API.

Pitfall. Sending QRD-8 without confirming the expected identifier type. Fillers vary in whether they match on placer order number, filler order number, or a site-specific composite. Sending the wrong identifier type returns an empty OSR with no error, which looks identical to a genuinely empty result set.

Pitfall. Ignoring QRD-4 when correlating responses. If the placer sends concurrent OSQ messages and correlates only on MSH-10, it may match a response to the wrong query. Always use QRD-4 as the primary correlation key.

How Vorro handles OSQ messages

Vorro supports OSQ^Q06 both as a sender — constructing well-formed queries with correct QRD-4 correlation ids and QRF date windows — and as a routing intermediary that forwards queries to the appropriate filler system and relays the OSR response back to the placer. Vorro tracks in-flight queries by QRD-4, enforces configurable timeouts for OSR responses, and surfaces unmatched or timed-out queries as integration alerts. Where a filler does not implement OSQ, Vorro can substitute a filler-specific proprietary query or switch to an event-driven status update pattern, so the placer application always receives order status through a consistent interface regardless of the downstream system's capabilities.

Related messages

• OSR — the Order Status Response returned by the filler in reply to an OSQ^Q06 query.
• ORM — the general order message used to place, modify, or cancel orders that OSQ subsequently queries.
• OML — the laboratory order message for specimen-based orders whose status can be checked with OSQ.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms no message map for OSQ_Q06
• HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for QRD or QRF
• HL7 Messaging Standard Version 2.5.1 product brief