Query and Response Paradigms (QBP/RSP)

Two ways to move data

Most of the HL7 v2 traffic seen so far follows an unsolicited push model: a real-world event happens, and the system where it happened sends a message without anyone asking. A patient is admitted, so an ADT goes out; a result is finalized, so an ORU is sent. The sender decides when communication occurs, and receivers acknowledge what arrives. This is efficient for keeping subscribers continuously up to date, but it only works when the data you need has already been pushed to you, in a feed you happen to be receiving.

The pull, or query, paradigm inverts the initiative. Instead of waiting for a relevant event, a system asks for specific data on demand and gets an answer back in the same exchange. A registration desk that needs the current demographics for a patient, or an application checking the status of an order, does not wait for the next push — it issues a query and reads the response. The trade-off is that the requester now owns a request/response conversation rather than a fire-and-forget transmission ¹.

QBP and RSP

The modern HL7 v2 query is Query By Parameter (QBP), answered by a Segment Pattern Response (RSP) ². A common pairing is QBP^Q11, which requests data, and RSP^K11, which returns it. The trigger codes identify a specific, pre-agreed query: both sides must already know what Q11 asks for and what shape its answer takes. QBP/RSP is the general framework that largely superseded the older query pairs QRY/ADR and QRY/DSR, which used more rigid, display- or record-oriented response formats. You will still encounter QRY-based queries in older interfaces, but new work is normally built on QBP/RSP.

Two segments carry the heart of a query:

• QPD — Query Parameter Definition. This states the message query name (which named query is being run) and the parameter values that scope it — for example, the patient identifier to look up. QPD is how the requester says both “run this query” and “with these inputs.”
• RCP — Response Control Parameter. This controls how the answer should be returned: the response priority (immediate or deferred) and limits such as the maximum number of rows to return. RCP is where paging and result-size expectations are expressed.

The RSP that comes back contains the requested data segments — for a demographic query, a PID, possibly accompanied by related segments — plus a QAK (Query Acknowledgment) segment. QAK reports the outcome of the query itself, distinct from the lower-level acknowledgment that the message was received: a status such as OK (data found), NF (no data found), or AE (application error). A receiver can therefore distinguish “the patient exists, here is the record” from “the query ran but matched nothing” from “the query failed.”

A QBP^Q11 / RSP^K11 skeleton

QBP^Q11 (request)
MSH|^~\&|REGAPP|HOSP|MPI|HOSP|20260601090000||QBP^Q11^QBP_Q11|MSG001|P|2.5.1
QPD|Q11^Get Demographics|QRY001|12345^^^HOSP^MR
RCP|I|1^RD

RSP^K11 (response)
MSH|^~\&|MPI|HOSP|REGAPP|HOSP|20260601090001||RSP^K11^RSP_K11|MSG002|P|2.5.1
MSA|AA|MSG001
QAK|QRY001|OK|Q11^Get Demographics
QPD|Q11^Get Demographics|QRY001|12345^^^HOSP^MR
PID|1||12345^^^HOSP^MR||DOE^JANE||19800101|F

Reading the request: QPD names the query (Q11), gives it a query tag (QRY001) so the answer can be matched to it, and supplies the parameter — a medical record number to look up. RCP|I|1^RD asks for an immediate response of at most one record. In the response, MSA acknowledges the request message, then QAK reports the query result as OK, echoing the same query tag. The PID carries the demographics that were requested. Had the identifier matched nothing, the QAK status would be NF and no PID would follow.

What queries cost you

A query interface is more capable than a feed, but it is also more demanding to build and operate. Because every request expects a matching answer, both ends must agree on the named queries and their parameters in advance, and the requester must handle conditions a push never raises: timeouts when no response arrives, retries, and paging through large result sets using the controls in RCP. Pushed feeds are fire-and-forget for the sender; queries are a conversation, and conversations can stall. Choosing between them is a design decision: subscribe to a push when you need a continuous stream of events, and issue a query when you need a specific answer at a specific moment ¹.