The Demo site for our new HL7 Version 2+ (plus) Standard
visit the hl7 website

Draft Website - For Review Purposes Only

Observation Reporting

Co-Chair:

Hans Buitendijk
Cerner Corporation

Co-Chair:

David Burgess
LabCorp

Co-Chair:

Lorraine Constable
Constable Consulting Inc.

Co-Chair:

Rob Hausam
Hausam Consulting

Co-Chair:

Patrick Loyd
ICode Solutions

Co-Chair:

Ken McCaslin
Accenture Federal

Co-Chair:

Riki Merrick
Vernetzt, LLC

Co-Chair:

J.D. Nolen
Children’s Mercy Hospital

Editor:

Hans Buitendijk
Cerner Corporation

Sponsoring Workgroup:

Orders & Observations

List Server:

ord@lists.hl7.org


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.

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. 

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.

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, 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."

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."

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.

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.).

Clinical Document Architecture (CDA):

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

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.

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.

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."

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).

ORU^R01^ORU_R01: Observation Message
HL7 MessageStructure Table - ORU_R01
Segment Cardinality Must Implement Status
ORU_R01
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PATIENT_RESULT 1..* Yes
PATIENT 0..1
PID 1..1 Yes
PD1 0..1
PRT 0..*
OH1 0..*
OH2 0..*
OH3 0..1
OH4 0..*
NTE 0..*
ARV 0..* B
NEXT_OF_KIN 0..*
NK1 1..1 Yes
OH2 0..*
OH3 0..1
PATIENT_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
VISIT 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
INSURANCE 0..*
IN1 1..1 Yes
IN2 0..1
IN3 0..1
ORDER_OBSERVATION 1..* Yes
OBR 1..1 Yes
NTE 0..*
CTD 0..1
FT1 0..*
CTI 0..*
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
ORDER_DOCUMENT 0..1
OBX 1..1 Yes
PRT 0..*
TXA 1..1 Yes
OBSERVATION_PARTICIPATION 0..*
PRT 1..1 Yes
DEV 0..*
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
NTE 0..*
SPECIMEN 0..*
SPM 1..1 Yes
SPECIMEN_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
DEVICE 0..*
DEV 1..1 Yes
OBX 0..*
DSC 0..1

Original Mode Acknowledgement Choreography for ORU^R01^ORU_R01

Send Application Ack: ACK^R01^ACK

Enhanced Mode Acknowledgement Choreography for ORU^R01^ORU_R01

When the MSH-15 value of an ORU^R01^ORU_R01 message is AL or ER or SU, an ACK^R01^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORU^R01^ORU_R01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORU^R01^ORU_R01 message is AL or ER or SU, an ACK^R01^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ORU^R01^ORU_R01 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R01^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^R01^ACK
NE (none)

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.

ACK^R01^ACK: Observation Message
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^R01^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^R01^ACK

When the MSH-15 value of an ACK^R01^ACK message is AL or ER or SU, an ACK^R01^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ACK^R01^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R01^ACK
NE (none)
MSH-16 NE (none)

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).

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.  

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.

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).

ORU^R30^ORU_R30: Observation Message:
HL7 MessageStructure Table - ORU_R30
Segment Cardinality Must Implement Status
ORU_R30
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PID 1..1 Yes
PD1 0..1
PRT 0..*
OH1 0..*
OH2 0..*
OH3 0..1
OH4 0..*
ARV 0..* B
PATIENT_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
VISIT 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
ORC 1..1 Yes
PRT 0..*
OBR 1..1 Yes
NTE 0..*
PRT 0..*
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
OBSERVATION 1..* Yes
OBX 1..1 Yes
PRT 0..*
NTE 0..*
DEVICE 0..*
DEV 1..1 Yes
OBX 0..1

Original Mode Acknowledgement Choreography for ORU^R30^ORU_R30

Send Application Ack: ACK^R33^ACK

Enhanced Mode Acknowledgement Choreography for ORU^R30^ORU_R30

When the MSH-15 value of an ORU^R30^ORU_R30 message is AL or ER or SU, an ACK^R30^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORU^R30^ORU_R30 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORU^R30^ORU_R30 message is AL or ER or SU, an ACK^R33^ACK or ORA^R33^ORA_R33 message SHALL be sent as an application ack.

When the MSH-16 value of an ORU^R30^ORU_R30 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R30^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^R33^ACK or ORA^R33^ORA_R33
NE (none)

ACK^R30^ACK: Observation Message
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^R30^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^R30^ACK

When the MSH-15 value of an ACK^R30^ACK message is AL or ER or SU, an ACK^R30^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ACK^R30^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R30^ACK
NE (none)
MSH-16 NE (none)

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).

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).

ORU^R31^ORU_R30: Observation Message
HL7 MessageStructure Table - ORU_R30
Segment Cardinality Must Implement Status
ORU_R30
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PID 1..1 Yes
PD1 0..1
PRT 0..*
OH1 0..*
OH2 0..*
OH3 0..1
OH4 0..*
ARV 0..* B
PATIENT_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
VISIT 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
ORC 1..1 Yes
PRT 0..*
OBR 1..1 Yes
NTE 0..*
PRT 0..*
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
OBSERVATION 1..* Yes
OBX 1..1 Yes
PRT 0..*
NTE 0..*
DEVICE 0..*
DEV 1..1 Yes
OBX 0..1

Original Mode Acknowledgement Choreography for ORU^R31^ORU_R30

Send Application Ack: ACK^R31^ACK

Enhanced Mode Acknowledgement Choreography for ORU^R31^ORU_R30

When the MSH-15 value of an ORU^R31^ORU_R30 message is AL or ER or SU, an ACK^R31^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORU^R31^ORU_R30 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORU^R31^ORU_R30 message is AL or ER or SU, an ACK^R31^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ORU^R31^ORU_R30 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R31^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^R31^ACK
NE (none)

ACK^R31^ACK: Acknowledgment
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^R31^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^R31^ACK

When the MSH-15 value of an ACK^R31^ACK message is AL or ER or SU, an ACK^R31^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ACK^R31^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R31^ACK
NE (none)
MSH-16 NE (none)

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).

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).

ORU^R32^ORU_R30: Observation Message
HL7 MessageStructure Table - ORU_R30
Segment Cardinality Must Implement Status
ORU_R30
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PID 1..1 Yes
PD1 0..1
PRT 0..*
OH1 0..*
OH2 0..*
OH3 0..1
OH4 0..*
ARV 0..* B
PATIENT_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
VISIT 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
ORC 1..1 Yes
PRT 0..*
OBR 1..1 Yes
NTE 0..*
PRT 0..*
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
OBSERVATION 1..* Yes
OBX 1..1 Yes
PRT 0..*
NTE 0..*
DEVICE 0..*
DEV 1..1 Yes
OBX 0..1

Original Mode Acknowledgement Choreography for ORU^R32^ORU_R30

Send Application Ack: ACK^R32^ACK

Enhanced Mode Acknowledgement Choreography for ORU^R32^ORU_R30

When the MSH-15 value of an ORU^R32^ORU_R30 message is AL or ER or SU, an ACK^R32^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORU^R32^ORU_R30 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORU^R32^ORU_R30 message is AL or ER or SU, an ACK^R32^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ORU^R32^ORU_R30 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R32^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^R32^ACK
NE (none)

ACK^R32^ACK: Observation Message
HL7 MessageStructure Table - ACK
Segment Cardinality Must Implement Status
ACK
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*

Original Mode Acknowledgement Choreography for ACK^R32^ACK

Send An Acknowlegment is never sent in original mode.

Enhanced Mode Acknowledgement Choreography for ACK^R32^ACK

When the MSH-15 value of an ACK^R32^ACK message is AL or ER or SU, an ACK^R32^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ACK^R32^ACK message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R32^ACK
NE (none)
MSH-16 NE (none)

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).

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.

ORA^R33^ORA_R33: Observation Report Acknowledgement
HL7 MessageStructure Table - ORA_R33
Segment Cardinality Must Implement Status
ORA_R33
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*
ORDER 0..1
ORC 1..1 Yes
PRT 0..*

Original Mode Acknowledgement Choreography for ORA^R33^ORA_R33

Send Immediate Ack: ACK^R33^ACK

Enhanced Mode Acknowledgement Choreography for ORA^R33^ORA_R33

When the MSH-15 value of an ORA^R33^ORA_R33 message is AL or ER or SU, an ACK^R33^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORA^R33^ORA_R33 message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R33^ACK
NE (none)
MSH-16 NE (none)

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).

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).

OUL^R22^OUL_R22: Observation Message
HL7 MessageStructure Table - OUL_R22
Segment Cardinality Must Implement Status
OUL_R22
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
NTE 0..1
PATIENT 0..1
PID 1..1 Yes
PD1 0..1
PRT 0..*
ARV 0..* B
NTE 0..*
PATIENT_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
VISIT 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
NK1 0..*
SPECIMEN 1..* Yes
SPM 1..1 Yes
SPECIMEN_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
CONTAINER 0..*
SAC 1..1 Yes
INV 0..1
ORDER 1..* Yes
OBR 1..1 Yes
PRT 0..*
NTE 0..*
PRT 0..* Deprecated
CTI 0..*
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
ORDER_DOCUMENT 0..1
OBX 1..1 Yes
PRT 0..*
TXA 1..1 Yes
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
RESULT 0..*
OBX 1..1 Yes
PRT 0..*
TCD 0..1
SID 0..* B
INV 0..*
NTE 0..*
DEVICE 0..*
DEV 1..1 Yes
OBX 0..*
DSC 0..1

Original Mode Acknowledgement Choreography for OUL^R22^OUL_R22

Send Application Ack: ACK^R22^ACK

Enhanced Mode Acknowledgement Choreography for OUL^R22^OUL_R22

When the MSH-15 value of an OUL^R22^OUL_R22 message is AL or ER or SU, an ACK^R22^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OUL^R22^OUL_R22 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OUL^R22^OUL_R22 message is AL or ER or SU, an ACK^R22^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an OUL^R22^OUL_R22 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R22^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^R22^ACK
NE (none)

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).

OUL^R23^OUL_R23: Observation Message
HL7 MessageStructure Table - OUL_R23
Segment Cardinality Must Implement Status
OUL_R23
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
NTE 0..1
PATIENT 0..1
PID 1..1 Yes
PD1 0..1
PRT 0..*
OH1 0..*
OH2 0..*
OH3 0..1
OH4 0..*
ARV 0..* B
NTE 0..*
PATIENT_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
VISIT 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
NK1 0..*
SPECIMEN 1..* Yes
SPM 1..1 Yes
SPECIMEN_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
CONTAINER 1..* Yes
SAC 1..1 Yes
INV 0..1
ORDER 1..* Yes
OBR 1..1 Yes
PRT 0..*
NTE 0..*
PRT 0..* Deprecated
CTI 0..*
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
ORDER_DOCUMENT 0..1
OBX 1..1 Yes
PRT 0..*
TXA 1..1 Yes
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
RESULT 0..*
OBX 1..1 Yes
PRT 0..*
TCD 0..1
SID 0..* B
INV 0..*
NTE 0..*
DEVICE 0..*
DEV 1..1 Yes
OBX 0..*
DSC 0..1

Original Mode Acknowledgement Choreography for OUL^R23^OUL_R23

Send Application Ack: ACK^R23^ACK

Enhanced Mode Acknowledgement Choreography for OUL^R23^OUL_R23

When the MSH-15 value of an OUL^R23^OUL_R23 message is AL or ER or SU, an ACK^R23^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OUL^R23^OUL_R23 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OUL^R23^OUL_R23 message is AL or ER or SU, an ACK^R23^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an OUL^R23^OUL_R23 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R23^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^R23^ACK
NE (none)

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).

OUL^R24^OUL_R24: Observation Message
HL7 MessageStructure Table - OUL_R24
Segment Cardinality Must Implement Status
OUL_R24
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
NTE 0..1
PATIENT 0..1
PID 1..1 Yes
PD1 0..1
PRT 0..*
OH1 0..*
OH2 0..*
OH3 0..1
OH4 0..*
ARV 0..* B
NTE 0..*
PATIENT_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
VISIT 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
NK1 0..*
ORDER 1..* Yes
OBR 1..1 Yes
PRT 0..*
NTE 0..*
PRT 0..* Deprecated
CTI 0..*
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
ORDER_DOCUMENT 0..1
OBX 1..1 Yes
PRT 0..*
TXA 1..1 Yes
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
SPECIMEN 0..*
SPM 1..1 Yes
SPECIMEN_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
CONTAINER 0..*
SAC 1..1 Yes
INV 0..1
RESULT 0..*
OBX 1..1 Yes
PRT 0..*
TCD 0..1
SID 0..* B
INV 0..*
NTE 0..*
DEVICE 0..*
DEV 1..1 Yes
OBX 0..*
DSC 0..1

Original Mode Acknowledgement Choreography for OUL^R24^OUL_R24

Send Application Ack: ACK^R24^ACK

Enhanced Mode Acknowledgement Choreography for OUL^R24^OUL_R24

When the MSH-15 value of an OUL^R24^OUL_R24 message is AL or ER or SU, an ACK^R24^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OUL^R24^OUL_R24 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OUL^R24^OUL_R24 message is AL or ER or SU, an ACK^R24^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an OUL^R24^OUL_R24 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R24^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^R24^ACK
NE (none)

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.

OPU^R25^OPU_R25: Observation Message
HL7 MessageStructure Table - OPU_R25
Segment Cardinality Must Implement Status
OPU_R25
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
NTE 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
PATIENT_VISIT_OBSERVATION 0..*
OBX 1..1 Yes
NTE 0..*
PRT 0..*
ACCESSION_DETAIL 1..* Yes
NK1 1..* Yes
PATIENT 0..1
PID 1..1 Yes
PD1 0..1
PRT 0..*
OH1 0..*
OH2 0..*
OH3 0..1
OH4 0..*
ARV 0..* B
PATIENT_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
NTE 0..*
SPECIMEN 1..* Yes
SPM 1..1 Yes
SPECIMEN_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
NTE 0..*
CONTAINER 0..*
SAC 1..1 Yes
INV 0..1
ORDER 1..* Yes
OBR 1..1 Yes
PRT 0..*
NTE 0..*
PRT 0..* Depracted
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
RESULT 1..* Yes
OBX 1..1 Yes
PRT 0..*
NTE 0..*

Original Mode Acknowledgement Choreography for OPU^R25^OPU_R25

Send Application Ack: ACK^R25^ACK

Enhanced Mode Acknowledgement Choreography for OPU^R25^OPU_R25

When the MSH-15 value of an OPU^R25^OPU_R25 message is AL or ER or SU, an ACK^R25^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an OPU^R25^OPU_R25 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an OPU^R25^OPU_R25 message is AL or ER or SU, an ACK^R25^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an OPU^R25^OPU_R25 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R25^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^R25^ACK
NE (none)

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).

ORU^R40^ORU_R01: Observation Message
HL7 MessageStructure Table - ORU_R01
Segment Cardinality Must Implement Status
ORU_R01
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PATIENT_RESULT 1..* Yes
PATIENT 0..1
PID 1..1 Yes
PD1 0..1
PRT 0..*
OH1 0..*
OH2 0..*
OH3 0..1
OH4 0..*
NTE 0..*
ARV 0..* B
NEXT_OF_KIN 0..*
NK1 1..1 Yes
OH2 0..*
OH3 0..1
PATIENT_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
VISIT 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
INSURANCE 0..*
IN1 1..1 Yes
IN2 0..1
IN3 0..1
ORDER_OBSERVATION 1..* Yes
OBR 1..1 Yes
NTE 0..*
CTD 0..1
FT1 0..*
CTI 0..*
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
ORDER_DOCUMENT 0..1
OBX 1..1 Yes
PRT 0..*
TXA 1..1 Yes
OBSERVATION_PARTICIPATION 0..*
PRT 1..1 Yes
DEV 0..*
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
NTE 0..*
SPECIMEN 0..*
SPM 1..1 Yes
SPECIMEN_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
DEVICE 0..*
DEV 1..1 Yes
OBX 0..*
DSC 0..1

Original Mode Acknowledgement Choreography for ORU^R40^ORU_R01

Send Application Ack: ORA^R41^ORA_R41

Enhanced Mode Acknowledgement Choreography for ORU^R40^ORU_R01

When the MSH-15 value of an ORU^R40^ORU_R01 message is AL or ER or SU, an ACK^R40^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORU^R40^ORU_R01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORU^R40^ORU_R01 message is AL or ER or SU, an ORA^R41^ORA_R41 message SHALL be sent as an application ack.

When the MSH-16 value of an ORU^R40^ORU_R01 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R40^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ORA^R41^ORA_R41
NE (none)

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.

ORA^R41^ORA_R41: Observation Report Alert Acknowledgement
HL7 MessageStructure Table - ORA_R41
Segment Cardinality Must Implement Status
ORA_R41
MSH 1..1 Yes
SFT 0..*
UAC 0..1
MSA 1..1 Yes
ERR 0..*
PRT 0..*

Original Mode Acknowledgement Choreography for ORA^R41^ORA_R41

Send Application Ack: ACK^R41^ACK

Enhanced Mode Acknowledgement Choreography for ORA^R41^ORA_R41

When the MSH-15 value of an ORA^R41^ORA_R41 message is AL or ER or SU, an ACK^R41^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORA^R41^ORA_R41 message is NE, an immediate ack SHALL NOT be sent.

Never send an application ack in enhanced mode.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R41^ACK
NE (none)
MSH-16 NE (none)

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 patient’s 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 patient’s 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.

ORU^R42^ORU_R01: Observation Message
HL7 MessageStructure Table - ORU_R01
Segment Cardinality Must Implement Status
ORU_R01
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PATIENT_RESULT 1..* Yes
PATIENT 0..1
PID 1..1 Yes
PD1 0..1
PRT 0..*
OH1 0..*
OH2 0..*
OH3 0..1
OH4 0..*
NTE 0..*
ARV 0..* B
NEXT_OF_KIN 0..*
NK1 1..1 Yes
OH2 0..*
OH3 0..1
PATIENT_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
VISIT 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
INSURANCE 0..*
IN1 1..1 Yes
IN2 0..1
IN3 0..1
ORDER_OBSERVATION 1..* Yes
OBR 1..1 Yes
NTE 0..*
CTD 0..1
FT1 0..*
CTI 0..*
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
ORDER_DOCUMENT 0..1
OBX 1..1 Yes
PRT 0..*
TXA 1..1 Yes
OBSERVATION_PARTICIPATION 0..*
PRT 1..1 Yes
DEV 0..*
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
NTE 0..*
SPECIMEN 0..*
SPM 1..1 Yes
SPECIMEN_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
DEVICE 0..*
DEV 1..1 Yes
OBX 0..*
DSC 0..1

Original Mode Acknowledgement Choreography for ORU^R42^ORU_R01

Send Application Ack: ACK^R42^ACK

Enhanced Mode Acknowledgement Choreography for ORU^R42^ORU_R01

When the MSH-15 value of an ORU^R42^ORU_R01 message is AL or ER or SU, an ACK^R42^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORU^R42^ORU_R01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORU^R42^ORU_R01 message is AL or ER or SU, an ACK^R42^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ORU^R42^ORU_R01 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R42^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^R42^ACK
NE (none)

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.

ORU^R43^ORU_R01: Observation Message
HL7 MessageStructure Table - ORU_R01
Segment Cardinality Must Implement Status
ORU_R01
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PATIENT_RESULT 1..* Yes
PATIENT 0..1
PID 1..1 Yes
PD1 0..1
PRT 0..*
OH1 0..*
OH2 0..*
OH3 0..1
OH4 0..*
NTE 0..*
ARV 0..* B
NEXT_OF_KIN 0..*
NK1 1..1 Yes
OH2 0..*
OH3 0..1
PATIENT_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
VISIT 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
INSURANCE 0..*
IN1 1..1 Yes
IN2 0..1
IN3 0..1
ORDER_OBSERVATION 1..* Yes
OBR 1..1 Yes
NTE 0..*
CTD 0..1
FT1 0..*
CTI 0..*
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
ORDER_DOCUMENT 0..1
OBX 1..1 Yes
PRT 0..*
TXA 1..1 Yes
OBSERVATION_PARTICIPATION 0..*
PRT 1..1 Yes
DEV 0..*
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
NTE 0..*
SPECIMEN 0..*
SPM 1..1 Yes
SPECIMEN_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
DEVICE 0..*
DEV 1..1 Yes
OBX 0..*
DSC 0..1

Original Mode Acknowledgement Choreography for ORU^R43^ORU_R01

Send Application Ack: ACK^R43^ACK

Enhanced Mode Acknowledgement Choreography for ORU^R43^ORU_R01

When the MSH-15 value of an ORU^R43^ORU_R01 message is AL or ER or SU, an ACK^R43^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of an ORU^R43^ORU_R01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of an ORU^R43^ORU_R01 message is AL or ER or SU, an ACK^R43^ACK message SHALL be sent as an application ack.

When the MSH-16 value of an ORU^R43^ORU_R01 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R43^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^R43^ACK
NE (none)

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.

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.)

HL7 Attribute Table - OBR - Observation Request Segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
OBR
1 00237 Set ID – OBR [0..1] [1..4]
SI
2

00216 Placer Order Number MAY
True:
False: 		C
[1..1]
[0..1]
EI
3

00217 Filler Order Number MAY
True:
False: 		C
[1..1]
[0..1]
EI
4 00238 Universal Service Identifier SHALL [1..1]
0612
CWE
5 00239 Priority SHALL NOT W [0..0]
6 00240 Requested Date/Time SHALL NOT W [0..0]
7

00241 Observation Date/Time # MAY
True:
False: 		C
[1..1]
[0..1]
DTM
8 00242 Observation End Date/Time # [0..1]
DTM
9 00243 Collection Volume * B [0..1]
CQ
10 00244 Collector Identifier * B [0..*]
XCN
11 00245 Specimen Action Code * [0..1] [1..1]
0065 Specimen Action Code
ID
12 00246 Danger Code [0..1]
0613
CWE
13 00247 Relevant Clinical Information = [0..*] 300
0916 Relevant Clinicial Information
CWE
14 00248 Specimen Received Date/Time * SHALL NOT W [0..0]
DTM
15 00249 Specimen Source SHALL NOT W [0..0]
16 00226 Ordering Provider SHALL NOT W [0..0]
17 00250 Order Callback Phone Number [0..2]
XTN
18 00251 Placer Field 1 = [0..1] 199
ST
19 00252 Placer Field 2 = [0..1] 199
ST
20 00253 Filler Field 1 + = [0..1] 199
ST
21 00254 Filler Field 2 + = [0..1] 199
ST
22

00255 Results Rpt/Status Chng – Date/Time + MAY
True:
False: 		C
[1..1]
[0..1]
DTM
23 00256 Charge to Practice + [0..1]
MOC
24 00257 Diagnostic Serv Sect ID [0..1] [2..3]
0074 Diagnostic Service Section ID
ID
25

00258 Result Status + MAY
True:
False: 		C
[1..1]
[0..1] 		[1..1]
0123 Result Status
ID
26 00259 Parent Result + [0..1]
PRL
27 00221 Quantity/Timing SHALL NOT W [0..0]
28 00260 Result Copies To SHALL NOT W [0..0]
29 00261 Parent Results Observation Identifier [0..1]
EIP
30 00262 Transportation Mode [0..1] [4..4]
0124 Transportation Mode
ID
31 00263 Reason for Study [0..*]
0951
CWE
32 00264 Principal Result Interpreter + SHALL NOT W [0..0]
33 00265 Assistant Result Interpreter + SHALL NOT W [0..0]
34 00266 Technician + SHALL NOT W [0..0]
35 00267 Transcriptionist + SHALL NOT W [0..0]
36 00268 Scheduled Date/Time + [0..1]
DTM
37 01028 Number of Sample Containers * = [0..1] 16
NM
38 01029 Transport Logistics of Collected Sample * [0..*]
0614
CWE
39 01030 Collector's Comment * [0..*]
0619
CWE
40 01031 Transport Arrangement Responsibility [0..1]
0620
CWE
41 01032 Transport Arranged [0..1] [1..1]
0224 Transport Arranged
ID
42 01033 Escort Required [0..1] [1..1]
0225 Escort Required
ID
43 01034 Planned Patient Transport Comment [0..*]
0621
CWE
44 00393 Procedure Code [0..1]
CNE
45 01316 Procedure Code Modifier [0..*]
CNE
46 01474 Placer Supplemental Service Information [0..*]
0411 Supplemental Service Information Values
CWE
47 01475 Filler Supplemental Service Information [0..*]
0411 Supplemental Service Information Values
CWE
48

01646 Medically Necessary Duplicate Procedure Reason MAY
True:
False: 		C
[1..1]
[0..1]
0476
CWE
49 01647 Result Handling [0..1]
0507 Observation Result Handling
CWE
50 02286 Parent Universal Service Identifier SHALL NOT W [0..0]
51 02307 Observation Group ID [0..1]
EI
52 02308 Parent Observation Group ID [0..1]
EI
53 03303 Alternate Placer Order Number [0..*]
CX
54 00222 Parent Order [0..*]
0119 Order Control Codes
EIP
55 00816 Action Code [0..1] [2..2]
0206 Segment Action Code
ID

OBR-1: Set ID – OBR (SI) 00237

(Definition from OBR.1 in Ch. 4)

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

(Definition from OBR.1 in Ch. 7)

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

OBR-2: Placer Order Number (EI) 00216

(Definition from ORC.2 in Ch. 4)

Definition: This field is the placer application's order number.

This field is a case of the Entity Identifier data type (See Section 2.A.28, "EI – Entity Identifier"). The first component is a string that identifies an individual order (i.e., ORC segment and associated order detail segment). It is assigned by the placer (ordering application). 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.

There are three situations in which the true placer is somewhat arbitrary (and thus not unique):

  1. in ORC-1-order control value of RO, following an RU replacement;

  2. in ORC-1-order control value of CH (child orders); and

  3. in ORC-1-order control value of SN (send number).

See the Table Notes under ORC-1-order control for the details of how the ORC-2-placer order number is assigned in these cases.

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). Note that if both ORC-2 and OBR-2 are valued then they must be valued the same; as well, if both ORC-3 and OBR-3 are valued, then they must be valued the same. 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 for the placer order number when a new order is placed or a unique number for the filler order number when an 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).

(Definition from OBR.2 in Ch. 4)

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).

(Definition from OBR.2 in Ch. 7)

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).

(Definition from TXA.14 in Ch. 9)

Definition: This field is the placer application's order number.

