HL7 QBP_Q13 Tabular Query

A QBP query that expects rows and columns back in RTB_K13.
HL7 message structure QBP_Q13 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

SegmentNameRequiredRepeatable
MSH
 Message Header Yes No
SFT
 Software Segment No Yes
QPD
 Query Parameter Definition Yes No
RDF
 Table Row Definition No No
RCP
 Response Control Parameter Yes No
DSC
 Continuation Pointer No No

QBP_Q13 is a query-by-parameter message for a tabular response. The requester sends a structured question in QPD, controls the response with RCP, and usually expects an RTB_K13 response with RDF and RDT rows.

This is useful when the response is more table than event: candidate lists, simple result history, reference data, or other screens where the receiver can describe columns and return zero or more rows.

A small QBP Q13 example

MSH|^~\&|PORTAL|CITYHOSP|RESULTS|CITYHOSP|20260717110000||QBP^Q13^QBP_Q13|QBP130001|P|2.5.1 QPD|Q13^Recent result table^HL7nnn|Q130001|123456^^^CITYHOSP^MR|20260701000000|20260717235959 RDF|4|PatientID^CX^20~Observation^CWE^80~Value^ST^40~ResultTime^DTM^24 RCP|I|20^RD

What workflow it represents

The requester wants a rowset, not a narrative display and not a full clinical event. The receiver evaluates the QPD parameters, applies quantity and timing controls from RCP, and returns a tabular response. Integration engines often map RTB rows into a local cache or transform them into an API response for an upstream application.

The optional RDF in the query can describe requested output columns, depending on the query profile. That only works when both systems agree what columns are allowed, what datatypes they carry, and whether the receiver is allowed to omit or add columns.

How to read the structure

MSH identifies the query. QPD names the query, carries the query tag, and holds profile-defined parameters. Optional RDF describes table output expectations. RCP tells the receiver whether the requester wants an immediate response and how many rows it wants. DSC asks for continuation when a previous response gave a continuation pointer.

The query tag is the handshake. The response echoes it in QAK and QPD, so the requester can match the rowset to the request.

Implementation traps

Tabular responses are only safe when column definitions are governed. If the receiver changes RDF order and the requester maps RDT by position, every row can still parse while every value lands in the wrong place.

Also agree how nulls, repetitions, coded values, and date/time precision are represented. RDT can carry varied datatypes, but your local mapper still needs precise rules.

Reference notes

The HL7 v2+ refactored QBP_Q13 page shows QPD, optional RDF, required RCP, and optional DSC, and pairs the query with tabular response structures such as RTB_K13. HL7 Chapter 5 also describes the RDF/RDT table pattern.