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

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.

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^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..*
NEXT_OF_KIN 0..*
NK1 1..1 Yes
OH2 0..*
OH3 0..1
ARV 0..* B
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
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
ORDER_DOCUMENT 0..1
OBX 1..1 Yes
PRT 0..*
TXA 1..1 Yes
OBR 1..1 Yes
NTE 0..*
OBSERVATION_PARTICIPATION 0..*
PRT 1..1 Yes
DEV 0..*
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
CTD 0..1
OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
NTE 0..*
FT1 0..*
CTI 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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

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

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

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^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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

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

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

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^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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

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

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

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^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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

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

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.

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^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 or AL or ER or SU, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of an ORA^R33^ORA_R33 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

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

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..*
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
ORDER_DOCUMENT 0..1
OBX 1..1 Yes
PRT 0..*
TXA 1..1 Yes
NTE 0..*
PRT 0..* Deprecated
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..*
CTI 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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R22^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^R22^ACK
NE, AL, ER, SU (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..*
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
ORDER_DOCUMENT 0..1
OBX 1..1 Yes
PRT 0..*
TXA 1..1 Yes
NTE 0..*
PRT 0..* Deprecated
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..*
CTI 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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R23^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^R23^ACK
NE, AL, ER, SU (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..*
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
ORDER_DOCUMENT 0..1
OBX 1..1 Yes
PRT 0..*
TXA 1..1 Yes
NTE 0..*
PRT 0..* Deprecated
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..*
CTI 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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R24^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^R24^ACK
NE, AL, ER, SU (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..*
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
NTE 0..*
PRT 0..* Depracted
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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R25^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^R25^ACK
NE, AL, ER, SU (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..*
NEXT_OF_KIN 0..*
NK1 1..1 Yes
OH2 0..*
OH3 0..1
ARV 0..* B
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
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
ORDER_DOCUMENT 0..1
OBX 1..1 Yes
PRT 0..*
TXA 1..1 Yes
OBR 1..1 Yes
NTE 0..*
OBSERVATION_PARTICIPATION 0..*
PRT 1..1 Yes
DEV 0..*
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
CTD 0..1
OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
NTE 0..*
FT1 0..*
CTI 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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R40^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ORA^R41^ORA_R41
NE, AL, ER, SU (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 or AL or ER or SU, an immediate ack SHALL NOT be sent.

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

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

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R41^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack:
NE, AL, ER, SU (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..*
NEXT_OF_KIN 0..*
NK1 1..1 Yes
OH2 0..*
OH3 0..1
ARV 0..* B
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
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
ORDER_DOCUMENT 0..1
OBX 1..1 Yes
PRT 0..*
TXA 1..1 Yes
OBR 1..1 Yes
NTE 0..*
OBSERVATION_PARTICIPATION 0..*
PRT 1..1 Yes
DEV 0..*
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
CTD 0..1
OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
NTE 0..*
FT1 0..*
CTI 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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R42^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^R42^ACK
NE, AL, ER, SU (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..*
NEXT_OF_KIN 0..*
NK1 1..1 Yes
OH2 0..*
OH3 0..1
ARV 0..* B
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
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
ORDER_DOCUMENT 0..1
OBX 1..1 Yes
PRT 0..*
TXA 1..1 Yes
OBR 1..1 Yes
NTE 0..*
OBSERVATION_PARTICIPATION 0..*
PRT 1..1 Yes
DEV 0..*
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
CTD 0..1
OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
NTE 0..*
FT1 0..*
CTI 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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^R43^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^R43^ACK
NE, AL, ER, SU (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# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
OBR
1 Set ID – OBR SI O
[0..1] 00237 [1..4]
2 Placer Order Number EI C
[0..1] 00216
3 Filler Order Number EI C
[0..1] 00217
4 Universal Service Identifier CWE R
0612
[1..1] 00238
5 Priority W
[0..1] 00239
6 Requested Date/Time W
[0..1] 00240
7 Observation Date/Time # DTM C
[0..1] 00241
8 Observation End Date/Time # DTM O
[0..1] 00242
9 Collection Volume * CQ B
[0..1] 00243
10 Collector Identifier * XCN B
[0..*] 00244
11 Specimen Action Code * ID O
0065(R) Specimen Action Code(Required)
[0..1] 00245 [1..1]
12 Danger Code CWE O
0613
[0..1] 00246
13 Relevant Clinical Information CWE O
0916 Relevant Clincial Information
[0..*] 00247 300 #
14 Specimen Received Date/Time * DTM W
[0..1] 00248
15 Specimen Source W
[0..1] 00249
16 Ordering Provider W
[0..1] 00226
17 Order Callback Phone Number XTN O
[0..2] 00250
18 Placer Field 1 ST O
[0..1] 00251 199 #
19 Placer Field 2 ST O
[0..1] 00252 199 #
20 Filler Field 1 + ST O
[0..1] 00253 199 #
21 Filler Field 2 + ST O
[0..1] 00254 199 #
22 Results Rpt/Status Chng – Date/Time + DTM C
[0..1] 00255
23 Charge to Practice + MOC O
[0..1] 00256
24 Diagnostic Serv Sect ID ID O
0074(R) Diagnostic Service Section ID(Required)
[0..1] 00257 [2..3]
25 Result Status + ID C
0123(R) Result Status(Required)
[0..1] 00258 [1..1]
26 Parent Result + PRL O
[0..1] 00259
27 Quantity/Timing W
[0..0] 00221
28 Result Copies To W
[0..1] 00260
29 Parent Results Observation Identifier EIP O
[0..1] 00261
30 Transportation Mode ID O
0124(R) Transportation Mode(Required)
[0..1] 00262 [4..4]
31 Reason for Study CWE O
0951(S) Reason for Study(Suggested)
[0..*] 00263
32 Principal Result Interpreter + W
[0..1] 00264
33 Assistant Result Interpreter + W
[0..1] 00265
34 Technician + W
[0..1] 00266
35 Transcriptionist + W
[0..1] 00267
36 Scheduled Date/Time + DTM O
[0..1] 00268
37 Number of Sample Containers * NM O
[0..1] 01028 16 #
38 Transport Logistics of Collected Sample * CWE O
0614
[0..*] 01029
39 Collector's Comment * CWE O
0619
[0..*] 01030
40 Transport Arrangement Responsibility CWE O
0620
[0..1] 01031
41 Transport Arranged ID O
0224(R) Transport Arranged(Required)
[0..1] 01032 [1..1]
42 Escort Required ID O
0225(R) Escort Required(Required)
[0..1] 01033 [1..1]
43 Planned Patient Transport Comment CWE O
0621
[0..*] 01034
44 Procedure Code CNE O
[0..1] 00393
45 Procedure Code Modifier CNE O
[0..*] 01316
46 Placer Supplemental Service Information CWE O
0411 Supplemental Service Information Values
[0..*] 01474
47 Filler Supplemental Service Information CWE O
0411 Supplemental Service Information Values
[0..*] 01475
48 Medically Necessary Duplicate Procedure Reason CWE C
0476 Medically Necessary Duplicate Procedure Reason
[0..1] 01646
49 Result Handling CWE O
0507 Observation Result Handling
[0..1] 01647
50 Parent Universal Service Identifier W
[0..1] 02286
51 Observation Group ID EI O
[0..1] 02307
52 Parent Observation Group ID EI O
[0..1] 02308
53 Alternate Placer Order Number CX O
[0..*] 03303
54 Parent Order EIP O
0119(R) Order Control Codes(Required)
[0..*] 00222
55 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]

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

FIXME

OBR-2: Placer Order Number (EI) 00216

FIXME

OBR-3: Filler Order Number (EI) 00217

FIXME

OBR-4: Universal Service Identifier (CWE) 00238

FIXME

OBR-5: Priority () 00239

FIXME

OBR-6: Requested Date/Time () 00240

FIXME

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

FIXME

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

FIXME

OBR-9: Collection Volume * (CQ) 00243

FIXME

OBR-10: Collector Identifier * (XCN) 00244

FIXME

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

FIXME

OBR-12: Danger Code (CWE) 00246

FIXME

OBR-13: Relevant Clinical Information (CWE) 00247

FIXME

OBR-14: Specimen Received Date/Time * (DTM) 00248

FIXME

OBR-15: Specimen Source () 00249

FIXME

OBR-16: Ordering Provider () 00226

FIXME

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

FIXME

OBR-18: Placer Field 1 (ST) 00251

FIXME

OBR-19: Placer Field 2 (ST) 00252

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

OBR-25: Result Status + (ID) 00258

FIXME

OBR-26: Parent Result + (PRL) 00259

FIXME

OBR-27: Quantity/Timing () 00221

FIXME

OBR-28: Result Copies To () 00260

FIXME

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

FIXME

OBR-30: Transportation Mode (ID) 00262

FIXME

OBR-31: Reason for Study (CWE) 00263

FIXME

OBR-32: Principal Result Interpreter + () 00264

FIXME

OBR-33: Assistant Result Interpreter + () 00265

FIXME

OBR-34: Technician + () 00266

FIXME

OBR-35: Transcriptionist + () 00267

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

OBR-40: Transport Arrangement Responsibility (CWE) 01031

FIXME

OBR-41: Transport Arranged (ID) 01032

FIXME

OBR-42: Escort Required (ID) 01033

FIXME

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

FIXME

OBR-44: Procedure Code (CNE) 00393

FIXME

OBR-45: Procedure Code Modifier (CNE) 01316

FIXME

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

FIXME

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

FIXME

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

FIXME

OBR-49: Result Handling (CWE) 01647

FIXME

OBR-50: Parent Universal Service Identifier () 02286

FIXME

OBR-51: Observation Group ID (EI) 02307

FIXME

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

FIXME

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

FIXME

OBR-54: Parent Order (EIP) 00222

FIXME

OBR-55: Action Code (ID) 00816

FIXME

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# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
OBX
1 Set ID – OBX SI O
[0..1] 00569 [1..4]
2 Value Type ID C
0125(R) Value Type(Required)
[0..1] 00570 [2..3]
3 Observation Identifier CWE R
0622
[1..1] 00571
4 Observation Sub-ID OG C
[0..1] 00572 20 #
5 Observation Value Varies C
[0..*] 00573
6 Units CWE O
0623
[0..1] 00574
7 Reference Range ST O
[0..1] 00575 60 #
8 Interpretation Codes CWE O
0078(R) Interpretation Codes(Required)
[0..*] 00576
9 Probability NM O
[0..1] 00577 5 #
10 Nature of Abnormal Test ID O
0080(R) Nature of Abnormal Testing(Required)
[0..*] 00578 [1..2]
11 Observation Result Status ID R
0085(R) Observation Result Status Codes Interpretation(Required)
[1..1] 00579 [1..1]
12 Effective Date of Reference Range DTM O
[0..1] 00580
13 User Defined Access Checks ST O
[0..1] 00581 20 #
14 Date/Time of the Observation DTM O
[0..1] 00582
15 Producer's ID CWE B
0624
[0..1] 00583
16 Responsible Observer XCN B
[0..*] 00584
17 Observation Method CWE O
0626
[0..*] 00936
18 Equipment Instance Identifier EI B
[0..*] 01479
19 Date/Time of the Analysis DTM O
[0..1] 01480
20 Observation Site CWE O
0163(R) Body Site(Required)
[0..*] 02179
21 Observation Instance Identifier EI O
[0..1] 02180
22 Mood Code CNE C
0725(R) Mood Codes(Required)
[0..1] 02182
23 Performing Organization Name XON B
[0..1] 02283
24 Performing Organization Address XAD B
[0..1] 02284
25 Performing Organization Medical Director XCN B
[0..1] 02285
26 Patient Results Release Category ID O
0909(R) Patient Results Release Categorization Scheme(Required)
[0..1] 02313 [1..10]
27 Root Cause CWE O
0914 Root Cause
[0..1] 03308
28 Local Process Control CWE O
0915 Process Control Code
[0..*] 03309
29 Observation Type ID O
0936(R) Observation Type(Required)
[0..1] 03432
30 Observation Sub-Type ID O
0937(R) Observation Sub-Type(Required)
[0..1] 03475
31 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]
32 Observation Value Absent Reason CWE C
0960(S) Data Absent Reason(Suggested)
[0..*] 03510
33 Observation Related Specimen Identifier EIP O
[0..*] 02454

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

FIXME

OBX-2: Value Type (ID) 00570

FIXME

OBX-3: Observation Identifier (CWE) 00571

FIXME

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

FIXME

OBX-5: Observation Value (Varies) 00573

FIXME

OBX-6: Units (CWE) 00574

FIXME

OBX-7: Reference Range (ST) 00575

FIXME

OBX-8: Interpretation Codes (CWE) 00576

FIXME

OBX-9: Probability (NM) 00577

FIXME

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

FIXME

OBX-11: Observation Result Status (ID) 00579

FIXME

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

FIXME

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

FIXME

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

FIXME

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

FIXME

OBX-16: Responsible Observer (XCN) 00584

FIXME

OBX-17: Observation Method (CWE) 00936

FIXME

OBX-18: Equipment Instance Identifier (EI) 01479

FIXME

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

FIXME

OBX-20: Observation Site (CWE) 02179

FIXME

OBX-21: Observation Instance Identifier (EI) 02180

FIXME

OBX-22: Mood Code (CNE) 02182

FIXME

OBX-23: Performing Organization Name (XON) 02283

FIXME

OBX-24: Performing Organization Address (XAD) 02284

FIXME

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

FIXME

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

FIXME

OBX-27: Root Cause (CWE) 03308

FIXME

OBX-28: Local Process Control (CWE) 03309

FIXME

OBX-29: Observation Type (ID) 03432

FIXME

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

FIXME

OBX-31: Action Code (ID) 00816

FIXME

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

FIXME

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

FIXME

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# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
SPM
1 Set ID - SPM SI O
[0..1] 01754 [1..4]
2 Specimen Identifier EIP O
[0..1] 01755
3 Specimen Parent IDs EIP O
[0..*] 01756
4 Specimen Type CWE R
0487(R) Specimen Type(Required)
[1..1] 01900
5 Specimen Type Modifier CWE O
0541 Specimen Type Modifier
[0..*] 01757
6 Specimen Additives CWE O
0371(R) Additive/Preservative(Required)
[0..*] 01758
7 Specimen Collection Method CWE O
0488(R) Specimen Collection Method(Required)
[0..1] 01759
8 Specimen Source Site CWE O
0784
[0..1] 01901
9 Specimen Source Site Modifier CWE O
0542 Specimen Source Type Modifier
[0..*] 01760
10 Specimen Collection Site CWE O
0543 Specimen Collection Site
[0..1] 01761
11 Specimen Role CWE O
0369(S) Specimen Role(Suggested)
[0..*] 01762
12 Specimen Collection Amount CQ O
[0..1] 01902
13 Grouped Specimen Count NM C
[0..1] 01763 6 #
14 Specimen Description ST O
[0..*] 01764
15 Specimen Handling Code CWE O
0376(S) Special Handling Code(Suggested)
[0..*] 01908
16 Specimen Risk Code CWE O
0489 Risk Codes
[0..*] 01903
17 Specimen Collection Date/Time DR O
[0..1] 01765
18 Specimen Received Date/Time * DTM O
[0..1] 00248
19 Specimen Expiration Date/Time DTM O
[0..1] 01904
20 Specimen Availability ID O
0136(R) Yes/no Indicator(Required)
[0..1] 01766 [1..1]
21 Specimen Reject Reason CWE O
0490(R) Specimen Reject Reason(Required)
[0..*] 01767
22 Specimen Quality CWE O
0491 Specimen Quality
[0..1] 01768
23 Specimen Appropriateness CWE O
0492 Specimen Appropriateness
[0..1] 01769
24 Specimen Condition CWE O
0493 Specimen Condition
[0..*] 01770
25 Specimen Current Quantity CQ O
[0..1] 01771
26 Number of Specimen Containers NM O
[0..1] 01772 4 #
27 Container Type CWE O
0785
[0..1] 01773
28 Container Condition CWE O
0544(S) Container Condition(Suggested)
[0..1] 01774
29 Specimen Child Role CWE O
0494(R) Specimen Child Role(Required)
[0..1] 01775
30 Accession ID CX O
[0..*] 02314
31 Other Specimen ID CX O
[0..*] 02315
32 Shipment ID EI O
[0..1] 02316
33 Culture Start Date/Time DTM O
[0..1] 03485
34 Culture Final Date/Time DTM O
[0..1] 03486
35 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]

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

FIXME

SPM-2: Specimen Identifier (EIP) 01755

FIXME

SPM-3: Specimen Parent IDs (EIP) 01756

FIXME

SPM-4: Specimen Type (CWE) 01900

FIXME

SPM-5: Specimen Type Modifier (CWE) 01757

FIXME

SPM-6: Specimen Additives (CWE) 01758

FIXME

SPM-7: Specimen Collection Method (CWE) 01759

FIXME

SPM-8: Specimen Source Site (CWE) 01901

FIXME

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

FIXME

SPM-10: Specimen Collection Site (CWE) 01761

FIXME

SPM-11: Specimen Role (CWE) 01762

FIXME

SPM-12: Specimen Collection Amount (CQ) 01902

FIXME

SPM-13: Grouped Specimen Count (NM) 01763

FIXME

SPM-14: Specimen Description (ST) 01764

FIXME

SPM-15: Specimen Handling Code (CWE) 01908

FIXME

SPM-16: Specimen Risk Code (CWE) 01903

FIXME

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

FIXME

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

FIXME

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

FIXME

SPM-20: Specimen Availability (ID) 01766

FIXME

SPM-21: Specimen Reject Reason (CWE) 01767

FIXME

SPM-22: Specimen Quality (CWE) 01768

FIXME

SPM-23: Specimen Appropriateness (CWE) 01769

FIXME

SPM-24: Specimen Condition (CWE) 01770

FIXME

SPM-25: Specimen Current Quantity (CQ) 01771

FIXME

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

FIXME

SPM-27: Container Type (CWE) 01773

FIXME

SPM-28: Container Condition (CWE) 01774

FIXME

SPM-29: Specimen Child Role (CWE) 01775

FIXME

SPM-30: Accession ID (CX) 02314

FIXME

SPM-31: Other Specimen ID (CX) 02315

FIXME

SPM-32: Shipment ID (EI) 02316

FIXME

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

FIXME

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

FIXME

SPM-35: Action Code (ID) 00816

FIXME

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# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
PRT
1 Participation Instance ID EI C
[0..1] 02379 [1..4]
2 Action Code ID R
0206(R) Segment Action Code(Required)
[1..1] 00816 [2..2]
3 Action Reason CWE O
[0..1] 02380
4 Role of Participation CWE R
0912(R) Participation(Required)
[1..1] 02381
5 Person XCN C
[0..*] 02382
6 Person Provider Type CWE C
[0..1] 02383
7 Organization Unit Type CWE C
0406 Participant Organization Unit Type
[0..1] 02384
8 Organization XON C
[0..*] 02385
9 Location PL C
[0..*] 02386
10 Device EI C
[0..*] 02348
11 Begin Date/Time DTM O
[0..1] 02387
12 End Date/Time DTM O
[0..1] 02388
13 Qualitative Duration CWE O
[0..1] 02389
14 Address XAD C
[0..*] 02390
15 Telecommunication Address XTN O
[0..*] 02391
16 UDI Device Identifier EI O
[0..1] 03476
17 Device Manufacture Date DTM O
[0..1] 03477
18 Device Expiry Date DTM O
[0..1] 03478
19 Device Lot Number ST O
[0..1] 03479
20 Device Serial Number ST O
[0..1] 03480
21 Device Donation Identification EI O
[0..1] 03481
22 Device Type CNE C
0961 Device Type
[0..1] 03483
23 Preferred Method of Contact CWE O
0185(R) Preferred Method of Contact(Required)
[0..1] 00684
24 Contact Identifiers PLN O
0328 Employee Classification
[0..*] 01171

PRT-1: Participation Instance ID (EI) 02379

FIXME

PRT-2: Action Code (ID) 00816

FIXME

PRT-3: Action Reason (CWE) 02380

FIXME

PRT-4: Role of Participation (CWE) 02381

FIXME

PRT-5: Person (XCN) 02382

FIXME

PRT-6: Person Provider Type (CWE) 02383

FIXME

PRT-7: Organization Unit Type (CWE) 02384

FIXME

PRT-8: Organization (XON) 02385

FIXME

PRT-9: Location (PL) 02386

FIXME

PRT-10: Device (EI) 02348

FIXME

PRT-11: Begin Date/Time (DTM) 02387

FIXME

PRT-12: End Date/Time (DTM) 02388

FIXME

PRT-13: Qualitative Duration (CWE) 02389

FIXME

PRT-14: Address (XAD) 02390

FIXME

PRT-15: Telecommunication Address (XTN) 02391

FIXME

PRT-16: UDI Device Identifier (EI) 03476

FIXME

PRT-17: Device Manufacture Date (DTM) 03477

FIXME

PRT-18: Device Expiry Date (DTM) 03478

FIXME

PRT-19: Device Lot Number (ST) 03479

FIXME

PRT-20: Device Serial Number (ST) 03480

FIXME

PRT-21: Device Donation Identification (EI) 03481

FIXME

PRT-22: Device Type (CNE) 03483

FIXME

PRT-23: Preferred Method of Contact (CWE) 00684

FIXME

PRT-24: Contact Identifiers (PLN) 01171

FIXME

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

PID|...

OBR|1|X89-1501^OE|78912^RD|71020^CHEST XRAY AP \T\ LATERAL|||198703290800||||...

OBX|1|CWE|19005-8^X-ray impression^LN|4|^MASS LEFT LOWER LOBE|||A|||F|...

OBX|2|CWE|19005-8^X-ray impression^LN|2|^INFILTRATE RIGHT LOWER LOBE|||A|||F|...

OBX|3|CWE|19005-8^X-ray impression^LN|3|^HEART SIZE NORMAL|||N|||F|...

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

OBX|5|CWE|71020&REC|5|71020^Follow up CXR 1 month||30-45||||F|...

Laboratory

Laboratory message: electrolytes, CBC, sed rate, blood cultures and susceptibilities

MSH|...

PID|...

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

OBX|1|NM|2951-2^SODIUM^LN||150|mmol/L|136-148|H||A|F|19850301|...

OBX|2|NM|2823-3^POTASSIUM^LN||4.5|mmol/L|3.5-5|N||N|F|19850301|...

OBX|3|NM|2075-0^CHLORIDE^LN||102|mmol/L|94-105|N||N|F|19850301|...

OBX|4|NM|2028-9^CARBON DIOXIDE^LN||27|mmol/L|24-31|N||N|F|19850301|...

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

OBX|1|NM|718-7^HEMOGLOBIN^LN||13.4|GM/DL|14-18|N||S|F|19860522|...

OBX|2|NM|4544-3^HEMATOCRIT^LN||40.3|%|42-52|L||S|F|19860522|...

OBX|3|NM|789-8^ERYTHROCYTES^LN||4.56|10*6/ml|4.7-6.1|L||S|F|19860522|...

OBX|4|NM|787-2^ERYTHROCYTE MEAN CORPUSCULAR VOLUME:^LN

||88|fl|80-94|N||S|F|19860522|...

OBX|5|NM|785-6^ERYTHROCYTE MEAN CORPUSCULAR HEMOGLOBIN:^LN

||29.5|pg|27-31|N||N|F|19860522|...

OBX|6|NM|786-4^ERYTHROCYTE MEAN CORPUSCULAR HEMOGLOBIN CONCENTRATION:^LN

||33|%|33-37|N||N|F|19860522|...

OBX|7|NM|6690-2^LEUKOCYTES^LN||10.7|10*3/ml|4.8-10.8|N||N|F|19860522|...

OBX|8|NM|770-8^NEUTROPHILS/100 LEUKOCYTES^LN||68|%|||||F|...

OBX|9|NM|736-9^LYMPHOCYTES/100 LEUKOCYTES:^LN||29|%|||||F|...

OBX|10|NM|5905-5^MONOCYTES/100 LEUKOCYTES:^LN||1|%|||||F|...

OBX|11|NM|713-8^EOSINOPHILS/100 LEUKOCYTES:^LN||2|%|||||F|...

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

OBX|1|NM|4537-7^ERYTHROCYTE SEDIMENTATION RATE:^LN|

|7|MM/HR|0-10|N||S|F|19860522|...

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

OBX|1|CWE|600-7^MICROORGANISM IDENTIFIED^LN|1|^E Coli|||A|||F|...

OBX|2|CWE|600-7^MICROORGANISM IDENTIFIED^LN|2|^S Aureus|||A|||F|...

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

OBX|1|ST|28-1^AMIPICILLIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...

OBX|2|ST|60-4^CARBENICILLIN:SUSC:PT:ISLT:QN:MIC^LN||<16|ug/ml||S|||F|...

OBX|3|ST|267-5^GENTAMICIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...

OBX|4|ST|496-0^TETRACYCLINE:SUSC:PT:ISLT:QN:MIC^LN||<1|ug/ml||S|||F|...

OBX|5|ST|408-5^PIPERACILLIN:SUSC:PT:ISLT:QN:MIC^LN||<8|ug/ml||S|||F|...

OBX|6|ST|145-3^CEFUROXIME:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...

OBX|7|ST|161-0^CEPHALOTHIN:SUSC:PT:ISLT:QN:MIC^LN||<8|ug/ml||S|||F|...

OBX|8|ST|20-8^AMOXICILLIN+CLAVULANATE:SUSC:PT:ISLT:QN:MIC^LN

||<4|ug/ml||S|||F|...

OBX|9|ST|173-5^CHLORAMPHENICOL:SUSC:PT:ISLT:QN:MIC^LN||<4|ug/ml||S|||F|...

OBX|10|ST|508-2^TOBRAMYCIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...

OBX|11|ST|12-5^AMIKACIN:SUSC:PT:ISLT:QN:MIC^LN||<4|ug/ml||S|||F|...

OBX|12|ST|516-5^TRIMETHOPRIM+SULFMOETHOXAZOLE:SUSC:PT:ISLT:QN:MIC^LN|

|<2/38|ug/ml||S|||F|...

OBX|13|ST|76-0^CEFAZOLIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...

OBX|14|ST|116-4^CEFOXITIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...

OBX|15|ST|141-2^CEFTRIAXONE:SUSC:PT:ISLT:QN:MIC^LN||<4|ug/ml||S|||F|...

OBX|16|ST|133-9^CEFTAZIDIME:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...

OBX|17|ST|185-9^CIPROFLOXACIN:SUSC:PT:ISLT:QN:MIC^LN||<1|ug/ml||S|||F|...

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

OBX|1|ST|28-1^AMPICILLIN:SUSC:PT:ISLT:QN:MIC^LN||<8|ug/ml||R|||F|...

OBX|2|ST|193-3^CLINDAMYCIN:SUSC:PT:ISLT:QN:MIC^LN||<.25|ug/ml||S|||F|...

OBX|3|ST|267-5^GENTAMICIN:SUSC:PT:ISLT:QN:MIC^LN||<1|ug/ml||S|||F|...

OBX|4|ST|233-7^ERYTHROMYCIN:SUSC:PT:ISLT:QN:MIC^LN||<.5|ug/ml||S|||F|...

OBX|5|ST|383-0^OXACILLIN:SUSC:PT:ISLT:QN:MIC^LN||<.5|ug/ml||S|||F|...

OBX|6|ST|524-9^VANCOMYCIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...

OBX|7|ST|6932-8^PENICILLIN:SUSC:PT:ISLT:QN:MIC^LN||<8|ug/ml||R|||F|...

OBX|8|ST|161-0^CEPHALOTHIN:SUSC:PT:ISLT:QN:MIC^LN||<2|ug/ml||S|||F|...

OBX|9|ST|173-5^CHLORAMPHENICOL:SUSC:PT:ISLT:QN:MIC^LN||<4|ug/ml||S|||F|...

OBX|10|ST|12-5^AMIKACIN:SUSC:PT:ISLT:QN:MIC^LN||<16|ug/ml||S|||F|...

OBX|11|ST|185-9^CIPROFLOXACIN:SUSC:PT:ISLT:QN:MIC^LN||<1|ug/ml||S|||F|...

OBX|12|ST|428-3^RIFAMPIN:SUSC:PT:ISLT:QN:MIC^LN||<1|ug/ml||S|||F|...

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

PID|...

Order record for CXR

OBR|2|P8754^OE|XR1501^XR|24646-2^CXR PA+LAT^LN|||198703290800|||

401-0^INTERN^IRVING^I^^^MD^L|...

Two CXR diagnostic impressions

OBX|1|CWE|24646-2&IMP^CXR PA+LAT^LN

|1|.61^RUL^ACR~.212^Bronchopneumonia^ACR|||A|||F|...

OBX|2|CWE|24646-2&IMP^CXR PA+LAT^LN |2|51.71^Congestive heart failure^ACR|||A|||F|...

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

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

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

OBX|1|CWE|11529-5&ANT^Surgical Path Report^LN|1|Y0480-912001^orbital region^SNM||||||F|...

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

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

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

OBX|1|NM|8462-4^INTRAVASCULAR DIASTOLIC:PRES^LN||90|mm(hg)|60-90||||F|...

OBX|2|NM|8479-8^INTRAVASCULAR SYSTOLIC:PRES^LN||120|mm(hg)

|100-160||||F|...

OBX|3|NM|8478-0^INTRAVASCULAR MEAN:PRES^LN||100|mm(hg)|80-120|N|||F|...

OBX|4|NM|8867-4^HEART BEAT RATE^LN||74|/min|60-100|N|||F|...

OBX|5|ST|8357-6^BLOOD PRESSURE METHOD^LN||MANUAL BY CUFF||||||F|...

OBX|6|ST|8886-4^HEART RATE METHOD^LN||MANUAL BY PALP||||||F|...

Part of the patient's history

OBR|5|P8568^OE|HX2230^^CLN||2000^HISTORY| ||198703290800||401

0^INTERN^IRVING^I^^^MD^L||...

OBX|1|CWE|8661-1^CHIEF COMPLAINT^LN||...

OBX|2|ST|8674-4^HISTORY SOURCE^LN||PATIENT||||||F|...

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

    .

    .

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

OBX|2|CWE|600-7^Micro Organism Identified^LN |2|^S. Aureus||||||F|...

Not recommended:

OBX|1|CWE|600-7^Micro Organism Identified^LN |1|^E. Coli||||||F|...

OBX|2|CWE|600-7^Micro Organism Identified^LN |1|^S. Aureus||||||F|...

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

PID|...

PV1|...

ORC|NW|...

OBR|1|A485388^OE|H29847^LAB1|17928-3^BLOOD CULTURE^LN|||...

Result for culture

ORC|RE|...

OBR|1|A485388^OE|H29847^LAB1|17928-3^BLOOD CULTURE ^LN||...

OBX|1|FT|SDES^SOURCE||BLOOD-RAPID||||||F|...

OBX|2|FT|664-3^GRAM STAIN SMEAR^LN||GRAM POSITIVE COCCI IN GROUPS||||||F|...

OBX|3|FT|600-7^MICROORGANISM IDENTIFIED^LN|1|ISOLATE 1||||||F|...

Result for susceptibility

ORC|RE|...

OBR|1|A485388^OE|H29848^LAB1|BT1^SUSCEPTIBILITY BATTERY||||||123^MANSFIELD^CHARLES| ||||||||||||||||600-7&MICROORGANISM IDENTIFIED&LN ^1|||A485388&OE^H29847&LAB1|...

OBX|1|NM|6932-8^PENICILLIN MIC^LN||0.5|||R|||F|...

OBX|2|NM|347-5^NAFCILLIN MIC^LN||1|||R|||F|...

OBX|3|ST|193-3^CLINDAMYCIN MIC^LN||<=0.1|||S|||F|...

Result for Culture ID

ORC|RE|...

OBR|1|A485388^OE|H29847^LAB1|17928-3^BLOOD CULTURE ^LN||...

OBX|1|FT|600-7^ MICROORGANISM IDENTIFIED^LN |1|STAPH EPI||||||F|...

New result for culture ID

ORC|RE|...

OBR|1|A485388^OE|H29847^LAB1|17928-3^BLOOD CULTURE ^LN||...

OBX|1|FT|600-7^MICROORGANISM IDENTIFIED^LN|1|STAPH EPI SERO TYPE 3||||||F|...

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

PID|...

Order record for EKG

OBR|1|P8753^OE|EK5230^EKG|8601-7^EKG impression^LN|||198703290800|||401

0^INTERN^IRVING^I^^^MD^L|...

Two interpretation records for EKG

OBX|1|CWE|8601-7^EKG impression^LN|1|^Sinus bradycardia|||A|||F|...

OBX|2|CWE|8601-7^EKG impression^LN |2|^Occasional PVCs|||A|||F|...

Four numeric results for EKG

OBX|3|NM|8897-1^QRS COMPLEX RATE ^LN|

|80|/min|60-100|||||F|...

OBX|4|NM|8894-8^PULSE RATE^LN||80|/min

|60-100||||F|...

OBX|5|NM|8633-0^QRS DURATION ^LN||.08|msec

|.06-.10||||F|...

OBX|6|NM|8625-6^P-R INTERVAL ^LN||.22|msec

|.18-.22||||F|...

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

PID|...

ORC|PA|A226677^OE|89-450^EKG|... // original order's ORC.

OBR|1|||8601-7^EKG REPORT|... // original order segment

ORC|CH|A226677^OE|89-451^EKG|... // 1st child ORC.

OBR|1|||8601-7^EKG REPORT|... // 1st EKG child OBR.

OBX|1|ST|... // 1st EKG report

OBX|2|ST|...

    ...

OBX|14|FT|...

ORC|CH|A226677^OE|89-452^EKG|... // 2nd child ORC.

OBR|1|||8601-7^EKG REPORT|... // 2nd EKG child OBR.

OBX|1|ST|... // 2nd EKG report

OBX|2|ST|...

    ...

OBX|14|FT|...

ORC|CH|A226677^OE|89-453^EKG|... // 3rd child ORC.

OBR|1|||8601-7^EKG REPORT|... // 3rd EKG child OBR.

OBX|1|ST|... // 3rd EKG report

OBX|2|ST|...

    ...

OBX|14|FT|...

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

PID|...

ORC|NW|... // New order.

OBR|1|P42^PC||2164-2^CREATININE RENAL CLEARANCE: QN^LN|...

OBX|1|NM|3141-9^BODY WEIGHT^LN||62|kg|...

OBX|2|NM|3137-7^BODY HEIGHT^LN||190|cm|...

ORC|NW|... // 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
PATIENT_VISIT 0..1
PV1 1..1 Yes
PRT 0..*
CSR 1..1 Yes
CSP 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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^C01^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^C01^ACK
NE, AL, ER, SU (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
PATIENT_VISIT 0..1
PV1 1..1 Yes
PRT 0..*
CSR 1..1 Yes
CSP 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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^C02^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^C02^ACK
NE, AL, ER, SU (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
PATIENT_VISIT 0..1
PV1 1..1 Yes
PRT 0..*
CSR 1..1 Yes
CSP 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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^C03^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^C03^ACK
NE, AL, ER, SU (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
PATIENT_VISIT 0..1
PV1 1..1 Yes
PRT 0..*
CSR 1..1 Yes
CSP 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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^C04^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^C04^ACK
NE, AL, ER, SU (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
PATIENT_VISIT 0..1
PV1 1..1 Yes
PRT 0..*
CSR 1..1 Yes
CSP 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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^C05^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^C05^ACK
NE, AL, ER, SU (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
PATIENT_VISIT 0..1
PV1 1..1 Yes
PRT 0..*
CSR 1..1 Yes
CSP 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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

Field Value Send Response
MSH-15 AL, ER, SU immediate ack: ACK^C06^ACK
NE, AL, ER, SU (none)
MSH-16 AL, ER, SU application ack: ACK^C06^ACK
NE, AL, ER, SU (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
PATIENT_VISIT 0..1
PV1 1..1 Yes
PRT 0..*
CSR 1..1 Yes
CSP 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 or AL or ER or SU, 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 or AL or ER or SU, an application ack SHALL NOT be sent.

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

CRM^C08^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
PATIENT_VISIT 0..1
PV1 1..1 Yes
PRT 0..*
CSR 1..1 Yes
CSP 0..*

Original Mode Acknowledgement Choreography for CRM^C08^CRM_C01

Send Application Ack: ACK^C08^ACK

Enhanced Mode Acknowledgement Choreography for CRM^C08^CRM_C01

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

When the MSH-15 value of a CRM^C08^CRM_C01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a CRM^C08^CRM_C01 message is AL or ER or SU, an ACK^C08^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a CRM^C08^CRM_C01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

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

CSU - Unsolicited Study Data Message (Events C09-C12)

Data are entered in the clinical trials system or may reside in laboratory, pathology, radiology, pharmacy and/or other clinical applications. Most clinical trials data - clinical observations and study variables - will be communicated in OBR and OBX segments. The CSR, CSP, and CSS segments will identify the specific association these OBR and OBX have to the clinical trial. Data can be broadcast or transmitted in batch mode to study sponsors or the data management center for collaborative studies.

The general acknowledgement message as defined in Chapter 2 should be used for any acknowledgements.

Event

Description

C09

Automated time intervals for reporting, like monthly

C10

Patient completes the clinical trial

C11

Patient completes a phase of the clinical trial

C12

Update/correction of patient order/result information


CSU^C09^CSU_C09: Clinical Trial Message
HL7 MessageStructure Table - CSU_C09
Segment Cardinality Must Implement Status
CSU_C09
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PATIENT 1..* Yes
PID 1..1 Yes
PD1 0..1
PRT 0..*
ARV 0..* B
NTE 0..*
VISIT 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
CSR 1..1 Yes
STUDY_PHASE 1..* Yes
CSP 0..1
STUDY_SCHEDULE 1..* Yes
CSS 0..1
STUDY_OBSERVATION 1..* Yes
0..1
ORC 1..1 Yes
PRT 0..*
OBR 1..1 Yes
PRT 0..*
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
OBX 1..1 Yes
PRT 0..*
STUDY_PHARM 1..* Yes
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
RX_ADMIN 1..* Yes
RXA 1..1 Yes
RXR 1..1 Yes
PRT 0..*

Original Mode Acknowledgement Choreography for CSU^C09^CSU_C09

Send Application Ack: ACK^C09^ACK

Enhanced Mode Acknowledgement Choreography for CSU^C09^CSU_C09

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

When the MSH-15 value of a CSU^C09^CSU_C09 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a CSU^C09^CSU_C09 message is AL or ER or SU, an ACK^C09^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a CSU^C09^CSU_C09 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

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

CSU^C10^CSU_C09: Clinical Trial Message
HL7 MessageStructure Table - CSU_C09
Segment Cardinality Must Implement Status
CSU_C09
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PATIENT 1..* Yes
PID 1..1 Yes
PD1 0..1
PRT 0..*
ARV 0..* B
NTE 0..*
VISIT 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
CSR 1..1 Yes
STUDY_PHASE 1..* Yes
CSP 0..1
STUDY_SCHEDULE 1..* Yes
CSS 0..1
STUDY_OBSERVATION 1..* Yes
0..1
ORC 1..1 Yes
PRT 0..*
OBR 1..1 Yes
PRT 0..*
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
OBX 1..1 Yes
PRT 0..*
STUDY_PHARM 1..* Yes
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
RX_ADMIN 1..* Yes
RXA 1..1 Yes
RXR 1..1 Yes
PRT 0..*

Original Mode Acknowledgement Choreography for CSU^C10^CSU_C09

Send Application Ack: ACK^C10^ACK

Enhanced Mode Acknowledgement Choreography for CSU^C10^CSU_C09

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

When the MSH-15 value of a CSU^C10^CSU_C09 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a CSU^C10^CSU_C09 message is AL or ER or SU, an ACK^C10^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a CSU^C10^CSU_C09 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

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

CSU^C11^CSU_C09: Clinical Trial Message
HL7 MessageStructure Table - CSU_C09
Segment Cardinality Must Implement Status
CSU_C09
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PATIENT 1..* Yes
PID 1..1 Yes
PD1 0..1
PRT 0..*
ARV 0..* B
NTE 0..*
VISIT 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
CSR 1..1 Yes
STUDY_PHASE 1..* Yes
CSP 0..1
STUDY_SCHEDULE 1..* Yes
CSS 0..1
STUDY_OBSERVATION 1..* Yes
0..1
ORC 1..1 Yes
PRT 0..*
OBR 1..1 Yes
PRT 0..*
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
OBX 1..1 Yes
PRT 0..*
STUDY_PHARM 1..* Yes
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
RX_ADMIN 1..* Yes
RXA 1..1 Yes
RXR 1..1 Yes
PRT 0..*

Original Mode Acknowledgement Choreography for CSU^C11^CSU_C09

Send Application Ack: ACK^C11^ACK

Enhanced Mode Acknowledgement Choreography for CSU^C11^CSU_C09

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

When the MSH-15 value of a CSU^C11^CSU_C09 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a CSU^C11^CSU_C09 message is AL or ER or SU, an ACK^C11^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a CSU^C11^CSU_C09 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

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

CSU^C12^CSU_C09: Clinical Trial Message
HL7 MessageStructure Table - CSU_C09
Segment Cardinality Must Implement Status
CSU_C09
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
PATIENT 1..* Yes
PID 1..1 Yes
PD1 0..1
PRT 0..*
ARV 0..* B
NTE 0..*
VISIT 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
CSR 1..1 Yes
STUDY_PHASE 1..* Yes
CSP 0..1
STUDY_SCHEDULE 1..* Yes
CSS 0..1
STUDY_OBSERVATION 1..* Yes
0..1
ORC 1..1 Yes
PRT 0..*
OBR 1..1 Yes
PRT 0..*
TIMING_QTY 0..*
TQ1 1..1 Yes
TQ2 0..*
OBX 1..1 Yes
PRT 0..*
STUDY_PHARM 1..* Yes
COMMON_ORDER 0..1
ORC 1..1 Yes
PRT 0..*
RX_ADMIN 1..* Yes
RXA 1..1 Yes
RXR 1..1 Yes
PRT 0..*

Original Mode Acknowledgement Choreography for CSU^C12^CSU_C09

Send Application Ack: ACK^C12^ACK

Enhanced Mode Acknowledgement Choreography for CSU^C12^CSU_C09

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

When the MSH-15 value of a CSU^C12^CSU_C09 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a CSU^C12^CSU_C09 message is AL or ER or SU, an ACK^C12^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a CSU^C12^CSU_C09 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

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

Clinical Trials – Segment Definitions

CSR - Clinical Study Registration Segment

The CSR segment will contain fundamental administrative and regulatory information required to document a patient's enrollment on a clinical trial. This segment is all that is required if one needs to message another system that an enrollment has taken place, i.e., from clinical trials to pharmacy, accounting, or order entry systems. The CSR segment may also be used to identify that OBR, OBX, RXA, and RXR segments that follow represent data applicable to the identified study.

HL7 Attribute Table - CSR - Clinical Study Registration Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
CSR
1 Sponsor Study ID EI R
[1..1] 01011
2 Alternate Study ID EI O
[0..1] 01036
3 Institution Registering the Patient CWE O
0589
[0..1] 01037
4 Sponsor Patient ID CX R
[1..1] 01038
5 Alternate Patient ID - CSR CX O
[0..1] 01039
6 Date/Time of Patient Study Registration DTM R
[1..1] 01040
7 Person Performing Study Registration XCN O
[0..*] 01041
8 Study Authorizing Provider XCN R
[1..*] 01042
9 Date/Time Patient Study Consent Signed DTM C
[0..1] 01043
10 Patient Study Eligibility Status CWE C
0590
[0..1] 01044
11 Study Randomization Date/time DTM O
[0..3] 01045
12 Randomized Study Arm CWE O
0591
[0..3] 01046
13 Stratum for Study Randomization CWE O
0592
[0..3] 01047
14 Patient Evaluability Status CWE C
0593
[0..1] 01048
15 Date/Time Ended Study DTM C
[0..1] 01049
16 Reason Ended Study CWE C
0594
[0..1] 01050
17 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]

CSR-1: Sponsor Study ID (EI) 01011

FIXME

CSR-2: Alternate Study ID (EI) 01036

FIXME

CSR-3: Institution Registering the Patient (CWE) 01037

FIXME

CSR-4: Sponsor Patient ID (CX) 01038

FIXME

CSR-5: Alternate Patient ID - CSR (CX) 01039

FIXME

CSR-6: Date/Time of Patient Study Registration (DTM) 01040

FIXME

CSR-7: Person Performing Study Registration (XCN) 01041

FIXME

CSR-8: Study Authorizing Provider (XCN) 01042

FIXME

CSR-9: Date/Time Patient Study Consent Signed (DTM) 01043

FIXME

CSR-10: Patient Study Eligibility Status (CWE) 01044

FIXME

CSR-11: Study Randomization Date/time (DTM) 01045

FIXME

CSR-12: Randomized Study Arm (CWE) 01046

FIXME

CSR-13: Stratum for Study Randomization (CWE) 01047

FIXME

CSR-14: Patient Evaluability Status (CWE) 01048

FIXME

CSR-15: Date/Time Ended Study (DTM) 01049

FIXME

CSR-16: Reason Ended Study (CWE) 01050

FIXME

CSR-17: Action Code (ID) 00816

FIXME

CSP - Clinical Study Phase Segment

The CSP segment contains information on a patient's status for a particular phase of the study. This segment is optional and is useful when a study has different evaluation intervals within it. (See section 7.8.1, "HL7 Attribute Table – CSR – Clinical Study Registration," and section 7.6.1.2, "Phase of a clinical trial:.") The CSP segment is implemented on a study-specific basis for messaging purposes. The fact that the patient has entered a phase of the study that represents a certain treatment approach may need to be messaged to other systems, like pharmacy, nursing, or order entry. It is also important to sponsors and data management centers for tracking patient progress through the study and monitoring the data schedule defined for each phase. It may subsume OBR and OBX segments that follow it to indicate that these data describe the phase.

HL7 Attribute Table - CSP - Clinical Study Phase Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
CSP
1 Study Phase Identifier CWE R
0587
[1..1] 01022
2 Date/time Study Phase Began DTM R
[1..1] 01052
3 Date/time Study Phase Ended DTM O
[0..1] 01053
4 Study Phase Evaluability CWE C
0588
[0..1] 01054

CSP-1: Study Phase Identifier (CWE) 01022

FIXME

CSP-2: Date/time Study Phase Began (DTM) 01052

FIXME

CSP-3: Date/time Study Phase Ended (DTM) 01053

FIXME

CSP-4: Study Phase Evaluability (CWE) 01054

FIXME

CSS - Clinical Study Data Schedule Segment

The Clinical Study Data Schedule (CSS) segment is optional depending on whether messaging of study data needs to be linked to the scheduled data time points for the study. (See Section 7.6.1.3, "Data schedule:".) The CSS segment enables communication of data schedules and adherence that ranges from the basic to the elaborate. Use of the segment must be planned for each implementation. Each CSS segment will subsume observation and drug administration segments that follow, indicating that they satisfy this scheduled time point.

HL7 Attribute Table - CSS - Clinical Study Data Schedule Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
CSS
1 Study Scheduled Time Point CWE R
0595
[1..1] 01055
2 Study Scheduled Patient Time Point DTM O
[0..1] 01056
3 Study Quality Control Codes CWE O
0596
[0..3] 01057

CSS-1: Study Scheduled Time Point (CWE) 01055

FIXME

CSS-2: Study Scheduled Patient Time Point (DTM) 01056

FIXME

CSS-3: Study Quality Control Codes (CWE) 01057

FIXME

CTI - Clinical Trial Identification Segment

The CTI segment is an optional segment that contains information to identify the clinical trial, phase and time point with which an order or result is associated.

HL7 Attribute Table - CTI - Clinical Trial Identification Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
CTI
1 Sponsor Study ID EI R
[1..1] 01011
2 Study Phase Identifier CWE C
0587
[0..1] 01022
3 Study Scheduled Time Point CWE O
0595
[0..1] 01055
4 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]

CTI-1: Sponsor Study ID (EI) 01011

FIXME

CTI-2: Study Phase Identifier (CWE) 01022

FIXME

CTI-3: Study Scheduled Time Point (CWE) 01055

FIXME

CTI-4: Action Code (ID) 00816

FIXME

CM0 - Clinical Study Master Segment

The Technical Steward for the CM0 segment is Orders and Observations.

The Clinical Study Master (CM0) segment contains the information about the study itself. The sending application study number for each patient is sent in the CSR segment. The optional CM0 enables information about the study at the sending application that may be useful to the receiving systems. All of the fields in the segment describe the study status at the sending facility unless otherwise agreed upon.

HL7 Attribute Table - CM0 - Clinical Study Master Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
CM0
1 Set ID - CM0 SI O
[0..1] 01010 [1..4]
2 Sponsor Study ID EI R
[1..1] 01011
3 Alternate Study ID EI O
[0..3] 01036
4 Title of Study ST R
[1..1] 01013 300 #
5 Chairman of Study XCN O
[0..*] 01014
6 Last IRB Approval Date DT O
[0..1] 01015
7 Total Accrual to Date NM O
[0..1] 01016 8 #
8 Last Accrual Date DT O
[0..1] 01017
9 Contact for Study XCN O
[0..*] 01018
10 Contact's Telephone Number XTN O
[0..1] 01019
11 Contact's Address XAD O
[0..*] 01020

CM0-1: Set ID - CM0 (SI) 01010

FIXME

CM0-2: Sponsor Study ID (EI) 01011

FIXME

CM0-3: Alternate Study ID (EI) 01036

FIXME

CM0-4: Title of Study (ST) 01013

FIXME

CM0-5: Chairman of Study (XCN) 01014

FIXME

CM0-6: Last IRB Approval Date (DT) 01015

FIXME

CM0-7: Total Accrual to Date (NM) 01016

FIXME

CM0-8: Last Accrual Date (DT) 01017

FIXME

CM0-9: Contact for Study (XCN) 01018

FIXME

CM0-10: Contact's Telephone Number (XTN) 01019

FIXME

CM0-11: Contact's Address (XAD) 01020

FIXME

CM1 - Clinical Study Phase Master Segment

The Technical Steward for the CM1 segment is Orders and Observations.

Each Clinical Study Phase Master (CM1) segment contains the information about one phase of a study identified in the preceding CM0. This is an optional structure to be used if the study has more than one treatment or evaluation phase within it. The identification of study phases that the patient enters are sent in the CSP segment: sequence 2. The CM1 segment describes the phase in general for the receiving system.

HL7 Attribute Table - CM1 - Clinical Study Phase Master Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
CM1
1 Set ID - CM1 SI R
[1..1] 01021 [1..4]
2 Study Phase Identifier CWE R
0587
[1..1] 01022
3 Description of Study Phase ST R
[1..1] 01023 300 #

CM1-1: Set ID - CM1 (SI) 01021

FIXME

CM1-2: Study Phase Identifier (CWE) 01022

FIXME

CM1-3: Description of Study Phase (ST) 01023

FIXME

CM2 - Clinical Study Schedule Master Segment

The Technical Steward for the CM2 segment is Orders and Observations.

The Clinical Study Schedule Master (CM2) contains the information about the scheduled time points for study or phase-related treatment or evaluation events. The fact that a patient has data satisfying a scheduled time point is sent in the CSS segment, sequence 2. The CM2 segment describes the scheduled time points in general.

HL7 Attribute Table - CM2 - Clinical Study Schedule Master Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
CM2
1 Set ID- CM2 SI O
[0..1] 01024 [1..4]
2 Scheduled Time Point CWE R
[1..1] 01025
3 Description of Time Point ST O
[0..1] 01026 300 #
4 Events Scheduled This Time Point CWE R
[1..200] 01027

CM2-1: Set ID- CM2 (SI) 01024

FIXME

CM2-2: Scheduled Time Point (CWE) 01025

FIXME

CM2-3: Description of Time Point (ST) 01026

FIXME

CM2-4: Events Scheduled This Time Point (CWE) 01027

FIXME

Clinical Trials – Examples of use

CRM - Message When Patient Registered on a Clinical Trial

MSH|^~VALUEamp;|PDMS|MDACC|ORDER |MDACC|200006021649||CRM^C01^CRM_C01|...

PID|1||2222||Everywoman^Eve^E||19530117|...

CSR|DM94-004^MDACC||MDACC|3||19941013||342^^^^^^^PDMS| |||||1005^^^^^^^MDACC|19941013|Y^Meets All Requirements^PDMS|...

CRM - Message When Patient Begins a Phase of a Clinical Trial

MSH|^~VALUEamp;|PDMS|MDACC|PHARM|MDACC|200006050925||CRM^C05^CRM_C05|...

PID|1||2222||Everywoman^Eve^E||19230213|...

CSR|ID91-025^MDACC||MDACC|301||19941005||342^^^^^^^PDMS |||19941201|2^blind^PDMS| 12^Smoker,Stage II,<60^PDMS|...

CSP|2^Treatment^PDMS|19941201|...

CSU - Message Reporting Monthly Patient Data Updates to the Sponsor

MSH|^~VALUEamp;|PDMS|MDACC|CTMS|NCI|200006050927||CSU^C09^CRM_C09|...

PID|1||235925||J^F^M||19350616|...                                [note:anonymous]

CSR|T93-080^NCI|ID93-030^^MDACC|MDACC|14||19941205|...

CSS|^Prestudy|19941204|C^compliant^NCI

OBR|1|1234|1234|3^EligibilChecklist^StudyFormsList|||19941205|...

Note: The clinical trials section probably needs its own definition of OBR. OBR-2&3 have condition rules indicating that the placer and filler numbers must be present in either the ORC or the OBR. Since an ORC is not present, then these fields must be populated in the OBR. My guess is that clinical trials aren't interested in the placer and filler number.

OBX|1|CWE|ELIG1^Elig Crit 1^NCI|Text Elig Crit 1|Y|...

OBX|2|CWE|ELIG2^Elig Crit 2^NCI||Y|...

OBR|2|1235|1235|4^Prestudy Form^StudyFormsList|||19941205|...

OBX|1|CWE|QOL^Quality of Life^NCI||2\T\T\T\T^SPITZER|...

OBX|2|CWE|PRICHEM^Prior Chemo^NCI||Yes|...

OBX|3|CWE|PRIBIOL^Prior Biologics^NCI||No|...

OBX|4|NM|NUMREM^Number Prior Remissions^NCI||2|...

OBR|3|932^OE|243789^LAB|88304^SURG PATH REPORT|||19940101|...

OBX|1|CWE|88304&ANT|1|9999^PANCREAS^SNM|...

OBX|2|CWE|88304&IMP|2|9999^ADENOCARCINOMA^SNM|...

OBR|4|933^OE|243790^LAB|85022^CBC|||199412050800|...

OBX|1|NM|718-7^HEMOGLOBIN:^LN||13.4|GM/DL|14-18|N||S|F|19860522|...

[cbc values]

OBX|2|NM|4544-3^HEMATOCRIT:^LN||40.3|%|42-52|L||S|F|19860522|...

OBX|3|NM|789-8^ERYTHROCYTES:^LN||4.56|10*6/ml|4.7-6.1|L||S|F|19860522|...

OBX|4|NM|787-22^ERYTHROCYTE MEAN CORPUSCULAR VOLUME:^LN||88|fl |80-94|N||S|F|19860522|...

OBX|5|NM|785-6^ERYTHROCYTE MEAN CORPUSCULAR HEMOGLOBIN:^LN||29.5|pg |27-31|N||N|F|19860522|...

OBX|6|NM|786-4^ERYTHROCYTE MEAN CORPUSCULAR HEMOGLOBIN CONCENTRATION:^LN||33|%|33-37|N||N|F|19860522|...

OBX|7|NM|6690-2^LEUKOCYTES:^LN||10.7|10*3/ml|4.8-10.8|N||N|F|19860522|...

OBX|8|NM|764-1^NEUTROPHILS BAND FORM/100 LEUKOCYTES:^LN||2|%|||||F|...

OBX|9|NM|769-0^NEUTROPHILS SEGMENTED/100 LEUKOCYTES:^LN||67|%|||||F |...

OBX|10|NM|736-9^LYMPHOCYTES/100 LEUKOCYTES:^LN||29|%|||||F|...

OBX|11|NM|5905-5^MONOCYTES/100 LEUKOCYTES:^LN||1|%|||||F|...

OBX|12|NM|713-8^EOSINOPHILS/100 LEUKOCYTES:^LN||2|%|||||F|...

OBR|5|934^OE|243791^LAB|80004^ELECTROLYTES|||199412050800|...

OBX|1|NM|2947-0^SODIUM:^LN||150|mmol/l|136-148|H||A|F|19850301 |...

OBX|2|NM|2823-3^POTASSIUM:^LN||4.5|mmol/l|3.5-5|N||N|F|19850301|...

[electrolytes values]

OBX|3|NM|2069-3^CHLORIDE:^LN||102|mmol/l|94-105|N||N|F|19850301|...

OBX|4|NM|2028-9^CARBON DIOXIDE.TOTAL:^LN||27|mmol/l|24-31|N||N|F |19850301|...

CSP|^Course 1|19941205|19950120|Y^Toxicity and Response^NCI |...

CSS|^Course Completion|19950120|...

OBR|1|935^OE|243791^LAB|2039-6^CARCINOEMBRYONIC AG:^LN|||19941008|...

OBX|1|NM|2039-6^CARCINOEMBRYONIC AG:^LN||15.2|IU |...

OBR|2|1236|1236|10^Course Completion Form^StudyPhaseFormsList|||19950120 |...

OBX|1|CWE|CRSRESP^Course Response^NCI||4^Partial Response|...

OBX|2|NM|DRUGDISP^Capsules Dispensed^NCI||60|...

OBX|3|NM|DRUGRETN^Capsules Returned^NCI||5|...

OBX|4|ID|DXCOMP^Diagnostic Tests Compliance^NCI||Y|...

OBX|5|CWE|PERSTAT^Performance Status^NCI||3^ZUBRODS|...

OBR|3|1237|1237|9999^Adverse Events|...

OBX|1|CWE|9999&EVENT|1|45^Vomiting^NCI|...

OBX|2|DT|9999&ONSET|1|19941215|...

OBX|3|DT|9999&RESOLUTION|1|19941217|...

OBX|4|CWE|9999&GRADE|1|M^MODERATE|...

OBX|5|CWE|9999&RELATION_TO_RX|1|L^LIKELY|...

OBX|6|CWE|9999&EVENT|2|303^Dyspnea^NCI|...

OBX|7|DT|9999&ONSET|2|19941231|...

OBX|8|DT|9999&RESOLUTION|2|...

OBX|9|CWE|9999&GRADE|2|MI^MILD|...

OBX|10|CWE|9999&RELATION_TO_RX|2|U^UNLIKELY|...

[Note: Needs to maintain compatibility with ongoing product experience message efforts.]

[Note2: There are other possible OBX suffixes defined by FDA: APEX/ NADIR, ACTION, THERAPY, OUTCOME, RECHALLENGE.]

Product Experience

Patients experience symptoms, manifest signs or develop diseases or syndromes while exposed to medical devices and/or drugs. Evidence suggests that some of these symptoms, signs, diseases or syndromes may develop as a consequence of the products used. Examples include the development of clear cell adenocarcinoma of the vagina in the daughters of mothers treated with diethylstilbestrol during pregnancy and gastrointestinal bleeding in patients treated with non-steroidal anti-inflammatory drugs. While it is difficult to prove causality, strong evidence exists in many cases.

It is important to document such experiences during the development and testing of products to identify potential adverse effects but also during routine use of the product to identify serious adverse effects which occur infrequently. The latter is the realm of pharmacoepidemiology and post-marketing surveillance.

Adverse events are important for product manufacturers as signal generating hypotheses concerning drug kinetics or dynamics, often in special populations of patients. Adverse events are important for regulators in ensuring that manufacturers protect the public health in assessments of risk and benefits, including special populations, and that they promptly and thoroughly investigate individual events and clusters of events. Adverse events are especially important for practitioners and patients who always deal with a special population of one individual who may be having an event and a practitioner seeking information about related events seen with the same or similar products.

Reporting has usually focused on serious and unexpected events. Serious, if defined unambiguously, focuses attention on those events of most importance to the patient and practitioner. Expected events are those which prior experience has demonstrated to be probabilistically linked to the product and are generally included in product labeling.

Because of the risks associated with the uses of drugs and medical devices, a system of surveillance has been established in most developed countries. With globalization of the marketplace, the need to share this information across national boundaries has increased. Currently most reporting is performed using a series of forms, including CIOMS, yellow cards, the FDA's 1639 and MedWatch forms and the Japanese form, which are sent:

  • from identified reporting sources to regulatory bodies

  • from identified reporting sources to product manufacturers

  • between regulatory bodies

  • within product manufacturers

  • within regulatory bodies

  • from product manufacturers to regulatory bodies

  • from regulatory bodies to the WHO Collaborative Drug Surveillance Center

Figure 7-6. - Flow of product experience information

Regardless of who originates a drug experience report, documentation of the experience eventually reaches the regulatory agencies. The manufacturer is mandated to alert the regulatory agency.

Electronic interchange of these data would reduce errors, decrease costs and speed communications.

Glossary

Drug:

Any chemical compound that may be used on or administered to humans or animals as an aid in the diagnosis, treatment or prevention of disease or other abnormal condition, for the relief of pain or suffering, or to control or improve any physiological condition (Dorland's Illustrated Medical Dictionary 27th edition).

Medical device:

Something contrived for or used in the diagnosis (vascular catheters), treatment (thermotherapy units) or prevention of disease or other abnormal condition, for the relief of pain or suffering or to control or improve any physiologic condition, including instrumentation and implanted devices (prosthetic cardiac valves, pacemakers, hip prostheses).

Product:

A drug or medical device.

Non-proprietary (generic) name:

Drug name that is not protected by a trademark, usually descriptive of its chemical structure; sometimes called a public name. In the US, most generic drug names are assigned by the US Adopted Name Council (USAN). Other generic names in common use are the National Formulary (NF) and the US Pharmacopoeia (USP) names. Figure 7-3 lists other available drug coding systems.

Trade (brand) name:

Proprietary names that are registered to protect the name for the sole use of the manufacturer holding the trademark.

Adverse event/adverse experience:

  • Pre-marketing: Any untoward medical occurrence in a patient or clinical investigation subject administered a pharmaceutical product and which does not necessarily have a causal relationship with this treatment.

  • Post-marketing/European Union: Any undesirable experience occurring to a patient treated with a pharmaceutical product whether or not considered related to the medicinal product.

  • Post-marketing/US: Any adverse event associated with the use of a drug in humans, whether or not considered drug related, including the following: An adverse event occurring in the course of the use of a drug product in professional practice; an adverse event occurring from drug overdose; an adverse event occurring from drug withdrawal; and any failure of expected pharmacologic action.

  • WHO: Any untoward medical occurrence that may present during treatment with a pharmaceutical product but which does not necessarily have a causal relationship with this product.

Adverse drug reaction:

  • Pre-marketing: All noxious and unintended responses to a medicinal product related to any dose.

  • Post-marketing/WHO: A response to a drug which is noxious and unintended, and which occurs at doses normally used in man for prophylaxis, diagnosis, or therapy of disease or for the modification of physiologic function

  • Post-marketing/European Union: A reaction which is harmful and unintended and which occurs at doses normally used in man for the prophylaxis, diagnosis, or treatment of disease or the modification of physiological function.

  • Post-marketing/US: Any undesirable effect reasonably associated with the use of the drug that may occur as part of the pharmacological action of the drug or may be unpredictable.

Causation:

An exposure which truly does increase or decrease the probability of a certain outcome.

Causal relationship:

When an event occurs a product may be suspected as causing the event but rarely can it be proven particularly at an early stage of the product's life. Certain information about the relationship between the product and the event can reinforce the belief in a causal relationship between the product and the event while others can decrease the probability that there is a causal relationship.

Regulatory agency:

Many geopolitical entities have established agencies/authority responsible for regulating products used in health care. The agencies are collectively referred to as regulatory agencies.

Product manufacturer:

The organization which is responsible for the manufacture of a product. This will usually be the entity, which holds the marketing authorization for the product.

Holder of marketing authorization:

The organization which holds the authority to market a product. This will often be the organization, which manufactures the product.

Serious adverse product reaction:

An adverse product reaction which:

  • is fatal (results in death)

  • is life threatening

  • requires hospitalization or prolongation of a hospitalization

  • results in persistent or significant disability/incapacity

  • results in a congenital anomaly/birth defect.

Medical and scientific judgment should be exercised in deciding whether expedited reporting is appropriate in other situations, such as important medical events that may not be immediately life threatening or result in hospitalization but may jeopardize the patient or may require intervention to prevent one of the other outcomes listed in the definition above. These should also be considered serious.

Expected adverse product reaction:

Expected events are those which prior experience has demonstrated to be probabilistically linked to the product and are generally included in product labeling.

Pre-marketing: An adverse reaction, the nature or severity of which is not consistent with the applicable product information (e.g., Investigator's Brochure for an unapproved investigational product).

Post-marketing/European Union: This relates to an adverse reaction which is not mentioned in any EC summary of product characteristics (SPC). In the absence of any European SPC, an international document prepared by the marketing authorization holder containing all relevant safety information which the marketing authorization holder considers should be listed for the medicinal product in all countries where the medicinal product is marketed (Care Data Sheet).

Post-marketing/US current: Unexpected means an adverse drug experience that is not listed in the current labeling for the drug product and includes an event that may be symptomatically and pathophysiologically related to an event listed in the labeling but differs from the event because of greater severity or specificity.

Post-marketing/US (proposed): The applicant's core safety data sheet shall be a document prepared by the applicant that contains all relevant safety information, including adverse drug experiences, which the applicant believes should e listed for the drug in all countries where the drug is marketed. It may be used by the applicant as the reference document by which an adverse drug experience is judged to be expected or unexpected for purposes of this post-marketing periodic report.

Post-marketing/WHO: An adverse reaction, the nature or severity of which is not consistent with domestic labeling or market authorization, or expected from characteristics of the drug.

References

Gabrielli ER. Standard specification for drug therapy documentation. ASTM Committee E31.12 July (1993).

Kessler DA. Introducing MEDWatch. JAMA 269: 2765-2768(1993).

Kurata JH, Overhage JM, Gabrielli E, Jones JK. International Data Standards for Hospital-based Drug Surveillance. M.D. Computing 12(1) 50-57 (1995).

Moore N, Montera d, Coulson R, DeAbajo F, Kreft-Jais C, Biron A, Monteaugudo J. The single case format: proposal for a structured message for the telematic transmission of information on individual case reports in pharmacovigilance. Pharmacoepidemiology and Drug Safety 3: 157-162 (1994)

Thompson WL. A modest proposal for enhancing the safety and effectiveness of use of human drugs, biologics and devices and animal health products with human health implications through cost-effective health informatics tools supporting a global database of safety reports as a joint ICH E2, M1 and M2 initiative. Private communication. March (1995)

Product Experience - Trigger Events And Message Definitions

The message header segment will care one of three event types at MSH-9-message type.

Event

Description

P07

PEX - Unsolicited initial individual product experience report

P08

PEX - Unsolicited update individual product experience report

P09

SUR - Summary product experience report


PEX - Product Experience Message (Events P07, P08)

The primary application of this message is to transfer information related to an adverse event occurring while a patient was exposed to a product.

The PID segment provides the patient identification information including institutional identification numbers, date of birth and in the case of patients who die, information about their death. Patients are frequently identified only by their initials which can be represented in the PID segment, e.g., the initials JMO would appear as J^M^O in the name field of the PID segment. The EVN segment identifies the type of transaction that is being sent -- primarily it specifies who the sender is and implies which information is expected to be included in the message. A message sent from a healthcare provider, for example, might contain minimal information, while a message from a pharmaceutical manufacturer might contain nearly complete information.

The PES or Product Experience Sender segment provides information about the message sender and its knowledge of the event. The heart of the product experience message is the product experience observation (PEO) segment and the PCR segments clustered under it. The PEO segment identifies a clinical event and the PCR segments identify products which are potentially causally related to the event. There may be more than one product which is potentially related to the event so multiple PCR segments can be included. RXE and RXR segments can be repeated and provide information about the products the patient was exposed to at the time of the event (typically excluding those used to treat the event). Details about the administration of the products identified in the PCR segments should be described with RXE and RXR segments. Repeated PRB segments provide information about diagnoses which represent comorbid conditions. The repeated OBX segments are used to send patient observations such as height, weight, last menstrual period, and laboratory results. Analytical commentary can be included in the NTE segment. This commentary will typically be the sender's analysis of the event and the potentially causally related products. Finally, the CSR and CSP segments can optionally be included if the event occurred during a formal clinical trial in order to describe the trial.

When a product experience relates to an exposure which occurred indirectly (transmammary or transplacentally for example), the individual experiencing the adverse effect — the fetus or child — would be described in the PID segment and the individual via which they are exposed in the NK1 segment. The first set of RXE segments would typically indicate the drugs which to which the fetus or child was exposed. Additional codes for the route are defined in this Appendix to allow the suspected routes of exposure to be represented. The second set of RXE/RXR segment - those clustered under the NK1 segment - would represent the route by which the mother or father was exposed to the drug. Early spontaneous abortion would normally be treated as an adverse effect on the mother rather than on the fetus, and the PID would refer to the mother. The second set of PRB/OBX segments reflects the problems/observations associated with the individual via which they were exposed.

Each message contains information about a single case including one patient (PID), at least one sender (PES), one or more events (PEO) and one or more suspected products (PCR and RXE/RXA) for a minimal message. The structure of the message allows actual administration information to be sent in the RXA if known; if administration information is unavailable, or the adverse reaction cannot be related to a single administration event, the RXE segment can be used to send prescription level information. Additional information may be included based on availability and regulatory requirements.

The MSH segment specifies the character set (MSH-18) and the language (MSH-19) used in the PEX message.

The PEX message is designed to accommodate required reporting of adverse product events to the responsible regulatory agencies. In the United States, the paper version of this report is Medwatch.

PEX^P07^PEX_P07: Product Experience Message
HL7 MessageStructure Table - PEX_P07
Segment Cardinality Must Implement Status
PEX_P07
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
EVN 1..1 Yes
PID 1..1 Yes
PD1 0..1
PRT 0..*
ARV 0..* B
NTE 0..*
VISIT 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
EXPERIENCE 1..* Yes
PES 1..1 Yes
PEX_OBSERVATION 1..* Yes
PEO 1..1 Yes
PEX_CAUSE 1..* Yes
PCR 1..1 Yes
RX_ORDER 0..1
RXE 1..1 Yes
PRT 0..*
TIMING_QTY 1..* Yes
TQ1 1..1 Yes
TQ2 0..*
RXR 0..*
RX_ADMINISTRATION 0..*
RXA 1..1 Yes
RXR 0..1
PRT 0..*
PRB 0..*
OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
NTE 0..*
ASSOCIATED_PERSON 0..1
NK1 1..1 Yes
ASSOCIATED_RX_ORDER 0..1
RXE 1..1 Yes
PRT 0..*
NK1_TIMING_QTY 1..* Yes
TQ1 1..1 Yes
TQ2 0..*
RXR 0..*
ASSOCIATED_RX_ADMIN 0..*
RXA 1..1 Yes
RXR 0..1
PRT 0..*
PRB 0..*
ASSOCIATED_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
STUDY 0..*
CSR 1..1 Yes
CSP 0..*

Original Mode Acknowledgement Choreography for PEX^P07^PEX_P07

Send Application Ack: ACK^P07^ACK

Enhanced Mode Acknowledgement Choreography for PEX^P07^PEX_P07

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

When the MSH-15 value of a PEX^P07^PEX_P07 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a PEX^P07^PEX_P07 message is AL or ER or SU, an ACK^P07^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a PEX^P07^PEX_P07 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

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

PEX^P08^PEX_P07: Product Experience Message
HL7 MessageStructure Table - PEX_P07
Segment Cardinality Must Implement Status
PEX_P07
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
EVN 1..1 Yes
PID 1..1 Yes
PD1 0..1
PRT 0..*
ARV 0..* B
NTE 0..*
VISIT 0..1
PV1 1..1 Yes
PV2 0..1
PRT 0..*
EXPERIENCE 1..* Yes
PES 1..1 Yes
PEX_OBSERVATION 1..* Yes
PEO 1..1 Yes
PEX_CAUSE 1..* Yes
PCR 1..1 Yes
RX_ORDER 0..1
RXE 1..1 Yes
PRT 0..*
TIMING_QTY 1..* Yes
TQ1 1..1 Yes
TQ2 0..*
RXR 0..*
RX_ADMINISTRATION 0..*
RXA 1..1 Yes
RXR 0..1
PRT 0..*
PRB 0..*
OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
NTE 0..*
ASSOCIATED_PERSON 0..1
NK1 1..1 Yes
ASSOCIATED_RX_ORDER 0..1
RXE 1..1 Yes
PRT 0..*
NK1_TIMING_QTY 1..* Yes
TQ1 1..1 Yes
TQ2 0..*
RXR 0..*
ASSOCIATED_RX_ADMIN 0..*
RXA 1..1 Yes
RXR 0..1
PRT 0..*
PRB 0..*
ASSOCIATED_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
STUDY 0..*
CSR 1..1 Yes
CSP 0..*

Original Mode Acknowledgement Choreography for PEX^P08^PEX_P07

Send Application Ack: ACK^P08^ACK

Enhanced Mode Acknowledgement Choreography for PEX^P08^PEX_P07

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

When the MSH-15 value of a PEX^P08^PEX_P07 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

When the MSH-16 value of a PEX^P08^PEX_P07 message is AL or ER or SU, an ACK^P08^ACK message SHALL be sent as an application ack.

When the MSH-16 value of a PEX^P08^PEX_P07 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

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

SUR - Summary Product Experience Report (Event P09)

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

Product Experience – Segment Definitions

PES - Product Experience Sender Segment

HL7 Attribute Table - PES - Product Experience Sender Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
PES
1 Sender Organization Name XON O
[0..*] 01059
2 Sender Individual Name XCN O
[0..*] 01060
3 Sender Address XAD O
[0..*] 01062
4 Sender Telephone XTN O
[0..*] 01063
5 Sender Event Identifier EI O
[0..1] 01064
6 Sender Sequence Number NM O
[0..1] 01065 16 #
7 Sender Event Description FT O
[0..*] 01066 600 #
8 Sender Comment FT O
[0..1] 01067 600 #
9 Sender Aware Date/Time DTM O
[0..1] 01068
10 Event Report Date DTM R
[1..1] 01069
11 Event Report Timing/Type ID O
0234(R) Report Timing(Required)
[0..2] 01070 [2..3]
12 Event Report Source ID O
0235(R) Report Source(Required)
[0..1] 01071 [1..1]
13 Event Reported To ID O
0236(R) Event Reported To(Required)
[0..*] 01072 [1..1]

PES-1: Sender Organization Name (XON) 01059

FIXME

PES-2: Sender Individual Name (XCN) 01060

FIXME

PES-3: Sender Address (XAD) 01062

FIXME

PES-4: Sender Telephone (XTN) 01063

FIXME

PES-5: Sender Event Identifier (EI) 01064

FIXME

PES-6: Sender Sequence Number (NM) 01065

FIXME

PES-7: Sender Event Description (FT) 01066

FIXME

PES-8: Sender Comment (FT) 01067

FIXME

PES-9: Sender Aware Date/Time (DTM) 01068

FIXME

PES-10: Event Report Date (DTM) 01069

FIXME

PES-11: Event Report Timing/Type (ID) 01070

FIXME

PES-12: Event Report Source (ID) 01071

FIXME

PES-13: Event Reported To (ID) 01072

FIXME

PEO - Product Experience Observation Segment

Details related to a particular clinical experience or event are embodied in the PEO segment. This segment can be used to characterize an event which might be attributed to a product to which the patient was exposed. Products with a possible causal relationship to the observed experience are described in the following PCR (possible causal relationship) segments. The message format was designed to be robust and includes many optional elements which may not be required for a particular regulatory purpose but allow a complete representation of the drug experience if needed.

A PEX message can contain multiple PEO segments if the patient experienced more than one event but must contain at least one PEO segment.

HL7 Attribute Table - PEO - Product Experience Observation Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
PEO
1 Event Identifiers Used CWE O
0678
[0..*] 01073
2 Event Symptom/Diagnosis Code CWE O
0679
[0..*] 01074
3 Event Onset Date/Time DTM R
[1..1] 01075
4 Event Exacerbation Date/Time DTM O
[0..1] 01076
5 Event Improved Date/Time DTM O
[0..1] 01077
6 Event Ended Data/Time DTM O
[0..1] 01078
7 Event Location Occurred Address XAD O
[0..*] 01079
8 Event Qualification ID O
0237(R) Event Qualification(Required)
[0..*] 01080 [1..1]
9 Event Serious ID O
0238(R) Event Seriousness(Required)
[0..1] 01081 [1..1]
10 Event Expected ID O
0239(R) Event Expected(Required)
[0..1] 01082 [1..1]
11 Event Outcome ID O
0240(R) Event Consequence(Required)
[0..*] 01083 [1..1]
12 Patient Outcome ID O
0241(R) Patient Outcome(Required)
[0..1] 01084 [1..1]
13 Event Description from Others FT O
[0..*] 01085 600 #
14 Event Description from Original Reporter FT O
[0..*] 01086 600 #
15 Event Description from Patient FT O
[0..*] 01087 600 #
16 Event Description from Practitioner FT O
[0..*] 01088 600 #
17 Event Description from Autopsy FT O
[0..*] 01089 600 #
18 Cause Of Death CWE O
0680
[0..*] 01090
19 Primary Observer Name XPN O
[0..*] 01091
20 Primary Observer Address XAD O
[0..*] 01092
21 Primary Observer Telephone XTN O
[0..*] 01093
22 Primary Observer's Qualification ID O
0242(R) Primary Observer's Qualification(Required)
[0..1] 01094 [1..1]
23 Confirmation Provided By ID O
0242(R) Primary Observer's Qualification(Required)
[0..1] 01095 [1..1]
24 Primary Observer Aware Date/Time DTM O
[0..1] 01096
25 Primary Observer's identity May Be Divulged ID O
0243(R) Identity May Be Divulged(Required)
[0..1] 01097 [1..2]

PEO-1: Event Identifiers Used (CWE) 01073

FIXME

PEO-2: Event Symptom/Diagnosis Code (CWE) 01074

FIXME

PEO-3: Event Onset Date/Time (DTM) 01075

FIXME

PEO-4: Event Exacerbation Date/Time (DTM) 01076

FIXME

PEO-5: Event Improved Date/Time (DTM) 01077

FIXME

PEO-6: Event Ended Data/Time (DTM) 01078

FIXME

PEO-7: Event Location Occurred Address (XAD) 01079

FIXME

PEO-8: Event Qualification (ID) 01080

FIXME

PEO-9: Event Serious (ID) 01081

FIXME

PEO-10: Event Expected (ID) 01082

FIXME

PEO-11: Event Outcome (ID) 01083

FIXME

PEO-12: Patient Outcome (ID) 01084

FIXME

PEO-13: Event Description from Others (FT) 01085

FIXME

PEO-14: Event Description from Original Reporter (FT) 01086

FIXME

PEO-15: Event Description from Patient (FT) 01087

FIXME

PEO-16: Event Description from Practitioner (FT) 01088

FIXME

PEO-17: Event Description from Autopsy (FT) 01089

FIXME

PEO-18: Cause Of Death (CWE) 01090

FIXME

PEO-19: Primary Observer Name (XPN) 01091

FIXME

PEO-20: Primary Observer Address (XAD) 01092

FIXME

PEO-21: Primary Observer Telephone (XTN) 01093

FIXME

PEO-22: Primary Observer's Qualification (ID) 01094

FIXME

PEO-23: Confirmation Provided By (ID) 01095

FIXME

PEO-24: Primary Observer Aware Date/Time (DTM) 01096

FIXME

PEO-25: Primary Observer's identity May Be Divulged (ID) 01097

FIXME

PCR - Possible Causal Relationship Segment

The PCR segment is used to communicate a potential or suspected relationship between a product (drug or device) or test and an event with detrimental effect on a patient. This segment identifies a potential causal relationship between the product identified in this segment and the event identified in the PEO segment.

More than one PCR segment can be included in the message if more than one product is possibly causally related to the event.

HL7 Attribute Table - PCR - Possible Causal Relationship Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
PCR
1 Implicated Product CWE R
0670
[1..1] 01098
2 Generic Product IS O
0249 Generic Product
[0..1] 01099 1 #
3 Product Class CWE O
0671
[0..1] 01100
4 Total Duration Of Therapy CQ O
[0..1] 01101
5 Product Manufacture Date DTM O
[0..1] 01102
6 Product Expiration Date DTM O
[0..1] 01103
7 Product Implantation Date DTM O
[0..1] 01104
8 Product Explantation Date DTM O
[0..1] 01105
9 Single Use Device CWE O
0244 Single Use Device
[0..1] 01106
10 Indication For Product Use CWE O
0672
[0..1] 01107
11 Product Problem CWE O
0245 Product Problem
[0..1] 01108
12 Product Serial/Lot Number ST O
[0..3] 01109 199 #
13 Product Available For Inspection CWE O
0246 Product Available for Inspection
[0..1] 01110
14 Product Evaluation Performed CWE O
0673
[0..1] 01111
15 Product Evaluation Status CWE O
0247(R) Status of Evaluation(Required)
[0..1] 01112
16 Product Evaluation Results CWE O
0674
[0..1] 01113
17 Evaluated Product Source ID O
0248(R) Product Source(Required)
[0..1] 01114 [1..1]
18 Date Product Returned To Manufacturer DTM O
[0..1] 01115
19 Device Operator Qualifications ID O
0242(R) Primary Observer's Qualification(Required)
[0..1] 01116 [1..1]
20 Relatedness Assessment ID O
0250(R) Relatedness Assessment(Required)
[0..1] 01117 [1..1]
21 Action Taken In Response To The Event ID O
0251(R) Action Taken in Response to the Event(Required)
[0..6] 01118 [1..2]
22 Event Causality Observations ID O
0252(R) Causality Observations(Required)
[0..6] 01119 [2..2]
23 Indirect Exposure Mechanism ID O
0253(R) Indirect Exposure Mechanism(Required)
[0..3] 01120 [1..1]

PCR-1: Implicated Product (CWE) 01098

FIXME

PCR-2: Generic Product (IS) 01099

FIXME

PCR-3: Product Class (CWE) 01100

FIXME

PCR-4: Total Duration Of Therapy (CQ) 01101

FIXME

PCR-5: Product Manufacture Date (DTM) 01102

FIXME

PCR-6: Product Expiration Date (DTM) 01103

FIXME

PCR-7: Product Implantation Date (DTM) 01104

FIXME

PCR-8: Product Explantation Date (DTM) 01105

FIXME

PCR-9: Single Use Device (CWE) 01106

FIXME

PCR-10: Indication For Product Use (CWE) 01107

FIXME

PCR-11: Product Problem (CWE) 01108

FIXME

PCR-12: Product Serial/Lot Number (ST) 01109

FIXME

PCR-13: Product Available For Inspection (CWE) 01110

FIXME

PCR-14: Product Evaluation Performed (CWE) 01111

FIXME

PCR-15: Product Evaluation Status (CWE) 01112

FIXME

PCR-16: Product Evaluation Results (CWE) 01113

FIXME

PCR-17: Evaluated Product Source (ID) 01114

FIXME

PCR-18: Date Product Returned To Manufacturer (DTM) 01115

FIXME

PCR-19: Device Operator Qualifications (ID) 01116

FIXME

PCR-20: Relatedness Assessment (ID) 01117

FIXME

PCR-21: Action Taken In Response To The Event (ID) 01118

FIXME

PCR-22: Event Causality Observations (ID) 01119

FIXME

PCR-23: Indirect Exposure Mechanism (ID) 01120

FIXME

PSH - Product Summary Header Segment

This segment is maintained for backwards compatibility only as of v 2.7.

HL7 Attribute Table - PSH - Product Summary Header Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
PSH
1 Report Type ST R
[1..1] 01233 60 #
2 Report Form Identifier ST O
[0..1] 01297 60 #
3 Report Date DTM R
[1..1] 01235
4 Report Interval Start Date DTM O
[0..1] 01236
5 Report Interval End Date DTM O
[0..1] 01237
6 Quantity Manufactured CQ O
[0..1] 01238
7 Quantity Distributed CQ O
[0..1] 01239
8 Quantity Distributed Method ID O
0329(R) Quantity Method(Required)
[0..1] 01240 [1..1]
9 Quantity Distributed Comment FT O
[0..1] 01241 600 #
10 Quantity in Use CQ O
[0..1] 01242
11 Quantity in Use Method ID O
0329(R) Quantity Method(Required)
[0..1] 01243 [1..1]
12 Quantity in Use Comment FT O
[0..1] 01244 600 #
13 Number of Product Experience Reports Filed by Facility NM O
[0..8] 01245 16 #
14 Number of Product Experience Reports Filed by Distributor NM O
[0..8] 01246 16 #

PSH-1: Report Type (ST) 01233

FIXME

PSH-2: Report Form Identifier (ST) 01297

FIXME

PSH-3: Report Date (DTM) 01235

FIXME

PSH-4: Report Interval Start Date (DTM) 01236

FIXME

PSH-5: Report Interval End Date (DTM) 01237

FIXME

PSH-6: Quantity Manufactured (CQ) 01238

FIXME

PSH-7: Quantity Distributed (CQ) 01239

FIXME

PSH-8: Quantity Distributed Method (ID) 01240

FIXME

PSH-9: Quantity Distributed Comment (FT) 01241

FIXME

PSH-10: Quantity in Use (CQ) 01242

FIXME

PSH-11: Quantity in Use Method (ID) 01243

FIXME

PSH-12: Quantity in Use Comment (FT) 01244

FIXME

PSH-13: Number of Product Experience Reports Filed by Facility (NM) 01245

FIXME

PSH-14: Number of Product Experience Reports Filed by Distributor (NM) 01246

FIXME

PDC - Product Detail Country Segment

This segment is maintained for backwards compatibility only as of v 2.7.

HL7 Attribute Table - PDC - Product Detail Country Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
PDC
1 Manufacturer/Distributor XON R
[1..*] 01247
2 Country CWE R
0675
[1..1] 01248
3 Brand Name ST R
[1..1] 01249 60 #
4 Device Family Name ST O
[0..1] 01250 60 #
5 Generic Name CWE O
0676
[0..1] 01251
6 Model Identifier ST O
[0..*] 01252 60 #
7 Catalogue Identifier ST O
[0..1] 01253 60 #
8 Other Identifier ST O
[0..*] 01254 60 #
9 Product Code CWE O
0677
[0..1] 01255
10 Marketing Basis ID O
0330(R) Marketing Basis(Required)
[0..1] 01256 [3..4]
11 Marketing Approval ID ST O
[0..1] 01257 60 #
12 Labeled Shelf Life CQ O
[0..1] 01258
13 Expected Shelf Life CQ O
[0..1] 01259
14 Date First Marketed DTM O
[0..1] 01260
15 Date Last Marketed DTM O
[0..1] 01261

PDC-1: Manufacturer/Distributor (XON) 01247

FIXME

PDC-2: Country (CWE) 01248

FIXME

PDC-3: Brand Name (ST) 01249

FIXME

PDC-4: Device Family Name (ST) 01250

FIXME

PDC-5: Generic Name (CWE) 01251

FIXME

PDC-6: Model Identifier (ST) 01252

FIXME

PDC-7: Catalogue Identifier (ST) 01253

FIXME

PDC-8: Other Identifier (ST) 01254

FIXME

PDC-9: Product Code (CWE) 01255

FIXME

PDC-10: Marketing Basis (ID) 01256

FIXME

PDC-11: Marketing Approval ID (ST) 01257

FIXME

PDC-12: Labeled Shelf Life (CQ) 01258

FIXME

PDC-13: Expected Shelf Life (CQ) 01259

FIXME

PDC-14: Date First Marketed (DTM) 01260

FIXME

PDC-15: Date Last Marketed (DTM) 01261

FIXME

FAC - Facility Segment

This segment is maintained for backwards compatibility only as of V2.7.

HL7 Attribute Table - FAC - Facility Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
FAC
1 Facility ID-FAC EI R
[1..1] 01262
2 Facility Type ID O
0331(R) Facility Type(Required)
[0..1] 01263 [1..1]
3 Facility Address XAD R
[1..*] 01264
4 Facility Telecommunication XTN R
[1..1] 01265
5 Contact Person XCN O
[0..*] 01266
6 Contact Title ST O
[0..*] 01267 60 #
7 Contact Address XAD O
[0..*] 01166
8 Contact Telecommunication XTN O
[0..*] 01269
9 Signature Authority XCN R
[1..*] 01270
10 Signature Authority Title ST O
[0..1] 01271 199 #
11 Signature Authority Address XAD O
[0..*] 01272
12 Signature Authority Telecommunication XTN O
[0..1] 01273

FAC-1: Facility ID-FAC (EI) 01262

FIXME

FAC-2: Facility Type (ID) 01263

FIXME

FAC-3: Facility Address (XAD) 01264

FIXME

FAC-4: Facility Telecommunication (XTN) 01265

FIXME

FAC-5: Contact Person (XCN) 01266

FIXME

FAC-6: Contact Title (ST) 01267

FIXME

FAC-7: Contact Address (XAD) 01166

FIXME

FAC-8: Contact Telecommunication (XTN) 01269

FIXME

FAC-9: Signature Authority (XCN) 01270

FIXME

FAC-10: Signature Authority Title (ST) 01271

FIXME

FAC-11: Signature Authority Address (XAD) 01272

FIXME

FAC-12: Signature Authority Telecommunication (XTN) 01273

FIXME

Product Experience – Examples of use

MSH|^-&|SAP||RAP||200006051512||PEX^P07|...

EVN|...

PID||1||A^A^A||19230616|F|||||||||||||||||Y|...

Note:    This section probably needs to have its own definition of the PID. PID-3 is a required field in chapter 3, but in the context of this section probably shouldn't be required. I also removed PID-23, Birthplace (19950710). A date is not a birthplace.

PES|MakeADrug, Inc||Manufacturer Mall^^Ann Arbor^MI^99999|| GB95070448A|0|||19950704|19950710|10D|...

PEO||^Awaiting results of autopsy|19950704||||^^^^^GBR||S|N|D~H~O||Patient admitted via casualty with increased shortness of breath and left sided chest pain on 04 JUL 95 for assessment.~11-JUL-95 Patient admitted 09-JUL-95 at 11:30 PM with an 18 hour history of diarrhoea followed by collapse. On admission, patient was exhausted and dehydrated. She had a rash on both breasts and abdomen. Patient found to have deteriorating renal function. Patient commenced IV fluid, however patient was found dead on 10-JUL-95 morning. Query vomited and aspirated. Post mortem requested. Events possibly related to study drug.|...

PCR|xxxxx^Wonder Drug 1^ATC|N|^antineoplastic|||||||^NON SMALL CELL LUNG CANCER|...

RXE|1^^^19950629^19950710|xxxxx^Wonder Drug 1^ATC|1||TAB|||||||||||||||||M1|3||||NON SMALL CELL LUNG CANCER|...

RXR|PO|...

Note:    The message structure for the PEX does not allow repeating RXE/RXR groups within a PCR group. This is probably a mistake in the message definition table for the PEX messages.



PRB|AD|19950704|705^DYSPNEA^MEDR|...

PRB|AD|19950710|20143^DEATH^MEDR|...

PRB|AD|19950704|18330^CHEST PAIN^MEDR|...

PRB|AD|19950709|21197^DIARRHEA^MEDR|...

PRB|AD|19950709|6432^SYNCOPE^MEDR|...

PRB|AD|19950709|4966^DEHYDRATION^MEDR|...

PRB|AD|19950709|20544^KIDNEY FUNCTION ABNORMAL^MEDR|...

OBX|1|NM|804-5^lEUKOCYTES^LN||2300|10*3/ml|||||F|19940704|...

OBX|2|NM|770-8^NEUTROPHILS/100 LEUKOCYTES^LN||1.9|%|||||F|19950704|...

OBX|3|NM|6299-2^UREA NITROGEN^LN||22.3|mg%|||||F|19950709|...

OBX|4|NM|2160-0^CREATININE^LN||247|mmole|||||F|19950709|...

NTE|||Additional details must be obtained from the affiliate in order to assess causality. A three day alert phone call was made to the FDA on 12-JUL-95|...

Waveform

Retained for backwards compatibility only in v 2.7 and withdrawn as of v2.9. Implementers are encouraged to use other V2 guidance (e.g., IHE's PCD profile) or V3 constructs to support waveform messages.

Waveform – Trigger Events & Message Definitions

Retained for backwards compatibility only in v 2.7 and withdrawm as of v2.9. Implementers are encouraged to use other V2 guidance (e.g., IHE's PCD profile) or V3 as it expands its use cases in this space, while using older V2 versions until that point.

SpECIMEN SHIPMENT MANIFEST

OSM - Unsolicited Specimen Shipment Manifest Message (Event R26)

The OSM^R26 Unsolicited Specimen Shipment Manifest message is used to communicate the contents of a specimen shipment to a specimen receiver (typically a laboratory). The message documents details regarding the following:

  • Shipment information including sender, receiver, shipper, shipping container, etc.;

  • Specimens in the shipment;

  • Specimen containers; and,

  • Identification of persons/places/things associated with the specimens.

OSM^R26^OSM_R26: Specimen Shipment Message
HL7 MessageStructure Table - OSM_R26
Segment Cardinality Must Implement Status
OSM_R26
MSH 1..1 Yes
ARV 0..*
SFT 0..*
UAC 0..1
SHIPMENT 1..* Yes
SHP 1..1 Yes
PRT 1..* Yes
SHIPPING_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
PACKAGE 1..* Yes
PAC 1..1 Yes
PRT 0..*
SPECIMEN 0..*
SPM 1..1 Yes
PRT 0..*
SPECIMEN_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
CONTAINER 0..*
SAC 1..1 Yes
CONTAINER_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
SUBJECT_PERSON_OR_ANIMAL_IDENTIFICATION 0..1
PID 1..1 Yes
PRT 0..*
ARV 0..* B
PATIENT_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
NK1 0..*
SUBJECT_POPULATION_OR_LOCATION_IDENTIFICATION 0..1
PV1 1..1 Yes
PRT 0..*
PATIENT_VISIT_OBSERVATION 0..*
OBX 1..1 Yes
PRT 0..*
PID 0..1
PRT 0..*
NK1 0..*

Original Mode Acknowledgement Choreography for OSM^R26^OSM_R26

Send Application Ack: ACK^R26^ACK

Enhanced Mode Acknowledgement Choreography for OSM^R26^OSM_R26

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

When the MSH-15 value of an OSM^R26^OSM_R26 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.

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

When the MSH-16 value of an OSM^R26^OSM_R26 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.

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

Segment Notes

The Participation (PRT) segment following the Shipment (SHP) segment is used to document participants in a shipment. A minimum of one Participation segment is required for documenting the destination of the shipment. Other participants including shipment originator, shipment packer, shipment waypoints, etc. can also be documented using the Participation segment.

The Observation/Result (OBX) segment in the SHIPPING_OBSERVATION segment group is used to carry any additional shipping information or observations that are not carried in the Shipment segment.

The Participation (PRT) segment following the Specimen (SPM) segment is used to identify the person(s) who collected the specimen.

The Observation/Result (OBX) segment in the SPECIMEN_OBSERVATION segment group is used to document any additional shipping information that is not conveyed in the Specimen (SPM) segment.

The Container (SAC) segment is used to document the containers for a specimen. If it is necessary to document where in a package a particular specimen container is found, use SAC-11 (Position in Carrier) to convey this position. SAC-10 (Carrier Identifier) can be used to carry the identifier of the package within which the specimen container is located.

The Observation/Result (OBX) segment in the CONTAINER_OBSERVATION segment group is used to document observations regarding the specimen container.

The SUBJECT_PERSON/ANIMAL_IDENTIFICATION segment group is used to associate a specimen with the person or animal the specimen was obtained from. If the subject of the testing is something other than a person, the Next of Kin/Associated Parties (NK1) segment will document the person or organization responsible or owning the subject. For patients who are persons, the NK1 segment documents the next of kin of the patient.

If the specimen was obtained from a population of animals or a location then the SUBJECT_POPULATION/LOCATION_IDENTIFICATION segment group should be used instead. The Patient Identification (PID) segment in this segment group is used to carry the species, breed and strain information for a population. The Next of Kin (NK1) segment in this segment group is used to convey information regarding the owner or responsible party for a population of animals or a location.

The Patient Visit (PV1) segment is used to provide basic information about a patient encounter where the specimen was taken.

The Observation/Result (OBX) segment in the PATIENT_VISIT_OBSERVATION segment group is used to document observations regarding the visit.

Actors

Specimen Shipper

The Specimen Shipper actor is an application capable of sending specimen shipments and transmitting the specimen shipment manifest message.

Specimen Shipment Receiver

The Specimen Shipment Receiver actor is an application capable of receiving specimen shipments as well as specimen shipment manifest messages. Typically this application is associated with a Laboratory.

Activity Diagram

The following activity diagram illustrates the usage of this message. The message is initially sent from the Specimen Shipper at the point the specimen is shipped. The actual point of transmission of the message could occur as soon as all the contents of the shipment have been identified, and the transporters shipment id has been assigned to the shipment. The specimen shipment receiver will send back transaction using the Specimen Shipment Manifest message indicating the specimen shipment has been accepted or rejected. This normally will occur after the shipment has been physically received and evaluated. Note that this response back is not considered an application acknowledgment, and is certainly not required. Its purpose is to update the shipper with the status of the shipment.

SHP - Shipment Segment

The intent of this segment is to describe the information associated with the transportation of the shipment.

HL7 Attribute Table - SHP - Shipment Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
SHP
1 Shipment ID EI R
[1..1] 02317
2 Internal Shipment ID EI O
[0..*] 02318
3 Shipment Status CWE O
0905 Shipment Status
[0..1] 02319
4 Shipment Status Date/Time DTM R
[1..1] 02320
5 Shipment Status Reason TX O
[0..1] 02321
6 Shipment Priority CWE O
0906(S) ActPriority(Suggested)
[0..1] 02322
7 Shipment Confidentiality CWE O
0907(S) Confidentiality(Suggested)
[0..*] 02323
8 Number of Packages in Shipment NM O
[0..1] 02324 4 #
9 Shipment Condition CWE O
0544(S) Container Condition(Suggested)
[0..*] 02325
10 Shipment Handling Code CWE O
0376(S) Special Handling Code(Suggested)
[0..*] 02326
11 Shipment Risk Code CWE O
0489 Risk Codes
[0..*] 02327
12 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]

SHP-1: Shipment ID (EI) 02317

FIXME

SHP-2: Internal Shipment ID (EI) 02318

FIXME

SHP-3: Shipment Status (CWE) 02319

FIXME

SHP-4: Shipment Status Date/Time (DTM) 02320

FIXME

SHP-5: Shipment Status Reason (TX) 02321

FIXME

SHP-6: Shipment Priority (CWE) 02322

FIXME

SHP-7: Shipment Confidentiality (CWE) 02323

FIXME

SHP-8: Number of Packages in Shipment (NM) 02324

FIXME

SHP-9: Shipment Condition (CWE) 02325

FIXME

SHP-10: Shipment Handling Code (CWE) 02326

FIXME

SHP-11: Shipment Risk Code (CWE) 02327

FIXME

SHP-12: Action Code (ID) 00816

FIXME

PAC - Shipment Package Segment

The intent of this segment is to describe the information associated with the shipping package specimens are sent in.

HL7 Attribute Table - PAC - Shipment Package Segment
Seq# Data Element Name DataType Usage Vocabulary Cardinality Item # Length C.LEN Flags
PAC
1 Set Id – PAC SI R
[1..1] 02350 [1..4]
2 Package ID EI C
[0..1] 02351
3 Parent Package ID EI O
[0..1] 02352
4 Position in Parent Package NA O
[0..1] 02353
5 Package Type CWE R
0908 Package Type
[1..1] 02354
6 Package Condition CWE O
0544(S) Container Condition(Suggested)
[0..*] 02355
7 Package Handling Code CWE O
0376(S) Special Handling Code(Suggested)
[0..*] 02356
8 Package Risk Code CWE O
0489 Risk Codes
[0..*] 02357
9 Action Code ID O
0206(R) Segment Action Code(Required)
[0..1] 00816 [2..2]

PAC-1: Set Id – PAC (SI) 02350

FIXME

PAC-2: Package ID (EI) 02351

FIXME

PAC-3: Parent Package ID (EI) 02352

FIXME

PAC-4: Position in Parent Package (NA) 02353

FIXME

PAC-5: Package Type (CWE) 02354

FIXME

PAC-6: Package Condition (CWE) 02355

FIXME

PAC-7: Package Handling Code (CWE) 02356

FIXME

PAC-8: Package Risk Code (CWE) 02357

FIXME

PAC-9: Action Code (ID) 00816

FIXME

TABLES LISTINGS

Common ISO Derived Units & ISO+ Extensions

Figure 7-10. Common ISO derived units and ISO+ extensions

Code/Abbr.

Name

/(arb_u)

*1 / arbitrary unit

/iu

*1 / international unit

/kg

*1 / kilogram

/L

1 / liter

1/mL

*1 / milliliter

10.L/min

*10 x liter / minute

10.L /(min.m2)

*10 x (liter / minute) / meter2 = liter / (minute  meter2)

10*3/mm3

*103 / cubic millimeter (e.g., white blood cell count)

10*3/L

*103 / Liter

10*3/mL

*103 / milliliter

10*6/mm3

*106 / millimeter3

10*6/L

*106 / Liter

10*6/mL

*106 / milliliter

10*9/mm3

*109 / millimeter3

10*9/L

*109 / Liter

10*9/mL

*109 / milliliter

10*12/L

*1012 / Liter

10*3(rbc)

*1000 red blood cells†

a/m

Ampere per meter

(arb_u)

*Arbitrary unit

bar

Bar (pressure; 1 bar = 100 kilopascals)

/min

Beats or Other Events Per Minute

bq

Becquerel

(bdsk_u)

*Bodansky Units

(bsa)

*Body surface area

(cal)

*Calorie

1

*Catalytic Fraction

/L

Cells / Liter

cm

Centimeter

cm_h20

* Centimeters of water =H20 (pressure)

cm_h20.s/L

Centimeters H20 / (liter / second) = (centimeters H20  second) / liter (e.g., mean pulmonary resistance)

cm_h20/(s.m)

(Centimeters H20 / second) / meter = centimeters H20 / (second  meter) (e.g., pulmonary pressure time product)

(cfu)

*Colony Forming Units

m3/s

Cubic meter per second

d

Day    

db

Decibels

dba

*Decibels a Scale

cel

Degrees Celsius

deg

Degrees of Angle

(drop)

Drop

10.un.s/cm5

Dyne  Second / centimeter5 (1 dyne = 10 micronewton = 10 un) (e.g., systemic vascular resistance)

10.un.s/(cm5.m2)

((Dyne  second) / centimeter5) / meter2 = (Dyne  second) / (centimeter5  meter2) (1 dyne = 10 micronewton = 10 un) (e.g., systemic vascular resistance/body surface area)

ev

Electron volts (1 electron volt = 160.217 zeptojoules)

eq

Equivalent

f

Farad (capacitance)

fg

Femtogram

fL

Femtoliter

fmol

Femtomole

/mL

*Fibers / milliliter

g

Gram

g/d

*Gram / Day

g/dL

Gram / Deciliter

g/hr

Gram / Hour

g/(8.hr)

*Gram / 8 Hour Shift

g/kg

Gram / Kilogram (e.g., mass dose of medication per body weight)

g/(kg.d)

(Gram / Kilogram) / Day = gram / (kilogram  day) (e.g., mass dose of medication per body weight per day)

g/(kg.hr)

(Gram / Kilogram) / Hour = gram / (kilogram  hour) (e.g., mass dose of medication per body weight per hour)

g/(8.kg.hr)

(Gram / Kilogram) /8 Hour Shift = gram / (kilogram  8 hour shift) (e.g., mass dose of medication per body weight per 8 hour shift)

g/(kg.min)

(Gram / Kilogram) / Minute = gram / (kilogram  minute) (e.g., mass dose of medication per body weight per minute)

g/L

Gram / Liter

g/m2

Gram / Meter2 (e.g., mass does of medication per body surface area)

g/min

Gram / Minute

g.m/(hb)

Gram  meter / heart beat (e.g., ventricular stroke work)

g.m/((hb).m2)

(Gram  meter/ heartbeat) / meter2 = (gram  meter) / (heartbeat  meter2)

(e.g., ventricular stroke work/body surface area, ventricular stroke work index)

g(creat)

*Gram creatinine

g(hgb)

*Gram hemoglobin

g.m

Gram meter

g(tot_nit)

*Gram total nitrogen

g(tot_prot)

*Gram total protein

g(wet_tis)

*Gram wet weight tissue

gy

Grey (absorbed radiation dose)

hL

Hectaliter = 102 liter

h

Henry

in

Inches

in_hg

Inches of Mercury (=Hg)

iu

*International Unit

iu/d

*International Unit / Day

iu/hr

*International Unit / Hour

iu/kg

International Unit / Kilogram

iu/L

*International Unit / Liter

iu/mL

*International Unit / Milliliter

iu/min

*International Unit / Minute

j/L

Joule/liter (e.g., work of breathing)

kat

*Katal

kat/kg

*Katal / Kilogram

kat/L

*Katal / Liter

k/watt

Kelvin per watt

(kcal)

Kilocalorie (1 kcal = 6.693 kilojoule)

(kcal)/d

*Kilocalorie / Day

(kcal)/hr

*Kilocalorie / Hour

(kcal)/(8.hr)

*Kilocalorie / 8 Hours Shift

kg

Kilogram

kg(body_wt)

* kilogram body weight

kg/m3

Kilogram per cubic meter

kh/h

Kilogram per hour

kg/L

Kilogram / liter

kg/min

Kilogram per minute

kg/mol

Kilogram / mole

kg/s

Kilogram / second

kg/(s.m2)

(Kilogram / second)/ meter2 = kilogram / (second  meter2)

kg/ms

Kilogram per square meter

kg.m/s

Kilogram meter per second

kpa

Kilopascal (1 mmHg = 0.1333 kilopascals)

ks

Kilosecond

(ka_u)

King-Armstrong Unit

(knk_u)

*Kunkel Units

L

Liter

L/d

*Liter / Day

L/hr

Liter / hour

L/(8.hr)

*Liter / 8 hour shift

L/kg

Liter / kilogram

L/min

Liter / minute

L/(min.m2)

(Liter / minute) / meter2 = liter / (minute  meter2)

(e.g., cardiac output/body surface area = cardiac index)

L/s

Liter / second (e.g., peak expiratory flow)

L.s

Liter / second / second2 = liter  second

lm

Lumen

lm/m2

Lumen / Meter2

(mclg_u)

*MacLagan Units

mas

Megasecond

m

Meter

m2

Meter2 (e.g., body surface area)

m/s

Meter / Second

m/s2

Meter / Second2

ueq

*Microequivalents

ug

Microgram

ug/d

Microgram / Day

ug/dL

Microgram / Deciliter

ug/g

Microgram / Gram

ug/hr

*Microgram / Hour

ug(8hr)

Microgram / 8 Hour Shift

ug/kg

Microgram / Kilogram

ug/(kg.d)

(Microgram / Kilogram) /Day = microgram / (kilogram  day) (e.g., mass dose of medication per patient body weight per day)

ug/(kg.hr)

(Microgram / Kilogram) / Hour = microgram / (kilogram  hours) (e.g., mass dose of medication per patient body weight per hour)

ug/(8.hr.kg)

(Microgram / Kilogram) / 8 hour shift = microgram / (kilogram  8 hour shift)

(e.g., mass dose of medication per patient body weight per 8 hour shift)

ug/(kg.min)

(Microgram / Kilogram) / Minute = microgram / (kilogram  minute)

(e.g., mass dose of medication per patient body weight per minute)

ug/L

Microgram / Liter

ug/m2

Microgram / Meter2 (e.g., mass dose of medication per patient body surface area)

ug/min

Microgram / Minute

uiu

*Micro international unit

ukat

*Microkatel

um

Micrometer (Micron)

umol

Micromole

umol/d

Micromole / Day

umol/L

Micromole / Liter

umol/min

Micromole / Minute

us

Microsecond

uv

Microvolt

mbar

Millibar (1 millibar = 100 pascals)

mbar.s/L

Millibar / (liter / second) =(millibar  second) / liter (e.g., expiratory resistance)

meq

*Milliequivalent

meq/d

*Milliequivalent / Day

meq/hr

*Milliequivalent / Hour

meq/(8.hr)

Milliequivalent / 8 Hour Shift

meq/kg

Milliequivalent / Kilogram (e.g., dose of medication in milliequivalents per patient body weight)

meq/(kg.d)

(Milliequivalents / Kilogram) / Day = milliequivalents / (kilogram  day) (e.g., dose of medication in milliequivalents per patient body weight per day)

meq/(kg.hr)

(Milliequivalents / Kilogram) / Hour = milliequivalents / (kilogram  hour) (e.g., dose of medication in milliequivalents per patient body weight per hour)

meq/(8.hr.kg)

(Milliequivalents / Kilogram) / 8 Hour Shift = milliequivalents / (kilogram  8 hour shift) (e.g., dose of medication in milliequivalents per patient body weight per 8 hour shift)

meq/(kg.min)

(Milliequivalents / Kilogram) / Minute = milliequivalents / (kilogram  minute) (e.g., dose of medication in milliequivalents per patient body weight per minute)

meq/L

Milliequivalent / Liter

Milliequivalent / Meter2 (e.g., dose of medication in milliequivalents per patient body surface area)

meq/min

Milliequivalent / Minute

mg

Milligram

mg/m3

Milligram / Meter3

mg/d

Milligram / Day

mg/dL

Milligram / Deciliter

mg/hr

Milligram / Hour

mg/(8.hr)

Milligram / 8 Hour shift

mg/kg

Milligram / Kilogram

mg/(kg.d)

(Milligram / Kilogram) / Day = milligram / (kilogram  day) (e.g., mass dose of medication per patient body weight per day)

mg/(kg.hr)

(Milligram / Kilogram) / Hour = milligram/ (kilogram  hour) (e.g., mass dose of medication per patient body weight per hour)

mg/(8.hr.kg)

(Milligram / Kilogram) /8 Hour Shift = milligram / (kilogram  8 hour shift) (e.g., mass dose of medication per patient body weight per 8 hour shift)

mg/(kg.min)

(Milligram / Kilogram) / Minute = milligram / (kilogram  minute) (e.g., mass dose of medication per patient body weight per hour)

mg/L

Milligram / Liter

mg/m2

Milligram / Meter2 (e.g., mass dose of medication per patient body surface area)

mg/min

Milligram / Minute

mL

Milliliter

mL/cm_h20

Milliliter / Centimeters of Water (H20) (e.g., dynamic lung compliance)

mL/d

*Milliliter / Day

mL/(hb)

Milliliter / Heart Beat (e.g., stroke volume)

mL/((hb).m2)

(Milliliter / Heart Beat) / Meter2 = Milliliter / (Heart Beat  Meter2) (e.g., ventricular stroke volume index)

mL/hr

*Milliliter / Hour

mL/(8.hr)

*Milliliter / 8 Hour Shift

mL/kg

Milliliter / Kilogram (e.g., volume dose of medication or treatment per patient body weight)

mL/(kg.d)

(Milliliter / Kilogram) / Day = milliliter / (kilogram  day) (e.g., volume dose of medication or treatment per patient body weight per day)

mL/(kg.hr)

(Milliliter / Kilogram) / Hour = milliliter / (kilogram  hour) (e.g., volume dose of medication or treatment per patient body weight per hour)

mL/(8.hr.kg)

(Milliliter / Kilogram) / 8 Hour Shift = milliliter / (kilogram  8 hour shift) (e.g., volume dose of medication or treatment per body weight per 8 hour shift)

mL/(kg.min)

(Milliliter / Kilogram) / Minute = milliliter / (kilogram  minute) (e.g., volume dose of medication or treatment per patient body weight per minute)

mL/m2

Milliliter / Meter2 (e.g., volume of medication or other treatment per patient body surface area)

mL/mbar

Milliliter / Millibar (e.g., dynamic lung compliance)

mL/min

Milliliter / Minute

mL/(min.m2)

(Milliliter / Minute) / Meter2 = milliliter / (minute  meter2) (e.g., milliliters of prescribed infusion per body surface area; oxygen consumption index)

mL/s

Milliliter / Second

mm

Millimeter

mm(hg)

*Millimeter (HG) (1 mm Hg = 133.322 kilopascals)

mm/hr

Millimeter/ Hour

mmol/kg

Millimole / Kilogram (e.g., molar dose of medication per patient body weight)

mmol/(kg.d)

(Millimole / Kilogram) / Day = millimole / (kilogram  day) (e.g., molar dose of medication per patient body weight per day)

mmol/(kg.hr)

(Millimole / Kilogram) / Hour = millimole / (kilogram  hour) (e.g., molar dose of medication per patient body weight per hour)

mmol/(8.hr.kg)

(Millimole / Kilogram) / 8 Hour Shift = millimole / (kilogram  8 hour shift) (e.g., molar dose of medication per patient body weight per 8 hour shift)

mmol/(kg.min)

(Millimole / Kilogram) / Minute = millimole / (kilogram  minute) (e.g., molar dose of medication per patient body weight per minute)

mmol/L

Millimole / Liter

mmol/hr

Millimole / Hour

mmol/(8hr)

Millimole / 8 Hour Shift

mmol/min

Millimole / Minute

mmol/m2

Millimole / Meter2 (e.g., molar dose of medication per patient body surface area)

mosm/L

*Milliosmole / Liter

ms

Milliseconds

mv

Millivolts

miu/mL

*Milliunit / Milliliter

mol/m3

Mole per cubic meter

mol/kg

Mole / Kilogram

mol/(kg.s)

(Mole / Kilogram) / Second = mole / (kilogram  second)

mol/L

Mole / Liter

mol/s

Mole / Second

ng

Nanogram

ng/d

Nanogram / Day

ng/hr

*Nanogram / Hour

ng/(8.hr)

Nanogram / 8 Hour shift

ng/L

Nanogram / Liter

ng/kg

Nanogram / Kilogram (e.g., mass dose of medication per patient body weight)

ng/(kg.d)

(Nanogram / Kilogram) / Day = nanogram / (kilogram  day) (e.g., mass dose of medication per patient body weight per day)

ng/(kg.hr)

(Nanogram / Kilogram) / Hour = nanogram / (kilogram  hour) (e.g., mass dose of medication per patient body weight per hour)

ng/(8.hr.kg)

(Nanogram / Kilogram) / 8 Hour Shift = nanogram / (kilogram  8 hour shift) (e.g., mass dose of medication per patient body weight per 8 hour shift)

ng/(kg.min)

(Nanogram / Kilogram) / Minute = nanogram / (kilogram  minute) (e.g., mass dose of medication per patient body weight per minute)

ng/m2

Nanogram / Meter2 (e.g., mass dose of medication per patient body surface area)

ng/mL

Nanogram / Milliliter

ng/min

*Nanogram / Minute

ng/s

*Nanogram / Second

nkat

*Nanokatel

nm

Nanometer

nmol/s

Nanomole / Second

ns

Nanosecond

n

Newton (force)

n.s

Newton second

(od)

*O.D. (optical density)

ohm

Ohm (electrical resistance)

ohm.m

Ohm meter

osmol

Osmole

osmol/kg

Osmole per kilogram

osmol/L

Osmole per liter

/m3

*Particles / Meter3

/L

*Particles / Liter

/(tot)

*Particles / Total Count

(ppb)

*Parts Per Billion

(ppm)

*Parts Per Million

(ppth)

Parts per thousand

(ppt)

Parts per trillion (10^12)

pal

Pascal (pressure)

/(hpf)

*Per High Power Field

(ph)

*pH

pa

Picoampere

pg

Picogram

pg/L

Picogram / Liter

pg/mL

Picogram / Milliliter

pkat

*Picokatel

pm

Picometer

pmol

*Picomole

ps

Picosecond

pt

Picotesla

(pu)

*P.U.

%

Percent

dm2/s2

Rem (roentgen equivalent man) = 10-2 meter2 / second2 = decimeter2 / second2 Dose of ionizing radiation equivalent to 1 rad of x-ray or gamma ray) [From Dorland's Medical Dictionary]

sec

Seconds of arc

sie

Siemens (electrical conductance)

sv

Sievert

m2/s

Square meter / second

cm2/s

Square centimeter / second

t

Tesla (magnetic flux density)

(td_u)

Todd Unit

v

Volt (electric potential difference)

1

Volume Fraction

wb

Weber (magnetic flux)

*Starred items are not genuine ISO, but do not conflict.

†This approach to units is discouraged by IUPAC. We leave them solely for backward compatibility


External Units of Measure Examples

Figure 7-11. ISO single case units abbreviations

Units

Abbreviation

Units

Abbreviation

Units

Abbreviation

Base units code/abbreviations

Ampere

a

kelvin

K

meter

m

Candela

cd

Kilogram

Kg

mole

mol

second

s

Derived units with specified name and abbreviation

coulomb

c

hour

Hr

pascal

pal

day

d

joule

J

volt

v

degree Celsius

cel

minute (ti)

Min

watt

w

farad

f

newton

N

weber

wb

hertz

hz

ohm

Ohm

year

ann

Other units

atomic mass unit

u

grey

gy

minute of arc

mnt

Bel

b

henry

h

radian

rad

Decibel

db

liter

l

siemens

sie

Degree

deg

lumen

Lm

steradian

sr

Gram

g

lux

Lx

tesla

t

See ISO 2955-1983 for full set


Figure 7-12. ANSI+ unit codes for some U.S. customary units

Units

Abbreviation

Units

Abbreviation

Units

Abbreviation

LENGTH

VOLUME

TIME

Inch

In

cubic foot

Cft

Year

yr

Foot

Ft

cubic inch

Cin

Month

mo

Mile (statute)

Mi

cubic yard

Cyd

Week

wk

nautical mile

Nmi

tablespoon

Tbs

Day

d

Rod

Rod

teaspoon

Tsp

Hour

hr

Yard

Yd

pint

Pt

minute

min

quart

Qt

second

sec

gallon

Gal

ounce (fluid)

Foz

AREA

MASS

square foot

Sqf

dram

Dr

square inch

Sin

grain

gr (avoir)

square yard

Syd

ounce (weight)

Oz

pound

Lb

Other ANSI units, derived units, and miscellaneous

**British thermal unit

Btu

**degrees Fahrenheit

Degf

**millirad

mrad

cubic feet/minute

cft/min

**feet/minute

ft/min

**RAD

rad

Note:    The abbreviations for conventional U.S. units of time are the same as ISO, except for year. ISO = ANN, AMSI = yr. The metric units in X3.50 are the same as ISO, except for: pascal ("pa" in ANSI, "pal" in ISO); ANSI uses "min" for both time and arc while ISO uses "mnt" for minutes of arc; and in ISA seconds are abbreviated "s", in ANSI, "sec".

Caution: Because the ANS+ specification includes both ISO and US customary units, as well as miscellaneous non-metric units, some of the abbreviations are ambiguous. Although there should be little confusion, in the context of a particular observation, this ambiguity is a good reason for a voiding ANS+ unit codes when possible.

This list is not exhaustive. Refer to ANSI X3.50-1986, Table 1, for other metric and standard U.S. units.

**Non-metric units not explicitly listed in ANSI


The ISO abbreviations for multiplier prefixes are given in Figure 7-13. Prefixes ranging from 10-24 (1/billion billionth) to 1024 (a billion billion) are available. The single case abbreviation for kilo (x1000) is k. A unit consisting of 1000 seconds would be abbreviated as ks, 1000 grams as kg, 1000 meters as km, and so on. Some prefixes share the abbreviation of a base unit. Farad and femto, for example, (10-18) both have the abbreviation of f. To avoid confusion, ISO forbids the use of solitary prefixes. It also deprecates the use of two prefixes in one complex unit. Thus, f always means farad, ff would mean 1 million billionth of a farad. Compound prefixes are not allowed.

A unit can be raised to an exponential power. Positive exponents are represented by a number immediately following a unit's abbreviation, i.e., a square meter would be denoted by m2. Negative exponents are signified by a negative number following the base unit, e.g., 1/m2 would be represented as m-2. Fractional exponents are expressed by a numeric fraction in parentheses: the square root of a meter would be expressed as m(1/2). The multiplication of units is signified by a period (.) between the units, e.g., meters X seconds would be denoted m.s. Notice that spaces are not permitted. Division is signified by a slash (/) between two units, e.g. meters per second would be denoted as m/s. Algebraic combinations of ISO unit abbreviations constructed by dividing, multiplying, or exponentiating base ISO units, are also valid ISO abbreviations units. Exponentiation has precedence over multiplication or division. For example, microvolts squared per hertz (a unit of spectral power) would be denoted uv2/hz and evaluated as uv 2/hz while microvolts per square root of hertz (a unit of spectral amplitude) would be denoted uv/hz(1/2) and evaluated as uv/hz½. If more than one division operator is included in the expression the associations should be parenthesized to avoid any ambiguity, but the best approach is to convert a/(b/c) to a.c/b or a.c.b-1 to simplify the expression.

Figure 7-13. Single case ISO abbreviations for multiplier prefixes

Prefix

Code

Prefix

Code

yotta*

1024

ya

yocto

10-24

Y

zetta*

1021

za

zepto

10-21

Z

exa

1018

ex

atto

10-18

A

peta

1015

pe

femto

10-15

F

tera

1012

t

pico

10-12

p

giga

109

g

nano

10-9

n

mega

106

ma

micro

10-6

u

kilo

103

k

milli

10-3

m

hecto

102

h

centi

10-2

c

deca

101

da

deci

10-1

d

*These abbreviations are not defined in the ISO specification for single case abbreviations.


Figure 7-9 lists the abbreviations for common ISO derived units. It also includes standard unit abbreviations for common units, e.g., Milliequivalents, and international units, mm(Hg), and for counting per which we denote by a division sign, a denominator, but no numerator, e.g., /c, that are not part of the above referenced ISO standards. We have extended the units table to better accommodate drug routes and physiologic measures, and otherwise fill in gaps in v2.2.

We have generally followed the IUPAC 1995 Silver Book2 in the definitions of units. However, IUPAC specifies standards for reporting or displaying units and employs 8-bit data sets to distinguish them. This Standard is concerned with the transmission of patient information. Therefore, we have restricted ourselves to case insensitive alphabetic characters and a few special characters (e.g., ".", "./", "(", ")", "*", and "_") to avoid any possible confusion in the transmission. Therefore, we use ISO 2955-1983 (Information processing -- representation of SI and other units in systems with limited character sets) and ANSI X3.50-1986 (Representations for U.S. customary, SI, and other units to be used in systems with limited character sets) case insensitive units abbreviations where they are defined. This means that in some cases, IUPAC abbreviations have different abbreviations in ISO+ even when the IUPAC abbreviations use only standard alphabetic characters. For example, Pascal is abbreviated Pa in IUPAC but PAL in ISO+ (following ISO 2955) because Pa in a case insensitive context also means Picoampere. However, the requirements for transmission do not preclude usage of IUPAC standards for presentation on paper or video display reports to end-users.

All unit abbreviations are case insensitive. One could write milliliters as ML, ml, or mL. In this table we have used lower case for all of the abbreviations except for the letter L which we represent in upper case so that readers will not confuse it with the numeral one (1). This is just a change in presentation, not a change in the Standard. Systems should continue to send the codes as upper or lower case as they always have.

Outstanding Issues

None.