7 .Observation Reporting

7

7.1 CHAPTER 7 CONTENTS

7.2 Purpose

This chapter 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, EKG system) (the filler), to the ordering system (e.g., HIS order entry, physician''s office system) (the placer). Observations can be sent from producing systems to clinical information systems (not necessarily the order placer) and from such 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. This chapter also provides mechanisms for registering clinical trials and methods for linking orders and results to clinical trials and for reporting experiences with drugs and devices.

These transaction sets permit the transmission of clinical observations including (but not limited to) clinical laboratory results, measures of patient status and condition, vital signs, intake and output, severity and/or frequency of symptoms.

If the observation being reported meets one or more of the following criteria, then the content would qualify as a medical document management message (MDM) rather than an observation message (ORU). The reader is referred to the MDM message type in Chapter 9.

Documents/reports that require succession management to reflect the evolution of both document addenda and replacement documents. Succession management is described in Chapter 9.

Documents/reports where the Sender wants to indicate the availability of the report for use in patient care using the availability status present in the TXA segment, as described in Chapter 9.

Additional considerations that may affect the appropriateness of using an MDM message:

Documents/reports where the whole requires a signature as part of the message. While the ORU message does not support the inclusion of signature or authentication, some document content forms support these requirements. Of particular note, CDA documents provide for the inclusion of originator/signature. Thus, if a CDA document requires a signature but does not require succession management or report availability (as described above), then an ORU message may be appropriate. However, if the CDA document requires succession management or report availability, then an MDM message is required.

Documents/reports where the whole requires authentication as part of the message. As described for signatures, authentication may exist within the document content form. Again, CDA documents provide for the identification of an authenticator. Thus if a CDA document does not require succession management or report availability, then an ORU message may be appropriate. If succession management or report availability are necessary, then an MDM message is required.

Documents/reports where the content as a whole requires special confidentiality protection using the confidentiality status present in the TXA segment, as described in Chapter 9.

Documents/reports where document storage status is useful for archival and purging purposes using the storage status present in the TXA segment, as described in Chapter 9.

Using these criteria, the following examples of documents/reports would typically qualify as medical document management (MDM) messages. Note that as clinical content, the following documents/reports typically require succession management and/or report availability thus would require an MDM message even if the payload utilizes CSA.

History and Physical

Consultation reports

Discharge summaries

Surgical/anatomic pathology reports

Diagnostic imaging reports

Cardio-diagnostic reports

Operative reports

As an international example, microbiology reports may include clinical interpretation and require authentication. This may not be the case in all jurisdictions, but is an example that the use or requirement of MDM messages may be influenced by local considerations.

Usage Notes:

Transcription is not a defining quality for the selection of an MDM or ORU message. In an MDM message, the document/report is typically dictated or transcribed, but not always. Machine-generated or automated output is an example of a document/report that is appropriate to the MDM but is not transcribed.

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. (See Chapter 5 for full discussion of the query transmission.)

The unsolicited mode is used primarily to transmit the values of new observations. It is the mode used by producing services to return the values of observations requested by an ordering system. A laboratory system, for example, 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 Section 7.3, "General 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? for observation IDs (OBX-3) and SNOMED for coding categorical observations 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 CWE or CNE coded field.

LOINC? codes exist 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 and physical findings, tumor registries, vital signs, intake and outputs, UCUM units of measure references and/or answer lists depending on the data type, and descriptions for most variables. Translations of LOINC? descriptions are provided for more than 14 languages. The most recent version of the LOINC? database, which includes records for more than 70,000 observations and includes codes, names, synonyms and other attributes (such as the molecular weights of chemical moieties) for each observation, the LOINC database and a downloadable browser and mapping tool are available at no cost from the Regenstrief Institute at http://loinc.org/. A web browser for LOINC is available at https://search.loinc.org. Codes for Neurophysiologic variables (EEG, EMG, Evoked potentials) are provided in Appendix X2 of ASTM E1467. Some parts of this document (the discussion and tables defining units, the discussion of the rules of mapping observations to OBX segments, and some of the examples at the end of the chapter) have been copied (with permission) from ASTM E1238.

As is true throughout this Standard, the emphasis should be on the abstract messages, defined without regard to the encoding rules. The example messages, however, are based upon the HL7 encoding rules.

7.2.1 Snapshot Mode

Chapter 2, Section 2.10.4 defines the meaning of snapshot mode updates and indicates that each chapter or related implementation guides may further refine this definition. The following guidance applies to results messages:

In some instances there are tests that have a precise relationship between the parent and child to assist the clinician in understanding to which OBX in the parent OBR the child is connected. In those instances the ORDER_OBSERVATION segment groups of the parent and other children should be included in the snapshot rather than sending the child''s ORDER_OBSERVATION segment group (including the OBR/OBX set) by itself. Example: OBRs of the parent OBR (example would be microbiology with culture and Sensitivity Panels (Sensi-Panels)), unless advised otherwise by trading partners, would be included in the snapshot reporting.?

7.2.2 Preface (organization of this chapter)

