HL7 QCN messages cancel a previously submitted query before its response is returned. A QCN message tells the query receiver to stop processing the identified query and return no response data for it. This page explains what a QCN message represents, the trigger event that carries it, every segment the message contains and what each one holds, and how a QCN cancel relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What a QCN message represents
A QCN message — QCN stands for Cancel Query — communicates that the originating system no longer needs the response to a query it previously submitted. The core of the message is the QID segment, which carries two pieces of identification: the query tag in QID-1, which is the unique identifier that was assigned to the original query, and the message query name in QID-2, which is the coded name of the query profile and matches the value that was placed in QPD-1 of the originating QBP or QSB message.
The sender is the system that initiated the original query, and the receiver is the system that received and is processing that query. Upon receiving a QCN message, the receiver should immediately halt processing of the identified query and must not send any response data for it. QCN is simple by design — it carries no clinical payload beyond the identification of the query to be cancelled — but it is important for deferred and asynchronous query patterns where a response may not be returned immediately and the requesting system may need to withdraw the request.
When a QCN message is sent
A QCN message is sent when a query-originating system determines it no longer requires a response to a query that is in progress on the receiving system. This most commonly occurs in deferred or asynchronous query patterns, where the query was submitted and the response is being assembled or queued, and the requesting application has since moved on — a user session ended, a workflow was cancelled, or the patient context changed. Because QCN carries only the identification of the query to cancel, it is lightweight and can be dispatched quickly.
Trigger event
The QCN message type carries a single trigger event:
QCN^J01— Cancel query.
Because QCN has one trigger event, the receiver's handling turns on the query tag in QID-1, which uniquely identifies the outstanding query to be cancelled, rather than on any additional state in MSH-9.
Integration topology
The diagram shows the querying system emitting a cancel event through the integration engine to the query-processing system that holds the outstanding query.
{{diagram: querying system → QCN message → integration engine → query-processing system (stops outstanding query)}}
Typical senders: EHR, clinical workstation, order-entry system, or any application that issues deferred or asynchronous queries.
Typical receivers: query-processing system, laboratory information system, pharmacy system, or any system that accepts and queues queries for deferred response.
Direction: unidirectional notification from the query originator to the query processor, instructing it to stop and discard the identified outstanding query.
Segments in a QCN message
The QCN_J01 message structure is intentionally minimal. It contains a required message header and a single clinical segment identifying the query to cancel. 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 QCN message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (QCN^J01), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 and deduplicate on MSH-10. |
QID | Query Identification. The only clinical segment in the message, and required. QID-1 carries the query tag — the unique identifier assigned to the original query in the originating QBP or QSB message — which the receiver uses to locate and halt the outstanding query. QID-2 carries the message query name, a coded element identifying the query profile; it matches the value placed in QPD-1 of the original query and allows the receiver to confirm that the query tag refers to the expected query type before cancelling. |
[ ] = optional, { } = repeating
The entire clinical intent of a QCN message is expressed in two fields of a single segment. The canonical segment page for QID carries the full field-by-field detail.
Sample QCN message
Note. Constructed for illustration. Query tags, application names, and identifiers are fictional.
MSH|^~&|EHR|MERCYGEN|LABSYS|MERCYGEN|202006151045||QCN^J01^QCN_J01|MSG00089|P|2.5.1
QID|Q2291837|Q22^Find Candidates^HL7
What this sample shows
The QCN^J01 in MSH-9 marks a cancel-query message. MSH-10 carries the message control id MSG00089, which the receiver can use to acknowledge receipt of the cancellation. The QID segment carries query tag Q2291837 in QID-1 — this is the value that was originally assigned in the QBP message's query tag field and uniquely identifies the outstanding query on the receiving system. QID-2 carries the coded message query name Q22^Find Candidates^HL7, confirming that the query to be cancelled is the Find Candidates query profile, which matches QPD-1 of the originating QBP. The receiver should locate the query identified by Q2291837, halt any processing underway, and discard any assembled response data.
Working with QCN messages
Match on the query tag, not the message control id
The query tag in QID-1 is the handle to the outstanding query on the receiving system; the message control id in MSH-10 identifies only the QCN message itself. Use QID-1 to locate and stop the query. If the receiver cannot find a query matching the tag — because the response was already dispatched before the QCN arrived — it should acknowledge the cancellation normally and take no further action. Racing between a response already sent and a cancel just arriving is expected and benign.
Acknowledge the cancellation
Even though no response data is returned for the cancelled query, the receiver should send an application-level acknowledgement (ACK) for the QCN message itself, using the message control id in MSH-10. An AA application-accept acknowledgement confirms the cancel was received and acted on. A CE or CR acknowledgement signals that the cancel was received but could not be applied — for example, because the response was already sent.
Confirm the query name before cancelling
QID-2 carries the query profile name alongside the query tag. Receivers that support multiple query types should verify that QID-2 matches the profile registered for the query tag in QID-1 before cancelling. A mismatch indicates either a configuration error or a malformed message and should be rejected with an AR acknowledgement rather than silently cancelling the wrong query.
Vendor variance. Some systems do not implement QCN and instead rely on timeouts or session teardown to abandon outstanding queries. Confirm that a query-processing partner supports active cancellation via QCN before depending on it in a deferred-query workflow, and agree on the expected acknowledgement behaviour in the interface specification.
FHIR equivalent
A cancel-query has no direct FHIR equivalent and no published mapping. The HL7 v2-to-FHIR Implementation Guide provides no message map for QCN_J01 and no ConceptMap for the QID segment.
Conceptually, the cancel-query intent can be represented in FHIR in two ways depending on the query pattern being cancelled. Where the original query was submitted as a FHIR asynchronous $operation (using the Bulk Data or async request pattern), cancelling it corresponds to the client sending a DELETE request to the status endpoint for that operation. Where the original query was modelled as a FHIR Subscription resource, cancelling it corresponds to deleting or deactivating the Subscription. Neither representation is a direct structural mapping from QCN — the choice depends on how the FHIR environment implemented the original query.
Common pitfalls
Pitfall. Treating a late-arriving QCN as an error when the response was already sent. If the query response was dispatched before the QCN arrived, the cancel arrives too late but is not a fault condition. Acknowledge normally and log the race; do not raise an error or attempt to retract the response.
Pitfall. Ignoring
QID-2and matching only on the query tag. A query tag is expected to be unique within a session, but implementations that reuse short numeric tags across query types can produce collisions. Validate bothQID-1andQID-2before cancelling to avoid inadvertently stopping the wrong query.
Pitfall. Assuming QCN is universally supported. QCN is part of the HL7 v2 query framework but is not implemented by all query-capable systems. A system that accepts QBP queries may not process QCN messages; verify support during integration design rather than discovering the gap at runtime.
How Vorro handles QCN messages
Vorro processes inbound QCN messages over MLLP or another configured transport, extracts the query tag from QID-1 and the query profile name from QID-2, and passes the cancellation to the query-management layer. Vorro deduplicates on MSH-10 and returns an application-level acknowledgement for every QCN it receives. When the identified query is still outstanding, Vorro halts its processing and suppresses any queued response. When the response has already been dispatched, Vorro acknowledges the QCN and records the late-cancel in the message audit log without attempting to retract data that has already been delivered.
Related messages
- QBP — the query-by-parameter message that originates the query a QCN cancels.
- QSX — the cancel subscription message, a related cancel pattern for subscription-based queries.
- RSP — the response to a query; a QCN instructs the receiver not to send this.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for QCN_J01
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for QID
- HL7 Messaging Standard Version 2.5.1 product brief
