HL7 RER messages return pharmacy-encoded-order records in response to a query — the answer a pharmacy system sends back when another application asks for the encoded order information it holds. An RER message is the response half of a query-response pair: a requesting system issues an encoded-order query, and the pharmacy replies with an RER message that acknowledges the query and carries the matching RXE encoded-order records. This page explains what an RER message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an RER encoded order relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an RER message represents
An RER message — RER stands for Pharmacy/Treatment Encoded Order Information Response — communicates the pharmacy-encoded order information that a requesting system asked for. The core of the message is the RXE segment, which carries the encoded order as the pharmacy has interpreted and prepared it: the give code in RXE-2, the give amount minimum in RXE-3, the give units in RXE-5, the dispense amount in RXE-10, the dispense units in RXE-11, and the number of refills in RXE-12. The RXE is the pharmacy's encoded reading of the order — the form the order takes after the pharmacy has resolved the prescriber's request into a fillable, encoded prescription.
The sender is the pharmacy information system that holds the encoded orders, and the receiver is the application that issued the query. RER sits in a request-driven exchange rather than an unsolicited feed: a system needs the current encoded-order state and asks for it, and the RER message returns what the pharmacy has on file. Because the response is built around the query, the MSA acknowledgement and the echoed QRD query definition frame the RXE records that answer it.
When an RER message is sent
An RER message is sent in reply to an encoded-order query — it is never unsolicited. When a requesting application submits a query for pharmacy-encoded order information, the pharmacy system answers with an RER message that acknowledges the query in MSA, echoes the query parameters in QRD, and returns one encoded order per matching record in the repeating order group.
Trigger event
The RER message type carries a single trigger event:
RER^RER– Pharmacy/treatment encoded order information response.
Because RER has one trigger event, the receiver's handling turns on the acknowledgement code in MSA and the contents of the returned RXE records — the give and dispense amounts, the units, and the refills — rather than on the trigger code in MSH-9.
Integration topology
The diagram shows a requesting application querying the pharmacy system through the integration engine and receiving the encoded order information back in an RER response.
{{diagram: requesting application → encoded-order query → integration engine → pharmacy system → RER response → requesting application}}
Typical senders: pharmacy information system, outpatient or retail pharmacy platform, the order-fulfilment system that holds encoded orders.
Typical receivers: the EHR or clinical application that issued the query, an order-management or reconciliation system requesting current encoded-order state.
Direction: a response, returned to the application that issued the query — the reply half of a query-response exchange rather than a one-way notification.
Segments in an RER message
The RER_RER message is built as a query-response envelope: a MSH header, the MSA acknowledgement, optional ERR and message-level NTE segments, and then one or more DEFINITION groups. Each DEFINITION group opens with the echoed query in QRD and contains one or more ORDER groups, each opening with ORC and built around the RXE encoded order. 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 RER message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (RER^RER), 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. MSA-1 carries the acknowledgment code (AA accept, AE error, AR reject) and MSA-2 echoes the control id of the query being answered, tying the response to the request. Required — it is what makes the RER a response. |
[{ERR}] | Error. Detail on any error the query encountered — the location, code, and severity. Present when MSA-1 reports a problem. Optional and repeating. |
[{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, the quantity-limited request, and the what-subject filter. Required, and the DEFINITION group repeats so a response can answer more than one query. |
[QRF] | Query Filter. Refines the echoed QRD with additional selection criteria — the where-subject and when-data filters. Optional; present when the query carried a filter. |
[PID] | Patient Identification. Identifies the patient the encoded orders 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 relative to the patient or the definition group. Optional and repeating. |
ORC | Common Order. Opens each order group and ties the encoded order to its order. The ORC carries the order control code and the filler order number, which links the encoded order back to the originating RDE order. Required, and the order group repeats once per returned encoded order. |
[{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 group. |
RXE | Pharmacy/Treatment Encoded Order. The core of the message and the encoded order returned by the query. It records the pharmacy's encoded reading of the order: the give code in RXE-2, the give amount minimum in RXE-3, the give units in RXE-5, the dispense amount in RXE-10, the dispense units in RXE-11, and the number of refills in RXE-12. Required. |
{RXR} | Pharmacy/Treatment Route. The route of administration (oral, IV, IM) and site for the encoded medication. Required and repeating — a medication with more than one route carries one RXR per route. |
[{RXC}] | Pharmacy/Treatment Component. The components of a compound or IV — each base and additive with its amount. Optional and repeating. |
[DSC] | Continuation Pointer. Supports continuation of a large response across messages, pointing to the next segment of the result set. Optional, closing the order group. |
[ ] = optional, { } = repeating
The order group from ORC through DSC repeats once per returned encoded order, and the DEFINITION group repeats once per echoed query, so a single RER message can answer a query with several encoded orders. The canonical segment pages carry the full field-by-field detail.
Sample RER message
Note. Constructed for illustration. Patient identifiers, order numbers, dates, and names are fictional.
MSH|^~&|PHARM|MERCYGEN|EHR|MERCYGEN|202006150900||RER^RER^RER_RER|MSG00031|P|2.5.1
MSA|AA|QRY00045
QRD|202006150900|R|I|Q00045|||10^RD|MR12345^^^MERCYGEN^MR|RXE||
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
ORC|RE|ORD789^EHR|RX456789^PHARM
RXE|1^BID^^202006150900|00071015523^Lisinopril 10 MG Oral Tablet^NDC|10||MG|||||30|TAB|4
RXR|PO^Oral^HL70162
What this sample shows
The RER^RER in MSH-9 marks an encoded order information response. MSA carries the acknowledgment code AA and echoes the originating query control id QRY00045, tying the response to the request. QRD echoes the query that was answered. PID carries the medical record number MR12345, and ORC carries the order control code RE with filler order number RX456789. The RXE returns the encoded order: the give code Lisinopril 10 MG (RXE-2), a give amount minimum of 10 (RXE-3) in MG (RXE-5), a dispense amount of 30 (RXE-10) in TAB (RXE-11), and 4 refills (RXE-12). The RXR gives the oral route.
Working with RER messages
Match the response to its query
MSA is what makes the message a response: MSA-1 reports whether the query succeeded and MSA-2 echoes the control id of the originating query. Correlate the RER back to the request on MSA-2 rather than on arrival order, so a response that arrives out of sequence is still matched to the right query.
Read the encoded order, not the dispense
The amounts in RXE describe what the pharmacy has encoded to give and dispense, not what was actually handed out. RXE-10 is the dispense amount the order calls for and RXE-12 the refills authorised — the planned shape of the order, not a record of any one fill. To see what was actually supplied, read the dispense in an RDS message; the RER returns the encoded order itself.
Idempotency and deduplication
Use MSH-10, the message control id, as the deduplication key, and treat the echoed query id in MSA-2 together with the filler order number in ORC as the natural business key for a returned encoded order. A query may be retried after a timeout, and treating a repeated control id as a duplicate prevents a replayed response from posting the same encoded order twice.
Handle the error and empty cases
Check MSA-1 before reading the order groups: an AE or AR response carries the problem detail in ERR and may return no order groups at all. A successful AA query can also legitimately match nothing, so treat zero returned RXE segments as an empty result, not a failure.
Vendor variance. The query-response segments —
QRD,QRF, and the original-mode query framework RER belongs to — were deprecated in later v2 releases in favour of the conformance-based query model, so support varies between systems. Confirm a partner's query-response field usage and continuation handling against their interface specification rather than assuming the base standard.
FHIR equivalent
A pharmacy encoded order corresponds to the FHIR MedicationRequest 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 RER_RER and no ConceptMap for the RXE encoded-order segment — among the pharmacy/treatment segments, only RXA, RXO, and RXR have published ConceptMaps, and RXO maps to MedicationRequest from the order side. A FHIR MedicationRequest produced from an RER message is therefore mapped manually, taking the encoded medication, give and dispense amounts, units, and refills from RXE and the patient and order context from PID and ORC.
Common pitfalls
Pitfall. Reading the order groups before checking
MSA-1. AnAEorARresponse may carry noRXErecords and only anERR; processing it as a successful result loses the error detail.
Pitfall. Treating the encoded amounts as a dispense.
RXE-10is the amount the order calls for, not the amount supplied — reading it as a dispense overstates what actually left the pharmacy.
Pitfall. Ignoring the continuation pointer. A large result set can be split across messages with
DSC; a reader that stops at the first message silently truncates the response.
How Vorro handles RER messages
Vorro receives the RER response over MLLP or another transport, deduplicates on MSH-10, and correlates each response back to its query on the echoed id in MSA before routing the returned encoded orders to the subscribing system in the format that system expects. Vorro reads the give and dispense amounts, units, and refills from RXE, links each encoded order back to its order through the filler order number in ORC, follows the continuation pointer in DSC when a result spans messages, and, where a FHIR destination is configured, maps the encoded order to a MedicationRequest resource — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- RDE — the pharmacy encoded order whose encoded records an RER response returns.
- RDS — the dispense message that records what was actually supplied against the encoded order.
- RGV — the give message that records medication-administration intent.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for RER_RER
- HL7 v2-to-FHIR IG — segment maps index — confirms no ConceptMap for RXE
- HL7 Messaging Standard Version 2.5.1 product brief
