HL7 ORA Messages: Observation Report — Annotated

HL7 ORA messages carry an observation report together with the human annotations that interpret it — the narrative notes a pathologist, radiologist, or reviewing clinician attaches to specific result values to explain, qualify, or flag them. An ORA message is a result delivery message in the same family as ORU and ORF, but its distinguishing feature is the OBSERVATION_ANNOTATION sub-group: NTE segments scoped to a specific OBX that hold the annotation for that single result. ORA was introduced in HL7 v2.7 and is not part of v2.5.1; an integration team running v2.5.1 feeds will not see this message. This page documents the v2.7 form. It explains what an ORA message represents, the trigger event that carries it, every segment the message can contain and what each one holds, and how an annotated report relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What an ORA message represents

An ORA message — ORA stands for Observation Report, Annotated — communicates a set of observation results together with annotations bound to those results. ORA was introduced in HL7 v2.7 and is not part of v2.5.1; an integration team running v2.5.1 feeds will not see this message. This page documents the v2.7 form. The core of the message is the pairing of OBR, which identifies the observation request — the universal service identifier, the observation date/time, and the ordering provider — with one or more OBX segments that carry the result values. What sets ORA apart from a plain result message is the OBSERVATION_ANNOTATION sub-group: a run of NTE segments that follows a specific OBX and is scoped to that result, holding the human interpretation or commentary on it.

ORA is a result-delivery message: the producer issues it when results, and the annotations on those results, are ready to be sent. The patient is identified in the optional PATIENT group through PID and its companion segments; the report is structured as a repeating OBSERVATION group, one per requested observation, each carrying its own OBR, results, and annotations. The annotation scoping is the point of the message — an NTE inside the OBSERVATION_ANNOTATION sub-group belongs to the preceding OBX, not to the report as a whole, which lets the producer say "this specific potassium value is hemolysed" or "this image finding is consistent with prior" without the receiver having to guess which result a free-text note applies to.

When an ORA message is sent

An ORA message is sent whenever a producer needs to deliver results along with human annotations bound to specific result values — pathology reports with per-finding commentary, radiology reports with per-image notes, laboratory reports where individual analytes carry interpretive flags. It is event-driven and unsolicited from the producer's side once results are finalised. ORA sits in the v2.7 results message family alongside ORU (unsolicited observation results, the workhorse result message) and ORF (the observation result response to a query); ORA is the one to use when the annotations are first-class and must travel with the results in a structured way.

Trigger event

The ORA message type carries a single trigger event:

• ORA^R33 – Observation report, annotated.

Because ORA has one trigger event, the receiver's handling turns on the structure of the OBSERVATION group — what is being reported in OBR and OBX, and which NTE segments are annotations on which results — rather than on the trigger code in MSH-9.

Integration topology

The diagram shows the result producer issuing an ORA report through the integration engine to the consuming clinical system.

{{diagram: result producer (LIS / pathology / radiology / EHR ancillary) → ORA^R33 annotated report → integration engine → consuming clinical system (EHR, downstream repository, registry)}}

Typical senders: laboratory information system, pathology system, radiology information system, EHR ancillary result module.

Typical receivers: the ordering EHR, a downstream clinical data repository, a registry, or an external clinician's inbox system.

Direction: producer-to-consumer result delivery — the ORA travels from the system that finalised the results and their annotations to the system that displays or stores them.

Segments in an ORA message

The ORA_R33 message opens with MSH, an optional run of software segments and an optional user authentication, then an optional PATIENT group that names the patient and visit, and then one or more OBSERVATION groups. Each OBSERVATION group opens with OBR and carries timing, contact, results, and specimen context for that observation, with the OBSERVATION_INTERPRETATION sub-group holding each OBX and any annotations attached to it. 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.

[ ] = optional, { } = repeating

The OBSERVATION group from OBR onward repeats, so a single ORA message can carry several observations for the same patient or visit in one exchange, each with its own results and per-result annotations. The canonical segment pages carry the full field-by-field detail.

Sample ORA message

Note. Constructed for illustration. Patient identifiers, order numbers, observation identifiers, and dates are fictional.

MSH|^~&|LIS|MERCYGEN|EHR|MERCYGEN|202606040930||ORA^R33^ORA_R33|MSG00091|P|2.7
PID|1||MRN778899^^^MERCYGEN^MR||DOE^JANE^A||19710314|F|||742 EVERGREEN TER^^SPRINGFIELD^IL^62704
PV1|1|O|LAB^^^MERCYGEN||||DR123^WELBY^MARCUS|||||||||||V0044556
OBR|1|ORD20260604001^LIS|ACC20260604001^LIS|CHEM7^Basic Metabolic Panel^LN|||202606040905|||||||||DR123^WELBY^MARCUS||||||202606040925|||F
OBX|1|NM|2823-3^Potassium^LN||5.9|mmol/L|3.5-5.1|H|||F
NTE|1|L|Specimen markedly hemolysed; potassium likely falsely elevated. Recommend redraw before clinical action.|RE^Remark^HL70364
OBX|2|NM|2345-7^Glucose^LN||102|mg/dL|70-99|H|||F
NTE|1|L|Mild fasting hyperglycaemia in keeping with prior trend; no acute concern.|RE^Remark^HL70364
SPM|1|SPEC456789^LIS||SER^Serum^HL70487|||||||||||||202606040905

What this sample shows

