Chapter 7: Observation Reporting
Health Level Seven, Version 2.5.1 © 2007. All rights reserved. Page 7-5
Final Standard. April 2007.
would usually send the results of an AM electrolytes to the ordering HIS via the unsolicited mode. An intensive
care system would send the blood pressures to the same HIS by the same 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) that
did not order the observation. The transactions that define these modes are more fully described in Section7.2,
“Trigger Events & Message Definitions.”
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 analyzable 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 analyzable 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. Alternately, text documents can be encoded as a CDA document and sent within a single
OBX.
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 major segments (OBR, OBX) defined in this chapter, their fields, and the code tables have been defined in
collaboration with ASTM E31.11 with the goal of keeping HL7 observation transmission the same as ASTM E1238
in pursuit of the goals of ANSI HISPP and the Message Standards Developers Subcommittee. (Some sections of
this chapter have been taken with permission directly from the E1238-91 document and vice versa in pursuit of
those goals).
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). Both of these
fields assume master tables that define coding systems (the universe of valid identifying codes) for batteries and
observations, respectively. These tables will usually be part of the producing and sending services application and
(usually) include many other useful pieces of information about the observation or battery. Segments for
transmitting such master file information between systems that produce and systems that use clinical information are
described in Chapter 8.
This Standard does not require the use of a particular coding system to identify either batteries or single observations
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.
In past versions of the HL7 standard, Appendix A to Chapter 7 presented suggestions for constructing clinical codes
from existing procedure code systems such as CPT4. Appendix A is now part of the Implementation Guide and
contains LOINC® codes for most laboratory tests and many common clinical variables and codes for reporting
observations from the laboratory, 12-lead EKG, cardiac echoes, obstetrical ultrasounds, radiology reports, history
- 1
- 2
前往页