HL7 RTB_K13 Tabular Response
RTB_K13 is the tabular response side of QBP_Q13. The receiver acknowledges the query, reports query status, echoes the query definition, and then returns a row definition plus zero or more row data segments.
In practice, RTB_K13 behaves like a small table delivered inside HL7 v2. That makes it convenient, but it also means column order, datatype, null handling, and continuation rules become part of the interface contract.
A small RTB K13 example
What systems do with it
The requester reads MSA for message acknowledgment, QAK for query status, and QPD to confirm which query was answered. Then it uses RDF to understand the columns and RDT to read the row values.
If the response is large, DSC can carry continuation. The requester should either request the next increment or send a QCN_J01 cancellation if it does not want more rows.
How to read the structure
The top of the message looks ACK-like: MSH, MSA, optional ERR, QAK, and QPD. The optional row definition group contains required RDF and repeating RDT rows. If there are no hits, the receiver may return no row group and report the status in QAK.
RDF is not just documentation. It is the map for the RDT values. If your integration uses positional mapping, treat RDF as required even when a local profile says the requester already knows the columns.
Implementation traps
Do not ignore QAK because MSA says AA. A receiver can accept the query message and still report no rows, too many matches, or an application-level problem.
Also resist the temptation to overload one column with formatted text. If the response is supposed to be tabular, keep each column stable and typed enough that downstream systems can trust it.
Reference notes
The HL7 v2+ refactored RTB_K13 page shows the response with MSA, ERR, QAK, QPD, an optional row definition group containing RDF and RDT, and optional DSC. HL7 Chapter 5 describes RDF as the table row definition and RDT as row data.