HL7 RDE Messages: Pharmacy/Treatment Encoded Order

HL7 RDE messages carry a pharmacy or treatment order after the pharmacy has encoded it — the prescription expressed in the exact, dispensable terms the pharmacy will act on, rather than the free-form terms the prescriber first wrote. An RDE message is the encoded order that a dispense (RDS) and a give (RGV) are subsequently reported against, and it is sent from the pharmacy system to the systems that need to know what was ordered. This page explains what an RDE message represents, the trigger events it carries, every segment the message can contain and what each one holds, and how an encoded order relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an RDE message represents

An RDE message — RDE stands for Pharmacy/Treatment Encoded Order — communicates a prescription that the pharmacy has translated into an encoded, actionable form. The core of the message is the RXE segment, which carries the pharmacy-encoded order: the give code and amount, the dispense amount, the dosing timing, the ordering provider, and the pharmacy-assigned prescription number. Where an RXO records the order as the prescriber expressed it, the RXE records the same order as the pharmacy will fill it — a fully specified, unambiguous instruction.

The sender is the pharmacy information system, and the receivers are the systems that act on or record the order — a nursing or clinical application, an automated dispensing cabinet, the medication record, and inventory. RDE sits at the head of the pharmacy workflow: the encoded order in RXE establishes what is to be given, and later a RDS dispense and a RGV give are reported against it. Because the RXE is the pharmacy's authoritative statement of the order, downstream systems reconcile dispenses and administrations against it rather than against the prescriber's original request.

When an RDE message is sent

An RDE message is sent when the pharmacy creates or changes an encoded order — a new prescription, a refill authorisation, a hold, or a discontinuation. Each change to the order is a distinct RDE event carrying the order control code in ORC-1 that says what happened, so the sequence of an order's life can be reconstructed from the RDE messages that touch it.

Trigger events

The RDE message type carries two trigger events, both verified in HL7 v2.5.1:

RDE^O11 – Pharmacy/treatment encoded order.
RDE^O25 – Pharmacy/treatment refill authorization request.

Both events use the same segment structure; the event in MSH-9 distinguishes an ordinary encoded order from a refill-authorization request, and the order control code in ORC-1 (for example NW new, RF refill, DC discontinue, HD hold) carries the finer action.

Integration topology

The diagram shows the pharmacy system emitting an encoded order through the integration engine to the systems that act on and record it.

{{diagram: pharmacy system → RDE encoded order → integration engine → nursing/clinical app / dispensing cabinet / medication record / inventory}}

Typical senders: pharmacy information system, computerized provider order entry after pharmacy verification, outpatient or retail pharmacy platform.

Typical receivers: nursing or clinical application, automated dispensing cabinet, EHR medication record, and inventory management.

Direction: unidirectional notification from the pharmacy to the systems that will dispense, administer, and record against the encoded order.

Segments in an RDE message

