NEWFree ROI Calculators — quantify what prior auth and siloed data are costing your organization.Prior Auth ROI Siloed Data ROI
HL7 v2Message13 min read

HL7 OPL Messages: Population/Location-Based Laboratory Observation

HL7 OPL messages carry laboratory observations scoped to a population or a location rather than to a single patient — the results of public-health surveillance runs, environmental sampling sweeps, wastewater monitoring, and other lab work where the thing being observed is a cohort or a place rather than an individual. An OPL message is the population- or location-shaped sibling of the per-patient lab result: an ordering or surveillance system sends one OPL to a laboratory or public-health receiver with one or more PATIENT groups (where each "patient" may instead be a population or location surrogate), each carrying its ORDER and OBSERVATION groups, and the receiver files the observations against the cohort or site they describe. OPL 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 OPL message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an OPL relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an OPL message represents

An OPL message — OPL stands for Population/Location-Based Laboratory Observation — communicates laboratory observations whose subject is a population (a cohort under surveillance, a defined group sampled together) or a location (a building, a water source, a sampling site) rather than an individual patient. The core of the message is the pairing of an order in OBR, which names the universal service identifier and the observation date/time, with one or more OBX segments that carry the observed values, and a SPM that identifies the specimen — which in an OPL is frequently environmental (a water sample, an air sample, a surface swab from a facility) rather than patient-derived.

OPL 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. OPL reuses the familiar lab order-and-result shape from the OPR/OPU/OUL family but re-scopes the subject. Each repeating PATIENT group is opened by PID, where in an OPL the "patient" identifier is a surrogate standing in for a population cohort or a location identifier; the ORDER group inside it carries ORC and OBR; and the OBSERVATION group inside that carries OBX results and the SPM that pins them to a specimen. The sender is typically a public-health laboratory, an environmental sampling system, or a surveillance LIS; the receiver is a public-health agency, a surveillance data hub, or a reference laboratory.

When an OPL message is sent

An OPL message is sent whenever a laboratory needs to report observations against a population or location rather than against a single patient — a wastewater pathogen surveillance run reporting against a sewershed, an environmental sampling sweep reporting against a building, a public-health cohort screening reporting aggregate or population-keyed observations. It is event-driven and, in surveillance contexts, often scheduled: each sampling cycle produces an OPL describing what was found at each population or location surrogate. OPL sits in the OPR/OPU/OUL family of laboratory observation messages introduced in HL7 v2.8.

Trigger event

The OPL message type carries a single trigger event:

  • OPL^O37 – Population/location-based laboratory observation.

Because OPL has one trigger event, the receiver's handling turns on the universal service identifier in OBR and the specimen and subject context in SPM and PID — what was tested, on what specimen, drawn from which population or location — rather than on the trigger code in MSH-9.

Integration topology

The diagram shows a public-health or environmental laboratory issuing an OPL through the integration engine to a surveillance data hub, which files the observations against the cohort or site they describe.

{{diagram: public-health / environmental laboratory → OPL observation → integration engine → surveillance data hub / public-health agency}}

Typical senders: public-health laboratory information system, environmental sampling system, wastewater surveillance LIS, reference laboratory reporting population-scoped runs.

Typical receivers: public-health agency surveillance hub, environmental monitoring data warehouse, epidemiology reporting platform.

Direction: unsolicited from the laboratory to the surveillance receiver — the OPL travels outbound carrying the observation set, and an acknowledgement (ACK) returns.

Segments in an OPL message

The OPL_O37 message opens with MSH, an optional software detail and user authentication, optional notes, and then one or more PATIENT groups. Each PATIENT group opens with PID — where the "patient" identifier may stand in for a population or location — and carries demographics, next-of-kin, guarantor, and insurance context, then one or more ORDER groups. Each ORDER group opens with ORC and OBR and carries one or more OBSERVATION groups, each opened by OBX and optionally followed by notes, participation, and one or more SPM specimen segments — each of which may carry its own nested OBX results. 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.

