Additional Information Message Implementation Guide

Transcription

1 Additional Information Message Implementation Guide Hl7 Version 2.4 Standard, Release 1.0 NPRM Draft December 11, 2001 Copyright 2000, 2001 Health Level Seven, Inc. Ann Arbor, MI

2 1 INTRODUCTION CONCEPTUAL APPROACH Relationship to the X12 Transaction No Trading Partner or Site-Specific Variations in Content ELECTRONIC SUPPORTING DOCUMENTATION AUTHORITY AUTHORITY, ORGANIZATION AND SCOPE OF THIS DOCUMENT HEALTH LEVEL SEVEN ORGANIZATION LOGICAL OBSERVATION IDENTIFIER NAMES AND CODES (LOINC ) LOINC Names and Identifiers LOINC Codes for Electronic Supporting Documentation The LOINC Consortium Obtaining LOINC Codes REVISION HISTORY CLAIMS ATTACHMENT MESSAGES RULES FOR CONSTRUCTING CLAIMS ATTACHMENT MESSAGES USE OF LOINC CODES ADDITIONAL INFORMATION MESSAGE BOOKLETS CONTENTS OF AN ADDITIONAL INFORMATION MESSAGE BOOKLET HL7 Message Variants Value Table Coding Example and Code Sets CHARACTER SETS THE HL7 STANDARD INTRODUCTION TO HL HL7 Messages Segments Fields Message Delimiters Data Types Timing/Quantity (TQ) Definition Use of Escape Sequences in Text Fields Message Construction Rules HL7 MESSAGE SPECIFICATIONS HL7 Specification Format ORU - Unsolicited Transmission of an Observation or Result (Event R01) HL7 SEGMENT SPECIFICATIONS MSH - Message Header Segment OBR - Observation Request Segment OBX - Observation/Result Segment PID - Patient Identification Segment...78

3 Figures Figure 1. Sample HL7 Message (in boldface) embedded in X12 BIN segment...2 Figure 2. Relationship of organizations, publications, and transactions...4 Figure 3. Usage of ORU message for claims attachments...9 Figure 4. Sample claims attachment medications message Figure 5. Sample Data Field Usage table for Discrete Element message variant...13 Figure 6. Sample Value Table...16 Figure 7. Partial Coding Example...16 Figure 8. Sample guidance on interpreting HL7 for attachment exceptions...18 Figure 9. Sample HL7 message with message ID and trigger event code highlighted...18 Figure 10. Sample Segment Attribute Table...19 Figure 11. HL7 Delimiters...21 Figure 12. HL7 Data Types Figure 13. User-defined table Repeat pattern...51 Figure 14. Formatted text as transmitted...57 Figure 15. Formatted text in one possible presentation Figure 16. Hypothetical HL7 Widget message...60 Figure 17. WPN and WPD segments in pairs...60 Figure 18. At least one pair of WPN and WPD Tables Table 1. Clinical report topics...5 Table 2. Uses of LOINC codes for Attachments Table 3. Uses of LOINC codes in Clinical Reports, Lab Results and Medications...Error! Bookmark not defined. Table 4. Related LOINC Publications Table 5. MSH Segment...61 Table 6. OBR Segment Table 7. OBX Segment Table 8. PID Segment...78

4 Additional Information Message Implementation Guide HL7 Version 2.4 Standard, Release Introduction This document specifies construction rules for a tightly constrained HL7 ORU message imbedded in the BIN segment of an X transaction. In conjunction with the documents listed below it constitutes a proposed solution to the requirement for electronic transmission of claims attachments included in the Health Insurance Portability and Accountability Act of 1996 (HIPAA). ASC X12N 275 (004020X107) Implementation Guide Additional Information to Support a Health Care Claim or Encounter; a product of the insurance subcommittee (X12N) of Accredited Standards Committee X12 1,2 ASC X12N 277 (004020X104) Implementation Guide Health Care Claim Request for Additional Information 3 ; a product of the insurance subcommittee (X12N) of Accredited Standards Committee. HL7 additional information message booklets containing codes published by the Logical Observation Identifiers, Names, and Codes (LOINC ) Committee as described in section This document will be published as an officially balloted recommendation of the HL7 Standards Development Organization (SDO), which is accredited by the American National Standards Institute (ANSI). For a comprehensive understanding of this proposed solution, the following reading sequence is suggested: ASC X12N 277 (004020X104) Implementation Guide Health Care Claim Request for Additional Information ASC X12N 275 (004020X107) Implementation Guide Additional Information to Support a Health Care Claim or Encounter Health Level Seven (HL7) Version 2.4 Standard; Implementation Guide: Additional Information to Support a Healthcare Claim or Encounter, Release 1.0, May Logical Observation Identifier Names and Codes (LOINC ) Committee publication LOINC Modifier Codes as used in the ASC X12N 277 Implementation Guide (004020X104) Health Care Claim Request for Additional Information. 1 Information on this and other X12/HIPAA-related implementation guides is available from the Washington Publishing Company, Gaithersburg, MD. 2 Within the HL7 Implementation Guide, references to the transaction defined by this document will be abbreviated by calling it 275. The implied citation is to this particular X12N document. 3 Within the HL7 Implementation Guide, references to the transaction defined by this document will be abbreviated by calling it 277. The implied citation is to this particular X12N document. 4 These booklets, and information on this and other HIPAA-related EDI matters will be available from the Washington Publishing Company, Gaithersburg, MD. Additional Information Message 1 NPRM Draft

