HL7 QBP_Q11 (Query by Parameter) | Integration Soup HL7 Reference Guide

HL7 QBP_Q11 Query by Parameter

A focused question with the search criteria carried in QPD.

HL7 message structure QBP_Q11 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

Segment	Name	Required	Repeatable
MSH	Message Header	Yes	No
SFT	Software Segment	No	Yes
QPD	Query Parameter Definition	Yes	No
RCP	Response Control Parameter	Yes	No
DSC	Continuation Pointer	No	No

QBP_Q11 is one of the practical query-by-parameter messages in HL7 v2. Instead of sending an event like an admit, result, or order, the sender is asking another system a structured question and expecting a matching response. You see this pattern around lookups, master data checks, and small service-style interfaces where the receiver owns the data and the sender needs the current answer.

The message is intentionally compact. MSH identifies the query, QPD carries the query name, tag, and parameters, RCP tells the receiver how many rows or what timing the sender wants, and DSC appears when continuation is needed.

A small QBP Q11 example

MSH|^~\&|PORTAL|CITYHOSP|MPI|CITYHOSP|20260717100000||QBP^Q11^QBP_Q11|QBP110001|P|2.5.1 QPD|Q11^Patient lookup by MRN^HL7nnn|Q110001|123456^^^CITYHOSP^MR RCP|I|10^RD

What workflow it represents

The sender is usually an application, portal, integration engine, or ancillary system that needs a specific answer before it can continue. The receiver is the system of record for the requested data. In a patient or reference-data lookup, the receiver may answer with an RSP_K11 segment-pattern response that contains row-style data in RDF and RDT.

The query tag in QPD is the piece that keeps the conversation sane. The response echoes it in QAK and QPD, so the requester can match the answer to the original question even when several queries are in flight.

How to read the structure

QPD is the heart of the message. QPD-1 names the query, QPD-2 carries the query tag, and the remaining fields are the actual search parameters defined by the profile. RCP controls whether the sender wants an immediate response and can limit the quantity of rows returned.

DSC is not common in tiny examples, but production queries can need continuation if the result set is too large. If your sender supports continuation, document whether it reuses the same query tag, how long the continuation pointer is valid, and what should happen when the receiver expires it.

Implementation traps

The main trap is treating QPD as free text. It is not. The receiving system expects parameters in the exact order and datatype defined by the query profile. A local "patient lookup" Q11 is only interoperable when both sides agree what each QPD parameter means.

Another trap is ignoring negative or partial answers. A syntactically valid response may say no records found, too many candidates, or the query was rejected. Handle those statuses explicitly instead of assuming every ACK-like success means a useful row came back.

Reference notes

The HL7 refactored message pages describe QBP_Q11 as a query structure with MSH, QPD, RCP, and optional DSC, and describe RSP_K11 as the segment-pattern response. See the HL7 Europe pages for QBP_Q11 and RSP_K11.