SegmentDescription
MSHMessage Header. Opens every OPL message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in MSH-9 (OPL^O37), carries the message control id in MSH-10, and pins the HL7 version (2.8). Receivers route on MSH-9 and deduplicate on MSH-10.
[{SFT}]Software Segment. Identifies the sending software — vendor, certified version, binary id, install date. Optional and repeating; used where the receiver tracks software provenance for surveillance or regulatory reporting.
[UAC]User Authentication Credential. Carries user authentication credentials for the sending session. Optional, used where the receiver requires per-message authentication context.
NTENotes and Comments. Message-level notes — context that applies to the OPL as a whole rather than to a single observation. Required at this position in the OPL_O37 abstract message.
PIDPatient Identification. Opens each PATIENT group. In OPL, PID-3 carries the surrogate identifier for the population or location being observed — a cohort id, a sampling-site id, a sewershed id — rather than a real patient mrn. Required, and the PATIENT group repeats so one OPL can carry observations for several cohorts or sites.
[PD1]Patient Additional Demographics. Additional demographic context for the subject. Optional; rarely populated for true population or location surrogates and more often used where the cohort has a registered representative.
[PRT]Participation. Names participants associated with the subject — investigator, sampling officer, responsible epidemiologist. Optional.
[{NK1}]Next of Kin / Associated Parties. Associated parties for the subject. Optional and repeating; in population or location contexts this is typically a contact for the cohort or site (a facility manager, a public-health liaison) rather than a clinical next-of-kin.
[{NTE}]Notes and Comments. Patient-group-level notes scoped to this cohort or location. Optional and repeating.
[{GT1}]Guarantor. Financial guarantor information. Optional and repeating; usually empty in surveillance and environmental reporting and present only where a billable party is attached to the run.
[{ INSURANCE }]Insurance group. Optional and repeating. Opens with IN1 (insurance) and may carry IN2 (additional insurance information) and IN3 (certification). Typically empty for population and location subjects.
ORCCommon Order. Opens each ORDER group inside the PATIENT group. Carries the order control code, placer and filler order numbers, order status, and entry context. Required. The ORDER group repeats so one PATIENT group can carry several orders.
[PRT]Participation. Order-level participants — the ordering officer, the receiving laboratory. Optional.
OBRObservation Request. Names the universal service identifier in OBR-4 (what was tested — the assay, the panel, the surveillance target) and the observation date/time in OBR-7. Required, and the heart of the ORDER group together with OBX.
[{TQ1, [{TQ2}]}]Timing/Quantity, with optional Relationship. Timing for the observation request — sample cadence, run schedule, duration of the surveillance window. Optional and repeating; each TQ1 may carry one or more TQ2 segments expressing relationships to other timed requests.
[{NTE}]Notes and Comments. Order-level notes. Optional and repeating.
OBXObservation/Result. Opens each OBSERVATION group. Carries one observation — the observation identifier in OBX-3, the value in OBX-5, units in OBX-6, reference range in OBX-7, abnormal flags in OBX-8, and the observation date/time in OBX-14. Required, and the OBSERVATION group repeats so one ORDER can carry many observed values.
[{NTE}]Notes and Comments. Observation-level notes scoped to a single OBX. Optional and repeating.
[{PRT}]Participation. Observation-level participants — the analyst, the verifying scientist. Optional and repeating.
[{SPM, [{OBX}]}]Specimen, with optional nested observations. Identifies the specimen the observation applies to. In OPL the specimen is frequently environmental rather than patient-derived — a water grab, an air filter, a surface swab — and is named in SPM-2 with type and collection context in the rest of the segment. Each SPM may carry one or more nested OBX segments that describe the specimen itself (volume, temperature at collection, container condition). Optional and repeating.

[ ] = optional, { } = repeating

The PATIENT group, the ORDER group inside it, and the OBSERVATION group inside that all repeat, so a single OPL can carry several cohorts or sites, each with several runs, each with many observed values. The canonical segment pages carry the full field-by-field detail.

Sample OPL message

Note. Constructed for illustration. Site identifiers, specimen identifiers, observation identifiers, and dates are fictional.

MSH|^~&|PH_LAB|STATEPH|SURV_HUB|STATEPH|202606040930||OPL^O37^OPL_O37|MSG00091|P|2.8
NTE|1||Wastewater surveillance run, sewershed cohort SS-NORTH-04
PID|1||SS-NORTH-04^^^STATEPH^PL||SEWERSHED^NORTH-04^^^^^L|||U
PRT|1|AD||RP^Responsible Party^HL70912|EPI001^HARRIS^MORGAN^^^^^^STATEPH
ORC|RE|ORD-770042|FIL-880042||CM|||||202606040800|||EPI001^HARRIS^MORGAN
OBR|1|ORD-770042|FIL-880042|SARS2-WW^SARS-CoV-2 wastewater RT-PCR^L|||202606040800|||||||||EPI001^HARRIS^MORGAN
OBX|1|NM|SARS2-N1^SARS-CoV-2 N1 gene copies/L^L||185000|copies/L^copies per litre^UCUM|<10000|H|||F|||202606040800
OBX|2|NM|PMMV^Pepper mild mottle virus^L||4.2E7|copies/L^copies per litre^UCUM|||N|||F|||202606040800
SPM|1|SPEC-WW-660031^STATEPH||WW^Wastewater^L|||||||||||||202606040800
OBX|1|NM|VOL^Sample volume^L||500|mL^millilitres^UCUM|||N|||F

What this sample shows

The OPL^O37 in MSH-9 and the 2.8 version in MSH-12 mark a population/location-based laboratory observation in the v2.8 form. PID carries the location surrogate SS-NORTH-04 — a sewershed identifier — in PID-3 rather than a patient mrn, with the corresponding name field naming the sampling site. ORC and OBR open the order: SARS2-WW is the universal service identifier in OBR-4, with the observation date/time 202606040800 in OBR-7. The two top-level OBX segments carry the observed values — 185000 copies/L of the SARS-CoV-2 N1 gene, flagged high against a <10000 reference, and 4.2E7 copies/L of the PMMV faecal-strength normaliser. SPM identifies the specimen SPEC-WW-660031 as wastewater, and the nested OBX under it describes the specimen itself — a 500 mL sample volume. The whole message reports against a sewershed location, not a person.

