HL7 RDS Messages: Pharmacy/Treatment Dispense

HL7 RDS messages report a pharmacy or treatment dispense — the record that a medication was actually supplied, in what quantity, by whom, and against which prescription. An RDS message confirms the dispensing of a treatment that was ordered, typically through an RDE pharmacy encoded order, and is sent from the pharmacy or treatment supplier to the systems that record and act on the dispense. This page explains what an RDS message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an RDS dispense relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an RDS message represents

An RDS message — RDS stands for Pharmacy/Treatment Dispense — communicates that a pharmacy or treatment supplier has dispensed a medication. The core of the message is the RXD segment, which carries the dispense data for a single issuance of medication: it may describe a single dose, a half-day dose, a daily dose, or a refill of a prescription. The RXD is deliberately not a complete record of the order — it records what was handed out on this occasion, not the full prescription.

The sender is the pharmacy information system, and the receivers are the systems that need to know a dose was supplied — most often a nursing or clinical application, the medication record, billing, and inventory. RDS sits one step downstream of the order: an RDE encoded order tells the pharmacy what to prepare, and the RDS message reports what was dispensed against it. Because the dispense is the event that affects inventory and generates a charge, the RXD — not the original order — is the authoritative record of what actually left the pharmacy.

When an RDS message is sent

An RDS message is sent when a dispense is completed. A single prescription can produce a series of RDS messages over time — an initial fill followed by each refill — and each one carries the number of refills remaining in RXD, so the sequence of dispenses can be reconstructed from the messages themselves.

Trigger event

The RDS message type carries a single trigger event:

RDS^O13 – Pharmacy/treatment dispense message.

Because RDS has one trigger event, the receiver's handling turns on the contents of RXD — the dispensed amount, the prescription number, the refills remaining, and the substitution status — rather than on the trigger code in MSH-9.

Integration topology

The diagram shows the pharmacy system emitting a dispense event through the integration engine to the systems that record and act on it.

{{diagram: pharmacy system → RDS message → integration engine → nursing/clinical app / medication record / billing / inventory}}

Typical senders: pharmacy information system, automated dispensing cabinet, outpatient or retail pharmacy platform.

Typical receivers: nursing or clinical application, EHR medication record, billing / charge capture, and inventory management.

Direction: unidirectional notification from the dispensing source to the systems that record, bill, and reconcile the dispense.

Segments in an RDS message

The RDS_O13 message is organised into groups: an optional PATIENT group (PID through PV2) and one or more ORDER groups, each opening with ORC and ending with the dispense. Within an order, the ORDER_DETAIL (RXO) and ENCODING (RXE) groups are optional, but the RXD dispense segment and at least one RXR route are required. 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 RDS message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in `MSH-9` (`RDS^O13`), carries the message control id in `MSH-10`, and pins the HL7 version. Receivers route on `MSH-9` and deduplicate on `MSH-10`.
`[{SFT}]`	Software Segment. Identifies the software product behind the sender — vendor, product, and version. Useful when dispense behaviour differs across pharmacy-system releases.
`[{NTE}]`	Notes and Comments. Message-level notes that apply to the dispense as a whole. Optional and repeating.
`[PID]`	Patient Identification. Identifies the patient the medication was dispensed for — the identifier list in `PID-3`, the name in `PID-5`. Required when the PATIENT group is present; the group as a whole is optional, so outpatient or mail-order dispenses can omit it.
`[PD1]`	Patient Additional Demographic. Supplements `PID` with data such as the patient's primary-care facility.
`[{AL1}]`	Allergy Information. Patient allergies carried with the dispense. Optional and repeating.
`[PV1]`	Patient Visit. The encounter the dispense belongs to — patient class, assigned location, and the providers on the visit. Optional.
`[PV2]`	Patient Visit Additional. Companion to `PV1` with admit reason and expected dates when a visit is present.
`ORC`	Common Order. Opens each order group and ties the dispense to its order. For a dispense the `ORC` carries the order control code `RE` and the filler order number, which links the dispense back to the originating RDE order. Required, and the order group repeats once per dispensed item.
`[{TQ1}]`	Timing/Quantity. The dosing schedule and timing for the order. Optional and repeating; introduced as the replacement for the deprecated quantity/timing field in v2.5.
`[TQ2]`	Timing/Quantity Relationship. Relates this order's timing to another order, when sequenced or conditional dosing applies.
`[RXO]`	Pharmacy/Treatment Order. The original order as the prescriber expressed it, carried for reference. Optional; when present it has its own route and component segments.
`[RXE]`	Pharmacy/Treatment Encoded Order. The pharmacy-encoded prescription the dispense is filling, with its own encoded timing, route, and components. Optional — present only when the receiving application needs its data; the dispense itself stands on `RXD`.
`RXD`	Pharmacy/Treatment Dispense. The core of the message and the only required clinical segment in the order. It records the dispense as it happened: the dispense/give code in `RXD-2`, the date and time dispensed in `RXD-3`, the actual dispense amount and units in `RXD-4` and `RXD-5`, the prescription number in `RXD-7`, the number of refills remaining in `RXD-8`, the dispensing provider in `RXD-10`, and the substitution status in `RXD-11`.
`[{NTE}]`	Notes and Comments. Notes relative to the dispense event, following the `RXD`. Optional and repeating.
`{RXR}`	Pharmacy/Treatment Route. The route of administration (oral, IV, IM) and site for the dispensed medication. Required and repeating — a medication with more than one route carries one `RXR` per route.
`[{RXC}]`	Pharmacy/Treatment Component. The components of a compound or IV — each base and additive with its amount. Optional and repeating.
`[{OBX}]`	Observation/Result. Dispense-time observations such as a lot number or a counselling flag. Optional and repeating.
`[{FT1}]`	Financial Transaction. The charge generated by the dispense — transaction code, amount, and quantity — sent on to billing. Optional and repeating, to accommodate multiple charge, benefit, and pricing situations.