5 The HL7 additional information message booklets containing the LOINC code tables specific to requests for additional information. These booklets may be read in any order. 1.1 Conceptual Approach A claim attachment is a set of supporting documentation that is associated with a healthcare claim or encounter. Electronic supporting documentation in this context is a collection of data elements that has been given a name and a LOINC code. Each data element has its own name and identification code. Many of these items of electronic supporting documentation are based on an analysis of paper forms that have been used by payers in the past. Each such item, however, has been reviewed for appropriateness in an electronic format. In some cases, electronic supporting documentation has been defined for situations where there was not a specific paper precursor. For example, items have been defined to send various kinds of clinical reports, laboratory results, and patient medication information Relationship to the X12 Transaction As described in the X12N Implementation Guide, the LX loop in the 275 includes a Binary (BIN) segment that will contain an HL7 message. The HL7 message may include an electronic attachment in its entirety or it may contain the specifics of one or more attachment data elements. Figure 1 shows an example of an HL7 Unsolicited Transmission of an Observation message embedded in an X This HL7 message, which is in boldface, has the message identification code ORU and will be referred to as the ORU message throughout this and related documents. Note that X12 segments do not end with a carriage return, each HL7 segment ending in a carriage return is shown on a separate line for readability. Figure 1. Sample HL7 Message (in boldface) embedded in X12 BIN segment. ST*275*1001~ BGN*11*0001* ~ NM1*PR*2*HEALTH CARE SERVICE CORPORATION*****PI*00121~ PER*IC*MEDICAL REVIEW DEPARTMENT~ NM1*85*2*LOYOLA UNIVERSITY MEDICAL CENTER*****FI* ~ NM1*41*2*LOYOLA UNIVERSITY MEDICAL CENTER*****SV* ~ NM1*QC*1*SMITH JOHN****HN* A~ REF*IK* ~ DTP*472*RD8* ~ LX*01~ STC*R3: ~ DTP*097*D8* ~ CAT*UL*HL~ EFI*09~ BIN*152*MSH ^~\& ORU^R01^ORU_R01 A49282 P 2.4 NE NE<cr> PID ^^^^MR Smith^John^J<cr> OBR ^^LN<cr> OBX NM ^^LN 147 LB^^ANS+<cr>~ SE*15*1001~ No Trading Partner or Site-Specific Variations in Content The economic benefits of the HIPAA are obtained, in part, by creating a universal specification. Providers will not have to maintain large libraries of variations on transaction formats to meet the Additional Information Message 2 NPRM Draft

6 differing requirements of payers. It is intended that the formats in this Implementation Guide meet the requirement for universality. Where options exist in HL7, the Implementation Guide should definitively specify which would be used. Occasionally, however, the senders need options to cover alternative use cases. Where such options exist in the Implementation Guide, the receivers will accept all of the options that exist. For example, the electronic attachment for ambulance has a data element called patient weight. There are three different LOINC codes for patient weight according to whether the weight was measured, estimated, or stated by the patient or an agent of the patient. The attachment specifies the option to use any of the three LOINC codes. Receivers must accept all three. 1.2 Electronic Supporting Documentation Authority HL7 does not specify what information is to be sent electronically. Federal regulations will assign that authority to data content committees. DHHS will publish information separately regarding the role and formation of Data Content Committee. HL7 only specifies how to format the HL7 messages that are embedded within X12 transactions and contain the prescribed information. That is specified in this Implementation Guide. When a data content committee establishes the requirement for specific electronic attachments or attachment data elements, HL7 does not specify the codes that are used to identify them. Those codes are established and maintained by the LOINC Consortium. When a data content committee establishes a specific set of concepts that are the valid answers for a data element, the LOINC committee provides codes to identify those concepts. Additional Information Message 3 NPRM Draft

7 Figure 2. Relationship of organizations, publications, and transactions. ASC X12 Subcommittee X12N Health Level Seven Data Content Committees X12 Transaction Sets 277, 275 HL7 Version 2.4 LOINC Consortium X12 Implementation Guides 277, 275 HL7 Additional Information Message Implementation Guide HL7 Additional Information Message Booklets X Transaction C C X Transaction C C HL7 ORU Message C C C Figure 2 illustrates the relationship of the organizations, documents, transaction messages, and codes. The X12N implementation guides determine the contents of the X12N transactions up to the BIN segment. It also specifies the use of externally defined LOINC codes in certain data fields. The HL7 Implementation Guide determines the format of the ORU message in the BIN segment. The external LOINC codes for the X12N transactions and the HL7 message are published in booklets that are specific to the kind of electronic supporting documentation being requested and sent. As of the publication of this implementation guide, six LOINC attachment booklets are available to describe electronic supporting documentation: ambulance Additional Information Message 4 NPRM Draft