Following this Purpose and general information section, the remainder of this chapter is organized into four main subject areas; General, Clinical Trials, Product Experience and Waveform. Sections 7.1 to 7.5 document the trigger events, message definitions, segment definitions and examples for general observation reporting. Sections 7.6 to 7.9 include all information related to Clinical Trials. Sections 7.10 to 7.13 include all information related to Product Experience messaging, and sections 7.14 to 7.17 include Waveform messaging information. Large tables can be found in section 7.18 and outstanding issues are listed in section 7.19.

7.2.3 Glossary

7.2.3.0 hiddentext

7.2.3.1 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, X-ray, vital signs, etc. The meaning is synonymous with, and used interchangeably with, requestor. See ORC-2-placer order number, Chapter 4, section 4.5.1.2, "Placer order number."

7.2.3.2 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, Chapter 2, section 4.5.1.3, "Filler order number."

7.2.3.3 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 CBC, Electrolytes, SMA12, 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 EKG) 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.

7.2.3.4 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," and encapsulated data aggregates using the ED data type described in Chapter 2A, section 2.A.24, "ED - encapsulated data," (which can represent actual images, audio data, etc.).

7.2.3.5 Clinical Document Architecture (CDA):

The Health Level 7 Specification (ANSI/HL7 CDA R1.0-2000) for encoding and encapsulating clinical documents.

7.2.4 Narrative Reports as Batteries with Many OBX

Narrative reports from services such as Radiology usually consist of a number of subcomponents (e.g., a chest X-ray report may consist of a description, an impression, and a recommendation). Other studies, such as echocardiograms, contain analogous components, as well as numeric observations (e.g., left ventricular and diastolic diameter). Surgical pathology reports may contain information about multiple specimens and reports: the anatomic source, the gross description, the microscopic description, and a diagnostic impression for each specimen.

The current Standard treats each component of a narrative report as a separate "test" or observation. Just as a CHEM12 is transmitted as an order segment (OBR) plus 12 OBX segments, a chest X-ray would be transmitted as an order (OBR) segment plus three OBX segments, one for the description, one for the impression, and one for the recommendations. Similarly, an EKG report would be transmitted as an order segment (OBR), two OBX segments for the impression and recommendation, and additional OBX segments for each EKG measurement, e.g., the PR interval, QR interval, QRS axis, and so on.

7.2.5 Suffixes for Defining Observation IDs for Common Components of Narrative Reports

Retained for backwards compatability only as of V2.7 and withdrawn as of v2.9, in favor of using LOINC codes that pre-coordinate the appropriate identifiers with the suffices. See Chapter 2.8.4.c.

7.3 General Trigger Events & Message Definitions

The triggering events that follow are all served by the ORU (Unsolicited Observation Message, Unsolicited Point-of-Care Observation Message, Unsolicited Alert Observation Message), the OUL (Observational Report  Automated Lab), or the OPU (Observational Report - Population) messages in combination with ACK and ORA (Observational Report - Application Acknowledgement). Each triggering event is listed below, along with the messages exchanged, and the segments that comprise the messages. The notation used to describe the sequence, optionality, and repeating of segments is described in Chapter 2, "Format for defining abstract messages."

7.3.1 ORU  Unsolicited Observation Message (Event R01)

The ORU message is for transmitting observational results, including lab, clinical or other observations, to other systems.. The OUL message is designed to accommodate the laboratory processes of laboratory automation systems.

With the segment (OBX) defined in this chapter, and the OBR defined in Chapter 4, one can construct almost any clinical report as a multi-level hierarchy, with the PID segment defined in Chapter 3 at the upper level, an order record (OBR) at the next level with one or more observation records (OBX), followed by the specimen information (SPM) and one or more observations (OBX) directly associated with the specimen.

One result segment (OBX) is transmitted for each component of a diagnostic report, such as an EKG or obstetrical ultrasound or electrolyte battery.

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

The Device segment (DEV) provides additional device information for a device referenced in one or more of the PRT segments in the message (using PRT-10 Participation Device to match DEV-2 Unique Device Identifier or PRT-22 Participation Device Type using DEV-3 Device Type).

Segments

MSH

[{ ARV}]

[{ SFT }]

[UAC]

{  

  [

     PID

     [PD1]

     [{PRT}]

     [{OH1}]

     [{OH2}]

      [OH3]

     [{OH4}]

     [{NTE}]

     [{

       NK1

       [{OH2}]

       [OH3]

     }]

     [{ARV}]

     [{

       OBX

       [{PRT}]

     }]

     [

       PV1

       [PV2]

       [{PRT}]

     ]

     [{

       IN1

      [IN2]

      [IN3]

      }]

   ]

   {

      [

        ORC

        [{PRT}]

        [

         OBX

         [{PRT}]

         TXA

        ]

      ]

      OBR

      [{NTE}]

      [{

        PRT

        [{DEV}]

      }]

      [{

         TQ1

         [{TQ2}]

      }]

      [CTD]

      [{

        OBX

        [{PRT}]

        {[NTE]}

      }]

      [{FT1}]

      {[CTI]}

      [{

        SPM

        [{

          OBX

          [{PRT}]

        }]

      }]

   }   

  [{

    DEV

    [{OBX}]

  }]

}   

