4 Observation Reporting

4.1 Purpose

This section describes the transaction set required for sending structured patient-oriented clinical data from one computer system to another. A common use of these transaction sets will be to transmit observations and results of diagnostic studies from the producing system (e.g., clinical laboratory system, Radiology system) (the filler), to the ordering system (e.g., GP Surgery, specialists office system) (the placer). However, the transaction set is not limited to such transactions. Observations can be sent from producing systems to archival medical record systems (not necessarily the order placer) and from such medical record systems to other systems that were not part of the ordering loop, e.g., an office practice system of the referring physician for inpatient test results ordered by an inpatient surgeon. These transaction sets permit the transmission of any kind of clinical observations including (but not limited to) clinical laboratory results, the results of imaging studies (excluding the image), Pulmonary function studies, measures of patient status and condition, vital signs, intake and output, severity and/or frequency of symptoms, drug allergies, problem lists, diagnostic lists, physician and nursing history, physicals, progress notes, operative notes and so on. An observation can be one of many data types. The main ones are text, numbers and codes. This provides the flexibility needed to transmit observations that are recorded as continuous values (e.g., glucose, diastolic blood pressure), as categorical values, e.g., patient position (sitting, reclining or standing), VDRL (reactive, weakly reactive or nonreactive), or as text. An entire History and Physical could be transmitted as an observation whose value is one large chunk of formatted text.

This section provides mechanisms for transmitting structured, record-oriented reports. This means that individual observations are transmitted as separate logical entities (objects), and within this entity, separate fields are defined for identifying the observation, its values, its units, normal ranges, etc., such that the receiving system can “understand,” reorganize and/or react to the contents of these messages. 

Observations may be transmitted in a solicited (in response to a query) or unsolicited mode. In the solicited mode, a user requests a set of observations according to criteria transmitted by the user. The sending system responds with existing data to satisfy the query (subject to access controls). Queries do not elicit new observations by the target system, they simply retrieve old observations. (The query message is covered in the International standard but is not covered in this guide) The unsolicited mode is used primarily to transmit the values of new observations. It is the mode used by Laboratories to return the values of observations requested by an ordering provider/system. A laboratory system, for example, would usually send the results of an morning electrolytes to the ordering system via the unsolicited mode. Calling such transactions unsolicited may sound like a misnomer, but is not. The placing service solicits the producing service to make the observation. It could also (through a query) solicit the value of that observation after it has been made. However, such an approach would demand continuous polling of the producing system until the result was produced. Using the unsolicited mode, the producing service returns the value of an observation as soon as it is available. The unsolicited mode can also be used to transmit new results to a system (e.g., an archival medical record system or copy doctor) that did not order the observation.

Observations are usually ordered and reported as sets (batteries) of many separate observations. Physicians order electrolytes (consisting of sodium, potassium, chloride, bicarbonate) or vitals (consisting of diastolic blood pressure, systolic blood pressure, pulse, and temperature). Moreover, tests that we may think of as single entity, e.g., cardiac echo, usually yield multiple separate measurements, e.g., left ventricular diameter, left atrial diameter, etc. Moreover, observations that are usually reported as text (e.g., the review of systems from the history and physical) can also be considered a set of separately analysable units (e.g., cardiac history, pulmonary history, genito-urinary history, etc.). We strongly suggest that all text clinical reports be broken down into such separate analysable entities and that these individual entities be transmitted as separate OBX segments. Because many attributes of a set of observations taken at one time will be identical, one OBR segment serves as a header for the report and carries the information that applies to all of the individual observations in the set. In the case of ordered observations, the OBR segment is a “turn-around document” like the manual request forms it replaces. It carries information about the order to the producing service; a copy of the OBR with additional fields completed is returned with the observations to the requesting service. Not all observations are preceded by an order. However, all observations whether explicitly ordered or initiated without an order are reported with an OBR segment as the report header.

The OBR segment provides information that applies to all of the observations that follow. It includes a field that identifies a particular battery (or panel or set) of observations (e.g., electrolytes, vital signs or Admission H&P). For simplicity we will refer to the observation set as the battery. The battery usually corresponds to the entity that is ordered or performed as a unit. (In the case of a query, observation sets may be a more arbitrary collection of observations.) The OBX segment provides information about a single observation, and it includes a field that identifies that single observation (e.g., potassium, diastolic blood pressure or admission diagnosis). The codes used in these fields (OBX-3) are usually LOINC codes and standard LOINC codes, units and reference ranges for many common Observations have been specified by the RCPA here.   In the past, local institutions tended to invent their own unique code systems for identifying test and other clinical observations because standard codes were not available. Such local code systems sufficed for transmitting information within the institutions but presented high barriers to pooling data from many sources for research or for building medical record systems. However, standard code systems such as LOINC® and SNOMED now exist for many of these purposes, and we strongly encourage their use in observation reporting. These codes can be sent either as the only code or they can be sent along with the local historic code as the second code system in a CE code.