[ ] = optional, { } = repeating

The order group from ORC through FT1 repeats once per dispensed item, so a single RDS message can report several medications dispensed together. The canonical segment pages carry the full field-by-field detail.

Sample RDS message

Note. Constructed for illustration. Patient identifiers, prescription numbers, dates, and names are fictional.

MSH|^~&|PHARM|MERCYGEN|EHR|MERCYGEN|202006150900||RDS^O13^RDS_O13|MSG00012|P|2.5.1
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
ORC|RE|ORD789^EHR|RX456789^PHARM
RXE|1^BID^^202006150900|00071015523^Lisinopril 10 MG Oral Tablet^NDC|10||MG|TAB
RXD|1|00071015523^Lisinopril 10 MG Oral Tablet^NDC|202006150900|30|TAB||RX456789|4||PHARM01^DOE^ANN^^^^RPH|N
RXR|PO^Oral^HL70162

What this sample shows

The RDS^O13 in MSH-9 marks a pharmacy dispense. PID carries the medical record number MR12345, and ORC carries the order control code RE with filler order number RX456789, linking the dispense to its order. The RXE echoes the encoded order it is dispensing against (Lisinopril 10 MG). The RXD reports the actual fill: 30 tablets dispensed (RXD-4, RXD-5) against prescription RX456789 (RXD-7), with 4 refills remaining (RXD-8), by dispensing provider PHARM01 (RXD-10), and no substitution — N in RXD-11. The RXR gives the oral route.

Working with RDS messages

Read the dispense from RXD, not the order

The dispensed quantity and date live in RXD, not in the order. RXD records what was actually handed out on this occasion and is not a complete record of the prescription, so a partial fill shows up as an RXD-4 smaller than the ordered quantity. Reconcile against RXD rather than assuming the dispense matched the order.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key, and treat the prescription number in RXD-7 together with the dispense date and time in RXD-3 as the natural business key for a dispense. Pharmacy feeds are replayed after outages, and treating a repeated control id as a duplicate prevents a replayed dispense from posting a second charge or decrementing inventory twice.

Refills and the dispense sequence

RXD-8 carries the number of refills remaining after this dispense, so a series of RDS messages for one prescription should show a decreasing count. Sequence by the dispense date and time in RXD-3 rather than arrival order, so an out-of-order refill does not appear to reverse the count.

Substitution status

RXD-11 records whether a substitution was made for the ordered product. Surface this on the medication record rather than discarding it — a dispense that substituted a product differs, clinically and for billing, from one that filled the order exactly.

Vendor variance. The encoded order in RXE is optional and is included only when the receiving application needs its data, so some pharmacy systems repeat the full order on every RDS while others send only the dispense in RXD. Confirm a partner's field usage against their interface specification rather than assuming the base standard.

FHIR equivalent

A pharmacy dispense corresponds to the FHIR MedicationDispense resource, with the patient as a Patient resource and, for a messaging exchange, a MessageHeader at the head of a Bundle.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for RDS_O13 and no ConceptMap for the RXD dispense segment — among the pharmacy/treatment segments, only RXA, RXO, and RXR have published ConceptMaps, and RXO maps to MedicationRequest (the order), not to the dispense. A FHIR MedicationDispense produced from an RDS message is therefore mapped manually, taking the dispensed medication, quantity, date, and substitution status from RXD and referencing the authorising MedicationRequest derived from the order.

Common pitfalls

Pitfall. Billing or recording from the ordered quantity instead of the dispensed quantity. The charge and the inventory change follow RXD-4, the actual dispense amount, not the quantity in the order; reading the order overcounts a partial fill.

Pitfall. Treating every RDS as a first fill. Ignoring RXD-8, the refills remaining, double-counts a prescription's supply across its refills.

Pitfall. Assuming a fixed date-time precision. Some senders stamp RXD-3 as YYYYMMDD and others as a full timestamp with an offset; do not assume a timezone — normalize on ingest.

How Vorro handles RDS messages

Vorro ingests the RDS feed over MLLP or another transport, deduplicates on MSH-10, and routes each dispense to every subscribed destination in the format that system expects — the medication record, billing, and inventory. Vorro reads the dispensed quantity, refills, and substitution status from RXD, links each dispense back to its order through the filler order number in ORC, and, where a FHIR destination is configured, maps the dispense to a MedicationDispense resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.

RDE — the pharmacy encoded order that an RDS message dispenses against.
RGV — the give message that records medication-administration intent.
RAS — the administration message that records the dose actually given to the patient.

Sources

HL7 v2-to-FHIR IG — message maps index — confirms no message map for RDS_O13
HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for RXD
HL7 Messaging Standard Version 2.5.1 product brief
HL7 v2 RDS_O13 message structure (hl7.eu standard mirror)
HL7 v2 RXD segment definition (hl7.eu standard mirror)

← Back to HL7 v2 Guide