HL7 QCK messages acknowledge a deferred query — the small, fast reply a server sends back to confirm that a query it cannot answer immediately has been accepted and queued, with the actual data response to follow later. A QCK message is not the answer to a query; it is the receipt for one. When a requester submits a query in deferred mode, the responder returns a QCK to say "I have it, it is queued, expect the data later," and only afterwards sends the real response asynchronously as an RSP or RTB. This page explains what a QCK message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how a QCK acknowledgement relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What a QCK message represents
A QCK message — QCK stands for Deferred Query Acknowledgement — communicates that a deferred query has been received and queued by the responding system. The core of the message is the QAK segment, which carries the state of the query: the query tag echoed from the originating QBP in QAK-1, and the query response status in QAK-2 — typically WAIT to signal that processing is in progress, or OK, AE, AR if the responder can already report acceptance, application error, or application reject at the moment of queuing. The MSA segment forms the message-level acknowledgement, carrying AA, AE, or AR in MSA-1 and the control id of the originating query in MSA-2.
QCK is intentionally minimal. It is a response message, sent in reply to a deferred query (a QBP submitted with RCP-1 set to D for deferred mode) rather than as an unsolicited notification. The sender is the application that holds the data the requester is asking for; the receiver is the system that submitted the query. Because the QCK carries no patient or clinical content of its own, it is just the receipt that confirms the request was accepted — the data response follows asynchronously in a separate message once the responder has assembled it.
When a QCK message is sent
A QCK message is sent in reply to a query submitted in deferred mode — never unsolicited, and never to a real-time query. When the responder cannot or will not answer a query synchronously, it queues the request, returns a QCK so the requester can close the synchronous exchange, and delivers the real response later when the data is ready. A real-time query, by contrast, returns an RSP immediately and never produces a QCK.
Trigger event
The QCK message type carries a single trigger event:
QCK^Q02– Deferred query acknowledgement.
Because QCK has one trigger event, the receiver's handling turns on the acknowledgement code in MSA and the query response status in QAK — accepted and queued, processing, or rejected — rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the requesting system submitting a deferred query, the responder returning a QCK to acknowledge the queue, and the asynchronous data response following on its own leg.
{{diagram: requesting application → deferred QBP query → integration engine → responding system → QCK acknowledgement → integration engine → requesting application … later: responding system → RSP data response → integration engine → requesting application}}
Typical senders: any application that supports deferred query mode — clinical repositories, master patient indexes, document registries, and other systems that defer expensive lookups.
Typical receivers: the application that submitted the originating deferred query.
Direction: the synchronous acknowledgement leg of an asynchronous query-response exchange — the QCK travels back to whichever system sent the deferred query, ahead of the eventual data response.
Segments in a QCK message
The QCK_Q02 message is one of the smallest in HL7 v2.5.1 — just the message header, the message-level acknowledgement, the query acknowledgement that carries the queue state, and an optional error segment. 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 QCK message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (QCK^Q02), 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 Acknowledgment. Acknowledges the originating deferred query at the message level. It carries the acknowledgment code in MSA-1 (for example AA for application accept) and the message control id of the query being acknowledged in MSA-2, which lets the requester match the QCK to its outstanding query. Required. |
QAK | Query Acknowledgment. Carries the state of the deferred query. QAK-1 echoes the query tag from the originating QBP so the requester can correlate the acknowledgement to a specific query, and QAK-2 reports the query response status — WAIT while the responder is still processing, OK if the query has been accepted and queued, AE for application error, AR for application reject. Required. |
[{ERR}] | Error. Reports any error encountered while accepting the query — the location, the error code, and severity. Optional and repeating; present when the responder is rejecting the query or flagging a problem alongside an AE or AR status. |
[ ] = optional, { } = repeating
QCK has no repeating definition or order groups — there is one MSA and one QAK per message — because a QCK acknowledges exactly one deferred query. The canonical segment pages carry the full field-by-field detail.
Sample QCK message
Note. Constructed for illustration. Patient identifiers, query tags, dates, and names are fictional.
MSH|^~&|MPI|MERCYGEN|EHR|MERCYGEN|202006150930||QCK^Q02^QCK_Q02|MSG00078|P|2.5.1
MSA|AA|QRY00099
QAK|Q00099|WAIT|IHE PDQ Query^^HL70471
What this sample shows
The QCK^Q02 in MSH-9 marks a deferred query acknowledgement. MSA carries AA (application accept) and the control id QRY00099 of the deferred query being acknowledged, letting the requester correlate the QCK to its outstanding query. QAK echoes the query tag Q00099 from the originating QBP in QAK-1 and reports WAIT in QAK-2 — the responder has accepted the query, queued it, and will deliver the data response in a separate RSP once processing completes. No clinical content is carried; the QCK is just the receipt.
Working with QCK messages
Match the acknowledgement to the query through MSA and QAK
A QCK is meaningless without the query it acknowledges. Read the acknowledgment code in MSA-1 first — an AE or AR means the deferred query was not accepted — and match MSA-2 to the control id of the query you sent. Then read QAK: the query tag in QAK-1 ties the acknowledgement to a specific outstanding query, and the response status in QAK-2 tells you whether to expect a data response (WAIT, OK) or whether the query has been rejected (AE, AR).
Treat QCK as a receipt, not a result
A QCK carries no patient or clinical data. Do not surface its contents as a query result, and do not close the outstanding query in your tracking when a QCK arrives — close the request only when the asynchronous data response (typically an RSP or RTB) lands. The QCK's job is to let the requester release the synchronous channel while the responder works on the answer.
Query response status drives waiting behaviour
QAK-2 tells the requester what to do next. WAIT and OK both mean a data response is coming; AE and AR mean it is not. Surface the status on the outstanding-query tracking so a requester does not wait indefinitely for a response that will never arrive because the deferred query was rejected.
Cancel with QCN, not by silence
A requester that no longer needs a queued deferred response cancels the query with a QCN cancel-query message, referencing the original query tag. Letting an outstanding query time out silently leaves the responder holding state for a request the requester has abandoned.
Vendor variance. Use of
WAITversusOKinQAK-2differs across implementations — some responders useOKto mean "accepted and queued" and reserveWAITfor partial-processing states, while others useWAITfor any queued state. Confirm a partner's status semantics against their interface specification rather than assuming the base standard.
FHIR equivalent
A deferred-query acknowledgement corresponds, in FHIR's RESTful model, to an asynchronous interaction: a client requests a long-running operation, the server returns 202 Accepted with a location to poll, and the data response is delivered later when the operation completes.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for QCK_Q02, and there is no FHIR resource that represents the receipt itself — the 202 Accepted is a transport-layer signal rather than a resource. A FHIR representation produced from a QCK message is therefore the HTTP 202 response and its Content-Location polling URL on a FHIR $operation, with the queued operation eventually delivering the same data a v2 RSP would have carried.
Common pitfalls
Pitfall. Treating a QCK as the query result. A QCK is the receipt for a deferred query — it carries no patient or clinical data. Closing the outstanding request when the QCK arrives loses the data response, which is delivered later in a separate message.
Pitfall. Ignoring
QAK-2. AWAITorOKstatus means a data response is coming;AEorARmeans it is not. Waiting for a response that will never arrive ties up an outstanding-query slot indefinitely.
Pitfall. Sending QCK in reply to a real-time query. A query submitted with
RCP-1set toI(immediate) expects an RSP with the data, not a QCK. Responding with QCK to a real-time query is a protocol error and will leave the requester waiting for a response leg that the responder never intends to send.
How Vorro handles QCK messages
Vorro correlates each QCK acknowledgement to its originating deferred query, reads the acknowledgment code in MSA, and the query tag and response status in QAK, and routes the outstanding-query state to every subscribed destination in the format that system expects. Vorro tracks QAK-2 to know whether to keep an outstanding query open for the asynchronous RSP data response or to close it on an AE or AR rejection, supports cancellation through QCN, and, where a FHIR destination is configured, maps the deferred-query pattern to an asynchronous $operation with a 202 Accepted and polling URL — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- QBP — the query by parameter that, when submitted with
RCP-1set toD, is acknowledged by a QCK. - RSP — the segment-pattern response that carries the deferred data later, after a QCK has acknowledged the queued query.
- QCN — the cancel-query message a requester sends to withdraw a deferred query that has been acknowledged by a QCK.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for QCK_Q02
- HL7 v2-to-FHIR IG — segment maps index
- HL7 Messaging Standard Version 2.5.1 product brief
