HL7 OSR messages return the current status of one or more orders in reply to an OSQ^Q06 order status query. An OSR message is a filler's authoritative answer to a placer's on-demand status inquiry: it acknowledges the query, reports whether matching orders were found, and then delivers the current ORC order control code for each order — whether it is in process, completed, cancelled, on hold, or in any other defined state. This page explains what an OSR message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an OSR response relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an OSR message represents
An OSR message — OSR stands for Order Status Response — is the filler's reply to a placer that has asked for order status on demand. Where unsolicited order updates travel from the filler to the placer whenever the filler chooses to send them, an OSR is a solicited, correlated response: it exists only because an OSQ query was sent first, and its contents are bounded by the orders that matched the query.
The filler is the sender — typically a laboratory information system, radiology information system, or pharmacy — and the receiver is the placer that originated the query: an EHR, order management application, or integration engine. The heart of the response is ORC inside the RESPONSE group's ORDER sub-group, specifically ORC-5, which carries the current order status. A single OSR message can report the status of multiple orders, each in its own ORDER group, so one query and one response can reconcile an entire set of orders in a single round trip.
When an OSR message is sent
An OSR message is sent by the filler in direct reply to an OSQ^Q06 query. It is never sent unsolicited. Common scenarios that trigger the exchange include: a clinician querying whether a stat order has been received and queued, an order management system verifying that a cancellation was processed before allowing the user to re-order, or a reconciliation process confirming which orders are still active after an interface outage.
Trigger event
The OSR message type carries a single trigger event, which mirrors the trigger event of the query it answers:
OSR^Q06– Order Status Response, replying to anOSQ^Q06query.
Because OSR has one trigger event, the receiver's handling turns on the query acknowledgement code in QAK — OK for matches found, NF for no records found, AE for application error, and AR for query rejected — and on the current order status in ORC-5 within each ORDER group, rather than on the trigger code in MSH-9 alone.
Integration topology
The diagram shows the filler system returning a status response through the integration engine to the placer that originated the query.
{{diagram: placer system → OSQ^Q06 → integration engine → filler system → OSR^Q06 → integration engine → placer system}}
Typical senders: laboratory information system, radiology information system, pharmacy information system, or any filler application that holds orders and supports the OSQ/OSR query-response pair.
Typical receivers: EHR order management module, clinical workstation, order reconciliation process, or integration engine relaying the response to the originating placer.
Direction: response leg of a request–response exchange. The filler sends OSR only after receiving OSQ; traffic is bidirectional within a single logical transaction.
Segments in an OSR message
The OSR_Q06 message is structured in layers. A required outer shell — MSH, MSA, optional repeating ERR and NTE — acknowledges the query and reports any errors. A required QAK signals the query outcome. A required QRD echoes the original query definition. Then a repeating RESPONSE group carries one PID per patient, followed by a repeating ORDER group — one per matched order — that opens with ORC and can include OBR, notes, and observations. 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.
| Segment | Description |
|---|---|
MSH | Message Header. Opens every OSR message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (OSR^Q06), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 and deduplicate on MSH-10. |
MSA | Message Acknowledgement. Required acknowledgement segment that echoes the query message's control id from MSH-10 in MSA-2 and carries the acknowledgement code — AA for accepted, AE for application error, AR for rejected — in MSA-1. Separates transport-level acceptance of the message from the query outcome reported in QAK. |
[{ERR}] | Error. Repeating error detail segment, populated when the acknowledgement code in MSA-1 is AE or AR. Carries a structured error code, severity, and location pointing to the field or segment that caused the problem. Optional and repeating to allow multiple errors to be reported in a single response. |
[{NTE}] | Notes and Comments. Message-level notes that apply to the response as a whole, separate from the order-level notes carried inside the ORDER group. Optional and repeating. |
QAK | Query Acknowledgement. Reports the outcome of the query itself, independent of the transport acknowledgement in MSA. QAK-2 carries the query response status: OK — records found and returned; NF — no records found matching the query criteria; AE — application error processing the query; AR — query rejected. Receivers should check QAK-2 before processing the ORDER groups, since a response with NF or AE contains no order data. QAK-1 echoes the unique query id from QRD-4 of the originating OSQ, providing the correlation key for in-flight queries. |
QRD | Original Query Definition. Echo of the QRD from the originating OSQ^Q06 message. The filler returns it unchanged so the placer can confirm which query this response answers. Contains the query date and time in QRD-1, the unique query id in QRD-4, the who subject filter in QRD-7, and the order identifier or identifiers in QRD-8. |
[{ RESPONSE group }] | Repeating RESPONSE group. The repeating outer container that wraps all matching order data. One RESPONSE group is present per patient whose orders matched the query. When QAK-2 is NF or AE, no RESPONSE groups appear. |
PID | Patient Identification. Opens each RESPONSE group and identifies the patient whose orders follow. Carries the patient identifier list in PID-3 and the patient name in PID-5. Required within the RESPONSE group; one PID appears per patient. |
[{ ORDER group }] | Repeating ORDER group. Repeating sub-group within each RESPONSE group, one per matched order. Contains the order status and supporting detail for a single order. |
ORC | Common Order. The core of each ORDER group and the segment that carries the answer to the status query. ORC-1 holds the order control code; ORC-2 holds the placer order number; ORC-3 holds the filler order number; ORC-5 holds the current order status — the primary data point the placer requested. Status code values include: IP in process, CM completed, CA cancelled, HD on hold, RP replaced, DC discontinued, SC scheduled, A some but not all results available, and ER error. Required and present once per ORDER group. |
OBR | Observation Request. The observation or service request that the order is for — the ordered test, procedure, or item — with the requested date and time, the ordering provider, and the specimen source when applicable. Provides context that lets the receiving placer identify which clinical request the ORC status applies to without having to look up the order separately. |
[{NTE}] | Notes and Comments. Order-level notes that apply to this specific order, following the OBR. Optional and repeating; separate from the message-level NTE segments that appear before QAK. |
[{OBX}] | Observation/Result. Optional structured observations associated with the order — for example, a preliminary result value or a status-qualifying observation. Optional and repeating within the ORDER group. Not all fillers include OBX in an OSR; when present, the placer should treat the data as supplemental context rather than a full result delivery. |
[ ] = optional, { } = repeating
The RESPONSE group repeats once per matching patient, and the ORDER group within it repeats once per matching order, so a single OSR message can return the status of an entire set of orders across multiple patients in one response. The canonical segment pages carry the full field-by-field detail.
Sample OSR message
Note. Constructed for illustration. Patient identifiers, order numbers, dates, and names are fictional.
MSH|^~&|LIS|MERCYGEN|ORDERAPP|MERCYGEN|20260604093512||OSR^Q06^OSR_Q06|MSG00048|P|2.5.1
MSA|AA|MSG00047
QAK|QRY00031|OK
QRD|20260604093000|R|I|QRY00031|||1^RD|ORD445566^ORDERAPP|STS
PID|1||MR88901^^^MERCYGEN^MR||SMITH^JANE^A||19750315|F
ORC|SC|ORD445566^ORDERAPP|LIS997732^LIS||IP|||20260604085500|||DR999^CHEN^MICHAEL^^^^MD
OBR|1|ORD445566^ORDERAPP|LIS997732^LIS|85025^CBC WITH DIFFERENTIAL^CPT|||20260604085500
What this sample shows
The OSR^Q06 in MSH-9 marks an order status response. The MSA carries acknowledgement code AA and echoes the originating query's control id MSG00047 in MSA-2, confirming the query was accepted. The QAK echoes query id QRY00031 in QAK-1 and reports OK in QAK-2, indicating that matching records were found. The QRD is returned unchanged from the originating OSQ, confirming which query this response answers and which order was requested (ORD445566). The PID identifies the patient — medical record number MR88901, Jane A. Smith — opening the RESPONSE group. The ORC carries the answer: placer order number ORD445566, filler order number LIS997732, and order status IP (in process) in ORC-5, meaning the laboratory has received and is working the order. The OBR names the ordered service — a CBC with differential, CPT code 85025 — and confirms the collection time.
Working with OSR messages
ORC-5 is the status answer
The placer's question — what is the current state of this order? — is answered entirely by ORC-5 inside each ORDER group. Read ORC-5 first; everything else in the ORDER group provides context. The full set of status codes the filler may return: IP in process, CM completed, CA cancelled, HD on hold, RP replaced, DC discontinued, SC scheduled, A some but not all results available, and ER error. Map each code to the corresponding state in the placer's order management model before processing, rather than comparing raw strings at the point of use.
Check QAK-2 before processing ORDER groups
QAK-2 tells the placer whether the query matched anything. A response with NF (no records found) contains no RESPONSE or ORDER groups, and attempting to parse for them returns empty rather than an error — which is indistinguishable from a successful empty result unless QAK-2 was checked first. Process QAK-2 before descending into the RESPONSE group, and distinguish NF (the order does not exist on the filler) from AE (the filler encountered an error trying to look it up).
Correlate on QAK-1 and MSA-2
Two correlation keys are present in every OSR. MSA-2 echoes MSH-10 of the originating OSQ and confirms which specific OSQ message this response acknowledges. QAK-1 echoes QRD-4 of the originating query and is the reliable business-level correlation key when multiple outstanding queries may be in flight simultaneously. Use both: MSA-2 for transport-level matching and QAK-1 as the primary key for tying the response to the placer's pending query state.
Match OBR to the correct order
When a RESPONSE group contains multiple ORDER groups, use the composite placer order number in ORC-2 — which the placer assigned and recognises — to associate each ORC/OBR pair with the correct order in the placer's system. Do not rely on position within the message, since the filler may return orders in any sequence.
Vendor variance. Support for
OBXwithin an OSR ORDER group varies widely. Some fillers populateOBXwith preliminary results or status-qualifying observations; others omit it entirely and treat OSR as a status-only message. Confirm a filler's behaviour against their interface specification, and do not treat an absentOBXas an indication that no results exist — the result delivery channel is typically a separate message such as ORU.
FHIR equivalent
An order status response conceptually corresponds to the ServiceRequest resource in FHIR, where the status field carries the equivalent of ORC-5 — values such as active (IP or SC), completed (CM), revoked (CA or DC), or on-hold (HD).
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for OSR_Q06 and no ConceptMap for the ORC segment in this query-response context. A FHIR equivalent is approximated manually: each ORDER group maps to a ServiceRequest resource keyed on the placer order number from ORC-2, and the ORC-5 status code maps to the closest ServiceRequest.status value. The OBR service identifier maps to ServiceRequest.code. In a FHIR exchange, the equivalent of an OSR is a Bundle of matching ServiceRequest resources returned in response to a RESTful search — for example, GET /ServiceRequest?identifier=ORD445566 — with each resource's status field reflecting the current state.
Common pitfalls
Pitfall. Processing ORDER groups when QAK-2 is NF or AE. When no records match the query or the filler reports an error, no RESPONSE groups are present; a parser that skips
QAK-2and proceeds directly to ORDER-group parsing silently produces an empty result set rather than raising an alert for a failed or unmatched query.
Pitfall. Treating ORC-5 values as stable across filler systems. The HL7 standard defines the status code table, but fillers vary in which codes they use — some never send
A(some results available) and jump directly fromIPtoCM, others useSCfor orders not yet received by the lab. Validate the status code vocabulary against the filler's interface specification and map defensively, treating an unknown code as an alert rather than silently ignoring it.
Pitfall. Using OBX results from an OSR as the definitive result record. When
OBXsegments appear in an OSR ORDER group they are supplemental context, not a formal result delivery. The authoritative result arrives in a separate ORU message; recordingOBXdata from an OSR as a clinical result risks storing a preliminary or incomplete value as final.
How Vorro handles OSR messages
Vorro receives OSR^Q06 responses correlated against the OSQ queries it originates or relays, matching each response to its pending query by QAK-1 and MSA-2. Vorro checks QAK-2 before processing RESPONSE groups, raises integration alerts for NF and AE outcomes, and maps each ORC-5 status code to the placer's order state model before forwarding the status update. Where a FHIR destination is configured, Vorro maps each ORDER group to a ServiceRequest resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message — and delivers the result as a Bundle of status-updated resources. Vorro enforces configurable timeouts on OSQ/OSR round trips and surfaces unmatched responses — OSR messages that arrive without a corresponding outstanding query — as integration alerts rather than silently discarding them.
Related messages
- OSQ — the Order Status Query that triggers every OSR^Q06 response.
- ORM — the general order message used to place, modify, or cancel orders whose status OSR subsequently reports.
- OML — the laboratory order message for specimen-based orders whose current status an OSR can return.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for OSR_Q06
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for ORC in this context
- HL7 Messaging Standard Version 2.5.1 product brief
