7 Observation Reporting

Chapter Chair/Editor:

Hans Buitendijk Siemens Medical Solutions Health Services Corporation

Chapter Chair/Editor:

Gunther Schadow, MD Regenstrief Institute for Health Care

Chapter Chair/Editor:

Patrick Loyd

Gordon Point Informatics Ltd

Editor

Karen Sieber Cerner Corporation

7.1 CHAPTER 7 CONTENTS

7.2 PURPOSE

This chapter describes the transaction set required for sending structured patient-oriented clinical data from one computer system to another. A common use of these transaction sets will be to transmit observations and results of diagnostic studies from the producing system (e.g., clinical laboratory system, EKG system) (the filler), to the ordering system (e.g., HIS order entry, physician's office system) (the placer). Observations can be sent from producing systems to clinical information systems (not necessarily the order placer) and from such systems to other systems that were not part of the ordering loop, e.g., an office practice system of the referring physician for inpatient test results ordered by an inpatient surgeon. This chapter also provides mechanisms for registering clinical trials and methods for linking orders and results to clinical trials and for reporting experiences with drugs and devices.

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

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

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

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

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

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

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

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

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

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

• History and Physical

• Consultation reports

• Discharge summaries

• Surgical/anatomic pathology reports

• Diagnostic imaging reports

• Cardio-diagnostic reports

• Operative reports

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

Usage Notes:

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

Observations may be transmitted in a solicited (in response to a query) or unsolicited mode. In the solicited mode, a user requests a set of observations according to criteria transmitted by the user. The sending system responds with existing data to satisfy the query (subject to access controls). Queries do not elicit new observations by the target system, they simply retrieve old observations. (See Chapter 5 for full discussion of the query transmission.)

The unsolicited mode is used primarily to transmit the values of new observations. It is the mode used by producing services to return the values of observations requested by an ordering system. A laboratory system, for example, would usually send the results of an AM electrolytes to the ordering HIS via the unsolicited mode. An intensive care system would send the blood pressures to the same HIS by the same mode. Calling such transactions unsolicited may sound like a misnomer, but is not. The placing service solicits the producing service to make the observation. It could also (through a query) solicit the value of that observation after it has been made. However, such an approach would demand continuous polling of the producing system until the result was produced. Using the unsolicited mode, the producing service returns the value of an observation as soon as it is available. The unsolicited mode can also be used to transmit new results to a system (e.g., an archival medical record system) that did not order the observation. The transactions that define these modes are more fully described in Section7.2, �??Trigger Events & Message Definitions.�?�

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

Not all observations are preceded by an order. However, all observations whether explicitly ordered or initiated without an order are reported with an OBR segment as the report header.

The major segments (OBR, OBX) defined in this chapter, their fields, and the code tables have been defined in collaboration with ASTM E31.11 with the goal of keeping HL7 observation transmission the same as ASTM E1238 in pursuit of the goals of ANSI HISPP and the Message Standards Developers Subcommittee. (Some sections of this chapter have been taken with permission directly from the E1238-91 document and vice versa in pursuit of those goals).

The OBR segment provides information that applies to all of the observations that follow. It includes a field that identifies a particular battery (or panel or set) of observations (e.g., electrolytes, vital signs or Admission H&P). For simplicity we will refer to the observation set as the battery. The battery usually corresponds to the entity that is ordered or performed as a unit. (In the case of a query, observation sets may be a more arbitrary collection of observations.) The OBX segment provides information about a single observation, and it includes a field that identifies that single observation (e.g., potassium, diastolic blood pressure or admission diagnosis). Both of these fields assume master tables that define coding systems (the universe of valid identifying codes) for batteries and observations, respectively. These tables will usually be part of the producing and sending services application and (usually) include many other useful pieces of information about the observation or battery. Segments for transmitting such master file information between systems that produce and systems that use clinical information are described in Chapter 8.

This Standard does not require the use of a particular coding system to identify either batteries or single observations In the past, local institutions tended to invent their own unique code systems for identifying test and other clinical observations because standard codes were not available. Such local code systems sufficed for transmitting information within the institutions but presented high barriers to pooling data from many sources for research or for building medical record systems. However, standard code systems such as LOINC® and SNOMED now exist for many of these purposes, and we strongly encourage their use in observation reporting. These codes can be sent either as the only code or they can be sent along with the local historic code as the second code system in a CE code.

In past versions of the HL7 standard, Appendix A to Chapter 7 presented suggestions for constructing clinical codes from existing procedure code systems such as CPT4. Appendix A is now part of the Implementation Guide and contains LOINC® codes for most laboratory tests and many common clinical variables and codes for reporting observations from the laboratory, 12-lead EKG, cardiac echoes, obstetrical ultrasounds, radiology reports, history and physical findings, tumor registries, vital signs, intake and outputs, and more. The most recent version of the LOINC® database, which includes records for more than 26,000 observations and includes codes, names, synonyms and other attributes (such as the molecular weights of chemical moieties) for each observation, is available from the Regenstrief Institute file server at http://www.regenstrief.org/loinc/loinc.htm . Codes for Neurophysiologic variables (EEG, EMG, Evoked potentials) are provided in Appendix X2 of ASTM E1467. Some parts of this document (the discussion and tables defining units, the discussion of the rules of mapping observations to OBX segments, and some of the examples at the end of the chapter have been copied (with permission) from ASTM E1238.

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

7.2.1 Preface (organization of this chapter)

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

7.2.2 Glossary

7.2.2.0

7.2.2.1 Placer:

Person or service that requests (places order for) an observation battery, e.g., the physician, the practice, clinic, or ward service, that orders a lab test, X-ray, vital signs, etc. The meaning is synonymous with, and used interchangeably with, requestor. See ORC-2-placer order number, Section 4.3.1.2, �??Placer order number.�?�

7.2.2.2 Filler:

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

7.2.2.3 Battery:

A set of one or more observations identified as by a single name and code number, and treated as a shorthand unit for ordering or retrieving results of the constituent observations. In keeping with the mathematical conventions about set, a battery can be a single observation. Vital signs, electrolytes, routine admission tests, and obstetrical ultrasound are all examples. Vital signs (conventionally) consist of diastolic and systolic blood pressure, pulse, and respiratory rate. Electrolytes usually consist of Na+, K+, Cl-, and HCO3-. Routine admission tests might contain CBC, Electrolytes, SMA12, and Urinalysis. (Note that the elements of a battery for our purposes may also be batteries). Obstetrical ultrasound is a battery made up of traditional component measurements and the impression, all of which would be returned as separate results when returned to the requestor. A test involving waveform recording (such as an EKG) can be represented as a battery comprised of results of many categories, including digital waveform data, labels and annotations to the data, measurements, and the impression

The word battery is used in this specification synonymously with the word profile or panel. The individual observation elements within a battery may be characteristic of a physiologic system (e.g., liver function tests), or many different physiologic systems.

7.2.2.4 Observation:

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

7.2.2.5 Clinical Document Architecture (CDA):

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

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

We have defined code suffixes for constructing observation IDs for the common components of narrative reports (see Figure 7-1). The observation identifier for each such component is obtained by concatenating the observation battery ID (the ID in OBR-4-universal service ID of the preceding OBR from any coding system) with the appropriate suffix. The observation ID for a chest X-ray impression, for example, would be the chest X-ray observation ID (if CPT4, it would be 71020), a subcomponent delimiter, and the suffix, IMP, i.e., 71020&IMP.

This same combining rule applies to other coding systems including local and universal procedural codes (see Chapter 4). For example, if a local code for EKG was E793, and the locally agreed upon designation for that local code was EKG, the impression would be identified as E793&IMP^^99EKG.

Note: The "99EKG" in the 3rd component is included to indicate a local code. The EKG's description, in this case, would be E793&GDT^^99EKG.

Although it is strongly discouraged, the sender and receiver may agree to allow the omission of the observation ID component of a result segment when it is the same as the observation ID of the preceding OBR. In this case, only the ampersand and the suffix would have to be sent, e.g., &IMP or &REC, in OBX-3-observation identifier of a result segment. The full code would be assumed as the test identifier (recorded in the order segment) plus the category identifier recorded in the observation segment.

Figure 7-1. Observation ID suffixes

The following subsections define each of the suffices except for the specialized waveform suffices, which are defined in Section 7.14.1, Specific Observation Id Suffixes

7.2.4.0

7.2.4.1 Diagnostic impression (IMP)

When the suffix is IMP (OBX-3-observation identifier), the result is a diagnosis or finding, stored as a CE data type. Multiple result segments with an IMP suffix can be used if there are multiple parts to the study and each have an associated diagnosis (for example, the awake and sleep portion of an EEG). Each of these would have a different observation sub-ID. Multiple result segments with an IMP suffix can also be used if there are separate diagnoses corresponding to separate anatomic sites; in this case, the site for each diagnosis (each result segment with an IMP suffix) must be specified by an immediately preceding result segment with a suffix of ANT (see Section 7.2.4.5, �??Anatomic site (ANT)�?�), which also has the same observation sub-ID. When multiple distinct diagnostic impressions are being reported, for example, mitral valve prolapse and aortic stenosis, each distinct impression should be sent in a separate OBX segment. More than one code may be included within one coded result segment, but only when such codes are modifiers of the principal impression, e.g., to report additional detail about the finding, not to report an entirely different finding. In this case, the OBX-5-observation value field may repeat, with each instance or repetition specifying one of the related coded impressions.

The coded data type for impressions does not mean that a reporting service must actually code all such impressions. The diagnostic impression can be sent as dictated text, but the text should be sent in the second component of the CE data type without a code to distinguish it from code, i.e. it should be preceded by a component delimiter, e.g., ^congestive heart failure.

When multiple separate text impressions are being reported, they should be reported in separate OBX segments to indicate that they are distinct impressions.

7.2.4.2 Recommendation (REC)

When the suffix is REC (OBX-3-observation identifier), the value is a CE result, representing the reading physician's recommendations about repeat testing, follow up or therapy. For example, when an ambiguous lesion result is seen on a mammogram, the reading physician might recommend a repeat mammogram in six months, or a needle biopsy immediately. The recommended procedures are recorded as codes and/or text descriptions in the coded identifier structure.

If more than one follow up study is recommended, each such recommendation is sent in a separate REC.

7.2.4.3 Confirming procedures (CNP)

The confirming procedure OBX suffix identifies additional studies used to confirm the diagnosis reported in the IMP OBX. If, for example, electron microscopy was done to confirm a surgical pathology diagnosis, the identifier for electron microscopy OBX-3-observation identifier would be stored as the value field of an observation ID with a confirming procedure suffix. Confirming procedures are most important in surgical pathology reports. But they might also be used by services such as endoscopy, to record the fact that a biopsy, culture, etc., was taken during the procedure. If more than one confirming procedure was used, each is sent in a separate result segment with observation ID suffix CNP.

7.2.4.4 Procedure medication (MED)

A coded result segment with a suffix of MED (OBX-3-observation identifier) indicates that the segment contained information about medication given as part of the procedure -- contrast medication, medication intended to invoke a physiologic response (e.g., to be used in stress testing) or premedication. When patients receive more than one procedure medication, each medication should be reported in a separate OBX medication segment. If the transmitting system has codes available for medications, they would be recorded as the first component of OBX-3-observation identifier. The name and/or the dosages could be included in the second component of OBX-5-observation value.

A coded result segment with a suffix of MED (procedure medication) may also be used to define a medication administered during recording of digital waveform data or other extended diagnostic procedure, e.g., exercise test. These may be displayed by the receiving system overlaid with the other events reported. The procedure medication is assumed to pertain to and be associated with the data recorded at the time specified in OBX-14-date/time of the observation, of the OBX segment labeled with MED, when present.

7.2.4.5 Anatomic site (ANT)

Some diagnostic studies include observations about more than one anatomic site within one report. If, for example, a patient had an appendectomy incidental to gallbladder surgery, the pathologist's assessment of both specimens would usually be included under a single specimen number in one report. Each distinct anatomic site would be reported as a separate OBX segment with a suffix of ANT (OBX-3-observation identifier). More than one coded anatomic location may be included within a single OBX segment only when such additional codes are used to construct an identity for a single site. In this case only, the OBX-5-observation value field may repeat, with each instance or repetition specifying one of the related locations. Each OBX segment with an ANT suffix could be followed by one or more OBX segments with an IMP or other suffix to transmit the diagnostic impression(s) associated with the anatomic site. These impressions or recommendations would be associated with a single anatomic site via a common observation ID.

7.2.4.6 Device/Instrument (DEV)

When required, the instrument or device which generated an observation can be transmitted as an additional result of the study. In this case, the suffix of OBX-3-observation identifier is DEV. Examples include: an automated instrument in the laboratory; an imaging device and model number in radiology; or an automatic blood pressure machine on the ward. The device is specified as a coded entry in anticipation that these identifiers could be specified as codes. Initially, we expect that most of the information about devices will be transmitted as text in the second component of the CE identifier.

7.2.4.7 Serial # device/instrument (SER)

Vendor's serial number of the device which generated the observation.

7.2.4.8 Gross or general description (GDT)

The general description suffix identifies the description component of a diagnostic study. In the case of anatomic pathology, it applies to the macroscopic (gross) description of the specimen. If the description consists of multiple paragraphs, the paragraphs should be separated by repeat delimiters so that the receiving computer can display them as paragraphs. It will not be necessary to include a description segment for a report when the impression segment says it all, e.g., for normal studies or studies such as EKG, whose reports are traditionally terse.

7.2.4.9 Microscopic or Secondary description (MDT)

For most studies, a secondary description will not be needed. In the case of surgical pathology, however, the microscopic description is a separate part of the report. It describes the histology as seen through the microscope. The microscopic description will be sent in a segment with the suffix MDT in OBX-3-observation identifier. If the microscopic description consists of multiple paragraphs, the paragraphs should be separated by repeat delimiters so that the receiving computer can display them as paragraphs.

7.2.4.10 Technician's comment (TCM)

This is free text stored in a result segment whose OBX-3-observation identifier has a suffix of TCM for technician comment. It is used to record information about technical performance of the procedure, usually recorded by the technician.

7.2.4.11 Addendum note (ADT)

Use to report information that is added as an addendum after the original dictation and sent as a separate labeled section of the report.

7.2.4.12 Diagnosis (problem) onset date/time (ITM)

Use to record the date-time that a problem was first perceived to exist.

7.2.4.13 Diagnosis (problem) resolution date/time (RTM)

Use to record the date-time that a problem became inactive, i.e., the problem was cured or remitted.

7.2.4.14 Comparison study (CMS)

When the reader of a diagnostic report compares the results for the current study with those of a previous study, this suffix allows them to report the nature of the comparison study as a separate result, i.e., an OBX segment with a segment whose observation ID has a suffix of CMS. Ordinarily, this would not be required because the observation ID in the other comparison OBXs would identify the test, if any of the other comparison values were transmitted.

7.2.4.15 Comparison date/time (CMT)

When the reader of a diagnostic procedure compares the current results with a previous study, this suffix allows them to report the date-time of the previous study (time optional) as a separate result within the current report.

7.2.4.16 Comparison results (CMR)

When the reader of a diagnostic procedure compares the current results with those of a previous study on the same patient, this suffix allows them to report the results (impression) of the previous study as a discrete result within the current report.

7.2.4.17 Comparison change (CMC)

When a diagnostic service reports a comparison between the current and a previous study, this suffix is used to report the degree of change (e.g., much worse, worse, minimal worsening, no change, slightly better, better, much better, returned to normal) as a separate result within the report.

In current dictation, information about comparison is usually contained in the descriptions of the study. The provision of the comparison suffixes listed above do not imply a requirement to send this information as separate components. The comparison variables are only meant to be enabling. When a system would like to transmit them as discrete report components, these suffixes give them the option.

7.2.4.18 Predicted value (PRD)

When an observation has a predicted value as is the case for many spirometry tests, this suffix identifies the predicted observation as distinguished from the actual observation. The AS4 code for forced vital capacity is 94010.1 (see the HL7 Implementation Guide). The predicted forced vital capacity would be 94010.1&PRD.

7.2.4.19 Percent predicted (PPR)

This is a computed observation = (actual observation)/(predicted observation. For forced vital capacity the percent predicted would be identified as 94010.1&PPR.

7.2.4.20 After drug observed (AFD)

An observation might be taken before and after a drug is given. This occurs especially in Spirometry. The predose observation is identified by the base ID. The post drug measure is identified by the AFD suffix. Using the AS4 base code for the forced vital capacity the post drug result would be identified by 94010.1&AFD.

7.2.4.21 Predicted value after drug (ADP)

The post drug predicted value is identified by the suffix, ADP. Following the pattern of the above example, it would be 94010.1&ADP.

7.2.4.22 Percent predicted after drug (APP)

The percent predicted after drug is identified by applying the suffix, APP to the base code - 94010.1&APP if using the AS4 code for forced vital capacity.

7.2.4.23 Timing information (TIM)

This suffix is used only for transmitting waveform data. It is fully described in Section 7.14.1.1.

7.2.4.24 Channel definition data (CHN)

This suffix is used only for transmitting waveform data. It is fully described in Section 7.14.1.2.

7.2.4.25 Waveform digital data (WAS)

This suffix is used only for transmitting waveform data. It is fully described in Section 7.14.1.3.

7.2.4.26 Waveform annotation (ANO)

This suffix is used only for transmitting waveform data. It is fully described in Section 7.14.1.4

7.2.4.27 Clinical observation codes

The recently introduced LOINC® codes (See Figure 7-2 for full information) may be more useful to many users. Code system information, including LOINC®, has been moved from Appendix 7A to the Implementation Guide.

7.3 GENERAL TRIGGER EVENTS & MESSAGE DEFINITIONS

The triggering events that follow are all served by the ORU (Observational report - Unsolicited) or the ORF (Observational Report Response) messages in combination with ACK and QRY. Each triggering event is listed below, along with the messages exchanged, and the segments that comprise the messages. The notation used to describe the sequence, optionality, and repeating of segments is described in Chapter 2, �??Format for defining abstract messages.�?�

7.3.1 ORU - Unsolicited Observation Message (Event R01)

The ORU message is for transmitting laboratory results 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.

ACK^R01^ACK	Acknowledgment	Status	Chapter	DB Ref.
MSH	Message header		2	DB
[ { SFT } ]	Software segment		2	DB
MSA	Message acknowledgment		2	DB
[ { ERR } ]	Error		2	DB

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.

7.3.2 OUL - Unsolicited Laboratory Observation Message (Event R21)

This message was designed to accommodate laboratory automation systems. It permits the communication of the following kinds of information in addition to the results themselves:

• relation of the analysis results to a particular container with patient sample (SAC segment),

• relation of the analysis results to a particular container with QC sample and the lot and manufacturer information about this sample (SAC-SID segments),

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

If the results are for QC specimen container, then the patient related segments (e.g., PID, PD1, PV1, PV2) are optional.

This message is kept here for backward compatibility reasons only. The new OUL messages with additional triggers should be used, when the Specimen information (segment SPM) with or without Container information (segment SAC) is required.

Refer to Chapter 13 Laboratory Automation for examples of usage.

--- OBSERVATION end

--- ORDER_OBSERVATION end

The query response format options are described in chapter 5, Section 5.2.4 �??Response format�?�.

The QRD segment is defined in Chapter 5 Section 5.10.5.3, �??QRD - original style query definition segment.�?� The Query Result Level field of the QRD determines the amount of data requested.

The QRF segment is defined in Chapter 5, Section 5.10.5.4, �??QRF - original style query filter segment.�?�

The subject filters contained in the QRD and QRF segments are defined by local agreement between the inquiring system and the ancillary system.

The Set ID fields in the various segments (including PID) are used to count the number of segments of one kind transmitted at one level of the hierarchy.

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

ORF^R04^ORF_R04	Observational Report	Status	Chapter	DB Ref.
MSH	Message Header		2	DB
[ { SFT } ]	Software Segment		2	DB
MSA	Message Acknowledgment		2	DB
QRD	Query Definition		2	DB
[ QRF ]	Query Filter		2	DB
{

--- QUERY_RESPONSE begin

--- PATIENT begin

--- PATIENT end

--- ORDER begin

--- TIMING_QTY begin

--- TIMING_QTY end

--- OBSERVATION begin

--- OBSERVATION end

--- ORDER end

--- QUERY_RESPNSE end

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 number in the ORC segment of the OML^O21 message. If desired, this message may also contain information returned from the Observation Recipient, such as the name of the patient corresponding to the order and result placed.

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 logging an exception rather than recording the result.

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

ACK^R31^ACK	Acknowledgment	Status	Chapter	DB Ref.
MSH	Message Acknowledgment		2	DB
[ { SFT } ]	Software segment		2	DB
MSA	Message Acknowledgment		2	DB
[ { ERR } ]	Error		2	DB

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

ACK^R32^ACK	Acknowledgment	Status	Chapter	DB Ref.
MSH	Message Acknowledgment		2	DB
[ { SFT } ]	Software segment		2	DB
MSA	Message Acknowledgment		2	DB
[ { ERR } ]	Error		2	DB

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

--- TIMING_QTY end

--- RESULT begin

--- RESULT end

--- ORDER end

--- SPECIMEN end

• This message was designed to accommodate specimen oriented testing. It should be applicable to, e.g., 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.

--- PATIENT begin

--- PATIENT end

--- VISIT begin

--- VISIT end

--- SPECIMEN begin

--- TIMING_QTY begin

--- TIMING_QTY end

--- RESULT begin

--- RESULT end

--- ORDER end

--- CONTAINER end

--- SPECIMEN end

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

--- PATIENT begin

--- PATIENT end

--- VISIT begin

--- VISIT end

--- TIMING_QTY begin

--- TIMING_QTY end

--- SPECIMEN begin

--- CONTAINER end

--- SPECIMEN end

--- RESULT begin

--- RESULT end

--- ORDER end

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

7.4.1 OBR - Observation Request Segment

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

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

HL7 Attribute Table - OBR - Observation Request

Note: The OBR segment is documented in its entirety in Chapter 4. The segment definition table is included here for reader convenience and for clarity of items related to Observation Reporting messages.

7.4.1.0 OBR field definitions

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

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

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

7.4.1.1 OBR-1 Set ID - OBR (SI) 00237

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

7.4.1.2 OBR-2 Placer Order Number (EI) 00216

Definition: This field is a case of the Entity Identifier data type (Section 2.16.28). The first component is a string that identifies an individual order (e.g., OBR). A limit of fifteen (15) characters is suggested but not required. It is assigned by the place (ordering application). It identifies an order uniquely among all orders from a particular ordering application. The second through fourth components contain the application ID of the placing application in the same form as the HD data type (Section 2.16.36, �??HD - Hierarchic designator�?�). The second component, namespace ID, is a user-defined coded value that will be uniquely associated with an application. A limit of six (6) characters is suggested but not required. A given institution or group of intercommunicating institutions should establish a unique list of applications that may be potential placers and fillers and assign unique application IDs. The components are separated by component delimiters.

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

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

ORC-2-placer order number is the same as OBR-2-placer order number. If the placer order number is not present in the ORC, it must be present in the associated OBR and vice versa. If both fields, ORC-2-placer order number and OBR-2-placer order number, are valued, they must contain the same value. When results are transmitted in an ORU message, an ORC is not required, and the identifying placer order number must be present in the OBR segments.

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

7.4.1.3 OBR-3 Filler Order Number (EI) 00217

Definition: This field is the order number associated with the filling application. This is a permanent identifier for an order and its associated observations. It is a special case of the Entity Identifier data type (Section 2.16.28, �??EI - Entity Identifier�?�).

The first component is a string that identifies an order detail segment (e.g., OBR). A limit of fifteen (15) characters is suggested but not required. It is assigned by the order filler (receiving) application. This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.

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

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

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

ORC-3-filler order number is the same as OBR-3-filler order number. If the filler order number is not present in the ORC, it must be present in the associated OBR. (This rule is the same for other identical fields in the ORC and OBR and promotes upward and ASTM compatibility.) This is particularly important when results are transmitted in an ORU message. In this case, the ORC is not required and the identifying filler order number must be present in the OBR segments.

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

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

7.4.1.4 OBR-4 Universal Service Identifier (CE) 00238

Definition: This field contains the identifier code for the requested observation/test/battery. This can be based on local and/or �??universal�?� codes. We recommend the �??universal�?� procedure identifier. The structure of this CE data type is described in the control section.

7.4.1.5 OBR-5 Priority (ID) 00239

Definition: This field has been retained for backward compatibility only. It is not used. Previously priority (e.g., STAT, ASAP), but that information is carried as the sixth component of OBR-27-quantity/timing.

7.4.1.6 OBR-6 Requested Date/Time (TS) 00240

Definition: This field has been retained for backward compatibility only. This is not used. Previously requested date/time. That information is now carried in the fourth component of the OBR-27-quantity/timing.

7.4.1.7 OBR-7 Observation Date/Time (TS) 00241

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

7.4.1.8 OBR-8 Observation End Date/Time (TS) 00242

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

7.4.1.9 OBR-9 Collection Volume (CQ) 00243

Definition: For laboratory tests, the collection volume is the volume of a specimen. The default unit is ML. Specifically, units should be expressed in the ISO Standard unit abbreviations (ISO-2955, 1977). This is a results-only field except when the placer or a party has already drawn the specimen. (See Chapter 7 Section 7.4.2.6 for a full discussion regarding units.)

7.4.1.10 OBR-10 Collector Identifier (XCN) 00244

Definition: When a specimen is required for the study, this field will identify the person, department, or facility that collected the specimen. Either name or ID code, or both, may be present.

7.4.1.11 OBR-11 Specimen Action Code (ID) 00245

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

7.4.1.12 OBR-12 Danger Code (CE) 00246

Definition: This field is the code and/or text indicating any known or suspected patient or specimen hazards, e.g., patient with active tuberculosis or blood from a hepatitis patient. Either code and/or text may be absent. However, the code is always placed in the first component position and any free text in the second component. Thus, free text without a code must be preceded by a component delimiter.

7.4.1.13 OBR-13 Relevant Clinical Information (ST) 00247

Definition: This field contains any additional clinical information about the patient or specimen. This field is used to report the suspected diagnosis and clinical findings on requests for interpreted diagnostic studies. Examples include reporting the amount of inspired carbon dioxide for blood gasses, the point in the menstrual cycle for cervical pap tests, and other conditions that influence test interpretations. For some orders this information may be sent on a more structured form as a series of OBX segments (see Chapter 7) that immediately follow the order segment.

7.4.1.14 OBR-14 Specimen Received Date/Time (TS) 00248

Definition: This field has been retained for backward compatibility only. As of version 2.5, in messages where the SPM segment is present, the use of SPM-18 Specimen Received Date/Time is favored over this field

For observations requiring a specimen, the specimen received date/time is the actual login time at the diagnostic service. This field must contain a value when the order is accompanied by a specimen, or when the observation required a specimen and the message is a report.

7.4.1.15 OBR-15 Specimen Source (SPS) 00249

Definition: This field has been retained for backward compatibility only. As of version 2.5, in messages where the SPM segment is present, the use of SPM Specimen segment is favored over this field

This field identifies the site where the specimen should be obtained or where the service should be performed.

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

The first component contains the specimen source name or code (as a CWE data type component). (Even in the case of observations whose name implies the source, a source may be required, e.g., blood culture-heart blood.) Refer to HL7 Table 0070 - Specimen Source Codes for valid entries.

The second component should include free text additives to the specimen such as Heparin, EDTA, or Oxlate, when applicable.

The third is a free text component describing the method of collection when that information is a part of the order. When the method of collection is logically an observation result, it should be included as a result segment.

The fourth component specifies the body site from which the specimen was obtained, and the fifth is the site modifier. For example, the site could be antecubital fossa, and the site modifier "right." The components of the CWE fields become subcomponents. Refer to User-Defined Table 0163 - Body Site for valid entries.

The sixth component indicates whether the specimen is frozen as part of the collection method. Suggested values are F (Frozen); R (Refrigerated). If the component is blank, the specimen is assumed to be at room temperature.

Refer to HL7 Table 0070 Specimen Source Codes for valid values.

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

7.4.1.16 OBR-16 Ordering Provider (XCN) 00226

Definition: This field identifies the provider who ordered the test. Either the ID code or the name, or both, may be present. This is the same as ORC-12-Ordering provider.

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

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

7.4.1.18 OBR-18 Placer Field 1 (ST) 00251

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

7.4.1.19 OBR-19 Placer Field 2 (ST) 00252

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

7.4.1.20 OBR-20 Filler Field 1 (ST) 00253

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

7.4.1.21 OBR-21 Filler Field 2 (ST) 00254

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

7.4.1.22 OBR-22 Results Rpt/Status Chng - Date/Time (TS) 00255

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

7.4.1.23 OBR-23 Charge to Practice (MOC) 00256

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

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

Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to Chapter 4, Section 4.5.3.24, HL7 Table 0074 - Diagnostic service section ID for valid entries.

7.4.1.25 OBR-25 Result Status (ID) 00258

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

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

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

7.4.1.26 OBR-26 Parent Result (PRL) 00259

Definition: This field is defined to make it available for other types of linkages (e.g., toxicology). This important information, together with the information in OBR-29-parent, uniquely identifies the parent result's OBX segment related to this order. The value of this OBX segment in the parent result is the organism or chemical species about which this battery reports. For example, if the current battery is an antimicrobial susceptibility, the parent result's identified OBX contains a result which identifies the organism on which the susceptibility were run. This indirect linkage is preferred because the name of the organism in the parent result may undergo several preliminary values prior to finalization.

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

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

This field is present only when the parent result is identified by OBR-29-parent and the parent spawn child orders for each of many results. (See Chapter 7 for more details about this linkage.)

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

7.4.1.27 OBR-27 Quantity/Timing (TQ) 00221

Definition: This field is retained for backward compatibility only. The reader is referred to the TQ1 and TQ2 segments described in sections 4.5.4 and 4.5.5 respectively.

This field contains information about how many services to perform at one service time and how often the service times are repeated, and to fix duration of the request.

7.4.1.28 OBR-28 Result Copies To (XCN) 00260

Definition: This field is the people who are to receive copies of the results. By local convention, either the ID number or the name may be absent.

7.4.1.29 OBR-29 Parent (EIP) 00261

Definition: This field is identical to ORC-8-parent. This field relates a child to its parent when a parent/child relationship exists. For example, observations that are spawned by previous observations, e.g., antimicrobial susceptibilities spawned by blood cultures, need to record the parent (blood culture) filler order number here. The parent/child mechanism is described under the order control field notes (see Segment ORC field notes in Section 4.3.1.1.1, �??Table notes for order control codes of ORC.�?� It is required when the order is a child.

7.4.1.30 OBR-30 Transportation Mode (ID) 00262

Definition: This field identifies how (or whether) to transport a patient, when applicable. Refer to Section 4.5.3.30, HL7 Table 0124 - Transportation mode for valid codes.

7.4.1.31 OBR-31 Reason for Study (CE) 00263

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

7.4.1.32 OBR-32 Principal Result Interpreter (NDL) 00264

Definition: This field identifies the physician or other clinician who interpreted the observation and is responsible for the report content.

7.4.1.33 OBR-33 Assistant Result Interpreter (NDL) 00265

Definition: This field identifies the clinical observer who assisted with the interpretation of this study.

7.4.1.34 OBR-34 Technician (NDL) 00266

Definition: This field identifies the performing technician.

7.4.1.35 OBR-35 Transcriptionist (NDL) 00267

Definition: This field identifies the report transcriber.

7.4.1.36 OBR-36 Scheduled - Date/Time (TS) 00268

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

7.4.1.37 OBR-37 Number of Sample Containers (NM) 01028

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

7.4.1.38 OBR-38 Transport Logistics of Collected Sample (CE) 01029

Definition: This field is the means by which a sample reaches the diagnostic service provider. This information is to aid the lab in scheduling or interpretation of results. Possible answers: routine transport van, public postal service, etc. If coded, requires a user-defined table.

7.4.1.39 OBR-39 Collector's Comment (CE) 01030

Definition: This field is for reporting additional comments related to the sample. If coded, requires a user-defined table. If only free text is reported, it is placed in the second component with a null in the first component, e.g., ^difficult clotting after venipuncture and ecchymosis.

7.4.1.40 OBR-40 Transport Arrangement Responsibility (CE) 01031

Definition: This field is an indicator of who is responsible for arranging transport to the planned diagnostic service. Examples: Requester, Provider, Patient. If coded, requires a user-defined table.

7.4.1.41 OBR-41 Transport Arranged (ID) 01032

Definition: This field is an indicator of whether transport arrangements are known to have been made. Refer to Section 4.5.3.41 HL7 Table 0224 - Transport arranged for valid codes.

7.4.1.42 OBR-42 Escort Required (ID) 01033

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

7.4.1.43 OBR-43 Planned Patient Transport Comment (CE) 01034

Definition: This field is the code or free text comments on special requirements for the transport of the patient to the diagnostic service department. If coded, requires a user-defined table.

7.4.1.44 OBR-44 Procedure Code (CE) 00393

Definition: This field contains a unique identifier assigned to the procedure, if any, associated with the charge. Refer to User-defined Table 0088 - Procedure code for suggested values. This field is a CE data type for compatibility with clinical and ancillary systems.

7.4.1.45 OBR-45 Procedure Code Modifier (CE) 01316

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

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

7.4.1.46 OBR-46 Placer Supplemental Service Information (CE) 01474

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

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

7.4.1.47 OBR-47 Filler Supplemental Service Information (CE) 01475

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

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

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

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

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

Refer to User-defined table 0476 in Chapter 4, Section 4.5.3.48 for suggested values.

7.4.1.49 OBR-49 Result Handling (IS) 01647

Definition: Transmits information regarding the handling of the result. For example, an order may specify that the result (e.g., an x-ray film) should be given to the patient for return to the requestor. Refer to User-defined table 0507 Observation Result Handling in Chapter 4, Section 4.5.3.49 for suggested values. If this field is not populated then routine handling is implied.

7.4.1.50 OBR-50 Parent Universal Service Identifier (CWE) 02286

Definition: This field contains the identifier code for the parent order, as identified in ORC-8 Parent and/or OBR-29 Parent (if present), which caused this observation/test/battery to be performed. This can be based on local and/or �??universal�?� codes. HL7 recommends the �??universal�?� service identifier."

Note that ORC-8 Parent and/or OBR-29 Parent, does not have to be present for OBR-50 to be used.  However, absence of ORC-8 Parent and/or OBR-29 Parent introduces potential ambiguity of the actual order being referenced.

Note that ORC-8 Parent and OBR-29 Parent identify an individual parent order (e.g., OBR) for ORC-31 Parent Universal Service Identifier and OBR-50 Parent Universal Service Identifier.

ORC-31 - parent universal service identifier is the same as OBR-50 - parent universal service identifier.  If both fields are valued, they must contain the same value.

Note that OBR-50 will be deprecated in V2.7 to enable message developers to start to adjust and be prepared for supporting the intended 1:1 relationship between Placer/Filler Order Number and Universal Service Identifier.

7.4.2 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 Section 4.4, �??Order 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 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

7.4.2.1 OBX-1 Set ID - OBX (SI) 00569

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

7.4.2.2 OBX-2 Value Type (ID) 00570

Definition: This field contains the format of the observation value in OBX. It must be valued if OBX-11-Observ result status is not valued with an �??X�?�. If the value is CE then the result must be a coded entry. When the value type is TX or FT then the results are bulk text. The valid values for the value type of an observation are listed in HL7 Table 0125 - Value Type.

The observation value must be represented according to the format for the data type defined in Chapter 2, Section 2.9, �??Data Types.�?� For example, a PN consists of 6 components, separated by component delimiters.

Although NM is a valid type, observations which are usually reported as numbers will sometimes have the string (ST) data type because non-numeric characters are often reported as part of the result, e.g., >300 to indicate the result was off-scale for the instrument. In the example, ">300", ">" is a symbol and the digits are considered a numeric value. However, this usage of the ST type should be discouraged since the SN (structured numeric) data type now accommodates such reporting and, in addition, permits the receiving system to interpret the magnitude.

All HL7 data types are valid, and are included in Table 0125 except CM, CQ, SI, and ID. For a CM definition to have meaning, the specifics about the CM must be included in the field definition. OBX-5-observation value is a general field definition that is influenced by the data type OBX-3, so CMs are undefined in this context. CQ is invalid because units for OBX-5-observation value are always specified explicitly in an OBX segment with OBX-6 units. SI is invalid because it only applied to HL7 message segments, and ID because it requires a constant field definition.

The RP value (reference pointer) must be used if the actual observation value is not sent in OBX but exists somewhere else. For example, if the observation consists of an image (document or medical), the image itself cannot be sent in OBX. The sending system may in that case opt to send a reference pointer. The receiving system can use this reference pointer whenever it needs access to the actual image through other interface standards, e.g., DICOM, or through appropriate data base servers.

HL7 Table 0125 - Value type

The full definition of these data types is given in Chapter 2, Section 2.9, �??Data Types.�?� The structured numeric (SN) data type, new to version 2.3, provides for reporting ranges (e.g., 3-5 or 10-20), titres (e.g., 1:10), and out-of-range indicators (e.g., >50) in a structured and computer interpretable way.

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

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

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

7.4.2.3 OBX-3 Observation Identifier (CE) 00571

Definition: This field contains a unique identifier for the observation. The format is that of the Coded Element (CE). Example: 8625-6^P-R interval^LN.

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

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

For a discussion of the use of suffixes as related to narrative reports see Section 7.2.3 and Section 7.2.4.

7.4.2.4 OBX-4 Observation Sub-ID (ST) 00572

Definition: This field is used to distinguish between multiple OBX segments with the same observation ID organized under one OBR. For example, a chest X-ray report might include three separate diagnostic impressions. The standard requires three OBX segments, one for each impression. By putting a 1 in the Sub-ID of the first of these OBX segments, 2 in the second, and 3 in the third, we can uniquely identify each OBX segment for editing or replacement.

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

Figure 7-2. Example of sub-identifier usage

OBR|1||1234^LAB|88304&SURG PATH REPORT|...<cr>

OBX|1|CE|88304&ANT|1|T57000^GALLBLADDER^SNM|...<cr>

OBX|2|TX|88304&GDT|1|THIS IS A NORMAL GALLBLADDER|...<cr>

OBX|3|TX|88304&MDT|1|MICROSCOPIC EXAM SHOWS HISTOLOGICALLY

NORMAL GALLBLADDER TISSUE|...<cr>

OBX|4|CE|88304&IMP|1|M-00100^NML^SNM|...<cr>

OBX|5|CE|88304&ANT|2|T66000^APPENDIX^SNM|...<cr>

OBX|6|TX|88304&GDT|2|THIS IS A RED, INFLAMED, SWOLLEN, BOGGY APPENDIX|...<cr>

OBX|7|TX|88304&MDT|2|INFILTRATION WITH MANY PMN's - INDICATING INFLAMATORY CHANGE|...<cr>

OBX|8|CE|88304&IMP|2|M-40000^INFLAMMATION NOS^SNM|...<cr>

The example in Figure 7-2 has two segments for each component of the report, one for each of the two tissues. Thus, there are two 88304&ANT segments; there are two 88304&GDT segments, and there are two 88304&MDT segments. Segments that apply to the gallbladder all have the sub-identifier 1. Segments that apply to the appendix all have sub-identifier 2.

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

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

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

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

Figure 7-3. Example of sub-identifier usage

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

OBX|2|TX|880304&GDT|1|THIS IS A NORMAL GALL BLADDER|...<cr>

OBX|3|TX|880304&MDT|1|MICROSCOPIC EXAMINATION SHOWS HISTOLOGICALLY

NORMAL GALLBLADDER TISSUE|...<cr>

OBX|4|CE|880304&IMP|1|M-00100^NML^SNM|...<cr>

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

OBX|6|TX|880304&GDT|2|THIS IS A RED, INFLAMED APPENDIX|...<cr>

OBX|7|TX|880304&MDT|2|INFLAMMATION WITH MANY PUS CELLS-ACUTE INFLAMMATION|...<cr>

OBX|8|CE|880304&IMP|2|M-40000^INFLAMMATION NOS^SNM|...<cr>

OBX|9|CE|880304&IMP|2|M-30280^FECALITH^SNM|...<cr>

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

Figure 7-4. Example of sub-identifier usage

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

OBX|2|TX|880304&GDT|1|THIS IS A NORMAL GALL BLADDER|...<cr>

OBX|3|TX|880304&MDT|1|MICROSCOPIC EXAMINATION SHOWS HISTOLOGICALLY

NORMAL GALLBLADDER TISSUE|...<cr>

OBX|4|CE|880304&IMP|1|M-00100^NML^SNM|...<cr>

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

OBX|6|TX|880304&GDT|2|THIS IS A RED, INFLAMED APPENDIX|...<cr>

OBX|7|TX|880304&MDT|2|INFLAMMATION WITH MANY PUS CELLS-ACUTE INFLAMMATION|...<cr>

OBX|8|CE|880304&IMP|2.1|M-40000^INFLAMMATION NOS^SNM|...<cr>

OBX|9|CE|880304&IMP|2.2|M-30280^FECALITH^SNM|...<cr>

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

If the observation includes a number of OBXs with the same value for the observation ID OBX-3, then one must use different values for the sub-ID. This is in fact the case of the repeats depicted in Figure 7-4, but without any need to group sets of OBXs. Three such OBXs could be distinguished by using sub-IDs 1, 2 etc. alternatively, sub-IDs 1.1, 1.2, 1.3 could be used, as shown in Figure 7-4. Figure 7-5 shows and example of an electrocardiograph chest radiograph report with three diagnostic impressions, using 1,2,3 in the sub-ID field to distinguish the three separate results.

Figure 7-5. Example of Sub-ID used to distinguish three independent results with the same observation ID

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

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

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

7.4.2.5 OBX-5 Observation Value (varies) 00573

Definition: This field contains the value observed by the observation producer. OBX-2-value type contains the data type for this field according to which observation value is formatted. It is not a required field because some systems will report only the normalcy/abnormalcy (OBX-8), especially in product experience reporting. The length of the observation field is variable, depending upon OBX-3-value type. This field may repeat for multipart, single answer results with appropriate data types, e.g., CE, TX, and FT data types.

Representation

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

Reporting logically independent observations

The main sections of dictated reports, such as radiologic studies or history and physicals, are reported as separate OBX segments. In addition, each logically independent observation should be reported in a separate OBX segment, i.e. one OBX segment should not contain the result of more than one logically independent observation. This requirement is included to assure that the contents of OBX-6-units, OBX-8-abnormal flags, and OBX-9-probability can be interpreted unambiguously. The electrolytes and vital signs batteries, for example, would each be reported as four separate OBX segments. Two diagnostic impressions, e.g., congestive heart failure and pneumonia, would also be reported as two separate OBX segments whether reported as part of a discharge summary or chest X-ray report. Similarly, two bacterial organisms isolated in a single bacterial culture would be reported as two separate OBX segments.

Though two independent diagnostic statements cannot be reported in one OBX segment, multiple categorical responses are allowed (usually as CE data types separated by repeat delimiters), so long as they are fragments (modifiers) that together construct one diagnostic statement. Right upper lobe (recorded as one code) and pneumonia (recorded as another code), for example, could be both reported in one OBX segment. Such multiple �??values�?� would be separated by repeat delimiters.

Multiple OBX segments with the same observation ID and Sub ID

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

Coded values

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

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

OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE.|...<cr>

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

OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE AND PNEUMONIA|...<cr>

but as:

OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE|...<cr>

OBX|2|CE|71020&IMP|2|^PNEUMONIA|....<cr>

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

OBX|1|CE|710120&IMP^CXR|1|428.0^CONGESTIVE HEART FAILURE^I9C~^MASSIVE HEART|...<cr>

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

Insertion of CDA within an OBX:

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

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

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

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

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

7.4.2.6 OBX-6 Units (CE) 00574

Background: When an observation's value is measured on a continuous scale, one must report the measurement units within the units field of the OBX segment. Since HL7 Version 2.2 of the specification, all fields that contain units are of data type CE. The default coding system for the units codes consists of the ISO abbreviation for a single case unit (ISO 2955-83) plus extensions that do not collide with ISO abbreviations. We designate this coding system as ISO+ (see Figure 7-9). Both the ISO unit's abbreviations and the extensions are defined in Section 7.4.2.6.2, �??ISO and ANSI customary units abbreviations.�?� The ISO+ abbreviations are the codes for the default coding system. Consequently, when ISO+ units are being used, only ISO+ abbreviations need be sent, and the contents of the units field will be backward compatible to HL7 Version 2.1.

7.4.2.6.1 Identifying reporting units

We strongly encourage observation producers to use ISO+ abbreviated units exclusively, but permit the use of other code systems, including US customary units (ANSI X3.50) and locally defined codes where necessary. Local units are designated L or 99zzz where z is an alphanumeric character (see Figures 7-2 and 73). ANSI X3.50 - 1986 provides an excellent description of these standards, as well as a table of single case abbreviations for US customary units such as foot or gallon.

We had originally intended to include the ANSI X3.50 - 1986 US customary units in the default ISO+ coding system. However, there are overlaps between ISO's abbreviations and the abbreviations for US customary units. For example, ft is the abbreviation for foot in US customary units and for femtotesla in ISO; pt is the abbreviation for pint in US customary and for picotesla in ISO. (Be aware that the ANSI document also differs from the ISO document regarding the abbreviation of a few ISO units, as well.) In order to avoid potential ambiguity, we have defined another coding system, designated ANS+ (see Figure 7.7). It includes the U.S. customary units (e.g., feet, pounds) and ISO abbreviations defined in ANSI X3.50 - 1986, as well as other non-metric units listed in Figure 7-7 and the ISO combinations of these units. Be aware that a few of the ANSI ISO unit abbreviations differ from their abbreviations in ISO (see note at bottom of Figure 7-7).

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 avoiding ANS+ unit codes when possible.

When ANS+ units codes (abbreviations) are being transmitted, ANS+ must be included in the third (sixth) component of the field. If the units of distance were transmitted as meters (ISO+) it would be transmitted as m because ISO+ is the default coding system for units. However, if transmitted in the US customary units of feet, the units would be transmitted as ft^^ANS+. When required, the full text of the units can be sent as the second component in keeping with the CE data type conventions.

Both ISO and ANSI also provide a set of mixed case abbreviations, but these abbreviations cannot be translated to single case without loss of meaning, and should not be used in this specification whose content is required to be case insensitive.

7.4.2.6.2 ISO and ANSI customary units abbreviations

ISO builds its units from seven base dimensions measured as meters, kilograms, seconds, amperes, kelvins, moles and candelas (see Figure 7-6). Other units can be derived from these by adding a prefix to change the scale and/or by creating an algebraic combination of two or more base or derived units. However, some derived units have acquired their own abbreviations (see Figure 7-6). Abbreviations for U.S. customary units are given in Figure 7-6.

The ISO rules, well explained in ANSI X3.50, provide a way to create units of different scales by adding multiplier prefixes. These prefixes can be expressed as words or abbreviations. In this Standard we are only concerned with the abbreviations.

Figure 7-6. ISO single case units abbreviations

The ISO abbreviations for multiplier prefixes are given in Figure 7-12. 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.

The ISO code is a grammar for building units. The rules for building these units are found in Figures 7-6 and 7-8. Figure 7-7 should be used only with English units and should not be used in conjunction with Figure 7-8. The ISO+ table (Figure 7-9) includes the most common such units constructed from this grammar (as well as important non-ISO units). Other ISO units derived from the grammar are valid as well.

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

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

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

Refer to section 7.18.3 for the contents of figure 7-9 - Common ISO derived units & ISO+ extensions.

7.4.2.6.3 Local unit codes

Local codes can be used for the units by indicating the code source of 99zzz in the third component (where 99zzz is an alpha-numeric string). In the case of local codes, the text name of the codes or the description of the units should also be transmitted (in the second component), so that the receiving system can compare the results with results for the same measurement sent by another service (refer to Chapter 2, Section 2.9, �??Data Types�?�). An "L" should be stored in the third component to indicate that the code is locally defined. More specialized local code designations, as specified in the CE data type definition, can also be employed.

7.4.2.7 OBX-7 References Range (ST) 00575

Components: for numeric values in the format:

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

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

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

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

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

7.4.2.8 OBX-8 Abnormal Flags (IS) 00576

Definition: This field contains a table lookup indicating the normalcy status of the result. We strongly recommend sending this value when applicable. (See ASTM 1238 - review for more details). Refer to User-defined Table 0078 - Abnormal flags for valid entries.

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

User-defined Table 0078 - Abnormal flags

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

7.4.2.9 OBX-9 Probability (NM) 00577

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

7.4.2.10 OBX-10 Nature of abnormal test (ID) 00578

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

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

HL7 Table 0080 - Nature of Abnormal Testing

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

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

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

HL7 Table 0085 - Observation result status codes interpretation

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

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

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

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

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

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

7.4.2.14 OBX-14 Date/Time of the Observation (TS) 00582

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

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

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

7.4.2.15 OBX-15 Producer's Reference (CE) 00583

Definition: This field contains a unique identifier of the responsible producing service. It should be reported explicitly when the test results are produced at outside laboratories, for example. When this field is null, the receiving system assumes that the observations were produced by the sending organization. This information supports CLIA regulations in the US. The code for producer ID is recorded as a CE data type. In the US, the Medicare number of the producing service is suggested as the identifier.

7.4.2.16 OBX-16 Responsible Observer (XCN) 00584

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

7.4.2.17 OBX-17 Observation Method (CE) 00936

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

The Centers for Disease Control and Prevention (CDC) Method Code (CDCM) (see Figure 7-3) is one candidate code system for reporting methods/instruments. EUCLIDES method codes are another. User-defined tables are an alternative.

7.4.2.18 OBX-18 Equipment Instance Identifier (EI) 01479

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

7.4.2.19 OBX-19 Date/Time of the Analysis (TS) 01480

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

7.4.2.20 OBX-20 Reserved for harmonization with V2.6

7.4.2.21 OBX-21 Reserved for harmonization with V2.6

7.4.2.22 OBX-22 Reserved for harmonization with V2.6

7.4.2.23 OBX-23 Performing Organization Name (XON) 02283

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

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

7.4.2.24 OBX-24 Performing Organization Address (XAD) 02284

Components: <Street Address (SAD)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or Province (ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address Type (ID)> ^ <Other Geographic Designation (ST)> ^ <County/Parish Code (IS)> ^ <Census Tract (IS)> ^ <Address Representation Code (ID)> ^ <DEPRECATED-Address Validity Range (DR)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)>

Subcomponents for Street Address (SAD): <Street or Mailing Address (ST)> & <Street Name (ST)> & <Dwelling Number (ST)>

Subcomponents for DEPRECATED-Address Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Definition: This field contains the address of the organization/service responsible for performing the service.

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

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

Components: <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

Subcomponents for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname (ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse (ST)>

Subcomponents for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>

Subcomponents for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>

Subcomponents for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>

Note subcomponent contains sub-subcomponents

Subcomponents for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>

Subcomponents for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Subcomponents for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System Version ID (ST)> & <Original Text (ST)>

Definition: This field contains the medical director of the organization/service responsible for performing the service.

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

7.4.3 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

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

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

7.4.3.2 SPM-2 Specimen ID (EIP) 01755

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

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

7.4.3.3 SPM-3 Specimen Parent IDs (EIP) 01756

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

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

7.4.3.4 SPM-4 Specimen Type (CWE) 01900

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

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

This attribute corresponds to the first component of OBR.15 - Specimen Source and SAC.6 - Specimen Source component 1 - Specimen source name or code. These components, and the SPS data type, were deprecated upon the development of this segment.

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

• HL7 table 0487 - Specimen Type (replaces HL7 table 0070 - Specimen source codes)

• SNOMED, etc.

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

HL7 Table 0487 - Specimen Type

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

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

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

User-defined Table 0541 - Specimen Type Modifier

Definition: This field identifies any additives introduced to the specimen before or at the time of collection. These additives may be introduced in order to preserve, maintain or enhance the particular nature or component of the specimen. Refer to HL7 Table 0371 - Additive for valid values.

7.4.3.7 SPM-7 Specimen Collection Method (CWE) 01759

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

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

7.4.3.8 SPM-8 Specimen Source Site (CWE) 01901

Definition: specifies the source from which the specimen was obtained. For example, in the case where a liver biopsy is obtained via a percutaneous needle, the source would be �??liver.'

Any nationally recognized coding system might be used for this field including SNOMED; alternatively the HL7 defined table 0070 may be used. Veterinary medicine may choose the tables supported for the components of this field as decided by their industry.

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

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

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

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

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

User-defined Table 0542 - Specimen Source Type Modifier

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

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

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

User-defined Table 0543 - Specimen Collection Site

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

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

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

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

Refer to User-defined Table 0369 - Specimen Role for suggested values.

User-defined Table 0369 - Specimen Role

Definition: This field specifies the volume or mass of the collected specimen. For laboratory tests, the collection volume is the volume of a specimen. Specifically, units should be expressed in the ISO Standard unit abbreviations (ISO-2955, 1977). This is a results-only field except when the placer or a party has already drawn the specimen. (See Chapter 7 for full details about units.)

7.4.3.13 SPM-13 Grouped Specimen Count (NM) 01763

Definition: This field refers to the number of individual specimens of a particular type represented by this instance of a specimen. The use of this field is restricted to specimens upon which all specimen related attributes are identical. This field would only be valued if the specimen role attribute has the value �??G�?�.

7.4.3.14 SPM-14 Specimen Description (ST) 01764

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

7.4.3.15 SPM-15 Specimen Handling Code (CWE) 01908

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

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

User-defined Table 0376 - Special Handling Code

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

User-defined Table 0489 - Risk Codes

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

7.4.3.18 SPM-18 Specimen Received Date/Time (TS) 00248

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

7.4.3.19 SPM-19 Specimen Expiration Date/Time (TS) 01904

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

7.4.3.20 SPM-20 Specimen Availability (ID) 01766

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

7.4.3.21 SPM-21 Specimen Reject Reason (CWE) 01767

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

HL7 Table 0490 - Specimen Reject Reason

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

User-defined Table 0491 - Specimen Quality

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

User-defined Table 0492 - Specimen Appropriateness

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

User-defined Table 0493 - Specimen Condition

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

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

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

7.4.3.27 SPM-27 Container Type (CWE) 01773

Definition: The container in or on which a specimen is transported

7.4.3.28 SPM-28 Container Condition (CWE) 01774

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

Refer to User-defined Table 0544 - Container Condition for suggested values.

User-defined Table 0544 - Container Condition

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

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

HL7 Table 0494 - Specimen Child Role

7.5.1 Query/response

The following is a query of the EKG system for the data for a particular patient number 0123456-1 for reports that have been modified or created since 1/1/88. These examples use LOINC® clinical codes. The response ends with a continuation pointer. A continuation query follows, in reply to which a continuation response is sent.

Query (QRY)

MSH|^~\&|CBD||EKG||198905201200||QRY^R02|CDB22222|P|...<cr>

QRD|198904180943|R|I|Q4412|||10|RD|0123456-1|RES|...<cr>

QRF|EKG||198801010000|...<cr>

Response

MSH|^~\&|EKG||CDB||198905201201||ORF^R04|X981672|P|...<cr>

MSA|AA|CDB22222|P|...<cr>

QRD|198904180943|R|I|Q4412|||10|RD|0123456-1|RES|...<cr>

QRF|EKG||198804010000|...<cr>

PID|1||0123456-1||EVERYMAN^ADAM^H||||||||555-2004|...<cr>

OBR|1|43215^OE|98765^EKG|93000^EKG REPORT| ||198801111330|||||||

||P030||||||198801120930||||||P011^SEVEN^HENRY^L^^^MD|43214^OE|...<cr>

OBX|1|ST|8897-1^QRS COMPLEX^LN||91|/MIN|60-100||||F|...<cr>

OBX|2|ST|8894-8^P WAVE^LN||92|/MIN|60-100||||F|...<cr>

OBX|3|ST|8625-6^P-R INTERVAL^LN||0|/MSEC|1.06-.10||||F|...<cr>

OBX|4|ST|8633-0^QRS DURATION^LN||.368|/MSEC|.18-.22||||F|...<cr>

...

...

...

OBX|8|CE|8601-7^EKG IMPRESSION^LN|1|^ATRIAL FIBRILATION||||||F|...<cr>

OBX|9|CE|8601-7^EKG IMPRESSION^LN|2|^ST DEPRESSION||||||F|...<cr>

OBX|10|FT|93000&ADT^EKG COMMENT||\.in+4\\.ti-4\ 1. When compared with EKG of

31-oct-88 ventricular rate has increased by 30 bpm.\.sp\\.ti-4\

2. Criteria for Lateral infarct are no longer present.|||||F|...<cr>

OBR|2|43217^OE|98767^EKG|93000^EKG REPORT|||198810311004|||||||||P030||||||198810311744||||||

P011^SEVEN^HENRY^L^^^MD |43213^OE |...<cr>

...

...

...

DSC|1896X22;0123456-1|...<cr>

Continuation query

MSH|^~\&|CDB||EKG||198905201204||QRY^R02|CDB22289|P|...<cr>

QRD|198904180943|R|I|Q4412|||10|RD|0123456-1|RES|...<cr>

QRF|EKG||1988040100000|...<cr>

DSC|1896X22;0123456-1|...<cr>

Continuation response

MSH|^~\&|EKG||CDB||198905201205||ORF^R04|X981672|P|...<cr>

MSA|AA|CDB22289|P|...<cr>