4.2 Glossary

Placer:
Person or service that requests (places order for) an observation battery, e.g., the physician, the practice, clinic, or ward service, that orders a lab test. The meaning is synonymous with,
and used interchangeably with, requester. See ORC-2-placer order number, Section 4.5.1.2, “Placer order number” of HL7 International V2.4.

Filler:
Person, or service, who produces the observations (fills the order) requested by the requestor. The word is synonymous with "producer" and includes diagnostic services and clinical services and care providers who report observations about their patients. The clinical laboratory is a producer of lab test results (filler of a lab order), the nursing service is the producer of vital signs observations (the filler of orders to measure vital signs), and so on. See ORC-3-filler order number, Section 4.5.1.3, “Filler order number.” of HL7 International V2.4.

Battery:
A set of one or more observations identified as by a single name and code number, and treated as a shorthand unit for ordering or retrieving results of the constituent observations. In keeping with the mathematical conventions about set, a battery can be a single observation. Vital signs, electrolytes, routine admission tests, and obstetrical ultrasound are all examples. Vital signs (conventionally) consist of diastolic and systolic blood pressure, pulse, and respiratory rate. Electrolytes usually consist of Na+, K+, Cl-, and HCO3-. Routine admission tests might contain FBC, Electrolytes, LFTs, and Urinalysis. (Note that the elements of a battery for our purposes may also be batteries). Obstetrical ultrasound is a battery made up of traditional component measurements and the impression, all of which would be returned as separate results when returned to the requestor. A test involving waveform recording (such as an ECG) can be represented as a battery comprised of results of many categories, including digital waveform data, labels and annotations to the data, measurements, and the impression The word battery is used in this specification synonymously with the word profile or panel. The individual observation elements within a battery may be characteristic of a physiologic system (e.g., liver function tests), or many different physiologic systems.

Observation:
A measurement of a single variable or a single value derived logically and/or algebraically from other measured or derived values. A test result, a diastolic blood pressure, and a single chest X-ray impression are examples of observations. In certain circumstances, tracings and images may be treated by HL7 as individual observations and sent as a single OBX. These include waveform data described in Section 7.15, “Waveform – Trigger Events & Message Definitions,” of HL7 International V2.4 and encapsulated data aggregates using the ED data type described in Section 2.9.16, “ED-encapsulated data,” of HL7 International V2.4 (which can represent actual images, audio data, etc.).

4.3 Trigger Events and Message Definitions

The triggering events that follow are all served by the ORU (Observational report – Unsolicited) or the ORF (Observational Report Response) messages in combination with ACK and QRY. Only the ORU message is covered in the Australian localisation and some of the optional segments have been removed.

ORU – unsolicited observation message (event R01)

ORU^R01 Unsolicited Observation Message

The structure documented here differs from the international version as NTE Segments have been removed from under both OBR and OBX segments and SHOULD NOT be used in Australian messages. The PV1 segment is also mandatory, whereas it is optional in the International standard. The optional FTI (Financial Transaction) and CTI (Clinical Trials identification) which are present in the international standard, have also been removed from the ORU Message structure

The CTD segment in this trigger is used to transmit temporary patient contact details specific to this order.

ORU^R01^ORU_R01 Message Structure

The ORU message performs three functions:

1. It returns the filler's status on the tests ordered by the placer.

2. It contains the atomic results in OBX segments which are used to populate the placer's result database.

3. It contains the formatted report e.g. pdf, of how the laboratory intended the results to be presented and to be displayed on the placer's system.

The ORU^R01 message is sent out by the laboratory and in response a ACK^R01 message should be produced to confirm receipt of the ORU message. The structure of the ACK message is as below:

Structure of the ACK^R01^ACK message

The Message ID in the original  MSH from the ORU^R01 message is returned in the MSA -2 Message Control ID to confirm receipt as detailed in section 2.16.8.2 of HL7 International V2.4.

4.4 Segments

The full definitions of many segments required for reporting clinical observations are included in other sections.

4.4.1 OBR – Observation Request Segment

In the reporting of clinical data, the OBR serves as the report header. It identifies the observation set represented by the following atomic observations. It includes the relevant ordering information when that applies. It contains many of the attributes that usually apply to all of the included observations.

When a set of observations is ordered, the order message contains an OBR segment. However, observations can be collected and reported without an antecedent order. When observations are reported, the report message also includes one or more OBR segments. So, the OBR segment is like a turn-around document. Some fields in the OBR segment apply only to the ordering message and some to the reporting message. To those familiar with healthcare procedures, these should be obvious from their names (e.g., transcriptionist or principal result interpreter could only apply to the reporting phase).

The OBR segments confirm the status and completion of the ordered tests back to the placer allowing the placer to check off each test ordered as it is received. The OBR segments do not contain the results or when the results will be available. However, the structure of the OBR and OBX segments in the ORU can reflect the specimen used to determine the results e.g. specimen ID. 

HL7 Attribute Table – OBR – Observation Request