8 rehabilitation, addressing nine disciplines: alcohol/substance abuse, cardiac, medical social services, occupational therapy, physical therapy, psychiatric, respiratory therapy, skilled nursing and speech therapy Emergency Department narrative clinical reports, including, but not limited to, those shown in Table 1, below laboratory results medications. In addition, a booklet is available that enumerates the use of LOINC codes in modifying the scope of requests in the X12N 277 transaction. anesthesia arthroscopy bronchoscope cardiac catheterization colonoscopy consultation note consultation request cytology diagnostic imaging discharge note echo heart EEG brain EKG Electromyelogram endoscopy exercise stress test Table 1. Clinical report topics. flexible sigmoidoscopy history and physical notes initial assessment nursing OB echo operative note procedure note progress note radiology spirometry surgical pathology temperature chart total visit note 1.3 Authority, Organization and Scope of this Document The Implementation Guide is based on the Health Level Seven Standard, Version 2.4, an ANSIaccredited American National Standard. The HL7 Membership in a letter ballot using the procedure for publishing HL7 Recommendations has approved the Implementation Guide. HL7 Version 2.4 is based on rules for forming messages from segments and data fields that are very similar to, but different than, those of X12. The organization of this specification is described below: Section 1 is this introduction Section 2 describes how the HL7 ORU message format is constructed to convey claims attachment information within the BIN segment of the X transaction. It also gives examples of attachment-specific booklets to establish the codes and answers for specific attachment elements. Readers who are unfamiliar with HL7 may find it beneficial to read Section 3 before reading this section. Section 3 provides summary information about Health Level Seven Standard, Version 2.4. It restates selected information, eliminating optional features that are not required for creating claims attachments and giving guidance on the use of other features. 1.4 Health Level Seven Organization The mission of HL7 is to provide standards for the exchange, management, and integration of data that support clinical patient care and the management, delivery, and evaluation of healthcare services. Founded in 1987, HL7 is a not-for-profit Standards Developing Organization (SDO) that specializes in developing standards for the exchange of clinical data among disparate health care computer applications. Like ASC X12, the American National Standards Institute accredits HL7. Additional Information Message 5 NPRM Draft

9 The HL7 membership represents more than 1,600 people drawn from more than 1000 of the nation's leading organizations with an interest in this topic. These include the industry's leading healthcare provider organizations, 90% of the top vendors selling information systems to healthcare providers, as well as consulting firms, payers, pharmaceutical vendors, other healthcare organizations and healthcare professional associations. HL7 has a number of International Affiliates including Australia, Austria, Belgium, Canada, Germany, Israel, Japan, New Zealand, The Netherlands, and the United Kingdom. HL7 complements X12N in that its interests have been to support the clinical processes, whereas Task Group 2, X12N (the Healthcare Task Group of the Insurance Subcommittee of X12) focuses on administrative and financial processes within healthcare. For information on membership and obtaining the standard, contact: Health Level Seven 3300 Washtenaw Ave., Suite 227 Ann Arbor, MI (734) hq@hl7.org Logical Observation Identifier Names and Codes (LOINC ) The HL7 encoding of claims attachments makes extensive use of the code set, Logical Observation Identifier Names and Codes (LOINC). LOINC codes are available for commercial use without charge, subject to the terms of a license that assures the integrity and ownership of the codes LOINC Names and Identifiers The LOINC database provides sets of universal names and ID codes for identifying laboratory and clinical test results and other units of information meaningful in claims attachments. Each LOINC record corresponds to a single observation. The record includes attributes to specify: The numeric code that identifies the observation The observed component e.g., potassium, hepatitis C antigen, distance the patient was transported (by an ambulance) The property measured e.g., a mass concentration, length (distance) Whether the measurement is a momentary observation at a point in time, or an observation made over a span of time The type of sample or other source of observation e.g., urine, blood, EMS transport The type of scale e.g., whether the measurement is quantitative (a true measurement) or nominal (red, blue, green) Where relevant, the method used to produce the result or other observation A class code that associates the observation with others in a group, such as the observations associated with an obstetric ultrasound procedure. Additional Information Message 6 NPRM Draft

10 Many medical concepts have multiple LOINC codes. The codes distinguish different methods of making the observation. For example, there are different LOINC codes for manual and automated leukocyte counts. Indeed, there are three codes for the patient s body weight according to whether it was measured, estimated, or the datum is the weight that the patient reported. Different LOINC codes will also be used to distinguish different ways to report the observation. For example, identifies the specimens taken during surgery when reported using narrative text, whereas would identify coded descriptions of the same specimens. LOINC codes may also identify sets of observations. For example, the LOINC code (discharge medications) identifies a set of other observations, identified by other LOINC codes, including (discharge medication identification), (discharge medication dose), (discharge medication timing), etc. The LOINC codes are not intended to transmit all possible information about a test or observation. They are only intended to identify the observation. The LOINC code for a name is unique and permanent. The LOINC code has no intrinsic structure except that the last character in the code is a mod-10 check digit. LOINC codes must always be transmitted with a hyphen before the check digit (e.g., " "). The LOINC committee assigns LOINC codes upon request from various agencies. Requests go through a review process to ensure the concept has not been previously added and the meaning is clear LOINC Codes for Electronic Supporting Documentation LOINC codes are used to identify requests for: An electronic attachment in its entirety (e.g., a request for the Ambulance attachment in support of a claim for ambulance services) One or more elements of an electronic attachment (e.g., a request for the number of miles that the ambulance drove in support of a claim for ambulance services) One of a set of observations that compose a single attachment element (e.g., one code identifies the name portion of the data element that is the ambulance destination; a distinct code identifies the address portion) A category of clinical report (e.g., send any reports of CAT scans of the head that are related to the claim or a specific service) A part or parts of a clinical report (e.g., send the impression section of a radiology report in support of a claim or a specific service) A category of laboratory results (e.g., send any hematology results that are related to the claim or a specific service) A category of medication information (e.g., send the discharge medications that are related to the claim or a specific service) LOINC codes are also used to modify the implicit scope of a request in an X12N 277 transaction; e.g., to modify a request for serology lab values to specify only the abnormal results for a period 30 days prior to treatment. Additional Information Message 7 NPRM Draft