[DSC]

Note: The ORC is permitted but not required in this message. Any information that could be included in either the ORC or the OBR must be included in the OBR on reporting. Notice also that the ORU (and the QRY) messages accommodate reports about many patients.

Many report headers (OBR) may be sent beneath each patient segment, with many separate observation segments (OBX) related to the order / observation request beneath each OBR. OBX segments that are related to specimens immediately follow the SPM segments. Note segments (NTE) may be inserted at different locations in the message. The note segment applies to the entity that immediately precedes it, i.e., the patient if it follows the PID segment, the observation request if it follows the OBR segment, and the individual result if it follows the OBX segment.

Segments

MSH

[{ SFT }]

[UAC]

MSA

[{ ERR }]

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

7.3.2 OUL  Unsolicited Laboratory Observation Message (Event R21)

Attention: Retained for backwards compatibility only as of v 2.5 and withdrawn as of v 2.7. ?

7.3.3 QRY/ORF - Query for Results of Observation (Events R02, R04)

Attention: Retained for backwards compatibility only as of v 2. .and withdrawn as of v 2.7.

7.3.4 ORU  Unsolicited Point-Of-Care Observation Message without Existing Order  Place an Order (Event R30)

This event trigger instructs the receiving system to create a new order for the observation(s) contained in the message.

One example of this trigger''s use case occurs when a Doctor verbally instructs a nurse to perform a test. Looking at this use case from an information management perspective, one might expect that, the nurse would enter an order into laboratory information or ordering system before performing the test. However, there usually isn''t time for order entry in these use cases. In fact, it is highly desirable for the POC measurement process to become automated so that the only action a user needs to take is to make a measurement on the POC Device, with all other processes for generating an order and tying it in to the observation handled by the "machines."

In order to allow for the passing of specific information relating to the Patient, responsible Doctor, placing doctor, patient location, etc., there is a requirement for the inclusion of a PV1 and PD1 segment in the ORU message type. One example of this trigger''s use case occurs when a Doctor at a remote site without a shared Patient index instructs a nurse to perform a test. The testing is carried out without prior entry of a request into the LIS. Once performed, the results, along with the patient information are transmitted to the LIS. In some circumstances, the LIS may add clinical interpretation to this and report it back to the placing system and/or another system. In order to allow for this to take place, the requester, location, etc., information is required.

To allow the sending system to correlate every result with its associated order, the receiving system will return the placer order number in the ORC segment of the ORA^R33 message. If the receiving system cannot place an order it must returning an application level error description in the Application Acknowledgement Message MSA Text Message field.

The sending system must return a commit-level acknowledgement in response to the ORA^R33 message.

The Device segment (DEV) provides additional device information for a device referenced in one or more of the PRT segments in the message (using PRT-10 Participation Device to match DEV-2 Unique Device Identifier or PRT-22 Participation Device Type using DEV-3 Device Type).

Segments

MSH

[{ ARV}]

[{ SFT }]

[UAC]

PID

[PD1]

[{PRT}]

[{OH1}]

[{OH2}]

 [OH3]

[{OH4}]

[{ARV}]

[{

OBX

[{PRT}]

}]

[

  PV1

  [PV2]

  [{PRT}]

]

ORC

[{PRT}]

OBR

{[NTE]}

[{PRT}]

[{

  TQ1

  [{TQ2}] 

    }]

{

  OBX

  [{PRT}]

  {[NTE]}

}   

[{

   DEV

   [{OBX]]

}]

Segments

MSH

[{ SFT }]

[UAC]

MSA

[{ ERR }]

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

7.3.5 ORU  Unsolicited New Point-Of-Care Observation Message  Search for an Order (Event R31)

This event trigger instructs the receiving system to search for an existing order for the observation(s) contained in the message.

In this case, the sending system does not know if an order has been placed. This transaction instructs the receiving system to search for an existing order for the associated results. If the receiver finds an existing order, it should return the Placer ID to the sender in the ORC segment of an OML^O21 message. This information allows the Observation Reviewer to correlate every result with its associated order.

The institution''s business rules will determine what the receiving system does if it can''t find a matching order. Possibilities include automatically placing an order (as in trigger event R30), or returning an application level error description in the Application Acknowledgement MSA Text Message field..

If it is necessary to pass specific information related to the Patient, responsible Doctor, placing doctor, patient location etc, there is a requirement for the inclusion of a PV1 and PD1 segment in the ORU message type (see also ORU^R30 for description).

The Device segment (DEV) provides additional device information for a device referenced in one or more of the PRT segments in the message (using PRT-10 Participation Device to match DEV-2 Unique Device Identifier or PRT-22 Participation Device Type using DEV-3 Device Type).

Segments

MSH

[{ARV}]

[{ SFT }]

[UAC]

PID

[PD1]

[{PRT}]

[{OH1}]

[{OH2}]

 [OH3]

[{OH4}]

[{ARV}]

[{

OBX

[{PRT}]

}]

[

  PV1

  [PV2]

  [{PRT}]

]

ORC

[{PRT}]

OBR

{[NTE]}

[{PRT}]

  [{

     TQ1

     [{TQ2}]

  }]

