The RDT (Table Row Data) segment delivers a single row in a tabular query response. Each RDT carries the values for one row, projected across the columns that the preceding RDF segment defined.
Purpose
RDT is the row-payload counterpart to RDF. The HAPI v2.5.1 javadoc defines exactly one field on the segment — RDT-1 Column Value, of variable data type — but the field can be repeated within the row by separating column values with the standard repetition delimiter, so a single RDT segment may carry many column values. Each value's data type is determined positionally by the matching RDF-2 column description.
The pair RDF + RDT is functionally analogous to a column-header row plus one body row in a CSV table.
Used in
RDT appears in tabular query response messages, primarily:
- DSR — Display Response, where each RDT row is intended for human-readable rendering.
- RTB — Tabular Response, where each RDT row is intended for machine processing.
Both flow inside the general query framework documented on QRY messages. RDT segments always follow an RDF segment that declares the column layout.
Field-by-field reference
Source: HAPI HL7v2 v2.5.1 javadocs (https://hapifhir.github.io/hapi-hl7v2/v251/apidocs/ca/uhn/hl7v2/model/v251/segment/RDT.html) for sequence, name, data type, and repetition. Length is not published in the javadocs (—); Required and Table # are filled from the HL7 v2.5.1 standard where well-established.
| Seq | Name | Data Type | Length | Req | Repeat | Table # | Description |
|---|---|---|---|---|---|---|---|
| RDT-1 | Column Value | varies | — | R | — | — | Row's column values, typed per RDF-2 layout. |
Most-used fields
- RDT-1 Column Value is the only field on the segment. Each column declared in RDF-2 contributes one value, and the values are concatenated with the repetition delimiter (
~) so the row remains one segment. The HAPI accessor exposes the field as aVariesinstance whose internal data type is set from the corresponding RDF-2 column descriptor at parse time.
Version differences (2.3 to 2.8.2)
- 2.3 introduced RDT alongside RDF for tabular and display query responses.
- 2.3.1, 2.4, 2.5, and 2.5.1 keep the single-field structure verified in the HAPI v2.5.1 javadoc.
- 2.6, 2.7, 2.7.1, 2.8, and 2.8.2 retain RDT unchanged. As with RDF, HL7 has steered new implementations toward the QBP/RSP query framework, but RDT remains the row segment for legacy DSR/RTB exchanges.
Common mistakes
- Sending RDT without a preceding RDF in the same message. Receivers have no way to interpret column types.
- Mismatching the number of column values in RDT against RDF-1. Even a single missing trailing column will cause downstream column-shift bugs that are hard to diagnose.
- Embedding raw delimiters in column values without proper HL7 escaping (
F,R,S,T,E). The repetition delimiter is particularly easy to corrupt because it is the inter-column separator. - Producing one RDT per column rather than one RDT per row.
Examples
Minimal RDT carrying two columns under a 2-column RDF:
RDT|P10045^^^MAIN^MR~Doe^Jane^A
Fully-populated RDT carrying four columns under a 4-column RDF:
RDT|P10045^^^MAIN^MR~Doe^Jane^A~202606091200~MED
Annotated breakdown:
RDT Segment ID
|P10045^^^MAIN^MR RDT-1(1) Column 1 value (typed ST per RDF-2(1))
~Doe^Jane^A RDT-1(2) Column 2 value (typed XPN per RDF-2(2))
~202606091200 RDT-1(3) Column 3 value (typed TS per RDF-2(3))
~MED RDT-1(4) Column 4 value (typed IS per RDF-2(4))
In-context excerpt — DSR tabular query response listing two patients:
MSH|^~&|LIS|MAIN|EHR|MAIN|20260610091500||DSR^Q03^DSR_Q03|MSG000343|P|2.5.1
MSA|AA|QRY000343
QAK|QRY000343|OK
RDF|3|PatientID^ST^20~PatientName^XPN^48~AdmitDate^TS^14
RDT|P10045^^^MAIN^MR~Doe^Jane^A~202606091200
RDT|P10046^^^MAIN^MR~Roe^Sam^B~202606091355
In-context excerpt — RTB tabular response returning charge rows:
MSH|^~&|BILLING|MAIN|EHR|MAIN|20260610100200||RTB^Q13^RTB_Q13|MSG000344|P|2.5.1
MSA|AA|QRY000344
QAK|QRY000344|OK
RDF|2|ChargeCode^CE^20~Amount^MO^12
RDT|99213^Office Visit^CPT~125.00^USD
RDT|85025^CBC^CPT~24.50^USD
FHIR mapping
No segment-level ConceptMap is published in the v2-to-FHIR IG for RDT. Tabular query and update-subscription infrastructure has no direct FHIR resource equivalent; FHIR uses RESTful search responses (a Bundle of typed resources) instead of a generic row container. When migrating, map each RDT row to one entry in a search Bundle, with the columns reconstructed as resource elements.
Engine considerations
- Engines that parse RDT eagerly need the upstream RDF in scope, or RDT-1 will be exposed only as a raw
Variesblob and column-level transforms become awkward. - Validate row arity against RDF-1 on the way in; otherwise downstream maps that index by column position will silently shift.
- When passing RDT through unchanged, preserve the repetition delimiter exactly. Some engines normalize delimiters in unrelated segments and corrupt RDT in the process.
- Logging RDT rows in their raw form is usually safer than logging the parsed projection, since the original primary form is the only place where escaping is guaranteed correct.
How Vorro parses and produces RDT
Vorro parses RDT by binding RDT-1 to the column descriptors captured from the preceding RDF, splitting on the repetition delimiter and applying the per-column data type so each value lands in the right schema slot. Producing RDT is the inverse: Vorro projects each tabular row from its internal record store into the column order declared by the producer's RDF, escapes the values with the standard HL7 escape sequences, and emits one RDT per row.