11 1.5.3 The LOINC Consortium LOINC is a consortium of laboratories, system vendors, hospitals and academic institutions organized by the Regenstrief Institute and supported by grants from The John A. Hartford Foundation, Inc., the Agency for Health Policy Research and Development and The National Library of Medicine to create formal names and codes for laboratory results and clinical variables with numeric, coded, or narrative text values. The LOINC codes were designed specifically to provide a universal identifier for OBX-3 of the HL7/ASTM observation reporting messages and the corresponding field in CEN messages. It has since been adopted by DICOM as well. For identifying observations in these "messages," the LOINC committee distributes the over 10,000- record database and the Regenstrief LOINC Mapping Assistant (RELMA ) software for perpetual use free via the Internet. Widespread use of LOINC will enable better and more efficient use of computer-stored clinical data Obtaining LOINC Codes LOINC codes are registered by Regenstrief Institute and the Logical Observation Identifier Names and Codes (LOINC ) Consortium. The Additional Information Message booklets, and information on this and other HIPAA-related EDI matters is available from the Washington Publishing Company, Gaithersburg, MD. The LOINC database can be obtained from Regenstrief Institute, c/o Kathy Hutchins, 1001 West 10th Street RG-5, Indianapolis, IN 46202, 317/ or on-line at Revision History Date Purpose Feb 1999 Version 1.0 Feb 2000 Version 1.0a released for technical correction. Dec 2001 Document identifier, title change and technical corrections Additional Information Message 8 NPRM Draft

12 2 Claims Attachment Messages This section documents how the HL7 ORU message is constructed to convey claims attachment information within the BIN segment of the X transaction. It further describes the format of Additional Information Message booklets that document specific electronic attachment documentation. 2.1 Rules for Constructing Claims Attachment Messages All additional information messages are derived from the HL7 ORU message and consist exclusively of MSH, PID, OBR and OBX segments. Each message variant uses the pattern of segments shown in Figure 3. Figure 3. Usage of ORU message for additional information. ORU Observational Results (Unsolicited) MSH Message Header PID Patient Identification {OBR Observations Report ID {OBX} Observation/Result } This message format requires that there be at least one OBR segment, although it allows many. In each OBR segment, the universal service ID (OBR-4) always contains a LOINC code that identifies an attachment data element. After each OBR segment there must be at least one OBX segment; in some cases there may be several. Each OBX segment following an OBR segment contains an answer part, identified by LOINC code, specific to the attachment element identified in OBR-4. For some parts, the information in OBR-4 may be supplemented by the contents of other data fields in the OBR segment. A particular set of requirements for using the data fields of the segments is called a message variant. These are described in In each OBX segment, the observation identifier (OBX-3) always contains a LOINC code that identifies the answer part of the attachment element contained in the segment. The observation value (OBX-5) contains the observation data and value type (OBX-2) defines the data type of the information in OBX-5. For some parts, the information in OBX-5 may be supplemented by the contents of other data fields in the OBX segment. Such requirements are documented as part of the message variant, also described in section Figure 4 provides an example of an additional information message for the scenario, the payer requests the date of onset or aggravation of the primary diagnosis for the psychiatric rehabilitation treatment plan, and the primary diagnosis. The boldface portion shows two OBR segments containing the LOINC codes for each of the requested elements. Each has one or more OBX segments to contain the information. The LOINC code identifies the request for date of onset; the specified date is March 26, The LOINC code requests the primary diagnosis. This element may be transmitted in two parts: identifies the coded diagnosis, 296.4; I9 in that element indicates that the code is from the ICD-9-CM code set. The optional second part of the element is identified by the LOINC code This is the descriptive text relevant to the ICD-9 code, in this case bipolar affective disorder. Additional Information Message 9 NPRM Draft