{

  OBX

  [{PRT}]

  {[NTE]}

}   

[{

   DEV

   [{OBX}]

}]

Segments

MSH

[{ SFT }]

[UAC]

MSA

[{ ERR }]

There is not supposed to be an Application Level acknowledgement to an Application LevelAcknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

7.3.6 ORU  Unsolicited Pre-Ordered Point-Of-Care Observation (Event R32)

This event trigger instructs the receiver to place the result with the order information included in the message.

From a traditional clinical laboratory perspective, this event trigger''s use case is probably the predominant (if not exclusive) one. However, in the POC environment, it is actually uncommon to have an order already generated when a test is performed. It does happen sometimes, though. If it is necessary to pass specific information related to the Patient, responsible Doctor, placing doctor, patient location, etc., there is a requirement for the inclusion of a PV1 and PD1 segment in the ORU message type (see also ORU^R30 for description).

If the receiving system accepts both the order and the result, it will return an ORA^R33 Application Acknowledgement message with the acknowledgement code of AA. A comment may be included in the Acknowledgement Message MSA Text Message field.

If the receiving system is unable to accept both the order and the result, no order or result should be placed and an ACK^33 Application Acknowledgement message must be returned to the sender with the error identified in the MSA Text Message field.

The sending system must return a commit-level acknowledgement in response to the ORA^R33 message.

The Device segment (DEV) provides additional device information for a device referenced in one or more of the PRT segments in the message (using PRT-10 Participation Device to match DEV-2 Unique Device Identifier or PRT-22 Participation Device Type using DEV-3 Device Type).

Segments

MSH

[{ARV}]

[{ SFT }]

[UAC]

PID

[PD1]

[{PRT}]

[{OH1}]

[{OH2}]

 [OH3]

[{OH4}]

[{ARV}]

[{

OBX

[{PRT}]

}]

[

  PV1

  [PV2]

  [{PRT}]

]

ORC

[{PRT}]

OBR

{[NTE]}

[{PRT}]

  [{

     TQ1

     [{TQ2}]

  }]

{

  OBX

  [{PRT}]

  {[NTE]}

}   

[{

   DEV

   [{OBX}]

}]

Segments

MSH

[{ SFT }]

[UAC]

MSA

[{ ERR }]

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

7.3.7 ORA  Observation Report Acknowledgement (Event R33)

This message enables a response to the ORU^R30 message to provide an application level acknowledgement that may include a placer order number.

Segments

MSH

[{ SFT }]

[UAC]

MSA

[{ ERR }]

[

  ORC

 [{PRT}]

]

There is not supposed to be an Application Level acknowledgement to an Application Level Acknowledgement message. In Enhanced Mode, MSH-16 SHALL always be set to NE (Never).

7.3.8 OUL  Unsolicited Specimen Oriented Observation Message (Event R22 )

This message was designed to accommodate specimen oriented testing. It should be applicable to container-less testing (e.g., elephant on a table) and laboratory automation systems requiring container.

Generally this construct allows transfer of multiple results related to a specimen from a patient, where this specimen has been in none, one, or multiple containers.

In addition to the patient results themselves it permits the communication of the following kinds of information:

Analysis results of a non patient related sample (e.g., environmental)  patient related segments (e.g., PID, PD1, PV1, PV2) are optional.

Analysis results to a particular container with QC sample and the lot and manufacturer information about this sample (SAC-INV segments)  however for this purpose the "Unsolicited Specimen Container Oriented Observation Message" (OUL^R23) is recommended due to explicit relation between the observation and the container.

Basic identification data (lot, manufacturer, etc.) of the reagents and other substances involved in the generation of analysis results (TCD-SID segments).

Refer to Chapter 13 Laboratory Automation for additional examples of usage of SAC.

The Device segment (DEV) provides additional device information for a device referenced in one or more of the PRT segments in the message (using PRT-10 Participation Device to match DEV-2 Unique Device Identifier or PRT-22 Participation Device Type using DEV-3 Device Type).

Segments

MSH

[{ARV}]

[{SFT}]

[UAC]

 [NTE]

 [

   PID

   [PD1]

   [{PRT}]

   [{ARV}]

   [{NTE}]

   [{

   OBX

   [{PRT}]

   }]

 [

   PV1

   [PV2]

   [{PRT}]

 ]

 ]

 [{NK1}]

   {

     SPM

       [{

       OBX

         [{PRT}]

       }]

       [{

         SAC

         [INV]

       }]

     {

       OBR

       [{PRT}]

       [

       ORC

       [{PRT}]

        [

         OBX

         [{PRT}]

         TXA

        ]

       ]

       [{NTE}]

       [{PRT}]

         [{

           TQ1

           [{TQ2}]

         }]

       [{

         OBX

         [{PRT}]

         [TCD]

         {[SID]}

         {[INV]}

         [{NTE}]

       }]

     [{CTI}]

     }

   }

[{

   DEV

   [{OBX}]

}]

[DSC]

7.3.9 OUL  Unsolicited Specimen Container Oriented Observation Message (Event R23)

This message was designed to accommodate specimen oriented testing. It should be applicable to, for example, laboratory automation systems requiring container.