This is a composite field. The first component is a string of characters that identifies an individual order (i.e., OBR). It is assigned by the placer (ordering application). It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the (filler) assigning authority of the placing application. The (filler) assigning authority is a string of characters that will be uniquely associated with an application. 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 entity identifiers. The components are separated by component delimiters.

TXA-14 - Condition: If corresponding ORC and/or OBR segments are present in the message and ORC-2 or OBR-2 is valued, this field must be blank. If TXA-14 is valued while ORC-2 or OBR-2 is valued it shall be ignored. See message definitions including TXA for further guidance on which ORC/OBR pairs to consider.

(Definition from ARQ.24 in Ch. 10)

Definition: This field is the placer application's order number for the order associated with this scheduling request.

This field is described in detail in Chapter 4, section 4.5.1.2, "ORC-2 – Placer Order Number." It is an optional field, but if a Placer order number is present, then a Filler order number (ARQ-25 – Filler Order Number) must also be present.

(Definition from SCH.26 in Ch. 10)

Definition: This field is the placer application's order number for the order associated with this scheduling filler application response.

This field is described in detail in Section 4.5.1.2. It is an optional field, but if a Placer order number is present, then a Filler order number (Section 10.6.2.27) must also be present. Both this field and the Filler order number below may have been sent as part of the appointment request in the ARQ segment or they may be assigned by the scheduling filler application only.

OBR-3: Filler Order Number (EI) 00217

(Definition from ORC.3 in Ch. 4)

Definition: This field is the order number associated with the filling application. It is a case of the Entity Identifier data type (Section 2.A.28). Its first component is a string that identifies an order detail segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filler (receiving) application. This string must uniquely identify the order (as specified in the order detail segment) from other orders in 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.

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 filler 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). Note that if both ORC-2 and OBR-2 are valued, then they must be valued the same; as well, if both ORC-3 and OBR-3 are valued, then they must be valued the same. 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 for the placer order number when a new order is placed or a unique number for the filler order number when an unsolicited result is initially communicated.

The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.

Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.

(Definition from OBR.3 in Ch. 4)

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.

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

The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.

Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.

(Definition from FT1.23 in Ch. 6)

Definition: This field is used when the billing system is requesting observational reporting justification for a charge. This is the number used by a filler to uniquely identify a result. See Chapter 4 for a complete description.

(Definition from OBR.3 in Ch. 7)

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.

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

The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.

Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.

(Definition from TXA.15 in Ch. 9)

Definition: This field is the order number associated with the filling application. Where a transcription service or similar organization creates the document and uses an internally unique identifier, that number should be inserted in this field. Its first component is a string of characters that identifies an order detail segment (i.e., OBR). This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (i.e., transcription service). This uniqueness must persist over time. Where a number is reused over time, a date can be affixed to the non-unique number to make it unique.

The second through fourth components contains the (filler) assigning authority. The (filler) assigning authority is a string of characters that uniquely defines the application from other applications on the network. The second through fourth components of the filler order number always identify the actual filler of an order.

TXA-15 - Condition: If corresponding ORC and/or OBR segments are present in the message and ORC-3 or OBR-3 is valued, this field must be blank. If TXA-14 is valued while ORC-3 or OBR-3 is valued it shall be ignored. See message definitions including TXA for further guidanceon which ORC/OBR pairs to consider.

For further details, please see the definitions provided in Chapter 4, "Orders".

(Definition from ARQ.25 in Ch. 10)

Definition: This field is the order number assigned by the filler application for the order associated with this scheduling request.

This field is described in detail in Chapter 4, section 4.5.1.3, "ORC-3 – Filler Order Number.” It is conditionally mandatory depending on the presence of the Placer order number (ARQ-24 – Placer Order Number). This conditionally mandatory requirement addresses the concern that a Scheduling system cannot and should not create or fill an order. Therefore, an order must have been accepted by the filler application before scheduling the resources associated with that order.

(Definition from SCH.27 in Ch. 10)

Definition: This field is the order number assigned by the filler application for the order associated with this scheduling filler response.

This field is described in detail in Chapter 4, Orders, section 4.5.1.3. It is conditionally mandatory depending on the presence of the placer order number (section 10.6.2.26). This conditionally mandatory requirement addresses the concern that a Scheduling system cannot and should not create or fill an order. Therefore, an order must have been accepted by the order filler application before scheduling the resources associated with that order.

OBR-4: Universal Service Identifier (CWE) 00238

(Definition from OBR.4 in Ch. 4)

Definition: This field contains the identifier code for the requested observation/test/battery. The identifier can come from either a local coding system or industry standards. Examples may be LOINC (emerging as the global standard for observation identifiers), JLAC10, or SNOMED CT. Refer to Table 0612 - Universal Service Identifier in Chapter 2C for valid values.

(Definition from OBR.4 in Ch. 7)

Definition: This field contains the identifier code for the requested observation/test/battery. The identifier can come from either a local coding system or industry standards. Examples may be LOINC (emerging as the global standard for observation identifiers), JLAC10, or SNOMED CT. Refer to Table 0612 - Universal Service Identifier in Chapter 2C for valid values.

(Definition from OM7.2 in Ch. 8)

Definition: This field contains the producer's usual or preferred identification of the test or service.

(Definition from AIS.3 in Ch. 10)

Definition: This field contains an identifier code for a service to be scheduled. This field may contain a universal service identifier describing the observation/test/battery/procedure or other activity that is to be performed during the requested appointment, similar to the universal service identifier defined for the OBR segment in the Order Entry chapter (Chapter 4). This code can be based on local and/or universal codes. The use of universal codes is recommended.

(Definition from TCC.1 in Ch. 13)

Definition: This field identifies the test code that information is being transmitted about. The alternate elements represent the test code identifier that has been assigned by the manufacturer to this particular test code. Refer to Table 0787 - Universal Service Identifier in Chapter 2C for valid values.

(Definition from TCD.1 in Ch. 13)

Definition: This field identifies the test code that information is being transmitted about. Refer to Table 0789 - Universal Service Identifier in Chapter 2C for valid values.

OBR-5: Priority

(Definition from OBR.5 in Ch. 4)

Attention: The OBR-5 element was retained for backward compatibility only as of v 2.4 and the detail was withdrawn and removed from the standard as of v 2.7.

(Definition from OBR.5 in Ch. 7)

Attention: The OBR-5 element was retained for backward compatibility only as of v 2.4 and the detail was withdrawn and removed from the standard as of v 2.7.

OBR-6: Requested Date/Time

(Definition from OBR.6 in Ch. 4)

Attention: The OBR-6 element was retained for backward compatibility only as of v 2.4 and the detail was withdrawn and removed from the standard as of v 2.7.

(Definition from OBR.6 in Ch. 7)

Attention: The OBR-6 element was retained for backward compatibility only as of v 2.4 and the detail was withdrawn and removed from the standard as of v 2.7.

OBR-7: Observation Date/Time # (DTM) 00241

(Definition from OBR.7 in Ch. 4)

Definition: This field is the clinically relevant date/time of the observation. In the case of observations taken directly from a subject, it is the actual date and time the observation was obtained. In the case of a specimen-associated study, this field shall represent the date and time the specimen was collected or obtained. (This is a results-only field except when the placer or a third party has already drawn the specimen.) This field is conditionally required. When the OBR is transmitted as part of a report message, the field must be filled in. If it is transmitted as part of a request and a sample has been sent along as part of the request, this field must be filled in because this specimen time is the physiologically relevant date/time of the observation.

(Definition from OBR.7 in Ch. 7)

Definition: This field is the clinically relevant date/time of the observation. In the case of observations taken directly from a subject, it is the actual date and time the observation was obtained. In the case of a specimen-associated study, this field shall represent the date and time the specimen was collected or obtained. (This is a results-only field except when the placer or a third party has already drawn the specimen.) This field is conditionally required. When the OBR is transmitted as part of a report message, the field must be filled in. If it is transmitted as part of a request and a sample has been sent along as part of the request, this field must be filled in because this specimen time is the physiologically relevant date/time of the observation.

OBR-8: Observation End Date/Time # (DTM) 00242

(Definition from OBR.8 in Ch. 4)

Definition: This field contains the end date and time of a study or timed specimen collection. If an observation takes place over a substantial period of time, it will indicate when the observation period ended. For observations made at a point in time, it will be null. This is a results field except when the placer or a party other than the filler has already drawn the specimen.

(Definition from OBR.8 in Ch. 7)

Definition: This field contains the end date and time of a study or timed specimen collection. If an observation takes place over a substantial period of time, it will indicate when the observation period ended. For observations made at a point in time, it will be null. This is a results field except when the placer or a party other than the filler has already drawn the specimen.

OBR-9: Collection Volume * (CQ) 00243

(Definition from OBR.9 in Ch. 4)

Definition: Deprecated in version 2.9 in favor of SPM-12.

(Definition from OBR.9 in Ch. 7)

Definition: Deprecated in version 2.9 in favor of SPM-12.

OBR-10: Collector Identifier * (XCN) 00244

(Definition from OBR.10 in Ch. 4)

Definition: This field is retained for backward compatibility only as of v 2.7. The reader is referred to the PRT segment described in Chapter 7.

When a specimen is required for the study, this field will identify the person, department, or facility that collected the specimen. Either name or ID code, or both, may be present. If the person referenced in this field is also referenced in PRT segment, they must contain the same information. However, if there is a difference, then PRT segment takes precedence.

(Definition from OBR.10 in Ch. 7)

Definition: This field is retained for backward compatibility only as of v 2.7. The reader is referred to the PRT segment described in Chapter 7.

When a specimen is required for the study, this field will identify the person, department, or facility that collected the specimen. Either name or ID code, or both, may be present. If the person referenced in this field is also referenced in PRT segment, they must contain the same information. However, if there is a difference, then PRT segment takes precedence.

OBR-11: Specimen Action Code * (ID) 00245

(Definition from OBR.11 in Ch. 4)

Definition: This field identifies the action to be taken with respect to the specimens that accompany or precede this order. The purpose of this field is to further qualify (when appropriate) the general action indicated by the order control code contained in the accompanying ORC segment. For example, when a new order (ORC – "NW") is sent to the lab, this field would be used to tell the lab whether or not to collect the specimen ("L" or "O"). Refer to HL7 Table 0065 – Specimen Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.11 in Ch. 7)

Definition: This field identifies the action to be taken with respect to the specimens that accompany or precede this order. The purpose of this field is to further qualify (when appropriate) the general action indicated by the order control code contained in the accompanying ORC segment. For example, when a new order (ORC – "NW") is sent to the lab, this field would be used to tell the lab whether or not to collect the specimen ("L" or "O"). Refer to HL7 Table 0065 – Specimen Action Code in Chapter 2C, Code Tables, for valid values.

OBR-12: Danger Code (CWE) 00246

(Definition from OBR.12 in Ch. 4)

Definition: This field contains the code and/or text indicating any known or suspected patient or specimen hazards, e.g., patient with active tuberculosis or blood from a hepatitis patient. Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, free text without a code must be preceded by a component delimiter. Refer to Table 0613 - Danger Code in Chapter 2C for valid values.

(Definition from OBR.12 in Ch. 7)

Definition: This field contains the code and/or text indicating any known or suspected patient or specimen hazards, e.g., patient with active tuberculosis or blood from a hepatitis patient. Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, free text without a code must be preceded by a component delimiter. Refer to Table 0613 - Danger Code in Chapter 2C for valid values.

OBR-13: Relevant Clinical Information (CWE) 00247

(Definition from OBR.13 in Ch. 4)

Definition: This field contains additional clinical information about the patient or specimen. This field is used to report the supporting and/or suspected diagnosis and clinical findings on requests for interpreted diagnostic studies where a simple text string or code is sufficient. This field could use all appropriate code sets including SNOMED to message Relevant Clinical Information. If more information is needed, such as date/time of the observation, who observed it, abnormal ranges, etc., or must be provided in further structured format, e.g., structured numeric with units of measure encoded, the Observation/Result group following the OBR should be used. Examples include reporting the amount of inspired carbon dioxide for blood gasses, the point in the menstrual cycle for cervical pap tests, and other conditions that influence test interpretations. Refer to HL7 Table 0916 – Relevant Clinical Information in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.13 in Ch. 7)

Definition: This field contains additional clinical information about the patient or specimen. This field is used to report the supporting and/or suspected diagnosis and clinical findings on requests for interpreted diagnostic studies where a simple text string or code is sufficient. This field could use all appropriate code sets including SNOMED to message Relevant Clinical Information. If more information is needed, such as date/time of the observation, who observed it, abnormal ranges, etc., or must be provided in further structured format, e.g., structured numeric with units of measure encoded, the Observation/Result group following the OBR should be used. Examples include reporting the amount of inspired carbon dioxide for blood gasses, the point in the menstrual cycle for cervical pap tests, and other conditions that influence test interpretations. Refer to HL7 Table 0916 – Relevant Clinical Information in Chapter 2C, Code Tables, for valid values.

OBR-14: Specimen Received Date/Time *

(Definition from OBR.14 in Ch. 4)

Attention: The OBR-14 element was retained for backward compatibility only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7. See SPM in Chapter 7.

(Definition from OBR.14 in Ch. 7)

Attention: The OBR-14 element was retained for backward compatibility only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7. See SPM in Chapter 7.

(Definition from SPM.18 in Ch. 7)

Definition: The specimen received date/time is the time that the specimen is received at the diagnostic service facility. The actual time that is recorded is based on how specimen receipt is managed and may correspond to the time the sample is logged in. This is fundamentally different from SPM-17 Specimen Collection date/time.

OBR-15: Specimen Source

(Definition from OBR.15 in Ch. 4)

Attention: The OBR-15 element was retained for backward compatibility only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7. See SPM in Chapter 7.

(Definition from OBR.15 in Ch. 7)

Attention: The OBR-15 element was retained for backward compatibility only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7. See SPM in Chapter 7.

(Definition from SAC.6 in Ch. 13)

Attention: This field was deprecated and retained for backward compatibilityonly as of v2.5 and withdrawn and removed as of v2.7.

(Definition from TCC.3 in Ch. 13)

Attention: As of version 2.5 this field was deprecated and retained for backward compatibility only and withdrawn as of v2.7.

OBR-16: Ordering Provider

(Definition from ORC.12 in Ch. 4)

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.

(Definition from OBR.16 in Ch. 4)

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred ot the PRT segment as described in Chapter 7.

(Definition from OBR.16 in Ch. 7)

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred ot the PRT segment as described in Chapter 7.

OBR-17: Order Callback Phone Number (XTN) 00250

(Definition from OBR.17 in Ch. 4)

Definition: This field contains the telephone number for reporting a status or a result using the standard format with extension and/or beeper number when applicable.

(Definition from OBR.17 in Ch. 7)

Definition: This field contains the telephone number for reporting a status or a result using the standard format with extension and/or beeper number when applicable.

OBR-18: Placer Field 1 (ST) 00251

(Definition from OBR.18 in Ch. 4)

Definition: This field is user field #1. Text sent by the placer will be returned with the results.

(Definition from OBR.18 in Ch. 7)

Definition: This field is user field #1. Text sent by the placer will be returned with the results.

OBR-19: Placer Field 2 (ST) 00252

(Definition from OBR.19 in Ch. 4)

Definition: This field is similar to placer field #1.

(Definition from OBR.19 in Ch. 7)

Definition: This field is similar to placer field #1.

OBR-20: Filler Field 1 + (ST) 00253

(Definition from OBR.20 in Ch. 4)

Definition: This field is definable for any use by the filler (diagnostic service).

(Definition from OBR.20 in Ch. 7)

Definition: This field is definable for any use by the filler (diagnostic service).

OBR-21: Filler Field 2 + (ST) 00254

(Definition from OBR.21 in Ch. 4)

Definition: This field is similar to filler field #1.

(Definition from OBR.21 in Ch. 7)

Definition: This field is similar to filler field #1.

OBR-22: Results Rpt/Status Chng – Date/Time + (DTM) 00255

(Definition from OBR.22 in Ch. 4)

Definition: This field specifies the date/time when the results were reported or status changed. This conditional field is required whenever the OBR-25 is valued. This field is used to indicate the date and time that the results are composed into a report and released, or that a status, as defined in ORC-5 order status, is entered or changed. (This is a results field only.) When other applications (such as office or clinical database applications) query the laboratory application for un-transmitted results, the information in this field may be used to control processing on the communications link. Usually, the ordering service would want only those results for which the reporting date/time is greater than the date/time the inquiring application last received results.

(Definition from OBR.22 in Ch. 7)

Definition: This field specifies the date/time when the results were reported or status changed. This conditional field is required whenever the OBR-25 is valued. This field is used to indicate the date and time that the results are composed into a report and released, or that a status, as defined in ORC-5 order status, is entered or changed. (This is a results field only.) When other applications (such as office or clinical database applications) query the laboratory application for un-transmitted results, the information in this field may be used to control processing on the communications link. Usually, the ordering service would want only those results for which the reporting date/time is greater than the date/time the inquiring application last received results.

OBR-23: Charge to Practice + (MOC) 00256

(Definition from OBR.23 in Ch. 4)

Definition: This field is the charge to the ordering entity for the studies performed when applicable. The first component is a dollar amount when known by the filler. The second is a charge code when known by the filler (results only).

(Definition from OBR.23 in Ch. 7)

Definition: This field is the charge to the ordering entity for the studies performed when applicable. The first component is a dollar amount when known by the filler. The second is a charge code when known by the filler (results only).

OBR-24: Diagnostic Serv Sect ID (ID) 00257

(Definition from OBR.24 in Ch. 4)

Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to HL7 Table 0074 – Diagnostic Service Section ID in Chapter 2C, Code Tables, for valid entries.

(Definition from OBR.24 in Ch. 7)

Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to HL7 Table 0074 – Diagnostic Service Section ID in Chapter 2C, Code Tables, for valid entries.

(Definition from OM1.49 in Ch. 8)

Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to HL7 Table 0074 – Diagnostic Service Section ID in Chapter 2C, Code Tables, for valid entries. Same as OBR-24.

OBR-25: Result Status + (ID) 00258

(Definition from OBR.25 in Ch. 4)

Definition: This field contains the status of results for this order. This conditional field is required whenever the OBR is contained in a report message. It is not required as part of an initial order.

There are two methods of sending status information. If the status is that of the entire order, use ORC-15-order effective date/time and ORC-5-order status. If the status pertains to the order detail segment, use OBR-25-result status and OBR-22-results rpt/status chng – date/time. If both are present, the OBR values override the ORC values.

This field would typically be used in a response to an order status query where the level of detail requested does not include the OBX segments. When the individual status of each result is necessary, OBX-11-observ result status may be used. Refer to HL7 Table 0123 – Result Status in Chapter 2C, Code Tables, for valid entries.

(Definition from OBR.25 in Ch. 7)

Definition: This field contains the status of results for this order. This conditional field is required whenever the OBR is contained in a report message. It is not required as part of an initial order.

There are two methods of sending status information. If the status is that of the entire order, use ORC-15-order effective date/time and ORC-5-order status. If the status pertains to the order detail segment, use OBR-25-result status and OBR-22-results rpt/status chng – date/time. If both are present, the OBR values override the ORC values.

This field would typically be used in a response to an order status query where the level of detail requested does not include the OBX segments. When the individual status of each result is necessary, OBX-11-observ result status may be used. Refer to HL7 Table 0123 – Result Status in Chapter 2C, Code Tables, for valid entries.

OBR-26: Parent Result + (PRL) 00259

(Definition from OBR.26 in Ch. 4)

Definition: This field is defined to make it available for other types of linkages (e.g., toxicology). This important information, together with the information in OBR-29-Parent Result Obersvation Identifier and OBR-54 Parent Order, uniquely identifies the parent result's OBX segment related to this order. The value of this OBX segment in the parent result is the organism or chemical species about which this battery reports, or the specific result for which this order or observation is a reflex. For example, if the current battery is an antimicrobial susceptibility, the parent results identified OBX contains a result which identifies the organism on which the susceptibility was run. This indirect linkage is preferred because the name of the organism in the parent result may undergo several preliminary values prior to finalization. In the case of a reflex order, if it is necessary to point to the specific result value for which it is in response, OBR-26 enables pointing to that specific OBX segment.

The third component may be used to record the name of the microorganism identified by the parent result directly. The organism in this case should be identified exactly as it is in the parent culture.

We emphasize that this field does not take the entire result field from the parent. It is meant only for the text name of the organism or chemical subspecies identified. This field is included only to provide a method for linking back to the parent result for those systems that could not generate unambiguous Observation IDs and sub-IDs.

This field is present only when the parent result is identified by OBR-29- Result Observation Identifieror OBR-54, Parent Order, and the parent spawns child orders or results for each of many results. (See Chapter 7 for more details about this linkage.)

A second mode of conveying this information is to use a standard observation result segment (OBX). If more than one organism is present, OBX-4-observation sub-ID is used to distinguish them. In this case, the first OBX with subID N will contain a value identifying the Nth microorganism, and each additional OBX with subID N will contain susceptibility values for a given antimicrobial test on this organism.

(Definition from OBR.26 in Ch. 7)

Definition: This field is defined to make it available for other types of linkages (e.g., toxicology). This important information, together with the information in OBR-29-Parent Result Obersvation Identifier and OBR-54 Parent Order, uniquely identifies the parent result's OBX segment related to this order. The value of this OBX segment in the parent result is the organism or chemical species about which this battery reports, or the specific result for which this order or observation is a reflex. For example, if the current battery is an antimicrobial susceptibility, the parent results identified OBX contains a result which identifies the organism on which the susceptibility was run. This indirect linkage is preferred because the name of the organism in the parent result may undergo several preliminary values prior to finalization. In the case of a reflex order, if it is necessary to point to the specific result value for which it is in response, OBR-26 enables pointing to that specific OBX segment.

The third component may be used to record the name of the microorganism identified by the parent result directly. The organism in this case should be identified exactly as it is in the parent culture.

We emphasize that this field does not take the entire result field from the parent. It is meant only for the text name of the organism or chemical subspecies identified. This field is included only to provide a method for linking back to the parent result for those systems that could not generate unambiguous Observation IDs and sub-IDs.

This field is present only when the parent result is identified by OBR-29- Result Observation Identifieror OBR-54, Parent Order, and the parent spawns child orders or results for each of many results. (See Chapter 7 for more details about this linkage.)

A second mode of conveying this information is to use a standard observation result segment (OBX). If more than one organism is present, OBX-4-observation sub-ID is used to distinguish them. In this case, the first OBX with subID N will contain a value identifying the Nth microorganism, and each additional OBX with subID N will contain susceptibility values for a given antimicrobial test on this organism.

OBR-27: Quantity/Timing

(Definition from ORC.7 in Ch. 4)

Attention: The ORC-7 field was retained for backward compatibility only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7. The reader is referred to the TQ1 and TQ2 segments described in sections 4.5.4 and 4.5.5, respectively.

(Definition from OBR.27 in Ch. 4)

Attention: The OBR-27 element was retained for backward compatibility only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7.

(Definition from RXE.1 in Ch. 4A)

Attention: The RXE-1 field was retained for backward compatibilty only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7.

(Definition from RXG.3 in Ch. 4A)

Attention: The RXG-3 field was retained for backward compatibilty only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7.

Note: The contents of fields 3-8 should be identical to the comparable fields in the RXE (RXE-2 thru 5).


(Definition from OBR.27 in Ch. 7)

Attention: The OBR-27 element was retained for backward compatibility only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7.

OBR-28: Result Copies To

(Definition from OBR.28 in Ch. 4)

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. Additional capabilities are now available through thePRT segment following the OBR using the "RCT" (Results Copy To) value in PRT-4 (Participation) from HL7 Table 912 - Participation in Chapter 2C, Code Tables, and referencing the appropriate participant information using other PRT Fields. The PRT segment is further described in Chapter 7 Section 7.3.4 "PRT – Participation Information Segment".

(Definition from OBR.28 in Ch. 7)

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. Additional capabilities are now available through thePRT segment following the OBR using the "RCT" (Results Copy To) value in PRT-4 (Participation) from HL7 Table 912 - Participation in Chapter 2C, Code Tables, and referencing the appropriate participant information using other PRT Fields. The PRT segment is further described in Chapter 7 Section 7.3.4 "PRT – Participation Information Segment".

OBR-29: Parent Results Observation Identifier (EIP) 00261

(Definition from OBR.29 in Ch. 4)

Definition: This field relates a child result to its parent result when a parent child result relationship exists. This field uniquely identifies the order number of the parent result; no other information is required to link the child result with its parent result.

(Definition from OBR.29 in Ch. 7)

Definition: This field relates a child result to its parent result when a parent child result relationship exists. This field uniquely identifies the order number of the parent result; no other information is required to link the child result with its parent result.

OBR-30: Transportation Mode (ID) 00262

(Definition from OBR.30 in Ch. 4)

Definition: This field identifies how (or whether) to transport a patient, when applicable. Refer to HL7 Table 0124 – Transportation Mode in Chapter 2C, Code Tables, for valid codes.

(Definition from OBR.30 in Ch. 7)

Definition: This field identifies how (or whether) to transport a patient, when applicable. Refer to HL7 Table 0124 – Transportation Mode in Chapter 2C, Code Tables, for valid codes.

OBR-31: Reason for Study (CWE) 00263

(Definition from OBR.31 in Ch. 4)

Definition: This field is the code or text using the conventions for coded fields given in the Control chapter (Chapter 2). This is required for some studies to obtain proper reimbursement.

Refer HL7 Table 0951 – Reason for Study in Chapter 2C, Code Tables.

(Definition from OBR.31 in Ch. 7)

Definition: This field is the code or text using the conventions for coded fields given in the Control chapter (Chapter 2). This is required for some studies to obtain proper reimbursement.

Refer HL7 Table 0951 – Reason for Study in Chapter 2C, Code Tables.

OBR-32: Principal Result Interpreter +

(Definition from OBR.32 in Ch. 4)

Definition: This field is retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9.. The reader is referred to the PRT segment described in Chapter 7.

(Definition from OBR.32 in Ch. 7)

Definition: This field is retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9.. The reader is referred to the PRT segment described in Chapter 7.

OBR-33: Assistant Result Interpreter +

(Definition from OBR.33 in Ch. 4)

Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9.. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."

(Definition from OBR.33 in Ch. 7)

Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9.. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."

OBR-34: Technician +

(Definition from OBR.34 in Ch. 4)

Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."

(Definition from OBR.34 in Ch. 7)

Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."

OBR-35: Transcriptionist +

(Definition from OBR.35 in Ch. 4)

Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."

(Definition from OBR.35 in Ch. 7)