Working with OPL messages

Read PID-3 as a population or location surrogate

In an OPL the value in PID-3 is the cohort or site identifier — a sewershed id, a building id, a sampling-site code, a population stratum — and the corresponding name field describes that subject. Receivers must resolve PID-3 against a population or location registry rather than a patient master index; treating it as an mrn drops the observation into the wrong domain entirely.

Anchor on OBR-4 and OBR-7

The universal service identifier in OBR-4 says what was tested — the assay, the surveillance target, the environmental analyte — and the observation date/time in OBR-7 says when. Surveillance receivers index on these two fields to align observations into a time series for each cohort or location; without them the values are uninterpretable.

Treat the specimen in SPM as potentially environmental

In OPL the SPM specimen is often environmental rather than patient-derived — a wastewater grab, an air filter, a surface swab, a soil core. The specimen type and collection context drive how the observation is normalised and compared. Read SPM-4 (specimen type) before applying clinical reference ranges, and use the nested OBX segments under SPM for sample-level metadata (volume, temperature, container) when present.

Carry context with NTE and PRT, not in the PID surrogate

The cohort or site description belongs in NTE (run-level notes), in PRT (the responsible epidemiologist or sampling officer), and in the location or population registry the PID-3 surrogate points to — not crammed into the surrogate identifier itself. Keep the identifier short and resolvable; put the descriptive content where the receiver expects to find it.

Vendor variance. The conventions for encoding a population or a location into PID-3 vary by jurisdiction and by surveillance programme. Some senders use a structured assigning-authority namespace (SS-NORTH-04^^^STATEPH^PL) while others repurpose the patient identifier list more loosely. Confirm a partner's surrogate scheme — the namespace, the identifier-type code (PL for location, programme-specific codes for cohorts), and any companion segments — against their interface specification rather than assuming a single convention.

FHIR equivalent

A population- or location-based laboratory observation corresponds, conceptually, to a FHIR DiagnosticReport carrying one or more Observation resources whose subject is a Group (for a population or cohort) or a Location (for a sampling site), with supporting Location and Group resources composed into a Bundle.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for OPL_O37, and population- and location-scoped lab observations sit at the edge of FHIR's clinical resource model — FHIR's Observation resource defaults to a Patient subject, and Group- and Location-subject Observations require deliberate composition. A FHIR representation produced from an OPL message is therefore composed manually, taking the surrogate from PID into either a Group or a Location reference, the order from OBR into the DiagnosticReport, the values from OBX into Observations, and the specimen from SPM into a Specimen resource flagged as environmental where appropriate. In most production surveillance integrations the OPL stays on the v2 channel.

Common pitfalls

Pitfall. Filing the PID-3 surrogate into a patient master index. The identifier in an OPL PID-3 names a population or a location, not a person; resolving it against the EHR's patient index pollutes the index and loses the surveillance subject entirely.

Pitfall. Applying clinical reference ranges to environmental specimens. A wastewater pathogen count compared against a human serum reference range is meaningless. Read the specimen type in SPM-4 before normalising; OPL observations need surveillance- and environment-specific reference frames.

Pitfall. Confusing OPL with the per-patient lab result messages. OPL is the population/location form introduced in HL7 v2.8; teams running v2.5.1 feeds will not encounter it. Treating an OPL trigger the way an OUL would be treated routes the message through the wrong pipeline.

How Vorro handles OPL messages

Vorro routes each OPL from the sending laboratory to the surveillance receiver, resolves the surrogate in PID PID-3 against a population or location registry rather than the patient master index, anchors each observation on the universal service identifier in OBR OBR-4 and the observation date/time in OBR-7, reads the specimen type in SPM SPM-4 and treats environmental specimens distinctly from patient-derived ones, carries cohort and site context through NTE and PRT, and, where a FHIR destination is configured, maps the message to a DiagnosticReport with Observations whose subject is a Group or Location — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message. Because OPL is a v2.8 construct, Vorro will only emit and accept it on feeds negotiated at v2.8 or later; v2.5.1 partners do not see this message.

  • OPR — population/location-based laboratory observation response, the response counterpart in the v2.8 OPR/OPU/OPL family.
  • OPU — unsolicited population/location-based laboratory observation, the unsolicited update form alongside OPL.
  • OUL — unsolicited laboratory observation for a single patient subject, the per-patient sibling that OPL re-scopes to populations and locations.

Sources

← Back to HL7 v2 Guide

Ready to Integrate This Into Your Workflow?

Talk to a Vorro expert about implementing HL7 v2 in your specific environment.

Browse HL7 v2 Guides
HL7 OPL Messages: Population/Location-Based Laboratory Observation | Vorro Academy | Vorro