Generally this construct allows transfer of multiple results related to one or more specific containers with one or more specimens from a patient.

In addition to the patient results themselves it permits the communication of the following kinds of information:

Analysis results of a non patient related sample (e.g., environmental)  patient related segments (e.g., PID, PD1, PV1, PV2) are optional.

Analysis results to a particular container with QC sample and the lot and manufacturer information about this sample (SAC-INV segments).

Basic identification data (lot, manufacturer, etc.) of the reagents and other substances involved in the generation of analysis results (TCD-SID segments).

Refer to Chapter 13 Laboratory Automation for additional examples of usage of SAC.

The Device segment (DEV) provides additional device information for a device referenced in one or more of the PRT segments in the message (using PRT-10 Participation Device to match DEV-2 Unique Device Identifier or PRT-22 Participation Device Type using DEV-3 Device Type).

Segments

MSH

[{ARV}]

[{ SFT }]

[UAC]

 [NTE]

 [

   PID

   [PD1]

   [{PRT}]

   [{OH1}]

   [{OH2}]

    [OH3]

   [{OH4}]

   [{ARV}]

   [{NTE}]

   [{

   OBX

   [{PRT}]

   }]

 [

   PV1

   [PV2]

   [{PRT}]

 ]

 ]

 [{NK1}]

 {

   SPM

    [{

      OBX

      [{PRT}]

    }]

   {

     SAC

       [INV]

       {

         OBR

         [{PRT}]

         [

          ORC

          [{PRT}]

          [

            OBX

            [{PRT}]

            TXA

          ]

         ]

         [{NTE}]

         [{PRT}]

         [{

           TQ1

           [{TQ2}]

         }]

         [{

           OBX

           [{PRT}]

           [TCD]

           [{SID}]

           [{INV}]

           [{NTE}]

         }]

     [{CTI}]

     }

   }

 }

[{

   DEV

   [{OBX}]

}]

[DSC]

7.3.10 OUL  Unsolicited Order Oriented Observation Message (Event R24)

This message was designed to accommodate multi-specimen oriented testing. It should be applicable to, e.g., laboratory automation systems requiring container.

Generally this construct allows transfer of multiple results, each one related to none, one or more specific containers with one or more specimens from a patient. (Example: Creatinine Clearance result with detailed information about the urine and serum specimens and their containers.)

In addition to the patient results themselves it permits the communication of the following kinds of information:

Analysis results of a non patient related sample (e.g., environmental)  patient related segments (e.g., PID, PD1, PV1, PV2) are optional.

Analysis results to a particular container with QC sample and the lot and manufacturer information about this sample (SAC-INV segments).

Basic identification data (lot, manufacturer, etc.) of the reagents and other substances involved in the generation of analysis results (TCD-SID segments).

Refer to Chapter 13 Laboratory Automation for additional examples of usage of SAC.

The Device segment (DEV) provides additional device information for a device referenced in one or more of the PRT segments in the message (using PRT-10 Participation Device to match DEV-2 Unique Device Identifier or PRT-22 Participation Device Type using DEV-3 Device Type).

Segments

MSH

[{ARV}]

[{ SFT }]

[UAC]

 [NTE]

 [

   PID

   [PD1]

   [{PRT}]

   [{OH1}]

   [{OH2}]

    [OH3]

   [{OH4}]

   [{ARV}]

   [{NTE}]

   [{

   OBX

   [{PRT}]

   }]

 [

   PV1

   [PV2]

   [{PRT}]

 ]

 ]

 [{NK1}]

 {

   OBR

   [{PRT}]

   [

   ORC

   [{PRT}]

   [

    OBX

    [{PRT}]

    TXA

    ]

   ]

   [{NTE}]

   [{PRT}]

   [{

     TQ1

     [{TQ2}]

   }]

   [{

     SPM

       [{

         OBX

         [{PRT}]

       }]

     [{

       SAC

         [INV]

     }]

   }]

   [{

     OBX

     [{PRT}]

     [TCD]

     [{SID}]

     [{INV}]

     [{NTE}]

   }]

   [{CTI}]

[{

   DEV

   [{OBX}]

}]

 }

[DSC]

7.3.11 OPU  Unsolicited Population/Location-Based Laboratory Observation Message (Event R25)

This message supports unsolicited population or location-based surveillance reporting to a central repository where the accession / visit may contain references to multiple patients, multiple specimens, non-patient specimens, and multiple orders per specimen.

This message structure represents the way most submissions to veterinary laboratories occur. There is a multi-tier hierarchy in which a single individual (for example, a veterinarian or an owner of a production facility) submits one or more specimen samples from one or more animals or non-living entity, such as environmental specimens or feed. This grouped submission of specimens from multiple animal ''patients'' is usually referred to as an ''accession'' which can be considered analogous to a ''visit'' in the veterinary laboratory context. This is what accounts for the unusual structure where the PV1 segment precedes a repeatable ACCESSION_DETAIL group.

Since specimens can originate from non-patients the PATIENT group is optional. This allows for specimens that are both associated with patients as well as those associated with non-patients to be included under the same accession (visit). Each specimen may have one or more orders assigned, each of which may have one or more individual results.

