Pharmacy / Treatment Encoded Order

An HL7 Pharmacy/Treatment Encoded Order (RDE) message is used to send orders to a pharmacy or medication dispensing system. It is used to facilitate communication between the ordering application (e.g. HIS) and the filling application (e.g pharmacy dispensing system). 

Both ORM and RDE messages can be used to submit phar macy orders. The decision to use ORM or RDE depends on the sending and receiving systems’ ability to support either message format. For example, if the sending system outputs pharmacy orders in ORM format, but the receiving system can only ingest RDE formats, it can result in messages being ignored, rejected, or resulting in error. In cases like this, interface engines such as Iguana can be used to translate one message format to another that is successfully accepted by the receiving system. 

RDE messages are composed of three different message types:

      • RDE^O01 – Order message (also RDE, RDS, RGV, RAS)
      • RDE^O11 – Pharmacy/treatment encoded order
      • RDE^O25 – Pharmacy/treatment refill authorization request


Below is an example of an HL7 version 2.3 RDE^O01 message, used to send a medication order:

PID|0001|1212121|9999999999||DOE^JOHN^||19010121|U|||123 HOME ST^^INDIANAPOLIS^IN^46201 |||||||0002104398|000-00-0000 PV1||1^I/P^00|003^UCC12^|D|||005600^SMITH^ELAINE^MD|^^^|^^^|1|||||||00 5600^SMITH^HAROLD^MD|||||||||||||||||||||||||||200910010938| PV2|||||||U|20090930000000||||||||||||||||||| MRG|112923
OBX|1|ST|1010.3^Height||072|Inches OBX|2|ST|1010.1^Body Weight||190.00|pounds ORC|NW|RX12345^ABC|||||1^^INDEF^201108250200^^RTN||20110825012431
RXE|1^^INDEF^201108250200|00338004902^SODIUM CHLORIDE 0.9 %^NDC|230||ML|SOLP
RXC|B|00338004902^SODIUM CHLORIDE 0.9 %^NDC|230|ML





Message Header. The header contains information about the sending system and location, the receiving system and location, the date and time of when the message was created, the type of trigger event being communicated, and the HL7 message version being used. This segment is required.


Patient Identification. Includes important patient identification information, including patient demographics. This segment is required.


Patient Visit. Contains information about patient visit details such as servicing facility, attending doctor, and visit ID. This segment is required.


Patient Visit - Additional Info. This segment is a continuation of information specific to the patient’s visit, and is the segment where the Admit Reason is communicated. It is an optional segment if a DG1 segment is included in the message. If there is no DG1 segment, then the PV2 segment is required.



Policy Coverage. Information about the patient’s insurance policy is listed here and is used to create patient and insurance bills. This segment is optional.


Observation Segment. Here is where information about the observation results is held. An OBX segment is used to communicate a single observation, so multiple observations would require this segment to repeat. This segment is optional and can be repeating.


Common Order. Here is where the order details are held. Additionally, information about the order number from the source system, the order number for the filing system, the date and time of when the order was created, the ordering provider, the order transcriber, the facility or department ID related to the order, and the callback information for any questions about the order are all contained within this segment. This segment is required.


Pharmacy Encoded Order. Provides information about the pharmacy or treatment application’s encoding of the order. This segment is required.


Pharmacy Route. Pharmacy or medical staff have a choice between order routes based on provider instructions or professional judgement. Contains an alternative combination of medication route, dispense site, administration device, and administration method. This segment is required and can be repeated.

[ ] = optional, { } = repeating


For more information on implementing various HL7 message types, please refer to the HL7 Messaging Standard Implementation Guides corresponding to your required version. 






Other HL7 Message Types:

      • HL7 ADT (Admit, Discharge and Transfer)
      • HL7 ORM (Order Entry)
      • HL7 ORU (Observation Result)
      • HL7 MDM (Medical Document Management)
      • HL7 DFT (Detailed Financial Transactions)
      • HL7 BAR (Billing Account Record)
      • HL7 SIU (Scheduling Information Unsolicited)
      • HL7 RDS (Pharmacy/treatment Dispense)
      • HL7 RDE (Pharmacy/Treatment Encoded Order)
      • HL7 ACK (Acknowledgement Message)


Integration with HL7

HL7 is great standard, but anyone with first hand experience knows it's not without its challenges. We're here to help!

Let's talk

The ''non-standard" Standard

In practice, you'll find that everyone formats HL7 messages slightly different, even though it has a standard structure in place. With iNTERFACEWARE's integration engine, you can ensure that all data is normalized as intended for full compliance.


Version Compatiblity

What happens when the source destination is sending one version of HL7, while the recipient's system can only handle an older version of HL7? With Iguana you can convert HL7 versions on the fly.


Data Extraction

As you've seen, HL7 messages can contain a lot of information -- sometimes much more than you need. Simplify things using Iguana, by extracting the data from the specific HL7 fields you need. 


Future Proofing

The HL7 organization is always working on improving the standard and new versions will keep coming in the future. Ensure that your data always remains compatible with iNTERFACEWARE's integration engine, Iguana.