The ORA^R33 in MSH-9 marks an annotated observation report under HL7 v2.7. PID and PV1 place the report on patient MRN778899 and visit V0044556. OBR identifies the observation request — the basic metabolic panel CHEM7 (LOINC), ordered by DR123 WELBY, observed at 202606040905, status F (final). Two OBX segments carry the results: a potassium of 5.9 flagged H (above reference range), and a glucose of 102 flagged H. Each OBX is immediately followed by an NTE — the OBSERVATION_ANNOTATION sub-group — that carries the human annotation for that specific result: the potassium note flags hemolysis and recommends a redraw; the glucose note interprets the value in the context of prior trend. The trailing SPM names the specimen the panel was performed on.

Working with ORA messages

Treat NTE position as load-bearing

ORA's value depends on the receiver honouring NTE scope. An NTE after an OBX belongs to that OBX; an NTE after the OBR belongs to the observation as a whole; an NTE after the PID belongs to the patient. Receivers that flatten all NTE segments to "report comments" lose the annotation binding that is the point of the message. Parse NTE against the segment that immediately precedes it and store the link.

Confirm the v2.7 baseline with the partner

ORA was added in HL7 v2.7 and is not present in v2.5.1. Confirm the partner's HL7 version in MSH-12 and reject — or at minimum quarantine — an ORA^R33 claiming a pre-2.7 version, since a v2.5.1 parser given an ORA will not have a structure definition for it and will mis-parse the OBSERVATION_ANNOTATION sub-group.

Distinguish the annotation NTE from other OBX-level notes

Inside the OBSERVATION_INTERPRETATION sub-group there are two NTE runs — one immediately after the OBX for clarifying remarks, and a second one (the OBSERVATION_ANNOTATION sub-group) further down the group, after PRT and CDO. Both bind to the same OBX, but the OBSERVATION_ANNOTATION run is the formal human interpretation. Where the partner uses both, preserve the order and the source field — NTE-2 source flag and NTE-4 comment type — so downstream displays can render the annotation distinctly from a clarifying remark.

Carry OBX-3 through to the annotation

Because annotations are bound to a specific OBX, the observation identifier in OBX-3 is the join key for any downstream system that stores results and notes separately. Carry OBX-3 (and the result's sub-identifier in OBX-4 where present) onto the annotation record on the way through, rather than relying on segment position alone, so the annotation survives a re-ordering of the persisted result set.

Vendor variance. Producer systems vary in how strictly they place annotations in the OBSERVATION_ANNOTATION sub-group versus in the earlier OBX-level NTE run, and some emit annotations as additional OBX segments of type TX rather than as NTE. Confirm a partner's annotation convention against their interface specification rather than assuming the base v2.7 structure.

FHIR equivalent

An annotated observation report corresponds, conceptually, to a FHIR DiagnosticReport that references one Observation resource per OBX, with each per-result human annotation carried in Observation.note on the relevant Observation.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide provides no message map for ORA_R33 — the IG's published message maps focus on the older result and order message types — so a FHIR representation produced from an ORA message is composed manually. The patient identifiers in PID become a Patient reference, the order metadata in OBR becomes the DiagnosticReport, each OBX becomes an Observation, and the OBSERVATION_ANNOTATION NTE segments are mapped onto Observation.note on the matching Observation — keyed on OBX-3 rather than on segment position so the binding survives serialisation. Report-level NTE runs map onto DiagnosticReport.conclusion or DiagnosticReport.presentedForm depending on whether they are textual commentary or a rendered narrative.

Common pitfalls

Pitfall. Treating an ORA like an ORU and flattening every NTE to report-level comments. The OBSERVATION_ANNOTATION sub-group binds an NTE to a specific OBX — losing that binding strips the message of its reason for existing and produces a report where the reader cannot tell which result the pathologist's remark refers to.

Pitfall. Accepting an ORA^R33 on a v2.5.1 channel. ORA does not exist in v2.5.1; a parser configured for v2.5.1 will not have the OBSERVATION_ANNOTATION structure and will silently mis-attribute annotation NTE segments. Reject on MSH-12 and route ORA traffic only through a v2.7-capable endpoint.

Pitfall. Joining annotations to results by segment position alone. A downstream system that re-orders observations on storage and then re-emits them loses the position-based binding. Carry OBX-3 (and OBX-4 where the sub-identifier is in use) onto every annotation record on the way through.

How Vorro handles ORA messages

Vorro routes each ORA report from the producer to the consumer under the v2.7 baseline, validates the version in MSH-12 and rejects an ORA^R33 claiming a pre-2.7 version, parses the OBSERVATION_ANNOTATION sub-group as NTE segments bound to the preceding OBX rather than to the report as a whole, carries OBX-3 (and OBX-4 where present) onto the annotation record so the binding survives downstream re-ordering, preserves the distinction between OBX-level clarifying NTE runs and the formal OBSERVATION_ANNOTATION run via the source field and comment type in NTE-2 and NTE-4, and, where a FHIR destination is configured, maps the report to a DiagnosticReport with one Observation per OBX and the annotations onto Observation.note — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.

Related messages

• ORU — the unsolicited observation result message, the workhorse result delivery message that carries results without the formal per-result annotation sub-group.
• ORF — the observation result response that returns results in answer to a query rather than as an unsolicited push.
• OUL — the unsolicited laboratory observation message used for laboratory automation result delivery with specimen and container context.

Sources

• HL7 v2-to-FHIR IG — message maps index — confirms no message map for ORA_R33
• HL7 v2-to-FHIR IG — segment maps index — confirms segment-level ConceptMap coverage for OBR, OBX, and NTE
• HL7 Messaging Standard Version 2.7 product brief