The OBX segment at the visit level provides the reason for submission. The repeatable PRT segment at the visit level represents the person(s) or organization submitting the request and other interested parties and locations who (that) play a role in the disposition of the accession/visit.

The NK1 segment contains owner and/or responsible party information for the patient and/or specimen.

Segments

MSH

[{ARV}]

[{SFT}]

[UAC]

 [NTE]

 PV1

   [PV2]

   [{PRT}]

   [{

   OBX

   [{NTE}]

   [{PRT}]

   }]

 {

  {NK1}

   [

    PID

    [PD1]

    [{PRT}]

    [{OH1}]

    [{OH2}]

     [OH3]

    [{OH4}]

    [{ARV}]

      [{

         OBX

         [{PRT}]

         [{NTE}]

      }]

    ]

    {

      SPM

       [{

         OBX

         [{PRT}]

         [{NTE}]

       }]

       [{

        SAC

         [INV]

       }]

     {

       OBR

       [{PRT}]

       [

       ORC

       [{PRT}]

       ]

       [{NTE}]

       [{PRT}]

         [{

           TQ1

           [{TQ2}]

         }]

       {

         OBX

         [{PRT}]

         [{NTE}]

       }

     }

   }

 }

7.3.12 ORU  Unsolicited Alert Observation Message (Event R40)

The R40 trigger event is used for observation reports that include an alertable condition, i.e., for which some timely human or application intervention in patient care may be indicated by the findings. The ORA^R41 provides the application level response to the ORU^R40.

The ORU^R40 message is outside of the order-fulfilling cycle of the ORU and OUL messages with other trigger events, and is supplemental to those order-fulfilling observations. As such, the results conveyed in the ORU^R40 do not replace, edit, or override the results of messages with other trigger events.

The ORU^R40 message represents a unitary alert, which is to be acknowledged as a whole by an ORA message. Multiple alerts requiring separate acknowledgement must be sent as individual messages.

The ORDER_OBSERVATION Segment Group which has OBR-49 value A (Alert provider when abnormal) conveys the alert observation(s). One or more OBX segments in this Segment Group will typically have OBX-8 Interpretation Codes value of LL. HH, or AA. At least one OBR segment shall have OBR-49 value A. Other ORDER_OBSERVATION Segment Groups within the message shall be considered supporting information for the alert observation(s).

An alert observation report may simply replicate observations conveyed in another observation message, e.g., sent in an ORU^R01 (the source observation). In such an instance the ORDER_OBSERVATION Segment Group shall replicate the OBR (and ORC, if present) of the source observation.

An alert observation reporting application may also derive a new alertable observation, e.g., from a combination of other observations from multiple orders, processed by a clinical decision support rule set. In this case, the ORDER_OBSERVATION Segment Group with the alertable observation may use an OBR representing the "order" for clinical decision support, with this instance uniquely identified in the OBR-51 Observation Group ID. Supporting source observations may be conveyed in subsequent ORDER_OBSERVATION Segment Groups in the message using their original OBR information.

If the reporting application can identify a preferred recipient for the alert, that may be conveyed in the PRT segment related to the OBR or OBX (with PRT-4 value RCT "Results Copies To"). This recipient may not be the same as the recipient(s) identified in a source observation. There is no expectation that the reporting application will a priori know a preferred recipient, nor that the receiving application will deliver the alert to the identified recipient (e.g., it may be delivered to an "on-call" clinician in lieu of the identified recipient).

Segments

MSH

[{ARV}]

[{ SFT }]

[UAC]

{  

  [

     PID

     [PD1]

     [{PRT}]

     [{OH1}]

     [{OH2}]

      [OH3]

     [{OH4}]

     [{NTE}]

     [{

       NK1

       [{OH2}]

       [OH3]

     }]

     [{ARV}]

     [{

       OBX

       [{PRT}]

     }]

     [

       PV1

       [PV2]

       [{PRT}]

     ]

     [{

       IN1

       [IN2]

       [IN3]

     }]

   ]

   {

      [

        ORC

        [{PRT}]

        [

         OBX

         [{PRT}]

         TXA

        ]

      ]

      OBR

      [{NTE}]

      [{

        [{PRT}]

        [{DEV}]

      }]

      [{

         TQ1

         [{TQ2}]

      }]

      [CTD]

      [{

        OBX

        [{PRT}]

        {[NTE]}

      }]

      [{FT1}]

      {[CTI]}

      [{

        SPM

        [{

          OBX

          [{PRT}]

        }]

      }]

   }   

   [{

     DEV

     [{OBX}]

   }]

}   

[DSC]

7.3.13 ORA  Observation Report Alert Acknowledgement (Event R41)

This message enables application level acknowledgements in response to the ORU^R40 alert observation message.

The R41 trigger event is used to indicate that the alert observation has been delivered to, and acknowledged by, a clinical user. If the clinical user can be identified, that identity can be conveyed in the PRT segment (with PRT-4 value AAP Alert Acknowledging Provider).

Considering that the alerts may be received by multiple providers, multiple acknowledgements may be returned. The behavior associated with the user acknowledgement may be specified in a local implementation agreement or implementation guide and may be indicated in MSH-21 Message Profile Identifier.

