HL7 OPR messages carry the response to a population- or location-based observation request — the acknowledgement returned to the system that sent an OPL request for observations scoped to a population (a cohort, a registry, a screening programme) or to a physical location (a ward, a unit, a facility). An OPR message is the response half of that exchange: a receiver (typically a clinical system, registry, or analytics service) replies to one OPL with an OPR that confirms acceptance or signals an error in MSA, itemises any problems in ERR, and echoes the order, observation, and specimen content the receiver has accepted. OPR was introduced in HL7 v2.8 and is not part of v2.5.1; teams running v2.5.1 feeds will not encounter this message. This page documents the v2.8 form. It explains what an OPR message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an OPR response relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an OPR message represents
An OPR message — OPR stands for Population/Location-Based Observation Response — communicates the receiver's acknowledgement of a population- or location-based observation request previously sent in an OPL. The core of the message is the pairing of MSA, which carries the acknowledgement code (AA accept, AE application error, AR application reject) and echoes the OPL's message control id in MSA-2, with an optional RESPONSE group that echoes the accepted patient, order, observation, and specimen content. Each ORDER group inside the response re-states one of the orders from the original request, scoped to the population or location the request targeted.
OPR was introduced in HL7 v2.8 and is not part of v2.5.1; teams running v2.5.1 feeds will not encounter this message. This page documents the v2.8 form. OPR is a solicited response message: the receiver issues it only in reply to an inbound OPL. The MSA segment pins the response to the original request — MSA-2 carries the OPL's message control id so the sender can correlate request and response — and the acknowledgement code in MSA-1 tells the sender whether the request was accepted in full (AA), accepted with application-level issues itemised in ERR (AE), or rejected outright (AR). The sender of the OPR is the system that received the OPL; the receiver is the original OPL sender. Because the message acknowledges a population- or location-scoped request, the echoed OBR, OBX, and SPM segments confirm what the receiver has accepted, while the surrounding ERR and NTE segments carry error detail and free-text notes.
When an OPR message is sent
An OPR message is sent whenever a system has received an OPL population- or location-based observation request and needs to acknowledge it — to confirm acceptance, to reject the request, or to flag application-level issues with one or more of its orders. It is event-driven and solicited: the receiver does not initiate OPR, it returns one for each OPL it has processed. OPR is paired in practice with OPL (the request it acknowledges) and lives alongside OPU (the unsolicited population/location-based observation update) and ORL (the general laboratory order response) in the population- and location-based observation message set.
Trigger event
The OPR message type carries a single trigger event:
OPR^O38– Population/location-based observation response.
Because OPR has one trigger event, the receiver's handling turns on the acknowledgement code in MSA and the error detail in ERR — whether the request was accepted and what, if anything, went wrong — rather than on the trigger code in MSH-9.
Integration topology
The diagram shows the clinical system or registry that received the OPL returning an OPR through the integration engine to the original OPL sender.
{{diagram: original OPL sender (analytics service / registry / population health system) → OPL request → integration engine → clinical system / registry / receiver → OPR response → integration engine → original OPL sender}}
Typical senders: the clinical system, registry, or analytics service that received the OPL — an LIS, EHR, public health registry, or population health platform.
Typical receivers: the original OPL sender — an analytics service, population health platform, screening programme, or location-based reporting system.
Direction: the response leg of a request-response exchange — the OPR travels from the OPL receiver back to the OPL sender, correlated on the OPL's message control id echoed in MSA-2.
Segments in an OPR message
The OPR_O38 message opens with MSH, followed by the acknowledgement in MSA, optional ERR and NTE segments, and then an optional RESPONSE group that echoes the accepted patient, order, observation, and specimen content from the original OPL. 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 OPR message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (OPR^O38), 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. Carries the acknowledgement. MSA-1 holds the acknowledgement code — AA application accept, AE application error, AR application reject — and MSA-2 echoes the message control id of the original OPL so the sender can correlate the response with the request. Required, and the heart of the message together with any ERR segments. |
[{ERR}] | Error. Itemises application-level problems with the request — bad codes, unknown identifiers, missing required fields, structural errors. Optional and repeating; expect one ERR per discrete problem when MSA-1 is AE or AR. |
[{NTE}] | Notes and Comments. Free-text notes scoped to the response as a whole — operator commentary, interpretive notes, processing context. Optional and repeating. |
[PID] | Patient Identification. Opens the optional RESPONSE group when the response echoes patient-scoped content. Identifies the patient the echoed orders apply to — used when the population is resolved to identified individuals rather than carried as an anonymous cohort. Optional. |
[PD1] | Patient Additional Demographics. Additional demographic detail for the patient in PID — primary care provider, living arrangement, publicity code. Optional. |
[{NTE}] | Notes and Comments. Patient-scoped notes inside the RESPONSE group — commentary that applies to the patient rather than to a specific order. Optional and repeating. |
ORC | Common Order. Opens each ORDER group inside the response. Echoes the order control code, placer and filler order numbers, and order status of an order from the original OPL request. Required inside the ORDER group; the ORDER group repeats — one per echoed order. |
OBR | Observation Request. Echoes the request detail for the order — the universal service identifier, observation date/time, ordering provider, specimen source, and the population or location scope. Required inside the ORDER group, paired with ORC. |
[{NTE}] | Notes and Comments. Order-scoped notes inside the ORDER group. Optional and repeating. |
[{TQ1 [{TQ2}]}] | Timing/Quantity. Timing for the echoed order — when the observation should be performed, how often, for how long. TQ1 opens the timing group and TQ2 carries relationships to other timings. Optional and repeating. |
[{OBX [{NTE}]}] | Observation/Result. The OBSERVATION group inside each ORDER group. OBX echoes one observation accepted by the receiver — the observation identifier in OBX-3, the value in OBX-5, the units in OBX-6, the abnormal flags in OBX-8, and the result status in OBX-11. Each OBX may be followed by repeating NTE segments scoped to that observation. Optional and repeating. |
[{SPM [{OBX}]}] | Specimen. Echoes specimen detail for the order — the specimen identifier, type, collection date/time, and source. Each SPM may be followed by repeating OBX segments carrying specimen-level observations such as volume, condition, or quality. Optional and repeating. |
[ ] = optional, { } = repeating
The RESPONSE group is optional as a whole, and the ORDER group inside it repeats so a single OPR can echo every order from a multi-order OPL in one exchange. The canonical segment pages carry the full field-by-field detail.
Sample OPR message
Note. Constructed for illustration. Patient identifiers, order numbers, observation identifiers, and dates are fictional.
MSH|^~&|REGISTRY|MERCYGEN|POPHEALTH|MERCYGEN|202006150930||OPR^O38^OPR_O38|MSG00091|P|2.8
MSA|AA|OPL00045
PID|1||PAT123456^^^MERCYGEN^MR||DOE^JANE^A||19700515|F
PD1|||||||||||N
ORC|OK|PLAC987654|FILL654321||CM
OBR|1|PLAC987654|FILL654321|A1C^Hemoglobin A1C^LN|||202006150900|||||||||DOC123^SMITH^JOHN
OBX|1|NM|A1C^Hemoglobin A1C^LN||6.8|%|4.0-5.6|H|||F
SPM|1|SPEC456789^MERCYGEN||SER^Serum^HL70487|||||||||||||202006150900
What this sample shows
The OPR^O38 in MSH-9 marks a population/location-based observation response. MSA carries AA in MSA-1 — application accept — and echoes the original request's control id OPL00045 in MSA-2, correlating the response with the OPL it answers. PID and PD1 identify the patient the echoed order applies to. ORC carries order control OK (accepted) with placer order PLAC987654 and filler order FILL654321, and OBR echoes the Hemoglobin A1C request. OBX confirms one accepted observation — A1C value 6.8 %, flagged H (high) against the reference range 4.0-5.6, final status F — and SPM names the specimen SPEC456789 as serum collected at the observation time. Together they tell the original OPL sender that the request was accepted in full, the order is on file, and the observation has been recorded.
Working with OPR messages
Read the acknowledgement in MSA before processing the body
MSA-1 reports whether the request was accepted (AA), accepted with application-level issues (AE), or rejected (AR). Process the RESPONSE group only when the acknowledgement permits — an AR should not be treated as a partial accept, and an AE should be reconciled against the ERR segments before the echoed orders are trusted as on-file at the receiver.
Correlate on MSA-2, not MSH-10
MSA-2 echoes the message control id of the original OPL, and that is the field the OPL sender uses to match the response to its request. MSH-10 on the OPR is the receiver's own control id for the response message — useful for deduplication on the OPR side but not for request-response correlation. Mixing the two leads to orphaned requests and double-applied responses.
Itemise problems on ERR, not on MSA
When the receiver has accepted the request with issues, ERR carries one segment per discrete problem — the location in the original message, the application error code, and the diagnostic text. MSA-1 only carries the overall verdict (AE), so a response with several issues will repeat ERR rather than expand MSA. Process every ERR rather than treating an AE as a single error.
Treat the RESPONSE group as confirmation, not as fresh data
The echoed ORC, OBR, OBX, and SPM segments confirm what the receiver has accepted, not new observations the receiver has produced. Match each echoed order against the order in the original OPL by placer order number rather than reloading the response as if it were an OPU result update.
Vendor variance. OPR was added in HL7 v2.8 and is not present in v2.5.1, so support is uneven — some partners on v2.8 implement OPR alongside
OPL, others substitute a general acknowledgement (ACK) or anORLlab order response, and v2.5.1 partners do not emit OPR at all. The depth of the echoed RESPONSE group also varies — some senders echo onlyMSAandERR, others echo every order and observation from the request. Confirm a partner's version and message usage against their interface specification rather than assuming the base standard.
FHIR equivalent
A population/location-based observation response corresponds, conceptually, to a FHIR OperationOutcome carrying the acknowledgement and any application-level issues, together with echoed ServiceRequest and Observation resources for the order and observation content, with a MessageHeader at the head of a Bundle when carried as a messaging exchange.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for OPR_O38, and population- and location-scoped acknowledgement messaging sits at the edge of the IG's coverage. A FHIR representation produced from an OPR message is therefore composed manually, taking the acknowledgement code and control id from MSA into an OperationOutcome, the issue detail from ERR into OperationOutcome issues, and the echoed ORC/OBR/OBX/SPM content into ServiceRequest, Observation, and Specimen resources. In most production integrations the OPR stays on the v2 channel.
Common pitfalls
Pitfall. Treating an OPR as proof of a v2.5.1 feed. OPR was introduced in HL7 v2.8 and does not exist in v2.5.1; a partner claiming v2.5.1 cannot legitimately send
OPR^O38. If you see one on a feed declared as v2.5.1, the version declaration inMSH-12is wrong or the partner is on v2.8 in practice.
Pitfall. Correlating the response on
MSH-10instead ofMSA-2.MSH-10is the OPR's own control id;MSA-2carries the originalOPL's control id. Matching on the wrong field leaves the original request unacknowledged in the sender's queue.
Pitfall. Ignoring
ERRwhenMSA-1isAE. AnAEis a header-level verdict; the actual problems are listed one perERR. Acting on the accept and discarding the errors lets bad codes, unknown identifiers, and missing fields slip into the receiving system silently.
How Vorro handles OPR messages
Vorro routes each OPR back to the original OPL sender, correlates the response on the control id echoed in MSA-2, surfaces the acknowledgement code in MSA-1, and itemises every ERR segment against the original request for operator review. Vorro reconciles the echoed RESPONSE group — PID, ORC, OBR, OBX, SPM — against the orders carried in the original OPL, flags partners declaring v2.5.1 but sending OPR^O38 (a version mismatch that needs resolving on the partner side), and, where a FHIR destination is configured, maps the response to an OperationOutcome together with the echoed ServiceRequest, Observation, and Specimen resources — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- OPL — the population/location-based observation request that an OPR acknowledges.
- OPU — the unsolicited population/location-based observation update that carries observation content the receiver has produced rather than acknowledged.
- ORL — the general laboratory order response, used outside the population- and location-scoped flow to acknowledge an
ORMorOMLorder.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for OPR_O38
- HL7 v2-to-FHIR IG — segment maps index — confirms no published ConceptMap specific to the OPR response structure
- HL7 Messaging Standard Version 2.8 product brief