13 For clarity, Figure 4 shows each segment of the ORU message as a separate line. Figure 4. Sample claims attachment medications message. BGN*11*0001* ~ NM1*PR*2*HEALTH CARE SERVICE CORPORATION*****PI*00121~ PER*IC*MEDICAL REVIEW DEPARTMENT~ NM1*85*2*DUKE UNIVERSITY MEDICAL CENTER*****FI* ~ NM1*41*2* DUKE UNIVERSITY MEDICAL CENTER*****SV* ~ NM1*QC*1*STONE^ERIKA****HN* A~ REF*IK* ~ DTP*472*RD8* ~ LX*01~ STC*R3:Z0001-0~ DTP*097*D8* ~ CAT*UL*HL~ EFI*09~ BIN*265*MSH ^~\& ORU^R01^ORU_R01 A P 2.4 NE NE<cr> PID ^^^^MR STONE^ERIKA<cr> OBR ^^LN<cr> OBX DT ^^LN F<cr> OBR ^^LN<cr> OBX CE ^^LN 296.4^^I9 F<cr> OBX ST ^^LN BIPOLAR AFFECTIVE D/O F<cr>~ SE*16*1001~ 2.2 Use of LOINC Codes LOINC codes are used for several different purposes both in the two X12 transactions and in the HL7 message format used to request and provide electronic supporting documentation. Furthermore, the information pattern of the messages can follow one of two paradigms: Electronic attachments, such as ambulance or rehabilitation services Clinical reports, such as discharge notes, radiology reports, lab results, or medication information. Table 2, below, identifies the use of LOINC codes for electronic supporting documentation. Note: the table provides a general orientation to how LOINC codes are used. The specific usage of LOINC codes in X and X transactions is described in the X12 implementation guides cited in section 1. The STC segment in these transactions has separate positions for the Scope Modifiers and Attachment Identifier, so LOINC codes can be used for both purposes in a single transaction. The specific usage of LOINC codes in the HL7 ORU message is defined in the Additional Information Message booklets.. Additional Information Message 10 NPRM Draft

14 Purpose of Message LOINC Modifier Codes LOINC Attachment Identifier LOINC Attachment Element LOINC Attachment Element Answer Part Table 2. Uses of LOINC codes for Attachments. X X HL7 ORU Request for additional information to support a health care claim Used in the STC segment to limit the scope or time frame of a request for information Send only abnormal results Send results for up to 90 days before the related encounter Used in the STC segment to request an attachment in its entirety Send the ambulance services attachment Send the occupational therapy rehabilitation attachment Used in the STC segment to request a specific attachment element or part of a clinical report Send the ambulance transport destination Additional information to support a health care claim or encounter Reiterated in the STC segment Reiterated in the STC segment Reiterated in the STC segment Not used in the 277 Not used in the 275 Provide structured content for X12N 275 BIN segment Not used in the ORU message Not used in the ORU message Used in OBR-4 to identify the attachment element being provided This is an element of the occupational therapy attachment This is the ambulance transport destination Used in OBX-3 to identify the answer part of an attachment element or clinical report being provided This is the name of the ambulance transport destination Additional Information Message 11 NPRM Draft

15 2.3 Additional Information Message Booklets Additional information message booklets provide information specific to a given attachment or attachment category and supplement this implementation guide. Table 3. Additional Information Message Booklets. Title Additional Information Message 0001: Ambulance Service Attachment (V24AIM0001R010) Additional Information Message 0002: Emergency Department Attachment (V24AIM0002R010) Additional Information Message 0003: Rehabilitation Services Attachment (V24AIM0003R010) Additional Information Message 0004:Clinical Reports Attachment (V24AIM0004R010) Additional Information Message 0005:Laboratory Results Attachment (V24AIM00051R010) Additional Information Message 0006:Medications Attachment (V24AIM0006R010) 2.4 Contents of an Additional Information Message Booklet The codes and message variants for each type of electronic supporting documentation are defined in a LOINC code booklet. Each booklet contains: The applicable message variant The LOINC code or codes that are used to identify the attachment in its entirety or the clinical report category in the 277 transaction The LOINC codes that are used to identify individual attachment elements or parts of clinical reports in the 275 and 277 transactions, and the HL7 ORU message A value table, which includes the LOINC codes for each attachment data element or report category with the associated answer part LOINC codes, data type, and answer code information A coding example Code sets, which are lists of the codes used for specific attachment data element parts. These are described below HL7 Message Variants An HL7 message variant is a specific subset of all the segments and data fields that might be included in a message. The description of each message variant includes: a general description of the applicability of the message variant an HL7 message format diagram that describes the segments that will actually be used Additional Information Message 12 NPRM Draft

16 a table of data fields that will be used in the message with guidance on how to populate the fields. Figure 5 is an example of the table that describes how each mandatory data field in the segments of a message variant will be populated. Fields that are not described in the table must be null. Figure 5. Sample Data Field Usage table for Discrete Element message variant. Example From LOINC Publication SEQ Element Name Required Value MSH-1 Field Separator (recommended) MSH-2 Encoding Characters ^~\& (recommended) MSH-7 Date/Time Of Message MSH-9 Message Type ORU^R01^ORU_R01 MSH-10 Message Control ID An identifier that uniquely identifies this message. MSH-11 Processing ID P MSH-12 Version ID 2.4 MSH-15 Accept Acknowledgment Type NE MSH-16 Application Acknowledgment Type NE PID-3 Patient ID (Internal ID) Provider identification number for patient. PID-5 Patient Name last^first^mi^prefix^suffix^title OBR-4 Universal Service ID Code to identify attachment data element in value table, below OBX-2 Value Type Code to identify data type of OBX-5, see value table, in the section for a specific electronic attachment. OBX-3 Observation Identifier See value table, in the section for a specific electronic attachment. OBX-5 Observation Value See value table in the section for a specific electronic attachment. OBX-6 Units See value table in the section for a specific electronic attachment. OBX-11 Observation Result Status F - Final results; N - Not asked; used to affirmatively document that the observation identified in OBX was not sought when the universal service ID in OBR-4 implies that it would be sought. P - Preliminary results; S - Partial results; X - Results cannot be obtained for this observation Value Table Additional Information Message 13 NPRM Draft

