HL7 RDR messages carry a pharmacy or treatment dispense history back to a system that asked for it — the records of what was actually dispensed for a patient or an order, returned in answer to a dispense history query. An RDR message is the response half of a query exchange: a querying system sends a pharmacy dispense history query, and the pharmacy or dispensing system returns one RDR with MSA acknowledging the query, QRD echoing it, and one or more dispense records carried in RXD with the prescribing context in RXE. RDR was introduced in HL7 v2.6 and is not part of v2.5.1; teams running v2.5.1 feeds will not encounter this message. This page documents the v2.6 form. This page explains what an RDR message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an RDR response relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an RDR message represents
An RDR message — RDR stands for Pharmacy/Treatment Dispense History Information Response — returns one or more pharmacy dispense records in answer to a dispense history query. The core of the message is the RXD segment, which carries the actual dispense event: what drug was given, how much, when, by whom, against which prescription. Each RXD is wrapped in an order group that opens with ORC and, where the encoded order is included, the prescribing detail in RXE, so the response carries both the dispense facts and the order they fulfilled. The same RXD segment is used in RDS (the unsolicited dispense message), and an RDR is essentially a query-driven roll-up of the dispense events an RDS would have communicated in real time.
RDR was introduced in HL7 v2.6 and is not part of v2.5.1; teams running v2.5.1 feeds will not encounter this message. This page documents the v2.6 form. RDR is a solicited response: the sending system does not issue it on its own initiative but produces it in answer to a pharmacy dispense history query. The MSA segment acknowledges the query and reports whether it succeeded, and the QRD segment (with optional QRF filter) echoes the query that was asked so the receiver can correlate the response to its request. The dispense data itself follows in repeating definition, order, and dispense groups — one RXD per dispense event, with RXR route, RXC components for compound formulations, and OBX observations carried alongside as needed.
When an RDR message is sent
An RDR message is sent in response to a pharmacy dispense history query — when a clinician's workstation, an EHR, a pharmacy benefit system, or another care setting needs the history of what has been dispensed for a patient or an order, queries the pharmacy or dispensing system, and the dispensing system answers with the dispense records. It is request-driven, not event-driven: there is no RDR without an inbound query, and the response is bounded by the query's selection criteria in QRD and QRF. RDR sits alongside RDS (the unsolicited dispense message), RER (encoded order response), and RGR (give history response) in the Chapter 4 pharmacy/treatment message set.
Trigger event
The RDR message type carries a single trigger event:
RDR^RDR– Pharmacy/treatment dispense history response.
Because RDR has one trigger event, the receiver's handling turns on the contents of RXD and the order context in ORC and RXE — what was dispensed, against which order — rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the querying system issuing a pharmacy dispense history query through the integration engine to the dispensing system, which replies with an RDR carrying the matching dispense records.
{{diagram: querying system (EHR / clinician workstation / PBM) → dispense history query → integration engine → pharmacy / dispensing system → RDR response → integration engine → querying system}}
Typical senders: pharmacy information system, outpatient dispensing system, inpatient medication administration system, pharmacy benefit manager.
Typical receivers: EHR, clinician workstation, care-coordination platform, pharmacy benefit system, any system that needs the dispense history.
Direction: the response leg of a query-response exchange — the RDR travels from the dispensing system to the querying system, carrying the dispense records the query asked for.
Segments in an RDR message
The RDR_RDR message opens with MSH, followed by MSA acknowledging the query, optional error and note segments, and then carries one or more DEFINITION groups. Each definition group opens with QRD and contains one or more ORDER groups, each of which contains one or more DISPENSE groups built around RXD. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.
| Segment | Description |
|---|---|
MSH | Message Header. Opens every RDR message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (RDR^RDR), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 and deduplicate on MSH-10. |
MSA | Message Acknowledgment. Acknowledges the inbound dispense history query. MSA-1 carries the acknowledgment code (AA accept, AE application error, AR reject) and MSA-2 echoes the message control id of the query so the querying system can correlate the response. Required. |
[{ERR}] | Error. Reports any application-level errors raised while processing the query — bad selection criteria, unauthorised access, query timeout. Optional and repeating; present when MSA-1 is AE or AR. |
[{NTE}] | Notes and Comments. Free-text notes scoped to the message as a whole. Optional and repeating. |
QRD | Query Definition. Opens each definition group and echoes the query that was asked — query date/time, query format and priority, the query id, the number of records requested, and the subject. Required and repeating; the responder echoes QRD so the receiver can correlate the response to the request. |
[QRF] | Query Filter. Echoes the filter criteria that narrowed the query — date range, dispense window, prescription number, drug code. Optional, present when the query carried a QRF. |
[PID] | Patient Identification. Identifies the patient whose dispense history is being returned. Optional in the message structure but present in practice for any patient-scoped query. |
[{NTE}] | Notes and Comments. Free-text notes scoped to the patient or the definition group. Optional and repeating. |
ORC | Common Order. Opens each order group and carries the order control code, the placer and filler order numbers, the order status, and the ordering provider. Required and repeating; one ORC per order whose dispense history is being returned. |
[{TQ1, [{TQ2}]}] | Timing/Quantity. Carries the timing of the order — start, stop, frequency, duration — and any timing relationships in TQ2. Optional and repeating. |
[RXE, {RXR}, [{RXC}]] | Encoded Order. Carries the pharmacy-encoded order that the dispenses fulfil — RXE for the encoded medication, dose, and instructions, one or more RXR for route, and optional RXC components for compound formulations. Optional as a group; included when the response carries the encoded order alongside the dispense records. |
RXD | Pharmacy/Treatment Dispense. Opens each dispense group and is the core segment of the response — the dispense event itself. RXD-2 carries the dispense/give code, RXD-3 the date/time dispensed, RXD-4 the actual dispense amount, RXD-5 the actual dispense units, RXD-7 the prescription number, RXD-8 the number of refills remaining, RXD-10 the dispensing provider, and RXD-11 the substitution status. Required and repeating; the same RXD segment is used in RDS. |
{RXR} | Pharmacy/Treatment Route. Carries the route, site, and administration device for the dispensed medication. Required and repeating; at least one RXR per RXD. |
[{RXC}] | Pharmacy/Treatment Component Order. Carries the components of a compound or admixture dispense — one RXC per ingredient. Optional and repeating. |
[{OBX, [{NTE}]}] | Observation/Result. Carries observations associated with the dispense — counselling provided, allergy check performed, clinical assessment at dispense — with notes attached. Optional and repeating. |
[DSC] | Continuation Pointer. Carries a continuation pointer when the response is fragmented across multiple messages. Optional. |
[ ] = optional, { } = repeating
The dispense group from RXD onward repeats inside each order group, the order group repeats inside each definition group, and the definition group itself repeats — so a single RDR can return many dispenses, across many orders, in answer to a broad query. The canonical segment pages carry the full field-by-field detail.
Sample RDR message
Note. Constructed for illustration. Patient identifiers, prescription numbers, drug codes, and dates are fictional.
MSH|^~&|PHARMACY|MERCYGEN|EHR|MERCYGEN|202006150930||RDR^RDR^RDR_RDR|MSG00099|P|2.6
MSA|AA|QRY00045
QRD|202006150930|R|I|Q00045|||10^RD|MR12345^^^MERCYGEN^MR|RX
PID|1||MR12345^^^MERCYGEN^MR||DOE^JANE^M||19720314|F
ORC|RE|PLC987654^EHR|FIL123456^PHARMACY||CM
RXE|^^^202006010800^^R|00093-0150-01^Lisinopril 10 mg tab^NDC|10|10|MG|TAB^Tablet^HL70162|||||30|||||PRESC456^SMITH^JOHN^A^^^DR
RXD|1|00093-0150-01^Lisinopril 10 mg tab^NDC|202006010815|30|TAB^Tablet^HL70162|||RX78901234|2|||PROV789^CHEN^LI^^^^RPH|||N
RXR|PO^Oral^HL70162
RXD|2|00093-0150-01^Lisinopril 10 mg tab^NDC|202006150915|30|TAB^Tablet^HL70162|||RX78901234|1|||PROV789^CHEN^LI^^^^RPH|||N
RXR|PO^Oral^HL70162
What this sample shows
The RDR^RDR in MSH-9 marks a pharmacy/treatment dispense history response. MSA carries AA against query control id QRY00045, accepting the query. QRD echoes the query — query id Q00045, up to 10 dispense records (10^RD), patient MR12345, scope RX. PID identifies the patient. ORC opens the order group with order control RE against filler order FIL123456, and RXE carries the encoded order for lisinopril 10 mg tablets, 30 dispensed, prescriber SMITH. Two RXD segments then return two dispense events against prescription RX78901234: the first on 202006010815 with 2 refills remaining, the second on 202006150915 with 1 refill remaining, both dispensed by CHEN with substitution status N (no substitution). Each RXD is followed by RXR PO (oral).
Working with RDR messages
Correlate every RDR to its query
The MSA segment carries the message control id of the inbound query in MSA-2, and QRD echoes the query id in QRD-4. Use both to correlate the response to the request — the querying system should not consume an RDR whose MSA-2 or QRD-4 does not match an outstanding query, since the response may belong to a different session or have been received out of order.
Key dispense events on the prescription number, not the order id
RXD-7 carries the prescription number — the identifier the pharmacy uses to track the dispense lineage. Multiple dispense events against the same prescription (an initial fill and subsequent refills) share the same RXD-7, with RXD-8 decrementing as refills are consumed. Key the dispense history on RXD-7 rather than on the filler order number in ORC-3, which may be reused or absent on retail fills.
Read substitution status in RXD-11
RXD-11 reports whether a therapeutic substitution was made — N no substitution, G generic substitution, T therapeutic substitution. A receiving system that reconciles dispenses to the prescribed order must read RXD-11 to know whether the dispensed product matches the encoded order in RXE or has been substituted at the pharmacy.
Handle DSC continuation for long histories
A broad query that matches many dispenses may exceed the message size the responder is willing to send in one transmission. The DSC segment carries a continuation pointer that the querying system uses to request the next fragment. Honour DSC rather than assuming a single RDR is the complete history.
Vendor variance. The exact contents of the encoded order group (
RXE,RXR,RXC) returned alongside the dispense records vary by responder — some pharmacies always include the encoded order, others return only the dispense segments and rely on the querying system to resolve the order from its own records. The substitution codes inRXD-11and the prescription number format inRXD-7are also partly site-defined. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A pharmacy dispense history response corresponds, conceptually, to a FHIR Bundle of MedicationDispense resources — one MedicationDispense per RXD returned — with a MessageHeader at the head of the Bundle when carried as a messaging exchange, and a Patient reference resolved from PID.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for RDR_RDR. A FHIR representation produced from an RDR is therefore composed manually: each RXD becomes a MedicationDispense with whenHandedOver from RXD-3, quantity from RXD-4/RXD-5, identifier from the prescription number in RXD-7, performer from RXD-10, and substitution from RXD-11; the encoded order in RXE anchors the authorizingPrescription reference. In most production integrations the RDR stays on the v2 channel.
Common pitfalls
Pitfall. Consuming an RDR without checking
MSAandQRD. The response carries the query id it answers; treating an RDR as authoritative without correlating it to the outstanding query can attach a dispense history to the wrong session, or accept a partial response as complete.
Pitfall. Building the dispense history on the filler order number rather than the prescription number in
RXD-7. Refills share a prescription number but may be tracked under different filler orders, and retail fills may carry no filler order at all — keying onORC-3fragments the lineage.
Pitfall. Ignoring
RXD-11substitution status. A dispense whose product differs from the encoded order inRXEbecause of a generic or therapeutic substitution is still a valid fulfilment; treating it as a mismatch and rejecting the record loses real dispense history.
Pitfall. Treating a single RDR as the full history when
DSCis present. A continuation pointer means there are more dispenses to come; consuming only the first fragment under-reports the history.
How Vorro handles RDR messages
Vorro routes each RDR from the responding pharmacy to the querying system, correlates the response to the outstanding query on MSA-2 and the query id in QRD, keys the dispense lineage on the prescription number in RXD-7 rather than the filler order, preserves the substitution status in RXD-11, follows DSC continuation pointers to assemble the complete history, and, where a FHIR destination is configured, maps each RXD to a MedicationDispense in a Bundle referencing the Patient resolved from PID — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message. Because RDR was introduced in HL7 v2.6, Vorro applies this handling only to v2.6 (and later) feeds; v2.5.1 partners exchange dispense data through RDS instead.
Related messages
- RDS — the unsolicited pharmacy/treatment dispense message that carries a dispense event in real time and uses the same
RXDsegment that RDR returns in bulk. - RER — the pharmacy/treatment encoded order information response that returns the encoded order history rather than the dispense history.
- RGR — the pharmacy/treatment dose information response that returns the give (administration) history rather than the dispense history.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for RDR_RDR
- HL7 v2-to-FHIR IG — segment maps index — confirms no published ConceptMap for the RXD segment
- HL7 Messaging Standard Version 2.6 product brief