Definition: This field was retained for backward compatibility only as of v 2.6 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRTsegment used relative to OBR as described in section 4.5.3.32, "Principal Result Interpreter."

OBR-36: Scheduled Date/Time + (DTM) 00268

(Definition from OBR.36 in Ch. 4)

Definition: This field is the date/time the filler scheduled an observation, when applicable (e.g., action code in OBR-11-specimen action code = "S"). This is a result of a request to schedule a particular test and provides a way to inform the placer of the date/time a study is scheduled (result only).

(Definition from OBR.36 in Ch. 7)

Definition: This field is the date/time the filler scheduled an observation, when applicable (e.g., action code in OBR-11-specimen action code = "S"). This is a result of a request to schedule a particular test and provides a way to inform the placer of the date/time a study is scheduled (result only).

OBR-37: Number of Sample Containers * (NM) 01028

(Definition from OBR.37 in Ch. 4)

Definition: This field identifies the number of containers for a given sample. For sample receipt verification purposes; may be different from the total number of samples which accompany the order.

(Definition from OBR.37 in Ch. 7)

Definition: This field identifies the number of containers for a given sample. For sample receipt verification purposes; may be different from the total number of samples which accompany the order.

OBR-38: Transport Logistics of Collected Sample * (CWE) 01029

(Definition from OBR.38 in Ch. 4)

Definition: This field is the means by which a sample reaches the diagnostic service provider. This information is to aid the lab in scheduling or interpretation of results. Possible answers: routine transport van, public postal service, etc. If coded, requires a user-defined table. Refer to Table 0614 - Transport Logistics of Collected Sample in Chapter 2C for valid values.

(Definition from OBR.38 in Ch. 7)

Definition: This field is the means by which a sample reaches the diagnostic service provider. This information is to aid the lab in scheduling or interpretation of results. Possible answers: routine transport van, public postal service, etc. If coded, requires a user-defined table. Refer to Table 0614 - Transport Logistics of Collected Sample in Chapter 2C for valid values.

OBR-39: Collector's Comment * (CWE) 01030

(Definition from OBR.39 in Ch. 4)

Definition: This field is for reporting additional comments related to the sample. If coded, requires a user-defined table. If only free text is reported, it is placed in the second component with a null in the first component, e.g., ^difficulty clotting after venipuncture and ecchymosis. Refer to Table 0619 - Collector's Comment in Chapter 2C for valid values.

(Definition from OBR.39 in Ch. 7)

Definition: This field is for reporting additional comments related to the sample. If coded, requires a user-defined table. If only free text is reported, it is placed in the second component with a null in the first component, e.g., ^difficulty clotting after venipuncture and ecchymosis. Refer to Table 0619 - Collector's Comment in Chapter 2C for valid values.

OBR-40: Transport Arrangement Responsibility (CWE) 01031

(Definition from OBR.40 in Ch. 4)

Definition: This field is an indicator of who is responsible for arranging transport to the planned diagnostic service. Examples: Requester, Provider, Patient. If coded, requires a user-defined table. Refer to Table 0620 - Transport Arrangement Responsibility in Chapter 2C for valid values.

(Definition from OBR.40 in Ch. 7)

Definition: This field is an indicator of who is responsible for arranging transport to the planned diagnostic service. Examples: Requester, Provider, Patient. If coded, requires a user-defined table. Refer to Table 0620 - Transport Arrangement Responsibility in Chapter 2C for valid values.

OBR-41: Transport Arranged (ID) 01032

(Definition from OBR.41 in Ch. 4)

Definition: This field is an indicator of whether transport arrangements are known to have been made. Refer to HL7 Table 0224 – Transport Arranged in Chapter 2C, Code Tables, for valid codes.

(Definition from OBR.41 in Ch. 7)

Definition: This field is an indicator of whether transport arrangements are known to have been made. Refer to HL7 Table 0224 – Transport Arranged in Chapter 2C, Code Tables, for valid codes.

OBR-42: Escort Required (ID) 01033

(Definition from OBR.42 in Ch. 4)

Definition: This field is an indicator that the patient needs to be escorted to the diagnostic service department. Note: The nature of the escort requirements should be stated in OBR-43-planned patient transport comment. See HL7 Table 0225 – Escort Required in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.42 in Ch. 7)

Definition: This field is an indicator that the patient needs to be escorted to the diagnostic service department. Note: The nature of the escort requirements should be stated in OBR-43-planned patient transport comment. See HL7 Table 0225 – Escort Required in Chapter 2C, Code Tables, for valid values.

OBR-43: Planned Patient Transport Comment (CWE) 01034

(Definition from OBR.43 in Ch. 4)

Definition: This field is the code or free text comments on special requirements for the transport of the patient to the diagnostic service department. If coded, requires a user-defined table. Refer to Table 0621 - Planned Patient Transport Comment in Chapter 2C for valid values.

(Definition from OBR.43 in Ch. 7)

Definition: This field is the code or free text comments on special requirements for the transport of the patient to the diagnostic service department. If coded, requires a user-defined table. Refer to Table 0621 - Planned Patient Transport Comment in Chapter 2C for valid values.

OBR-44: Procedure Code (CNE) 00393

(Definition from OBR.44 in Ch. 4)

Definition: This field contains a unique identifier assigned to the procedure, if any, associated with the charge. Refer to Externally-defined table 0088 – Procedure code in Chapter 2C, Code Tables, for suggested values. This field is a coded data type for compatibility with clinical and ancillary systems.

As of version 2.6, applicable external coding systems include those in the referenced table. If the code set used is in the referenced table, then the coding scheme designation in the table shall be used.

(Definition from FT1.25 in Ch. 6)

Definition: This field contains a unique identifier assigned to the procedure, if any, associated with the charge. Refer to Externally-defined Table 0088 - Procedure Code in Chapter 2C, Code Tables, for suggested values. This field is a coded data type for compatibility with clinical and ancillary systems.

As of v 2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.

Procedure Code Coding Systems (from HL7 Table 0396)

Code

Description

Comment / Source

C4

CPT-4

American Medical Association, P.O. Box 10946, Chicago IL 60610.

C5

CPT-5

(under development – same contact as above)

HCPCS

CMS (formerly HCFA) Common Procedure Coding System

HCPCS: contains codes for medical equipment, injectable drugs, transportation services, and other services not found in CPT4.

HPC

CMS (formerly HCFA )Procedure Codes (HCPCS)

Health Care Financing Administration (HCFA) Common Procedure Coding System (HCPCS) including modifiers.

I10P

ICD-10 Procedure Codes

Procedure Coding System (ICD-10-PCS.) See http://www/hcfa.gov/stats/icd10.icd10.htm for more information.

(Definition from PR1.3 in Ch. 6)

Definition: This field contains a unique identifier assigned to the procedure. Refer to Externally-defined Table 0088 - Procedure Code in Chapter 2C, Code Tables, for suggested values. This field is a CNE data type for compatibility with clinical and ancillary systems.

(Definition from OBR.44 in Ch. 7)

Definition: This field contains a unique identifier assigned to the procedure, if any, associated with the charge. Refer to Externally-defined table 0088 – Procedure code in Chapter 2C, Code Tables, for suggested values. This field is a coded data type for compatibility with clinical and ancillary systems.

As of version 2.6, applicable external coding systems include those in the referenced table. If the code set used is in the referenced table, then the coding scheme designation in the table shall be used.

(Definition from CDM.7 in Ch. 8)

Definition: This field contains the procedure code for procedure, if any, associated with this charge description. Repeating field allows for different procedure coding systems such as CPT4, ICD9. Coded entry made up of code plus coding schema. Refer to Externally-defined Table 0088 - Procedure Code in Chapter 2C, Code Tables, for suggested values.

(Definition from IIM.14 in Ch. 17)

Definition: This field contains a unique identifier assigned to the service item, if any, associated with the charge. In the United States this is often the HCPCS code. Refer to Externally Defined Table 0088 - Procedure Code in Chapter 2C, Code Tables, for suggested values. This field is a CNE data type for compatibility with clinical and ancillary systems.

As of v2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.

Procedure Code Coding Systems

Coding System

Description

Comment

C4

CPT-4

American Medical Association, P.O. Box 10946, Chicago IL 60610.

C5

CPT-5

(under development – same contact as above)

HCPCS

CMS (formerly HCFA) Common Procedure Coding System

HCPCS: contains codes for medical equipment, injectable drugs, transportation services, and other services not found in CPT4.

HPC

CMS (formerly HCFA) Procedure Codes (HCPCS)

Health Care Financing Administration (HCFA) Common Procedure Coding System (HCPCS) including modifiers.

(Definition from ITM.27 in Ch. 17)

Definition: This field contains a unique identifier assigned to the service item, if any, associated with the charge. In the United States this is often the HCPCS code. Refer to Externally defined Table 0088 - Procedure code for suggested values. This field is a CNE data type for compatibility with clinical and ancillary systems. Refer to HL7 Table 0088 – Procedure Coding Systems in Chapter 2C, Code Tables, for valid values.

As of v2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.

(Definition from SCD.32 in Ch. 17)

Definition: The unique identifier indicating the type of procedure performed on the patient with the supplies being sterilized.

Refer to HL7 Table 0088 – Procedure Code in Chapter 2C, Code Tables, for suggested values.

As of v2.6, the known applicable external coding systems include those in the referenced table. If the code set you are using is in this table, then you must use that designation.

OBR-45: Procedure Code Modifier (CNE) 01316

(Definition from OBR.45 in Ch. 4)

Definition: This field contains the procedure code modifier to the procedure code reported in OBR-44-procedure code, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. The modifiers are sequenced in priority according to user entry. In the USA, this is a requirement of the UB and the 1500 claim forms. Multiple modifiers are allowed and the order placed on the form affects reimbursement. Refer to Externally- defined table 0340 – Procedure code modifier in Chapter 2C, Code Tables, for suggested values.

Usage Rule: This field can only be used if OBR-44 – procedure code contains certain procedure codes that require a modifier in order to be billed or performed. For example, HCPCS codes that require a modifier to be precise.

As of version 2.6, applicable external coding systems include those in the referenced table. If the code set used is in the referenced table, then the coding scheme designation in the table shall be used.

(Definition from FT1.26 in Ch. 6)

Definition: This field contains the procedure code modifier to the procedure code reported in FT1-25 - Procedure Code, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. The modifiers are sequenced in priority according to user entry. This is a requirement of the UB and the 1500 claim forms. Multiple modifiers are allowed and the order placed on the form affects reimbursement. Refer to Externally-defined Table 0340 - Procedure Code Modifier in Chapter 2C, Code Tables, for suggested values.

Usage Rule: This field can only be used if FT1-25 - Procedure Code contains certain procedure codes that require a modifier in order to be billed or performed. For example, HCPCS codes that require a modifier to be precise.

As of v 2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.

Procedure Code Modifier Coding Systems (From HL7 Table 0396)

Code

Description

Comment / Source

CPTM

CPT Modifier Code

Available for the AMA at the address listed for CPT above. These codes are found in Appendix A of CPT 2000 Standard Edition. (CPT 2000 Standard Edition, American Medical Association, Chicago, IL).

HPC

CMS (formerly HCFA )Procedure Codes (HCPCS)

Health Care Financing Administration (HCFA) Common Procedure Coding System (HCPCS) including modifiers.

I10P

ICD-10 Procedure Codes

Procedure Coding System (ICD-10-PCS.) See http://www/hcfa.gov/stats/icd10.icd10.htm for more information.

I9C

ICD-9CM

Commission on Professional and Hospital Activities, 1968 Green Road, Ann Arbor, MI 48105 (includes all procedures and diagnostic tests).

ICD10AM

ICD-10 Australian modification

ICD10CA

ICD-10 Canada


(Definition from PR1.16 in Ch. 6)

Definition: This field contains the procedure code modifier to the procedure code reported in field 3, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. Refer to Externally-defined Table 0340 - Procedure Code Modifier in Chapter 2C, Code Tables, for suggested values.

(Definition from OBR.45 in Ch. 7)

Definition: This field contains the procedure code modifier to the procedure code reported in OBR-44-procedure code, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. The modifiers are sequenced in priority according to user entry. In the USA, this is a requirement of the UB and the 1500 claim forms. Multiple modifiers are allowed and the order placed on the form affects reimbursement. Refer to Externally- defined table 0340 – Procedure code modifier in Chapter 2C, Code Tables, for suggested values.

Usage Rule: This field can only be used if OBR-44 – procedure code contains certain procedure codes that require a modifier in order to be billed or performed. For example, HCPCS codes that require a modifier to be precise.

As of version 2.6, applicable external coding systems include those in the referenced table. If the code set used is in the referenced table, then the coding scheme designation in the table shall be used.

(Definition from IIM.15 in Ch. 17)

Definition: This field contains the procedure code modifier to the procedure code reported in IIM-14 Procedure Code, when applicable. Procedure code modifiers are defined by USA regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. Refer to Externally defined Table 0340 - Procedure Code Modifier in Chapter 2C, Code Tables, for suggested values.

As of v2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.

(Definition from ITM.28 in Ch. 17)

Definition: This field contains the procedure code modifier to the procedure code reported in ITM-27, Procedure Code, when applicable. Procedure code modifiers are defined by USA regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. Refer to Externally-defined Table 0340 - Procedure Code Modifier in Chapter 2C, Code Tables, for suggested values.

OBR-46: Placer Supplemental Service Information (CWE) 01474

(Definition from OBR.46 in Ch. 4)

Definition: This field contains supplemental service information sent from the placer system to the filler system for the universal procedure code reported in OBR-4 Universal Service ID. This field will be used to provide ordering information detail that is not available in other specific fields in the OBR segment. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 - Supplemental service information values in Chapter 2C, Code Tables.

This field can be used to describe details such as whether study is to be done on the right or left, for example, where the study is of the arm and the order master file does not distinguish right from left, or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).

(Definition from OBR.46 in Ch. 7)

Definition: This field contains supplemental service information sent from the placer system to the filler system for the universal procedure code reported in OBR-4 Universal Service ID. This field will be used to provide ordering information detail that is not available in other specific fields in the OBR segment. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 - Supplemental service information values in Chapter 2C, Code Tables.

This field can be used to describe details such as whether study is to be done on the right or left, for example, where the study is of the arm and the order master file does not distinguish right from left, or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).

(Definition from AIS.11 in Ch. 10)

Definition: This field contains supplemental service and/or logistical information sent from the placer system to the filler system for the universal procedure code reported in field AIS-3. This field will be used to provide scheduling information detail that is not available in other, specific fields in the AIS segment. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 – Supplemental Service Information Values in Chapter 2C, Code Tables, for valid values.

OBR-47: Filler Supplemental Service Information (CWE) 01475

(Definition from OBR.47 in Ch. 4)

Definition: This field contains supplemental service information sent from the filler system to the placer system for the procedure code reported in OBR-4 Universal Service ID. This field will be used to report ordering information detail that is not available in other specific fields in the OBR segment. Typically it will reflect the same information as was sent to the filler system in OBR-46-Placer supplemental service information unless the order was modified, in which case the filler system will report what was actually performed using this field. Multiple supplemental service information elements may be reported. Refer to User-Defined Table 0411 - Supplemental Service Information Values in Chapter 2C, Code Tables.

This field can be used to describe details such as whether study is to be done on the right or left, for example, where the study is of the arm and the order master file does not distinguish right from left, or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).

(Definition from OBR.47 in Ch. 7)

Definition: This field contains supplemental service information sent from the filler system to the placer system for the procedure code reported in OBR-4 Universal Service ID. This field will be used to report ordering information detail that is not available in other specific fields in the OBR segment. Typically it will reflect the same information as was sent to the filler system in OBR-46-Placer supplemental service information unless the order was modified, in which case the filler system will report what was actually performed using this field. Multiple supplemental service information elements may be reported. Refer to User-Defined Table 0411 - Supplemental Service Information Values in Chapter 2C, Code Tables.

This field can be used to describe details such as whether study is to be done on the right or left, for example, where the study is of the arm and the order master file does not distinguish right from left, or whether the study is to be done with or without contrast (when the order master file does not make such distinctions).

(Definition from AIS.12 in Ch. 10)

Definition: This field contains supplemental service and/or logistical information sent from the filler system to the placer system for the procedure code reported in field AIS-3. This field will be used to report scheduling information details that is not available in other, specific fields in the AIS segment. Typically it will reflect the same information as was sent to the filler system in AIS-11-Placer Supplemental information unless the scheduling was modified in which case the filler system will report what was actually performed using this field. Multiple supplemental service information elements may be reported. Refer to User-defined Table 0411 - Supplemental service information values in Chapter 2C, Code Tables, for valid values..

OBR-48: Medically Necessary Duplicate Procedure Reason (CWE) 01646

(Definition from OBR.48 in Ch. 4)

Definition: This field is used to document why the procedure found in OBR-44 - Procedure Code is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined to be medically necessary. The reason may be coded or it may be a free text entry.

This field is intended to provide financial systems information on who to bill for duplicate procedures.

Refer to User-Defined Table 0476 – Medically Necessary Duplicate Procedure Reason in Chapter 2C, Code Tables, for suggested values.

(Definition from FT1.28 in Ch. 6)

Definition: This field is used to document why the procedure found in FT1-25 - Procedure Code is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined to be medically necessary. The reason may be coded or it may be a free text entry. This field is intended to provide financial systems information on who to bill for duplicate procedures. Refer to User-Defined Table 0476 – Medically Necessary Duplicate Procedure Reason in Chapter 2C, Code Tables, for suggested values.

(Definition from OBR.48 in Ch. 7)

Definition: This field is used to document why the procedure found in OBR-44 - Procedure Code is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined to be medically necessary. The reason may be coded or it may be a free text entry.

This field is intended to provide financial systems information on who to bill for duplicate procedures.

Refer to User-Defined Table 0476 – Medically Necessary Duplicate Procedure Reason in Chapter 2C, Code Tables, for suggested values.

OBR-49: Result Handling (CWE) 01647

(Definition from OBR.49 in Ch. 4)

Definition: Transmits information regarding the handling of the result. For example, an order may specify that the result (e.g., an x-ray film) should be given to the patient for return to the requestor. Refer to HL7 Table 0507 - Observation Result Handling in Chapter 2C, Code Tables, for values. If this field is not populated or if it includes value "CC^Copies Requested", then routine handling is implied and PRT segments assocatied with this OBR with PRT-4 value of "RCT^Result Copies To" identify additional recipients for the results. When this field includes the value "BCC^Blind Copy", those PRT segments, which are included in the order message and in the observation result message sent to the requestor, shall not be included in the observation result messages sent to the copied recipients.

(Definition from OBR.49 in Ch. 7)

Definition: Transmits information regarding the handling of the result. For example, an order may specify that the result (e.g., an x-ray film) should be given to the patient for return to the requestor. Refer to HL7 Table 0507 - Observation Result Handling in Chapter 2C, Code Tables, for values. If this field is not populated or if it includes value "CC^Copies Requested", then routine handling is implied and PRT segments assocatied with this OBR with PRT-4 value of "RCT^Result Copies To" identify additional recipients for the results. When this field includes the value "BCC^Blind Copy", those PRT segments, which are included in the order message and in the observation result message sent to the requestor, shall not be included in the observation result messages sent to the copied recipients.

OBR-50: Parent Universal Service Identifier

(Definition from OBR.50 in Ch. 4)

Definition: This field is retained for backward compatibility only as of v 2.7 and withdrawn as of v2.9.

(Definition from OBR.50 in Ch. 7)

Definition: This field is retained for backward compatibility only as of v 2.7 and withdrawn as of v2.9.

OBR-51: Observation Group ID (EI) 02307

(Definition from OBR.51 in Ch. 4)

Definition: The Observation Group ID is the identifier assigned by the producer of a result to uniquely identify the results associated with this OBR segment. The Observation Group ID is intended to remain the same regardless of the change in status to the result (i.e., it is not a snapshot ID). This field is intended to promote forward compatibility with HL7 V3.

(Definition from OBR.51 in Ch. 7)

Definition: The Observation Group ID is the identifier assigned by the producer of a result to uniquely identify the results associated with this OBR segment. The Observation Group ID is intended to remain the same regardless of the change in status to the result (i.e., it is not a snapshot ID). This field is intended to promote forward compatibility with HL7 V3.

OBR-52: Parent Observation Group ID (EI) 02308

(Definition from OBR.52 in Ch. 4)

Definition: The Parent Observation Group ID field relates this child OBR to its parent OBR segment using the Observation Group ID of the parent result.

(Definition from OBR.52 in Ch. 7)

Definition: The Parent Observation Group ID field relates this child OBR to its parent OBR segment using the Observation Group ID of the parent result.

OBR-53: Alternate Placer Order Number (CX) 03303

(Definition from OBR.53 in Ch. 4)

Definition: This field enables a shorter number to be communicated that is unique within other identifiers.

(Definition from OBR.53 in Ch. 7)

Definition: This field enables a shorter number to be communicated that is unique within other identifiers.

OBR-54: Parent Order (EIP) 00222

(Definition from ORC.8 in Ch. 4)

Definition: This field relates a child order to its parent order when a parent child order relationship exists. The parent child order mechanism is described in HL7 Table 0119 under order control code PA. This field uniquely identifies the parent order; no other information is required to link the child order with its parent order. It can be used to link the order to the results that triggered this order (e.g., a reflex order) or other order it relates to as an occurrence. This field repeats to allow linking to more than one parent, if necessary.

The first component has the same format as ORC-2-Placer Order Number (Section 4.5.3.2, "Placer Order Number (EI) 00216"). The second component has the same format as ORC-3-Filler Order Number (Section 4.5.3.3, "Filler Order Number (EI) 00217"). The components of the placer order number and the filler order number are transmitted in sub-components of the two components of this field.

Note that ORC-8 – Parent Order is equivalent to OBR-54 – Parent Order, but neither one is the same as OBR-29 – Result Observation Identifier.

Condition: Where the message has matching ORC/OBR pairs, ORC-8 and OBR-54 Must carry the same value.

(Definition from OBR.54 in Ch. 4)

Definition: This field relates a child order to its parent order when a parent child order relationship exists. The parent child order mechanism is described in HL7 Table 0119 – Order Control Codes in Chapter 2C, Code Tables, under order control code PA. This field uniquely identifies the parent orders; no other information is required to link the child order with its parent orders. It can be used to express that this order is a reflex being a consequence of original results referred here.

The first component has the same format as ORC-2-placer order number (Section 4.5.3.2, "Placer Order Number (EI) 00216"). The second component has the same format as ORC-3-filler order number (Section 4.5.3.3, "Filler Order Number (EI) 00217"). The components of the placer order number and the filler order number are transmitted in sub-components of the two components of this field.

Note that ORC-8 – Parent Order is equivalent to OBR-54-Parent Order, but neither one is the same as OBR-29-Parent Result Obersvation Identifier .

Condition: Where the message has matching ORC/OBR pairs, ORC-8 and OBR-54 must carry the same value.

(Definition from OBR.54 in Ch. 7)

Definition: This field relates a child order to its parent order when a parent child order relationship exists. The parent child order mechanism is described in HL7 Table 0119 – Order Control Codes in Chapter 2C, Code Tables, under order control code PA. This field uniquely identifies the parent orders; no other information is required to link the child order with its parent orders. It can be used to express that this order is a reflex being a consequence of original results referred here.

The first component has the same format as ORC-2-placer order number (Section 4.5.3.2, "Placer Order Number (EI) 00216"). The second component has the same format as ORC-3-filler order number (Section 4.5.3.3, "Filler Order Number (EI) 00217"). The components of the placer order number and the filler order number are transmitted in sub-components of the two components of this field.

Note that ORC-8 – Parent Order is equivalent to OBR-54-Parent Order, but neither one is the same as OBR-29-Parent Result Obersvation Identifier .

Condition: Where the message has matching ORC/OBR pairs, ORC-8 and OBR-54 must carry the same value.

OBR-55: Action Code (ID) 00816