17 Figure 6 is an example of the value table. Figure 7 shows sample HL7 coding that corresponds to the value table. The columns of the value table are: LOINC code this column contains the LOINC code that identifies an element or clinical report category in OBR-4, or a part of an element or clinical report an OBX-3. Value this column names the element identified by the LOINC codes. It can also contain instructions on how to populate OBX-5, the field that carries the data. OBX-2 this column contains the HL7 data type of the data in the OBX-5 field; this value will be sent in OBX-2. Card this column gives the minimum and maximum number of repetitions. In a row associated with an OBR segment, it describes whether the element is optional or can repeat. In a row associated with an OBX segment, it describes whether the element part is optional or can repeat. (See ) Additional Information Message 14 NPRM Draft

18 OBX-5/6 this column defines supporting information relevant to those attachment elements defined as coded elements (CE) or numeric (NM). For CE data types it specifies the coding system entry to be placed in OBX-5 component 3 (OBX-5^3). For NM data types is stipulates the units of measure notation to be placed in OBX Repetitions Repetitions are described as a pair of numbers, the first is the least number of repetitions that are permitted, and the second the greatest. The second number can also be n which means an unspecified number, more than one. The common patterns are 1,1 The element or element part is required; only a single occurrence is permitted 0,1 The element or element part is optional; at most a single occurrence is permitted 1,n The element or element part is required; multiple occurrences are permitted 0,n The element or element part is optional; multiple occurrences are permitted The Card column describes repetition in the pattern of OBR and OBX segments. If such a value appears in a row containing LOINC code for an OBR-4, it describes whether the entire element (including an OBR and one or more OBX segments) can repeat. If a Rep value appears in a row containing LOINC code for an OBX-3, it indicates that the OBX segment for that part can repeat within a single occurrence of the complete attachment element. In some cases, a data element may be shown as required even though it is not always collected as part of the episode that is the subject of the claim. In this case, the detailed specifications offer the ability to document affirmatively that the data was not collected. Additional Information Message 15 NPRM Draft

19 Figure 6. Sample Value Table. The same LOINC code, , appears in OBR-4 andobx-3 The data type is date so DT will appear in OBX-2 This element may occur once and only once and has a single response that is required and may occur only once LOINC code Value OBX-2 Card OBX 5/6 OBR-4: PSYCHIATRIC REHABILITATION TREATMENT 1,1 PLAN, DATE ONSET OR EXACERBATION OF This column specifies the coding system PRIMARY DIAGNOSIS (OBX-5 component 3) OBX-3: DT 1,1 for coded elements or the unit of measure for OBR-4: PSYCHIATRIC REHABILITATION TREATMENT 1,1 numeric (NM) data PLAN, START DATE types (OBX-6) OBX-3: DT 1,1 OBR-4: PSYCHIATRIC REHABILITATION TREATMENT 1,1 PLAN, PRIMARY DIAGNOSIS (COMPOSITE) OBX-3: PSYCHIATRIC REHABILITATION TREATMENT PLAN, CE 1,1 OBX-5^3: I9C PRIMARY DIAGNOSIS (IDENTIFIER) ICD-9CM code. OBX-3: PSYCHIATRIC REHABILITATION TREATMENT PLAN, ST 0,1 PRIMARY DIAGNOSIS (TEXT) OBR-4: PSYCHIATRIC REHABILITATION TREATMENT 1,1 PLAN, PROGNOSIS FOR REHABILITATION OBX-3: Poor 2 Guarded 3 Fair 4 Good CE 1,1 OBX-5^3: HL79005 This OBR may be followed by two OBX, the required identifier and the optional text description if needed for clarity Because there are only a few answer codes, they are listed inline as well as in a separate code table section The data type is coded element so CE will appear in OBX-2 Figure 7. Partial Coding Example OBR ^^LN<cr> OBX DT ^^LN F<cr> OBR ^^LN<cr> OBX CE ^^LN 296.4^^I9 F<cr> OBX ST ^^LN BIPOLAR AFFECTIVE D/O F<cr> Additional Information Message 16 NPRM Draft

