Pharmacy / Treatment Dispense

An HL7 Pharmacy/Treatment Dispense (RDS) message is used to communicate when a pharmacy application has dispensed medication or treatments to fill an existing order(s). For example, when the pharmacy dispensing system has collected the HL7 RDE Pharmacy/Treatment Encoded Order message, the dispensing system will fill the order and send the ordering application (ie. an HIS or EMR) and other clinical applications (ie. a nursing system) an HL7 RDS message to communicate information and instructions about the medications dispensed or treatments prescribed.


Below is an example of an HL7 version 2.5 RDS^O13 message. The trigger event O13 was introduced in the HL7 v2.4 standard. Event O01 was used in previous versions.  

MSH|^~\&|MESA_OP|XYZ_HOSPITAL|iFW|ABC_HOSPITAL|200812121359||RDS^O13|00963425|P|2.5 PID|1|12345|12345^^^MIE&1.2.840.114398.1.100&ISO^MR||DOE^JOHN^S||19281118|M|||123 Main St.^^Lake Buena Vista^FL^3283|||||||||||||||||||
RXD|1|1255^Omeprazole^NZMT |200812121359|90|capsule||
FT1|1|||200607211055||CD|00340024110^VERAPAMIL 120MG TABLET^NDC|||100|55.43&USD|
FT1|2|||200607211055||CP|00340024110^VERAPAMIL 120MG TABLET^NDC|||100|5.00&USD|





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. Important patient identification information, including patient demographics. This segment is required.


Common Order. Here is where the order details are held. Medication and treatment dispense messages are typically classified as Observations to Follow (RE) to indicate important information is contained in the following segments. The ORC segment contains information about the ordering/filling systems, related facilities or departments, date and time of the order and the callback information for any questions about the order. This segment can be repeated if the message contains information and instructions for multiple orders.


Pharmacy/treatment Order. This segment contains the complete medication or treatment order information. This data is not specific to components or additives. The RXD segment described below, is utilised to communicate individual order dispense information. This segment is required.



Pharmacy/treatment Route. Pharmacy or medical staff have a choice between order routes based on provider instructions or professional judgement. This segment contains important prescription information regarding medication route, dispense site, administration device, and administration method. This segment is required and can be repeating.


Pharmacy/treatment Dispense. Contains information about the medication or treatment dispensed, such as the type of medication, amount, dosage, expiration, number of refills permitted, etc. The RXD is not a complete record of an order, it is included for each medication included in the order. This segment is required.


Financial Transaction. Contains the necessary information to post charges, payments, adjustment, etc. to patient accounting records. This segment is optional and can be repeated if payment is generated from multiple sources, for example payments made by insurance and the patient.

[ ] = 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.