HL7 OPU messages carry laboratory observations that are scoped to a population or a location rather than to a named patient, and that are pushed without a prior order — the unsolicited counterpart to OPL. An OPU message is the typical shape of a public-health surveillance feed, an environmental monitoring report, or a syndromic surveillance push: a producing system sends results keyed on a population cohort or a geographic location, and the receiver ingests them without ever having placed an order. OPU was introduced in HL7 v2.7 and is not part of v2.5.1; teams running v2.5.1 feeds will not encounter this message. This page documents the v2.7 form. It explains what an OPU message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an OPU relates to FHIR. Sample content is constructed for illustration with fictional identifiers.
What an OPU message represents
An OPU message — OPU stands for Unsolicited Population/Location-Based Observation — communicates one or more observations whose subject is a population or a location, not an individual patient, and which were not preceded by an order. The core of the message is the OBSERVATION group built around OBX, carrying the result values, scoped by an OBR that names the observation request and by a PATIENT-group surrogate in which the PID identifier represents a population cohort, a geographic location, or another non-individual subject rather than a person.
OPU was introduced in HL7 v2.7 and is not part of v2.5.1; teams running v2.5.1 feeds will not encounter this message. This page documents the v2.7 form. The defining feature of the message — what separates it from the rest of the Chapter 7 unsolicited observation family — is that the ORC segment is optional. There need not be a prior order; the producing system is reporting observations on its own initiative against a population or location subject. The sender is typically a public-health laboratory, an environmental monitoring system, or a syndromic surveillance feed; the receiver is a public-health agency, a surveillance hub, or an integration engine fronting one of those.
When an OPU message is sent
An OPU message is sent whenever observations need to be reported against a population cohort or a location without an order having been placed — a weekly count of positive influenza tests from a sentinel site, a water-quality reading from a monitored location, a syndromic surveillance roll-up from an emergency department feed. It is event-driven and unsolicited: the producer pushes the result when it is ready. OPU is paired conceptually with OPL (the population/location-based observation request) and sits alongside the broader unsolicited observation set, of which OUL is the per-patient analogue.
Trigger event
The OPU message type carries a single trigger event:
OPU^R25– Unsolicited population/location-based observation.
Because OPU has one trigger event, the receiver's handling turns on the contents of OBR and OBX — the observation request and the result values — and on the population or location identifier carried in the PATIENT group, rather than on the trigger code in MSH-9.
Integration topology
The diagram shows a public-health laboratory, environmental monitoring system, or syndromic surveillance feed pushing an OPU through the integration engine to a public-health agency or surveillance hub.
{{diagram: public-health lab / environmental monitor / syndromic feed → OPU^R25 → integration engine → public-health agency / surveillance hub / FHIR endpoint}}
Typical senders: public-health laboratory, environmental monitoring system, syndromic surveillance feed, sentinel-site reporting system.
Typical receivers: public-health agency, state or national surveillance hub, integration engine fronting a surveillance data store, FHIR endpoint accepting Observation resources with Group or Location subjects.
Direction: unsolicited push — the producing system sends the OPU to the surveillance receiver without a prior order or query.
Segments in an OPU message
The OPU_R25 message opens with MSH and a small header block, then carries one or more PATIENT groups, each of which can carry one or more VISIT groups and one or more ORDER groups, each of which carries one or more OBSERVATION groups built around OBX. 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 OPU message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (OPU^R25), carries the message control id in MSH-10, and pins the HL7 version (2.7). Receivers route on MSH-9 and deduplicate on MSH-10. |
[{SFT}] | Software Segment. Identifies the sending software — vendor, product, version, install date — for traceability of the producing system. Optional and repeating; commonly populated on surveillance feeds where the software stack is part of the data provenance. |
[UAC] | User Authentication Credential. Carries a user authentication credential when the message itself needs to attest to who or what authenticated the push. Optional. |
NTE | Notes and Comments. Free-text notes scoped to the message header — provenance, reporting period, surveillance protocol identifier. Required at the message level in OPU. |
| PATIENT group (repeating) | One or more population or location subjects. The group repeats so a single OPU can carry observations for several cohorts or locations in one push. |
PID | Patient Identification. In OPU, PID carries the population or location surrogate rather than a person — a cohort identifier, a location identifier, a sentinel-site code, or another non-individual subject. The field semantics are the standard PID fields; the convention is that the identifier names a group or place. Required within the group. |
[PD1] | Patient Additional Demographic. Additional demographic context for the subject; rarely used when the subject is a population or location, but available where the surrogate carries demographic-style attributes. Optional. |
[PRT] | Participation. A participating party at the subject level — for example, the steward of a location or the contact for a cohort. Optional. |
[{NK1}] | Next of Kin / Associated Parties. Associated parties for the subject; in population/location use, typically repurposed to carry an associated authority or contact for the cohort or location. Optional and repeating. |
| VISIT group (optional, repeating) | Visit context for the subject when relevant — for instance, an emergency-department encounter that anchors a syndromic surveillance reading. Optional. |
[PV1] | Patient Visit. Visit-level context — facility, location, encounter identifiers — when the observations are scoped to a specific encounter. Optional. |
[PV2] | Patient Visit – Additional Information. Additional visit attributes. Optional. |
[{PRT}] | Participation. Participating parties at the visit level. Optional and repeating. |
| ORDER group (repeating) | One or more orders carrying the observations. The group repeats so a single OPU can carry several observation requests for the same subject. |
[ORC] | Common Order. The order header — placer and filler order numbers, status, ordering provider. In OPU, ORC is optional: an unsolicited population or location observation need not be backed by a prior order, and many surveillance feeds omit it entirely. When present, it carries enough order context to relate the result to an upstream record. |
[PRT] | Participation. Participating parties at the order level. Optional. |
OBR | Observation Request. Names the observation or panel being reported — the universal service identifier in OBR-4, the observation date/time, the producer, and the result status. Required, and the anchor of the order group; the subsequent OBX segments are the observations belonging to this OBR. |
[{NTE}] | Notes and Comments. Notes scoped to the observation request. Optional and repeating. |
[{TQ1[{TQ2}]}] | Timing/Quantity. Timing for the request — reporting period, collection interval. Optional and repeating; TQ2 carries the relationship to a parent timing record. |
[{TIMING_QTY}] | Timing/Quantity group. A grouped timing block at the order level for legacy timing patterns. Optional and repeating. |
[{CTD}] | Contact Data. Contact information for the producer or reporting party. Optional and repeating. |
| OBSERVATION group (repeating) | One or more observations against the order. The group repeats so a single OBR can carry many OBX results. |
OBX | Observation/Result. Carries the observation itself — value type, identifier, observation value, units, reference range, abnormal flags, observation status, observation date/time. Required, and the load-bearing segment of the message; the surrounding segments scope it. |
[{PRT}] | Participation. Participating parties at the observation level — for example, the analyst or the device. Optional and repeating. |
[{NTE}] | Notes and Comments. Notes scoped to the observation. Optional and repeating. |
[{SPM[{OBX}]}] | Specimen. Identifies the specimen the observation applies to, with optional nested OBX segments carrying specimen-level observations. Optional and repeating; many population and environmental observations omit SPM because they are not specimen-based. |
[{FT1}] | Financial Transaction. Financial detail for the observation. Optional and repeating; rare in surveillance feeds. |
[{CTI}] | Clinical Trial Identification. Clinical trial context for the observation. Optional and repeating; used where the surveillance feed is also a study feed. |
[ ] = optional, { } = repeating
The PATIENT group, the VISIT group inside it, the ORDER group, and the OBSERVATION group inside the order all repeat, so a single OPU can carry many observations across many cohorts or locations in one message. The canonical segment pages carry the full field-by-field detail.
Sample OPU message
Note. Constructed for illustration. Population and location identifiers, observation identifiers, and dates are fictional.
MSH|^~&|SURVEIL_LAB|STATE_PH|SURVEIL_HUB|CDC|202606040900||OPU^R25^OPU_R25|MSG00091|P|2.7
SFT|VorroSurveil|3.2.0|SurveilPush|3.2.0.1023|20260101
NTE|1||Weekly sentinel-site influenza positivity roll-up; reporting period 2026-W22
PID|1||COHORT-SENTINEL-07^^^STATE_PH^PL||SentinelSite^Region07||||||||||||||||
OBR|1|||FLU-POS-RATE^Influenza positivity rate^L|||202606040900|||||||||||||||F
OBX|1|NM|FLU-POS-RATE^Influenza positivity rate^L||7.4|%^percent^UCUM|||||F|||202606040900
OBX|2|NM|FLU-TESTS-TOTAL^Total influenza tests^L||1284|{count}^count^UCUM|||||F|||202606040900
OBX|3|NM|FLU-TESTS-POS^Positive influenza tests^L||95|{count}^count^UCUM|||||F|||202606040900
What this sample shows
The OPU^R25 in MSH-9 marks an unsolicited population-based observation, and MSH-12 pins the version at 2.7. SFT records the producing software for provenance, and NTE at the message level names the reporting period. PID carries the population surrogate COHORT-SENTINEL-07 rather than a person — the cohort identifier for sentinel-site region 07 — and there is no ORC: no order was placed, the producer is pushing the roll-up on its own initiative. OBR names the observation request as influenza positivity rate at 202606040900, and the three OBX segments carry the positivity rate (7.4%), the total test count (1,284), and the positive count (95) for the period. No SPM is present — these are population-scoped observations, not specimen-scoped ones.
Working with OPU messages
Treat PID as a population or location surrogate, not a person
In OPU, PID-3 carries a cohort, location, sentinel-site, or other non-individual identifier. Validators and downstream patient indices built for clinical messaging will reject these identifiers if they expect a person; route OPU through a surveillance pipeline that recognises a population or location subject, or normalise the identifier into a Group or Location reference before persisting.
Do not require ORC
Unlike OUL and the rest of the Chapter 7 observation family, OPU's order group makes ORC optional. A surveillance feed will routinely omit it. Receivers that hard-require an ORC for every observation will reject valid OPU messages; treat ORC as optional and key the observation on OBR and OBX instead.
Anchor the reporting period in OBR-7 (and NTE)
A population observation is meaningful only against a window — the week, the day, the monitoring interval. Read the observation date/time in OBR-7 and, when present, the period narrative in NTE, and store the window alongside the result. A 7.4% positivity rate with no period is data without context.
Carry the producing software in SFT
Surveillance data is provenance-sensitive, and SFT is the standard carrier for the producing software stack. Populate it on outbound OPU and persist it on inbound — investigators downstream will want to know which version of which system produced a reading.
Vendor variance. Because OPU was introduced in HL7 v2.7, support is uneven: not every interface engine, LIS, or surveillance hub parses or emits OPU, and some sites use older patterns — including
ORU^R01with a population identifier inPID— to carry the same payload. Confirm a partner's version support and field usage against their interface specification rather than assuming the base v2.7 standard.
FHIR equivalent
A population- or location-scoped unsolicited observation corresponds, conceptually, to a FHIR Observation resource (or a Bundle of them) whose subject references a Group for a cohort or a Location for a place, rather than a Patient. When carried as a messaging exchange, a MessageHeader sits at the head of the Bundle.
There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for OPU_R25, and the segment maps for PID assume a person subject rather than a population or location surrogate. A FHIR representation produced from an OPU message is therefore composed manually: the PID identifier is resolved to a Group or Location reference, the OBR and OBX segments are mapped into Observation resources in the standard way, and the NTE reporting-period narrative is carried into the Observation's effectivePeriod. In most production integrations the OPU stays on the v2 channel and is mapped only at the surveillance boundary.
Common pitfalls
Pitfall. Routing OPU through a clinical patient index. The
PIDcarries a population or location surrogate, not a person; a patient index built for clinical messaging will reject the identifier or, worse, silently match it to a real patient with a similar id.
Pitfall. Hard-requiring
ORC. OPU is unsolicited;ORCis optional and routinely absent. A receiver that rejects an OPU becauseORCis missing is rejecting valid surveillance traffic.
Pitfall. Dropping the reporting period. The
OBR-7observation date/time and theNTEperiod narrative are what make a population observation interpretable; persisting the value without the window strips the meaning.
Pitfall. Assuming v2.5.1 compatibility. OPU was introduced in v2.7 and does not exist in v2.5.1; a feed pinned to v2.5.1 in
MSH-12cannot carry an OPU, and a partner running v2.5.1 will not accept one.
How Vorro handles OPU messages
Vorro recognises OPU as a v2.7-introduced message, parses the population or location surrogate in PID without forcing it through a clinical patient index, treats ORC as optional so unsolicited surveillance traffic is not rejected, persists the reporting window from OBR-7 and the NTE narrative alongside each result, preserves the producing software stack from SFT for provenance, and, where a FHIR destination is configured, maps the message to a Bundle of Observation resources with a Group or Location subject — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.
Related messages
- OPL — the population/location-based laboratory order, the request-side counterpart to OPU.
- OPR — the population/location-based observation response, used where a response to an OPL is required.
- OUL — the unsolicited laboratory observation message for per-patient observations, the patient-scoped analogue to OPU.
Sources
- HL7 v2-to-FHIR IG — message maps index — confirms no message map for OPU_R25
- HL7 v2-to-FHIR IG — segment maps index — confirms no published ConceptMap covering PID used as a population or location surrogate
- HL7 Messaging Standard Version 2.7 product brief