(Definition from OH1.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH2.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH3.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH4.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from ORC.35 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when either ORC-2 and/or ORC 3 is valued with a unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from OBR.55 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when either an OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from IPC.10 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when the combination of IPC-1, IPC-2, IPC-3, and IPC-4 represents a unique identifier according to Chapter 2, Section 2.10.4.2.

(Definition from BPX.22 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BPX is uniquely identified sufficiently within the specific implementation using BPX-17 or BPX-6 as agreed to by the trading partners and in accordance with Chapter 2, Section 2.10.4.2.

(Definition from BTX.21 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BTX is uniquely identified sufficiently within the specific implementation using BTX-20 or BTX-3 as agreed to by the trading partners in accordance with Chapter 2, Section 2.10.4.2.

(Definition from DON.34 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an DON is uniquely identified sufficiently within the specific implementation using DON-1 in accordance with Chapter 2, Section 2.10.4.2.

(Definition from BUI.13 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BUI is uniquely identified sufficiently within the specific implementation using BUI-2 in accordance with Chapter 2, Section 2.10.4.2

(Definition from RXV.22 in Ch. 4A)

Definition: The intended handling by the receiver of the infusion order is represented by this segment. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from CDO.2 in Ch. 4A)

Definition: The Action Code indicates whether the cumulative dosage segment is intended to be added, deleted, updated, or did not change. If the field is not valued in any CDO segments for the order, the segments are considered to have been sent in snapshot mode. If some but not all CDO segments for the order do not have the action code valued, the default value is Add. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.55 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an either OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from OBX.31 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an OBX-21 is valued in accordance with guidance in Chapter 2, Section 2.10.4.2.

(Definition from SPM.35 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an SPM-2 or SPM-31 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from PRT.2 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.

(Definition from CSR.17 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when CSR-1 and CSR-4, or CSR-2 and CSR-5 are valued as agreed to by the trading partners in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from CTI.4 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when CTI-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from SHP.12 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when SHP-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from PAC.9 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when PAC-2 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from GOL.1 in Ch. 12)

Definition: The action code field gives the intent of the problem or goal. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from PRB.1 in Ch. 12)

Definition: This field contains the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from PTH.1 in Ch. 12)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from DEV.1 in Ch. 17)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.

OBX - Observation/Result Segment

The OBX segment is used to transmit a single observation or observation fragment. It represents the smallest indivisible unit of a report. The OBX segment can also contain encapsulated data, e.g., a CDA document or a DICOM image.

Its principal mission is to carry information about observations in report messages. But the OBX can also be part of an observation order (see Chapter 4, section 4.4, "General Trigger Events & Message Definitions"). In this case, the OBX carries clinical information needed by the filler to interpret the observation the filler makes. For example, an OBX is needed to report the inspired oxygen on an order for a blood oxygen to a blood gas lab, or to report the menstrual phase information which should be included on an order for a pap smear to a cytology lab. Appendix 7A includes codes for identifying many of the pieces of information needed by observation producing services to properly interpret a test result. OBX is also found in other HL7 messages that need to include patient clinical information.

HL7 Attribute Table - OBX - Observation/Result Segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
OBX
1 00569 Set ID – OBX [0..1] [1..4]
SI
2

00570 Value Type MAY
True:
False: 		C
[1..1]
[0..1] 		[2..3]
0125 Value Type
ID
3 00571 Observation Identifier SHALL [1..1]
0622
CWE
4

00572 Observation Sub-ID MAY
True:
False: 		C=
[1..1]
[0..1] 		20
OG
5

00573 Observation Value MAY
True:
False: 		C
[1..1]
[0..1]
Varies
6 00574 Units [0..1]
0623
CWE
7 00575 Reference Range = [0..1] 60
ST
8 00576 Interpretation Codes [0..*]
0078 Interpretation Codes
CWE
9 00577 Probability # [0..1] 5
NM
10 00578 Nature of Abnormal Test [0..*] [1..2]
0080 Nature of Abnormal Testing
ID
11 00579 Observation Result Status SHALL [1..1] [1..1]
0085 Observation Result Status Codes Interpretation
ID
12 00580 Effective Date of Reference Range [0..1]
DTM
13 00581 User Defined Access Checks = [0..1] 20
ST
14 00582 Date/Time of the Observation [0..1]
DTM
15 00583 Producer's ID B [0..1]
0624
CWE
16 00584 Responsible Observer B [0..*]
XCN
17 00936 Observation Method [0..*]
0626
CWE
18 01479 Equipment Instance Identifier B [0..*]
EI
19 01480 Date/Time of the Analysis [0..1]
DTM
20 02179 Observation Site [0..*]
0163 Body Site
CWE
21 02180 Observation Instance Identifier [0..1]
EI
22

02182 Mood Code MAY
True:
False: 		C
[1..1]
[0..1]
0725 Mood Codes
CNE
23 02283 Performing Organization Name B [0..1]
XON
24 02284 Performing Organization Address B [0..1]
XAD
25 02285 Performing Organization Medical Director B [0..1]
XCN
26 02313 Patient Results Release Category [0..1] [1..10]
0909 Patient Results Release Categorization Scheme
ID
27 03308 Root Cause [0..1]
0914 Root Cause
CWE
28 03309 Local Process Control [0..*]
0915
CWE
29 03432 Observation Type [0..1]
0936
ID
30 03475 Observation Sub-Type [0..1]
0937
ID
31 00816 Action Code [0..1] [2..2]
0206 Segment Action Code
ID
32

03510 Observation Value Absent Reason MAY
True:
False: 		C
[1..1]
[0..1]
0960
CWE
33 02454 Observation Related Specimen Identifier [0..*]
EIP

OBX-1: Set ID – OBX (SI) 00569

Definition: This field contains the sequence number. For compatibility with ASTM.

OBX-2: Value Type (ID) 00570

(Definition from OBX.2 in Ch. 7)

Definition: This field defines the data type of OBX-5, Observation Value. If OBX-5, Observation Value, is valued then OBX-2, Value Type, SHALL be valued. When OBX-5, Observation Value, is not valued, OBX-2 Value Type MAY be valued to represent a data type used to value the observation expressed in OBX-3, Observation Identifier. See HL7 Table 0125 – Value Types for valid values.

Condition: This field is required if OBX-5, Observation Value, is valued.

For example, if the value is 'CWE' then the result in OBX-5 must be a coded entry or text or both. As of v 2.7, the ST data type may not be used to transmit data that can be more precisely transmitted using other data types, e.g. SN when comparative symbols are needed.

The RP value (reference pointer) must be used if the OBX-5 contains a pointer to the data e.g., a URL of an image. The receiving system can use this reference pointer whenever it needs access to the actual data through other interface standards, e.g., DICOM, or through appropriate data base servers.

The structured numeric (SN) data type provides for reporting ranges (e.g., 3-5 or 10-20), titres (e.g., 1:10), and out-of-range indicators (e.g., >50) in a structured and computer-interpretable way.

We allow the FT data type in the OBX segment, but its use is discouraged. Formatted text usually implies a meaningful structure, e.g., a list of three independent diagnoses reported on different lines. But ideally, the structure in three independent diagnostic statements would be reported as three separate OBX segments.

TX should not be used except to send large amounts of text. In the TX data type, the repeat delimiter can only be used to identify paragraph breaks. Use ST to send short, and possibly encodable, text strings.

CDA documents are to be exchanged in the OBX segment in any message that can exchange documents (such as MDM or ORU). Within the OBX segment, the MIME package is encoded as an encapsulated (ED) data type.

(Definition from OM3.7 in Ch. 8)

Definition: This field contains the allowed data type for a single categorical observation (code A or C in OM1-18 - Nature of Observation). Refer to HL7 Table 0125 – Value Type in Chapter 2C, Code Tables, for valid values.

OBX-3: Observation Identifier (CWE) 00571

Definition: This field contains a unique identifier for the observation. The format is that of the Coded Element (CWE). Example: "8625-6^P-R interval^LN". Refer to Table 0622 - Observation Identifier in Chapter 2C for valid values.

In most systems the identifier will point to a master observation table that will provide other attributes of the observation that may be used by the receiving system to process the observations it receives. A set of message segments for transmitting such master observation tables is described in Chapter 8. The relation of an observation ID to a master observation table is analogous to the relationship between a charge code (in a billing record) and the charge master.

When local codes are used as the first identifier in this field we strongly encourage sending a universal identifier as well to permit receivers to equivalence results from different providers of the same service (e.g., a hospital lab and commercial lab that provides serum potassium to a nursing home). LOINC® is one possible universal and HL7-approved code system for the Observation identifier. It covers observations and measurements, such as laboratory tests, physical findings, radiology studies, and claims attachments. See HL7 Table 0396 – Coding System, the HL7 www list server and Appendix X2 of ASTM E1467 for neurophysiology tests, or it can be obtained from www.regenstrief.org/loinc/loinc.htm.

The use of suffixes as described in section 7.2.4 and section 7.2.5has been deprecated as of v 2.7.

OBX-4: Observation Sub-ID (OG) 00572

Definition: This field is used to distinguish between multiple OBX segments with the same observation ID organized under one OBR. Starting with V2.8.2 the data type was changed from ST to OG to enable improved structured grouping of observation segments. In this enhanced mode, the first component provides backwards compatibility with existing grouping schemes, while the additional components can be used for improved structures as defined in specific conformance profiles. For example, a chest X-ray report might include three separate diagnostic impressions. The standard requires three OBX segments, one for each impression. By putting a 1 in the Sub-ID of the first of these OBX segments, 2 in the second, and 3 in the third, we can uniquely identify each OBX segment for editing or replacement.

The sub-identifier is also used to group related components in reports such as surgical pathology. It is traditional for surgical pathology reports to include all the tissues taken from one surgical procedure in one report. Consider, for example, a single surgical pathology report that describes the examination of gallbladder and appendix tissue. This report would be transmitted roughly as shown in Figure 7-2.

Figure 7-2. Example of sub-identifier usage – enhanced mode

OBR|1||1234^LAB|11529-5^Study report^LN|...<cr>

OBX|1|CWE|31208-2^Specimen source [Identifier] of Unspecified specimen^LN|^1^1^1|8231008^Gallbladder structure (body structure)^SCT|...<cr>

OBX|2|TX|22634-0^Path report.gross observation^LN|^1^2^1|THIS IS A NORMAL GALLBLADDER|...<cr>

OBX|3|TX|22635-7^Path report.microscopic observation^LN|^1^3^1|MICROSCOPIC EXAM SHOWS HISTOLOGICALLY NORMAL GALLBLADDER TISSUE|...<cr>

OBX|4|CWE|34574-4^Path report.final diagnosis^LN|^1^4^1|300355005^Gallbladder normal (finding)^SCT|...<cr>

OBX|5|CWE|31208-2^Specimen source [Identifier] of Unspecified specimen^LN|^2^1^1|66754008^Appendix structure (body structure)^SCT|...<cr>

OBX|6|TX|22634-0^Path report.gross observation^LN|^2^2^1|THIS IS A RED, INFLAMED, SWOLLEN, BOGGY APPENDIX|...<cr>

OBX|7|TX|22635-7^Path report.microscopic observation^LN|^2^3^1|INFILTRATION WITH MANY PMN's - INDICATING INFLAMATORY CHANGE|...<cr>

OBX|8|CWE|34574-4^Path report.final diagnosis^LN|^2^4^1|M-40000^INFLAMMATION NOS^SNM|...<cr>

The example in Figure 7-2 has two segments for each component of the report, one for each of the two tissues. Thus, there are two "31208-2^Specimen source [Identifier] of Unspecified specimen^LN" segments; there are two "22634-0^Path report.gross observation^LN" segments, and there are two "22635-7^Path report.microscopic observation^LN" segments. Segments that apply to the gallbladder all have the sub-identifier 1. Segments that apply to the appendix all have sub-identifier 2.

The observation sub ID has other grouping uses. It can be used to organize the reporting of some kinds of fluid intakes and outputs. For example, when intake occurs through multiple intravenous lines, a number of separate observations (OBX segments), the intake volume, the type of intake (Blood, D5W, Plasma, etc.), the site of the IV line, etc. may be needed for each intravenous line, each requiring a separate OBX segment. If more than one IV line is running, we can logically link all of the OBX segments that pertain to the first IV line by assigning them an observation sub ID of 1. We can do the same with the second IV line by assigning them a sub ID 2 and so on. The same would apply to the outputs of surgical drains when there are multiple such drains.

The use of the sub ID to distinguish repeating OBXs for the same observation ID is really a special case of using the sub ID to group, as can be seen if we picture the OBX segments in Figure 7-2 as part of a table where the rows correspond to a particular species of observation and the cells correspond to the sub ID numbers that would be associated with each corresponding OBX.

Distinct Observations

88304&ANT

22634-0^Path report.gross observation^LN

22635-7^Path report.microscopic observation^LN

34574-4^Path report.final diagnosis^LN

Sub ID 1st Group

1

1

1

1

Sub ID 2nd Group

2

2

2

2

The use of Sub IDs to group results is equivalent to defining a table, and the use of sub IDs to distinguish repeats is just a special case, represented by one column in this table.

However, this approach introduces ambiguities if we have a set of repeating observations within a group, e.g., if the appendix observations include two impressions as in the 8th and 9th OBXs shown in Figure 7-3. This really represents the existence of a row nested within a single cell of the table given above.

Figure 7-3. Example of sub-identifier usage – original mode

OBX|1|CWE|880304&ANT|1|T57000^GALLBLADDER^SNM|...<cr>

OBX|2|TX|22634-0^Path report.gross observation^LN|1|THIS IS A NORMAL GALL BLADDER|...<cr>

OBX|3|TX|22635-7^Path report.microscopic observation^LN|1|MICROSCOPIC EXAMINATION SHOWS HISTOLOGICALLY

    NORMAL GALLBLADDER TISSUE|...<cr>

OBX|4|CWE|34574-4^Path report.final diagnosis^LN|1|M-00100^NML^SNM|...<cr>

OBX|5|CWE|880304&ANT|2|T57000^APPENDIX^SNM|...<cr>

OBX|6|TX|22634-0^Path report.gross observation^LN|2|THIS IS A RED, INFLAMED APPENDIX|...<cr>

OBX|7|TX|22635-7^Path report.microscopic observation^LN|2|INFLAMMATION WITH MANY PUS CELLS-ACUTE INFLAMMATION|...<cr>

OBX|8|CWE|34574-4^Path report.final diagnosis^LN|2|M-40000^INFLAMMATION NOS^SNM|...<cr>

OBX|9|CWE|34574-4^Path report.final diagnosis^LN|2|M-30280^FECALITH^SNM|...<cr>

The text under OBX-5-observation value provides guidance about dealing with two OBXs with the same observation ID and observation sub IDs. They are sent and replaced as a unit. However, some systems will take this to mean that the set of OBXs is to be combined into one composite observation in the receiving system. In original mode, this could use a dot and a string (similar to the Dewey Decimal system) notation that would be used when users wish to distinguish each of the repeats within one type, or results within a cell for editing and correction purposes. Using this system, Figure 7-3 would become 7-4. If there are cases where such nesting occurs at even deeper levels, this approach could be extended, although with the introduction of the OG data type we suggest the use of components 2-4 as described in Figure 7-2.

Figure 7-4. Example of sub-identifier usage – original mode with nesting

OBX|1|CWE||31208-2^Specimen source [Identifier] of Unspecified specimen^LN|1|28231008^Gallbladder structure (body structure)^SCT|...<cr>

OBX|2|TX|22634-0^Path report.gross observation^LN|1|THIS IS A NORMAL GALL BLADDER|...<cr>

OBX|3|TX|22635-7^Path report.microscopic observation^LN|1|MICROSCOPIC EXAMINATION SHOWS HISTOLOGICALLY

    NORMAL GALLBLADDER TISSUE|...<cr>

OBX|4|CWE|34574-4^Path report.final diagnosis^LN|1|300355005^Gallbladder normal (finding)^SCT|...<cr>

OBX|5|CWE|31208-2^Specimen source [Identifier] of Unspecified specimen^LN|2|66754008^Appendix structure (body structure)^SCT|...<cr>

OBX|6|TX|22634-0^Path report.gross observation^LN|2|THIS IS A RED, INFLAMED APPENDIX|...<cr>

OBX|7|TX|22635-7^Path report.microscopic observation^LN|2|INFLAMMATION WITH MANY PUS CELLS-ACUTE INFLAMMATION|...<cr>

OBX|8|CWE|34574-4^Path report.final diagnosis^LN|2.1|M-40000^INFLAMMATION NOS^SNM|...<cr>

OBX|9|CWE|34574-4^Path report.final diagnosis^LN|2.2|M-30280^FECALITH^SNM|...<cr>

Use a null or 1 when there is no need for multiples.

If the observation includes a number of OBXs with the same value for the observation ID OBX-3, then one must use different values for the sub-ID. If there is no need to group or sequence any further, the original mode can continue to be used to ensure uniqueness of OBX as shown in the example below of an electrocardiograph chest radiograph report with three diagnostic impressions, using 1,2,3 in the sub-ID field to distinguish the three separate results.

Figure 7-5. Example of Sub-ID used to distinguish three independent results with the same observation ID – without grouping/sequencing

OBX|1|CWE|8601-7^EKG IMPRESSION ^LN|1|^atrial fibrillation|...<cr>

OBX|2|CWE|8601-7^EKG IMPRESSION ^LN|2|^OLD SEPTAL MYOCARDIAL INFARCT|...<cr>

OBX|3|CWE|8601-7^EKG IMPRESSION ^LN|3|^poor R wave progression|...<cr>

OBX-5: Observation Value (Varies) 00573

Definition: This field contains the value observed by the observation producer. OBX-2-value type contains the data type for this field according to which observation value is formatted. It is not a required field because some systems will report only the Interpretation Codes (OBX-8), especially in product experience reporting. The length of the observation field is variable, depending upon OBX-2-value type. This field may repeat for multipart, single answer results.

Representation

This field contains the value related to the OBX-3-observation identifier of the same segment. Depending upon the observation, the data type may be a number (e.g., a respiratory rate), a coded answer (e.g., a pathology impression recorded as SNOMED), or a date/time (the date/time that a unit of blood is sent to the ward). An observation value is always represented as the data type specified in OBX-2-value type of the same segment. Whether numeric or short text, the answer shall be recorded in ASCII text.

Reporting logically independent observations

The main sections of dictated reports, such as radiologic studies or history and physicals, are reported as separate OBX segments. In addition, each logically independent observation should be reported in a separate OBX segment, i.e., one OBX segment should not contain the result of more than one logically independent observation, unless it is part of a list of like concepts that belong together (e.g., a list of conditions tested for in newborn screening or mutations looked for in genomic testing). This requirement is included to assure that the contents of OBX-6-units, OBX-8-interpretation codes, and OBX-9-probability can be interpreted unambiguously. This means that all other OBX field values apply equally to the whole of OBX-5 noting that OBX-6 does not apply in the case of coded values. The electrolytes and vital signs batteries, for example, would each be reported as four separate OBX segments. Two diagnostic impressions, e.g., congestive heart failure and pneumonia, would also be reported as two separate OBX segments whether reported as part of a discharge summary or chest X-ray report. Similarly, two bacterial organisms isolated in a single bacterial culture would be reported as two separate OBX segments.

Though two independent diagnostic statements cannot be reported in one OBX segment, unless they represent elements of a single list to which all other OBX field values apply equally, multiple categorical responses are allowed (usually as CWE data types separated by repeat delimiters), so long as they are fragments (modifiers) that together construct one diagnostic statement. Right upper lobe (recorded as one code) and pneumonia (recorded as another code), for example, could be both reported in one OBX segment. Such multiple "values" would be separated by repeat delimiters. The other example where use of repeat delimiters is allowed for coded values would be a list of conditions or mutations tested for to provide reference for the test results reported in related, but independent OBX segments. Multiple answers to a single question (for example mark all that apply type questions) could also be handled using this approach. It is important to state that ANY independent observation, that may require parent-child linking to additional tests, such as reflex testing, SHALL NOT be included in a single OBX-5 field using repeat delimiters, nor any list elements that require variations in the values of other OBX field values.

The following provides an example of how this may be communicated for 10 Cystic Fibrosis mutations, where the mutations are highlighted in red font (note that some labs test for as many as 140 mutations):

OBX|1|CWE|21656-4^CFTR gene mutations tested for in Blood or Tissue by Molecular genetics method Nominal ^LN|1|c.254G>A^^HGVS~c.350G>A^^HGVS~c.489+1G>T^^HGVS~c.579+1G>T^^HGVS~c.1000C>T^^HGVS~c.1040G>C^^HGVS~c.1364C>A^^HGVS~c.1519_1521del^^HGVS~c.1521_1523del^^HGVS~c.1585-1G>A^^HGVS|||N|||F

Multiple OBX segments with the same observation ID and Sub ID

In some systems, a single observation may include fragments of more than one data type. The most common example is a numeric result followed by coded comments (CWE). In this case, the logical observation can be sent in more than one OBX segment. For example, one segment of numeric data type for the numeric result and another segment of CWE data type for coded comments. If the producer was reporting multiple coded comments they would all be sent in one OBX segment separated by repeat delimiters because they all modified a single logical observation. Multiple OBX segments with the same observation ID and sub ID should always be sent in sequence with the most significant OBX segment (the one that has the normal flag/units and or reference range and status flag) first. The value of OBX-6 through 12 should be null in any following OBX segments with the same OBX-3-observation identifier and OBX-4-observation sub-ID. For the purpose of replacement or deletion, multiple OBX segments with the same observation ID and sub ID are treated as a unit. If any are replaced or deleted, they all are replaced.

Coded values

When an OBX segment contains values of CWE data types, the observations are stored as a combination of codes and/or text. In Section 7.8.3, "CSS - Clinical Study Data Schedule Segment," examples of results that are represented as CWE data types are shown in the first and second OBX segments of OBR 1 and the first and second OBX segments of OBR 2. The observation may be an observation battery ID (for recommended studies), a diagnostic code or finding (for a diagnostic impression), or an anatomic site for a pathology report, or any of the other kinds of coded results.

It is not necessary to always encode the information stored within a coded observation. For example, a chest X-ray impression could be transmitted as pure text even though it has a CWE data type. In this case, the test must be recorded as the second component of the result code, e.g.,

OBX|1|CWE|19005^X-Ray Impression^LN|1|^CONGESTIVE HEART FAILURE.|...<cr>

However, separate impressions, recommendations, etc., even if recorded as pure text, should be recorded in separate result segments. That is, congestive heart failure and pneumonia should not be sent as:

OBX|1|CWE|19005^X-Ray Impression^LN|1|^CONGESTIVE HEART FAILURE AND PNEUMONIA|...<cr>

but as:

OBX|1|CWE|19005^X-Ray Impression^LN|1|^CONGESTIVE HEART FAILURE|...<cr>

OBX|2|CWE|19005^X-Ray Impression^LN|2|^PNEUMONIA|....<cr>

Even better would be fully-coded results that include computer understandable codes (component 1) instead of, or in addition to, the text description (component 2). One may include multiple values in a CWE value and these can be mixtures of code and text, but only when they are needed to construct one diagnosis, impression, or concept. When text follows codes as an independent value it would be taken as a modifier or addenda to the codes. E.g.,

OBX|1|CWE|19005-8^X-ray impression^LN~29548-5^DiagnosisImpPatient^LN |1|428.0^CONGESTIVE HEART FAILURE^I9C~^MASSIVE HEART|...<cr>

  • The text in component 2 should be an accurate description of the code in component 1. Likewise, if used, the text in component 5 should be an accurate description of the code in component 4.

  • Insertion of CDA within an OBX:

CDA documents are to be exchanged in the OBX segment. The value of OBX-2-Value Type should be set to 'ED'. OBX-5-Observation Value contains the MIME package encoded as an encapsulated data type. The components should be valued as follows:

  • Set the value of OBX-5.2-Type of Data to 'multipart.'

  • Set the value of OBX-5.3-Data Subtype to '-hl7-cda-level-one.'

  • Set the value of OBX-5.4-Encoding to 'A'. (Note that a MIME package is not itself Base64-encoded. Rather entities within the MIME package are Base64-encoded. A MIME package is sent as ASCII text. Therefore, the correct value is 'A' not 'Base64.'

  • Set the value of OBX-5.5-Data to equal the MIME package. Every entity within the MIME package must be Base64-encoded. As stated in Chapter 2, "the data component must be scanned before transmission for HL7 delimiter characters (and other non-printing ASCII or non-ASCII characters such as LineFeed), and any found must be escaped by using the HL7 escape sequences defined in Section 2.7 'Use of escape sequences in text fields.' On the receiving application, the data field must be de-escaped after being parsed." As a result, CR/LF sequences required in the MIME package need to be escaped (i.e., converted to '\X0D0AVALUE#39;) prior to transmission. The content type of the first MIME entity is set to 'application/x-hl7-cda-level-one+xml', and should contain the CDA document itself. Multimedia objects referenced by the CDA document that need to be transmitted within the CDA document are to be placed in successive entities of the MIME package.

OBX-6: Units (CWE) 00574

(Definition from OBX.6 in Ch. 7)

Definition: This field contains the units of measurement for the value in OBX-5, Observation Value. Coding system from which the values may be drawn include, UCUM, ISO+, ANSI X3.50 - 1986 and site specific (local) coding systems. Considering Version 3 direction and consistent use of V2 and V3 messages/documents within an organization, use of UCUM is strongly recommended. Refer to Table 0623 - Units in Chapter 2C for valid values.

Note that OBX-6 applies to both OBX-5.2 and OBX-5.4 if OBX-2 = “SN”.

(Definition from TCC.13 in Ch. 13)

Definition: This field is the units that have a data type of CWE. The default coding system for the units codes consists of the ISO+ abbreviation for a single case unit (ISO 2955-83) plus extensions, that do not collide with ISO abbreviations (see Chapter 7, section 7.4.2.6). We designate this coding system as ISO+. Both the ISO unit's abbreviations and the extensions are defined in Chapter 7, section 7.4.2.6.2 and listed in Figure 7-9. The ISO+ abbreviations are the codes for the default coding system. Consequently, when ISO+ units are being used, only ISO+ abbreviations need be sent, and the contents of the units field will be backward compatible to HL7 Version 2.1. For more information on this field see reference Chapter 7, section 7.4.2.6.

These units apply to fields "Endogenous content of pre-dilution diluent" and "Equipment dynamic range".

Refer to Table 0788 - Units in Chapter 2C for valid values.

OBX-7: Reference Range (ST) 00575

Components: for numeric values in the format:

  1. lower limit-upper limit (when both lower and upper limits are defined, e.g., for potassium 3.5 - 4.5)

  2. > lower limit        (if no upper limit, e.g., >10)

  3. < upper limit        (if no lower limit, e.g., <15)

alphabetical values: the normal value may be reported in this location

Definition: When the observation quantifies the amount of a toxic substance, then the upper limit of the range identifies the toxic limit. If the observation quantifies a drug, the lower limits identify the lower therapeutic bounds and the upper limits represent the upper therapeutic bounds above which toxic side effects are common.

OBX-8: Interpretation Codes (CWE) 00576

Definition: One or more codes specifying a categorical assessment of the observation value (OBX.5), such as "Normal", "Abnormal", "Positive", "Negative", "Resistant", "Susceptible", etc.

This field may also be used to convey an assessment of an observation where no legitimate result may be obtained. This includes laboratory assays that are rejected due to the presence of interfering substances, specimen toxicity or failure of quality control.

As a CWE data type, this field may be populated with either HL7-defined codes or codes derived from other code systems (such as SNOMED). See User-defined Table 0078 – Interpretation Code for potential entries.

When the filler can discern the normal status of a textual report, such as chest X-ray reports or microbiologic culture, these should be reported as "N" when normal and "A"when abnormal. Multiple codes, e.g., abnormal and worse, would be separated by a repeat delimiter, e.g., "A~W".

Results may also be reported in shorthand by reporting the normalcy status without specifying the exact numeric value of the result. Such shorthand is quite common in clinical notes, where physicians will simply say that the glucose result was normal. Such shorthand reporting is also seen in drug experience reporting. In such cases, the result can be reported in the OBX by reporting the interpretation code in OBX-8-Interpretation Codes without specifying any value in OBX-5-observation value.

OBX-9: Probability (NM) 00577

Definition: This field contains the probability of a result being true for results with categorical values. It mainly applies to discrete coded results. It is a decimal number represented as an ASCII string that must be between 0 and 1, inclusive.

OBX-10: Nature of Abnormal Test (ID) 00578

Definition: This field contains the nature of the abnormal test. Refer to HL7 Table 0080 - Nature of abnormal testing for valid values. As many of the codes as apply may be included, separated by repeat delimiters. For example, normal values based on age, sex, and race would be codes as "A~S~R".

The constraints on the use of the codes in this table must be consistent with those defined in the PID segment, specifically PID-35-Species Code, PID-36-Breed Code and PID-37-Strain.

OBX-11: Observation Result Status (ID) 00579

Definition: This field contains the observation result status. Refer to HL7 table 0085 - Observation result status codes interpretation for valid values. This field reflects the current completion status of the results for one Observation Identifier.

It is a required field. Previous versions of HL7 stated this implicitly by defining a default value of "F." Code F indicates that the result has been verified to be correct and final. Code W indicates that the result has been verified to be wrong (incorrect); a replacement (corrected) result may be transmitted later. Code C indicates that data contained in the OBX-5-observation value field are to replace previously transmitted (verified and) final result data with the same observation ID (including suffix, if applicable) and observation sub-ID usually because the previous results were wrong. Code D indicates that data previously transmitted in a result segment with the same observation ID (including suffix) and observation sub-ID should be deleted. When changing or deleting a result, multiple OBX segments with the same observation ID and observation sub-ID are replaced or deleted as a unit. Normal progression of results through intermediate (e.g., 'gram positive cocci') to final (e.g., 'staphylococcus aureus') should not be transmitted as C (correction); they should be transmitted as P (depending upon the specific case) until they are final.

If an observation involves multiple OBX segments with the same observation ID (including suffix) and observation sub-ID, the observation result status applies to all OBX segments, except where the value is D or X. The value of D or X is applicable only to the individual OBX. All other OBX segments with the same Observation ID and observation sub-ID must have the same value.

In the case of coding systems such as LOINC, the preceding rules typically mean that this field applies to a single OBX segment.

There are situations where the observation battery required for the order needs to be dynamically specified at the time of ordering. That is, this battery is then defined by the set of OBX segments transmitted along with the order and generated by the placing system. For example, timed measurements of serum glucose challenge tests may vary among laboratories. One institution may report them at –30, -15, 0, 30, 60, and 120 minutes, while another may report them at –30, 0, 30, 60, 90, and 120 minutes. Master file entries may exist for each individual element of the battery but not for the battery itself. Another example may be Renin Studies where the specification may be done upon ordering without having a master file definition for each permutation of the possible element. The OBX segments in the ORM message can be used to create dynamic specifications to accommodate these permutations without defining pre-existing master file definitions for the battery itself. The result status field in the OBX can be used to indicate whether the OBX in the ORM message is used to provide a dynamic specification or is used to communicate a result as context to the order. The status of O shall be used to indicate that the OBX segment is used for a dynamic specification of the required result. An OBX used for a dynamic specification must contain the detailed examination code, units, etc., with OBX-11 valued with O, and OBX-2 and OBX-5 valued with null.

OBX-12: Effective Date of Reference Range (DTM) 00580

Definition: This field contains the date (and, optionally, the time) on which the values in OBX-7-reference range went into effect.

Usage Rule: This field can be valued only if OBX-7-reference range is populated.

When this field is present, it facilitates comparison between identical results with different reference ranges. Reference range values may vary because of changes in laboratory practice over time. Such variances could reflect updated practice in laboratory medicine, or the use of updated instrumentation.

OBX-13: User Defined Access Checks (ST) 00581

Definition: This field permits the producer to record results-dependent codes for classifying the observation at the receiving system. This field should be needed only rarely, because most classifications are fixed attributes of the observation ID and can be defined in the associated observation master file (see description in Chapter 8).

However, there are a few cases when such controls vary with the value of the observation in a complex way that the receiving system would not want to re-calculate. An example is an antimicrobial susceptibility result. Some systems prefer to display only the susceptibility results of inexpensive antimicrobials depending upon the organism, the source of the specimen and the patient's allergy status. The sending service wants to send all of the susceptibilities so that certain privileged users (e.g., Infectious Disease specialists) can review all of the results but non-privileged users would see only the "preferred" antimicrobials to which the organism was susceptible. We expect that other cases also occur.

OBX-14: Date/Time of the Observation (DTM) 00582

Definition: This field is needed in two circumstances. The first is when the observations reported beneath one report header (OBR) have different dates/times. This could occur in the case of queries, timed test sequences, or clearance studies where one measurement within a battery may have a different time than another measurement.

It is also needed in the case of OBX segments that are being sent by the placer to the filler, in which case the date of the observation being transmitted is likely to have no relation to the date of the requested observation. In France, requesting services routinely send a set of the last observations along with the request for a new set of observations. The date of these observations is important to the filler laboratories.

In all cases, the observation date-time is the physiologically relevant date-time or the closest approximation to that date-time. In the case of tests performed on specimens, the relevant date-time is the specimen's collection date-time. In the case of observations taken directly on the patient (e.g., X-ray images, history and physical), the observation date-time is the date-time that the observation was performed.

The Date/Time of observation can be used to identify when the answer was determined, i.e., when the answer to an Ask at Order Entry question was acquired.

OBX-15: Producer's ID (CWE) 00583

Definition: Retained for backwards compatibility as of v 2.7 only. This field is now represented through the PRT segment. This field contains a unique identifier of the responsible producing service. It should be reported explicitly when the test results are produced at outside laboratories, for example. When this field is null, the receiving system assumes that the observations were produced by the sending organization. This information supports CLIA regulations in the US. The code for producer ID is recorded as a CWE data type. In the US, the Medicare number of the producing service is suggested as the identifier. Refer to Table 0624 - Producer's ID in Chapter 2C for valid values.

OBX-16: Responsible Observer (XCN) 00584

Definition: Retained for backwards compatibility as of v 2.7 only. This field is now represented through the PRT segment. When required, this field contains the identifier of the individual directly responsible for the observation (i.e., the person who either performed or verified it). In a nursing service, the observer is usually the professional who performed the observation (e.g., took the blood pressure). In a laboratory, the observer is the technician who performed or verified the analysis. The code for the observer is recorded as a CWE data type. If the code is sent as a local code, it should be unique and unambiguous when combined with OBX-15-producer ID.

OBX-17: Observation Method (CWE) 00936

This optional field can be used to transmit the method or procedure by which an observation was obtained when the sending system wishes to distinguish among one measurement obtained by different methods and the distinction is not implicit in the test ID. Chemistry laboratories do not usually distinguish between two different methods used to measure a given serum constituent (e.g., serum potassium) as part of the test name. See the LOINC® Users Manual1 for a more complete discussion of these distinctions. If an observation producing service wanted to report the method used to obtain a particular observation, and the method was NOT embedded in the test name, they can use this field. Refer to Table 0626 - Observation Method in Chapter 2C for valid values.

OBX-18: Equipment Instance Identifier (EI) 01479

(Definition from OBX.18 in Ch. 7)

Definition: Retained for backwards compatibility as of v 2.7 only. This field is now represented through the PRT segment. This field identifies the Equipment Instance (e.g., Analyzer, Analyzer module, group of Analyzers, etc.) responsible for the production of the observation. This is the identifier from an institution's master list of equipment, where the institution is specified by the namespace ID or if it is blank, then by the "Producer's ID" (OBX-15). It should be possible to retrieve from this master list the equipment type, serial number, etc., however it is not planned to transfer this information with every OBX. The repeating of this field allows for the hierarchical representation of the equipment (lowest level first), e.g., module of an instrument, instrument consisting of modules, cluster of multiple instruments, etc.

(Definition from EQU.1 in Ch. 13)

Definition: This field identifies the equipment. This is the identifier from an institution's master list of equipment. The <namespace ID> identifies the institution.

The Equipment Instance Identifier shall be unique, meaning that the “Entity Identifier” component shall be unique within the Namespace ID that should accommodate hierarchical representation of equipment (recursive hierarchy like in "Russian dolls", e.g., a sub-module embedded in a module assembled in a system being a member of a cluster).

If this attribute repeats, all instances must represent the same device.

OBX-19: Date/Time of the Analysis (DTM) 01480

Definition: This field is used to transfer the time stamp associated with generation of the analytical result by the instrument specified in Equipment Instance Identifier (see above).

OBX-20: Observation Site (CWE) 02179

Definition: This field typically contains the body site(s) where the measurement being reported was obtained. This field should not be used for a specimen source or specimen collection site.

This information is of particular importance if the clinical meaning of a value is modified either directly by the site (for example, is the temperature central or peripheral?) or if the site of one measurement impacts the value of another measurement (for example, is the finger SpO2 probe on the same arm as the NIBP cuff?). In most cases these observations are performed directly upon the patient and do not involve a specimen.

Any nationally recognized coding system might be used for this field including SNOMED or MDC; alternatively the HL7 Table 0163 – Body Site may be used. Veterinary medicine may choose the tables supported for the components of this field as decided by their industry.

OBX-21: Observation Instance Identifier (EI) 02180

Definition: This field contains a unique identifier for this observation. This instance identifier is persistent between messages.

Note: OBX-21 Observation Instance Identifier was introduced in v 2.6 to support Patient Care messaging concepts and constructs. At this time, there are no documented use cases for this field in the context of messages as described in this chapter. This statement does not preclude the use of OBX-21, but implementers should exercise caution in using this field outside of the Patient Care context until the appropriate use cases are established. This identifier provides persistent reference to an object within or outside the message and represents an identifier established by external applications rather than temporal message considerations.


OBX-22: Mood Code (CNE) 02182

(Definition from OBX.22 in Ch. 7)

Definition: This field identifies the actuality of the observation (e.g., intent, request, promise, event). Refer to HL7 Table 0725 – Mood Codes for valid values. This field may only be used with new trigger events and new messages from v 2.6 onward. When this field is not valued in a message that qualifies, then the Value is assumed to be 'EVN'.

Note: OBX-22 Mood Code was introduced in v 2.6 to support Patient Care messaging concepts and constructs. At this time, there are no documented use cases for this field in the context messages as described in this chapter. This statement does not preclude the use of OBX-22, but implementers should exercise caution in using this field outside of the Patient Care context until appropriate use cases are established. While a similar note exists for OBX-21 Observation Instance Identifier, particular care should be taken with OBX-22 as this could modify the intent of the segment/message and create backward compatibility problems.


(Definition from GOL.22 in Ch. 12)

Definition: This field indicates the Mood of the Goal. It allows expression of the context of the problem.

Note: As Mood Code changes the meaning of the segment it must only be used in new messages as of v2.6.


Refer to HL7 Table 0725 – Mood Codes in Chapter 2C, Code Tables, for allowed values.

OBX-23: Performing Organization Name (XON) 02283

Definition: Retained for backwards compatibility as of v 2.7 only. This field is now represented through the PRT segment. This field contains the name of the organization/service responsible for performing the service. When this field is null, the receiving system assumes that the observations were produced by the sending organization. The information for performing organization is recorded as an XON data type. In the US, the Medicare number of the performing organization is suggested as the identifier (component 10).

For lab, this field specifies the laboratory that produced the test result described in this OBX segment. It should be reported explicitly when the test results are produced at outside laboratories, for example. This information supports CLIA regulations in the US. For the US producing laboratories, which are CLIA certified, the CLIA identifier should be used for the organization identifier (component 10).

OBX-24: Performing Organization Address (XAD) 02284

Definition: Retained for backwards compatibility as of v 2.7 only. This field is now represented through the PRT segment. This field contains the address of the organization/service responsible for performing the service.

For labs, this field specifies the address of the laboratory that produced the test result described in this OBX segment. It should be reported explicitly when the test results are produced at outside laboratories, for example. This information supports CLIA regulations in the US.

OBX-25: Performing Organization Medical Director (XCN) 02285

Definition: Retained for backwards compatibility as of v 2.7 only. This field is now represented through the PRT segment. This field contains the medical director of the organization/service responsible for performing the service.

For labs, this field specifies the medical director of the laboratory that produced the test result described in this OBX segment. This field is different than OBX-16 in that OBX-16 identifies the individual who performed the lab test (made the observation) whereas this field identifies the individual who is the medical director of the organization responsible for the result. It should be reported explicitly when the test results are produced at outside laboratories, for example. This information supports CLIA regulations in the US.

OBX-26: Patient Results Release Category (ID) 02313

Definition: This field contains instructions on whether to share the results with the patient, and if so how.

Valid values are provided in HL7 Table 0909 – Patient Results Release Categorization Scheme.

OBX-27: Root Cause (CWE) 03308

Definition: This element contains the reason code indicating the root cause for the reissue of a previously released lab report. This element is used in conjunction with OBX-11 Observation Result Status to define the root cause for a reissued laboratory result in the case of a corrected, amended, appended, or revised result. For example, if the laboratory result was reissued due to an equipment malfunction.

Refer to User-defined Table 0914 – Root Cause in Chapter 2C, Code Tables, for potential values.

OBX-28: Local Process Control (CWE) 03309

Definition: This element contains information intended to be used for locally defined processing, particularly process control/status type information. It is defined as repeating and as a CWE data type to provide flexibility. The specific use may be specified in a message profile or implementation guide (see Chapter 2.B), or use may be specified by local agreement internally within an organization.

For example, a laboratory information system might use this element to convey an internal status during processing before the result is communicated outside the organization, such as revision previously reported, revision report pending.

See User-Defined Table 0915 – Process Control Code in Chapter 2C, Code Tables, for a list of suggested values.

OBX-29: Observation Type (ID) 03432

Definition: This field indicates the type of observation to enable systems to distinguish between observations sent along with an order, versus observations sent as the result to an order. See HL7 Table 0936 – Observation Type in Chapter 2C, Code Tables, for valid values.

OBX-30: Observation Sub-Type (ID) 03475

Definition: The result sub-type provides further classification of OBX-29 Observation Type. This may aid in the grouping of OBX-segments. See HL7-defined Table 0937 – Observation Sub-Type in Chapter 2C, Code Tables, for a set of valid values.

OBX-31: Action Code (ID) 00816

(Definition from OH1.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH2.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH3.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH4.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from ORC.35 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when either ORC-2 and/or ORC 3 is valued with a unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from OBR.55 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when either an OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from IPC.10 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when the combination of IPC-1, IPC-2, IPC-3, and IPC-4 represents a unique identifier according to Chapter 2, Section 2.10.4.2.

(Definition from BPX.22 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BPX is uniquely identified sufficiently within the specific implementation using BPX-17 or BPX-6 as agreed to by the trading partners and in accordance with Chapter 2, Section 2.10.4.2.

(Definition from BTX.21 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BTX is uniquely identified sufficiently within the specific implementation using BTX-20 or BTX-3 as agreed to by the trading partners in accordance with Chapter 2, Section 2.10.4.2.

(Definition from DON.34 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an DON is uniquely identified sufficiently within the specific implementation using DON-1 in accordance with Chapter 2, Section 2.10.4.2.

(Definition from BUI.13 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BUI is uniquely identified sufficiently within the specific implementation using BUI-2 in accordance with Chapter 2, Section 2.10.4.2

(Definition from RXV.22 in Ch. 4A)

Definition: The intended handling by the receiver of the infusion order is represented by this segment. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from CDO.2 in Ch. 4A)

Definition: The Action Code indicates whether the cumulative dosage segment is intended to be added, deleted, updated, or did not change. If the field is not valued in any CDO segments for the order, the segments are considered to have been sent in snapshot mode. If some but not all CDO segments for the order do not have the action code valued, the default value is Add. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.55 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an either OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from OBX.31 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an OBX-21 is valued in accordance with guidance in Chapter 2, Section 2.10.4.2.

(Definition from SPM.35 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an SPM-2 or SPM-31 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from PRT.2 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.

(Definition from CSR.17 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when CSR-1 and CSR-4, or CSR-2 and CSR-5 are valued as agreed to by the trading partners in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from CTI.4 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when CTI-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from SHP.12 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when SHP-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from PAC.9 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when PAC-2 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from GOL.1 in Ch. 12)

Definition: The action code field gives the intent of the problem or goal. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from PRB.1 in Ch. 12)

Definition: This field contains the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from PTH.1 in Ch. 12)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from DEV.1 in Ch. 17)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.

OBX-32: Observation Value Absent Reason (CWE) 03510

Definition: This field reports the reason(s) why there is no value reported in the Observation Value (OBX-5) field. This field can be used when OBX-5-Observation Value is empty.

See HL7 Table 0960 – Observation Value Absent Reason for valid values.

Condition: This field must be blank if OBX-5, Observation Value, is valued.

OBX-33: Observation Related Specimen Identifier (EIP) 02454

Definition: This field contains the unique identifier for the specimen as referenced by the Placer application, the Filler application, or both in the SPM segment that describes the specimen this observation is related to, allowing an explicit linkage between the two.

SPM - Specimen Segment

The intent of this segment is to describe the characteristics of a specimen. It differs from the intent of the OBR in that the OBR addresses order-specific information. It differs from the SAC segment in that the SAC addresses specimen container attributes. An advantage afforded by a separate specimen segment is that it generalizes the multiple relationships among order(s), results, specimen(s) and specimen container(s).

A specimen is defined as "A physical entity that is an individual, a group, an item, or a part representative of a larger group, class or whole that is the target of an observation or analysis for the purpose of drawing conclusions about the group, class, or whole." Note that any physical entity in the universe has the potential to become a specimen

A specimen is collected or obtained from a source and may be representative of the source, or may represent a deviation within the source. A specimen may be wholly or partially consumed during an observation and any remaining portion of the specimen is persistent and can be stored.

This segment may also be used in limited cases to describe a "virtual" specimen. In particular, to identify the characteristics required for a specimen in the context of a specific observation or test.

In summary, SPM represents the attributes specific and unique to a specimen.

HL7 Attribute Table - SPM - Specimen Segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
SPM
1 01754 Set ID - SPM [0..1] [1..4]
SI
2 01755 Specimen Identifier [0..1]
EIP
3 01756 Specimen Parent IDs [0..*]
EIP
4 01900 Specimen Type SHALL [1..1]
0487 Specimen Type
CWE
5 01757 Specimen Type Modifier [0..*]
0541
CWE
6 01758 Specimen Additives [0..*]
0371 Additive/Preservative
CWE
7 01759 Specimen Collection Method [0..1]
0488 Specimen Collection Method
CWE
8 01901 Specimen Source Site [0..1]
0784
CWE
9 01760 Specimen Source Site Modifier [0..*]
0542
CWE
10 01761 Specimen Collection Site [0..1]
0543
CWE
11 01762 Specimen Role [0..*]
0369 Specimen Role
CWE
12 01902 Specimen Collection Amount [0..1]
CQ
13

01763 Grouped Specimen Count MAY
True:
False: 		C=
[1..1]
[0..1] 		6
NM
14 01764 Specimen Description [0..*]
ST
15 01908 Specimen Handling Code [0..*]
0376 Special Handling Code
CWE
16 01903 Specimen Risk Code [0..*]
0489 Risk Codes
CWE
17 01765 Specimen Collection Date/Time [0..1]
DR
18 00248 Specimen Received Date/Time * [0..1]
DTM
19 01904 Specimen Expiration Date/Time [0..1]
DTM
20 01766 Specimen Availability [0..1] [1..1]
0136 Yes/no Indicator
ID
21 01767 Specimen Reject Reason [0..*]
0490 Specimen Reject Reason
CWE
22 01768 Specimen Quality [0..1]
0491 Specimen Quality
CWE
23 01769 Specimen Appropriateness [0..1]
0492 Specimen Appropriateness
CWE
24 01770 Specimen Condition [0..*]
0493 Specimen Condition
CWE
25 01771 Specimen Current Quantity [0..1]
CQ
26 01772 Number of Specimen Containers = [0..1] 4
NM
27 01773 Container Type [0..1]
0785
CWE
28 01774 Container Condition [0..1]
0544 Container Condition
CWE
29 01775 Specimen Child Role [0..1]
0494 Specimen Child Role
CWE
30 02314 Accession ID [0..*]
CX
31 02315 Other Specimen ID [0..*]
CX
32 02316 Shipment ID [0..1]
EI
33 03485 Culture Start Date/Time [0..1]
DTM
34 03486 Culture Final Date/Time [0..1]
DTM
35 00816 Action Code [0..1] [2..2]
0206 Segment Action Code
ID

SPM-1: Set ID - SPM (SI) 01754

Definition: This field contains the sequence number. This field is used to identify SPM segment instances in message structures where the SPM segment repeats.

SPM-2: Specimen Identifier (EIP) 01755

Definition: This field contains a unique identifier for the specimen as referenced by the Placer application, the Filler application, or both.

This field is not required, as there are use cases in which a unique specimen identifier may not exist. In the first scenario, a placer application may initiate an observation request against an existing specimen without uniquely identifying the specimen. Additionally, in the case of the TCU_U10 message structure, used in Automated equipment test code settings messages, the SPM segment is used to define required characteristics of the specimen. As such, TCU_U10 uses SPM to define a virtual specimen, and a specific specimen identifier would not exist. Filler applications would be expected to assign a Specimen Identifier and populate this field accordingly.

SPM-3: Specimen Parent IDs (EIP) 01756

Definition: This field contains the identifiers for the specimen or specimens that contributed to the specimen that is described by the segment instance.

If this field repeats, then SPM-11-Specimen Role should be valued with "L" (pooled). The repetitions of this field then carry the specimen IDs of the parent specimens contributing to the pool.

SPM-4: Specimen Type (CWE) 01900

Definition: This field describes the precise nature of the entity that will be the source material for the observation.

Any physical entity that may have observations made about it may qualify as a specimen. The entry in this attribute describes the specific entity as precisely as possible, whether that is a complex organism (e.g., an ostrich) or a specific cellular mass (e.g., a specific muscle biopsy).

A nationally recognized coding system is to be used for this field. Valid coding sources for this field include:

SPM-5: Specimen Type Modifier (CWE) 01757

Definition: This field contains modifying or qualifying description(s) about the specimen type

The use of this attribute is to modify, qualify or further specify, the entity described by SPM-4 -Specimen Type. This is particularly useful when the code set used in SPM-4-Specimen Type does not provide the precision required to fully describe the specimen. For example, if the specimen was precisely described as 'capillary venous blood' but the code set employed only provided 'venous blood,' this attribute could be employed to add the modifier 'capillary.'

Refer to User-Defined Table 0541 Specimen Type Modifier for suggested values.

SPM-6: Specimen Additives (CWE) 01758

Definition: This field identifies any additives introduced to the specimen before or at the time of collection. These additives may be introduced in order to preserve, maintain or enhance the particular nature or component of the specimen. Refer to HL7 Table 0371 – Additive/Preservative for valid values. When multiple additives are introduced and valid individual additive codes exist but a valid value for the combination does not exist, repeating the field with individual values is most appropriate.

SPM-7: Specimen Collection Method (CWE) 01759

Definition: Describes the procedure or process by which the specimen was collected.

Any nationally recognized coding system might be used for this field including SNOMED; alternatively the HL7 Table 0488 – Specimen Collection Method may be used. Veterinary medicine may choose the tables supported for the components of this field as decided by their industry.

SPM-8: Specimen Source Site (CWE) 01901

Definition: specifies the source from which the specimen was obtained. For example, in the case where a liver biopsy is obtained via a percutaneous needle, the source would be 'liver'. Refer to Table 0784 - Specimen Source Site in Chapter 2C for valid values.Any nationally recognized coding system might be used for this field including SNOMED; alternatively the HL7 Table 0163 – Body Site may be used. Veterinary medicine may choose the tables supported for the components of this field as decided by their industry.

SPM-9: Specimen Source Site Modifier (CWE) 01760

Definition: This field contains modifying or qualifying description(s) about the specimen source site

The use of this attribute is to modify, qualify or further specify, the entity described by SPM-8 – Specimen Source Site. This is particularly useful when the code set used in SPM-8 does not provide the precision required to fully describe the site from which the specimen originated. For example, if the specimen source site was precisely described as 'left radial vein' but the code set employed only provided 'radial vein,' this attribute could be employed to add the modifier 'left.'

Veterinary medicine may choose the tables supported for the components of this field as decided by their industry.

Refer to User-Defined Table 0542 – Specimen Source Type Modifier for suggested values.

SPM-10: Specimen Collection Site (CWE) 01761

Definition: This field differs from SPM-8-Specimen Source Site in those cases where the source site must be approached via a particular site (e.g., anatomic location). For example, in the case where a liver biopsy is obtained via a percutaneous needle, the collection site would be the point of entry of the needle. For venous blood collected from the left radial vein, the collection site could be "antecubital fossa".

Veterinary medicine may choose the tables supported for the components of this field as decided by their industry.

Refer to User-Defined Table 0543 – Specimen Collection Site for suggested values.

SPM-11: Specimen Role (CWE) 01762

This field indicates the role of the sample. Refer to User-defined Table 0369 – Specimen role for suggested values. Each of these values is normally identifiable by the systems and its components and can influence processing and data management related to the specimen.

If this field is not populated, then the specimen described has no special, or specific, role other than serving as the focus of the observation. Such specimens include patient, environmental and other specimens that are intended for analysis.

A grouped specimen consists of identical specimen types from multiple individuals that do not have individual identifiers and upon which the same services will be performed. If the specimen role value is "G" then the Grouped Specimen Count (SPM-13) must be valued with the total number of specimens contained in the group.

If the specimen role is "L", the repetitions of Parent Specimen ID (SPM-4) represent the individual parent specimens that contribute to the pooled specimen.

SPM-12: Specimen Collection Amount (CQ) 01902

Definition: This field specifies the volume or mass of the collected specimen. For laboratory tests, the collection volume is the volume of a specimen. Specifically, units should be expressed in the ISO Standard unit abbreviations (ISO-2955, 1977). This is a results-only field except when the placer or a party has already drawn the specimen. Use of UCUM is strongly recommended as one of the delivered units (could be in addition to the local units). (See Chapter 7 Section 7.4.2.6 for a full discussion regarding units.)

SPM-13: Grouped Specimen Count (NM) 01763

Definition: This field refers to the number of individual specimens of a particular type represented by this instance of a specimen. The use of this field is restricted to specimens upon which all specimen related attributes are identical. This field would only be valued if SPM-11 Specimen Role has the value "G" or “L”.

SPM-14: Specimen Description (ST) 01764

Definition: This is a text field that allows additional information specifically about the specimen to be sent in the message

SPM-15: Specimen Handling Code (CWE) 01908

(Definition from SPM.15 in Ch. 7)

Definition: This describes how the specimen and/or container need to be handled from the time of collection through the initiation of testing. As this field is not required, no assumptions can be made as to meaning when this field is not populated.

Refer to User-defined Table 0376 – Special Handling Code for suggested values.

(Definition from OM4.15 in Ch. 8)

Definition: This describes how the specimen and/or container need to be handled from the time of collection through the initiation of testing. As this field is not required, no assumptions can be made as to meaning when this field is not populated.

Refer to User-defined Table 0376 – Special Handling Code in Chapter 2C, Code Tables, for suggested values.

SPM-16: Specimen Risk Code (CWE) 01903

Definition: This field contains any known or suspected specimen hazards, e.g., exceptionally infectious agent or blood from a hepatitis patient. Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, a component delimiter must precede free text without a code. Refer to User-defined Table 0489 – Risk Codes for suggested entries

SPM-17: Specimen Collection Date/Time (DR) 01765

Definition: The date and time when the specimen was acquired from the source. The use of the Date Range data type allows for description of specimens collected over a period of time, for example, 24-hour urine collection. For specimens collected at a point in time, only the first component (start date/time) will be populated.

SPM-18: Specimen Received Date/Time * (DTM) 00248

(Definition from OBR.14 in Ch. 4)

Attention: The OBR-14 element was retained for backward compatibility only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7. See SPM in Chapter 7.

(Definition from OBR.14 in Ch. 7)

Attention: The OBR-14 element was retained for backward compatibility only as of v 2.5 and the detail was withdrawn and removed from the standard as of v 2.7. See SPM in Chapter 7.

(Definition from SPM.18 in Ch. 7)

Definition: The specimen received date/time is the time that the specimen is received at the diagnostic service facility. The actual time that is recorded is based on how specimen receipt is managed and may correspond to the time the sample is logged in. This is fundamentally different from SPM-17 Specimen Collection date/time.

SPM-19: Specimen Expiration Date/Time (DTM) 01904

Definition: This field is the date and time the specimen can no longer be used for the purpose implied by the order. For example, in the Blood Banking environment the specimen can no longer be used for pre-transfusion compatibility testing. The specimen segment will include a SPM-21-Specimen Reject Reason of 'EX' indicating 'Expired' for message instances created after this date and time.

SPM-20: Specimen Availability (ID) 01766

Definition: This describes whether the specimen, as it exists, is currently available to use in an analysis. Refer to HL7 Table 0136 – Yes/No Indicator for valid values.

SPM-21: Specimen Reject Reason (CWE) 01767

Definition: This describes one or more reasons the specimen is rejected for the specified observation/result/analysis. Refer to HL7 Table 0490 – Specimen Reject Reason for valid values.

SPM-22: Specimen Quality (CWE) 01768

Definition: The degree or grade of excellence of the specimen at receipt. The filler populates this attribute. Refer to User-defined Table 0491 – Specimen Quality for suggested entries.

SPM-23: Specimen Appropriateness (CWE) 01769

Definition: The suitability of the specimen for the particular planned use as determined by the filler. Refer to User-defined Table 0492 – Specimen Appropriateness for suggested entries.

SPM-24: Specimen Condition (CWE) 01770

Definition: A mode or state of being that describes the nature of the specimen. Refer to User-defined Table 0493 – Specimen Condition for suggested entries.

SPM-25: Specimen Current Quantity (CQ) 01771

Definition: This attributes contains the amount of specimen that currently exists or is available for use in further testing.

SPM-26: Number of Specimen Containers (NM) 01772

Definition: This field identifies the number of containers for a given sample. For sample receipt verification purposes; may be different from the total number of samples that accompany the order.

SPM-27: Container Type (CWE) 01773

Definition: The container in or on which a specimen is transported. Refer to Table 0785 - Container Type in Chapter 2C for valid values.

Note:     If the container type is categorized (e.g., FBT (false-bottom-tube), Cup, …), the specific codes should be transferred in the SPM-27 field "Container Type". If the container is characterized by dimensions and other characteristics this information should be transferred as specific values in the SAC segment (fields: SAC-16 … SAC-21).


SPM-28: Container Condition (CWE) 01774

Definition: In chain of custody cases where specimens are moved from lab to lab, the status of the container that the specimen is shipped in must be recorded at each receipt. If the container is compromised in any way (seal broken, container cracked or leaking, etc) then this needs to be recorded for legal reasons.

Refer to HL7 Table 0544 – Container Condition for suggested values.

SPM-29: Specimen Child Role (CWE) 01775

Definition: For child specimens, this field identifies the relationship between this specimen and the parent specimen. If this field is populated, then SPM-3-Specimen Parent ID must be populated. This field differs from SPM-15-Specimen Role in that this field refers to the role of this specimen relative to a parent role rather than the role of this specimen to the ordered service.

Refer to HL7 Table 0494 – Specimen Child Role for valid values.

SPM-30: Accession ID (CX) 02314

Definition: This field contains accession identifier(s) associated with the specimen. In many cases, applications involved in the collection, transportation or testing of the specimen will assign their own accession identifiers. This field allows communication of these accession identifiers.

An accession id may or may not, depending up laboratory practice, identify a single specimen. Best practice is to use accession identifiers that are globally unique (typically ID Number + Assigning Facility components). However, an accession id may or may not, depending up laboratory practice, identify a single specimen. In addition, accession ids are commonly re-used over time, so the accession id may not uniquely identify a specimen.

SPM-31: Other Specimen ID (CX) 02315

Definition: This field contains other identifier(s) for the specimen as referenced in an application. Normally this field is used to carry additional identifiers for the specimen in addition to those identified in SPM-2, Specimen ID. In may cases other applications involved in the collection, transportation or testing of the specimen will assign additional specimen identifiers. This field allows communication of those other specimen identifiers.

SPM-32: Shipment ID (EI) 02316

Definition: The shipment identifier is the identifier assigned by the shipment transportation provider that uniquely identifies this shipment from all other shipments by the same provider. The addressee for the shipment should be able to use this identifier to match a physical shipment with the electronic manifest for the shipment.

SPM-33: Culture Start Date/Time (DTM) 03485

Definition: The Culture Start date/time is the time that the specimen is plated, or inoculated to selective and differential growth mediums that are used in organism identification in microbiology. This is the start of differential diagnosis and is a clinically relevant date and time. The actual time that is recorded is based on when specimen is directly inoculated onto growth media and may correspond to the time the sample is logged in or received.

SPM-34: Culture Final Date/Time (DTM) 03486

Definition: The Culture Final date/time is the time in which the order filler is communicating to the clinician that all work on a cultured specimen is completed and no further updates will be received. All work, including determination of growth, Organism Identification, and sensitivity testing are completed. The clinician should expect no further updates on this cultured specimen.

SPM-35: Action Code (ID) 00816

(Definition from OH1.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH2.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH3.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH4.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from ORC.35 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when either ORC-2 and/or ORC 3 is valued with a unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from OBR.55 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when either an OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from IPC.10 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when the combination of IPC-1, IPC-2, IPC-3, and IPC-4 represents a unique identifier according to Chapter 2, Section 2.10.4.2.

(Definition from BPX.22 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BPX is uniquely identified sufficiently within the specific implementation using BPX-17 or BPX-6 as agreed to by the trading partners and in accordance with Chapter 2, Section 2.10.4.2.

(Definition from BTX.21 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BTX is uniquely identified sufficiently within the specific implementation using BTX-20 or BTX-3 as agreed to by the trading partners in accordance with Chapter 2, Section 2.10.4.2.

(Definition from DON.34 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an DON is uniquely identified sufficiently within the specific implementation using DON-1 in accordance with Chapter 2, Section 2.10.4.2.

(Definition from BUI.13 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BUI is uniquely identified sufficiently within the specific implementation using BUI-2 in accordance with Chapter 2, Section 2.10.4.2

(Definition from RXV.22 in Ch. 4A)

Definition: The intended handling by the receiver of the infusion order is represented by this segment. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from CDO.2 in Ch. 4A)

Definition: The Action Code indicates whether the cumulative dosage segment is intended to be added, deleted, updated, or did not change. If the field is not valued in any CDO segments for the order, the segments are considered to have been sent in snapshot mode. If some but not all CDO segments for the order do not have the action code valued, the default value is Add. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.55 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an either OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from OBX.31 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an OBX-21 is valued in accordance with guidance in Chapter 2, Section 2.10.4.2.

(Definition from SPM.35 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an SPM-2 or SPM-31 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from PRT.2 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.

(Definition from CSR.17 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when CSR-1 and CSR-4, or CSR-2 and CSR-5 are valued as agreed to by the trading partners in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from CTI.4 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when CTI-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from SHP.12 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when SHP-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from PAC.9 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when PAC-2 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from GOL.1 in Ch. 12)

Definition: The action code field gives the intent of the problem or goal. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from PRB.1 in Ch. 12)

Definition: This field contains the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from PTH.1 in Ch. 12)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from DEV.1 in Ch. 17)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.

PRT - Participation Information Segment

The Participation Information segment contains the data necessary to add, update, correct, and delete from the record persons, organizations, devices, or locations (participants) participating in the activity being transmitted.

In general, the PRT segment is used to describe a participant playing a particular role within the context of the message. In OO, for example, in the results messages the PRT segment may be used to provide the performing provider, whether a person or organization. In a specimen shipment message it may be the waypoint location relevant for the shipment.

The positional location of the PRT segment indicates the relationship. When the segment is used following the OBX segment, then the participations relate to that OBX addressing participations such as responsible observer.

The PRT segment may be used to communicate U.S. FDA Unique Device Identifier (UDI2) information, with the PRT-10 field containing the UDI and additional fields added to contain UDI elements, when it is advised to communicate these individually (see Guidance in PRT-10 definition). These identifiers are intended to cover a wide variety of devices. When representing a UDI, PRT-4 would be “EQUIP”.

HL7 Attribute Table - PRT - Participation Information Segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
PRT
1

02379 Participation Instance ID MAY
True:
False: 		C
[1..1]
[0..1] 		[1..4]
EI
2 00816 Action Code SHALL [1..1] [2..2]
0206 Segment Action Code
ID
3 02380 Action Reason [0..1]
CWE
4 02381 Role of Participation SHALL [1..1]
0912 Participation
CWE
5

02382 Person MAY
True:
False: 		C
[1..1]
[0..1]
XCN
6

02383 Person Provider Type MAY
True:
False: 		C
[1..1]
[0..1]
CWE
7

02384 Organization Unit Type MAY
True:
False: 		C
[1..1]
[0..1]
0406 Participant Organization Unit Type
CWE
8

02385 Organization MAY
True:
False: 		C
[1..1]
[0..1]
XON
9

02386 Location MAY
True:
False: 		C
[1..1]
[0..1]
PL
10

02348 Device MAY
True:
False: 		C
[1..1]
[0..1]
EI
11 02387 Begin Date/Time [0..1]
DTM
12 02388 End Date/Time [0..1]
DTM
13 02389 Qualitative Duration [0..1]
CWE
14

02390 Address MAY
True:
False: 		C
[1..1]
[0..1]
XAD
15 02391 Telecommunication Address [0..*]
XTN
16 03476 UDI Device Identifier [0..1]
EI
17 03477 Device Manufacture Date [0..1]
DTM
18 03478 Device Expiry Date [0..1]
DTM
19 03479 Device Lot Number [0..1]
ST
20 03480 Device Serial Number [0..1]
ST
21 03481 Device Donation Identification [0..1]
EI
22

03483 Device Type MAY
True:
False: 		C
[1..1]
[0..1]
0961
CNE
23 00684 Preferred Method of Contact [0..1]
0185 Preferred Method of Contact
CWE
24 01171 Contact Identifiers [0..*]
0328
PLN

PRT-1: Participation Instance ID (EI) 02379

Definition: This field contains a unique identifier of the specific participation record.

In the case of waypoints tracked for a shipment, it identifies the waypoint.

Condition: The identifier is required when known, but there are times we may only know a name but do not have an identifier.

PRT-2: Action Code (ID) 00816

(Definition from OH1.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH2.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH3.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OH4.2 in Ch. 3)

Definition: This field contains a code defining the action to be taken for this segment. It allows this segment to be sent to delete or update, for example, previously sent information. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from ORC.35 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when either ORC-2 and/or ORC 3 is valued with a unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from OBR.55 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when either an OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from IPC.10 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when the combination of IPC-1, IPC-2, IPC-3, and IPC-4 represents a unique identifier according to Chapter 2, Section 2.10.4.2.

(Definition from BPX.22 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BPX is uniquely identified sufficiently within the specific implementation using BPX-17 or BPX-6 as agreed to by the trading partners and in accordance with Chapter 2, Section 2.10.4.2.

(Definition from BTX.21 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BTX is uniquely identified sufficiently within the specific implementation using BTX-20 or BTX-3 as agreed to by the trading partners in accordance with Chapter 2, Section 2.10.4.2.

(Definition from DON.34 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an DON is uniquely identified sufficiently within the specific implementation using DON-1 in accordance with Chapter 2, Section 2.10.4.2.

(Definition from BUI.13 in Ch. 4)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an BUI is uniquely identified sufficiently within the specific implementation using BUI-2 in accordance with Chapter 2, Section 2.10.4.2

(Definition from RXV.22 in Ch. 4A)

Definition: The intended handling by the receiver of the infusion order is represented by this segment. Refer to HL7 Table 0206 – Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from CDO.2 in Ch. 4A)

Definition: The Action Code indicates whether the cumulative dosage segment is intended to be added, deleted, updated, or did not change. If the field is not valued in any CDO segments for the order, the segments are considered to have been sent in snapshot mode. If some but not all CDO segments for the order do not have the action code valued, the default value is Add. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from OBR.55 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an either OBR-2 and/or OBR-3 is valued with unique identifier in accordance with Chapter 2, Section 2.10.4.2.

(Definition from OBX.31 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an OBX-21 is valued in accordance with guidance in Chapter 2, Section 2.10.4.2.

(Definition from SPM.35 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when an SPM-2 or SPM-31 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from PRT.2 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.

(Definition from CSR.17 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when CSR-1 and CSR-4, or CSR-2 and CSR-5 are valued as agreed to by the trading partners in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from CTI.4 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when CTI-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from SHP.12 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when SHP-1 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from PAC.9 in Ch. 7)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0206 - Segment Action Code for valid values.

The action code can only be used when PAC-2 is valued in accordance with the guidance in Chapter 2, Section 2.10.4.2.

(Definition from GOL.1 in Ch. 12)

Definition: The action code field gives the intent of the problem or goal. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from PRB.1 in Ch. 12)

Definition: This field contains the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from PTH.1 in Ch. 12)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/Goal Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from DEV.1 in Ch. 17)

Definition: This field reveals the intent of the message. Refer to HL7 Table 0287 – Problem/goal action code for valid values.

PRT-3: Action Reason (CWE) 02380

Definition: This field indicates the reason why the person, organization, location, or device is assuming (or changing) the role (e.g., shift change, new primary nurse, etc.).

PRT-4: Role of Participation (CWE) 02381

Definition: This field indicates the functional involvement with the activity being transmitted (e.g., Case Manager, Evaluator, Transcriber, Nurse Care Practitioner, Midwife, Physician Assistant, etc.). Refer to HL7 Table 0912 – Participation for valid values.

PRT-5: Person (XCN) 02382

Definition: This field contains the identity of the person who is represented in the participation that is being transmitted.

If this attribute repeats, all instances must represent the same person.

Condition: At least one of PRT-5 Person, PRT-8 Organization, PRT-9 Location, or PRT-10 Device or PRT-22 Device Type fields must be valued.

PRT-6: Person Provider Type (CWE) 02383

Definition: This field contains a code identifying the provider type for the participating person. This attribute correlates to the following master file attribute: STF-4 Staff Type. Coded values from the correlated master file table are used; the user defined master file table is used as the coding system for this attribute. For example, if you are using values from STF-2 Staff Type, the coding system would be HL70182 which is the table number for the user defined Staff Type table. This field is included in this segment to support international requirements. When ROL is used in an encounter message, it is not intended as a master file update.

Condition: This field may only be valued if PRT-5 Person is valued.

PRT-7: Organization Unit Type (CWE) 02384

Definition: This field identifies the environment in which the participant acts in the role specified in PRT-3 Action Reason. In the case of a person, the environment is not the specialty for the provider. The specialty information for the provider is defined in the PRA segment.

This attribute is included in the PRT segment to allow communication of this data when the participant information may not have been communicated previously in a master file or to provide better context. Refer to User-defined table 0406 - Organization unit type. This field is included in this segment to support international requirements, and is not intended as a master file update.

Condition: This field may only be valued if PRT-5 Person is valued.

PRT-8: Organization (XON) 02385

Definition: The organization that is involved in the participation. If PRT-5 Person is valued, it reflects the affiliation of the individual participating as identified in PRT-4 Role of Participation. Otherwise the organization is directly participating as identified in PRT-4 Role of Participation.

If this attribute repeats, all instances must represent the same organization.

Condition: At least one of the PRT-5 Person, PRT-8 Organization, PRT-9 Location, or PRT-10 Device or PRT-22 Device Type fields must be valued.

PRT-9: Location (PL) 02386

Definition: This field specifies the physical location (e.g., nurse station, ancillary service location, clinic, or floor) that is participating. If either PRT-5 Person or PRT-8 Organization is valued, it reflects the location of the individual or organization participating as identified in PRT-4 Role of Participation. Otherwise the location is directly participating as identified in PRT-4 Role of Participation.

If this attribute repeats, all instances must represent the same organization.

Condition: At least one of the PRT-5 Person, PRT-8 Organization, PRT-9 Location, or PRT-10 Device or PRT-22 Device Type fields must be valued.

PRT-10: Device (EI) 02348

Definition: Identifier for the device participating. This may reflect an unstructured or a structured identifier such as FDA UDI, RFID, IEEE EUI-64 identifiers, or bar codes.

Example: The device used to register the shipment at the waypoint.

If this attribute repeats, all instances must represent the same device.

Condition: At least one of the PRT-5 Person, PRT-8 Organization, PRT-9 Location, or PRT-10 Device or PRT-22 Device Type fields must be valued.

If this field contains an FDA UDI, it shall contain the entire Human Readable Form of the UDI. For example, a GS1-based UDI would be represented as follows:

|(01)00643169001763(17)160712(21)21A11F4855^^2.16.840.1.113883.3.3719^ISO|

A HIBCC-based example would be represented as follows:

|+H123PARTNO1234567890120/$$420020216LOT123456789012345/SXYZ4567890123 45678/16D20130202C^^2.16.840.1.113883.3.3719^ISO

An ICCBBA-based example would be represented as follows:

|=/A9999XYZ100T0944=,000025=A99971312345600=>014032=}013032\T\,1000000000000XYZ123^^2.16.840.1.113883.3.3719^ISO|

Or for ICCBBA (for blood bags only) an example would be represented as follows:

|=)1TE123456A\T\)RZ12345678^^2.16.840.1.113883.3.3719^ISO|

The identifier root shall be the OID assigned to UDI. For example, for FDA UDIs the root shall be 2.16.840.1.113883.3.3719, and the extension shall be the Human Readable Form appropriate for the style of content. When captured as a simple string, the string shall be the Human Readable Form appropriate for the style of content. The content style can be determined from the leading characters of the content:

UDIs beginning with:     

    ‘(‘ are in the GS1 Human Readable style;

        ‘0-9’ are a GS1 DI (containing only the DI value, no PI or GS1 AI);

    ‘+‘ are in the HIBCC Human Readable style;

    ‘=‘ or ‘&’ are in the ICCBBA Human Readable style.

Note: If “&” is used in the UDI while one of the delimiters in MSH.2 includes “&” as well, it must be properly escaped per Chapter 2.7.

The exchange of UDI sub-elements in PRT-16 through PRT-21 is not required when the full UDI string is provided in PRT-10. Whether to include some or all these fields as well when PRT-10 is present with a UDI that the rules are subject to specific implementation guides that will have to consider the patient safety implications of potentially conflicting data.

When a UDI is provided and sub-elements are also provided, then for those sub-elements that are valued, the content must match the content encoded in the UDI if it is encoded within the UDI.

When communicating a UDI, the UDI may either be uniquely identifying an instance of a device, or a type of device. This can be asserted based on the inclusion or absence of a serial number in the Product Identifier section of the UDI. When the serial number is present, PRT-10 must be used, while if it is absent, PRT-22 must be used.

Caution: The UDI may contain personally identifying information in the form of the device serial number which may be used to link to other information on a patient. Security and privacy consideration should be addressed, particularly when sending a UDI with a serial number, as that may inadvertently be able to identify a patient. Note: In the US realm that would be addressed by HIPAA.

Note: PRT-10 Device is a repeating field. Additional device identifiers, such as an IEEE EUI-64 may also be contained in this field.

PRT-11: Begin Date/Time (DTM) 02387

Definition: This field contains the date/time when the participation began.

In the case of waypoints, this reflects the time a shipment arrives at the waypoint.

PRT-12: End Date/Time (DTM) 02388

Definition: This field contains the date/time when the participation ended.

In the case of waypoints, this reflects the time a shipment departs from the waypoint.

PRT-13: Qualitative Duration (CWE) 02389

Definition: This field contains the qualitative length of time for participation (e.g., until the next assessment, four days, until discharge, etc.).

PRT-14: Address (XAD) 02390

Definition: This field contains addresses associated with the participation. The address can repeat to indicate alternate addresses or an alternate expression of the same address.

Condition: The address must be present if the Participation is Performing Organization Medical Director.

PRT-15: Telecommunication Address (XTN) 02391

Definition: The waypoint telecommunication address field carries telecommunications addresses for the waypoint. These telecommunications addresses are used to contact the waypoint for additional information regarding the receipt of the shipment. The address can repeat to indicate alternate addresses or an alternate expression of the same address.

PRT-16: UDI Device Identifier (EI) 03476

(Definition from PRT.16 in Ch. 7)

Definition: Provides the U.S. FDA UDI device identifier (DI) element.

This is the first component in the UDI and acts as the look up key for the Global Unique Device Identification Database (GUDID3), and may be used for retrieving additional attributes.

When exchanging Device Identifiers (DI) the root shall be the OID, or standards’ appropriate corollary to the OID, assigned to DI and the extension shall be the Human Readable Form of the content. For example, for DIs the root shall be:

    GS1 DIs:     2.51.1.1

    HIBCC DIs:    1.0.15961.10.816

ICCBBA DIs:    2.16.840.1.113883.6.18.1.17 for Blood containers and 2.16.840.1.113883.6.18.1.34 otherwise.

Example:    |00643169001763^^2.51.1.1^ISO|

(Definition from DEV.9 in Ch. 17)

Definition: Provides the U.S. FDA UDI device identifier (DI) element. This is not the same as DEV-2, Unique Device Identifier as DEV-2 represents either the full UDI Carrier in the case of an implantable Device,

This is the first component in the UDI and acts as the look up key for the Global Unique Device Identification Database (GUDID2), and may be used for retrieving additional attributes.

When exchanging Device Identifiers (DI) the root shall be the OID, or standards’ appropriate corollary to the OID, assigned to DI and the extension shall be the Human Readable Form of the content. For example, for DIs the root shall be:

    GS1 DIs:     2.51.1.1

    HIBCC DIs:    1.0.15961.10.816

ICCBBA DIs:    2.16.840.1.113883.6.18.1.17 for Blood containers and 2.16.840.1.113883.6.18.1.34 otherwise.

Example:    |00643169001763^^2.51.1.1^ISO|

PRT-17: Device Manufacture Date (DTM) 03477

(Definition from PRT.17 in Ch. 7)

Definition: Date and time when the device was manufacturered.

Note: The user system may need to convert the date and optional hour from the UDI Human Readable Form to a timestamp style data type, augmenting the date as required to provide for a complete date and optionally the hour.

Example:    |20140401|

(Definition from DEV.12 in Ch. 17)

Definition: Date and time when the device was manufacturered.

Note: The user system may need to convert the date and optional hour from the UDI Human Readable Form to a timestamp style data type, augmenting the date as required to provide for a complete date and optionally the hour.

Example:    |20140401|

PRT-18: Device Expiry Date (DTM) 03478

(Definition from PRT.18 in Ch. 7)

Definition: Date and time when the device is no longer approved for use.

Note: The user system may need to convert the date and optional hour from the UDI Human Readable Form to a timestamp style data type, augmenting the date as required to provide for a complete date and optionally the hour.

Example:    |20160712|

(Definition from DEV.13 in Ch. 17)

Definition: Date and time when the device is no longer approved for use.

Note: The user system may need to convert the date and optional hour from the UDI Human Readable Form to a timestamp style data type, augmenting the date as required to provide for a complete date and optionally the hour.

Example:    |20160712|

CAUTION: See the related privacy considerations discussion in PRT-10.

Example:    |21A11F4855|

PRT-19: Device Lot Number (ST) 03479

(Definition from PRT.19 in Ch. 7)

Definition: Alphanumeric string that identifies the device’s production lot number.

    Example:    |123ABC|

(Definition from DEV.10 in Ch. 17)

Definition: Alphanumeric string that identifies the device’s production lot number.

    Example:    |123ABC|

PRT-20: Device Serial Number (ST) 03480

(Definition from PRT.20 in Ch. 7)

Definition: Manufacturer’s serial number for this device.

CAUTION: See the related privacy considerations discussion in PRT-10.

Example:    |21A11F4855|

(Definition from DEV.11 in Ch. 17)

Definition: Manufacturer’s serial number for this device. This field may be the same as DEV-2, Unique Device Identifier when the device does not involve a UDI Carrier for UDI and DEV-2 represents a serial number. The implementation guide would determine whether DEV-11 is then used or not.

PRT-21: Device Donation Identification (EI) 03481

(Definition from PRT.21 in Ch. 7)

Definition: Identifies a device related to a donation (e.g., whole blood).

When exchanging Donation Identification Numbers (DIN) the root shall be the OID assigned to DIN and the extension shall be the Human Readable Form of the content. For example, for DINs the root shall be:

    ICCBBA DINs:    2.16.840.1.113883.6.18.2.1

An ICCBBA DIN OID is available for reference where required, but is not required when the specific data element is scoped to ICCBBA DINs.

Example:    | RA12345678BA123^^2.16.840.1.113883.6.18.1.34^ISO|

(Definition from DEV.15 in Ch. 17)

Definition: Identifies a device related to a donation.

When exchanging Donation Identification Numbers (DIN) the root shall be the OID assigned to DIN and the extension shall be the Human Readable Form of the content. For example, for DINs the root shall be:

    ICCBBA DINs:    2.16.840.1.113883.6.18.2.1

An ICCBBA DIN OID is available for reference where required, but is not required when the specific data element is scoped to ICCBBA DINs.

Example:    | RA12345678BA123^^2.16.840.1.113883.6.18.1.34^ISO|

PRT-22: Device Type (CNE) 03483

(Definition from PRT.22 in Ch. 7)

Definition: This field contains the type of device used in the participation.

When communicating a UDI, the UDI may either be uniquely identifying an instance of a device, or a type of device. This can be asserted based on the inclusion or absence of a serial number in the Product Identifier section of the UDI. When the serial number is present, PRT-10 must be used, while if it is absent, PRT-22 must be used.

When communicating a UDI in this field, the coding system used is limited to FDA (FDAUDI), HIBCC (HIBUDI), ICCBBA (ICCUDI), and GS1 (GS1UDI) coding systems defined in HL7 Table 0396.

Condition: At least one of the PRT-5 Person, PRT-8 Organization, PRT-9 Location, or PRT-10 Device or PRT-22 Device Type fields must be valued.

See Externally HL7 defined HL70961 in Chapter 2C for suggested values.

(Definition from DEV.3 in Ch. 17)

Definition: This field contains the type of device used in the participation.

See Externally HL7 defined 0961 in Chapter 2C for a list of suggested values. This field can repeat.

When intended to have the additional device information for the device referenced in a PRT segment in the message, DEV-2 must be equal to PRT-10 Device. When PRT-22 Device Type is used, DEV-3 must be equal.

When communicating a UDI Carrier, the UDI may either be uniquely identifying an instance of a device, or a type of device. This can be asserted based on the inclusion or absence of a serial number in the Product Identifier section of the UDI. When the serial number is present, PRT-10 must be used, while if it is absent, PRT-22 must be used.

When communicating a UDI Carrier in this field, the coding system used is limited to FDA (FDAUDI), HIBCC (HIBUDI), ICCBBA (ICCUDI), and GS1 (GS1UDI) coding systems defined in HL7 Table 0396.

Condition: Either DEV-2 Unique Device Identifier or DEV-3 Device Type must be valued, or both are valued.

PRT-23: Preferred Method of Contact (CWE) 00684

(Definition from PRT.23 in Ch. 7)

Definition: This field contains the preferred method to use when communicating particularly when the contact is a person or organization This is typically used in combination with PRT-5 Person, and/or PRT-8 Organization. Refer to User-defined Table 0185 - Preferred Method of Contact in Chapter 2C, "Code Tables", for suggested values.

(Definition from PRD.6 in Ch. 11)

Definition: This field contains the preferred method to use when communicating with the provider. Refer to User-defined Table 0185 - Preferred Method of Contact in Chapter 2C, "Code Tables", for suggested values.

(Definition from CTD.6 in Ch. 11)

Definition: This field contains the preferred method to use when communicating with the contact person. Refer to User-defined Table 0185 - Preferred Method of Contact in Chapter 2C, "Code Tables", for suggested values.

(Definition from STF.16 in Ch. 15)

Definition: This field indicates which of a group of multiple phone numbers is the preferred method of contact for this person. Note that all values of this code refer to this segment's phone field, except for the value "E," which refers to the E-mail address field. If more than one phone number of the preferred type exists in STF-10-phone, this field refers to the first such instance. Refer to HL7 Table 0185 - Preferred Method of Contact in Chapter 2C, Code Tables, for valid values. This table contains values for beeper, cell phone etc.

PRT-24: Contact Identifiers (PLN) 01171

(Definition from PRT.24 in Ch. 7)

Definition: This field contains the contact identifier to use when communicating particularly when the contact is a person or organization This is typically used in combination with PRT-5 Person, and/or PRT-8 Organization. This repeating field contains the contact's unique identifiers such as UPIN, Medicare and Medicaid numbers. Refer to User-defined Table 0338 – Practitioner.

(Definition from CTD.7 in Ch. 11)

Definition: This repeating field contains the contact's unique identifiers such as UPIN, Medicare and Medicaid numbers. Refer to User-defined Table 0338 - Practitioner ID Number Type (see Chapter 2, "Code Tables") for suggested values.

Examples of use

Query/response

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

Unsolicited

The following is an unsolicited transmission of radiology data.

MSH|^~VALUEamp;|XRAY||CDB||200006021411||ORU^R01^ORU_R01|K172|P|...<cr>

PID|...<cr>

OBR|1|X89-1501^OE|78912^RD|71020^CHEST XRAY AP \T\ LATERAL|||198703290800||||...<cr>

OBX|1|CWE|19005-8^X-ray impression^LN|4|^MASS LEFT LOWER LOBE|||A|||F|...<cr>

OBX|2|CWE|19005-8^X-ray impression^LN|2|^INFILTRATE RIGHT LOWER LOBE|||A|||F|...<cr>

OBX|3|CWE|19005-8^X-ray impression^LN|3|^HEART SIZE NORMAL|||N|||F|...<cr>

OBX|4|FT|36687-2^Chest XR AP+Lat ^LN|1|circular density (2 x 2 cm) is seen in the posterior segment of

    the LLL. A second, less well-defined infiltrated circulation density is

    seen in the R mid lung field and appears to cross the minor fissure#||||||F|...<cr>

OBX|5|CWE|71020&REC|5|71020^Follow up CXR 1 month||30-45||||F|...<cr>

Laboratory

Laboratory message: electrolytes, CBC, sed rate, blood cultures and susceptibilities

MSH|...<cr>

PID|...<cr>

Electrolytes:

OBR|1|870930010^OE|CM3562^LAB|2432-6^ELECTROLYTES HCFA 98 PANEL^LN| ||198703290800|||

    401-0^INTERN^IRVING^I^^^MD^L| ||||SER|^HIPPOCRATES^HAROLD^H^^DR|(555)555-1003|

    This is requestor field #1.|Requestor field #2|Diag.serv.field #1.|

    Diag.serv.field #2.|198703311400|||F|...<cr>

OBX|1|NM|2951-2^SODIUM^LN||150|mmol/L|136-148|H||A|F|19850301|...<cr>

OBX|2|NM|2823-3^POTASSIUM^LN||4.5|mmol/L|3.5-5|N||N|F|19850301|...<cr>

OBX|3|NM|2075-0^CHLORIDE^LN||102|mmol/L|94-105|N||N|F|19850301|...<cr>

OBX|4|NM|2028-9^CARBON DIOXIDE^LN||27|mmol/L|24-31|N||N|F|19850301|...<cr>

CBC:

OBR|2|870930011^OE|HEM3268^LAB|24359-2^HEMOGRAM+DIFFERENTIAL PANEL^LN| ||198703290800|||401-0 ^

    INTERN^IRVING^I^^^MD^L|||||BLDV|^HIPPOCRATES^HAROLD^H^^DR|(555)555-1003|This is    requestor field #1.|This is Requestor field #2.|This is lab field #1.|Lab    field #2.|198703311400|||F|...<cr>

OBX|1|NM|718-7^HEMOGLOBIN^LN||13.4|GM/DL|14-18|N||S|F|19860522|...<cr>

OBX|2|NM|4544-3^HEMATOCRIT^LN||40.3|%|42-52|L||S|F|19860522|...<cr>

OBX|3|NM|789-8^ERYTHROCYTES^LN||4.56|10*6/ml|4.7-6.1|L||S|F|19860522|...<cr>

OBX|4|NM|787-2^ERYTHROCYTE MEAN CORPUSCULAR VOLUME:^LN

||88|fl|80-94|N||S|F|19860522|...<cr>

OBX|5|NM|785-6^ERYTHROCYTE MEAN CORPUSCULAR HEMOGLOBIN:^LN

||29.5|pg|27-31|N||N|F|19860522|...<cr>

OBX|6|NM|786-4^ERYTHROCYTE MEAN CORPUSCULAR HEMOGLOBIN CONCENTRATION:^LN

||33|%|33-37|N||N|F|19860522|...<cr>

OBX|7|NM|6690-2^LEUKOCYTES^LN||10.7|10*3/ml|4.8-10.8|N||N|F|19860522|...<cr>

OBX|8|NM|770-8^NEUTROPHILS/100 LEUKOCYTES^LN||68|%|||||F|...<cr>

OBX|9|NM|736-9^LYMPHOCYTES/100 LEUKOCYTES:^LN||29|%|||||F|...<cr>

OBX|10|NM|5905-5^MONOCYTES/100 LEUKOCYTES:^LN||1|%|||||F|...<cr>

OBX|11|NM|713-8^EOSINOPHILS/100 LEUKOCYTES:^LN||2|%|||||F|...<cr>

Sed rate:

OBR|3|870930011^OE|HEM3269^LAB|4537-7^ERYTHROCYTE SEDIMENTATION RATE^LN

|||198703290800|||

    401-0^INTERN^IRVING^I^^^MD^L|||||BLDV|^HIPPOCRATES^HAROLD^H^^DR|(555)555-1003|

    This is requestor field #1.|This is Requestor field #2.|This is lab field

    #1.|Lab field #2.|198703311400|||F|...<cr>

OBX|1|NM|4537-7^ERYTHROCYTE SEDIMENTATION RATE:^LN|

|7|MM/HR|0-10|N||S|F|19860522|...<cr>

Parent micro result, identifies organism

OBR|4|2740X^OE|BC376^MIC|87040^Blood culture| ||198703290800|||

    99-2^SPINNER^SAM^S||^Hepatitis risk||198703290830|BLDV|

    4010^INTERN^IRVING^I^^^MD^L|555-1022 X3472^^^^^^^3472|Requestor field 1|Requestor field 2|

    Producer's field 1|Producer's field 2|198703301000|35.00|MB|F|...<cr>

OBX|1|CWE|600-7^MICROORGANISM IDENTIFIED^LN|1|^E Coli|||A|||F|...<cr>

OBX|2|CWE|600-7^MICROORGANISM IDENTIFIED^LN|2|^S Aureus|||A|||F|...<cr>

Child micro result, gives antimicrobials susceptibilities for organism identified in first OBX of parent

OBR|5|2740X^OE|BC402^MIC|87186^Antibiotic MIC||

|198703290800||||G|^Hepatitis Risk||198703290830|BLDB

|401.0^INTERN^IRVING^I^^^MD^L|555-1022 X3472^^^^^^^3472|||||198703310900|40.00

|MB|F|600-7&MICROORGANISM IDENTIFIED&LN^1|||2740X&OE^BC376&MIC|...<cr>

OBX|1|ST|28-1^AMIPICILLIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>

OBX|2|ST|60-4^CARBENICILLIN:SUSC:PT:ISLT:QN:MIC^LN||<16|ug/ml||S|||F|...<cr>

OBX|3|ST|267-5^GENTAMICIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>

OBX|4|ST|496-0^TETRACYCLINE:SUSC:PT:ISLT:QN:MIC^LN||<1|ug/ml||S|||F|...<cr>

OBX|5|ST|408-5^PIPERACILLIN:SUSC:PT:ISLT:QN:MIC^LN||<8|ug/ml||S|||F|...<cr>

OBX|6|ST|145-3^CEFUROXIME:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>

OBX|7|ST|161-0^CEPHALOTHIN:SUSC:PT:ISLT:QN:MIC^LN||<8|ug/ml||S|||F|...<cr>

OBX|8|ST|20-8^AMOXICILLIN+CLAVULANATE:SUSC:PT:ISLT:QN:MIC^LN

||<4|ug/ml||S|||F|...<cr>

OBX|9|ST|173-5^CHLORAMPHENICOL:SUSC:PT:ISLT:QN:MIC^LN||<4|ug/ml||S|||F|...<cr>

OBX|10|ST|508-2^TOBRAMYCIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>

OBX|11|ST|12-5^AMIKACIN:SUSC:PT:ISLT:QN:MIC^LN||<4|ug/ml||S|||F|...<cr>

OBX|12|ST|516-5^TRIMETHOPRIM+SULFMOETHOXAZOLE:SUSC:PT:ISLT:QN:MIC^LN|

|<2/38|ug/ml||S|||F|...<cr>

OBX|13|ST|76-0^CEFAZOLIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>

OBX|14|ST|116-4^CEFOXITIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>

OBX|15|ST|141-2^CEFTRIAXONE:SUSC:PT:ISLT:QN:MIC^LN||<4|ug/ml||S|||F|...<cr>

OBX|16|ST|133-9^CEFTAZIDIME:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>

OBX|17|ST|185-9^CIPROFLOXACIN:SUSC:PT:ISLT:QN:MIC^LN||<1|ug/ml||S|||F|...<cr>

Second micro child result, gives susceptibilities or organism identified by Second OBX of parent

OBR|6|2740X^OE|BC403^MIC|87186^Antibiotic MIC| ||198703290800||||G|

    ^Hepatitis risk||198703290830|BLDV|401.0^INTERN^IRVING^I^^^MD^L|321-4321 X3472^^^^^^^3472|||||

    198703310900|40.00|MB|F|600-7&MICROORGANISM IDENTIFIED &LN^2|

||2740X&OE^BC376&MIC|...<cr>

OBX|1|ST|28-1^AMPICILLIN:SUSC:PT:ISLT:QN:MIC^LN||<8|ug/ml||R|||F|...<cr>

OBX|2|ST|193-3^CLINDAMYCIN:SUSC:PT:ISLT:QN:MIC^LN||<.25|ug/ml||S|||F|...<cr>

OBX|3|ST|267-5^GENTAMICIN:SUSC:PT:ISLT:QN:MIC^LN||<1|ug/ml||S|||F|...<cr>

OBX|4|ST|233-7^ERYTHROMYCIN:SUSC:PT:ISLT:QN:MIC^LN||<.5|ug/ml||S|||F|...<cr>

OBX|5|ST|383-0^OXACILLIN:SUSC:PT:ISLT:QN:MIC^LN||<.5|ug/ml||S|||F|...<cr>

OBX|6|ST|524-9^VANCOMYCIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>

OBX|7|ST|6932-8^PENICILLIN:SUSC:PT:ISLT:QN:MIC^LN||<8|ug/ml||R|||F|...<cr>

OBX|8|ST|161-0^CEPHALOTHIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...<cr>

OBX|9|ST|173-5^CHLORAMPHENICOL:SUSC:PT:ISLT:QN:MIC^LN||<4|ug/ml||S|||F|...<cr>

OBX|10|ST|12-5^AMIKACIN:SUSC:PT:ISLT:QN:MIC^LN||<16|ug/ml||S|||F|...<cr>

OBX|11|ST|185-9^CIPROFLOXACIN:SUSC:PT:ISLT:QN:MIC^LN||<1|ug/ml||S|||F|...<cr>

OBX|12|ST|428-3^RIFAMPIN:SUSC:PT:ISLT:QN:MIC^LN||<1|ug/ml||S|||F|...<cr>

Narrative report messages

This example of the body of reports shows the following observation from what are usually free text reports. The text within these examples that begins with **-- and ends with --** are explanatory comments, not a formal part of the message. The following outline shows the segments that are included in this example message.

  1. patient identifying record (PID)

  2. order record for chest x-ray (OBR)

  3. two diagnostic impressions for CXR (OBX)

  4. description record for CXR (OBX)

  5. a recommendation record for CXR (OBX)

  6. an order record for surgical pathology (OBR)

  7. a gross description record for pathology showing use of anatomy fields (OBX)

  8. a microscopic description record for pathology (OBX)

  9. vital signs request (OBR)

  10. six vital signs (OBX)

  11. part of the physical history (OBR & OBX)

  12. end record

MSH|...<cr>

PID|...<cr>

Order record for CXR

OBR|2|P8754^OE|XR1501^XR|24646-2^CXR PA+LAT^LN|||198703290800|||

401-0^INTERN^IRVING^I^^^MD^L|...<cr>

Two CXR diagnostic impressions

OBX|1|CWE|24646-2&IMP^CXR PA+LAT^LN

|1|.61^RUL^ACR~.212^Bronchopneumonia^ACR|||A|||F|...<cr>

OBX|2|CWE|24646-2&IMP^CXR PA+LAT^LN |2|51.71^Congestive heart failure^ACR|||A|||F|...<cr>

CXR Description with continuation records

OBX|3|TX|24646-2&GDT^CXR PA+LAT^LN||Infiltrate probably representing bronchopneumonia in the right lower lobe. Also pulmonary venous congestion cardiomegaly and cephalization, indicating early congestive heart failure.|...<cr>

Recommendations about CXR report to follow up one month with a repeat CXR

OBX|4|CWE|24646-2&REC^CXR PA+LAT^LN||71020^Followup CXR 1 month^AS4||||||F|...<cr>

Order record for pathology report

OBR|3|P8755^OE|SP89-739^SP|11529-5^Surgical Path

Report^LN|||198703290800|||401-0^INTERN^IRVING^I^^^MD^L|...<cr>

OBX|1|CWE|11529-5&ANT^Surgical Path Report^LN|1|Y0480-912001^orbital region^SNM||||||F|...<cr>

Gross description record (with overflow) for pathology

OBX|2|TX|22634-0^Path report.gross observation^LN||The specimen is received in four containers. The first is labeled with the patient's name and consists of three fragments of reddish-brown tissue each of which measures 2 mm in greatest dimension. They are wrapped in tissue paper and submitted in toto in a single cassette|...<cr>

Microscopic description record for pathology

OBX|3|TX|22635-7^Path report.microscopic observation^LN|1|Sections of the first specimen received for frozen section diagnosis reveal thick walled, ramifying vessels lined by a single layer of flattened endothelial cells. The thick smooth muscle walls exhibit no malignant cytologic features nor do the endothelial lining cells. Within the same specimen are also found fragments of fibrous connective tissue, bone, and nerve which are histologically unremarkable||||||F|...<cr>

Vital signs using LOINC® codes as observation identifiers

OBR|4|P8756^OE|N2345^NR|29274-8^VITAL SIGNS^LN| ||198703290800|||401-0^INTERN^IRVING^I^^^MD^L|...<cr>

OBX|1|NM|8462-4^INTRAVASCULAR DIASTOLIC:PRES^LN||90|mm(hg)|60-90||||F|...<cr>

OBX|2|NM|8479-8^INTRAVASCULAR SYSTOLIC:PRES^LN||120|mm(hg)

|100-160||||F|...<cr>

OBX|3|NM|8478-0^INTRAVASCULAR MEAN:PRES^LN||100|mm(hg)|80-120|N|||F|...<cr>

OBX|4|NM|8867-4^HEART BEAT RATE^LN||74|/min|60-100|N|||F|...<cr>

OBX|5|ST|8357-6^BLOOD PRESSURE METHOD^LN||MANUAL BY CUFF||||||F|...<cr>

OBX|6|ST|8886-4^HEART RATE METHOD^LN||MANUAL BY PALP||||||F|...<cr>

Part of the patient's history

OBR|5|P8568^OE|HX2230^^CLN||2000^HISTORY| ||198703290800||401

0^INTERN^IRVING^I^^^MD^L||...<cr>

OBX|1|CWE|8661-1^CHIEF COMPLAINT^LN||...<cr>

OBX|2|ST|8674-4^HISTORY SOURCE^LN||PATIENT||||||F|...<cr>

OBX|3|TX|8684-3^PRESENT ILLNESS^LN||SUDDEN ONSET OF CHEST PAIN. 2 DAYS,

PTA ASSOCIATED WITH NAUSEA, VOMITING \T\ SOB. NO RELIEF WITH ANTACIDS

OR NTG. NO OTHER SX. NOT PREVIOUSLY ILL.||||||F|...<cr>

    .

    .

and so on.

Reporting Cultures and Susceptibilities

Culture battery/report representation

Organisms and other observations/tests are reported using multiple OBX segments. The granularity expected for HL7culture reports is one observation per organism.

All OBX segments which have the same observation ID and sub-ID are part of a single observation.

Each organism in a culture battery is assigned a unique OBX-4 Observation Sub-ID (and is therefore a separate observation). The organism name is given in OBX-5 Observation Value (results). It is recommended, but not required, that the organism name may change over time, but the corresponding observation sub-ID never changes. (The observation ID will be identical for all organisms reported.)

Recommended:

OBX|1|CWE|600-7^Micro Organism Identified^LN|1|^E. Coli||||||F|...<cr>

OBX|2|CWE|600-7^Micro Organism Identified^LN |2|^S. Aureus||||||F|...<cr>

Not recommended:

OBX|1|CWE|600-7^Micro Organism Identified^LN |1|^E. Coli||||||F|...<cr>

OBX|2|CWE|600-7^Micro Organism Identified^LN |1|^S. Aureus||||||F|...<cr>

Susceptibility battery/report representation

Each antimicrobial should be reported as a separate (OBX) observation where the Observation ID is a code for the antimicrobial. (OBXs for non-antimicrobials observations and related information may be present in the same battery.)

MIC and disk diffusion (Kirby Bauer) susceptibility results can be combined in the same OBX segment. An OBX can contain a MIC value (in OBX-5 Observation Value (results)) and OBX-8 Interpretation Codes that indicates whether the organism is sensitive, resistant, or intermediate (see HL7 Table 0078 - Interpretation Codes under abnormal flag fields).

Or, an OBX can contain a disk diffusion result string (e.g., sensitive) in the Observation Results field and the disk diffusion interpretation in OBX-8 Interpretation Codes (e.g., S).

A susceptibility battery may only contain results corresponding to a single organism that has been previously reported in a culture battery.

Identification of the organism for a susceptibility battery

The following is the preferred, but not required method of organizing data about antimicrobial susceptibility.

A susceptibility battery may only contain results corresponding to a single organism that has been previously reported in a culture battery.

A susceptibility battery is always a child order to a culture battery. OBR-29 Parent (parent's filler order number) in the susceptibility OBR is equal to OBR-3 Filler Order Number in the parent culture OBR and is used to link the two batteries logically.

The susceptibility battery also contains a linkage back to a particular organism in the culture battery. OBR-26 Parent Result of the susceptibility OBR contains two components--OBX-3 Observation Identifier (code only) and OBX-4 Observation Sub-ID of the OBX in the culture battery which contains the organism name.

The identity of an organism/isolate is expected to be refined over time. When an organism identification changes, the parent culture battery can be resent without resending the child susceptibility battery.

The case may occur where a susceptibility battery is reported on an organism which has not yet been identified. In this case, it is required that a placeholder OBX for the organism name be reported in the corresponding culture battery so that OBR-26 Parent Result in the susceptibility OBR will point to a valid organism OBX in the culture battery. Transmission of an organism OBX (in the culture battery) with the Sub-ID field valued must precede the susceptibility battery which uses the identical Sub-ID in OBR-26 Parent Result.

Discussion and examples:

Order micro results (blood culture)

MSH|^~VALUEamp;|LAB1||DESTINATION||19910127105114||ORU^R01^ORU_R01|LAB1003929|...<cr>

PID|...<cr>

PV1|...<cr>

ORC|NW|...<cr>

OBR|1|A485388^OE|H29847^LAB1|17928-3^BLOOD CULTURE^LN|||...<cr>

Result for culture

ORC|RE|...<cr>

OBR|1|A485388^OE|H29847^LAB1|17928-3^BLOOD CULTURE ^LN||...<cr>

OBX|1|FT|SDES^SOURCE||BLOOD-RAPID||||||F|...<cr>

OBX|2|FT|664-3^GRAM STAIN SMEAR^LN||GRAM POSITIVE COCCI IN GROUPS||||||F|...<cr>

OBX|3|FT|600-7^MICROORGANISM IDENTIFIED^LN|1|ISOLATE 1||||||F|...<cr>

Result for susceptibility

ORC|RE|...<cr>

OBR|1|A485388^OE|H29848^LAB1|BT1^SUSCEPTIBILITY BATTERY||||||123^MANSFIELD^CHARLES| ||||||||||||||||600-7&MICROORGANISM IDENTIFIED&LN ^1|||A485388&OE^H29847&LAB1|...<cr>

OBX|1|NM|6932-8^PENICILLIN MIC^LN||0.5|||R|||F|...<cr>

OBX|2|NM|347-5^NAFCILLIN MIC^LN||1|||R|||F|...<cr>

OBX|3|ST|193-3^CLINDAMYCIN MIC^LN||<=0.1|||S|||F|...<cr>

Result for Culture ID

ORC|RE|...<cr>

OBR|1|A485388^OE|H29847^LAB1|17928-3^BLOOD CULTURE ^LN||...<cr>

OBX|1|FT|600-7^ MICROORGANISM IDENTIFIED^LN |1|STAPH EPI||||||F|...<cr>

New result for culture ID

ORC|RE|...<cr>

OBR|1|A485388^OE|H29847^LAB1|17928-3^BLOOD CULTURE ^LN||...<cr>

OBX|1|FT|600-7^MICROORGANISM IDENTIFIED^LN|1|STAPH EPI SERO TYPE 3||||||F|...<cr>

Assumptions

  1. All OBXs in the parent order must employ the same coding scheme.

  2. The Sub-ID of the parent OBXs (result) cannot change.

EKG Results Reporting

Suppose an order has been placed to the EKG system for three EKGs to be performed on successive days. These results can be reported in various ways.

  1. The EKG application needs to communicate to anyone the results of the 1st EKG:

ORU message:

MSH|...<cr>

PID|...<cr>

Order record for EKG

OBR|1|P8753^OE|EK5230^EKG|8601-7^EKG impression^LN|||198703290800|||401

0^INTERN^IRVING^I^^^MD^L|...<cr>

Two interpretation records for EKG

OBX|1|CWE|8601-7^EKG impression^LN|1|^Sinus bradycardia|||A|||F|...<cr>

OBX|2|CWE|8601-7^EKG impression^LN |2|^Occasional PVCs|||A|||F|...<cr>

Four numeric results for EKG

OBX|3|NM|8897-1^QRS COMPLEX RATE ^LN|

|80|/min|60-100|||||F|...<cr>

OBX|4|NM|8894-8^PULSE RATE^LN||80|/min

|60-100||||F|...<cr>

OBX|5|NM|8633-0^QRS DURATION ^LN||.08|msec

|.06-.10||||F|...<cr>

OBX|6|NM|8625-6^P-R INTERVAL ^LN||.22|msec

|.18-.22||||F|...<cr>

  • Notice that this report is without reference to the original order.

  • No ORC is required because the identifying Fillers Order Number (and other ORC fields) is carried in the OBR segment.

  • The EKG application needs to communicate to anyone the original order information, the details of the child orders, the fact of the child spin off, and the results of all three EKGs:

ORU message:

MSH|...<cr>

PID|...<cr>

ORC|PA|A226677^OE|89-450^EKG|...<cr> // original order's ORC.

OBR|1|||8601-7^EKG REPORT|...<cr> // original order segment

ORC|CH|A226677^OE|89-451^EKG|...<cr> // 1st child ORC.

OBR|1|||8601-7^EKG REPORT|...<cr> // 1st EKG child OBR.

OBX|1|ST|...<cr> // 1st EKG report

OBX|2|ST|...<cr>

    ...

OBX|14|FT|...<cr>

ORC|CH|A226677^OE|89-452^EKG|...<cr> // 2nd child ORC.

OBR|1|||8601-7^EKG REPORT|...<cr> // 2nd EKG child OBR.

OBX|1|ST|...<cr> // 2nd EKG report

OBX|2|ST|...<cr>

    ...

OBX|14|FT|...<cr>

ORC|CH|A226677^OE|89-453^EKG|...<cr> // 3rd child ORC.

OBR|1|||8601-7^EKG REPORT|...<cr> // 3rd EKG child OBR.

OBX|1|ST|...<cr> // 3rd EKG report

OBX|2|ST|...<cr>

    ...

OBX|14|FT|...<cr>

... // Other parts of message might follow.

In this case, we are transmitting the information about the fact of child spin off, the original order and the results all at the same time. Thus, this form of the ORU message reports not only the results of an order, but all of its associated ordering information including the original OBR for three EKGs that was replaced by three separate OBR EKG segments.

Patient-Specific Clinical Data with an Order

Reporting body weight and height with a creatinine clearance.

MSH|...<cr>

PID|...<cr>

ORC|NW|...<cr> // New order.

OBR|1|P42^PC||2164-2^CREATININE RENAL CLEARANCE: QN^LN|...<cr>

OBX|1|NM|3141-9^BODY WEIGHT^LN||62|kg|...<cr>

OBX|2|NM|3137-7^BODY HEIGHT^LN||190|cm|...<cr>

ORC|NW|...<cr> // Next order.

Patient-connected medical device reporting

Information acquired from patient-connected medical devices may be relatively simple, such as monitored values from a pulse-oximeter or infusion pump, or highly complex and rich such as comprehensive data from a multi-parameter physiological monitor or ventilator. In acute care contexts, many devices may be associated with a single patient and are often added and removed during an episode of care. Though point-of-care devices typically use non-HL7 protocols for their communication interfaces, data acquired from these devices are often aggregated and periodically published to enterprise applications using an HL7-based interface.

In order to enhance interoperability between point-of-care medical device systems and enterprise applications, there have been a number of collaborative projects to establish a consistent mapping of information acquired from these devices to HL7 messages. This clause provides an overview and examples of such a project by the IHE Patient Care Device ("PCD") group4 that defines a consistent mapping from specialized device semantics to HL7 messages.

Standardized representation of device semantics is provided by the ISO/IEEE 11073 ("X73") family of standards. Specifically the ISO/IEEE 11073-10101 standard5 provides a nomenclature or terminology for the representation of device information and is referenced in HL7 Table 0396 – Coding System as "MDC."

Additionally, a device-specific information model is defined, ISO/IEEE 11073-10201 Domain Information Model ("DIM"), to support the specialized, real-time communication needs of medical devices. The following diagram presents a simplified example of the X73 objects in which a given observation or Metric::Numeric are contained. The MDS, VMD, and Channel objects provide the information that is often necessary to identify specific devices and their configuration (e.g., serial numbers or internal time settings), as well as the association of data items that come from the same device subsystem (VMD or Channel) and shouldn't be confused with other observations that may have the same identifier.

The IHE PDC Device-to-Enterprise ("DEC") profile defines a single HL7 message, ORU^R01, that maps X73 abstract device semantics to specific message segments and fields. The message specification includes the following:

  • Device terms should be communicated using their "MDC" code within and among devices. Between devices and medical record systems other standard vocabulary, e.g., LOINC (emerging as the global standard) and SNOMED, may be used.

  • Units of measurement may be either those defined in the ISO/IEEE 11073-10101 Nomenclature, or UCUM. Carrying both is recommended.

  • Devices and device-related applications and systems are identified using the 64-bit IEEE EUI-64 identifier (Table 0301) that is specified in the X73 standards.

  • OBX-4 is used with a dotted nomenclature6 to indicate containment of specific measurements within Channels, Virtual Medical Devices and Medical Device Systems.

Complete details of this message profile are defined in the IHE PCD DEC framework. The following message examples illustrate how device information is communicated using this profile.

Message Example from a Single Simple Device

MSH|^~VALUEamp;|PAT_DEVICE_PUMPCO^0012210000000001^EUI-64|PUMPCO|CIS_HITCO|HITCO|20071204153604-0600||ORU^R01^ORU_R01|11|P|2.8|||NE|AL||ASCII|EN^English^ISO659||IHE PCD ORU-R01 2006^HL7^2.16.840.1.113883.9.n.m^HL7

PID|||CD60002^^^IHE^PI||Darwin^Charles^^^^^L|Emerine|19620101000000-0600|M

PV1||I|3 West ICU^3002^1

OBR|0|AB12345^HL7^ACDE48234567ABCD^EUI-64|CD12345^HL7^ACDE48234567ABCD^EUI-64|69985^MDC_DEV_PUMP_INFUS_MDS^MDC|||20071204153602-0600

OBX|1||69985^MDC_DEV_PUMP_INFUS_MDS^MDC|1000002.0.0.0|||||||X|||||N60002||^^A0002^PUMPCO

OBX|2||69986^MDC_DEV_PUMP_INFUS_VMD^MDC|1000002.1.0.0|||||||X

OBX|3||126978^MDC_DEV_PUMP_INFUS_CHAN_DELIVERY^MDC|1000002.1.1.0|||||||X

OBX|4||126977^MDC_DEV_PUMP_INFUS_CHAN_SOURCE^MDC|1000002.1.2.0|||||||X

OBX|5||126977^MDC_DEV_PUMP_INFUS_CHAN_SOURCE^MDC|1000002.1.3.0|||||||X

OBX|6|NM|68063^MDC_ATTR_PT_WEIGHT^MDC|1000002.0.0.2|95.0|1731^kg^UCUM^263875^MDC_DIM_X_KILO_G^MDC|||||R|||20071204153602-0600|||||20071204153602-0600

OBX|7|ST|184504^MDC_PUMP_MODE^MDC|1000002.1.1.101|pump-mode-drug-dosing||||||R|||20071204153602-0600|||||20071204153602-0600

OBX|8|ST|184508^MDC_PUMP_STAT^MDC|1000002.1.1.102|pump-status-infusing||||||R|||20071204153602-0600|||||20071204153602-0600

OBX|9|NM|157784^MDC_FLOW_FLUID_PUMP^MDC|1000002.1.1.103|24.9|3122^mL/h^UCUM^265266^MDC_DIM_MILLI_L_PER_HR^MDC|||||R|||20071204153602-0600|||||20071204153602-0600

OBX|10|NM|157784^MDC_FLOW_FLUID_PUMP^MDC|1000002.1.2.201|24.9|3122^mL/h^UCUM^265266^MDC_DIM_MILLI_L_PER_HR^MDC|||||R|||20071204153602-0600|||||20071204153602-0600

OBX|11|NM|157872^MDC_VOL_FLUID_TBI_REMAIN^MDC|1000002.1.2.202|250.0|1618^mL^UCUM^263762^MDC_DIM_MILLI_L^MDC|||||R|||20071204153602-0600|||||20071204153602-0600

OBX|12|NM|157916^MDC_TIME_PD_REMAIN^MDC|1000002.1.2.203|601|2208^min^UCUM^264352^MDC_DIM_MIN^MDC|||||R|||20071204153602-0600|||||20071204153602-0600

OBX|13|ST|184330^MDC_DRUG_NAME_TYPE^MDC|1000002.1.2.204|DOPamine||||||R|||20071204153602-0600|||||20071204153602-0600

OBX|14|NM|157760^MDC_CONC_DRUG^MDC|1000002.1.2.205|1.6|2162^mg/mL^UCUM^264306^MDC_DIM_MILLI_G_PER_ML^MDC|||||R|||20071204153602-0600|||||20071204153602-0600

OBX|15|NM|157924^MDC_RATE_DOSE^MDC|1000002.1.2.206|7.00|3475^ug/kg/min^UCUM^265619^MDC_DIM_MICRO_G_PER_KG_PER_MIN^MDC|1-20||||R|||20071204153602-0600|||||20071204153602-0600

Message Example for Multiple Devices

MSH|^~VALUEamp;|CIS_HITCO ^ACDE48234567ABCD^EUI-64||||20061220214210-0500||ORU^R01^ORU_R01|D1220214210609b5f9aa|P|2.8|||NE|AL

PID|||LM60005^^^Health IT Co^PI||Montgomery^Larry^^^^^L||19560101000000|M

PV1||I|UNIT_1^^Bed1

OBR|1|D1220214210609b5f9aa^CIS_HITCO^ACDE48234567ABCD^EUI-64|D1220214210609b5f9aa^CIS_HITCO^ACDE48234567ABCD^EUI-64|69640^MDC_DEV_ANALY_SAT_O2^MDC|||20061220213500

OBX|1|NM|150456^MDC_PULS_OXIM_SAT_O2^MDC|1.1.1.150456|99|262688^MDC_DIM_PERCENT^MDC||N|||F|||20061220213500

OBR|2|D1220214210609b5f9aa^CIS_HITCO^ACDE48234567ABCD^EUI-64|D1220214210609b5f9aa^CIS_HITCO^ACDE48234567ABCD^EUI-64|69636^MDC_DEV_ANALY^MDC|||20061220213500

OBX|1|NM|147842^MDC_ECG_HEART_RATE^MDC|1.1.1.147842|133|264864^MDC_DIM_BEAT_PER_MIN^MDC||A|||F|||20061220213500

OBR|3|D1220214210609b5f9aa^CIS_HITCO^ACDE48234567ABCD^EUI-64|D1220214210609b5f9aa^CIS_HITCO^ACDE48234567ABCD^EUI-64|69708^MDC_DEV_ANALY_PRESS_BLD^MDC|||20061220213500

OBX|1|NM|150037^MDC_PRESS_BLD_ART_ABP_SYS^MDC|1.1.1.150037|126|266016^MDC_DIM_MMHG^MDC||N|||F|||20061220213500

OBX|2|NM|150038^MDC_PRESS_BLD_ART_ABP_DIA^MDC|1.1.1.150038|76|266016^MDC_DIM_MMHG^MDC||N|||F|||20061220213500

OBX|3|NM|150039^MDC_PRESS_BLD_ART_ABP_MEAN^MDC|1.1.1.150039|92|266016^MDC_DIM_MMHG^MDC||N|||F|||20061220213500

OBR|4|D1220214210609b5f9aa^CIS_HITCO^ACDE48234567ABCD^EUI-64|D1220214210609b5f9aa^CIS_HITCO^ACDE48234567ABCD^EUI-64|69708^MDC_DEV_ANALY_PRESS_BLD^MDC|||20061220213500

OBX|1|NM|150087^MDC_PRESS_BLD_VEN_CENT_MEAN^MDC|1.1.1.150087|12|266048^MDC_DIM_CM_H2O^MDC||N|||F|||20061220213500

OBR|5|D1220214210609b5f9aa^CIS_HITCO^ACDE48234567ABCD^EUI-64|D1220214210609b5f9aa^CIS_HITCO^ACDE48234567ABCD^EUI-64|69708^MDC_DEV_ANALY_PRESS_BLD^MDC|||20061220213500

OBX|1|NM|150045^MDC_PRESS_BLD_ART_PULM_SYS^MDC|1.1.1.150045|26|266016^MDC_DIM_MMHG^MDC||A|||F|||20061220213500

OBX|2|NM|150046^MDC_PRESS_BLD_ART_PULM_DIA^MDC|1.1.1.150046|9|266016^MDC_DIM_MMHG^MDC||A|||F|||20061220213500

OBX|3|NM|150047^MDC_PRESS_BLD_ART_PULM_MEAN^MDC|1.1.1.150047|14|266016^MDC_DIM_MMHG^MDC||A|||F|||20061220213500

[4] Information on Integrating the Healthcare Enterprise (“IHE”), including PCD message profiles are available at www.IHE.net.

[5] Additional ISO/IEEE 11073-1010x standards may be used to represent abstract device semantics, such as ISO/IEEE 11073-10102 Annotated ECG.

[6] See section 7.4.2.5 OBX-4 Observation Sub-ID discussion, including Figure 7-4 Example of sub-identifier usage.

Clinical Trials

Academic medical institutions, academic research coordinating centers, and industry-based research organizations often have computer systems that support registration, compliance and safety monitoring, and outcomes analysis for clinical trials. Patients on these trials may receive their treatment and evaluation at one research facility or at many different medical facilities. Clinical trials systems could message other applications that a patient is registered on a clinical trial. Several functional examples follow:

  • (1) Some of the data required to monitor or analyze outcomes on the trial are generated in other medical computer systems, such as pharmacy, laboratory, or clinical applications. These applications may tag patients on clinical trials so that data may be sent back to the clinical trials system.

  • (2) Order entry systems could also use patient registration information: they could display standard order sets for the protocol or particular treatment/evaluation phases of a complex protocol. They could pass the clinical trials status on to service provider applications to initiate a results report to the clinical trials system. It could also be passed to billing applications that may use specialized procedures for research-related costs.

  • (3) Nursing and pharmacy systems can use information on patients' clinical trials status for care plans or dispensing authorization (auxiliary to the physician's prescription), respectively. There could be many other uses of this message since a patient's involvement on a clinical trial affects all concurrent medical care.

To meet monitoring and analysis requirements, patient registration, treatment, diagnostic, and study summary data are reported to study sponsors like pharmaceutical or medical device companies, regulatory agencies, and data management centers for collaborative studies. Automated procedures must be used to transfer these voluminous data among the participant computer systems in a cost-efficient and timely manner. The following additions to HL7 aim to specify standard messaging transactions to automate such reporting as well as to enable communication of clinical trials registration data to relevant medical applications as described above.

The objectives of the clinical trials messages and segments are to identify that patients are registered on clinical trials, have entered a study-specific phase of treatment or evaluation, or to indicate the study protocol's data schedule. Messages include OBR (section 4.5.3, "OBR - Observation Request Segment"), OBX (section 7.4.2, "OBX - Observation/Result Segment"), RXA (section 4.14.7, "RXA - Pharmacy /Treatment Administration Segment"), and RXR (section 4.14.2, "RXR - pharmacy/Treatment Route Segment") segments to report observations or drug administration that are relevant to the study. In addition to study-related clinical data, OBX segments may contain the results of study variables according to master code tables such as the Health Outcomes Variables (HL7 Implementation Guide). There are also master segments to describe the clinical trial, its treatment phases, and its scheduled date-time points for message recipients. These are analogous to the Test/Observation Master Segments (Chapter 8), with the trials, phases, or scheduled time points treated as the OMX treats observation identifiers.

Glossary

Clinical trial:

A scientifically rigorous study of individual outcomes to some process of healthcare intervention. Clinical trials usually involve medical treatments so this document will use the term treatment, rather than the broader term intervention. A clinical trial design may randomly assign and compare one treatment approach with another, or generate safety and efficacy data on a single treatment approach. The clinical trial has a protocol for the patient's course of treatment and/or evaluation. There is usually a schedule for collection of data to measure compliance, safety, and outcomes.

Phase of a clinical trial:

A treatment and/or observation interval of a clinical trial. A phase may represent an interval with a specific treatment regimen assigned randomly or otherwise, with each regimen of a progression of treatments, or with an evaluation component only. Generally, for each phase, there is an explicit patient management, evaluation, and data collection schedule. Each of these phases may have associated safety, outcome, and quality-control variables. A simpler study design need not use the phase structures.

The phase structure serves several purposes in the clinical trials messages. Other computer systems may need to know that the patient has begun a phase with a particular treatment regimen or diagnostic schedule, such as the pharmacy or order entry systems. When reporting study data, observations and variables often describe particular phase instances. For example, each course of treatment may have its own values for the same set of observations or variables. Phase instances may also have distinct data schedules that need to be linked to submitted data.

Several examples follow with each line depicting a phase.

Example 1

Alternating treatment plus observation intervals:

__________> _________> _________> _________> ...

Rx A Rx B Rx A Rx B

Example 2

Random assignment to two courses each of treatment A or B, all responding patients to treatment C, continue with observation and a diagnostic regimen after all treatment phases are completed. Treatment phases include the evaluation component for that course of treatment:

___________> __________

Rx A Crs 1 Rx A Crs 2

VALUEgt; __________> __________> _______

/ Rx C Crs 1 Rx C Crs 2

Observe

___________> __________/

Rx B Crs 1 Rx B Crs 2

Example 3

Random assignment to placebo or treatment A, both taken daily and evaluated monthly.

___________> __________> __________> __________> . . .

Month 1 Month 2 Month 3 Month 4

Data schedule:

The treatment, diagnostic, and procedural requirements, as well as data collection due dates, scheduled on a timeline for most clinical trials. As data are reported, they may need to reflect the scheduled time point that they satisfy. Clinical trials quality control requires attention to compliance between the protocol's schedule and patient data records.

The data schedule will be keyed by time points relative to the study. Some data may be due prior to and at the conclusion of the study and/or one or more of its phases. Some are interim within the study or its phases depending on protocol events such as administration of treatment, arbitrary time intervals instated to make and record assessments, or some clinical milestone such as relapse of disease. Often, multiple data parameters are scheduled at the same time point. Several examples follow:

Schedule for a randomized cancer prevention trial
Figure 7-5 Basic ISO/IEEE 11073-10201 Containment Tree

Treatment 1st - 3rd Years

Reg

Rand

Months

3

6

9

12

18

24

30

36

42

48

54

60

66

72

78

84

Disease Staging

X

H & P

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

Assess Adverse Events and Outcome Variables

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

Chest PAL X-ray

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

CBC, Diff, Plt

X

X

X

X

X

X

X

X

X

X

X

X

SMA 12

X

X

X

X

X

X

X

X

X

X

X

X

X

Cholesterol and Triglyceride

X

X

X

X

X

X

X

X

X

Electrolytes

X

Plasma Retinoic Acid

X

X

Cotinine Level (nonsmokers)

X


Schedule for a cancer chemotherapy trial


Prestudy

Prior to Each Cycle


During Cycle

Every 3 Cycles


End Study

Informed Consent

X

X

H & P Neurologic

X1

X

Vital Signs

X1

X2

X

Disease Staging

X

X3

X

ECG

X1

X4

Radiology*

X

X5

X

Chest X-ray

X

X

X

Bone Marrow Bx.

X6

HCG

X1

Assess Adverse Events

X

X

CBC, Diff, Plt

X1

X7

X

UA, PT, PTT

X1

X

SMA12, Mg, CEA

X1

X

X

  1. Within 3 days prior to start of infusion.

  2. At 0,10,30, and 60 minutes after start of drug administration and one-half hour after test drug infusion ends for cycles 1 and 2. For subsequent cycles at 0 and 10 minutes after start of drug administration, and at the end of infusion.

  3. Record tumor measurements at the end of every cycle if assessable clinically by physical examination or with simple X-ray.

  4. Continuous ECG monitoring during infusion if necessary, due to bradycardia (<50 beats/min) or other significant cardiac findings.

  5. When measurable disease requires complex radiologic studies such as CT or radionucleide scans.

  6. To be done at baseline (if clinically indicated) at the option of the investigator and also during study if patient has prolonged myelosuppression (WBC<2000 cells/mm3>14 days).

  7. Blood counts will be done twice weekly during cycles 1 and 2, then weekly.

  8. *    Radionucleide scan and X-ray of the bones, CT scans of the chest, pelvis, and brain only when clinically indicated.

Schedule for a randomized pain medication trial

Day 1
Before RX

Day 1
After RX


Daily


Day 30

H & P

X

X

Creat, Bili, SGOT

X

Urinalysis

X

Pain Diagnosis

X

Opioid Dose Strand

X

X

X

X

Non-opioid Analgesic

X

X

X

Medications for Side Effects

X

X

X

Phone Report: Pain and Side Effects

X

Visual Analog Scales

X

X

X

X

Pain Evaluation Form

X

X

Clinical Trials - Trigger Events And Message Definitions

The event type will be carried in the message header segment.

CRM - Clinical Study Registration Message (Events C01-C08)

The data are entered in a clinical trials or other patient data system and broadcast to other facility systems such as order entry, pharmacy, accounting, and nursing systems. They can be transmitted in batch mode or broadcast to outside-facility computer systems, including diagnostic and patient management systems. It is assumed that proper routing and security mechanisms are in place.

The general acknowledgement message as defined in Chapter 2 should be used for any acknowledgements.

Event

Description

C01

Register a patient on a clinical trial

C02

Cancel a patient registration on clinical trial (for clerical mistakes since an intended registration should not be canceled)

C03

Correct/update registration information

C04

Patient has gone off a clinical trial

C05

Patient enters phase of clinical trial

C06

Cancel patient entering a phase (clerical mistake)

C07

Correct/update phase information

C08

Patient has gone off phase of clinical trial

CRM^C01^CRM_C01: Clinical Trial Message
HL7 MessageStructure Table - CRM_C01
Segment Cardinality Must Implement Status
CRM_C01
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PATIENT 1..* Yes
PID 1..1 Yes
PRT 0..*
ARV 0..* B
CSR 1..1 Yes
CSP 0..*
PATIENT_VISIT 0..1
PV1 1..1 Yes
PRT 0..*

Original Mode Acknowledgement Choreography for CRM^C01^CRM_C01

Send Application Ack: ACK^C01^ACK

Enhanced Mode Acknowledgement Choreography for CRM^C01^CRM_C01

When the MSH-15 value of a CRM^C01^CRM_C01 message is AL or ER or SU, an ACK^C01^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a CRM^C01^CRM_C01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a CRM^C01^CRM_C01 message is AL or ER or SU, an ACK^C01^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a CRM^C01^CRM_C01 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^C01^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^C01^ACK
NE (none)

CRM^C02^CRM_C01: Clinical Trial Message
HL7 MessageStructure Table - CRM_C01
Segment Cardinality Must Implement Status
CRM_C01
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PATIENT 1..* Yes
PID 1..1 Yes
PRT 0..*
ARV 0..* B
CSR 1..1 Yes
CSP 0..*
PATIENT_VISIT 0..1
PV1 1..1 Yes
PRT 0..*

Original Mode Acknowledgement Choreography for CRM^C02^CRM_C01

Send Application Ack: ACK^C02^ACK

Enhanced Mode Acknowledgement Choreography for CRM^C02^CRM_C01

When the MSH-15 value of a CRM^C02^CRM_C01 message is AL or ER or SU, an ACK^C02^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a CRM^C02^CRM_C01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a CRM^C02^CRM_C01 message is AL or ER or SU, an ACK^C02^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a CRM^C02^CRM_C01 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^C02^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^C02^ACK
NE (none)

CRM^C03^CRM_C01: Clinical Trial Message
HL7 MessageStructure Table - CRM_C01
Segment Cardinality Must Implement Status
CRM_C01
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PATIENT 1..* Yes
PID 1..1 Yes
PRT 0..*
ARV 0..* B
CSR 1..1 Yes
CSP 0..*
PATIENT_VISIT 0..1
PV1 1..1 Yes
PRT 0..*

Original Mode Acknowledgement Choreography for CRM^C03^CRM_C01

Send Application Ack: ACK^C03^ACK

Enhanced Mode Acknowledgement Choreography for CRM^C03^CRM_C01

When the MSH-15 value of a CRM^C03^CRM_C01 message is AL or ER or SU, an ACK^C03^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a CRM^C03^CRM_C01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a CRM^C03^CRM_C01 message is AL or ER or SU, an ACK^C03^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a CRM^C03^CRM_C01 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^C03^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^C03^ACK
NE (none)

CRM^C04^CRM_C01: Clinical Trial Message
HL7 MessageStructure Table - CRM_C01
Segment Cardinality Must Implement Status
CRM_C01
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PATIENT 1..* Yes
PID 1..1 Yes
PRT 0..*
ARV 0..* B
CSR 1..1 Yes
CSP 0..*
PATIENT_VISIT 0..1
PV1 1..1 Yes
PRT 0..*

Original Mode Acknowledgement Choreography for CRM^C04^CRM_C01

Send Application Ack: ACK^C04^ACK

Enhanced Mode Acknowledgement Choreography for CRM^C04^CRM_C01

When the MSH-15 value of a CRM^C04^CRM_C01 message is AL or ER or SU, an ACK^C04^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a CRM^C04^CRM_C01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a CRM^C04^CRM_C01 message is AL or ER or SU, an ACK^C04^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a CRM^C04^CRM_C01 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^C04^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^C04^ACK
NE (none)

CRM^C05^CRM_C01: Clinical Trial Message
HL7 MessageStructure Table - CRM_C01
Segment Cardinality Must Implement Status
CRM_C01
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PATIENT 1..* Yes
PID 1..1 Yes
PRT 0..*
ARV 0..* B
CSR 1..1 Yes
CSP 0..*
PATIENT_VISIT 0..1
PV1 1..1 Yes
PRT 0..*

Original Mode Acknowledgement Choreography for CRM^C05^CRM_C01

Send Application Ack: ACK^C05^ACK

Enhanced Mode Acknowledgement Choreography for CRM^C05^CRM_C01

When the MSH-15 value of a CRM^C05^CRM_C01 message is AL or ER or SU, an ACK^C05^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a CRM^C05^CRM_C01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a CRM^C05^CRM_C01 message is AL or ER or SU, an ACK^C05^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a CRM^C05^CRM_C01 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^C05^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^C05^ACK
NE (none)

CRM^C06^CRM_C01: Clinical Trial Message
HL7 MessageStructure Table - CRM_C01
Segment Cardinality Must Implement Status
CRM_C01
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PATIENT 1..* Yes
PID 1..1 Yes
PRT 0..*
ARV 0..* B
CSR 1..1 Yes
CSP 0..*
PATIENT_VISIT 0..1
PV1 1..1 Yes
PRT 0..*

Original Mode Acknowledgement Choreography for CRM^C06^CRM_C01

Send Application Ack: ACK^C06^ACK

Enhanced Mode Acknowledgement Choreography for CRM^C06^CRM_C01

When the MSH-15 value of a CRM^C06^CRM_C01 message is AL or ER or SU, an ACK^C06^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a CRM^C06^CRM_C01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a CRM^C06^CRM_C01 message is AL or ER or SU, an ACK^C06^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a CRM^C06^CRM_C01 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^C06^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^C06^ACK
NE (none)

CRM^C07^CRM_C01: Clinical Trial Message
HL7 MessageStructure Table - CRM_C01
Segment Cardinality Must Implement Status
CRM_C01
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PATIENT 1..* Yes
PID 1..1 Yes
PRT 0..*
ARV 0..* B
CSR 1..1 Yes
CSP 0..*
PATIENT_VISIT 0..1
PV1 1..1 Yes
PRT 0..*

Original Mode Acknowledgement Choreography for CRM^C07^CRM_C01

Send Application Ack: ACK^C07^ACK

Enhanced Mode Acknowledgement Choreography for CRM^C07^CRM_C01

When the MSH-15 value of a CRM^C07^CRM_C01 message is AL or ER or SU, an ACK^C07^ACK message SHALL be sent as an immediate ack.

When the MSH-15 value of a CRM^C07^CRM_C01 message is NE, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a CRM^C07^CRM_C01 message is AL or ER or SU, an ACK^C07^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a CRM^C07^CRM_C01 message is NE, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^C07^ACK
NE (none)
MSH-16 AL, ER, SU application ack: ACK^C07^ACK
NE (none)

CRM^C08^CRM_C01: Clinical Trial Message