The RDE_O11 message is organised into groups: an optional PATIENT group (PID through AL1) and one or more required ORDER groups, each opening with ORC and carrying the encoded order. Within an order the RXE encoded-order segment and at least one RXR route are required, and the earlier ORDER_DETAIL (RXO) group is optional. 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 RDE message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in `MSH-9` (`RDE^O11` or `RDE^O25`), 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. Optional and repeating; useful when order behaviour differs across pharmacy-system releases.
`[{NTE}]`	Notes and Comments. Message-level notes that apply to the encoded order as a whole. Optional and repeating.
`[PID]`	Patient Identification. Identifies the patient the order is 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 a pharmacy-to-pharmacy exchange can omit it.
`[PD1]`	Patient Additional Demographic. Supplements `PID` with data such as the patient's primary-care facility.
`[{NTE}]`	Notes and Comments. Notes about the patient carried within the PATIENT group. Optional and repeating.
`[PV1]`	Patient Visit. The encounter the order belongs to — patient class, assigned location, and the providers on the visit. Part of the optional PATIENT_VISIT group.
`[PV2]`	Patient Visit Additional. Companion to `PV1` with admit reason and expected dates when a visit is present.
`[{IN1}]`	Insurance. Coverage for the order — payer, plan, and policy — carried in the optional and repeating INSURANCE group, with `IN2` and `IN3` following.
`[GT1]`	Guarantor. The financially responsible party for the order. Optional.
`[{AL1}]`	Allergy Information. Patient allergies carried with the order. Optional and repeating.
`ORC`	Common Order. Opens each order group and carries the control data common to the order — the order control code in `ORC-1` (`NW`, `RF`, `DC`, `HD`, and so on), the placer and filler order numbers, the ordering provider, and the order date and time. Required, and the order group repeats once per encoded order.
`[{TQ1}]`	Timing/Quantity. The dosing schedule and timing for the order, carried in the optional and repeating TIMING group. `TQ2` follows to relate this order's timing to another.
`[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 in the optional ORDER_DETAIL group. When present it is followed by its own notes, at least one `RXR` route, and optional `RXC` components.
`RXE`	Pharmacy/Treatment Encoded Order. The core of the message and the required clinical segment in the order. It carries the pharmacy-encoded order: the give code and give amount in `RXE-2` through `RXE-5`, the dispense amount and units in `RXE-10` and `RXE-11`, the number of refills in `RXE-12`, the pharmacy-assigned prescription number in `RXE-15`, the number of refills remaining in `RXE-16`, and the ordering and dispensing provider fields — the fully specified instruction the pharmacy will fill.
`[{NTE}]`	Notes and Comments. Notes relative to the encoded order, following the `RXE`. Optional and repeating.
`{TQ1}`	Timing/Quantity. The encoded timing of the order, carried in the required and repeating TIMING_ENCODED group that follows `RXE`; `TQ2` follows to relate it to another order's timing.
`{RXR}`	Pharmacy/Treatment Route. The route of administration (oral, IV, IM) and site for the encoded order. Required and repeating — an order 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. Order-time observations such as height, weight, or a clinical indication used in dosing. Carried in the optional and repeating OBSERVATION group with its own notes.
`[{FT1}]`	Financial Transaction. The charge associated with the order — transaction code, amount, and quantity — sent on to billing. Optional and repeating.
`[BLG]`	Billing. Billing instructions for the order, such as the account to charge. Optional.
`[{CTI}]`	Clinical Trial Identification. Links the order to a clinical trial and study phase, where the medication is part of a protocol. Optional and repeating.

[ ] = optional, { } = repeating

The order group from ORC through CTI repeats once per encoded order, so a single RDE message can carry several orders for one patient. The canonical segment pages carry the full field-by-field detail.

Sample RDE message

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

MSH|^~&|PHARM|MERCYGEN|EHR|MERCYGEN|202006150845||RDE^O11^RDE_O11|MSG00011|P|2.5.1
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
ORC|NW|ORD789^EHR|RX456789^PHARM|||||||1234^SMITH^JANE^A^^^MD||1234^SMITH^JANE^A^^^MD
RXE|1^BID^^202006150900|00071015523^Lisinopril 10 MG Oral Tablet^NDC|10||MG|TAB|||||30|TAB|5|RX456789||||5
TQ1|1||BID||||202006150900
RXR|PO^Oral^HL70162

What this sample shows

The RDE^O11 in MSH-9 marks a pharmacy encoded order. PID carries the medical record number MR12345, and ORC carries the order control code NW (new order) with placer order number ORD789 and filler order number RX456789, naming the ordering provider. The RXE is the encoded order: Lisinopril 10 MG, a give amount of 10 MG per tablet, a dispense amount of 30 tablets, 5 refills authorised (RXE-12), prescription number RX456789 (RXE-15), and 5 refills remaining (RXE-16). The TQ1 gives the twice-daily timing, and the RXR gives the oral route.

Working with RDE messages

Read the order from RXE, not RXO

The encoded order the pharmacy will act on lives in RXE, not in the optional RXO. RXO is the prescriber's original request, carried for reference; RXE is the pharmacy's fully specified, dispensable form. Reconcile dispenses and administrations against the RXE, and treat any difference between RXO and RXE as the pharmacy's encoding decision rather than an error.

Dispatch on the order control code

The trigger event in MSH-9 marks the message as an encoded order, but the specific action — new, refill, discontinue, hold — lives in the order control code in ORC-1. Dispatch on ORC-1 to know whether to open, update, or close an order, because the same RDE^O11 structure carries all of these actions.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key, and treat the prescription number in RXE-15 together with the filler order number in ORC as the natural business key for the order. Pharmacy feeds are replayed after outages, and treating a repeated control id as a duplicate prevents a replayed order from creating a second prescription.

Refills

RXE-12 carries the number of refills authorised and RXE-16 the number remaining. A refill-authorization request arrives as RDE^O25 or as an RDE^O11 carrying an RF order control code; read the refill counts from RXE rather than inferring them from the dispenses that follow.

Vendor variance. The original order in RXO is optional and is included only when the receiving application needs the prescriber's original terms, so some pharmacy systems send both RXO and RXE on every RDE while others send only the encoded RXE. Confirm a partner's field usage against their interface specification rather than assuming the base standard.

FHIR equivalent

A pharmacy encoded order corresponds to the FHIR MedicationRequest resource, with the patient as a Patient resource and, for a messaging exchange, a MessageHeader at the head of a Bundle. The dispenses reported later against the order map to MedicationDispense, and administrations to MedicationAdministration.

There is, however, no published message map to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for RDE_O11 and no ConceptMap for the RXE encoded-order segment — among the pharmacy/treatment segments only RXA, RXO, and RXR have published ConceptMaps, and RXO maps to MedicationRequest from the order side. A FHIR MedicationRequest produced from an RDE message is therefore composed from the per-segment maps, taking the medication, dose, timing, and refill data from RXE (and RXO where present) and the order control data from ORC.

Common pitfalls

Pitfall. Reading the order from RXO instead of RXE. RXO is the prescriber's original request and may be absent; the pharmacy-encoded order the downstream systems act on is in RXE.

Pitfall. Ignoring the order control code in ORC-1. Treating every RDE^O11 as a new order misses discontinuations, holds, and refills that reuse the same message structure with a different ORC-1.

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

How Vorro handles RDE messages

Vorro ingests the RDE feed over MLLP or another transport, deduplicates on MSH-10, and routes each encoded order to every subscribed destination in the format that system expects — the medication record, dispensing cabinets, and inventory. Vorro dispatches on the order control code in ORC-1 to open, update, or close an order, reads the encoded order and refill counts from RXE, and, where a FHIR destination is configured, composes a MedicationRequest resource from the segment maps, since the v2-to-FHIR Implementation Guide publishes no map for this message.

RDS — the dispense message reported against the encoded order.
RGV — the give message that records medication-administration intent for the order.
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 RDE_O11
HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for RXE
HL7 Messaging Standard Version 2.5.1 product brief
HAPI v2.5.1 RDE_O11 message structure
HAPI v2.5.1 RDE_O11_ORDER group structure
HAPI v2.5.1 RDE_O11_PATIENT group structure

← Back to HL7 v2 Guide