HL7 QSB messages establish a standing query subscription on a server — instead of a client repeatedly polling for new data, the client sends one QSB message to register its interest, and the server pushes matching results as they become available. The server responds with an acknowledgement (ACK) or a response (RSP) confirming whether the subscription was accepted. This page explains what a QSB message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how a QSB subscription relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What a QSB message represents
A QSB message — QSB stands for Create Subscription — instructs a server to open a standing query and to push results to the requesting application each time data matching the subscription criteria becomes available. The QPD segment carries the identity of the query profile and the filter parameters that define what the client wants to receive; the RCP segment controls how the server should deliver results — immediately or deferred, in what volume, and in what order.
The sender is any client application that wants event-driven data delivery rather than polling — a clinical decision-support engine, a results viewer, or a public-health reporting system. The receiver is the server that holds the data and is capable of satisfying subscriptions. Once a subscription is registered the server takes over responsibility for delivery, so the client does not need to issue repeated QBP queries to check for new matching records. The subscription is cancelled with a QSX^J02 message.
When a QSB message is sent
A QSB message is sent once, at the moment the client wants to begin receiving pushed results for a given query profile and set of filter criteria. A client may maintain multiple concurrent subscriptions by sending separate QSB messages with different query profiles or different filter values in QPD. Each subscription is identified by the unique message control id in MSH-10, which the server uses to track and later cancel the standing query.
Trigger event
The QSB message type carries a single trigger event:
QSB^Z83– Create subscription.
The trigger code Z83 is a site-defined event code, meaning the query profile name in QPD-1 — not the trigger code alone — fully identifies the kind of data being subscribed to. The server's handling therefore turns on the contents of QPD as well as on MSH-9.
Integration topology
The diagram shows the subscribing client registering a standing query through the integration engine, after which the server pushes matching results without further prompting.
{{diagram: subscribing client → QSB message → integration engine → server; server → pushed results → integration engine → subscribing client}}
Typical senders: clinical decision-support engine, results-review workstation, laboratory information system, public-health reporting gateway.
Typical receivers: EHR or data repository capable of managing standing queries and pushing results, health information exchange server.
Direction: the QSB itself is a request from client to server; subsequent result pushes travel in the reverse direction from server to client.
Segments in a QSB message
The QSB_Z83 message is a compact structure: a required message header, a required query parameter definition, a required response control parameter, and an optional continuation pointer for paging. There are no patient or order groups — the subscription applies at the query level, not to a single patient or encounter. 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 QSB message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (QSB^Z83), carries the message control id in MSH-10, and pins the HL7 version. The server uses MSH-10 as the durable subscription identifier — it appears in the acknowledgement and is referenced when the subscription is later cancelled with QSX. |
QPD | Query Parameter Definition. The heart of the subscription. QPD-1 carries the message query name — a coded identifier that references the specific query profile the client is subscribing to, defining the shape of the data the server will push. QPD-2 carries the query tag, a unique identifier for this query instance. QPD-3 and beyond carry user parameters — the subscription filter criteria expressed as field-by-field values defined by the query profile, such as patient identifiers, result types, date ranges, or event types. The query profile determines which parameters are required and what coded values are permitted. |
RCP | Response Control Parameter. Controls how the server delivers pushed results. RCP-1 sets query priority: D (deferred) means the server may batch results; I (immediate) means the server should push results as soon as they are available. RCP-2 sets the quantity limited request — a maximum number of records the server should include in each pushed response. RCP-5 carries the modify indicator, which signals whether this message is creating a new subscription or modifying an existing one. RCP-6 specifies a sort-by field so the server delivers results in a defined order. RCP-7 lists segment group inclusions, allowing the client to request that the server include or suppress optional segment groups in the pushed responses. |
[DSC] | Continuation Pointer. Used when the subscription request itself spans a continuation — carries the pointer value from a previous partial response so the server can resume from the correct position. Optional; present only when the QSB is part of a multi-message subscription setup. |
[ ] = optional, { } = repeating
The simplicity of the structure reflects the purpose: the QSB is an instruction, not a data payload. All of the subscription intelligence lives in QPD and RCP. The pushed results that arrive after the subscription is registered carry the full segment structure appropriate to the query profile — typically an RSP message whose segments mirror the query response defined in the profile.
Sample QSB message
Note. Constructed for illustration. Application names, facility identifiers, query profile codes, and filter values are fictional.
MSH|^~&|CDSSAPP|MERCY|LABSERVER|MERCY|20260604083000||QSB^Z83^QSB_Z83|SUB00099|P|2.5.1
QPD|LAB_RESULT_SUBSCRIPTION^Lab Result Subscription^LocalQueryProfile|Q001|^RES^F^^20260601000000^20261231235959
RCP|I|100^RD|||||PID~OBR~OBX
What this sample shows
The QSB^Z83 in MSH-9 marks a create-subscription request. MSH-10 assigns the subscription the control id SUB00099, which the server returns in the acknowledgement and which the client will use in a future QSX to cancel the subscription. The QPD identifies the query profile LAB_RESULT_SUBSCRIPTION in QPD-1, tags this query instance Q001 in QPD-2, and in QPD-3 specifies filter criteria: result status F (final) with a date range from 1 June 2026 through 31 December 2026. The RCP sets RCP-1 to I (immediate delivery), caps each pushed response at 100 records in RCP-2, and in RCP-7 instructs the server to include PID, OBR, and OBX segments in each pushed response.
Working with QSB messages
Preserve MSH-10 as the subscription handle
The message control id in MSH-10 is the only durable identifier for the subscription. The server echoes it in the acknowledgement and the client must supply it — in the DSC or the query tag — when issuing a QSX cancellation. Log it at the moment the subscription is created and associate it with whatever internal record the client uses to track the standing query.
Validate the query profile before subscribing
QPD-1 references a query profile that must be pre-negotiated with the server. If the profile name is unknown to the server, the server will reject the QSB with an error acknowledgement. Confirm the profile name, the permitted filter parameters in QPD-3, and the permitted coded values against the server's published query profile documentation before sending the first QSB.
Choose RCP-1 priority deliberately
RCP-1 of I (immediate) requests real-time pushes; D (deferred) permits the server to batch results. Immediate delivery is appropriate for alert-driving subscriptions where latency matters; deferred is appropriate for bulk or reporting subscriptions where batching reduces connection overhead. Servers that do not support the requested priority will either reject the message or silently fall back to their default — confirm the server's behaviour.
Plan for subscription lifecycle management
A subscription that is never cancelled remains open on the server until the server times it out or the implementation agreement expires. Maintain an inventory of active subscriptions, link each one to its MSH-10 control id, and send a QSX^J02 when the subscription is no longer needed. Orphaned subscriptions waste server resources and can cause pushed messages to arrive at receivers that are no longer prepared to process them.
Vendor variance. The query profile referenced in
QPD-1, the permitted filter parameters inQPD-3, the supported values ofRCP-1, and whetherRCP-7segment group inclusions are honoured are all implementation-specific. The base standard defines the message structure; the query profile defines the semantics. Always validate against the target server's interface specification rather than assuming the base standard defaults.
FHIR equivalent
A standing query subscription corresponds to the FHIR Subscription resource, which allows a client to register a filter and a channel (REST hook, websocket, email, or message) through which the server pushes notifications when matching resources are created or updated.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for QSB_Z83 and no ConceptMap for the QPD or RCP segments. A FHIR Subscription derived from a QSB message is therefore mapped conceptually: the query profile in QPD-1 informs the Subscription.criteria expression, the filter parameters in QPD-3 inform Subscription.filterBy, and the delivery priority in RCP-1 informs the channel type and heartbeat settings. The subscription identifier in MSH-10 has no direct FHIR equivalent and must be tracked out of band if the integration needs to correlate a QSB subscription with a FHIR Subscription resource.
Common pitfalls
Pitfall. Discarding
MSH-10after the acknowledgement is received. The control id is the only handle for cancelling the subscription later. Without it, the client cannot send a well-formed QSX, and the server retains an orphaned standing query indefinitely.
Pitfall. Sending a QSB without confirming the query profile name. An unrecognised
QPD-1value produces an error acknowledgement, not a subscription. Negotiate the profile name and permitted filter parameters with the server operator before the first production QSB.
Pitfall. Assuming immediate delivery is supported. Not all servers honour
RCP-1=I; some silently treat all subscriptions as deferred. Test the actual delivery latency in the target environment rather than relying on the requested priority.
How Vorro handles QSB messages
Vorro accepts QSB messages over MLLP or another transport and routes them to the target server, preserving the query profile identity in QPD and the delivery controls in RCP. Vorro logs the MSH-10 control id against the subscribing application and the query profile so that a subsequent QSX can be matched to its originating subscription. When a FHIR-capable server is the target, Vorro translates the QSB to a FHIR Subscription resource — mapping the query profile to Subscription.criteria and the filter parameters to Subscription.filterBy — since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- QSX — the cancel-subscription message that terminates a standing query opened by a QSB.
- QBP — the query-by-parameter message used for one-time queries when a standing subscription is not needed.
- RSP — the segment pattern response that a server typically uses to push results to an active subscription.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for QSB_Z83
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for QPD or RCP
- HL7 Messaging Standard Version 2.5.1 product brief