Segments

MSH

[{ SFT }]

[UAC]

MSA

[{ ERR }]

[{ PRT }]

7.3.14 ORU  Unsolicited Device Event Observation Message (Event R42)

The R42 trigger event is used for observation reports that identify a device-sourced event (e.g., transition on an infusion pump between primary and secondary modes of operation) that is relevant to clinical workflow but that does not require a response from a clinician or clinical management system (in which case, an R40 alert message should be used). These events are episodic (vs. periodic), require low latency and appropriate prioritized handling (i.e., should be communicated immediately after the event is signaled), and typically require low transmission bandwidth. R42 messages do not need to provide for an application level response, as does the ORU^R40 message (via the ORA^R41 message).

Use examples of this message include:

Electronic medication administration record (eMAR) systems that record the pre-programmed transition event of an infusion pump between primary and secondary operational modes, or when it is manually paused and then restarted;

Clinical decision support systems (CDSS) that track a patients progress by monitoring, among other events, ventilator transitions from the primary operational mode to a backup mode (e.g., patient triggered to fully mechanical breaths);

Clinical information systems that note an event when a patients physiological monitor is placed into Standby Mode;

Computerized Maintenance Management Systems (CMMS) records usage events and technical (non-alert) maintenance events to determine when a piece of equipment should be evaluated for proper operation.

In contrast to ORU^R42, the ORU^R01 message is typically used to periodically report bulk or full-disclosure device data that may include event information, albeit not reported in a timely manner and in a way that requires more processing to identify. As mentioned, the ORU^R40 message supports a class of episodic events, but focuses on those alerts and alarms that require some level of clinical response to resolve. The ORU^R42 message explicitly does not require clinical action to be taken in response to receipt of the message.

The OBX-8 field for these messages should be left blank or set to N for normal. Any abnormal or other non-normal indications should result in usage of the ORU^R40 message.

The ORU^R40 message is outside of the order-fulfilling cycle of the ORU and OUL messages with other trigger events, and is supplemental to those order-fulfilling observations. As such, the results conveyed in the ORU^R40 message do not replace, edit, or override the results of messages with other trigger events.

Segments

MSH

[{ARV}]

[{ SFT }]

[UAC]

{  

  [

     PID

     [PD1]

     [{PRT}]

     [{OH1}]

     [{OH2}]

      [OH3]

     [{OH4}]

     [{NTE}]

      [{

       NK1

        [{OH2}]

        [OH3]

      }]

     [{ARV}]

     [{

       OBX

       [{PRT}]

     }]

     [

       PV1

       [PV2]

       [{PRT}]

     ]

     [{

        IN1

       [IN2]

       [IN3]

     }]

   ]

   {

      [

      ORC

      [{PRT}]

        [

         OBX

         [{PRT}]

         TXA

        ]

      ]

      OBR

      {[NTE]}

      [{

      PRT

        [{DEV}]

      }]

      [{

         TQ1

         [{TQ2}]

      }]

      [CTD]

      [{

        OBX

        [{PRT}]

        {[NTE]}

      }]   

      [{FT1}]

      {[CTI]}

      [{

        SPM

        [{

          OBX

          [{PRT}]

        }]

      }]

   }   

  [{

     DEV

     [{OBX}]

  }]

}   

[DSC]

7.3.15 ORU  Unsolicited Patient-Device Association Observation Message (Event R43)

The R43 trigger event is used for observation reports that indicate the association of one patient to one or more health care devices. This includes both patient-device association as well as disassociation when a device is removed from active use with a patient. Other messages may be utilized for this purpose (e.g., ADT); however, this message was chosen given the general use of ORU-style messages to communicate device data, including unique device identifiers (e.g., PRT-10 and UDI components), and the possible need to include additional device data such as hardware / software configuration. The R43 trigger provides indication of the specialized usage of this message. Note that OBX-3 Observation Identifier, PRT-4 Participation, and OBX-11 Observation Result Status represent the purpose of the association of the device and the status of that association as further defined through the appropriate implementation guides and/or profiles.

Use cases that this message supports include:

Simple patient-device association where a system that integrates a bar code or RFID reader is used to capture patient and device identifiers at the point of care and then communicate those to other devices and systems that process device data associated with the same patient.

When one or more devices are no longer associated with a patient, this message can be used to communicate this change of status

Systems may not only perform the identifier acquisition from patients and devices, but may also authenticate the identifiers and support cross-referencing (e.g., when there are multiple patient identifiers)

In the latter use case, this message can be used to establish a source of truth for patient-device associations. There are many systems in and supportive of the point of care that make associations between patients and health care devices, all of which need to be coordinated to ensure there are no mis-matches between information sources and the patients to which they are associated.

The message shall identify a patient with optional location information, and one or more device observations, each including a unique device identifier along with an indication of whether the device is being associated or disassociated with the specified patient. In addition, a single observation can be specified to disassociate all devices for a given patient.

Segments

MSH

[{ARV}]

[{ SFT }]

[UAC]

