HL7 RRE_O12 Pharmacy/Treatment Encoded Order Acknowledgment
RRE_O12 is the application response to an RDE_O11 encoded order. It is not just a generic "I received your bytes" acknowledgment. It is the pharmacy or treatment application saying whether it accepted the encoded order workflow, and it may include a compact copy of the patient, order, and encoded medication detail that it accepted.
The sender is usually pharmacy, treatment, or pharmacy middleware. The receiver is commonly the EHR, CPOE system, eMAR, or integration engine that sent the RDE. The most important operational fields are in MSA and ERR: accepted, rejected, application error, and enough detail for the sender to retry, correct, or alert someone.
A small RRE example
What systems do with it
RRE normally closes the loop on an RDE exchange. A clean MSA|AA tells the sender that the receiving application accepted the message. AE or AR should come with useful ERR detail so the sender can distinguish a retryable problem from a bad order, bad drug code, unsupported route, or duplicate control ID.
The optional response group is where RRE can echo the relevant patient and order detail. ORC ties the response to the placer and filler order numbers. RXE, TQ1, RXR, and RXC describe the accepted encoded order when the receiver chooses to return it.
How to read the structure
The top of the message is the acknowledgment layer: MSH, MSA, optional ERR, software information, and notes. The response group is optional, but if it appears the order group repeats and starts with ORC. The encoding group is also optional, but when present it requires RXE, encoded timing, at least one RXR, and optional components.
That shape matters in production because some systems send a terse RRE with only MSH, MSA, and ERR, while others send a fuller application response with the accepted order detail. Both patterns can be valid. The interface specification should say which one the sender expects.
Implementation traps
The first trap is treating RRE like an automatic transport ACK. In enhanced acknowledgment mode, an application acknowledgment message should not ask for another application acknowledgment back. Keep MSH-15 and MSH-16 aligned with the actual choreography.
The second trap is trusting the echoed medication detail without checking order identifiers. If the receiver changes or normalizes the encoded order, reconcile by the placer and filler numbers in ORC, not by display text. Drug names are useful to people, but order numbers are what let systems close the loop.
Reference notes
The HL7 v2+ RRE_O12 page lists this as the pharmacy/treatment encoded order acknowledgment and shows the MSH, MSA, ERR, optional response, patient, order, timing, encoding, RXE, RXR, and RXC structure.