20 2.4.3 Coding Example and Code Sets The Coding Example portion of this section includes a description of an electronic attachment as a sample message. The sample includes the X transaction envelope and the HL7 ORU message contained in the BIN segment. A description of the scenario that would generate the sample message precedes the example. This section also describes all the code sets that are identified in the Code Source or Units column (OBX-5/6) of the Value Table. Some code sets are simply named and described. For others the code values are listed here. The example below shows the code set named DEEDS DEEDS4.24: Respiratory rate special circumstances codes See DEEDS 5 data element Table DEEDS4.24: Respiratory rate special circumstances codes Code DEEDS respiratory rate special circumstances codes 666 Agonal respirations 777 Respiratory assistance with manual or mechanical ventilation 888 Not measured 999 Unknown 2.5 Character Sets HL7 version 2.4 uses the Basic G0 Set of the International Reference Version of ISO 646:1990 (ISO IR-6) as the default character repertoire for character strings. This is a single-byte character set, identical to ASCII. It supports trading partner agreements to use numerous extensions to the character set including ISO 8859 (1-9) for various European alphabets and JIS X 0201, JIS X 0208, JIS X 0212 for Japanese applications. The HL7 standard theoretically permits trading partner agreements to use EBCDIC instead of ASCII. However, the anticipated regulations associated with HIPAA claims attachments do not permit these variations. For HIPAA implementations, senders must use ASCII when exchanging information among trading partners. Numerous HL7 implementations have been built on mainframes and other operating environments that natively do not support ASCII. These applications have successfully interoperated with other applications using ASCII as the data exchange format. Such implementations typically work with data in EBCDIC in the programming environment and rely on one of two approaches to convert the data to and from ASCII before transmission and after reception: Many operating system versions provide features for automatic conversion of data between EBCDIC and ASCII during input-output operations. Many "message mapping" or "interface engine" products provide this translation. 5 This example is drawn from a separate booklet. In that booklet the acronym DEEDS is identified as the document Data Elements for Emergency Department Systems. Additional Information Message 17 NPRM Draft

21 3 The HL7 Standard 3.1 Introduction to HL7 This section provides information excerpted and adapted from the Health Level Seven Standard, Version 2.4. Certain HL7 options are required or prohibited for HL7 additional information messages. These are indicated in this document in the following ways: HL7 features and message formats that are not described in this document shall not be used Optional segments and data fields should not be used unless they are explicitly described in sections 3.2 or Further required interpretations of HL7 are described in highlighted exception notes, an example is shown in Figure 8. Figure 8. Sample exception note for HL7 additional information message. (Sample) The optional second component of the TS data type shall not be used for claims attachments HL7 Messages A message is the unit of data transferred between information systems. It is composed of a group of segments in a defined sequence. Each message has a message type that defines its purpose. For example, the Observation or Result Unsolicited (ORU) message type is used to transmit clinical data about a patient from one system to another. A three-character code contained within each message identifies its type, in this case ORU. The real-world event that initiates an exchange of messages is called a trigger event. Examples of trigger events include a patient is admitted to a healthcare facility, an order for a medication is discontinued or a laboratory measurement has been completed and has met the criteria for release to users. The trigger event that stimulates a message is identified in a message by a code. There is a one-to-many relationship between message types and trigger event codes. The same trigger event code may not be associated with more than one message type; however, a message type may be associated with more than one trigger event. Figure 9 shows a sample HL7 Observation or Result Unsolicited message (ORU) sent for the trigger event unsolicited transmission of an observation message (R01 ). The message ID and trigger event code are highlighted. The characters, ^, \, & and the carriage return character (shown as <cr> ) are reserved for special functions as described in Figure 9. Sample HL7 message with message ID and trigger event code highlighted. MSH ^~\& ORU^R01^ORU_R01 A P 2.4 NE NE<cr> PID ^^^^MR Smith^John^J<cr> OBR ^^LN<cr> OBX NM ^^LN 147 LB^^ANS+ F<cr> Segments Messages are composed of segments. Additional Information Message 18 NPRM Draft

22 A segment is a logical grouping of data fields. Segments of a message may be required or optional. They may occur only once in a message or they may be allowed to repeat. Each segment is identified by a name and a unique three-character code known as the Segment ID. Segments are sent within messages as the Segment ID followed by a sequence of data fields. The last field ends with the end-of-segment character, a carriage return. For example, the ORU message in Figure 9 contains the following segments: Message Header (MSH), Patient ID (PID), observation request (OBR) and observation/result (OBX) Fields Data fields are transmitted as character strings separated by characters that are data field separators. This recommendation includes segment attribute tables. These tables list and describe the data fields in the segment and characteristics of their usage. Figure 10 is an example of the attribute table that describes the MSH segment. The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message. The columns are described below. Figure 10. Sample Segment Attribute Table. SEQ LEN DT OPT RP/# TBL# ITEM # Element Name 1 1 ST R Field Separator 2 4 ST R Encoding Characters HD O Sending Application HD O Sending Facility HD O Receiving Application HD O Receiving Facility 7 26 TS R Date/Time Of Message 8 40 ST O Security 9 13 CM R Message Type ST R Message Control ID 11 3 PT R Processing ID VID R Version ID NM O Sequence Number ST O Continuation Pointer 15 2 ID O Accept Acknowledgment Type 16 2 ID O Application Acknowledgment Type 17 3 ID O Country Code ID O Y Character Set CE O Principal Language Of Message ID O Alternate Character Set Handling Scheme ID O Y Conformance Statement ID SEQ Position (sequence within the segment) This column defines the ordinal position of the data field within the segment. This number is used to refer to the data field in the text comments that follow the segment definition table. When combined with the segment ID it is often used to identify the data element; i.e., MSH-9 is the message type. Additional Information Message 19 NPRM Draft

