HL7 RRA_O18 Pharmacy/Treatment Administration Acknowledgment

The receiver is answering an administration event.
HL7 message structure RRA_O18 groups and segments from HL7 v2.5.1 Hide structure

These are the generated groups and segments for the version selected at the top of the page. The article explains the workflow, and this panel follows the chosen HL7 version.

Message Structure

SegmentNameRequiredRepeatable
MSH
 Message Header Yes No
MSA
 Message Acknowledgment Yes No
ERR
 Error No Yes
SFT
 Software Segment No Yes
NTE
 Notes and Comments No Yes
RRA_O18.RESPONSE
 Response group No No
RRA_O18.PATIENT
 Patient group No No
PID
 Patient Identification Yes No
NTE
 Notes and Comments No Yes
RRA_O18.ORDER
 Order group Yes Yes
ORC
 Common Order Yes No
RRA_O18.TIMING
 Timing group No Yes
TQ1
 Timing/Quantity Yes No
TQ2
 Timing/Quantity Relationship No Yes
RRA_O18.ADMINISTRATION
 Administration group No No
RXA
 Pharmacy/Treatment Administration Yes Yes
RXR
 Pharmacy/Treatment Route Yes No

RRA_O18 is the application response to an RAS_O17 pharmacy/treatment administration message. The RAS says what happened at administration time. The RRA says whether the receiving application accepted that administration event and, optionally, returns the patient, order, and administration detail that was processed.

This is an important message when administration events drive pharmacy review, charge capture, inventory decrement, clinical repositories, or medication history. A lost RAS can leave a patient record incomplete. A vague RRA can make it hard to know whether a retry is safe.

A small RRA example

MSH|^~\&|PHARM|CITYHOSP|MAR|CITYHOSP|20260715141300||RRA^O18^RRA_O18|RRA00001|P|2.5.1 MSA|AA|RAS00001 PID|1||123456^^^CITYHOSP^MR||Smith^Jane^Anne^^Ms^^L||19800314|F ORC|OK|MED448811^EHR|RX998877^PHARM RXA|0|1|20260715140000|20260715140200|AMOX500^Amoxicillin 500 mg capsule^L|1|CAP^capsule^UCUM||00^Administered^HL70167|12345^Nurse^Nora RXR|PO^Oral^HL70162

What systems do with it

The sender is the system that received the administration report. The receiver is the original RAS sender, usually an eMAR or clinical system. MSA gives the acknowledgment result, and ERR should identify patient, order, dose, route, timestamp, or duplicate-event problems with enough precision to route the exception.

When response detail is sent, RXA is the administration segment, RXR carries route, and ORC connects the administration back to the medication order. This echo can be useful for reconciliation, but it should not replace a durable local event identifier.

How to read the structure

The core acknowledgment layer is MSH, MSA, and optional ERR. The optional response group can carry patient context and one or more order groups. Each order group may include timing and an administration group.

If the administration group appears, RXA is required and RXR repeats. That mirrors the practical relationship: the administration event needs a medication/dose/time, and the route tells the receiver how the dose was administered.

Implementation traps

The most common trap is making all non-AA responses look the same. A duplicate administration, unknown order, invalid route, and clinical rejection need different downstream handling. Put that distinction in ERR rather than relying on a free-text note that nobody parses.

Also be careful with resend behavior. If the sender retries after a timeout, the receiver should be able to answer idempotently. Otherwise an integration engine may have to choose between losing an administration and creating a duplicate event.

Reference notes

The HL7 v2+ RRA_O18 page lists this as the pharmacy/treatment administration acknowledgment and shows the response, patient, order, timing, administration, RXA, and RXR structure.