{  

  [

     PID

     [PD1]

     [{PRT}]

     [{OH1}]

     [{OH2}]

      [OH3]

     [{OH4}]

     [{NTE}]

     [{

       NK1

        [{OH2}]

        [OH3]

      }]

     [{ARV}]

     [{

       OBX

       [{PRT}]

     }]

     [

       PV1

       [PV2]

       [{PRT}]

     ]

     [{

       IN1

       [IN2]

       [IN3]

     }]

   ]

   {

      [

        ORC

       [{PRT}]

        [

         OBX

         [{PRT}]

         TXA

        ]

      ]

      OBR

      {[NTE]}

      [{

        PRT

        [{DEV}]

      }]

      [{

         TQ1

         [{TQ2}]

      }]

      [CTD]

      [{

        OBX

        [{PRT}]

        {[NTE]}

      }]   

      [{FT1}]

      [{CTI}]

      [{

         SPM

         [{

            OBX

            [{PRT}]

         }]

      }]

   }   

   [{

      DEV

      [{OBX}]

   }]

}   

[DSC]

7.4 General Segments

The full definitions of many segments required for reporting clinical observations are included in other chapters. The patient identifying segment (PID) is provided in Chapter 3. The NTE segment is in Chapter 2.

7.4.1 OBR  Observation Request Segment

General (taken from ASTM E1238)

The Observation Request (OBR) segment is used to transmit information specific to an order for a diagnostic study or observation, physical exam, or assessment.

The Observation Request segment defines the attributes of a particular request for diagnostic services (e.g., laboratory, EKG) or clinical observations (e.g., vital signs or physical exam). When a placer requests a given set of observations, always include an order segment. For lab tests, the information in the order segment usually applies to a single specimen. However, there is not a one-to-one relationship between specimen and tests ordered. Different test batteries will usually require their own order segments even when they can be performed on a single specimen. In this case, the specimen information must be duplicated in each of the order segments that employ that specimen. For other diagnostic studies, e.g., chest X-ray, a separate order segment will usually be generated for each diagnostic study.

Though multiple observation batteries can be ordered on a single order segment, the observation filler shall generate a separate order segment for each battery that it processes independently, e.g., electrolyte, CBC, vital signs. When reporting the observations, the filling service shall copy the appropriate order (specimen) information from the original order segment into each of the new order segments so that a separate "order" segment is returned to the placer as a "header" for each separate battery of observations.

In the event that an ordered battery of observations cannot be performed, e.g., because of hemolysis on a blood sample, an order segment will be returned to the placer with OBR-25-result status equal to X (to indicate that the study was not performed). In this case, no observation segments will be transmitted.

When observations are successfully completed, the message returned to the placer will include the order segment (OBR) followed by observation (OBX) segments for each distinct observation generated by the order (see Chapter 7). The number of such observation segments will depend upon the number of individual measurements performed in the process.

OBX segments can be sent by the placer along with an order to provide the filling service with clinical data needed to interpret the results. (See Chapter 7 for OBX details.)

7.4.1.0 OBR field definitions

The daggered (+) items in this segment are created by the filler, not the placer. They are valued by the filler as needed when the OBR segment is returned as part of a report.

The starred (*) fields are only relevant when an observation is associated with a specimen. These are completed by the placer when the placer obtains the specimen. They are completed by the filler when the filler obtains the specimen.

OBR-7-observation date/time and OBR-8-observation end date/time (flagged with #) are the physiologically relevant times. In the case of an observation on a specimen, they represent the start and end of the specimen collection. In the case of an observation obtained directly from a subject (e.g., BP, Chest X-ray), they represent the start and end time of the observation.

7.4.1.1 OBR-1 Set ID  OBR (SI) 00237

Definition: For the first order transmitted, the sequence number shall be 1; for the second order, it shall be 2; and so on.

7.4.1.2 OBR-2 Placer order number (EI) 00216

Definition: This field is identical to ORC-2-Placer Order Number.

This field is a special case of the Entity Identifier data type (Chapter 2A, section 2.A.28). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). A limit of fifteen (15) characters is suggested but not required. It is assigned by the placer (ordering application). An implementation is HL7 compliant when the number of characters for this field is increased to accommodate applications that require a greater number of characters for the Placer order number. It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (section 2.A.36, "HD  Hierarchic designator"). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.

See ORC-2-placer order number (section 4.5.1.2) for information on when this field must be valued.

A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution''s master dictionary lists that is documented in Chapter 8. Since third-party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the placer application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.

It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.

These rules apply to the few other fields that are present in both ORC and OBR for upward compatibility (e.g., quantity/timing, parent numbers, ordering provider, and ordering call back numbers).

7.4.1.3 OBR-3 Filler Order Number (EI) 00217

Definition: This field is the order number associated with the filling application. This is a permanent identifier for an order and its associated observations. It is a special case of the Entity Identifier data type (see Chapter 2, section 2.A.28, "EI  entity identifier").

The first component is a string that identifies an individual order segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filling (receiving) application. It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.

The second through fourth components contain the filler application ID, in the form of the HD data type (see section 2.A.36, "HD  hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.

See ORC-3-filler order number for information on when this field must be valued.

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.