23 LEN Maximum length Maximum number of characters that one occurrence of the data field may occupy. The maximum length is not of conceptual importance in the abstract message or the HL7 coding rules. The length of a field is normative. However, in general practice it is often negotiated on a site-specific basis. It is calculated to include the component and subcomponent separators that are defined below. Because the maximum length is that of a single occurrence, the repetition separator is not included in calculating the maximum length DT Data type Data types restrict the contents and specification of the format of the data field. There are a number of data types defined by HL7. These are explained in Section Many data types are complex constructs comprised of multiple components. For example, the HL7 person name data type (PN) has six components: family name, given name, middle initial or name, suffix, prefix, degree OPT Optionality Whether the field is required, optional, or conditional in a segment. The designations are: R - Required O - Optional C - Conditional on the trigger event or on some other field(s). The field definitions following the segment attribute table should specify the algorithm that defines the conditionality for this field. X - Not used with this trigger event B - Left in for backward compatibility with previous versions of HL7. The field definitions following the segment attribute table should denote the optionality of the field for prior versions. In the segment attribute tables this information is in a column labeled OPT RP# Repetition Whether the field may repeat. The designations are: N - No repetition Y - The field may repeat an indefinite or site-determined number of times Integer - The field may repeat up to the number of times specified in the integer Each occurrence may contain the number of characters specified by the field s maximum length. (See Section , LEN Maximum length. ) TBL# Table HL7 defines a table of values for this field. An entry in the table number column means that the table name and the element name are equivalent. Additional Information Message 20 NPRM Draft

24 The manner in which HL7 defines the valid values for tables will vary. Certain fields, like Patient Location, will have values that vary from institution to institution. Such tables are designated user- or site-defined. Even though these tables are not defined in the Standard, they are given a user-defined table number to facilitate implementations. The IS data type is often used to encode values for these tables. Note that some of these tables (e.g., location) may reference common master files. Others, like Event Type (HL7 table 0003), are a part of the HL7 Standard because they affect the interpretation of the messages that contain them. They are limited to the values established by the HL7 Standard. Still other tables contain values that are encoded by reference to other standards documents. The CE data type is used to encode values for these tables Item Number A small integer that uniquely identifies the data field throughout the Standard Element Name The field s descriptive name Message Delimiters In constructing a message, certain special characters are used. They are the segment terminator, the field separator, the component separator, subcomponent separator, repetition separator, and escape character. The segment terminator is always a carriage return (in ASCII, a hex 0D). The other delimiters are defined in the MSH segment, with the field delimiter in the 4th character position, and the other delimiters occurring as in the field called Encoding Characters, which is the first field after the segment ID. The delimiter values used in the MSH segment are the delimiter values used throughout the entire message. In the absence of other considerations, HL7 strongly recommends the suggested values found in Figure 11. Delimiter Segment Terminator Figure 11. HL7 Delimiters. Encoding Character Suggested Value Position <cr> hex 0D (this value required) Field Separator vertical bar Component Separator Subcomponent Separator ^ caret & ampersand Repetition Separator ~ tilde Usage - Terminates a segment record. Implementers cannot change this value. - Separates two adjacent data fields within a segment. It also separates the segment ID from the first data field in each segment. 1 Separates adjacent components of data fields, where allowed. 4 Separates adjacent subcomponents of data fields, where allowed. If there are no subcomponents, this character may be omitted. 2 Separates multiple occurrences of a field, where allowed. Additional Information Message 21 NPRM Draft

25 Delimiter Suggested Value Escape Character \ back slash Encoding Character Position Usage 3 Escape character for use with any field represented by an ST, TX or FT data type, or for use with the data (fourth) component of the ED data type. If no escape characters are used in a message, this character may be omitted. However, it must be present if subcomponents are used in the message Data Types As described in , when a field is described in a segment attribute table, one of the characteristics given is the data type. The data type declaration describes the format of the data. Many data types are compound. That means that a single occurrence of a data field that conforms to the data type may have multiple components. Components may be declared to have subcomponents. Additional Information Message 22 NPRM Draft

26 Data Type Category/ Data type Figure 12. HL7 Data Types. Data Type Name Comment Alphanumeric ST String TX Text data FT Formatted text Not used in Additional Information Message Numeric CQ Composite quantity Not used in Additional Information Message with units MO Money Not used in Additional Information Message NM Numeric SI Sequence ID SN Structured numeric Identifier ID Coded values for HL7 tables IS Coded value for userdefined tables HD Hierarchic designator EI Entity identifier RP Reference pointer PL Person location PT Processing type Date/Time DT Date TM Time TS Time stamp Coded Values CE Coded element CF Coded element with formatted values CK Composite ID with check digit CN Composite ID Not used in Additional Information Message number and name CX Extended composite ID with check digit XCN Extended composite ID number and name Generic CM Composite Demographics AD Address Not used in Additional Information Message PN Person name Not used in Additional Information Message TN Telephone number XAD Extended address XPN Extended person name XON Extended composite name and ID number Not used in Additional Information Message for organizations XTN Extended telecommunications number Not used in Additional Information Message Additional Information Message 23 NPRM Draft