HL7 RGR messages answer a pharmacy give query — they return the medication give records that match a request, describing what is to be given to a patient, in what amount, by which route, and against which order. An RGR message is the response half of a query-response exchange: a system asks for give information, and the pharmacy or treatment system replies with an RGR carrying the matching RXG give segments. This page explains what an RGR message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an RGR give record relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an RGR message represents
An RGR message — RGR stands for Pharmacy/Treatment Give Information Response — communicates the medication give records that satisfy a give query. The core of the message is the RXG segment, which carries the give data for a single scheduled administration: the give code in RXG-4, the minimum give amount in RXG-5, the give units in RXG-7, and the give indication in RXG-15. The RXG records administration intent — what the patient is to receive on this occasion — rather than what was actually administered.
The sender is the pharmacy or treatment information system that holds the give records, and the receiver is the application that issued the query — most often a nursing, clinical, or medication-administration system reconstructing the give schedule. RGR sits inside a query-response envelope: a give query asks for the records, and the RGR message returns them with an MSA acknowledgement and a QRD that echoes the query. Because the response is a snapshot of the give records as the pharmacy holds them, the RXG — keyed by its give and dispense sub-identifiers — is the authoritative record of the scheduled give.
When an RGR message is sent
An RGR message is sent in direct response to a pharmacy give query. It is not an unsolicited notification: a requesting system asks for the give information for a patient or order, and the responding system returns one RGR carrying the matching records. A single response can contain several give records grouped under several orders, so the full give schedule for a patient can be returned in one message.
Trigger event
The RGR message type carries a single trigger event:
RGR^RGR– Pharmacy/treatment give information response message.
Because RGR has one trigger event, the receiver's handling turns on the contents of MSA — whether the query was accepted — and on the give records in RXG, rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the requesting system issuing a give query and the pharmacy system returning the RGR response through the integration engine.
{{diagram: requesting system → give query → integration engine → pharmacy system → RGR response → requesting system}}
Typical senders: pharmacy information system, treatment information system, medication-management platform answering a give query.
Typical receivers: nursing or clinical application, medication-administration system, EHR medication record reconstructing the give schedule.
Direction: the response leg of a query-response exchange — the pharmacy source replies to the system that issued the give query.
Segments in an RGR message
The RGR_RGR message is organised into groups: an optional message-level header of acknowledgement and notes, one or more DEFINITION groups (each opening with QRD and carrying the patient and the orders), and within each definition one or more ORDER groups, each opening with ORC and ending with one or more GIVE groups built around the RXG give segment and its required RXR route. 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 RGR message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (RGR^RGR), 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 Acknowledgement. Acknowledges the query the RGR responds to. It carries the acknowledgement code in MSA-1 and echoes the control id of the query in MSA-2, so the requester can match the response to its request. Required — the RGR is a response and must acknowledge what it answers. |
[{ERR}] | Error. Any errors detected in processing the query — the location and the error condition. 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 original query — the query date/time, the format and priority, the quantity limit, and the subject the records were requested for. Required, and the definition group repeats once per query answered. |
[QRF] | Query Filter. Refines the query echoed in QRD with the filters the requester applied — date ranges and other selection criteria. Optional. |
[PID] | Patient Identification. Identifies the patient the give records belong to — the identifier list in PID-3, the name in PID-5. Optional; present when the response is scoped to a patient. |
[{NTE}] | Notes and Comments. Notes that apply to the patient within the definition group. Optional and repeating. |
ORC | Common Order. Opens each order group and ties the give records to their order. The ORC carries the order control code and the filler order number, which links the give back to its originating order. Required, and the order group repeats once per order returned. |
[{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 within the timing group. |
[RXE] | Pharmacy/Treatment Encoded Order. The pharmacy-encoded prescription the give records belong to, with its own encoded timing, route, and components. Optional — opens the encoding group; present when the requester needs the encoded order alongside the give records. |
{RXR} | Pharmacy/Treatment Route. The route of administration and site for the encoded order. Required and repeating within the encoding group when RXE is present. |
[{RXC}] | Pharmacy/Treatment Component. The components of a compound or IV for the encoded order — each base and additive with its amount. Optional and repeating within the encoding group. |
RXG | Pharmacy/Treatment Give. The core of the message and the segment that carries each give record. It opens a give group and records the give as scheduled: the give sub-id in RXG-1 and the dispense sub-id in RXG-2 that key the record, the give code in RXG-4, the minimum give amount in RXG-5, the give units in RXG-7, and the give indication in RXG-15. Required within the give group, which repeats once per scheduled give. |
{RXR} | Pharmacy/Treatment Route. The route of administration (oral, IV, IM) and site for the give. Required and repeating — a give with more than one route carries one RXR per route. |
[{RXC}] | Pharmacy/Treatment Component. The components of a compound or IV give — each base and additive with its amount. Optional and repeating. |
[{OBX}] | Observation/Result. Give-time observations such as a measured value or a flag, each with its own optional notes. Optional and repeating. |
[DSC] | Continuation Pointer. Carries a continuation pointer when the response is too large for a single message and is returned in segments. Optional, closing the give group. |
[ ] = optional, { } = repeating
The give group built around RXG repeats once per scheduled give, the order group from ORC repeats once per order, and the definition group from QRD repeats once per query answered — so a single RGR message can return the full give schedule across several orders. The canonical segment pages carry the full field-by-field detail.
Sample RGR message
Note. Constructed for illustration. Patient identifiers, order numbers, dates, and names are fictional.
MSH|^~&|PHARM|MERCYGEN|EHR|MERCYGEN|202006150900||RGR^RGR^RGR_RGR|MSG00021|P|2.5.1
MSA|AA|QRY00017
QRD|202006150900|R|I|Q001|||10^RD|MR12345^^^MERCYGEN^MR|RXG||
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
ORC|RE|ORD789^EHR|RX456789^PHARM
RXG|1|1||00071015523^Lisinopril 10 MG Oral Tablet^NDC|10||MG|||||||||Hypertension
RXR|PO^Oral^HL70162
What this sample shows
The RGR^RGR in MSH-9 marks a give information response. MSA carries the acknowledgement code AA and echoes the query control id QRY00017, matching the response to its request. QRD echoes the query — record-oriented response (R) for subject MR12345, asking for RXG records. PID carries the medical record number MR12345, and ORC carries the order control code RE with filler order number RX456789, linking the give to its order. The RXG reports the scheduled give: give sub-id 1 and dispense sub-id 1 (RXG-1, RXG-2), give code Lisinopril 10 MG (RXG-4), a minimum give amount of 10 (RXG-5) in MG units (RXG-7), and a give indication of Hypertension (RXG-15). The RXR gives the oral route.
Working with RGR messages
Read the acknowledgement in MSA before the give records
Because the RGR is the response leg of a query, check MSA first. MSA-1 tells you whether the query was accepted, and any ERR segments describe why it was not. A response that returns no give records is not necessarily an error — confirm against MSA rather than treating an empty result as a failure.
Key each give on its sub-identifiers
A give record is identified by the give sub-id in RXG-1 together with the dispense sub-id in RXG-2, scoped to its order. Use the pair as the natural business key for a scheduled give rather than the message control id, so the same give returned in two responses reconciles to one record.
Give intent, not administration
RXG records administration intent — what the patient is scheduled to receive — not what was actually administered. Do not post an RGR give record as a completed dose. The actual administration is reported separately by an RAS message; reconcile the give against the administration rather than assuming the give was carried out.
Continuations with DSC
When a give schedule is too large for one message, the responder returns it in segments closed by a DSC continuation pointer. Follow the pointer to retrieve the remaining records, and do not treat a continued response as the complete set until the final segment arrives.
Vendor variance. The encoding group built on
RXEis optional, so some pharmacy systems return the encoded order alongside every give while others return only theRXGgive records and their routes. Confirm a partner's field usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A pharmacy give record corresponds to the FHIR MedicationAdministration resource — modelling administration intent — with the patient as a Patient resource and, for a messaging exchange, a MessageHeader at the head of a Bundle. Where the give is treated as a request rather than a record of intent, MedicationRequest is the closer fit.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for RGR_RGR and no ConceptMap for the RXG give segment — among the pharmacy/treatment segments, only RXA, RXO, and RXR have published ConceptMaps, and none of them covers the give. A FHIR MedicationAdministration produced from an RGR message is therefore mapped manually, taking the give code, amount, units, route, and indication from RXG and RXR and referencing the authorising MedicationRequest derived from the order.
Common pitfalls
Pitfall. Posting an RGR give record as an administered dose.
RXGcarries administration intent, not the dose actually given; the administration is reported by an RAS message, and treating the give as completed overstates what the patient received.
Pitfall. Ignoring the acknowledgement in
MSA. The RGR is a query response; reading the give records without checkingMSA-1and anyERRsegments can hide a query that was rejected or only partially satisfied.
Pitfall. Treating a continued response as complete. When a
DSCcontinuation pointer is present, more give records follow; processing the first segment as the full result drops the remainder of the schedule.
How Vorro handles RGR messages
Vorro receives the RGR response over MLLP or another transport, matches it to its query through the control id echoed in MSA, and routes each give record to every subscribed destination in the format that system expects. Vorro reads the give code, amount, units, and indication from RXG, keys each record on its give and dispense sub-identifiers, links each give back to its order through the filler order number in ORC, follows any DSC continuation to assemble the full schedule, and, where a FHIR destination is configured, maps the give to a MedicationAdministration resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- RGV — the give message that records medication-administration intent, the records an RGR returns.
- RAS — the administration message that records the dose actually given to the patient.
- RDS — the dispense message that reports a medication actually supplied by the pharmacy.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for RGR_RGR
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for RXG
- HL7 Messaging Standard Version 2.5.1 product brief
