HL7 RAR messages return medication-administration records in response to a pharmacy administration query — the records that say which doses were actually administered to a patient, when, in what amount, and by which route. An RAR message is the answer half of a query-response exchange: a requesting system asks for a patient's administration history and the pharmacy or treatment application replies with one RAR message carrying the matching RXA administration records. This page explains what an RAR message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an RAR administration record relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an RAR message represents
An RAR message — RAR stands for Pharmacy/Treatment Administration Information Response — communicates the administration records that satisfy a pharmacy administration query. The core of the message is the RXA segment, which carries the data for a single administration: the date and time the administration started in RXA-3, the administered code in RXA-5, the administered amount in RXA-6 and units in RXA-7, and the completion status in RXA-20. Each RXA records one dose as it was given, not the order behind it.
RAR is a query-response message: it is wrapped in an acknowledgement envelope rather than sent as an unsolicited notification. The MSA segment forms the acknowledgement of the originating query, and the QRD segment echoes the query parameters so the requester can match the response to what it asked. The sender is the pharmacy or treatment application that holds the administration records, and the receiver is the system that issued the query — typically a clinical, nursing, or reconciliation application building a medication-administration history. Because the response replays administrations that have already happened, the RXA is the authoritative record of what was given, while the surrounding MSA and QRD carry the conversation state.
When an RAR message is sent
An RAR message is sent in reply to a pharmacy administration query — it is never unsolicited. When a system asks for the administration records that match a set of query parameters, the responding application gathers the matching RXA records and returns them in a single RAR message, acknowledging the query in MSA and echoing the original parameters in QRD.
Trigger event
The RAR message type carries a single trigger event:
RAR^RAR– Pharmacy/treatment administration information response.
Because RAR has one trigger event, the receiver's handling turns on the acknowledgement code in MSA and the administration contents of RXA — the administered code, amount, date, and completion status — rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the requesting system issuing a query and the pharmacy system replying through the integration engine with the matching administration records.
{{diagram: querying clinical/nursing app → query → integration engine → pharmacy system → RAR response → integration engine → querying clinical/nursing app}}
Typical senders: pharmacy information system, treatment-administration application, medication-administration record system.
Typical receivers: the clinical, nursing, or reconciliation application that issued the originating query.
Direction: the response leg of a synchronous query-response exchange — the RAR travels back to whichever system sent the administration query.
Segments in an RAR message
The RAR_RAR message opens with the acknowledgement of the query — MSH then MSA, with optional ERR and NTE — and then carries one or more DEFINITION groups. Each definition group opens with the echoed query (QRD) and contains one or more ORDER groups; each order group opens with ORC and contains one or more ADMINISTRATION groups built around the RXA administration segment. 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 RAR message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (RAR^RAR), carries the message control id in MSH-10, and pins the HL7 version. Receivers route on MSH-9 and deduplicate on MSH-10. |
MSA | Message Acknowledgment. Acknowledges the originating query. It carries the acknowledgment code in MSA-1 (for example AA for application accept) and the message control id of the query being answered in MSA-2, which lets the requester match the response to its outstanding query. Required. |
[{ERR}] | Error. Reports any error encountered while processing the query — the location, the error code, and severity. Optional and repeating; present when the query could not be fully satisfied. |
[{NTE}] | Notes and Comments. Message-level notes that apply to the response as a whole. Optional and repeating. |
QRD | Query Definition. Opens each definition group and echoes the parameters of the query being answered — the query date/time, format, priority, the requested quantity, and the subject filter. Echoing QRD lets the requester confirm the response matches what it asked for. Required, and the definition group repeats. |
[QRF] | Query Filter. Refines the QRD with additional selection criteria, such as a date range or other qualifiers applied to the query. Optional. |
[PID] | Patient Identification. Identifies the patient whose administration records are returned — the identifier list in PID-3, the name in PID-5. Optional, since a query may be scoped in other ways. |
[{NTE}] | Notes and Comments. Notes relative to the patient or the definition group. Optional and repeating. |
ORC | Common Order. Opens each order group and ties the returned administrations to their order. The ORC carries the order control code and the filler order number, which links the administration back to the originating order. Required, and the order group repeats once per order in the response. |
[{TQ1}] | Timing/Quantity. The dosing schedule and timing for the order. Optional and repeating; introduced as the replacement for the deprecated quantity/timing field in v2.5. |
[{TQ2}] | Timing/Quantity Relationship. Relates this order's timing to another order, when sequenced or conditional dosing applies. Optional and repeating, nested within the TQ1 timing. |
[RXE] | Pharmacy/Treatment Encoded Order. The pharmacy-encoded prescription the administrations were given against, with its own encoded route and components. Opens the optional ENCODING group; present only when the requester needs the order context, since the administration record itself stands on RXA. |
{RXR} | Pharmacy/Treatment Route. Within the ENCODING group, the route of administration (oral, IV, IM) and site for the encoded order. Required and repeating when the ENCODING group is present. |
[{RXC}] | Pharmacy/Treatment Component. The components of a compound or IV in the encoded order — each base and additive with its amount. Optional and repeating. |
RXA | Pharmacy/Treatment Administration. The core of the message and the only required clinical segment in the administration group. It records the administration as it happened: the date and time administration started in RXA-3, the administered code in RXA-5, the administered amount in RXA-6 and units in RXA-7, and the completion status in RXA-20. The administration group repeats once per administered dose. |
{RXR} | Pharmacy/Treatment Route. The route of administration and site for the administered dose. Required and repeating within the administration group — a dose given by more than one route carries one RXR per route. |
[{OBX}] | Observation/Result. Administration-time observations such as a vital sign taken at the time of the dose or a lot number. Optional and repeating. |
[{NTE}] | Notes and Comments. Notes relative to an observation, following the OBX. Optional and repeating. |
[DSC] | Continuation Pointer. Supports continuation of a large response across messages — the pointer the requester sends back to fetch the next segment of results. Optional, closing the administration group. |
[ ] = optional, { } = repeating
The definition group from QRD onward repeats, and within it the order group from ORC and the administration group around RXA repeat, so a single RAR message can return many administrations for one patient. The canonical segment pages carry the full field-by-field detail.
Sample RAR message
Note. Constructed for illustration. Patient identifiers, order numbers, dates, and names are fictional.
MSH|^~&|PHARM|MERCYGEN|EHR|MERCYGEN|202006150930||RAR^RAR^RAR_RAR|MSG00045|P|2.5.1
MSA|AA|QRY00021
QRD|202006150930|R|I|Q00021|||10^RD|MR12345^^^MERCYGEN^MR|RAR||
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
ORC|RE|ORD789^EHR|RX456789^PHARM
RXA|0|1|202006150900||00071015523^Lisinopril 10 MG Oral Tablet^NDC|10|MG|||||||||||||CP
RXR|PO^Oral^HL70162
What this sample shows
The RAR^RAR in MSH-9 marks an administration information response. MSA carries AA (application accept) and the control id QRY00021 of the query being answered. QRD echoes the query parameters, including the subject MR12345. PID confirms the patient, and ORC carries the order control code RE with filler order number RX456789, linking the administration to its order. The RXA reports the dose actually given: administration started at 202006150900 (RXA-3), the administered code is Lisinopril 10 MG (RXA-5), the administered amount is 10 (RXA-6) in MG (RXA-7), and the completion status is CP — complete — in RXA-20. The RXR gives the oral route.
Working with RAR messages
Match the response to the query through MSA and QRD
An RAR is meaningless without the query it answers. Read the acknowledgment code in MSA-1 first — an AE or AR means the query failed and the response carries no administrations — and match MSA-2 to the control id of the query you sent. Use the echoed QRD to confirm the response is scoped to the patient and parameters you asked for before posting any of its records.
Read the administration from RXA, not the order
The administered amount, date, and completion status live in RXA, not in the order. RXA records what was actually given on this occasion, so a held or refused dose shows up in the completion status of RXA-20 rather than as a quantity matching the order. Reconcile against RXA rather than assuming the administration matched the order.
Completion status drives reconciliation
RXA-20 records whether the dose was completed, partially given, refused, or not administered. Surface this on the medication-administration record rather than treating every returned RXA as a completed dose — a refused or partial administration differs, clinically, from one that was given in full.
Continuation with DSC
A large administration history can exceed a single message. When DSC is present, the response is continued — send the pointer back to retrieve the next segment rather than assuming the first RAR holds the complete history.
Vendor variance. The ENCODING group built around
RXEis optional and is included only when the requester needs the order context, so some pharmacy systems return the full encoded order with every administration while others return only the administration inRXA. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A medication administration corresponds to the FHIR MedicationAdministration resource, with the patient as a Patient resource and, for a messaging exchange, a MessageHeader at the head of a Bundle.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for RAR_RAR. The RXA administration segment does have a published ConceptMap, but it targets the Immunization resource rather than MedicationAdministration, so it does not apply to a general pharmacy/treatment administration record. A FHIR MedicationAdministration produced from an RAR message is therefore mapped manually, taking the administered medication, amount, start time, and completion status from RXA and referencing the authorising MedicationRequest derived from the order.
Common pitfalls
Pitfall. Posting administration records without checking the acknowledgment. An
AEorARinMSA-1means the query was not satisfied; treating the response as a successful result posts an empty or partial history as though it were complete.
Pitfall. Treating every returned
RXAas a completed dose. Ignoring the completion status inRXA-20records refused, held, or partial administrations as full doses.
Pitfall. Assuming a fixed date-time precision on
RXA-3. Some senders stamp the administration start asYYYYMMDDand others as a full timestamp with an offset; do not assume a timezone — normalize on ingest.
How Vorro handles RAR messages
Vorro correlates each RAR response to its originating query, reads the acknowledgment code in MSA, and verifies the echoed QRD parameters before routing the administration records to every subscribed destination in the format that system expects — the medication-administration record and reconciliation systems. Vorro reads the administered code, amount, date, and completion status from RXA, links each administration back to its order through the filler order number in ORC, follows DSC to gather continued results, and, where a FHIR destination is configured, maps the administration to a MedicationAdministration resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- RAS — the administration message that records a dose given to the patient, the event an RAR replays in response to a query.
- RGV — the give message that records medication-administration intent.
- RDE — the pharmacy encoded order that an administration is given against.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for RAR_RAR
- HL7 v2-to-FHIR IG — segment maps index — confirms the RXA ConceptMap targets Immunization, not MedicationAdministration
- HL7 Messaging Standard Version 2.5.1 product brief
