Sie sind auf Seite 1von 184

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

National Electronic Data Interchange Transaction Set Implementation Guide

Additional Information to Support a Health Care Claim or Encounter 275


ASC X12N 275 (004050X151)

May 2004
MAY 2004

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

. Contact Washington Publishing Company for more Information.

www.wpc-edi.com
Third Printing

2004 WPC Copyright for the members of ASC X12N by Washington Publishing Company.
Permission is hereby granted to any organization to copy and distribute this material internally as long as this copyright statement is included, the contents are not changed, and the copies are not sold. This ASC X12N Implementation Guide incorporates copyrighted material from Health Level Seven, Inc. Please consult www.HL7.org for additional information.

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

Table of Contents
1 Purpose and Business Overview .................................... 7
1.1 Document Purpose........................................................................... 7
1.1.1 Trading Partner Agreements................................................... 8 1.1.2 HIPAA Role in Implementation Guides .................................. 8

1.2 Version and Release ....................................................................... 8 1.3 Business Use and Definition ........................................................ 9
1.3.1 Response to a Health Care Claim Request for Additional Information............................................................. 9 1.3.2 Unsolicited Additional Information to Support an 837 Health Care Claim sent within the same transmssion ......... 9

1.4 Information Flows .......................................................................... 10

2 Data Overview ............................................................................. 11


2.1 Overall Data Architecture ............................................................ 11 2.2 Data Use by Business Use .......................................................... 12
2.2.1 Table 1 Transaction Control Information ............................. 13 2.2.1.1 Transaction Identification and Purpose .................. 13 2.2.1.2 NM1 Loop Participants Identification Structure ...... 14 2.2.2 Table 2 Detail Information ..................................................... 17 2.2.2.1 Claim Level Additional Information ......................... 17 2.2.2.2 Revenue or Service Line Level Additional Information.............................................................. 20

2.3 Interaction with Other Transaction Sets ................................ 23


2.3.1 2.3.2 2.3.3 2.3.4 Request for Additional Information (277) ............................ 24 The Claim (837) ...................................................................... 24 The Functional Acknowledgment (997) ............................... 24 Associated Data (102)............................................................ 24

3 Transaction Sets ........................................................................ 25


3.1 Presentation Examples................................................................. 25 3.2 Implementation Usage .................................................................. 30
3.2.1 Industry Usage ....................................................................... 30 3.2.2 Loops ...................................................................................... 30

3.3 Transaction Set Listing ................................................................. 31


3.3.1 Implementation ...................................................................... 31 3.3.2 X12 Standard .......................................................................... 33

3.4 275 Segment Detail......................................................................... 36


ST BGN NM1 PER NM1 NM1 275 Transaction Header ......................................... 37 Beginning Segment ................................................ 39 Transaction Receiver.............................................. 41 Response Contact .................................................. 43 Submitter Information ............................................. 46 Service Provider Information .................................. 49

MAY 2004

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REF NM1 REF REF REF REF DTP LX TRN STC REF REF DTP DTP CAT EFI BIN SE

Provider Secondary Identification ........................... 52 Patient Name.......................................................... 54 Patient Account Number......................................... 57 Institutional Type of Bill ........................................... 59 Medical Record Number ......................................... 61 Claim Identification Number for Clearing Houses and Other Transmission Intermediaries..... 62 Institutional Claim Service Date.............................. 64 Assigned Number ................................................... 65 Payers Control Number/Providers Control Number................................................................... 66 Status Information .................................................. 68 Service Line Item Identification............................... 72 Procedure or Revenue Code.................................. 74 Service Line Date of Service .................................. 77 Date Additional Information Was Submitted ........... 79 Category of Patient Information Service ................. 80 Electronic Format Identification .............................. 82 Binary Data Segment ............................................. 84 275 Transaction Set Trailer..................................... 85

4 EDI Transmission Examples for Business Usages .............................................................................................. 87 A Nomenclature..............................................................................A.1


A.1 ASC X12 Nomenclature ...............................................................A.1
A.1.1 Interchange and Application Control Structures ...............A.1 A.1.1.1 Interchange Control Structure ...............................A.1 A.1.1.2 Application Control Structure Definitions and Concepts ...............................................................A.2 A.1.1.3 Business Transaction Structure Definitions and Concepts ...............................................................A.5 A.1.1.4 Envelopes and Control Structures.......................A.13 A.1.1.5 Acknowledgments ...............................................A.15

A.2 Other Syntaxes .............................................................................A.16

B EDI Control Directory ............................................................B.1


B.1 Control Segments ..........................................................................B.1
ISA IEA GS GE TA1 ST AK1 AK2 AK3 AK4 AK5 Interchange Control Header.................................................B.3 Interchange Control Trailer ..................................................B.7 Functional Group Header .....................................................B.8 Functional Group Trailer ....................................................B.10 Interchange Acknowledgment ........................................... B.11 Transaction Set Header ......................................................B.16 Functional Group Response Header.................................B.18 Transaction Set Response Header ....................................B.19 Data Segment Note .............................................................B.20 Data Element Note ..............................................................B.22 Transaction Set Response Trailer .....................................B.24
MAY 2004

B.2 Functional Acknowledgment Transaction Set, 997 .......B.15

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

AK9 Functional Group Response Trailer ..................................B.26 SE Transaction Set Trailer........................................................B.28

C External Code Sources ........................................................C.1


X12 Directories......................................................................C.1 Health Industry Number .......................................................C.1 Current Procedural Terminology (CPT) Codes ..................C.1 Health Industry Level 7 (HL7) ..............................................C.2 Health Care Claim Status Category Code...........................C.2 Centers for Medicare and Medicaid Services National Provider Identifier .................................................................C.2 540 Centers for Medicare and Medicaid Services PlanID ........C.3 663 Logical Observation Identifier Names and Codes (LOINC) ..................................................................................C.3 881 Version / Release / Industry Identifier Code .......................C.4 77 121 133 464 507 537

D Change Summary ....................................................................D.1


D.1 Change Summary ..........................................................................D.1

E Data Element Dictionary .....................................................E.1 F 102 Associated Data Transaction Set........................ F.1

MAY 2004

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

1 Purpose and Business Overview


1.1 Document Purpose
For the health care industry to achieve the potential administrative cost savings associated with Electronic Data Interchange (EDI), standards have been developed and need to be implemented consistently by all organizations. To facilitate a smooth transition into the EDI environment, uniform implementation is critical. The purpose of this implementation guide is to provide standardized data requirements and content to all users of ANSI ASC X12 275 Patient Information (275) Transaction Set. This Implementation guide focuses on the use of the 275 to send additional information about a claim or encounter. This implementation guide provides a detailed explanation of the transaction set by defining uniform data content, identifying valid code tables, and specifying values applicable for the business use of conveying Additional Information to Support a Health Care Claim or Encounter (275). The intention of the developers of the 275 is represented in the guide. This implementation guide describes a solution that includes the encapsulation of a Health Level Seven (HL7) Standard within the 275 transaction. HL7 is an ANSI Accredited Standards Development Organization (SDO) whose domain is clinical and administrative data. HL7s mission is: To provide standards for the exchange, management and integration of data that supports clinical patient care and the management, delivery and evalution of healthcare services. Specifically, to create flexible, cost effective approaches, standards, guidelines, methodologies, and related services for interoperability between healthcare information systems. HL7 is widely used in the United States as well as many other countries. For the purpose of this recommendation, the HL7 ANSI approved standard being proposed is the Clinical Document Architecture (CDA), as tailored for Claims Attachments. CDA is a standard that expresses data using Extensible Markup Language (XML). This implementation guide is designed to assist those who send additional supporting information or who receive additional supporting information to a claim or encounter using the 275 format. Entities that use this implementation of the 275 include but are not limited to, Health Plans, third party administrators (TPAs), managed care service organizations, state and federal agencies and their contractors, plan purchasers, and any other entity that processes health care claims, manages the delivery of health care services, or collects health care data. Other business partners affiliated with the 275 include but are not limited to billing services; consulting services, vendors of systems, software and EDI translators, and EDI network intermediaries such as Automated Clearing Houses (ACHs), Value Added Networks (VANs), and telecommunications services.

MAY 2004

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

1.1.1

Trading Partner Agreements


It is appropriate and prudent for payers to have trading partner agreements that go with the standard Implementation Guides. This is because there are 2 levels of scrutiny that all electronic transactions must go through. First is standards compliance. These requirements MUST be completely described in the Implementation Guides for the standards, and NOT modified by specific trading partners. Second is the specific processing, or adjudication, of the transactions in each trading partners individual system. Since this will vary from site to site (e.g., payer to payer), additional documentation which gives information regarding the processing, or adjudication, will prove helpful to each sites trading partners (e.g., providers), and will simplify implementation. It is important that these trading partner agreements NOT: Modify the definition, condition, or use of a data element or segment in the standard Implementation Guide Add any additional data elements or segments to this Implementation Guide Utilize any code or data values which are not valid in this Implementation Guide Change the meaning or intent of this Implementation Guide These types of companion documents should exist solely for the purpose of clarification, and should not be required for acceptance of a transaction as valid.

1.1.2

HIPAA Role in Implementation Guides


Administrative Simplification provisions of the Health Insurance Portability and Accountability Act of 1996 (PL 104-191 - known as HIPAA) direct the Secretary of Health and Human Services to adopt standards for transactions to enable health information to be exchanged electronically and to adopt specifications for implementing each standard. This implementation guide has been developed for use as an insurance industry implementation guide. At the time of publication it has not been adopted as a HIPAA standard. Should the Secretary adopt this implementation guide as a standard, the Secretary will establish compliance dates for its use by HIPAA covered entities.

1.2

Version and Release


This implementation guide is based on the October, 2001 ASC X12 standards, referred to as Version 4, Release 5 (004050). This implementation guide will incorporate the use of the ANSI accredited Standard Development Organization (SDO) HL7 Clinical Document Architecture (CDA) in the Binary Data Segment (BIN) within the 275 transaction.

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

1.3

Business Use and Definition


The ASC X12N 275 Patient Information transaction set is intended to meet the particular needs of the health care industry. The ASC X12N 275 Additional Information to Support a Healthcare Claim or Encounter is used to: Respond to an ASC X12N 277 Health Care Claim Request for Additional Information or a paper request for additional information. Provide unsolicited additional information to support an ASC X12N 837 Health Care Claim or Encounter sent within the same transmission. Other intended uses of the 275 transaction set includes the request and response of patient information from provider to provider and to provide unsolicited additional information to support an X12N 837 Health Care Claim or Encounter in support of statistical reporting and regulatory requirements. These uses are not supported by this Implementation Guide. This Implementation Guide was not written with the intent to send attachment data from payer to payer.

1.3.1

Response to a Health Care Claim Request for Additional Information


Typically, a claim that is subjected to Medical or Utilization review during the adjudication process is suspended by the payer. The payer then requests specific information to supplement or support the providers request for payment of the services. The payers request for additional information may be service specific or apply to the entire claim, the 277 is used to transmit the request. The provider uses the 275 to respond to the previously mentioned request. The 277 structure allows the payer to request additional information on multiple claims. However, the 275 transaction structure only allows the submitter to send additional information for one claim in each 275. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each claim response. The 275 can accommodate multiple responses for a specific claim. See the LX segment section for additional details. In the 277, the payer must specify the period of time in which the provider has to respond to the request for additional information. The 275 response must be received by the payer within the specified timeframe, or the claim in question will proceed to the next phase of the payers adjudication cycle. The ultimate disposition of the claim or service line can include, but is not limited to, rejection, or denial.

1.3.2

Unsolicited Additional Information to Support an 837 Health Care Claim sent within the same transmission
In situations where specific additional information is required by the payer to complete the adjudication process, and the provider is aware of the need for this additional information at the time of billing, they may include a 275 within the same interchange (ISA/IEA) of the initial 837. This situation will require separate GS/GE Functional Groups for the 837 and the 275. This eliminates the need for the payer to request additional information. See Section 4, Transmission Examples. The value in the 2300 PWK06 of the 837 and the 2000A TRN02 of the 275 are

MAY 2004

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

used as the main matching criteria. This value must be unique for each attachment.

1.4

Information Flows
Figure 1.1 illustrates the flow of information related to all uses of the 275 Additional Information to Support a Health Care Claim or Encounter.

837 837+275(+HL7)

Providers Hospitals Specialists PCPs

277 Payers 275(+HL7)

835

Note: For use of 997 by either partner refer to Section 2.3.3.

Figure 1.1. ANSI Standard EDI Health Care Transaction Flow

Arrow 1 Shows that claims can be transmitted in either of two methods, with or without an attachment. 837 - Standalone Claim or 837+275 (+ HL7) - Claim plus attachment information with HL7 embedded in the 275, sent in the same transmission (ISA/IEA) as the claim. Separate GS/GE Functional Groups will be required. Arrow 2 Some claims will require additional information to be sent to the payer before the adjudication cycle can be completed. If that information was not sent with the claim, the request for additional information will be made by the payer. Arrow 3 The provider will respond to the request for additional information by sending the 275 transaction set to the payer. This transaction will contain the Additional Information to Support a Health Care Claim or Encounter, which will be expressed as HL7. Arrow 4 The Health Care Claim Remittance (835) Transaction Set is sent to the provider when the claim has completed the adjudication process.

10

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

2 Data Overview
This section introduces the structure of the 275 and describes the positioning of the business data within that structure. Familiarity with ASC X12 nomenclature, segments, data elements, hierarchical levels, and looping structures is recommended. For a review, see Appendix A, ASC X12 Nomenclature, and Appendix B, EDI Control Directory.

2.1

Overall Data Architecture


Two formats or views are used to present the transaction set: the implementation view and the standard view. Figure 2.1, 275 Transaction Set Listing, shows the

Table 1 - Header
POS. # SEG. ID NAME USAGE REPEAT LOOP REPEAT

0100 ST 0200 BGN 0500 NM1 0900 PER 0500 NM1 0500 NM1 1000 REF 0500 1000 1000 1000 1000 NM1 REF REF REF REF

275 Transaction Header Beginning Segment LOOP ID - 1000A TRANSACTION RECEIVER Transaction Receiver Response Contact LOOP ID - 1000B SUBMITTER INFORMATION Submitter Information LOOP ID - 1000C SERVICE PROVIDER INFORMATION Service Provider Information Provider Secondary Information LOOP ID - 1000D PATIENT NAME Patient Name Patient Account Number Institutional Type of Bill Medical Record Number Claim Identification Number for Clearing Houses and Other Transmission Intermediaries Institutional Claim Service Date

R R R S R R S R R S S S S

1 1 1 1 1 1 1 1 1 5 1 1 1 1 1 1 1

1050 DTP

Table 2 - Detail
POS. # SEG. ID NAME USAGE REPEAT LOOP REPEAT

0100 0150 0175 0500 0500

LX TRN STC REF REF

LOOP ID - 2000A ASSIGNED NUMBER Assigned Number Payers Control Number/Providers Control Number Status Information Service Line Item Identification Procedure or Revenue Code LOOP ID - 2100A SERVICE LINE DATE OF SERVICE Service Line Date of Service LOOP ID - 2100B DATE ADDITIONAL INFORMATION WAS SUBMITTED Date Additional Information Was Submitted Category of Patient Information Service LOOP ID - 2110B ELECTRONIC FORMAT IDENTIFICATION Electronic Format Identification Binary Data 275 Transaction Set Trailer

>1 R R S S S S 1 1 1 1 1 1 1 1 R R 1 1 1 R R R 1 1 1

0600 DTP

0600 DTP 0700 CAT

0900 EFI 1000 BIN 1100 SE

Figure 2.1. 275 Transaction Set Listing


MAY 2004

11

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

implementation view. This view displays only the segments and their designated health care names described in this implementation guide. The intent of the implementation view is to clarify the purpose and use of the segments by restricting the view to display only those segments used with their assigned health care names. This implementation view is also repeated in Section 3. The standard view is presented in Section 3, Transaction Set. The standard view displays all segments available within the transaction set with their assigned ASC X12 names.

2.2

Data Use by Business Use


The 275 is divided into two tables. Table 1 contains transaction control information and is presented in 2.2.1. Table 2 contains the detail information for the business function of the transaction and is presented in 2.2.2. When a request for additional information is made, the payer supplies the parameters that assist the provider in locating the claim. These parameters are frequently the patient account number, type of bill, medical record number, procedure code or revenue code, and the date of service. The provider is the source of this information. If the information is found on the original billed claim, the payer returns these data elements in the ASC X12N 277 Health Care Claim Request for Additional Information. When the additional information is returned in the 275, it will either be related to the entire claim or for a specific revenue line or service line. The segments used to return the requested information are more clearly identified by specifying whether the information is related to the Claim Level or Service Line Level. The TRN segment is required and will either contain the payers control number, if sent in response to a 277 or the providers control number, if sent with the 837. See Section 3 for detail segment usage. The following table presents the developers view of segments returned for Claim Level information.
Loop ID 1000D Patient Name Segment ID NM1 REF REF REF REF Segment Name Patient Name Patient Account Number Institutional Type Of Bill Medical Record Number Claim Identification Number for Clearing Houses and Other Transmission Intermediaries Institutional Claim Service Date Assigned Number Payers Control Number/ Providers Control Number Status Information Date Additional Information Was Submitted Category of Patient Information Service Electronic Format Identification Binary Data Business Purpose Name of Patient Providers Patient Account Number Institutional Type of Bill Medical Record number from the original claim A claim identification number for Clearing Houses and Other Transmission Intermediaries.

DTP 2000A Assigned Number LX TRN STC 2100B Date Additional Information Submitted DTP CAT 2110B Electronic Format Identification EFI BIN

Institutional Claim Service Date A sequence number that starts at 1 and is incremented by 1 when the loop is repeated. Control Number assigned by either the Payer or Provider. Echo back the STC segment that was given in the 277 The 275 Submittal Date. Needed in order to use the BIN Segment Used to identify the type of information that will be in the BIN Security Level of Data. Needed in order to use BIN Segment Data in HL7 standard

12

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

The following table presents the developers view of segments returned for Service Line Level information.
Loop ID 1000D Patient Name Segment ID NM1 REF REF REF REF Segment Name Patient Name Patient Account Number Institutional Type Of Bill Medical Record Number Claim Identification Number for Clearing Houses and Other Transmission Intermediaries Institutional Claim Service Date Assigned Number Payers Control Number/ Providers Control Number Claim Status Information Service Line Item Identification Business Purpose Name of Patient Providers Patient Account Number Institutional Type of Bill Medical Record number from the original claim A claim identification number for Clearing Houses and Other Transmission Intermediaries.

DTP 2000A Assigned Number LX TRN STC REF REF 2100A Service Line Date of Service 2100B Date Additional Information Submitted DTP DTP CAT 2110B Electronic Format Identification EFI BIN

Institutional Claim Service Date A sequence number that starts at 1 and is incremented by 1 when the loop is repeated. Control Number assigned by either the Payer or Provider. Echo back the STC segment that was given in the 277 Line Item control number

Procedure or Revenue Code Specific Revenue Code or Procedure Code that additional information supports Service Line Date of Service Service Line Date of Service Date Additional Information Was Submitted Category of Patient Information Service Electronic Format Identification Binary Data The 275 Submittal Date. Needed in order to use the BIN Segment Used to identify the type of information that will be in the BIN Security Level of Data. Needed in order to use BIN Segment Data in HL7 standard

2.2.1

Table 1 Transaction Control Information


Table 1 is named the Header Level. The purpose of Table 1 is to identify the transaction, distinguish the business purpose, and identify the participants. See Figure 2.2 for an example of Table 1.

2.2.1.1

Transaction Identification and Purpose


The Transaction Set Header Segment (ST) identifies the transaction set by using 275 as the data value for the transaction set identifier code data element, ST01. The originator of the transaction set assigns the unique control number ST02 which is shown here as 0001. In this example, the originator is the provider. ST03 carries the same value that is populated in GS08 which is the Implementation Version Identifier. For the 275 transaction this is 004050X151. The 275 transaction structure only allows the submitter to send additional information for one claim in each 275. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each claim response. However, the 275 can accommodate multiple attachments for a specific claim. See the LX segment section for additional details. The Beginning Segment (BGN) indicates the transaction use. The Transaction Set Purpose Code value of 11" in the BGN01 indicates that this 275 is a response to a 277 Health Care Claim Request for Additional Information. A value of 02" indicates that this 275 is additional information for an 837 claim or encounter in the same transmission. The originator of the transaction set assigns

MAY 2004

13

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

Table 1 - Header
POS. # SEG. ID NAME USAGE REPEAT LOOP REPEAT

0100 ST 0200 BGN 0500 NM1 0900 PER 0500 NM1 0500 NM1 1000 REF 0500 1000 1000 1000 1000 NM1 REF REF REF REF

275 Transaction Header Beginning Segment LOOP ID - 1000A TRANSACTION RECEIVER Transaction Receiver Response Contact LOOP ID - 1000B SUBMITTER INFORMATION Submitter Information LOOP ID - 1000C PROVIDER INFORMATION Provider Information Provider Secondary Information LOOP ID - 1000D PATIENT NAME Patient Name Patient Account Number Institutional Type of Bill Medical Record Number Claim Identification Number for Clearing Houses and Other Transmission Intermediaries Institutional Claim Service Date

R R R S R R S R R S S S S

1 1 1 1 1 1 1 1 1 5 1 1 1 1 1 1 1

1050 DTP

Figure 2.2. Table 1 - Header Level

the unique reference number in BGN02 and the date of creation in BGN03. The Functional Group Header Segment (GS) provides additional identification of the business purpose of multi-functional transaction sets. See Appendix B, EDI Control Directory, for a detailed description of the elements in the GS segment. A coding example of Table 1 in the 275 Additional Information to Support a Health Care Claim or Encounter follows. See Appendix A, ASC X12 Nomenclature, for descriptions of data element separators (e.g., *) and segment terminators (e.g., ~). See the HL7 documents for XML tag names to be used in the BIN segment.

ST*275*0001*004050X151~ BGN*11*1*20030724~

2.2.1.2

NM1 Loop Participants Identification Structure


The Loop ID 1000 is repeated to define the participants involved in the transaction. The participants identified in the 275 are generally the transaction receiver (payer), submitter (e.g., service bureau, clearinghouse, provider groups), provider, and patient. The implementation guide specifies the participants in the subsequent loops within the transaction set and refers to these participants, respectively, in the following order and terms: Transaction Receiver - This entity is the decision maker in the business transaction. For this business use, this entity is the payer, even when the transaction is sent to a clearinghouse for forwarding to a payer. Submitter -This entity is the sender of the transaction. For this business use, this entity can be a provider, a provider group, a clearinghouse, a service bureau, an employer, etc. Provider -This entity delivered the health care service.

14

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

Patient - This is the person who received the services. The additional information is being sent to support the claim or encounter related to those services. Transaction Participants A detailed view of the segments and data elements used to describe the participants and their relationships is presented here. The segments and data elements are found in the 1000 Loop and the 2000 Loop. The coding examples are presented sequentially as found within an actual transaction set; however, for reading ease each segment begins on a new line. The following example demonstrates coding for segments and data elements: Transaction Receiver

NM1*40*2*ABC INSURANCE COMPANY*****46*12345~ PER*IC*MEDICAL REVIEW DEPARTMENT~


Submitter

NM1*41*2*XYZ BILLING SERVICE*****46*X100~


Provider

NM1*1P*2*ST HOLY HILLS JOSEPH HOSPITAL* ****SV*399999~


Patient

NM1*QC*1*SMITH*JOHN****MI*111223333A~ REF*EJ*JS960503LAB~ DTP*434*RD8*20030701-20030715~


NM1 Segment at the 1000A Loop The NM1 segment is required and is used to identify the transaction participants.

NM1*40*2*ABC INSURANCE COMPANY*****46*12345~


Within the NM1 segment, NM101 = 40 This value indicates that the participant is a receiver. NM102 = 2 This value indicates that the entity is a nonperson. An entity that is a person is identified with a value of 1. When the entity is a person, NM103 and NM104 contain the last and first names, respectively. NM103 = ABC INSURANCE COMPANY This value identifies the Information Source as ABC INSURANCE COMPANY. NM108 = 46 This value identifies the next data element as the assigned Payer Identification. NM109 = 12345 The NM109 value is the actual identification code associated with NM108 (e.g., Pl). The identification code listed in NM109 refers to ABC INSURANCE Company. PER Segment at the 1000A Loop The payer uses the PER segment in the 277 to specify the administration communications contact who should receive the additional information when returned by
MAY 2004

15

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

the provider. The PER segment of the Transaction Receiver NM1 (Loop 1000A) in the 275 is used to identify the entity who is expecting to receive the additional information from the provider. The following example demonstrates the identification of the entity to whom the provider should return the additional information:

PER*IC*MEDICAL REVIEW DEPARTMENT~


Within the PER, PER01 = IC This value indicates that the person or group named is the Information Contact. PER02 = MEDICAL REVIEW DEPARTMENT This value is the person or group name. REF Segment at the 1000D Loop The REF segment can be repeated a maximum of four times at the Patient 1000D loop level for this implementation. The providers patient account number, the institutional Type of Bill, the Medical Record Number and the Claim Identification Number for Clearing Houses and Other Transmission Intermediaries. The following are coding examples of the REF segment:

REF*EJ*JS960503LAB~ REF*BLT*131~ REF*EA*STHH12345~ REF*D9*23235~


Within the REF, REF01 = EJ This value indicates that the next data element contains the Patient Account Number. REF02 = JS960503LAB The value shown is the actual Patient Account Number assigned by the provider for the claim. When REF01 is BLT, REF02 contains the institutional type of bill (e.g., 131). When REF01 is EA, REF02 contains the medical record number (e.g., STHH12345). When REF01 is D9, REF02 contains the claim identification number for clearing houses and other transmission intermediaries (e.g. 23235). The order of the REF segments are not significant. DTP Segment at the 1000D Loop This segment occurs once at the 1000D loop for this implementation. The occurrence specifies the Claim Statement Period as supplied by the claim originator and is only required for institutional claims. The dates must be returned by the provider to the payer. The following is a coding example of the DTP segment:

DTP*434*RD8*20030705-20030715~
Within the DTP,

16

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

DTP01 = 434 This value indicates Statement Period Date. This means that the data element found in DTP03 represents the statement from and through dates for the claim. DTP02 = RD8 This value indicates that the next data element, DTP03, is a range of dates expressed in the format CCYYMMDD-CCYYMMDD. DTP03 = 20030705-20030715 This represents the actual statement from and through Dates found on the original claim.

2.2.2

Table 2 Detail Information


The structure used in Table 2 is based on the 2000A loop. The 2000A and its subordinate loops (loops 2100A, 2100B, 2110B) specify the additional information provided to support a claim or encounter. Figure 2.3, Table 2 - Detail Level, presents the segments used in Table 2 of the 275. These segments define the specific information that can be sent.

Table 2 - Detail
POS. # SEG. ID NAME USAGE REPEAT LOOP REPEAT

0100 0150 0175 0500 0500

LX TRN STC REF REF

LOOP ID - 2000A ASSIGNED NUMBER Assigned Number Payers Control Number/Providers Control Number Status Information Service Line Item Identification Procedure or Revenue Code LOOP ID - 2100A SERVICE LINE DATE OF SERVICE Service Line Date of Service LOOP ID - 2100B DATE ADDITIONAL INFORMATION WAS SUBMITTED Date Additional Information Was Submitted Category of Patient Information Service LOOP ID - 2110B ELECTRONIC FORMAT IDENTIFICATION Electronic Format Identification Binary Data Segment 275 Transaction Set Trailer

>1 R R S S S S 1 1 1 1 1 1 1 1 R R 1 1 1 R R R 1 1 1

0600 DTP

0600 DTP 0700 CAT

0900 EFI 1000 BIN 1100 SE

Figure 2.3. Table 2 - Detail Level

2.2.2.1

Claim Level Additional Information


The following is a coding example of the 275 when providing claim level additional information.

LX*1~ TRN*2*1722634842~ STC*R3:18682-5::LOI~ DTP*368*D8*20030724~ CAT*AE*HL~ EFI*05~


MAY 2004

17

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

BIN*10*XXXXXXXXXX~
LX Segment The LX segment begins the detailed additional information that is being sent to the payer. The occurrence is 1 or more. The LX loop will begin each time the submitter is starting another response to a different STC or sending another type of additional information for a specific claim. The following is a coding example of the LX segment:

LX*1~
Within the LX, LX01 is the sequence number assigned to identify the group of segments that follow. The LX01 sequence number must start at 1 and increment by 1.

NOTE: Each 275 must only reference one claim. However, the LX loop allows for multiple attachments to any one claim.
TRN Segment The Trace Segment (TRN) is a required segment. The 2000A TRN segment contains either the payers or the providers control number. In the unsolicited 275 transaction, the TRN segment will contain the providers control number to link the 275 attachment data to the 837 claim or encounter. In the solicited 275, the TRN segment will contain the payers control number that was originally sent in the 2200D loop TRN segment of the 277. The following is a coding example of the TRN segment:

TRN*2*1722634842~
TRN01 = 2 The value in TRN01 will be 2 when this transaction is a response to a 277. TRN02 = 1722634842 The value shown is the payers control number that was given in the 2200D or 2200E loop TRN segment of the 277. This value must be returned in the TRN segment of the 2000A loop in the 275. TRN01 will be a 1" when this transaction is additional information for an 837. When submitting additional information to support an 837 claim within the same transmission, the originator of the transaction will place the Attachment Control Number that was given in the PWK segment of the 837 claim or encounter in TRN02 of the 275. STC Segment The purpose of the STC segment in loop 2000A is for the provider to return the Logical Observation Identifier Names and Codes (LOINC) Code List code that identifies the payers question from the STC segment of the 277. For further details, refer to the 277 Implementation Guide. When the 277 claim level STC01 is the place holder value of R0:19016-5::LOI, this information must not be returned in the 275. When the STC at the claim level of the 277 is populated with this value it indicates that the request for information is conveyed at the service line level STC. Esentially it points you to the service line level to identify the request.

18

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

The following is a coding example of requested additional information at the claim level:

STC*R3:18682-5::LOI~
Within the STC, STC01-1 = R3 This value indicates that the claim has been suspended for additional information/documentation. STC01-2 = 18682-5 This LOINC code value indicates ambulance certification. STC01-4 = LOI This value indicates that table used for STC01-2 was the LOINC code list. DTP Segment The DTP segment at the start of the 2100B loop identifies the date the information was submitted to the payer. This segment is required in order to use the BIN segment. The following is a coding example of the DTP segment at the claim level:

DTP*368*D8*20030724~
Within the DTP segment at the 2100B loop, DTP01 = 368 This value is the date/time qualifier element. When the value is 368, the date found in DTP03 is known to be the submitted date. DTP02 = D8 This value is the date/time period format qualifier. When this value is D8, the format of the date in DTP03 is known to be CCYYMMDD. DTP03 = 20030724 The date represented in DTP03 is the submitted date for this information. CAT Segment The CAT segment in loop 2100B conveys the format and type of information reported in the BIN segment. The following is a coding example of the CAT segment at the claim level.

CAT*AE*HL~
Within the CAT, CAT01 = AE This value indicates the data in the BIN segment will be an attachment. CAT02 = HL The value shown indicates the data within the BIN segment will be in the HL7 Standard. EFI Segment The EFI segment in the 2110B loop is required. It is used to convey the level of confidentiality of the information in the BIN segment. The following is a coding example of the EFI segment at the claim level:

EFI*05~
Within the EFI,
MAY 2004

19

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

EFI01 = 05 This value represents that the security level has been defined as personal. BIN Segment The BIN segment in the 2110B loop is used to hold the additional information. It allows for the use of the HL7 standard in cases where it is not a HIPAA adopted attachment and requires it in cases where it is a HIPAA adopted standard.

BIN*10*XXXXXXXXXX~
Within the BIN, BIN01 = 10 This represents the number of bytes of data that will follow. BIN02 is where the HL7 standard begins and will be ended by the segment delimiter.

NOTE: For complete details on the HL7 documentation for claims attachments, please see the HL7 Additional Information Specification Implementation Guide and the associated Additional Information Specificiation attachment documents accompanying this implementation guide.

2.2.2.2

Revenue or Service Line Level Additional Information


The following is a coding example of the 275 when providing service line level additional information in response to a 277.

LX*1~ TRN*2*1722634842~ STC*R3:11504-8::LOI~ REF*FJ*1234~ REF*CPT*44499~ DTP*472*D8*20030704~ DTP*368*D8*20030724~ CAT*AE*HL~ EFI*05~ BIN*52*XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXX~
LX Segment The LX segment begins the detailed additional information that is being sent to the payer. The occurrence is 1 or more. The LX loop will begin each time the provider is starting another response to a different STC or sending another type of additional information for the patient or claim. The following is a coding example of the LX segment:

LX*1~
Within the LX, LX01 is the sequence number assigned to identify the group of segments that follow. The LX01 sequence number must start at 1 and increment by 1. TRN Segment

20

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

The Trace Segment (TRN) is a required segment. The TRN segment serves two purposes. First, the attachment control number, when transmitted in the unsolicited 275 transaction will contain the key information the provider utilizes to extract patient medical record information or attachment data needed to support the claim or encounter. The second scenario involves a solicited response to a request for additional information from a payer. In this situation, the attachment control number contains the key in the payers system to trace and match the response to the appropriate request for additional information. The following is a coding example of the TRN segment:

TRN*2*1722634842~
TRN01 = 2 The value in TRN01 will be 2 when this transaction is a response to a 277. TRN01 will be 1 when this transaction is additional information for an 837. TRN02 = 1722634842 The value shown is the payers control numbers that was given in the 2200D loop TRN segment of the 277. This value must be returned in the TRN segment of the 2000A loop in the 275. When submitting additional information to support an 837 claim within the same transmission, the originator of the transaction will replicate the Attachment Control Number that was given in the PWK segment of the 837 claim or encounter. STC Segment The purpose of the STC segment in loop 2000A is for the provider to return the LOINC code that identifies the payers question in the STC segment of the 277. The following is a coding example of requested additional information at the service line level:

STC*R3:11504-8::LOI~
Within the STC, STC01-1 = R3 This value indicates that the claim has been suspended for additional information/documentation. STC01-2 = 11504-8 This LOINC code value indicates the description of a surgical procedure. STC01-4 = LOI This value indicates the table used for STC01-2 was the Logical Observation Identifier Names and Codes (LOINCTM) Code List. REF Segment at Loop 2000A The REF segment identifies the specific revenue/service line in question or it can be used to identify the line item control number. On both institutional and professional claims there could be additional information that is sent for multiple services. The following are coding examples of the REF segment: Identifying a specific revenue/service line by the Line Item Control Number

REF*FJ*1234~
Identifying a specific revenue/service line by the procedure code.

REF*CPT*44499~
MAY 2004

21

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

Within the REF, REF01 = CPT This value indicates that the next data element contains the procedure code. REF02 = 44499 The value shown is the procedure code that was submitted on the claim in question. The payer returns the value in the SVC segment of the 277. It is also used by the provider when submitting additional information to support a claim. This element can be used to match the additional information to a particular revenue/service line. When REF01 is FJ, REF02 contains the Line Item Control Number DTP Segment - Date of Service This DTP segment is in the 2100A loop. At this location and in this example, the DTP segment identifies the date the service was performed and is only used when the additional information applied to a specific service line. The following is a coding example of the DTP segment at the service line level:

DTP*472*D8*20030804~
Within the DTP segment in the 2100A loop, DTP01 = 472 This value is the date/time qualifier element. When the value is 472", the date found in DTP03 is known to be the date of service. DTP02 = D8 This value is the date/time period format qualifier. When this value is D8", the format of the date in DTP03 is known to be CCYYMMDD. DTP03 = 20030804 The date, represented in DTP03, is the date of service, as defined by the prior qualifiers. DTP Segment - Date Additional Information was Summitted The DTP segment in the 2100B loop identifies the date the additional information was submitted. This segment is required. The following is a coding example of the DTP segment at the service line level:

DTP*368*D8*20030826~
Within the DTP segment in the 2100B loop, DTP01 = 368 This value is the date/time qualifier element. When the value is 368", the date found in DTP03 is known to be the submitted date. DTP02 = D8 This value is the date/time period format qualifier. When this value is D8", the format of the date in DTP03 is known to be CCYYMMDD. DTP03 = 20030826 The date range represented in DTP03 is the submitted date for the additional information reported in the BIN segment. CAT Segment

22

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

The CAT segment in loop 2100B conveys the type of information and the format type of the information reported in the BIN segment. The following is a coding example of the CAT segment at the service line level:

CAT*AE*HL~
Within the CAT, CAT01 = AE This value indicates the data in the BIN segment will be an attachment. CAT02 = HL The value shown indicates the data within the BIN segment will be in the HL7 format. EFI Segment The EFI segment in the 2110B loop is required. It is used to convey the level of confidentiality of the information in the BIN segment. The following is a coding example of the EFI segment at the service line level:

EFI*05~
Within the EFI, EFI01 = 05 This value represents that the security level has been defined as personal. BIN Segment The BIN segment in the 2110B loop is used to hold the additional information. It allows for the use of the HL7 standard in cases where it is not a HIPAA adopted attachment and requires it in cases where it is a HIPAA adopted standard.

BIN*52*XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXX~
Within the BIN, BIN01 = 52 This represents the number of bytes of data that will follow. BIN02 is where the HL7 Standard begins and will be ended by the segment delimiter.

NOTE: For complete details on the HL7 documention on claims attachments, please see the HL7 Additional Information Specification Implementation Guide and the associated Additional Information Specification Attachment documents that accompany the Implementation Guide.

2.3

Interaction with Other Transaction Sets


This section presents an overview of related ASC X12N transaction sets and discusses their direct or indirect interaction with the 275 Additional Information to Support a Health Care Claim or Encounter (X151).

2.3.1

The Request for Additional Information (277)


Submitting a claim, by using the 837 or another format, is the first step in the claim adjudication process. All data elements found on the original bill have their

MAY 2004

23

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

source from the providers billing system. When a claim does not include enough information to complete the payers adjudication process, the payer can electronically request the information using the 277 Health Care Claim Request for Additional Information (X150). Data from the original claim is included on the 277 to assist with locating the claim or the supporting information.

2.3.2

The Claim (837)


Submitting a claim by using the 837 is the first step in the adjudication process. All data elements found on the original bill have their source from the providers billing system. When a claim needs additional information to complete the adjudication process, the provider can send an unsolicited 275 Additional Information to Support a Health Care Claim or Encounter (X151) within the same Interchange as the 837.

2.3.3

The Functional Acknowledgment (997)


The Functional Acknowledgment (997) transaction is used upon request by one of the trading partners. A 997 can be used by the following: the payer to acknowledge claim receipt (837) the payer to acknowledge claim receipt (837) and Additional Information to Support a Health Care Claim or Encounter (275) the provider to acknowledge receipt of a Health Care Claim Request for Additional Information (277) the payer to acknowledge the receipt of an Additional Information to Support a Health Care Claim or Encounter (275) the provider to acknowledge receipt of a Health Care Claim Payment Advice (835)

2.3.4

Associated Data (102)


The Associated Data (102) will be used to provide HL7 syntax validation. It can be requested by one of the trading partners. This transaction set is used to acknowledge (accept/reject) the HL7 standard in the 275 BIN segment. This transaction is based on mutual agreement between trading partners, unless mandated under HIPAA. If not mandated the authors strongly suggest the use of the 102 Transaction.

24

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

3 Transaction Set
NOTE See Appendix A, Nomenclature, to review the transaction set structure, including descriptions of segments, data elements, levels, and loops.

3.1

Presentation Examples
The ASC X12 standards are generic. For example, multiple trading communities use the same PER segment to specify administrative communication contacts. Each community decides which elements to use and which code values in those elements are applicable. This implementation guide uses a format that depicts both the generalized standard and the insurance industry-specific implementation. In this implementation guide, IMPLEMENTATION specifies the requirements for this implementation. X12 STANDARD is included as a reference only. The transaction set presentation is comprised of two main sections with subsections within the main sections: 3.3 Transaction Set Listing There are two sub-sections under this general title. The first sub-section concerns this implementation of a generic X12 transaction set. The second sub-section concerns the generic X12 standard itself. IMPLEMENTATION This section lists the levels, loops, and segments contained in this implementation. It also serves as an index to the segment detail. STANDARD This section is included as a reference. The implementation guide reference clarifies actual usage. 3.4 Segment Detail There are four sub-sections under this general title. This section repeats once for each segment used in this implementation providing segment specific detail and X12 standard detail. IMPLEMENTATION This section specifies the segments, data elements, and codes for this implementation. STANDARD This section is included as a reference. DIAGRAM This section is included as a reference. It provides a pictorial view of the standard and shows which elements are used in this implementation.

MAY 2004

25

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

ELEMENT SUMMARY This section specifies the implementation details of each data element. Annotated illustrations, presented below in the same order they appear in this implementation guide, describe the format of the transaction set that follows.

26

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

IMPLEMENTATION Indicates that this section is the implementation and not the standard

800
NAME

Insurance Transaction Set

Table 1 - Header
PAGE # POS. # SEG. ID USAGE REPEAT LOOP REPEAT

53 54 60 62 65 66 68 70 72 75 76 78 79 81 82 84

010 020 040 050 060 060 070 080 100 110 120 130 080 100 110 120

ST BPR TRN CUR REF REF DTM N1 N3 N4 REF PER N1 N3 N4 REF

Transaction Set Header Financial Information Reassociation Key Non-US Dollars Currency Receiver ID Version Number Production Date

Each segment is assigned an industry specific name. Not used segments do not appear Each loop is assigned an industry specific name

R R R S S S S R S S S S R S S S

1 1 1 1 1 1 1 1 1 1 1 1

Segment repeats and loop repeats reflect actual usage

PAYER NAME Payer Name Payer Address Payer City, State, Zip Additional Payer Reference Number Payer Contact PAYEE NAME Payee Name Payee Address Payee City, State, Zip Payee Additional Reference Number

1 R=Required S=Situational

1 1 1 1 >1

Position Numbers and Segment IDs retain their X12 values

Individual segments and entire loops are repeated

Figure 1. Transaction Set Key Implementation

STANDARD

Indicates that this section is identical to the ASC X12 standard See Appendix A, ASC X12 Nomenclature for a complete description of the standard

800

Insurance Transaction Set


Functional Group ID:

XX

This Draft Standard for Trial Use contains the format and establishes the data contents of the Insurance Transaction Set (800) within the context of the Electronic Data Interchange (EDI) environment.

Table 1 - Header
POS. # SEG. ID NAME REQ. DES. MAX USE LOOP REPEAT

010 020 030 040

ST BPR NTE TRN

Transaction Set Header Beginning Segment Note/Special Instruction Trace

M M O O

1 1 >1 1

Figure 2. Transaction Set Key Standard

MAY 2004

27

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

IMPLEMENTATION Industry Usage Industry Segment Repeat

PAYER NAME
Loop: Usage: Repeat: Loop OD: Segment OD: Advisory: Notes:

Industry assigned Segment Name

Industry Notes Example

1000A PAYER IDENTIFICATION Repeat: 1 Industry Loop Repeat SITUATIONAL Industry assigned Loop ID and Loop Name 1 Object Descriptors, see Appendix A.2 800_A1_1000A for additional information 800_A1_1000A_N1 Under most circumstances, this segment is expected to be sent. 1. This N1 loop provides the name/address information for the payer. The payers secondary identifying reference number should be provided in N104, if necessary.

Example: N1PRINSURANCE COMPANY OF TIMBUCKTUNI88888888~

Figure 3. Segment Key Implementation

STANDARD

N1 Name
Level: Header Position: 080 Loop: N1 Repeat: 200 Requirement: Max Use: Purpose: Syntax:

X12 ID and Name X12 Level X12 Position Number X12 Loop Information X12 Requirement

Optional X12 Maximum Use 1 To identify a party by type of organization, name and code 1 R0203 At least one of N102 or N103 is required. 2 P0304 If either N103 or N104 is present, then the other is required.

X12 Syntax Notes

Figure 4. Segment Key Standard

DIAGRAM Indicates a Required Element


N101 98 N102

Element Delimiter
93 N103

Abbreviated Element Name


66 N104 67 N105 706 N106

Segment Terminator
98

N1
Segment ID

Entity ID Code
M1 ID 2/2

X1

Name
AN 1/35

ID Code Qualifier
X1 ID 1/2

X1

ID Code
AN 2/20

Entity Relat Code


O1 ID 2/2

Entity ID Code
O1 ID 2/2

Requirement Designator

Minimum/ Maximum Length

Data Type

Element Repeat

Indicates a Situational Element

Indicates a Not Used Element

Figure 5. Segment Key Diagram

28

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

SITUATIONAL
Industry Usages: See the following page for complete descriptions

EQ01
Data Element Number

1365

Service Type Code Code identifying the classification of service


OD:

X 99 ID

2/3

270A1_2110C_EQ01__ServiceType Code R0102

Element Repeat

SYNTAX:

SEMANTIC: Position

of data in the repeating data element conveys no

Object Descriptor, see Appendix A.2 for 90147 additional information X12 Syntax Note X12 Semantic Note Industry Note

significance.

Not used if EQ02 is used.


CODE DEFINITION

1 2

Medical Care Surgical

Selected Code Values

SITUATIONAL

EQ02

C003

Reference Designator Composite Number

COMPOSITE MEDICAL PROCEDURE X1 IDENTIFIER To identify a medical procedure by its standardized codes and applicable modifiers
OD:

270A1_2110C_EQ02_C003

90147
REQUIRED EQ02 - 1

Not used if EQ01 is used. 235 Product/Service ID Qualifier M ID 2/2 Code identifying the type/source of the descriptive number used in Product/Service ID (234)

Industry Name See Appendix E for definition Alias Name

OD:

270A1_2110C_EQ02_C00301_ProductServiceIDQualifier

INDUSTRY: ALIAS:

Product or Service ID Qualifier

Procedure Code Qualifier

90147

Use this code to qualify the type of specific Product/Service ID that will beused in EQ02-2.
CODE DEFINITION

See Appendix C for external code source reference

AD CJ

American Dental Association Codes


CODE SOURCE 135:

American Dental Association Codes

Current Procedural Terminology (CPT) Codes


CODE SOURCE 133:

Current Procedural Terminology (CPT)

Codes

Figure 6. Segment Key Element Summary

MAY 2004

29

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

3.2
3.2.1

Implementation Usage
Industry Usage
Industry Usage describes when loops, segments, and elements are to be sent. The three choices for Usage are required, not used, and situational. To avoid confusion, these are named differently than the X12 standard Condition Designators (mandatory, optional, and relational). Required this loop/segment/element must always be sent when complying with this implementation guide. this loop/segment/element must never be sent when complying with this implementation guide. use of this loop/segment/element varies, depending on data content and business context as described in the defining rule. The defining rule is documented in a note attached to the item. The item is required when the situation defined in the note is true; otherwise the item is not used.

Not Used

Situational

3.2.2

Loops
Loop usage within ASC X12 transactions and their implementation guides can be confusing. Care must be used to read the loop requirements in terms of the context or location within the transaction. A nested loop can be used only when the associated higher level loop is used. The usage of a loop is the same as the usage of its beginning segment. If a loops beginning segment is Required, the loop is Required and must occur at least once unless it is nested in a loop that is not being used. If a loops beginning segment is Situational, the loop is Situational. Subsequent segments within a loop can be sent only when the beginning segment is used. Required segments in Situational loops occur only when the loop is used.

30

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

3.3
3.3.1

Transaction Set Listing


Implementation
This section lists the levels, loops, and segments contained in this implementation. It also serves as an index to the segment detail. Refer to section 3.1 Presentation Examples for detailed information on the components of the Implementation section.

MAY 2004

31

004050X151 275
004050X151 275

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

APRIL 28, 2004 IMPLEMENTATION

275

Patient Information

Additional Information to Support a Health Care Claim or Encounter

Table 1 - Header
PAGE # POS. # SEG. ID NAME USAGE REPEAT LOOP REPEAT

37 39 41 43 46 49 52 54 57 59 61 62 64

0100 ST 0200 BGN 0500 NM1 0900 PER 0500 NM1 0500 NM1 1000 REF 0500 1000 1000 1000 1000 NM1 REF REF REF REF

275 Transaction Header Beginning Segment LOOP ID - 1000A TRANSACTION RECEIVER Transaction Receiver Response Contact LOOP ID - 1000B SUBMITTER INFORMATION Submitter Information LOOP ID - 1000C SERVICE PROVIDER INFORMATION Service Provider Information Provider Secondary Identification LOOP ID - 1000D PATIENT NAME Patient Name Patient Account Number Institutional Type of Bill Medical Record Number Claim Identification Number for Clearing Houses and Other Transmission Intermediaries Institutional Claim Service Date

R R R S R R S R R S S S S

1 1 1 1 1 1 1 1 1 5 1 1 1 1 1 1 1

1050 DTP

Table 2 - Detail
PAGE # POS. # SEG. ID NAME USAGE REPEAT LOOP REPEAT

65 66 68 72 74 77

0100 0150 0175 0500 0500

LX TRN STC REF REF

LOOP ID - 2000A ASSIGNED NUMBER Assigned Number Payers Control Number/Providers Control Number Status Information Service Line Item Identification Procedure or Revenue Code LOOP ID - 2100A SERVICE LINE DATE OF SERVICE Service Line Date of Service LOOP ID - 2100B DATE ADDITIONAL INFORMATION WAS SUBMITTED Date Additional Information Was Submitted Category of Patient Information Service LOOP ID - 2110B ELECTRONIC FORMAT IDENTIFICATION Electronic Format Identification Binary Data Segment 275 Transaction Set Trailer

>1 R R S S S S 1 1 1 1 1 1 1 1 R R 1 1 1 R R R 1 1 1

0600 DTP

79 80

0600 DTP 0700 CAT

82 84 85

0900 EFI 1000 BIN 1100 SE

32

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275

3.3.2

X12 Standard
This section is included as a reference. The implementation guide reference clarifies actual usage. Refer to section 3.1 Presentation Examples for detailed information on the components of the X12 Standard section.

MAY 2004

33

004050X151 275 STANDARD

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

275

Patient Information
Functional Group ID: PI
This X12 Transaction Set contains the format and establishes the data contents of the Patient Information Transaction Set (275) for use within the context of an Electronic Data Interchange (EDI) environment. This transaction set can be used to communicate individual patient information requests and patient information (either solicited or unsolicited) between separate health care entities in a variety of settings to be consistent with confidentiality and use requirements. Patient information consists of demographic, clinical, and other supporting data.

Table 1 - Header
PAGE #
POS. # SEG. ID NAME REQ. DES. MAX USE LOOP REPEAT

0100 0200 0300 0400 0500 0600 0700 0800 0900 1000 1050

ST BGN DTM TRN NM1 IN1 DMG PRV PER REF DTP

Transaction Set Header Beginning Segment Date/Time Reference Trace LOOP ID - NM1 Individual or Organizational Name Individual Identification Demographic Information Provider Information Administrative Communications Contact Reference Information Date or Time or Period LOOP ID - NM1/NX1 Property or Entity Identification Party Location Geographic Location

M O O O O O O O O O O O O O

1 1 3 5 >1 1 1 3 1 2 5 1 5 1 1 1

1100 NX1 1200 N3 1300 N4

Table 2 - Detail
PAGE #
POS. # SEG. ID NAME REQ. DES. MAX USE LOOP REPEAT

0100 0150 0175 0200 0300 0400 0500

LX TRN STC NM1 PRV PER REF

LOOP ID - LX Transaction Set Line Number Trace Status Information Individual or Organizational Name Provider Information Administrative Communications Contact Reference Information LOOP ID - LX/DTP Date or Time or Period Category of Patient Information Service

>1 O O O O O O O O O 1 1 1 1 1 1 5 >1 1 1

0600 DTP 0700 CAT

34

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE 0800 PID 0900 EFI 1000 BIN 1100 SE NOTES: 1/0500 1/0800 2/0150 2/0175 2/0200 Product/Item Description LOOP ID - LX/DTP/EFI Electronic Format Identification Binary Data Segment Transaction Set Trailer O O M M 1

004050X151 275

1 1 1 1

Loop NM1 identifies a single patient; it also identifies other entities or individuals which include the requester, responder or other organizations. The PRV segment is only used in Loop NM1 when identifying a requestor or responder who is also a provider. The TRN segment in Loop LX identifies a previously sent transaction set. The LX loop provides supporting or additional information for that item when TRN is used. The STC segment in LX loop identifies the status and action requested in a prior transaction when the response is provided in this transaction. The NM1 segment in loop LX identifies an individual provider within a responder group.

MAY 2004

35

004050X151 275

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

3.4

275 - Segment Detail


This section specifies the segments, data elements, and codes for this implementation. Refer to section 3.1 Presentation Examples for detailed information on the components of the Segment Detail section.

36

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


TRANSACTION SET HEADER

004050X151 275 ST 275 TRANSACTION HEADER

ST

275 TRANSACTION ST 004050X151 275 HEADER

IMPLEMENTATION

275 TRANSACTION HEADER


Usage: REQUIRED Repeat: 1

54
STANDARD

Example: ST2750001004050X151~

ST Transaction Set Header


Level: Header Position: 0100 Loop: ____ Requirement: Mandatory Max Use: 1 Purpose: To indicate the start of a transaction set and to assign a control number
DIAGRAM

ST01

143

ST02

329

ST03

1705

ST
M1

TS ID Code
ID 3/3

TS Control Number
M1 AN 4/9

Imple Conv Reference


O1 AN 1/35

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

ST01

143

Transaction Set Identifier Code


Code uniquely identifying a Transaction Set
SEMANTIC:

M1

ID

3/3

The transaction set identifier (ST01) is used by the translation routines of the interchange partners to select the appropriate transaction set definition (e.g., 810 selects the Invoice Transaction Set).

168

Use this code to identify the transaction set ID for the transaction set that will follow the ST segment. Each X12 standard has a transaction set identifier code that is unique to that transaction set.
CODE DEFINITION

275 REQUIRED ST02 329

Patient Information M 1 AN 4/9

Transaction Set Control Number

Identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set

142

The Transaction Set Control Number in ST02 and SE02 must be identical. This unique number also aids in error resolution research. Submitters could begin sending transactions using the number 0001 in this element and increment from there. The number must be unique within a specific functional group (GS-GE) and interchange (ISA-IEA), but can repeat in other groups and interchanges.

MAY 2004

37

004050X151 275 ST 275 TRANSACTION HEADER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REQUIRED

ST03

1705

Implementation Convention Reference


Reference assigned to identify Implementation Convention
SEMANTIC:

O 1 AN

1/35

The implementation convention reference (ST03) is used by the translation routines of the interchange partners to select the appropriate implementation convention to match the transaction set definition. When used, this implementation convention reference takes precedence over the implementation reference specified in the GS08.

INDUSTRY: Implementation

Convention Reference Identifier

190

004050X151 This field contains the same value as GS08. Some translator products strip off the ISA and GS segments prior to application (STSE) processing. Providing the information from the GS08 at this level will ensure that the appropriate application mapping is utilized at translation time.

38

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


BEGINNING SEGMENT

004050X151 275 BGN BEGINNING SEGMENT

BGN

BEGINNING 275 BGN 004050X151 SEGMENT

IMPLEMENTATION

BEGINNING SEGMENT
Usage: REQUIRED Repeat: 1

55
STANDARD

Example: BGN11120030701~

BGN Beginning Segment


Level: Header Position: 0200 Loop: ____ Requirement: Optional Max Use: 1 Purpose: To indicate the beginning of a transaction set Syntax:
DIAGRAM

1. C0504 If BGN05 is present, then BGN04 is required.

BGN01

353

BGN02

127

BGN03

373

BGN04

337

BGN05

623

BGN06

127

BGN

TS Purpose
Code
ID M1 2/2

Reference Ident
M1 AN 1/50

M1

Date
DT 8/8

X1

Time
TM 4/8

O1

Time Code
ID 2/2

Reference Ident
O1 AN 1/50

BGN07

640

BGN08

306

BGN09

786

Transaction Type Code


O1 ID 2/2

O1

Action Code
ID 1/2

Security Level Code


O1 ID 2/2

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

BGN01

353

Transaction Set Purpose Code


Code identifying purpose of transaction set
CODE DEFINITION

M1

ID

2/2

02

Add Used when submitting an attachment to an 837 transmitted within the same Interchange.

1000158
11

Response Used when submitting Attachment information in response to a 277.

1000159

MAY 2004

39

004050X151 275 BGN BEGINNING SEGMENT

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REQUIRED

BGN02

127

Reference Identification

M 1 AN

1/50

Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC:

BGN02 is the transaction set reference number.

INDUSTRY: Transaction

Set Reference Number

1000084
REQUIRED BGN03 373

The originator of the transaction set assigns the unique reference number in BGN02 and the date of creation in BGN03. Date M 1 DT 8/8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEMANTIC:

BGN03 is the transaction set date.

INDUSTRY: Transaction

Set Creation Date


X1 O1 TM ID 4/8 2/2 1/50 2/2 1/2 2/2

NOT USED NOT USED NOT USED NOT USED NOT USED NOT USED

BGN04 BGN05 BGN06 BGN07 BGN08 BGN09

337 623 127 640 306 786

Time Time Code Reference Identification Transaction Type Code Action Code Security Level Code

O 1 AN O1 O1 O1 ID ID ID

40

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


INDIVIDUAL OR ORGANIZATIONAL NAME

004050X151 275 1000A NM1 TRANSACTION RECEIVER

NM1

004050X151 275 1000A NM1 TRANSACTION RECEIVER

IMPLEMENTATION

TRANSACTION RECEIVER
Loop: 1000A TRANSACTION RECEIVER Repeat: 1 Usage: REQUIRED Repeat: 1

143
STANDARD

Example: NM1402ABC INSURANCE COMPANY4612345~

NM1 Individual or Organizational Name


Level: Header Position: 0500 Loop: NM1 Repeat: >1 Requirement: Optional Max Use: 1 Purpose: To supply the full name of an individual or organizational entity Set Notes: Syntax: 1. Loop NM1 identifies a single patient; it also identifies other entities or individuals which include the requester, responder or other organizations. 1. P0809 If either NM108 or NM109 is present, then the other is required. 2. C1110 If NM111 is present, then NM110 is required. 3. C1203 If NM112 is present, then NM103 is required.
DIAGRAM

NM101

98

NM102

1065

NM103

1035

NM104

1036

NM105

1037

NM106

1038

NM1

Entity ID Code
M1 ID 2/3

Entity Type Qualifier


M1 ID 1/1

Name Last/ Org Name


X1 AN 1/60

O1

Name First
AN 1/35

O1

Name Middle
AN 1/25

O1

Name Prefix
AN 1/10

NM107

1039

NM108

66

NM109

67

NM110

706

NM111

98

NM112

1035

Name Suffix
O1 AN 1/10

ID Code Qualifier
X1 ID 1/2

X1

ID Code
AN 2/80

Entity Relat Code


X1 ID 2/2

Entity ID Code
O1 ID 2/3

Name Last/ Org Name


O1 AN 1/60

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

NM101

98

Entity Identifier Code

M1

ID

2/3

Code identifying an organizational entity, a physical location, property or an individual


CODE DEFINITION

40

Receiver

MAY 2004

41

004050X151 275 1000A NM1 TRANSACTION RECEIVER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REQUIRED

NM102

1065

Entity Type Qualifier


Code qualifying the type of entity
SEMANTIC:

M1

ID

1/1

NM102 qualifies NM103.


DEFINITION

CODE

2 REQUIRED NM103 1035

Non-Person Entity X1 AN 1/60

Name Last or Organization Name


Individual last name or organizational name
SYNTAX:

C1203

INDUSTRY: Receiver

Name
O 1 AN O 1 AN O 1 AN O 1 AN X1 ID 1/35 1/25 1/10 1/10 1/2

NOT USED NOT USED NOT USED NOT USED REQUIRED

NM104 NM105 NM106 NM107 NM108

1036 1037 1038 1039 66

Name First Name Middle Name Prefix Name Suffix Identification Code Qualifier

Code designating the system/method of code structure used for Identification Code (67)
SYNTAX:

P0809
DEFINITION

CODE

46

Electronic Transmitter Identification Number (ETIN) Established by Trading Partner Agreement.

1000143
XV

Health Care Financing Administration PlanID Required if the National PlanID is mandated for use. Otherwise, one of the other listed codes may be used.
CODE SOURCE 540:

Centers for Medicare and Medicaid Services

PlanID

REQUIRED

NM109

67

Identification Code
Code identifying a party or other code
SYNTAX:

X1

AN

2/80

P0809

INDUSTRY: Receiver

Identifier
X1 O1 ID ID 2/2 2/3 1/60

NOT USED NOT USED NOT USED

NM110 NM111 NM112

706 98 1035

Entity Relationship Code Entity Identifier Code Name Last or Organization Name

O 1 AN

42

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


ADMINISTRATIVE COMMUNICATIONS CONTACT

004050X151 275 1000A PER RESPONSE CONTACT

PER

004050X151 CONTACT RESPONSE 275 1000A PER

IMPLEMENTATION

RESPONSE CONTACT
Loop: 1000A TRANSACTION RECEIVER Usage: SITUATIONAL Repeat: 1

0 016 100

Notes:

1. Required when the value in BGN01 is 11 and the 277 designates a specific contact for the return of the requested information. This is the person/department to whom the information must be returned. If not required, do not send. 2. When the communication number represents a telephone number in the United States and other countries using the North American Dialing Plan (for voice, data, fax, etc.), the communication number should always include the area code and phone number using the format AAABBBCCCC. Where AAA is the area code, BBB is the telephone number prefix, and CCCC is the telephone number (e.g. (534)224-2525 would be represented as 5342242525). The extension when applicable, should be included in the communication number immediately after the telephone number.

4 020 100

61
STANDARD

Example: PERICMEDICAL REVIEW DEPARTMENT~

PER Administrative Communications Contact


Level: Header Position: 0900 Loop: NM1 Requirement: Optional Max Use: 2 Purpose: To identify a person or office to whom administrative communications should be directed Syntax: 1. P0304 If either PER03 or PER04 is present, then the other is required. 2. P0506 If either PER05 or PER06 is present, then the other is required. 3. P0708 If either PER07 or PER08 is present, then the other is required.

MAY 2004

43

004050X151 275 1000A PER RESPONSE CONTACT DIAGRAM

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

PER01

366

PER02

93

PER03

365

PER04

364

PER05

365

PER06

364

PER

Contact Funct Code


M1 ID 2/2

O1

Name
AN 1/60

Comm Number Qual


X1 ID 2/2

Comm Number
X1 AN 1/256

Comm Number Qual


X1 ID 2/2

Comm Number
X1 AN 1/256

PER07

365

PER08

364

PER09

443

Comm Number Qual


X1 ID 2/2

Comm Number
X1 AN 1/256

Contact Inq Reference


O1 AN 1/20

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

PER01

366

Contact Function Code


CODE DEFINITION

M1

ID

2/2

Code identifying the major duty or responsibility of the person or group named

IC REQUIRED PER02 93 Name


Free-form name

Information Contact O 1 AN 1/60

INDUSTRY: Information

Receiver Contact Name

1000186
SITUATIONAL PER03 365

Return information given at the 2100A, 2200D or 2200E loop of the 277. Communication Number Qualifier
Code identifying the type of communication number
SYNTAX:

X1

ID

2/2

P0304

191

Required when the PER segment in the 2100A, 2210D or 2210E loops of the 277 include the information. If not required, do not send.
CODE DEFINITION

ED EM FX TE SITUATIONAL PER04 364

Electronic Data Interchange Access Number Electronic Mail Facsimile Telephone X1 AN 1/256

Communication Number

Complete communications number including country or area code when applicable


SYNTAX:

P0304

INDUSTRY: Information

Receiver Contact Communication Number

191

Required when the PER segment in the 2100A, 2210D or 2210E loops of the 277 include the information. If not required, do not send.

44

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 1000A PER RESPONSE CONTACT

SITUATIONAL

PER05

365

Communication Number Qualifier


Code identifying the type of communication number
SYNTAX:

X1

ID

2/2

P0506

191

Required when the PER segment in the 2100A, 2210D or 2210E loops of the 277 include the information. If not required, do not send.
CODE DEFINITION

ED EM EX FX TE SITUATIONAL PER06 364

Electronic Data Interchange Access Number Electronic Mail Telephone Extension Facsimile Telephone X1 AN 1/256

Communication Number

Complete communications number including country or area code when applicable


SYNTAX:

P0506

INDUSTRY: Information

Receiver Contact Communication Number

191
SITUATIONAL

Required when the PER segment in the 2100A, 2210D or 2210E loops of the 277 include the information. If not required, do not send. PER07 365 Communication Number Qualifier
Code identifying the type of communication number
SYNTAX:

X1

ID

2/2

P0708

191

Required when the PER segment in the 2100A, 2210D or 2210E loops of the 277 include the information. If not required, do not send.
CODE DEFINITION

ED EM EX FX TE SITUATIONAL PER08 364

Electronic Data Interchange Access Number Electronic Mail Telephone Extension Facsimile Telephone X1 AN 1/256

Communication Number

Complete communications number including country or area code when applicable


SYNTAX:

P0708

INDUSTRY: Information

Receiver Contact Communication Number

191
NOT USED

Required when the PER segment in the 2100A, 2210D or 2210E loops of the 277 include the information. If not required, do not send. PER09 443 Contact Inquiry Reference O 1 AN 1/20

MAY 2004

45

004050X151 275 1000B NM1 SUBMITTER INFORMATION


INDIVIDUAL OR ORGANIZATIONAL NAME

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

NM1

004050X151 275 1000B NM1 SUBMITTER INFORMATION

IMPLEMENTATION

SUBMITTER INFORMATION
Loop: 1000B SUBMITTER INFORMATION Repeat: 1 Usage: REQUIRED Repeat: 1

192 146
STANDARD

Notes:

1. This segment is used to provide the submitter information.

Example: NM1412ABC BILLING SERVICE46X100~

NM1 Individual or Organizational Name


Level: Header Position: 0500 Loop: NM1 Repeat: >1 Requirement: Optional Max Use: 1 Purpose: To supply the full name of an individual or organizational entity Set Notes: Syntax: 1. Loop NM1 identifies a single patient; it also identifies other entities or individuals which include the requester, responder or other organizations. 1. P0809 If either NM108 or NM109 is present, then the other is required. 2. C1110 If NM111 is present, then NM110 is required. 3. C1203 If NM112 is present, then NM103 is required.
DIAGRAM

NM101

98

NM102

1065

NM103

1035

NM104

1036

NM105

1037

NM106

1038

NM1

Entity ID Code
M1 ID 2/3

Entity Type Qualifier


M1 ID 1/1

Name Last/ Org Name


X1 AN 1/60

O1

Name First
AN 1/35

O1

Name Middle
AN 1/25

O1

Name Prefix
AN 1/10

NM107

1039

NM108

66

NM109

67

NM110

706

NM111

98

NM112

1035

Name Suffix
O1 AN 1/10

ID Code Qualifier
X1 ID 1/2

X1

ID Code
AN 2/80

Entity Relat Code


X1 ID 2/2

Entity ID Code
O1 ID 2/3

Name Last/ Org Name


O1 AN 1/60

46

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE ELEMENT SUMMARY


REF. DES. DATA ELEMENT

004050X151 275 1000B NM1 SUBMITTER INFORMATION

USAGE

NAME

ATTRIBUTES

REQUIRED

NM101

98

Entity Identifier Code

M1

ID

2/3

Code identifying an organizational entity, a physical location, property or an individual


CODE DEFINITION

41 REQUIRED NM102 1065

Submitter M1 ID 1/1

Entity Type Qualifier


Code qualifying the type of entity
SEMANTIC:

NM102 qualifies NM103.


DEFINITION

CODE

1 2 REQUIRED NM103 1035

Person Non-Person Entity X1 AN 1/60

Name Last or Organization Name


Individual last name or organizational name
SYNTAX:

C1203

INDUSTRY: Submitter

Last or Organization Name


O 1 AN 1/35

SITUATIONAL

NM104

1036

Name First
Individual first name
INDUSTRY: Submitter

First Name

150
SITUATIONAL NM105 1037

Required when the value in NM102 equals 1 and the persons first name is known. If not required, do not send. Name Middle
Individual middle name or initial
INDUSTRY: Submitter

O 1 AN

1/25

Middle Name

170
NOT USED NOT USED REQUIRED NM106 NM107 NM108 1038 1039 66

Required when the value in NM102 equals 1 and the persons middle name/initial is known. If not required, do not send. Name Prefix Name Suffix Identification Code Qualifier O 1 AN O 1 AN X1 ID 1/10 1/10 1/2

Code designating the system/method of code structure used for Identification Code (67)
SYNTAX:

P0809
DEFINITION

CODE

46 REQUIRED NM109 67

Electronic Transmitter Identification Number (ETIN) X1 AN 2/80

Identification Code
Code identifying a party or other code
SYNTAX:

P0809

INDUSTRY: Submitter

Identifier
X1 O1 ID ID 2/2 2/3

NOT USED NOT USED

NM110 NM111

706 98

Entity Relationship Code Entity Identifier Code

MAY 2004

47

004050X151 275 1000B NM1 SUBMITTER INFORMATION

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

NOT USED

NM112

1035

Name Last or Organization Name

O 1 AN

1/60

48

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


INDIVIDUAL OR ORGANIZATIONAL NAME

004050X151 275 1000C NM1 SERVICE PROVIDER INFORMATION

NM1

004050X151 275 1000C NM1 SERVICE PROVIDER INFORMATION

IMPLEMENTATION

SERVICE PROVIDER INFORMATION


Loop: 1000C SERVICE PROVIDER INFORMATION Repeat: 1 Usage: REQUIRED Repeat: 1

1 016 100
STANDARD

Example: NM11P2ABC HOSPITALSV159999~

NM1 Individual or Organizational Name


Level: Header Position: 0500 Loop: NM1 Repeat: >1 Requirement: Optional Max Use: 1 Purpose: To supply the full name of an individual or organizational entity Set Notes: Syntax: 1. Loop NM1 identifies a single patient; it also identifies other entities or individuals which include the requester, responder or other organizations. 1. P0809 If either NM108 or NM109 is present, then the other is required. 2. C1110 If NM111 is present, then NM110 is required. 3. C1203 If NM112 is present, then NM103 is required.
DIAGRAM

NM101

98

NM102

1065

NM103

1035

NM104

1036

NM105

1037

NM106

1038

NM1

Entity ID Code
M1 ID 2/3

Entity Type Qualifier


M1 ID 1/1

Name Last/ Org Name


X1 AN 1/60

O1

Name First
AN 1/35

O1

Name Middle
AN 1/25

O1

Name Prefix
AN 1/10

NM107

1039

NM108

66

NM109

67

NM110

706

NM111

98

NM112

1035

Name Suffix
O1 AN 1/10

ID Code Qualifier
X1 ID 1/2

X1

ID Code
AN 2/80

Entity Relat Code


X1 ID 2/2

Entity ID Code
O1 ID 2/3

Name Last/ Org Name


O1 AN 1/60

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

NM101

98

Entity Identifier Code

M1

ID

2/3

Code identifying an organizational entity, a physical location, property or an individual


CODE DEFINITION

1P

Provider

MAY 2004

49

004050X151 275 1000C NM1 SERVICE PROVIDER INFORMATION

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REQUIRED

NM102

1065

Entity Type Qualifier


Code qualifying the type of entity
SEMANTIC:

M1

ID

1/1

NM102 qualifies NM103.


DEFINITION

CODE

1 2 REQUIRED NM103 1035

Person Non-Person Entity X1 AN 1/60

Name Last or Organization Name


Individual last name or organizational name
SYNTAX:

C1203

INDUSTRY: Provider

Last or Organization Name


O 1 AN 1/35

SITUATIONAL

NM104

1036

Name First
Individual first name
INDUSTRY: Provider

First Name

169
SITUATIONAL NM105 1037

Required when the value in NM102 is 1 and the persons first name is known. If not required, do not send. Name Middle
Individual middle name or initial
INDUSTRY: Provider

O 1 AN

1/25

Middle Name

151
NOT USED SITUATIONAL NM106 NM107 1038 1039

Required when the value in NM102 is 1 and the persons middle name/initial is known. If not required, do not send. Name Prefix Name Suffix
Suffix to individual name
INDUSTRY: Provider

O 1 AN O 1 AN

1/10 1/10

Name Suffix

1000162
REQUIRED NM108 66

Required when the value in NM102 is 1 and the Suffix is known. If not required, do not send. Identification Code Qualifier X1 ID 1/2
Code designating the system/method of code structure used for Identification Code (67)
SYNTAX:

P0809
DEFINITION

CODE

24

Employers Identification Number Use only when value in BGN01 is 02 and the code is in NM108 of loop 2010AA of the 837.

1000163
34

Social Security Number Use only when value in BGN01 is 02 and the code is in NM108 of loop 2010AA of the 837.

1000163
FI SV

Federal Taxpayers Identification Number Service Provider Number Use only when the value in BGN01 is 11. Return the provider number from the 277.

1000164

50

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 1000C NM1 SERVICE PROVIDER INFORMATION

XX

Health Care Financing Administration National Provider Identifier Required value if the National Provider ID is mandated for use. Otherwise, one of the other listed codes must be used.
CODE SOURCE 537: Centers for Medicare and Medicaid Services National Provider Identifier

REQUIRED

NM109

67

Identification Code
Code identifying a party or other code
SYNTAX:

X1

AN

2/80

P0809

INDUSTRY: Provider

Identifier
X1 O1 ID ID 2/2 2/3 1/60

NOT USED NOT USED NOT USED

NM110 NM111 NM112

706 98 1035

Entity Relationship Code Entity Identifier Code Name Last or Organization Name

O 1 AN

MAY 2004

51

004050X151 275 1000C REF PROVIDER SECONDARY IDENTIFICATION


REFERENCE INFORMATION

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REF

PROVIDER 275 1000C REF 004050X151SECONDARY IDENTIFICATION

IMPLEMENTATION

PROVIDER SECONDARY IDENTIFICATION


Loop: 1000C SERVICE PROVIDER INFORMATION Usage: SITUATIONAL Repeat: 5

6 012 100

Notes:

1. Required when a secondary Identification number is necessary to identify the entity. The primary identification number should be reported in NM108/09 in this loop. If not required, may provide at senders discretion. 2. If the reason the number being used in this REF can be met by the NPI, reported in the NM108/09 of this loop, then this REF is not used.

7 012 100 4 014 100


STANDARD

Example: REF1C565656~

REF Reference Information


Level: Header Position: 1000 Loop: NM1 Requirement: Optional Max Use: 5 Purpose: To specify identifying information Syntax:
DIAGRAM

1. R0203 At least one of REF02 or REF03 is required.

REF01

128

REF02

127

REF03

352

REF04

C040

REF

Reference Ident Qual


M1 ID 2/3

Reference Ident
X1 AN 1/50

Description
X1 AN 1/80

Reference Identifier
O1

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

REF01

128

Reference Identification Qualifier


Code qualifying the Reference Identification
CODE DEFINITION

M1

ID

2/3

0B 1A 1B 1C

State License Number Blue Cross Provider Number Blue Shield Provider Number Medicare Provider Number

52

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 1000C REF PROVIDER SECONDARY IDENTIFICATION

1D 1E 1G 1H 1J B3 BQ EI FH G2 G5 LU SY

Medicaid Provider Number Dentist License Number Provider UPIN Number CHAMPUS Identification Number Facility ID Number Preferred Provider Organization Number Health Maintenance Organization Code Number Employers Identification Number Clinic Number Provider Commercial Number Provider Site Number Location Number Social Security Number The Social Security Number may not be used for Medicare.

1000128
TJ U3 X5 REQUIRED REF02 127

Federal Taxpayers Identification Number Unique Supplier Identification Number (USIN) State Industrial Accident Provider Number X1 AN 1/50

Reference Identification

Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SYNTAX:

R0203

INDUSTRY: Provider

Secondary Identifier
X1 O1 AN 1/80

NOT USED NOT USED

REF03 REF04

352 C040

Description REFERENCE IDENTIFIER

MAY 2004

53

004050X151 275 1000D NM1 PATIENT NAME


INDIVIDUAL OR ORGANIZATIONAL NAME

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

NM1

004050X151 275 1000D NM1 PATIENT NAME

IMPLEMENTATION

PATIENT NAME
Loop: 1000D PATIENT NAME Repeat: 1 Usage: REQUIRED Repeat: 1

1 018 100
STANDARD

Example: NM1QC1SMITHJOHNHMI987654320~

NM1 Individual or Organizational Name


Level: Header Position: 0500 Loop: NM1 Repeat: >1 Requirement: Optional Max Use: 1 Purpose: To supply the full name of an individual or organizational entity Set Notes: Syntax: 1. Loop NM1 identifies a single patient; it also identifies other entities or individuals which include the requester, responder or other organizations. 1. P0809 If either NM108 or NM109 is present, then the other is required. 2. C1110 If NM111 is present, then NM110 is required. 3. C1203 If NM112 is present, then NM103 is required.
DIAGRAM

NM101

98

NM102

1065

NM103

1035

NM104

1036

NM105

1037

NM106

1038

NM1

Entity ID Code
M1 ID 2/3

Entity Type Qualifier


M1 ID 1/1

Name Last/ Org Name


X1 AN 1/60

O1

Name First
AN 1/35

O1

Name Middle
AN 1/25

O1

Name Prefix
AN 1/10

NM107

1039

NM108

66

NM109

67

NM110

706

NM111

98

NM112

1035

Name Suffix
O1 AN 1/10

ID Code Qualifier
X1 ID 1/2

X1

ID Code
AN 2/80

Entity Relat Code


X1 ID 2/2

Entity ID Code
O1 ID 2/3

Name Last/ Org Name


O1 AN 1/60

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

NM101

98

Entity Identifier Code

M1

ID

2/3

Code identifying an organizational entity, a physical location, property or an individual


CODE DEFINITION

QC

Patient

54

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 1000D NM1 PATIENT NAME

REQUIRED

NM102

1065

Entity Type Qualifier


Code qualifying the type of entity
SEMANTIC:

M1

ID

1/1

NM102 qualifies NM103.


DEFINITION

CODE

1 REQUIRED NM103 1035

Person X1 AN 1/60

Name Last or Organization Name


Individual last name or organizational name
SYNTAX:

C1203

INDUSTRY: Patient

Last Name
O 1 AN 1/35

SITUATIONAL

NM104

1036

Name First
Individual first name
INDUSTRY: Patient

First Name

169
SITUATIONAL NM105 1037

Required when the value in NM102 is 1 and the persons first name is known. If not required, do not send. Name Middle
Individual middle name or initial
INDUSTRY: Patient

O 1 AN

1/25

Middle Name

151
NOT USED SITUATIONAL NM106 NM107 1038 1039

Required when the value in NM102 is 1 and the persons middle name/initial is known. If not required, do not send. Name Prefix Name Suffix
Suffix to individual name
INDUSTRY: Patient

O 1 AN O 1 AN

1/10 1/10

Name Suffix

171
REQUIRED NM108 66

Required when the value in NM102 is 1 and the suffix is known. For example, I, II, III, IV, JR, SR. If not required, do not send. Identification Code Qualifier X1 ID 1/2
Code designating the system/method of code structure used for Identification Code (67)
SYNTAX:

P0809
DEFINITION

CODE

MI

Member Identification Number The code MI is intended to be the subscribers identification number as assigned by the payer. Payers use different terminology to convey the same number. Therefore the 275 Workgroup recommends using MI - Member Identification Number to convey the following terms: Insureds ID, Subscribers ID, Health Insurance Claim Number (HIC), etc. MI is also intended to be used in claims submitted to the Indian Health Service/Contract Health Services (IHS/CHS) Fiscal Intermediary for the purpose of reporting the Tribe Residency Code (Tribe County State).

153

MAY 2004

55

004050X151 275 1000D NM1 PATIENT NAME

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

ZZ

Mutually Defined The value ZZ when used in this data element shall be defined as HIPAA Individual Identifier if this identifier is adopted for use. Under the Health Insurance Portability and Accountability Act of 1996, the secretary of the Department of Health and Human Services may adopt a standard Individual Identifier for use in this transaction.

1000145

REQUIRED

NM109

67

Identification Code
Code identifying a party or other code
SYNTAX:

X1

AN

2/80

P0809

INDUSTRY: Patient

Primary Identifier
X1 O1 ID ID 2/2 2/3 1/60

NOT USED NOT USED NOT USED

NM110 NM111 NM112

706 98 1035

Entity Relationship Code Entity Identifier Code Name Last or Organization Name

O 1 AN

56

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


REFERENCE INFORMATION

004050X151 275 1000D REF PATIENT ACCOUNT NUMBER

REF

PATIENT ACCOUNT NUMBER 004050X151 275 1000D REF

IMPLEMENTATION

PATIENT ACCOUNT NUMBER


Loop: 1000D PATIENT NAME Usage: REQUIRED Repeat: 1

8 018 100 65
STANDARD

Notes:

1. Required when the 277 includes this value or when the 275 is unsolicited.

Example: REFEJME1234~

REF Reference Information


Level: Header Position: 1000 Loop: NM1 Requirement: Optional Max Use: 5 Purpose: To specify identifying information Syntax:
DIAGRAM

1. R0203 At least one of REF02 or REF03 is required.

REF01

128

REF02

127

REF03

352

REF04

C040

REF

Reference Ident Qual


M1 ID 2/3

Reference Ident
X1 AN 1/50

Description
X1 AN 1/80

Reference Identifier
O1

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

REF01

128

Reference Identification Qualifier


Code qualifying the Reference Identification
CODE DEFINITION

M1

ID

2/3

EJ

Patient Account Number When the value in BGN01 of the 275 is 02, the Patient Account Number must be the same number as reported in CLM01 in the 2300 loop of the 837. When the value in BGN01 is 11, the Patient Account Number must be the same number as reported in REF02 in the 2200D loop of the 277.

1000180

MAY 2004

57

004050X151 275 1000D REF PATIENT ACCOUNT NUMBER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REQUIRED

REF02

127

Reference Identification

X1

AN

1/50

Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SYNTAX:

R0203

INDUSTRY: Patient

Account Number

1000147

The maximum number of characters to be supported for this field is 20. A provider may submit fewer characters depending upon their needs. However, the HIPAA maximum requirement to be supported by any responding system is 20. Characters beyond 20 are not required to be stored nor returned by any 837 receiving system. For a solicited 275, this value must be identical to the patient account number from the 2200D or 2200E REF segment in the 277. REF03 REF04 352 C040 Description REFERENCE IDENTIFIER X1 O1 AN 1/80

1000205
NOT USED NOT USED

58

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


REFERENCE INFORMATION

004050X151 275 1000D REF INSTITUTIONAL TYPE OF BILL

REF

INSTITUTIONAL TYPE OF REF 004050X151 275 1000DBILL

IMPLEMENTATION

INSTITUTIONAL TYPE OF BILL


Loop: 1000D PATIENT NAME Usage: SITUATIONAL Repeat: 1

6 020 100

Notes:

1. Required when the Institutional Type of Bill from the submitted claim is available in the payers system and is included in the 2200D/2200E REF segment of the 277. If not required, may be provided at the senders discretion. 2. Not used for Professional Claims.

20 67
STANDARD

Example: REFBLT111~

REF Reference Information


Level: Header Position: 1000 Loop: NM1 Requirement: Optional Max Use: 5 Purpose: To specify identifying information Syntax:
DIAGRAM

1. R0203 At least one of REF02 or REF03 is required.

REF01

128

REF02

127

REF03

352

REF04

C040

REF

Reference Ident Qual


M1 ID 2/3

Reference Ident
X1 AN 1/50

Description
X1 AN 1/80

Reference Identifier
O1

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

REF01

128

Reference Identification Qualifier


Code qualifying the Reference Identification
CODE DEFINITION

M1

ID

2/3

BLT

Billing Type

MAY 2004

59

004050X151 275 1000D REF INSTITUTIONAL TYPE OF BILL

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REQUIRED

REF02

127

Reference Identification

X1

AN

1/50

Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SYNTAX:

R0203

INDUSTRY: Bill

Type Identifier

1000207

The value in REF02 corresponds to a concatenation of Facility Type Code (CLM05-1) and Claim Frequency Type Code (CLM05-3) from the ASC X12N 837 claim transaction or this is the value from the loop 2200D/2200E REF02 of the 277. REF03 REF04 352 C040 Description REFERENCE IDENTIFIER X1 O1 AN 1/80

NOT USED NOT USED

60

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


REFERENCE INFORMATION

004050X151 275 1000D REF MEDICAL RECORD NUMBER

REF

MEDICAL RECORD 1000D REF 004050X151 275 NUMBER

IMPLEMENTATION

MEDICAL RECORD NUMBER


Loop: 1000D PATIENT NAME Usage: SITUATIONAL Repeat: 1

7 011 100

Notes:

1. Required when the Medical Record Number is submitted on the original claim. If not required, may be provided at the senders discretion.

127
STANDARD

Example: REFEASTHH12345~

REF Reference Information


Level: Header Position: 1000 Loop: NM1 Requirement: Optional Max Use: 5 Purpose: To specify identifying information Syntax:
DIAGRAM

1. R0203 At least one of REF02 or REF03 is required.

REF01

128

REF02

127

REF03

352

REF04

C040

REF

Reference Ident Qual


M1 ID 2/3

Reference Ident
X1 AN 1/50

Description
X1 AN 1/80

Reference Identifier
O1

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

REF01

128

Reference Identification Qualifier


Code qualifying the Reference Identification
CODE DEFINITION

M1

ID

2/3

EA REQUIRED REF02 127

Medical Record Identification Number X1 AN 1/50

Reference Identification

Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SYNTAX:

R0203

INDUSTRY: Medical

Record Number

1000085
NOT USED NOT USED REF03 REF04 352 C040

This is the Medical Record Number from the original claim. Description REFERENCE IDENTIFIER X1 O1 AN 1/80

MAY 2004

61

004050X151 275 1000D REF ASC X12N INSURANCE SUBCOMMITTEE CLAIM ID NUMBER FOR CLEARING HOUSES AND OTHER TRANSMISSION INTERMEDIARIES IMPLEMENTATION GUIDE
REFERENCE INFORMATION

REF

CLAIM ID NUMBER 1000D REF 004050X151 275 FOR CLEARING HOUSES AND OTHER TRANSMISSION INTERMEDIARIES

IMPLEMENTATION

CLAIM IDENTIFICATION NUMBER FOR CLEARING HOUSES AND OTHER TRANSMISSION INTERMEDIARIES
Loop: 1000D PATIENT NAME Usage: SITUATIONAL Repeat: 1

3 018 100

Notes:

1. Required when transmission intermediaries (Automated Clearing Houses and others) need to attach their own unique claim number. If not required, do not send. 2. Although this REF is supplies for transmission intermediaries to attach their own unique claim number to a claim/encounter, recipients are not required under HIPAA to return this number in any HIPAA transaction. Trading partners may voluntarily agree to this interaction if they wish.

4 018 100

STANDARD

REF Reference Information


Level: Header Position: 1000 Loop: NM1 Requirement: Optional Max Use: 5 Purpose: To specify identifying information Syntax:
DIAGRAM

1. R0203 At least one of REF02 or REF03 is required.

REF01

128

REF02

127

REF03

352

REF04

C040

REF

Reference Ident Qual


M1 ID 2/3

Reference Ident
X1 AN 1/50

Description
X1 AN 1/80

Reference Identifier
O1

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

REF01

128

Reference Identification Qualifier


Code qualifying the Reference Identification
CODE DEFINITION

M1

ID

2/3

D9

Claim Number

62

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE 004050X151 275 1000D REF IMPLEMENTATION GUIDE CLAIM ID NUMBER FOR CLEARING HOUSES AND OTHER TRANSMISSION INTERMEDIARIES

REQUIRED

REF02

127

Reference Identification

X1

AN

1/50

Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SYNTAX:

R0203

INDUSTRY: Clearinghouse

Trace Number

1000185
NOT USED NOT USED REF03 REF04 352 C040

The value carried in this element is limited to a maximum of 20 positions. Description REFERENCE IDENTIFIER X1 O1 AN 1/80

MAY 2004

63

004050X151 275 1000D DTP INSTITUTIONAL CLAIM SERVICE DATE


DATE OR TIME OR PERIOD

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

DTP

INSTITUTIONAL CLAIM SERVICE 004050X151 275 1000D DTP DATE

IMPLEMENTATION

INSTITUTIONAL CLAIM SERVICE DATE


Loop: 1000D PATIENT NAME Usage: SITUATIONAL Repeat: 1

15 7 016 100
STANDARD

Notes:

1. This is required for Institutional Claims and is the Statement From and Through dates. If not required, do not send.

Example: DTP434RD820030720-20030724~

DTP Date or Time or Period


Level: Header Position: 1050 Loop: NM1 Requirement: Optional Max Use: 1 Purpose: To specify any or all of a date, a time, or a time period
DIAGRAM

DTP01

374

DTP02

1250

DTP03

1251

DTP

Date/Time Qualifier
M1 ID 3/3

Date Time format Qual


M1 ID 2/3

Date Time Period


M1 AN 1/35

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

DTP01

374

Date/Time Qualifier
Code specifying type of date or time, or both date and time
INDUSTRY: Date
CODE

M1

ID

3/3

Time Qualifier
DEFINITION

434 REQUIRED DTP02 1250

Statement M1 ID 2/3

Date Time Period Format Qualifier


SEMANTIC:

Code indicating the date format, time format, or date and time format DTP02 is the date or time or period format that will appear in DTP03.
DEFINITION

CODE

RD8 REQUIRED

Range of Dates Expressed in Format CCYYMMDDCCYYMMDD M 1 AN 1/35

DTP03

1251

Date Time Period


INDUSTRY: Claim

Expression of a date, a time, or range of dates, times or dates and times

Service Period

195

This is the Statement From and Through dates.

64

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


TRANSACTION SET LINE NUMBER

004050X151 275 2000A LX ASSIGNED NUMBER

LX

004050X151 275 2000A LX ASSIGNED NUMBER

IMPLEMENTATION

ASSIGNED NUMBER
Loop: 2000A ASSIGNED NUMBER Repeat: >1 Usage: REQUIRED Repeat: 1

189 0 019 100

Notes:

1. Within the LX, LX01 is the sequence number of the segments that follow. The LX01 sequence number must start at 1 and increment by 1. 2. The LX segment can be repeated to respond to multiple questions on an individual claim. The 275 transaction structure only allows the submitter to send one claim in each 275. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each claim.

156
STANDARD

Example: LX1~

LX Transaction Set Line Number


Level: Detail Position: 0100 Loop: LX Repeat: >1 Requirement: Optional Max Use: 1 Purpose: To reference a line number in a transaction set
DIAGRAM

LX01

554

LX

Assigned Number
M1 N0 1/6

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

LX01

554

Assigned Number
Number assigned for differentiation within a transaction set

M1

N0

1/6

189

Within the LX, LX01 is the sequence number of the segments that follow. The LX01 sequence number must start at 1 and increment by 1.

MAY 2004

65

004050X151 275 2000A TRN PAYERS CONTROL NUMBER/PROVIDERS CONTROL NUMBER


TRACE

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

TRN

004050X151 275 2000A TRN PAYERS CONTROL NUMBER/PROVIDERS CONTROL NUMBER

IMPLEMENTATION

PAYERS CONTROL NUMBER/PROVIDERS CONTROL NUMBER


Loop: 2000A ASSIGNED NUMBER Usage: REQUIRED Repeat: 1

27 8 016 100

Notes:

1. Payers Control Number is the value from the TRN segment loop 2200D/2200E of the 277. 2. Providers Control Number is the value from PWK06 loop 2300 of the 837 submitted within the same Interchange. This is the main matching criteria and must be unique on a per attachment basis. 3. The TRN02 value must be the same in each iteration of the 2000A loop when the value in TRN02 is the Payers control number.

1 019 100 104


STANDARD

Example: TRN21234567~

TRN Trace
Level: Detail Position: 0150 Loop: LX Requirement: Optional Max Use: 1 Purpose: To uniquely identify a transaction to an application Set Notes: 1. The TRN segment in Loop LX identifies a previously sent transaction set. The LX loop provides supporting or additional information for that item when TRN is used.

DIAGRAM

TRN01

481

TRN02

127

TRN03

509

TRN04

127

TRN

Trace Type Code


M1 ID 1/2

Reference Ident
M1 AN 1/50

Originating Company ID
O1 AN 10/10

Reference Ident
O1 AN 1/50

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

TRN01

481

Trace Type Code


Code identifying which transaction is being referenced
CODE DEFINITION

M1

ID

1/2

Current Transaction Trace Numbers Used when sending a 275 to support an 837 within the same interchange.

196

66

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 2000A TRN PAYERS CONTROL NUMBER/PROVIDERS CONTROL NUMBER

Referenced Transaction Trace Numbers Used when responding to a 277.

1000169
REQUIRED TRN02 127

Reference Identification

M 1 AN

1/50

Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC:

TRN02 provides unique identification for the transaction.

INDUSTRY: Payer ALIAS: Payer

or Providers Control Number

Control Identifier

1000192

When the value in BGN02 is 11, this number will be the payers control number that is in the 2200D/2200E loop, TRN02 of the 277. This value must be the same in each LX loop. When the value in BGN02 is 02, this number is the unique control number that the provider assigned for the attachment. It must match the number in PWK06 loop 2300 of the 837 within the same interchange. This is the main matching criteria and must be unique on a per attachment basis. TRN03 TRN04 509 127 Originating Company Identifier Reference Identification O 1 AN O 1 AN 10/10 1/50

1000193

NOT USED NOT USED

MAY 2004

67

004050X151 275 2000A STC STATUS INFORMATION


STATUS INFORMATION

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

STC

004050X151 275 2000A STC STATUS INFORMATION

IMPLEMENTATION

STATUS INFORMATION
Loop: 2000A ASSIGNED NUMBER Usage: SITUATIONAL Repeat: 1

175

Notes:

1. This segment is required when the value in BGN01 is 11 and the 277 STC01 value is not 19016-5. When the 277 contains the STC01 claim level place holder of R0:19016-5::LOI, this information must not be returned in the 275. If not required, do not send. 2. This segment is not used when sending a 275 to support an 837 within the same interchange.

32 188
STANDARD

Example: STCR3:18682-5::LOI~

STC Status Information


Level: Detail Position: 0175 Loop: LX Requirement: Optional Max Use: 1 Purpose: To report the status, required action, and paid information of a claim or service line Set Notes:
DIAGRAM

1. The STC segment in LX loop identifies the status and action requested in a prior transaction when the response is provided in this transaction.

STC01

C043

STC02

373

STC03

306

STC04

782

STC05

782

STC06

373

STC

Health Care Stat Claim


M1

O1

Date
DT 8/8

O1

Action Code
ID 1/2

Monetary Amount
O1 R 1/18

Monetary Amount
O1 R 1/18

O1

Date
DT 8/8

STC07

591

STC08

373

STC09

429

STC10

C043

STC11

C043

STC12

933

Payment Method Code


O1 ID 3/3 O1

Date
DT 8/8

Check Number
O1 AN 1/16

Health Care Health Care


Stat Claim Stat Claim
O1 O1

Free-Form Message Txt ~


O1 AN 1/264

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

STC01

C043

HEALTH CARE CLAIM STATUS

M1

Used to convey status of the entire claim or a specific service line

178

This data element contains the values found in the STC in the 277.

68

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 2000A STC STATUS INFORMATION

REQUIRED

STC01 - 1

1271

Industry Code
SEMANTIC:

AN

1/30

Code indicating a code from a specific industry code list C043-01 is used to specify the logical groupings of Health Care Claim Status Codes (See Code Source 507).
INDUSTRY: Health
CODE SOURCE 507:

Care Claim Status Category Code


Health Care Claim Status Category Code

107
REQUIRED STC01 - 2 1271

This is the Category Code. Industry Code


SEMANTIC:

AN

1/30

Code indicating a code from a specific industry code list C043-02 is used to identify the status of an entire claim or a serviceline. Code Source 508 is referenced unless qualified by C043-04.
INDUSTRY: Additional
CODE SOURCE 663:

Information Request Code

Logical Observation Identifier Names and Codes

(LOINC)

1000170
NOT USED REQUIRED STC01 - 3 STC01 - 4 98 1270

This will be the LOINC Code that defines the additional information that was requested. Entity Identifier Code Code List Qualifier Code
Code identifying a specific industry code list
SEMANTIC:

O O

ID ID

2/3 1/3

C043-04 is used to identify the Code Source referenced in C043-02.


CODE DEFINITION

LOI

Logical Observation Identifier Names and Codes (LOINC) Codes


CODE SOURCE 663: Logical Observation Identifier Names and Codes (LOINC)

NOT USED NOT USED NOT USED NOT USED NOT USED NOT USED NOT USED NOT USED SITUATIONAL

STC02 STC03 STC04 STC05 STC06 STC07 STC08 STC09 STC10

373 306 782 782 373 591 373 429 C043

Date Action Code Monetary Amount Monetary Amount Date Payment Method Code Date Check Number HEALTH CARE CLAIM STATUS

O1 O1 O1 O1 O1 O1 O1

DT ID R R DT ID DT

8/8 1/2 1/18 1/18 8/8 3/3 8/8 1/16

O 1 AN O1

Used to convey status of the entire claim or a specific service line

1000194

This element is required when the 277 STC10 is used. This element is used to return the values found in the STC of the 277. If not required, do not send.

MAY 2004

69

004050X151 275 2000A STC STATUS INFORMATION

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REQUIRED

STC10 - 1

1271

Industry Code
SEMANTIC:

AN

1/30

Code indicating a code from a specific industry code list C043-01 is used to specify the logical groupings of Health Care Claim Status Codes (See Code Source 507).
INDUSTRY: Health
CODE SOURCE 507:

Care Claim Status Category Code


Health Care Claim Status Category Code

107
REQUIRED STC10 - 2 1271

This is the Category Code. Industry Code


SEMANTIC:

AN

1/30

Code indicating a code from a specific industry code list C043-02 is used to identify the status of an entire claim or a serviceline. Code Source 508 is referenced unless qualified by C043-04.
INDUSTRY: Additional
CODE SOURCE 663:

Information Request Modifier

Logical Observation Identifier Names and Codes

(LOINC)

1000170
NOT USED REQUIRED STC10 - 3 STC10 - 4 98 1270

This will be the LOINC Code that defines the additional information that was requested. Entity Identifier Code Code List Qualifier Code
Code identifying a specific industry code list
SEMANTIC:

O O

ID ID

2/3 1/3

C043-04 is used to identify the Code Source referenced in C043-02.


CODE DEFINITION

LOI

Logical Observation Identifier Names and Codes (LOINC) Codes


CODE SOURCE 663: Logical Observation Identifier Names and Codes (LOINC)

SITUATIONAL

STC11

C043

HEALTH CARE CLAIM STATUS

O1

Used to convey status of the entire claim or a specific service line

1000194
REQUIRED

This element is required when the 277 STC10 is used. This element is used to return the values found in the STC of the 277. If not required, do not send. STC11 - 1 1271 Industry Code
SEMANTIC:

AN

1/30

Code indicating a code from a specific industry code list C043-01 is used to specify the logical groupings of Health Care Claim Status Codes (See Code Source 507).
INDUSTRY: Health
CODE SOURCE 507:

Care Claim Status Category Code


Health Care Claim Status Category Code

107

This is the Category Code.

70

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 2000A STC STATUS INFORMATION

REQUIRED

STC11 - 2

1271

Industry Code
SEMANTIC:

AN

1/30

Code indicating a code from a specific industry code list C043-02 is used to identify the status of an entire claim or a serviceline. Code Source 508 is referenced unless qualified by C043-04.
INDUSTRY: Additional
CODE SOURCE 663:

Information Request Modifier

Logical Observation Identifier Names and Codes

(LOINC)

1000170
NOT USED REQUIRED STC11 - 3 STC11 - 4 98 1270

This will be the LOINC Code that defines the additional information that was requested. Entity Identifier Code Code List Qualifier Code
Code identifying a specific industry code list
SEMANTIC:

O O

ID ID

2/3 1/3

C043-04 is used to identify the Code Source referenced in C043-02.


CODE DEFINITION

LOI

Logical Observation Identifier Names and Codes (LOINC) Codes


CODE SOURCE 663: Logical Observation Identifier Names and Codes (LOINC)

NOT USED

STC12

933

Free-Form Message Text

O 1 AN

1/264

MAY 2004

71

004050X151 275 2000A REF SERVICE LINE ITEM IDENTIFICATION


REFERENCE INFORMATION

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REF

004050X151 275 2000A REF SERVICE LINE ITEM IDENTIFICATION

IMPLEMENTATION

SERVICE LINE ITEM IDENTIFICATION


Loop: 2000A ASSIGNED NUMBER Usage: SITUATIONAL Repeat: 1

9 014 100

Notes:

1. This segment is required when the additional information is associated with the service line or revenue line information. If not required, may be provided at the senders discretion. 2. If this segment is used, then there will be a REF segment that contains the Procedure Code or Revenue Code.

95 76
STANDARD

Example: REFFJ1234~

REF Reference Information


Level: Detail Position: 0500 Loop: LX Requirement: Optional Max Use: 5 Purpose: To specify identifying information Syntax:
DIAGRAM

1. R0203 At least one of REF02 or REF03 is required.

REF01

128

REF02

127

REF03

352

REF04

C040

REF

Reference Ident Qual


M1 ID 2/3

Reference Ident
X1 AN 1/50

Description
X1 AN 1/80

Reference Identifier
O1

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

REF01

128

Reference Identification Qualifier


Code qualifying the Reference Identification
CODE DEFINITION

M1

ID

2/3

6R

Provider Control Number Used when the value in BGN01 is 02. This is the Provider Control that is reported in the 837 on the original claim.

1000171

FJ

Line Item Control Number Used when the value in BGN01 is 11. This is the Line Item Control Number that is reported in the 277.

1000172

72

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 2000A REF SERVICE LINE ITEM IDENTIFICATION

REQUIRED

REF02

127

Reference Identification

X1

AN

1/50

Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SYNTAX:

R0203

INDUSTRY: Line

Item Control Number

1000087
NOT USED NOT USED REF03 REF04 352 C040

This is the provider control number or the line item control number that is associated with the additional information. Description REFERENCE IDENTIFIER X1 O1 AN 1/80

MAY 2004

73

004050X151 275 2000A REF PROCEDURE OR REVENUE CODE


REFERENCE INFORMATION

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REF

004050X151 OR REVENUEREF PROCEDURE 275 2000A CODE

IMPLEMENTATION

PROCEDURE OR REVENUE CODE


Loop: 2000A ASSIGNED NUMBER Usage: SITUATIONAL Repeat: 1

0 015 100

Notes:

1. This segment is required when the Service Line Item Identification REF Segment is used. If not required, may be provided at the senders discretion. 2. This segment will convey service line or revenue code information that is associated with the additional information. This matches the value in the 837 SV101-2, SV201-2, or SV301-2 or the 277 SVC01-2.

48

74
STANDARD

Example: REFCPT44499~

REF Reference Information


Level: Detail Position: 0500 Loop: LX Requirement: Optional Max Use: 5 Purpose: To specify identifying information Syntax:
DIAGRAM

1. R0203 At least one of REF02 or REF03 is required.

REF01

128

REF02

127

REF03

352

REF04

C040

REF

Reference Ident Qual


M1 ID 2/3

Reference Ident
X1 AN 1/50

Description
X1 AN 1/80

Reference Identifier
O1

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

REF01

128

Reference Identification Qualifier


Code qualifying the Reference Identification
CODE DEFINITION

M1

ID

2/3

CPT

Current Procedural Terminology Code Used to convey the Procedure Code (HCPCS Level I (CPT) or Level II) reported in the 837 or the 277.
CODE SOURCE 133:

1000173
F8

Current Procedural Terminology (CPT) Codes

Original Reference Number Used to convey the CDT-3 code.

1000195

74

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 2000A REF PROCEDURE OR REVENUE CODE

FO

Drug Formulary Number Used to convey the National Drug Code (NDC) in 5-42 format reported in the 837 or the 277.

1000174
PRT

Product Type This code is used for the Universal Product Number or when the 277 SVC01-1 has the value of UX. This code set is not allowed for use under HIPAA at the time of this writing. The qualifier can only be used: 1) If a new rule names the Universal Product Code as an allowable code set under HIPAA. 2) For Property & Casualty claims/encounters that are not covered under HIPAA.

1000203

YJ

Revenue Source Used to convey the Revenue Code reported in the 837 or the 277.

1000175
ZZ

Mutually Defined Used to convey HEIC and Alternative Link codes.

1000196
REQUIRED REF02 127

Reference Identification

X1

AN

1/50

Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SYNTAX:

R0203

INDUSTRY: Procedure

Code

1000177
NOT USED SITUATIONAL REF03 REF04 352 C040

When the service line item is identified with both a procedure code and a revenue code, the revenue code must be reported in REF04. Description REFERENCE IDENTIFIER X1 O1 AN 1/80

To identify one or more reference numbers or identification numbers as specified by the Reference Qualifier
SYNTAX:

P0304 If either C04003 or C04004 is present, then the other is required. P0506 If either C04005 or C04006 is present, then the other is required.

1000197
REQUIRED

This element is required when the service line is identified with both a procedure code and a revenue code. If not required, do not send. REF04 - 1 128 Reference Identification Qualifier
Code qualifying the Reference Identification
CODE DEFINITION

ID

2/3

YJ

Revenue Source Used to convey the Revenue Code reported in the 837 or the 277.

1000175

MAY 2004

75

004050X151 275 2000A REF PROCEDURE OR REVENUE CODE

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REQUIRED

REF04 - 2

127

Reference Identification

AN

1/50

Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
INDUSTRY: Revenue

Code
X X X X ID AN ID AN 2/3 1/50 2/3 1/50

NOT USED NOT USED NOT USED NOT USED

REF04 - 3 REF04 - 4 REF04 - 5 REF04 - 6

128 127 128 127

Reference Identification Qualifier Reference Identification Reference Identification Qualifier Reference Identification

76

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


DATE OR TIME OR PERIOD

004050X151 275 2100A DTP SERVICE LINE DATE OF SERVICE

DTP

004050X151 275 2100A DTP SERVICE LINE DATE OF SERVICE

IMPLEMENTATION

SERVICE LINE DATE OF SERVICE


Loop: 2100A SERVICE LINE DATE OF SERVICE Repeat: 1 Usage: SITUATIONAL Repeat: 1

1 015 100

Notes:

1. This segment is required when the date of service is not reported at the claim level. If not required, may be provided at the senders discretion. 2. This segment is required for Institutional Claims to report Service Line level date of service on outpatient claims when revenue, procedure, HEIC or Drug codes are reported in the 2400 loop SV2 segment in the 837.

2 015 100

3 015 100
STANDARD

Example: DTP472D820030724~

DTP Date or Time or Period


Level: Detail Position: 0600 Loop: LX/DTP Repeat: >1 Requirement: Optional Max Use: 1 Purpose: To specify any or all of a date, a time, or a time period
DIAGRAM

DTP01

374

DTP02

1250

DTP03

1251

DTP

Date/Time Qualifier
M1 ID 3/3

Date Time format Qual


M1 ID 2/3

Date Time Period


M1 AN 1/35

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

DTP01

374

Date/Time Qualifier
Code specifying type of date or time, or both date and time
INDUSTRY: Date
CODE

M1

ID

3/3

Time Qualifier
DEFINITION

472

Service

MAY 2004

77

004050X151 275 2100A DTP SERVICE LINE DATE OF SERVICE

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REQUIRED

DTP02

1250

Date Time Period Format Qualifier


SEMANTIC:

M1

ID

2/3

Code indicating the date format, time format, or date and time format DTP02 is the date or time or period format that will appear in DTP03.

1000178

RD8 is required only when the To and From dates are different.
CODE DEFINITION

D8 RD8 REQUIRED

Date Expressed in Format CCYYMMDD Range of Dates Expressed in Format CCYYMMDDCCYYMMDD M 1 AN 1/35

DTP03

1251

Date Time Period


INDUSTRY: Service

Expression of a date, a time, or range of dates, times or dates and times

Date

78

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


DATE OR TIME OR PERIOD

004050X151 275 2100B DTP DATE ADDITIONAL INFORMATION WAS SUBMITTED

DTP

004050X151 275 INFORMATION WAS SUBMITTED DATE ADDITIONAL 2100B DTP

IMPLEMENTATION

DATE ADDITIONAL INFORMATION WAS SUBMITTED


Loop: 2100B DATE ADDITIONAL INFORMATION WAS SUBMITTED Repeat: 1 Usage: REQUIRED Repeat: 1

161
STANDARD

Example: DTP368D820030724~

DTP Date or Time or Period


Level: Detail Position: 0600 Loop: LX/DTP Repeat: >1 Requirement: Optional Max Use: 1 Purpose: To specify any or all of a date, a time, or a time period
DIAGRAM

DTP01

374

DTP02

1250

DTP03

1251

DTP

Date/Time Qualifier
M1 ID 3/3

Date Time format Qual


M1 ID 2/3

Date Time Period


M1 AN 1/35

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

DTP01

374

Date/Time Qualifier
Code specifying type of date or time, or both date and time
INDUSTRY: Date
CODE

M1

ID

3/3

Time Qualifier
DEFINITION

368

Submittal Date information is submitted.

1000179
REQUIRED DTP02 1250

Date Time Period Format Qualifier


SEMANTIC:

M1

ID

2/3

Code indicating the date format, time format, or date and time format DTP02 is the date or time or period format that will appear in DTP03.
DEFINITION

CODE

D8 REQUIRED DTP03 1251

Date Expressed in Format CCYYMMDD M 1 AN 1/35

Date Time Period


INDUSTRY: Additional

Expression of a date, a time, or range of dates, times or dates and times

Information Gathered Date

MAY 2004

79

004050X151 275 2100B CAT CATEGORY OF PATIENT INFORMATION SERVICE


CATEGORY OF PATIENT INFORMATION SERVICE

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

CAT

004050X151 OF PATIENT INFORMATION SERVICE CATEGORY 275 2100B CAT

IMPLEMENTATION

CATEGORY OF PATIENT INFORMATION SERVICE


Loop: 2100B DATE ADDITIONAL INFORMATION WAS SUBMITTED Usage: REQUIRED Repeat: 1

79
STANDARD

Example: CATAEHL~

CAT Category of Patient Information Service


Level: Detail Position: 0700 Loop: LX/DTP Requirement: Optional Max Use: 1 Purpose: To specify categories of patient information service Syntax: 1. C0302 If CAT03 is present, then CAT02 is required. 2. P0405 If either CAT04 or CAT05 is present, then the other is required. 3. C0605 If CAT06 is present, then CAT05 is required. 4. C0704 If CAT07 is present, then CAT04 is required.
DIAGRAM

CAT01

755

CAT02

756

CAT03

799

CAT04

1270

CAT05

1271

CAT06

1271

CAT

Report Report Type Code Transm Code


O1 ID 2/2 X1 ID 1/2

Version ID
O1 AN 1/30

Code List Qual Code


X1 ID 1/3

Industry Code
X1 AN 1/30

Industry Code
O1 AN 1/30

CAT07

799

Version ID
O1 AN 1/30

80

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE ELEMENT SUMMARY


REF. DES. DATA ELEMENT

004050X151 275 2100B CAT CATEGORY OF PATIENT INFORMATION SERVICE

USAGE

NAME

ATTRIBUTES

REQUIRED

CAT01

755

Report Type Code


INDUSTRY: Attachment
CODE

O1

ID

2/2

Code indicating the title or contents of a document, report or supporting item

Report Type Code

DEFINITION

AE REQUIRED CAT02 756

Attachment X1 ID 1/2

Report Transmission Code

Code defining timing, transmission method or format by which reports are to be sent
SYNTAX:

C0302

INDUSTRY: Attachment ALIAS: Industry

Information Format Code

Report Transmission Code

33

Format of the attachment information that will be in the BIN segment.


CODE DEFINITION

HL

Health Industry Level 7 Interface Standards (HL7) Format Required for Claim Attachment types named under HIPAA.
CODE SOURCE 464:

1000155
IA

Health Industry Level 7 (HL7)

Electronic Image This qualifier must not be used when exchanging attachments adopted under HIPAA. When exchanging HIPAA adopted attachments the CAT02 must always be HL. IA may be used when exchanging attachments NOT adopted under HIPAA, so also may the HL qualifier be used in these instances. It is up to mutually agreeing TPs to choose which qualifier to use in cases where attachments are either not yet adopted or not adopted (for some other reason) under HIPAA.

1000198

SITUATIONAL

CAT03

799

Version Identifier
SYNTAX:

O 1 AN

1/30

Revision level of a particular format, program, technique or algorithm C0302

INDUSTRY: Version

Identification Code

1000157
NOT USED NOT USED NOT USED NOT USED CAT04 CAT05 CAT06 CAT07 1270 1271 1271 799

Required when it is necessary to further qualify CAT02. If not required, may be provided at the senders discretion. Code List Qualifier Code Industry Code Industry Code Version Identifier X1 X1 ID AN 1/3 1/30 1/30 1/30

O 1 AN O 1 AN

MAY 2004

81

004050X151 275 2110B EFI ELECTRONIC FORMAT IDENTIFICATION


ELECTRONIC FORMAT IDENTIFICATION

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

EFI

004050X151 FORMAT IDENTIFICATION ELECTRONIC 275 2110B EFI

IMPLEMENTATION

ELECTRONIC FORMAT IDENTIFICATION


Loop: 2110B ELECTRONIC FORMAT IDENTIFICATION Repeat: 1 Usage: REQUIRED Repeat: 1

80
STANDARD

Example: EFI05~

EFI Electronic Format Identification


Level: Detail Position: 0900 Loop: LX/DTP/EFI Repeat: 1 Requirement: Optional Max Use: 1 Purpose: To provide basic information about the electronic format of the interchange data Syntax: 1. C0504 If EFI05 is present, then EFI04 is required. 2. C0706 If EFI07 is present, then EFI06 is required. 3. C0908 If EFI09 is present, then EFI08 is required. 4. P1516 If either EFI15 or EFI16 is present, then the other is required.
DIAGRAM

EFI01

786

EFI02

933

EFI03

797

EFI04

799

EFI05

802

EFI06

799

EFI

Security Level Code


M1 ID 2/2

Free-Form Message Txt


O1 AN 1/264

Security Tech Code


O1 ID 2/2

Version ID
X1 AN 1/30

Program ID
O1 AN 1/30

Version ID
X1 AN 1/30

EFI07

801

EFI08

799

EFI09

800

EFI10

789

EFI11

803

EFI12

804

Interchange Format
O1 AN 1/30

Version ID
X1 AN 1/30

Compression Technique
O1 AN 1/30

Draw Sheet Size Code


O1 AN 2/2

O1

File Name
AN 1/64

O1

Block Type
AN 1/4

EFI13

787

EFI14

788

EFI15

799

EFI16

1570

Record Length
O1 N 1/15

Block Length
O1 N 1/5

Version ID
X1 AN 1/30

Filter ID Code
X1 ID 3/3

82

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE ELEMENT SUMMARY


REF. DES. DATA ELEMENT

004050X151 275 2110B EFI ELECTRONIC FORMAT IDENTIFICATION

USAGE

NAME

ATTRIBUTES

REQUIRED

EFI01

786

Security Level Code

M1

ID

2/2

Code indicating the level of confidentiality assigned by the sender to the information following
CODE DEFINITION

05

Personal Per public law publication 104-191 August 21, 1996 Section 1177 [HIPAA] - This information is confidential and wrongful use is subject to penalties.

162
NOT USED NOT USED NOT USED NOT USED NOT USED NOT USED NOT USED NOT USED NOT USED NOT USED NOT USED NOT USED NOT USED NOT USED NOT USED

EFI02 EFI03 EFI04 EFI05 EFI06 EFI07 EFI08 EFI09 EFI10 EFI11 EFI12 EFI13 EFI14 EFI15 EFI16

933 797 799 802 799 801 799 800 789 803 804 787 788 799 1570

Free-Form Message Text Security Technique Code Version Identifier Program Identifier Version Identifier Interchange Format Version Identifier Compression Technique Drawing Sheet Size Code File Name Block Type Record Length Block Length Version Identifier Filter ID Code

O 1 AN O1 X1 ID AN

1/264 2/2 1/30 1/30 1/30 1/30 1/30 1/30 2/2 1/64 1/4 1/15 1/5 1/30 3/3

O 1 AN X1 AN

O 1 AN X1 AN

O 1 AN O 1 AN O 1 AN O 1 AN O1 O1 X1 X1 N N AN ID

MAY 2004

83

004050X151 275 2110B BIN BINARY DATA SEGMENT


BINARY DATA SEGMENT

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

BIN

004050X151 275 2110B BIN BINARY DATA SEGMENT

IMPLEMENTATION

BINARY DATA SEGMENT


Loop: 2110B ELECTRONIC FORMAT IDENTIFICATION Usage: REQUIRED Repeat: 1

184 163 3 012 100


STANDARD

Notes:

1. This is used to send additional information in the HL7 format. 2. It is recommended that BIN02 not be larger than 64 megabytes.

Example: BIN7xxxxxxx~

BIN Binary Data Segment


Level: Detail Position: 1000 Loop: LX/DTP/EFI Requirement: Mandatory Max Use: 1 Purpose: To transfer binary data in a single data segment and allow identification of the end of the data segment through a count; there is no identification of the internal structure of the binary data in this segment
DIAGRAM

BIN01

784

BIN02

785

BIN

Length of Binary Data


M1 N0 1/15

M1

Binary Data
B 1/1

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

BIN01

784

Length of Binary Data


The length in integral octets of the binary data
INDUSTRY: Binary

M1

N0

1/15

Data Length Number

1000109
REQUIRED BIN02 785

This number should represent all of the characters in the BIN02 data element. Binary Data M1 B 1/1
A string of octets which can assume any binary pattern from hexadecimal 00 to FF

84

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


TRANSACTION SET TRAILER

004050X151 275 SE 275 TRANSACTION SET TRAILER

SE

275 TRANSACTION SE 004050X151 275 SET TRAILER

IMPLEMENTATION

275 TRANSACTION SET TRAILER


Usage: REQUIRED Repeat: 1

83
STANDARD

Example: SE170001~

SE Transaction Set Trailer


Level: Detail Position: 1100 Loop: ____ Requirement: Mandatory Max Use: 1 Purpose: To indicate the end of the transaction set and provide the count of the transmitted segments (including the beginning (ST) and ending (SE) segments)
DIAGRAM

SE01

96

SE02

329

SE

Number of Inc Segs


M1 N0 1/10

TS Control Number
M1 AN 4/9

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

SE01

96

Number of Included Segments

M1

N0

1/10

Total number of segments included in a transaction set including ST and SE segments


INDUSTRY: Transaction

Segment Count

111
REQUIRED

Do not include the segments contained within the HL7 format. However, include the entire BIN segment as one segment in the count. SE02 329 Transaction Set Control Number M 1 AN 4/9
Identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set

142

The Transaction Set Control Number in ST02 and SE02 must be identical. This unique number also aids in error resolution research. Submitters could begin sending transactions using the number 0001 in this element and increment from there. The number must be unique within a specific functional group (GS-GE) and interchange (ISA-IEA), but can repeat in other groups and interchanges.

MAY 2004

85

004050X151 275 SE 275 TRANSACTION SET TRAILER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

86

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

4 EDI Transmission Examples for Business Usages


Overview
The 277 Health Care Claim Request for Additional Information has been written to be able to send questions concerning claims requiring attachment information. The 275 Additional Information to Support a Health Care Claim or Encounter has been written to be able to send answers to standard attachments electronically. The following scenarios have used the Rehabilitative Services (Psychiatric Rehabilitation discipline) and the Ambulance Additional Information Specification booklets as well as the HL7 documentation that accompanies this Implementation Guide. These attachment examples are being used to show how to code the 275.

Scenario One - Electronic request, response is returned on paper/fax:


Scenario one depicts the utilization of the 277 and a response that is faxed to the payer in a Medicare Part A institutional environment. One claim has been electronically transmitted to the Medicare Part A fiscal intermediary through the use of a third party billing service (clearinghouse). In this scenario, the claim has been accepted into the claims adjudication system and requires additional information. The Psychiatric Rehabilitation attachment is needed and is being requested so the claim can continue processing through the adjudication process. A 277 transaction is sent to the provider for the purpose of requesting additional information. The provider responds to the request by faxing the necessary paper documentation to the payer. In this scenario, the provider does not generate a 275 transaction. Medicare Part A Fiscal Intermediary, ABC Insurance Company, has a National Payer Identification (PlanID) of 12345. The payer received one ASC X12N 837 Institutional claim from XYZ Clearing House with submitter number A222222221, on behalf of St. Holy Hills Hospital whose provider number is 3999000B. The hospital has submitted a claim for outpatient services (Bill Type 131) with a service date of August 12, 2003, for Jack J. Jackson. Mr. Jacksons Medicare Health Insurance Claim Number is 987654320. The hospital assigned a patient account number of JACKSON123 and a medical record number of STHHL12345. ABC Insurance Company assigned a payer internal control number of 1822634845. On August 24, 2003, a 277 request for the psychiatric rehabilitation documentation was generated with a response due date of September 23, 2003. The 277 specifies the Payer contact information of the Medical Review Department at ABC Insurance Company, with a fax number of 999-999-9999.

277 Request for Additional Information Transmission ST*277*1001*004050X150~ BHT*0010*48*277X150000001*20030824*1211*RQ~ HL*1**20*1~ NM1*PR*2*ABC INSURANCE COMPANY*****XV*12345~ PER*IC*MEDICAL REVIEW DEPARTMENT*FX*9999999999~ HL*2*1*21*1~
MAY 2004

87

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

NM1*41*2*XYZ CLEARING HOUSE*****46*A222222221~ HL*3*2*19*1~ NM1*1P*2*ST HOLY HILLS HOSPITAL*****SV*3999000B~ HL*4*3*22*0~ NM1*QC*1*JACKSON*JACK*J***MI*987654320~ TRN*1*1822634845~ STC*R4:18594-2::LOI*20030824~ REF*EJ*JACKSON123~ REF*BLT*131~ REF*EA*STHHL12345~ DTP*434*RD8*20030812-20030812~ DTP*106*D8*20030923~ SE*19*1001~ Scenario Two Description
Scenario two depicts the utilization of the 277 and 275 in a Medicare Part A institutional environment. Two claims have been electronically transmitted to the Medicare Part A fiscal intermediary through the use of a third party billing service (clearinghouse). In this scenario, both claims have been accepted into the claims adjudication system and require additional information in order to continue processing. A 277 transaction is sent to the provider for the purpose of requesting additional information. The provider responds to the request giving the necessary information in a 275 transaction. Medicare Part A Fiscal Intermediary, ABC Insurance Company, has a National Payer Identification (PlanID) of 12345. The payer received two ASC X12N 837 Institutional claims from XYZ Clearing House with submitter number A222222221, on behalf of St. Holy Hills Hospital whose provider number is 3999000B. The hospital has submitted a claim for outpatient services (Bill Type 131) with a service date of August 12, 2003, for Jack J. Jackson. Mr. Jacksons Medicare Health Insurance Claim Number is 987654320. The hospital assigned a patient account number of JACKSON123 and a medical record number of STHHL12345. ABC Insurance Company assigned a payer internal control number of 1822634840. On August 24, 2003, a 277 request for the psychiatric rehabilitation document was generated with a response due date of September 23, 2003. The second claim for Peter M. Jones was submitted for inpatient services (Bill Type 111) with service dates of August 7 to August 12, 2003. Mr Jones Medicare Health Insurance Claim Number is 987654321. The hospital assigned a patient account number of JONES123 and a medical record number of STHHL12378. ABC Insurance Company assigned a payer internal control number of 1822634845. On August 24, 2003, a 277 request for the psychiatric rehabilitation document was generated with a response due date of September 23, 2003.

277 Request for Additional Information Transmission ST*277*1001*004050X150~ BHT*0010*48*277X150000001*20030824*1211*RQ~ HL*1**20*1~ NM1*PR*2*ABC INSURANCE COMPANY*****XV*12345~ PER*IC*MEDICAL REVIEW DEPARTMENT~ HL*2*1*21*1~ NM1*41*2*XYZ Clearing House*****46*A222222221~

88

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

HL*3*2*19*1~ NM1*1P*2*ST HOLY HILLS HOSPITAL*****SV*3999000B~ HL*4*3*22*0~ NM1*QC*1*JACKSON*JACK*J***MI*987654320~ TRN*1*1822634840~ STC*R4:18594-2::LOI*20030824~ REF*EJ*JACKSON123~ REF*BLT*131~ REF*EA*STHHL12345~ DTP*434*RD8*20030812-20030812~ DTP*106*D8*20030923~ HL*5*3*22*0~ NM1*QC*1*JONES*PETER*M***MI*987654321~ TRN*2*1822634845~ STC*R4:19016-5::LOI*20030824~ REF*EJ*JONES123~ REF*BLT*111~ REF*EA*STHHL12378~ DTP*434*RD8*20030807-20030812~ DTP*106*D8*20030923~ SVC*NU:0360*2021.75~ STC*R4:18594-2::LOI*20030824~ SE*30*1001~ 275 Additional Information to Support a Health Care Claim or Encounter
The BIN segment in this example displays a Human Decision Variant example.

ST*275*1001*004050X151~ BGN*11*0001*20030915~ NM1*40*2*ABC INSURANCE COMPANY*****XV*12345~ PER*IC*MEDICAL REVIEW DEPARTMENT~ NM1*41*2*XYZ Clearing House*****46*A222222221~ NM1*1P*2*ST HOLY HILLS HOSPITAL*****SV*3999000B~ NM1*QC*1*JACKSON*JACK*J***MI*987654320~ REF*EJ*JACKSON123~ REF*BLT*131~ REF*EA*STHHL12345~ DTP*434*RD8*20030812-20030812~ LX*1~ TRN*2*1822634840~ STC*R4*18594-2::LOI~ DTP*368*D8*20030915~ CAT*AE*HL~ EFI*05~ BIN*8031* <levelone xmlns="urn:hl7-org:v3/cda" xmlns:v3dt="urn:hl7-org:v3/v3dt" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xsi:schemaLocation="urn:hl7-org:v3/cda levelone_1.0.attachments.xsd"> <clinical_document_header>
MAY 2004

89

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

<id EX="a123" RT="2.16.840.1.113883.3.933"/> <document_type_cd V="18594-2" DN="Psychiatric Rehabilitation Attachment"/> <origination_dttm V="2003-09-15"/> <originating_organization> <originating_organization.type_cd V="CST"/> <organization> <id EX="3999000B"/> <organization.nm V="St Holy Hills Hospital"/> </organization> </originating_organization> <patient> <patient.type_cd V="PATSBJ"/> <person> <id EX="987654320" RT="2.16.840.1.113883.3.933"/> <person_name> <nm> <v3dt:GIV V="Jack"/> <v3dt:FAM V="Jackson"/> <v3dt:MID V="J"/> </nm> <person_name.type_cd V="L" S="2.16.840.1.113883.5.200"/> </person_name> </person> </patient> <local_header descriptor="Att_ACN"> <local_attr name="attachment_control_number" value="1822634840"/> </local_header> </clinical_document_header> <body> <section> <caption>NEW/REVISED</caption> <paragraph> <content>New Plan</content> </paragraph> </section> <section> <caption>DATE ONSET OR EXACERBATION OF PRIMARY DIAGNOSIS </caption> <paragraph> <content>26 March 2003</content> </paragraph> </section> <section> <caption>START DATE</caption> <paragraph> <content>22 June 2003</content> </paragraph> </section>

90

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

<section> <caption>PRIMARY DIAGNOSIS</caption> <paragraph> <content>bipolar affective disorder (296.4)</content> </paragraph> </section> <section> <caption>DIAGNOSIS ADDRESSED BY PLAN</caption> <paragraph> <content>bipolar affective disorder (296.4)</content> </paragraph> </section> <section> <caption>AUTHOR OF TREATMENT PLAN </caption> <paragraph> <caption>AUTHOR NAME</caption> <content>JOHN E SMITH, MD</content> </paragraph> <paragraph> <caption>AUTHOR IDENTIFIER</caption> <content> 3582901 (NJ)</content> </paragraph> <paragraph> <caption>AUTHOR PROFESSION</caption> <content>103T00000N Psychologist</content> </paragraph> </section> <section> <caption>VISIT FREQUENCY</caption> <paragraph> <content>3 visits per week for 90 days</content> </paragraph> </section> <section> <caption>DATE RANGE (FROM/THROUGH) DESCRIBED BY PLAN </caption> <paragraph> <caption>START DATE</caption> <content>22 June 2003</content> </paragraph> <paragraph> <caption>PLAN END DATE</caption> <content>22 Sep 2003</content> </paragraph> </section> <section> <caption>DATE RANGE (FROM/THROUGH) OF HOSPITALIZATION LEADING TO TREATMENT </caption>
MAY 2004

91

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

<paragraph> <caption>START DATE</caption> <content>26 March 2003</content> </paragraph> <paragraph> <caption>END DATE</caption> <content>29 March 2003</content> </paragraph> </section> <section> <caption>CONTINUATION STATUS</caption> <paragraph> <content>Continue</content> </paragraph> </section> <section> <caption>DATE ATTENDING MD REFERRED PATIENT FOR TREATMENT </caption> <paragraph> <content>12 June 2003</content> </paragraph> </section> <section> <caption>DATE ATTENDING MD SIGNED</caption> <paragraph> <content>28 June 2003</content> </paragraph> </section> <section> <caption>DATE REHAB PROFESSIONAL SIGNED</caption> <paragraph> <content>28 June 2003</content> </paragraph> </section> <section> <caption>SIGNATURE OF RESPONSIBLE ATTENDING MD ON FILE </caption> <paragraph> <content>Yes</content> </paragraph> </section> <section> <caption>SIGNATURE OF RESPONSIBLE REHAB PROFESSIONAL ON FILE </caption> <paragraph> <content>Yes</content> </paragraph> </section> <section>

92

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

<caption>Medications Administered> </caption> <table cellpadding="15"> <tbody> <tr><td>LITHIUM 600 mg QAM PO</td></tr> <tr><td>LITHIUM 900 mg QHS PO</td></tr> <tr><td>THIOTHIXENE 5 mg TID PO</td></tr> <tr><td>BENZTROPINE 5 mg TID PO</td></tr> <tr><td>INDOMETHACIN 50 mg TID PO</td></tr> </tbody> </table> </section> <section><caption>PROGNOSIS FOR REHABILITATION </caption> <paragraph> <content>Guarded</content> </paragraph> </section> <section> <caption>ESTIMATED DATE OF COMPLETION</caption> <paragraph> <content>30 Sept 2003 <local_markup descriptor="dt_DT" ignore="all"> 2003-09-30</local_markup> </content> </paragraph> </section> <section> <caption>PAST MEDICAL HISTORY + LEVEL OF FUNCTION </caption> <paragraph> <content>PATIENT HAS HAD MULTIPLE PSYCHIATRIC HOSPITALIZATIONS OVER MANY YEARS, MOST RECENTLY 2 INPATIENT ADMISSIONS TO GENERAL HOSPITAL FOR SUICIDAL IDEATION AND SEVERE ANXIETY. PATIENT HAS BEEN UN OR UNDEREMPLOYED SINCE SUICIDE DEATH OF HIS TWIN BROTHER </content> </paragraph> </section> <section> <caption>INITIAL ASSESSMENT</caption> <paragraph> <content>PATIENT IS EXTREMELY ANXIOUS, AGITATED AND NEEDY, CANNOT HOLD EMPLOYMENT, HAS DIFFICULTY ATTENDING PROGRAM REGULARLY, AND CANNOT SIT IN GROUPS FOR 10 MINUTES AT A TIME. RETURNS TO HOSPITAL INPATIENT WARDS WHENEVER ANXIETY BECOMES OVERWHELMING, WHICH IS OFTEN.</content>
MAY 2004

93

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

</paragraph> </section> <section> <caption>PLAN OF TREATMENT</caption> <list> <item><content>FUNCTIONAL GOALS.</content> <list> <item><content>GOAL 1: PATIENT IS WORKING TO COME UP WITH ALTERNATIVES TO INPATIENT HOSPITALIZATION WHEN HE FEELS ABANDONED OR ANXIOUS.</content></item> <item><content>GOAL 2: PATIENT IS EXPECTED TO RETURN TO THE LEVEL OF EMPLOYMENT THAT IS COMMENSORATE WITH HIS COGNITIVE ABILITIES..</content></item> </list> </item> <item><content>PLAN OF TREATMENT</content> <list> <item><content>915/90853 GROUP THERAPY: SYMPTOM MANAGEMENT 3X WEEK WITH PSYCHOLOGIST</content></item> <item><content>LABWORK 1X MONTH: TO MONITOR LITHIUM FOR THERAPEUTIC LEVEL.</content></item> </list> </item> </list> </section> <section> <caption>PROGRESS NOTE + ATTAINMENT OF GOALS </caption> <paragraph> <content>915/90853 GROUP THERAPY: SYMPTOM MANAGEMENT ON 7/17,22,24,27,29,31 WITH PSYCHOLOGIST: PATIENT MADE ATTEMPTS TO COME AND PARTICIPATE IN SYMPTOM MANAGEMENT GROUP. PATIENT WAS URGED TO USE ANXIETY CONTROL TECHNIQUES HE HAD BEEN TAUGHT TO TOLERATE INCREASING LONGER STAGES IN GROUP. PATIENT RESPONDED BY BEING ABLE TO STAY AND PARTICIPATE IN GROUP 50% LONGER</content> </paragraph> <paragraph> <content>DONE ON {DATE}07/17/98 {TEST}LITHIUM LEVEL {RESULT}90 {JUSTIF.}ROUTINE MONITORING OF THERAPEUTIC RESPONSE.</content> </paragraph> </section> <section> <caption>REASON TO CONTINUE</caption> <paragraph>

94

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

<content>PATIENT HAS ACTIVE ANXIETY SYMPTOMS AND SUICIDAL IDEATION AND REQUIRES THIS LEVEL OF CARE TO HELP PREVENT RELAPSE AND INPATIENT TREATMENT.</content> </paragraph> </section> <section> <caption>JUSTIFICATION</caption> <paragraph> <content>PATIENT HAD SEVERAL RECENT PSYCHIATRIC HOSPITALIZATIONS FOR ANXIETY AND SUICIDAL IDEATION, AND REQUIRED THE SUPPORT AND STRUCTURE OF DAY HOSPITAL PROGRAM TO PREVENT RELAPSE AND REHOSPITALIZATION.</content> </paragraph> </section> <section> <caption>PSYCHIATRIC SYMPTOMS</caption> <paragraph> <content>PATIENT WAS AGITATED, ANXIOUS AND NEEDY, EXPRESSING FEARS OF ABANDONMENT AND PASSIVE SUICIDAL IDEATION. PATIENT REQUIRED FREQUENT REINFORCEMENT IN ORDER TO CONTINUE TO FUNCTION OUTSIDE OF AN INPATIENT PSYCHIATRIC WARD.</content> </paragraph> </section> </body> </levelone> SE*16*1001~
The BIN segment in this example displays a Computer Decision Variant example.

ST*275*1002*004050X151~ BGN*11*0001*20030919~ NM1*40*2*ABC INSURANCE COMPANY*****XV*12345~ PER*IC*MEDICAL REVIEW DEPARTMENT~ NM1*41*2*XYZ SERVICES*****46*A222222221~ NM1*1P*2*ST HOLY HILLS HOSPITAL*****SV*3999000B~ NM1*QC*1*JONES*PETER*M***MI*987654321~ REF*EJ*JONES123~ REF*BLT*111~ REF*EA*STHHL12378~ DTP*434*RD8*20030807-20030812~ LX*1~ TRN*2*1822634845~ STC*R4:18594-2::LOI*20030824~ REF*FJ*1~ REF*YJ*0360~ DTP*368*D8*20030919~ CAT*AE*HL~ EFI*05~ BIN*15970*<levelone xmlns="urn:hl7-org:v3/cda"
MAY 2004

95

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

xmlns:v3dt="urn:hl7-org:v3/v3dt" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xsi:schemaLocation="urn:hl7-org:v3/cda levelone_1.0.attachments.xsd"> <clinical_document_header> <id EX="a123" RT="2.16.840.1.113883.3.933"/> <document_type_cd V="18594-2" DN="Psychiatric Rehabilitation Attachment"/> <origination_dttm V="2003-09-19"/> <originating_organization> <originating_organization.type_cd V="CST"/> <organization> <id EX="3999000B"/> <organization.nm V="St Holy Hills Hospital"/> </organization> </originating_organization> <patient> <patient.type_cd V="PATSBJ"/> <person> <id EX="987654321" RT="2.16.840.1.113883.3.933"/> <person_name> <nm> <v3dt:GIV V="Peter"/> <v3dt:FAM V="Jones"/> <v3dt:MID V="M"/> </nm> <person_name.type_cd V="L" S="2.16.840.1.113883.5.200"/> </person_name> </person> </patient> <local_header descriptor="Att_ACN"> <local_attr name="attachment_control_number" value="1822634845"/> </local_header> </clinical_document_header> <body> <section> <caption><caption_cd V="18626-2" S="2.16.840.1.113883.6.1"/> NEW/REVISED</caption> <paragraph> <content>New Plan <coded_entry> <coded_entry.value V="700" S="OID to be provided" SN="HL79002"/> </coded_entry> </content> </paragraph> </section> <section>

96

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

<caption><caption_cd V="18627-0" S="2.16.840.1.113883.6.1"/> DATE ONSET OR EXACERBATION OF PRIMARY DIAGNOSIS </caption> <paragraph> <content>26 March 2003 <local_markup descriptor="dt_DT" ignore="all">2003-03-26</local_markup> </content> </paragraph> </section> <section> <caption><caption_cd V="18628-8" S="2.16.840.1.113883.6.1"/> START DATE</caption> <paragraph> <content>22 June 2003 <local_markup descriptor="dt_DT" ignore="all">2003-06-22</local_markup> </content> </paragraph> </section> <section> <caption><caption_cd V="19007-4" S="2.16.840.1.113883.6.1"/> PRIMARY DIAGNOSIS</caption> <paragraph> <content>bipolar affective disorder (296.4) <coded_entry> <coded_entry.value V="296.4" S="2.16.840.1.113883.6.2" SN="ICD-9-CM"/> </coded_entry> </content> </paragraph> </section> <section> <caption><caption_cd V="18631-2" S="2.16.840.1.113883.6.1"/> DIAGNOSIS ADDRESSED BY PLAN </caption> <paragraph> <content>bipolar affective disorder (296.4) <coded_entry> <coded_entry.value V="296.4" S="2.16.840.1.113883.6.2" SN="ICD-9-CM"/> </coded_entry> </content> </paragraph> </section> <section> <caption><caption_cd V="18632-0" S="2.16.840.1.113883.6.1"/>
MAY 2004

97

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

AUTHOR OF TREATMENT PLAN </caption> <paragraph> <caption><caption_cd V="18633-8" S="2.16.840.1.113883.6.1"/> AUTHOR NAME </caption> <content>JOHN E SMITH, MD <local_markup descriptor="dt_PN"> <local_markup descriptor="dt_PN_GIV"> JOHN</local_markup> <local_markup descriptor="dt_PN_MID">E </local_markup> <local_markup descriptor="dt_PN_FAM"> SMITH</local_markup> <local_markup descriptor="dt_PN_SFX">MD </local_markup> </local_markup> </content> </paragraph> <paragraph> <caption><caption_cd V="18730-2" S="2.16.840.1.113883.6.1"/> AUTHOR IDENTIFIER </caption> <content> 3582901 (NJ) <local_markup descriptor="dt_CX"> <local_attr name="dt_CX_EX" value="3582901"/> <local_attr name="dt_CX_RT" value="2.16.840.1.113883.5.1"/> </local_markup> </content> </paragraph> <paragraph> <caption><caption_cd V="18634-6" S="2.16.840.1.113883.6.1"/> AUTHOR PROFESSION </caption> <content>103T00000N Psychologist <coded_entry> <coded_entry.value V="103T00000N S= 2.16.840.1.113883.6.101 SN=USProvTxnmy"/> </coded_entry> </content> </paragraph> </section> <section> <caption><caption_cd V="18637-9" S="2.16.840.1.113883.6.1"/> VISIT FREQUENCY</caption> <paragraph>

98

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

<content>3 visits per week for 90 days</content> </paragraph> </section> <section> <caption><caption_cd V="18639-5" S="2.16.840.1.113883.6.1"/> DATE RANGE (FRESCRIBED BY PLAN </caption> <paragraph> <caption><caption_cd V="18640-3" S="2.16.840.1.113883.6.1"/> START DATE</caption> <content>22 June 2003 <local_markup descriptor="dt_DT" ignore="all"> 2003-06-22</local_markup> </content> </paragraph> <paragraph> <caption><caption_cd V="18641-1" S="2.16.840.1.113883.6.1"/> PLAN END DATE</caption> <content>22 Sep 2003 <local_markup descriptor="dt_DT" ignore="all"> 2003-09-22</local_markup> </content> </paragraph> </section> <section> <caption><caption_cd V="18642-9" S="2.16.840.1.113883.6.1"/> DATE RANGE (FROM/THROUGH) OF HOSPITALIZATION LEADING TO TREATMENT </caption> <paragraph> <caption><caption_cd V="18643-7" S="2.16.840.1.113883.6.1"/> START DATE OF HOSPITALIZATION LEADING TO TREATMENT </caption> <content>26 March 2003 <local_markup descriptor="dt_DT" ignore="all"> 2003-03-26</local_markup> </content> </paragraph> <paragraph> <caption><caption_cd V="18644-5" S="2.16.840.1.113883.6.1"/> END DATE OF HOSPITALIZATION LEADING TO TREATMENT
MAY 2004

99

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

</caption> <content>29 March 2003 <local_markup descriptor="dt_DT" ignore="all"> 2003-03-29</local_markup> </content> </paragraph> </section> <section> <caption><caption_cd V="18645-2" S="2.16.840.1.113883.6.1"/> CONTINUATION STATUS </caption> <paragraph> <content>Continue <coded_entry> <coded_entry.value V="C" S="2.16.840.1.113883.12.9003" SN="Rehab continue/discontinue"/> </coded_entry> </content> </paragraph> </section> <section> <caption><caption_cd V="18646-0" S="2.16.840.1.113883.6.1"/> DATE ATTENDING MD REFERRED PATIENT FOR TREATMENT </caption> <paragraph> <content>12 June 2003 <local_markup descriptor="dt_DT" ignore="all">2003-06-12</local_markup> </content> </paragraph> </section> <section> <caption><caption_cd V="18647-8" S="2.16.840.1.113883.6.1"/> DATE ATTENDING MD SIGNED </caption> <paragraph> <content>28 June 2003 <local_markup descriptor="dt_DT" ignore="all"> 2003-06-28</local_markup> </content> </paragraph> </section> <section> <caption><caption_cd V="18648-6" S="2.16.840.1.113883.6.1"/> DATE REHAB PROFESSIONAL SIGNED

100

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

</caption> <paragraph> <content>28 June 2003 <local_markup descriptor="dt_DT" ignore="all"> 2003-06-28</local_markup> </content> </paragraph> </section> <section> <caption><caption_cd V="18649-4" S="2.16.840.1.113883.6.1"/> SIGNATURE OF RESPONSIBLE ATTENDING MD ON FILE </caption> <paragraph> <content>Yes <coded_entry> <coded_entry.value V="Y" S="2.16.840.1.113883.12.136" SN="HL7 Yes/No"/> </coded_entry> </content> </paragraph> </section> <section> <caption><caption_cd V="18650-2" S="2.16.840.1.113883.6.1"/> SIGNATURE OF RESPONSIBLE REHAB PROFESSIONAL ON FILE </caption> <paragraph> <content>Yes <coded_entry> <coded_entry.value V="Y" S="2.16.840.1.113883.12.136" SN="HL70136"/> </coded_entry> </content> </paragraph> </section> <section> <caption><caption_cd V="18651-0" S="2.16.840.1.113883.6.1"/> Medications Administered </caption> <table cellpadding="15"> <thead> <tr> <th><caption_cd V="18816-9" S="2.16.840.1.113883.6.1"/> Medication </th>
MAY 2004

101

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

<th><caption_cd V="18817-7" S="2.16.840.1.113883.6.1"/> Dose </th> <th><caption_cd V="18818-5" S="2.16.840.1.113883.6.1"/> Timing </th> <th><caption_cd V="18819-3" S="2.16.840.1.113883.6.1"/> Route </th> </tr> </thead> <tbody> <tr> <td>LITHIUM</td> <td align="right">600 mg <local_markup descriptor="dt_nm" ignore="all">600 <coded_entry> <coded_entry.value V="mg" S="2.16.840.1.113883.5.141"/> </coded_entry> </local_markup > </td> <td>QAM <local_markup descriptor="dt_TQ"> <local_markup descriptor="dt_TQ_IVL" ignore="all">QAM </local_markup> </local_markup> </td> <td>Oral <coded_entry> <coded_entry.value V="PO" S="2.16.840.1.113883.12.162" SN="HL7 Yes/No"/> </coded_entry> </td> </tr> <tr> <td>LITHIUM</td> <td align="right">900 mg <local_markup descriptor="dt_nm" ignore="all">900 <coded_entry> <coded_entry.value V="mg" S="2.16.840.1.113883.5.141"/> </coded_entry> </local_markup > </td> <td>at bedtime

102

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

<local_markup descriptor="dt_TQ"> <local_markup descriptor="dt_TQ_IVL" ignore="all">QHS </local_markup> </local_markup> </td> <td>Oral <coded_entry> <coded_entry.value V="PO" S="2.16.840.1.113883.12.162" SN="Route of administration"/> </coded_entry> </td> </tr> <tr> <td>THIOTHIXENE</td> <td align="right">5 mg <local_markup descriptor="dt_nm" ignore="all">5 <coded_entry> <coded_entry.value V="mg" S="2.16.840.1.113883.5.141"/> </coded_entry> </local_markup > </td> <td>TID <local_markup descriptor="dt_TQ"> <local_markup descriptor="dt_TQ_IVL" ignore="all">TID </local_markup> </local_markup> </td> <td>Oral <coded_entry> <coded_entry.value V="PO" S="2.16.840.1.113883.12.162" SN="Route of administration"/> </coded_entry> </td> </tr> <tr> <td>BENZTROPINE</td> <td align="right">5 mg <local_markup descriptor="dt_nm" ignore="all">5 <coded_entry> <coded_entry.value V="mg" S="2.16.840.1.113883.5.141"/> </coded_entry> </local_markup > </td> <td>TID <local_markup descriptor="dt_TQ">
MAY 2004

103

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

<local_markup descriptor="dt_TQ_IVL" ignore="all">TID </local_markup> </local_markup> </td> <td>Oral <coded_entry> <coded_entry.value V="PO" S="2.16.840.1.113883.12.162" SN="Route of administration"/> </coded_entry> </td> </tr> <tr> <td>INDOMETHACIN</td> <td align="right">50 mg <local_markup descriptor="dt_nm" ignore="all">50 <coded_entry> <coded_entry.value V="mg" S="2.16.840.1.113883.5.141"/> </coded_entry> </local_markup > </td> <td>TID <local_markup descriptor="dt_TQ"> <local_markup descriptor="dt_TQ_IVL" ignore="all">TID </local_markup> </local_markup> </td> <td>Oral <coded_entry> <coded_entry.value V="PO" S="2.16.840.1.113883.12.162 </coded_entry> </td> </tr> </tbody> </table> </section> <section> <caption> <caption_cd V="18652-8" S="2.16.840.1.113883.6.1"/> PROGNOSIS FOR REHABILITATION </caption> <paragraph> <content>Guarded <coded_entry> <coded_entry.value V="2" S="2.16.840.1.113883.12.9005" SN="Rehabilitation Plan Prognosis"/>

104

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

</coded_entry> </content> </paragraph> </section> <section> <caption><caption_cd V="18653-6" S="2.16.840.1.113883.6.1"/> ESTIMATED DATE OF COMPLETION </caption> <paragraph> <content>30 Sept 2003 <local_markup descriptor="dt_DT" ignore="all"> 2003-09-30</local_markup> </content> </paragraph> </section> <section> <caption><caption_cd V="18655-1" S="2.16.840.1.113883.6.1"/> PAST MEDICAL HISTORY + LEVEL OF FUNCTION </caption> <paragraph> <content>PATIENT HAS HAD MULTIPLE PSYCHIATRIC HOSPITALIZATIONS OVER MANY YEARS, MOST RECENTLY 2 INPATIENT ADMISSIONS TO GENERAL HOSPITAL FOR SUICIDAL IDEATION AND SEVERE ANXIETY. PATIENT HAS BEEN UN OR UNDEREMPLOYED SINCE SUICIDE DEATH OF HIS TWIN BROTHER </content> </paragraph> </section> <section> <caption><caption_cd V="18656-9" S="2.16.840.1.113883.6.1"/> INITIAL ASSESSMENT </caption> <paragraph> <content>PATIENT IS EXTREMELY ANXIOUS, AGITATED AND NEEDY, CANNOT HOLD EMPLOYMENT, HAS DIFFICULTY ATTENDING PROGRAM REGULARLY, AND CANNOT SIT IN GROUPS FOR 10 MINUTES AT A TIME. RETURNS TO HOSPITAL INPATIENT WARDS WHENEVER ANXIETY BECOMES OVERWHELMING, WHICH IS OFTEN.</content> </paragraph> </section> <section> <caption><caption_cd V="18657-7" S="2.16.840.1.113883.6.1"/> PLAN OF TREATMENT</caption> <list> <item><content>FUNCTIONAL GOALS.</content>
MAY 2004

105

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

<list> <item><content>GOAL 1: PATIENT IS WORKING TO COME UP WITH ALTERNATIVES TO INPATIENT HOSPITALIZATION WHEN HE FEELS ABANDONED OR ANXIOUS.</content></item> <item><content>GOAL 2: PATIENT IS EXPECTED TO RETURN TO THE LEVEL OF EMPLOYMENT THAT IS COMMENSORATE WITH HIS COGNITIVE ABILITIES..</content></item> </list> </item> <item><content>PLAN OF TREATMENT</content> <list> <item><content>915/90853 GROUP THERAPY: SYMPTOM MANAGEMENT 3X WEEK WITH PSYCHOLOGIST</content></item> <item><content>LABWORK 1X MONTH: TO MONITOR LITHIUM FOR THERAPEUTIC LEVEL.</content></item> </list> </item> </list> </section> <section> <caption><caption_cd V="18658-5" S="2.16.840.1.113883.6.1"/> PROGRESS NOTE + ATTAINMENT OF GOALS </caption> <paragraph> <content>915/90853 GROUP THERAPY: SYMPTOM MANAGEMENT ON 7/17,22,24,27,29,31 WITH PSYCHOLOGIST: PATIENT MADE ATTEMPTS TO COME AND PARTICIPATE IN SYMPTOM MANAGEMENT GROUP. PATIENT WAS URGED TO USE ANXIETY CONTROL TECHNIQUES HE HAD BEEN TAUGHT TO TOLERATE INCREASING LONGER STAGES IN GROUP. PATIENT RESPONDED BY BEING ABLE TO STAY AND PARTICIPATE IN GROUP 50% LONGER</content> </paragraph> <paragraph> <content>DONE ON {DATE}07/17/98 {TEST}LITHIUM LEVEL {RESULT}90 {JUSTIF.}ROUTINE MONITORING OF THERAPEUTIC RESPONSE.</content> </paragraph> </section> <section> <caption><caption_cd V="18659-3" S="2.16.840.1.113883.6.1"/> REASON TO CONTINUE </caption> <paragraph> <content>PATIENT HAS ACTIVE ANXIETY SYMPTOMS

106

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

AND SUICIDAL IDEATION AND REQUIRES THIS LEVEL OF CARE TO HELP PREVENT RELAPSE AND INPATIENT TREATMENT.</content> </paragraph> </section> <section> <caption><caption_cd V="18660-1" S="2.16.840.1.113883.6.1"/> JUSTIFICATION</caption> <paragraph> <content>PATIENT HAD SEVERAL RECENT PSYCHIATRIC HOSPITALIZATIONS FOR ANXIETY AND SUICIDAL IDEATION, AND REQUIRED THE SUPPORT AND STRUCTURE OF DAY HOSPITAL PROGRAM TO PREVENT RELAPSE AND REHOSPITALIZATION.</content> </paragraph> </section> <section> <caption><caption_cd V="18661-9" S="2.16.840.1.113883.6.1"/> PSYCHIATRIC SYMPTOMS </caption> <paragraph> <content>PATIENT WAS AGITATED, ANXIOUS AND NEEDY, EXPRESSING FEARS OF ABANDONMENT AND PASSIVE SUICIDAL IDEATION. PATIENT REQUIRED FREQUENT REINFORCEMENT IN ORDER TO CONTINUE TO FUNCTION OUTSIDE OF AN INPATIENT PSYCHIATRIC WARD.</content> </paragraph> </section> </body> </levelone> SE*16*1001~ Scenario Three
Description Scenario three depicts the utilization of the unsolicited ASC X12N 275 in an institutional 837 claim environment. This example shows two claims with one of the claims having a 275 Additional Information being transmitted electronically to the Medicare Part A fiscal intermediary through the use of a third party billing service (clearinghouse). ABC Insurance Company has a Payer Identifier (Payer ID) of 12345 and is a Medicare Part A Intermediary. The insurance company received an electronic 837 claim transmissions from XYZ Services, a clearing house with submitter number A222222221, on behalf of St. Holy Hills Hospital whose Part A provider number is 3999000B with a Employer Tax ID of 99-1234567. XYZ Services address is 234 Main Street, Miami, FL 33132-3111 and the contact person is Jane Doe. St. Holy Hills Hospitals address is 2345 Winter Blvd, Miami, FL 33132-3111.

MAY 2004

107

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

The transmission contains two Institutional claims. The first claim submitted is for ambulance services (Bill Type 131) rendered on September 15, 2003 for Jack J Jackson. Mr Jacksons Medicare Health Insurance Claim Number is 987654323. The hospital assigned a patient control number of JACKSON123 and medical record number of STHHL12345. Mr Jacksons address is 125 City Avenue, Miami, FL, 33132-3111 and is 7 miles from St. Holy Hills Hospital. ABC Insurance Company always wants an Ambulance certification on any ambulance run so rather than wait for a request, St Holy Hills Hospital has sent the ambulance certification in the 275 within the same interchange as the 837 claim. St. Holy Hills assigned the Attachment Control Number as 986543. The second claim submitted is for outpatient services (Bill Type131) rendered on June 14, 2003 on behalf of Joe Smith. Mr Smiths Medicare Health Insurance Claim Number is 987654324. The Hospitals patient control number is SMITH123 and a medical record number of STHHL12389. Below is the 837 and the 275 that have been sent to ABC Insurance Company. The BIN segment in this example displays a Human decision variant coded example.

Institutional Transmission ISA*00* *00* *ZZ*A222222221 *ZZ*12345 *030918*0908*^*00402* 000001173*0*P*:~ GS*HC*A222222221*12345*19970918*0908*1173*X* 004010X096A1~ ST*837*987654~ BHT*0019*00*0123*20030918*0932*CH~ REF*87*004010X096A1~ NM1*41*2*XYZ SERVICE*****46*A222222221~ PER*IC*JANE DOE*TE*8005551212~ NM1*40*2*ABC INSURANCE COMPANY*****46*12345~ HL*1**20*1~ PRV*BI*ZZ*609TL0100Y~ NM1*85*2*ST HOLY HILLS HOSPITAL*****24*99-1234567~ N3*2345 WINTER BLVD~ N4*MIAMI*FL*331323111~ REF*1C*3999000B~ PER*IC*SUE SMITH*TE*8007775555~ HL*2*1*22*0~ SBR*P*18*******MA~ NM1*IL*1*JACKSON*JACK*J***MI*987654323~ N3*125 CITY AVENUE~ N4*MIAMI*FL*331323111~ DMG*D8*19261111*M~ NM1*PR*2*ABC INSURANCE COMPANY*****PI*12345~ CLM*JACKSON123*500***13:A:1*Y*A*Y*Y********N~ DTP*434*RD8*20030915-20030915~ CL1*2*7*01~ PWK*OB*EL***AC*986543~ REF*EA*STHHL12345~ HI*BK:3669*BJ:4019~ HI*BF:79431~ NMl*71*1*JONES*JOHN*J***XX*B99937~

108

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

PRV*AT*ZZ*363LPO200N~ SBR*S*01*351630*STATE TEACHERS*SP*****CI~ OI***Y***Y~ NMl*IL*l*JACKSON*JILL*C***MI*333991111~ N3*125 CITY AVENUE~ N4*MIAMI*FL*331323111~ NMl*PR*2*STATE TEACHERS*****PI*1135~ LX*1~ SV2*0540*HC:A0030:RH:QN*150*UN*1~ DTP*472*D8*20030911~ LX*2~ SV2*0540*HC:A0380:RH:QN*100*UN*10~ DTP*472*D8*20030911~ LX*3~ SV2*0540*HC:A0030:HR:QN*150*UN*1~ DTP*472*D8*20030911~ LX*4~ SV2*0540*HC:A0380:HR:QN*100*UN*10~ DTP*472*D8*20030911~ LX*5~ SV2*0001*500~ DTP*472*D8*20030911~ HL*3*1*22*0~ SBR*P*18*******MA~ NM1*IL*1*SMITH*JOE****MI*987654324~ N3*5 MAIN STREET~ N4*MIAMI*FL*331323111~ DMG*D8*19120512*M~ NM1*PR*2*ABC INSURANCE COMPANY*****PI*12345~ CLM*SMITH123*50***13:A:1*Y*A*Y*Y*********N~ DTP*434*RD8*20030614-20030614~ HI*BK:30000~ NMl*71*1*JONES*JOHN*J***XX*B99937~ PRV*AT*ZZ*363LPO200N~ LX*1~ SV2*300*HC:85087*50*UN*1~ DTP*472*D8*20030614~ SE*66*987654~ GE*1*1173~
The BIN segment in this example displays a Computer decision variant coded example.

GS*PI*A222222221*12345*030918*0908*1174*X* 004050X151~ ST*275*1001*004050X151~ BGN*02*0001*20030918~ NM1*40*2*ABC INSURANCE COMPANY*****46*12345~ PER*IC*MEDICAL REVIEW DEPARTMENT~ NM1*41*2*XYZ SERVICE*****46*A222222221~ NM1*1P*2*ST HOLY HILLS HOSPITAL*****SV*3999000B~ NM1*QC*1*JACKSON*JACK*J***MI*987654323~ REF*EJ*JACKSON123~ REF*BLT*131~
MAY 2004

109

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REF*EA*STHHL12345~ DTP*434*RD8*20030915-20030915~ LX*1~ TRN*1*986543~ DTP*368*D8*20030918~ CAT*AE*HL~ EFI*05~ BIN*3192*<levelone xmlns="urn:hl7-org:v3/cda" xmlns:v3dt="urn:hl7-org:v3/v3dt" xmlns:xsi="http://www.w3.org/2001/XMLSchema -instance" xsi:schemaLocation="urn:hl7-org:v3/cda levelone_1.0.attachments.xsd"> <clinical_document_header> <id EX="a123" RT="2.16.840.1.113883.3.933" /> <document_type_cd V="18682-5" DN="AMBULANCE SERVICE CLAIMS ATTACHMENT" /> <origination_dttm V="2000-09-18" /> <originating_organization> <originating_organization.type_cd V="CST" /> <organization> <id EX="3999000B" /> <organization.nm V="St Holy Hills Hospital" /> </organization> </originating_organization> <patient> <patient.type_cd V="PATSBJ" /> <person> <id EX="987654323" RT="2.16.840.1.113883.3.933" /> <person_name> <nm> <v3dt:GIV V="Jack" /> <v3dt:FAM V="Jackson" /> <v3dt:MID V="J" /> </nm> </person_name> </person> </patient> <local_header descriptor="Att_ACN"> <local_attr name="attachment_control_number" value="986543" /> </local_header> </clinical_document_header> <body> <section> <caption>Body Weight at Time of Transport</caption> <paragraph> <caption>Body Weight at Time of Transport</caption> <content>287 lb</content> </paragraph>

110

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

</section> <section> <caption>Transport Direction</caption> <paragraph> <caption>Transport Direction</caption> <content>Initial trip</content> </paragraph> </section> <section> <caption>Rationale for Choice of Destination</caption> <paragraph> <caption>Rationale for Choice of Destination</caption> <content>Patient was transported to nearest facility for care of symptoms, complaints or both.</content> </paragraph> </section> <section> <caption>EMS Transport, Distance Transported</caption> <paragraph> <caption>EMS Transport, Distance Transported</caption> <content>7 mi</content> </paragraph> </section> <section> <caption>Ems Transport, Origination Site</caption> <paragraph> <caption>EMS Transport, Origination Site Name</caption> <content>HOME</content> </paragraph> <paragraph> <caption>EMS Transport, Origination Site ADDRESS</caption> <content>125 City Avenue; Miami, FL 33132-3111</content> </paragraph> </section> <section> <caption>EMS Transport, Destination Site Information</caption> <paragraph> <caption>EMS Transport Destination Site Name</caption> <content>St Holy Hills Hospital</content> </paragraph> <paragraph> <caption>EMS Transport, Destination Site
MAY 2004

111

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

Address</caption> <content>2345 Winter Blvd; Miami, FL 33132-3111</content> </paragraph> </section> <section> <caption>EMS Transport, Admitted At Destination Facility On Transfer</caption> <paragraph> <caption>EMS Transport, Admitted At Destination Facility On Transfer</caption> <content>Yes</content> </paragraph> </section> </body> </levelone> SE*18*1001~ GE*1*1174~ IEA*2*000001173~

112

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

A Nomenclature
A.1
A.1.1

ASC X12 Nomenclature


Interchange and Application Control Structures
Appendix A is provided for guidance about the X12 syntax, usage, and related information. It is not a full statement of Interchange and Control Structure rules. The full X12 Interchange and Control Structures and other rules (X12.5, X12.6, X12.59 and X12 dictionaries and other X12 standards and official documents) apply unless specifically modified in Sections 1, 2, or 3 of this guide or unless specific statements are made in this appendix or Appendix B about specific implementations, such as are made in Section A.1.1.3.1.2.

A.1.1.1

Interchange Control Structure


The transmission of data proceeds according to very strict format rules to ensure the integrity and maintain the efficiency of the interchange. Each business grouping of data is called a transaction set. For instance, a group Communications Transport Protocol of benefit enrollments sent from a sponsor to a payer is Interchange Control Header ISA considered a transaction set.
GS Functional Group Header Transaction Set Header FUNCTIONAL GROUP Detail Segments
for example, Benefit Enrollment

ST

Transaction Set Header Detail Segments


for example, Claim Payment

SE

Transaction Set Trailer

The sequence of the eleGE Functional Group Trailer ments within one segment is IEA Interchange Control Trailer specified by the ASC X12 standard as well as the seCommunications Transport Trailer quence of segments in the transaction set. In a more conFigure A.1. Transmission Control Schematic ventional computing environMAY 2004

FUNCTIONAL GROUP

Each transaction set contains groups of logically related data in units called segments. For instance, the N4 segment used in the transaction set conveys the city, state, ZIP Code, and other geographic information. A transaction set contains multiple segments, so the addresses of the different parties, for example, can be conveyed from one computer to the other. An analogy would be that the transaction set is like a freight train; the segments are like the trains cars; and each segment can contain several data elements the same as a train car can hold multiple crates.

ST

ST

Transaction Set Header Detail Segments


for example, Benefit Enrollment

SE GE GS

Transaction Set Trailer Functional Group Trailer Functional Group Header

A.1

COMMUNICATIONS ENVELOPE

SE

Transaction Set Trailer

INTERCHANGE ENVELOPE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

ment, the segments would be equivalent to records, and the elements equivalent to fields. Similar transaction sets, called functional groups, can be sent together within a transmission. Each functional group is prefaced by a group start segment; and a functional group is terminated by a group end segment. One or more functional groups are prefaced by an interchange header and followed by an interchange trailer. Figure A.1., Transmission Control Schematic, illustrates this interchange control. The interchange header and trailer segments envelop one or more functional groups or interchange-related control segments and perform the following functions: 1. 2. 3. 4. Define the data element separators and the data segment terminator. Identify the sender and receiver. Provide control information for the interchange. Allow for authorization and security information.

A.1.1.2
A.1.1.2.1

Application Control Structure Definitions and Concepts


Basic Structure
A data element corresponds to a data field in data processing terminology. A data segment corresponds to a record in data processing terminology. The data segment begins with a segment ID and contains related data elements. A control segment has the same structure as a data segment; the distinction is in the use. The data segment is used primarily to convey user information, but the control segment is used primarily to convey control information and to group data segments.

A.1.1.2.2

Basic Character Set


The section that follows is designed to have representation in the common character code schemes of EBCDIC, ASCII, and CCITT International Alphabet 5. The ASC X12 standards are graphic-character-oriented; therefore, common character encoding schemes other than those specified herein may be used as long as a common mapping is available. Because the graphic characters have an implied mapping across character code schemes, those bit patterns are not provided here. The basic character set of this standard, shown in Figure A.2., Basic Character Set, includes those selected from the uppercase letters, digits, space, and special characters as specified below.
A...Z 0...9 ! & ; ( ? ) = * +

. / : Figure A.2. Basic Character Set

(space)

A.2

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

A.1.1.2.3

Extended Character Set


An extended character set may be used by negotiation between the two parties and includes the lowercase letters and other special characters as specified in Figure A.3., Extended Character Set.
a..z } % \ ~ | @ < [ > ] # _ $ {

Figure A.3. Extended Character Set

Note that the extended characters include several character codes that have multiple graphical representations for a specific bit pattern. The complete list appears in other standards such as CCITT S.5. Use of the USA graphics for these codes presents no problem unless data is exchanged with an international partner. Other problems, such as the translation of item descriptions from English to French, arise when exchanging data with an international partner, but minimizing the use of codes with multiple graphics eliminates one of the more obvious problems. For implementations compliant with this guide, either the entire extended character set must be acceptable, or the entire extended character set must not be used. In the absence of a specific trading partner agreement to the contrary, trading partners will assume that the extended character set is acceptable. Use of the extended character set allows the use of the @ character in email addresses within the PER segment. Users should note that characters in the extended character set, as well as the basic character set, may be used as delimiters only when they do not occur in the data as stated in Section A.1.1.2.7.

A.1.1.2.4

Control Characters
Two control character groups are specified; they have only restricted usage. The common notation for these groups is also provided, together with the character coding in three common alphabets. In the Matrix A.1., Base Control Set, the column IA5 represents CCITT V.3 International Alphabet 5.

A.1.1.2.5

Base Control Set


The base control set includes those characters that will not have a disruptive effect on most communication protocols. These are represented by:
NOTATION NAME BEL bell HT horizontal tab LF line feed VT vertical tab FF form feed CR carriage return FS file separator GS group separator RS record separator US unit separator NL new line Matrix A.1. Base Control Set EBCDIC 2F 05 25 0B 0C 0D 1C 1D 1E 1F 15 ASCII 07 09 0A 0B 0C 0D 1C 1D 1E 1F IA5 07 09 0A 0B 0C 0D 1C 1D 1E 1F

The Group Separator (GS) may be an exception in this set because it is used in the 3780 communications protocol to indicate blank space compression.

MAY 2004

A.3

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

A.1.1.2.6

Extended Control Set


The extended control set includes those that may have an effect on a transmission system. These are shown in Matrix A.2., Extended Control Set.
NOTATION NAME SOH start of header STX start of text ETX end of text EOT end of transmission ENQ enquiry ACK acknowledge DC1 device control 1 DC2 device control 2 DC3 device control 3 DC4 device control 4 NAK negative acknowledge SYN synchronous idle ETB end of block Matrix A.2. Extended Control Set EBCDIC 01 02 03 37 2D 2E 11 12 13 3C 3D 32 26 ASCII 01 02 03 04 05 06 11 12 13 14 15 16 17 IA5 01 02 03 04 05 06 11 12 13 14 15 16 17

A.1.1.2.7

Delimiters
A delimiter is a character used to separate two data elements (or subelements) or to terminate a segment. The delimiters are an integral part of the data. Delimiters are specified in the interchange header segment, ISA. The ISA segment can be considered in implementations compliant with this guide (see Appendix B, ISA Segment Note 1) to be a 105 byte fixed length record, followed by a segment terminator. The data element separator is byte number 4; the repetition separator is byte number 83; the component element separator is byte number 105; and the segment terminator is the byte that immediately follows the component element separator. Once specified in the interchange header, the delimiters are not to be used in a data element value elsewhere in the interchange. For consistency, this implementation guide uses the delimiters shown in Matrix A.3., Delimiters, in all examples of EDI transmissions.
CHARACTER * ^ : ~ Matrix A.3. Delimiters NAME Asterisk Caret Colon Tilde DELIMITER Data Element Separator Repetition Separator Subelement Separator Segment Terminator

The delimiters above are for illustration purposes only and are not specific recommendations or requirements. Users of this implementation guide should be aware that an application system may use some valid delimiter characters within the application data. Occurrences of delimiter characters in transmitted data within a data element can result in errors in translation programs. The existence of asterisks (*) within transmitted application data is a known issue that can affect translation software.

A.4

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

A.1.1.3

Business Transaction Structure Definitions and Concepts


The ASC X12 standards define commonly used business transactions (such as a health care claim) in a formal structure called transaction sets. A transaction set is composed of a transaction set header control segment, one or more data segments, and a transaction set trailer control segment. Each segment is composed of the following: A unique segment ID One or more logically related data elements each preceded by a data element separator A segment terminator

A.1.1.3.1

Data Element
The data element is the smallest named unit of information in the ASC X12 standard. Data elements are identified as either simple or component. A data element that occurs as an ordinally positioned member of a composite data structure is identified as a component data element. A data element that occurs in a segment outside the defined boundaries of a composite data structure is identified as a simple data element. The distinction between simple and component data elements is strictly a matter of context because a data element can be used in either capacity. Data elements are assigned a unique reference number. Each data element has a name, description, type, minimum length, and maximum length. For ID type data elements, this guide provides the applicable ASC X12 code values and their descriptions or references where the valid code list can be obtained. A simple data element within a segment or a composite data element may have an attribute indicating that it may occur once or a specific number of times more than once. The number of permitted repeats are defined as an attribute in the individual segment or composite structure where the repeated data element occurs. In this implementation guide, no simple data element repeats. Each data element is assigned a minimum and maximum length. The length of the data element value is the number of character positions used except as noted for numeric, decimal, and binary elements. The data element types shown in Matrix A.4., Data Element Types, appear in this implementation guide.
SYMBOL TYPE Nn Numeric R Decimal ID Identifier AN String DT Date TM Time B Binary Matrix A.4. Data Element Types

The data element minimum and maximum lengths may be restricted in this implementation guide for a compliant implementation. Such restrictions may occur by

MAY 2004

A.5

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

virtue of the allowed qualifier for the data element or by specific instructions regarding length or format as stated in this implementation guide. A.1.1.3.1.1 Numeric A numeric data element is represented by one or more digits with an optional leading sign representing a value in the normal base of 10. The value of a numeric data element includes an implied decimal point. It is used when the position of the decimal point within the data is permanently fixed and is not to be transmitted with the data. This set of guides denotes the number of implied decimal positions. The representation for this data element type is Nn where N indicates that it is numeric and n indicates the number of decimal positions to the right of the implied decimal point. If n is 0, it need not appear in the specification; N is equivalent to N0. For negative values, the leading minus sign (-) is used. Absence of a sign indicates a positive value. The plus sign (+) should not be transmitted. EXAMPLE A transmitted value of 1234, when specified as numeric type N2, represents a value of 12.34. Leading zeros should be suppressed unless necessary to satisfy a minimum length requirement. The length of a numeric type data element does not include the optional sign. A.1.1.3.1.2 Decimal A decimal data element may contain an explicit decimal point and is used for numeric values that have a varying number of decimal positions. This data element type is represented as R. The decimal point always appears in the character stream if the decimal point is at any place other than the right end. If the value is an integer (decimal point at the right end) the decimal point should be omitted. For negative values, the leading minus sign (-) is used. Absence of a sign indicates a positive value. The plus sign (+) should not be transmitted. Leading zeros should be suppressed unless necessary to satisfy a minimum length requirement. Trailing zeros following the decimal point should be suppressed unless necessary to indicate precision. The use of triad separators (for example, the commas in 1,000,000) is expressly prohibited. The length of a decimal type data element does not include the optional leading sign or decimal point. EXAMPLE A transmitted value of 12.34 represents a decimal value of 12.34. For implementation of this guide under the rules promulgated under the Health Insurance Portability and Accountability Act (HIPAA), decimal data elements in Data Element 782 (Monetary Amount) will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). Note the statement in the preceding paragraph that the decimal point and leading sign, if sent, are not part of the character count. A.1.1.3.1.3 Identifier An identifier data element always contains a value from a predefined list of codes that is maintained by the ASC X12 Committee or some other body recognized by

A.6

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

the Committee. Trailing spaces should be suppressed unless they are necessary to satisfy a minimum length. An identifier is always left justified. The representation for this data element type is ID. A.1.1.3.1.4 String A string data element is a sequence of any characters from the basic or extended character sets. The string data element must contain at least one non-space character. The significant characters shall be left justified. Leading spaces, when they occur, are presumed to be significant characters. Trailing spaces should be suppressed unless they are necessary to satisfy a minimum length. The representation for this data element type is AN. A.1.1.3.1.5 Date A date data element is used to express the standard date in either YYMMDD or CCYYMMDD format in which CC is the first two digits of the calendar year, YY is the last two digits of the calendar year, MM is the month (01 to 12), and DD is the day in the month (01 to 31). The representation for this data element type is DT. Users of this guide should note that all dates within transactions are 8-character dates (millennium compliant) in the format CCYYMMDD. The only date data element that is in format YYMMDD is the Interchange Date data element in the ISA segment, and also used in the TA1 Interchange Acknowledgment, where the century can be readily interpolated because of the nature of an interchange header. A.1.1.3.1.6 Time A time data element is used to express the ISO standard time HHMMSSd..d format in which HH is the hour for a 24 hour clock (00 to 23), MM is the minute (00 to 59), SS is the second (00 to 59) and d..d is decimal seconds. The representation for this data element type is TM. The length of the data element determines the format of the transmitted time. EXAMPLE Transmitted data elements of four characters denote HHMM. Transmitted data elements of six characters denote HHMMSS.

A.1.1.3.2

Repeating Data Elements


Simple or composite data elements within a segment can be designated as repeating data elements. Repeating data elements are adjacent data elements that occur up to a number of times specified in the standard as number of repeats. The implementation guide may also specify the number of repeats of a repeating data element in a specific location in the transaction that are permitted in a compliant implementation. Adjacent occurrences of the same repeating simple data element or composite data structure in a segment shall be separated by a repetition separator.

A.1.1.3.3

Composite Data Structure


The composite data structure is an intermediate unit of information in a segment. Composite data structures are composed of one or more logically related simple data elements, each, except the last, followed by a sub-element separator. The final data element is followed by the next data element separator or the segment terminator. Each simple data element within a composite is called a component. Each composite data structure has a unique four-character identifier, a name, and a purpose. The identifier serves as a label for the composite. A composite

MAY 2004

A.7

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

data structure can be further defined through the use of syntax notes, semantic notes, and comments. Each component within the composite is further characterized by a reference designator and a condition designator. The reference designators and the condition designators are described below. A composite data structure within a segment may have an attribute indicating that it may occur once or a specific number of times more than once. The number of permitted repeats are defined as an attribute in the individual segment where the repeated composite data structure occurs.

A.1.1.3.4

Data Segment
The data segment is an intermediate unit of information in a transaction set. In the data stream, a data segment consists of a segment identifier, one or more composite data structures or simple data elements each preceded by a data element separator and succeeded by a segment terminator. Each data segment has a unique two- or three-character identifier, a name, and a purpose. The identifier serves as a label for the data segment. A segment can be further defined through the use of syntax notes, semantic notes, and comments. Each simple data element or composite data structure within the segment is further characterized by a reference designator and a condition designator.

A.1.1.3.5

Syntax Notes
Syntax notes describe relational conditions among two or more data segment units within the same segment, or among two or more component data elements within the same composite data structure. For a complete description of the relational conditions, See A.1.1.3.9, Condition Designator.

A.1.1.3.6

Semantic Notes
Simple data elements or composite data structures may be referenced by a semantic note within a particular segment. A semantic note provides important additional information regarding the intended meaning of a designated data element, particularly a generic type, in the context of its use within a specific data segment. Semantic notes may also define a relational condition among data elements in a segment based on the presence of a specific value (or one of a set of values) in one of the data elements.

A.1.1.3.7

Comments
A segment comment provides additional information regarding the intended use of the segment.

A.1.1.3.8

Reference Designator
Each simple data element or composite data structure in a segment is provided a structured code that indicates the segment in which it is used and the sequential position within the segment. The code is composed of the segment identifier followed by a two-digit number that defines the position of the simple data element or composite data structure in that segment. For purposes of creating reference designators, the composite data structure is viewed as the hierarchical equal of the simple data element. Each component data element in a composite data structure is identified by a suffix appended to the reference designator for the composite data structure of which it is a member.

A.8

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

This suffix is a two-digit number, prefixed with a hyphen, that defines the position of the component data element in the composite data structure. EXAMPLE The first simple element of the CLP segment would be identified as CLP01. The first position in the SVC segment is occupied by a composite data structure that contains seven component data elements, the reference designator for the second component data element would be SVC01-02.

A.1.1.3.9

Condition Designator
This section provides information about X12 standard conditions designators. It is provided so that users will have information about the general standard. Implementation guides may impose other conditions designators. See implementation guide section 3.1 Presentation Examples for detailed information about the implementation guide Industry Usage requirements for compliant implementation. Data element conditions are of three types: mandatory, optional, and relational. They define the circumstances under which a data element may be required to be present or not present in a particular segment.
DESIGNATOR M- Mandatory DESCRIPTION The designation of mandatory is absolute in the sense that there is no dependency on other data elements. This designation may apply to either simple data elements or composite data structures. If the designation applies to a composite data structure, then at least one value of a component data element in that composite data structure shall be included in the data segment. The designation of optional means that there is no requirement for a simple data element or composite data structure to be present in the segment. The presence of a value for a simple data element or the presence of value for any of the component data elements of a composite data structure is at the option of the sender. Relational conditions may exist among two or more simple data elements within the same data segment based on the presence or absence of one of those data elements (presence means a data element must not be empty). Relational conditions are specified by a condition code (see table below) and the reference designators of the affected data elements. A data element may be subject to more than one relational condition. The definitions for each of the condition codes used within syntax notes are detailed below: CONDITION CODE P- Paired or Multiple DEFINITION If any element specified in the relational condition is present, then all of the elements specified must be present. At least one of the elements specified in the condition must be present. Not more than one of the elements specified in the condition may be present. If the first element specified in the condition is present, then all other elements must be present. However, any or all of the elements not specified as the first element in the condition may appear without requiring that the first element be present. The order of the elements in the condition does not have to be the same as the order of the data elements in the data segment.

O- Optional

X- Relational

R- Required E- Exclusion C- Conditional

MAY 2004

A.9

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER L- List Conditional

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

If the first element specified in the condition is present, then at least one of the remaining elements must be present. However, any or all of the elements not specified as the first element in the condition may appear without requiring that the first element be present. The order of the elements in the condition does not have to be the same as the order of the data elements in the data segment.

Table A.5. Condition Designator

A.1.1.3.10

Absence of Data
Any simple data element that is indicated as mandatory must not be empty if the segment is used. At least one component data element of a composite data structure that is indicated as mandatory must not be empty if the segment is used. Optional simple data elements and/or composite data structures and their preceding data element separators that are not needed should be omitted if they occur at the end of a segment. If they do not occur at the end of the segment, the simple data element values and/or composite data structure values may be omitted. Their absence is indicated by the occurrence of their preceding data element separators, in order to maintain the elements or structures position as defined in the data segment. Likewise, when additional information is not necessary within a composite, the composite may be terminated by providing the appropriate data element separator or segment terminator.

A.1.1.3.11

Control Segments
A control segment has the same structure as a data segment, but it is used for transferring control information rather than application information.

A.1.1.3.11.1

Loop Control Segments Loop control segments are used only to delineate bounded loops. Delineation of the loop shall consist of the loop header (LS segment) and the loop trailer (LE segment). The loop header defines the start of a structure that must contain one or more iterations of a loop of data segments and provides the loop identifier for this loop. The loop trailer defines the end of the structure. The LS segment appears only before the first occurrence of the loop, and the LE segment appears only after the last occurrence of the loop. Unbounded looping structures do not use loop control segments.

A.1.1.3.11.2

Transaction Set Control Segments The transaction set is delineated by the transaction set header (ST segment) and the transaction set trailer (SE segment). The transaction set header identifies the start and identifier of the transaction set. The transaction set trailer identifies the end of the transaction set and provides a count of the data segments, which includes the ST and SE segments.

A.1.1.3.11.3

Functional Group Control Segments The functional group is delineated by the functional group header (GS segment) and the functional group trailer (GE segment). The functional group header starts and identifies one or more related transaction sets and provides a control number and application identification information. The functional group trailer defines the

A.10

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

end of the functional group of related transaction sets and provides a count of contained transaction sets. A.1.1.3.11.4 Relations among Control Segments The control segment of this standard must have a nested relationship as is shown and annotated in this subsection. The letters preceding the control segment name are the segment identifier for that control segment. The indentation of segment identifiers shown below indicates the subordination among control segments. GS Functional Group Header, starts a group of related transaction sets. ST Transaction Set Header, starts a transaction set. LS Loop Header, starts a bounded loop of data segments but is not part of the loop. LS Loop Header, starts an inner, nested, bounded loop. LE Loop Trailer, ends an inner, nested bounded loop. LE Loop Trailer, ends a bounded loop of data segments but is not part of the loop. SE Transaction Set Trailer, ends a transaction set. GE Functional Group Trailer, ends a group of related transaction sets. More than one ST/SE pair, each representing a transaction set, may be used within one functional group. Also more than one LS/LE pair, each representing a bounded loop, may be used within one transaction set.

A.1.1.3.12

Transaction Set
The transaction set is the smallest meaningful set of information exchanged between trading partners. The transaction set consists of a transaction set header segment, one or more data segments in a specified order, and a transaction set trailer segment. See Figure A.1., Transmission Control Schematic.

A.1.1.3.12.1

Transaction Set Header and Trailer A transaction set identifier uniquely identifies a transaction set. This identifier is the first data element of the Transaction Set Header Segment (ST). A user assigned transaction set control number in the header must match the control number in the Trailer Segment (SE) for any given transaction set. The value for the number of included segments in the SE segment is the total number of segments in the transaction set, including the ST and SE segments.

A.1.1.3.12.2

Data Segment Groups The data segments in a transaction set may be repeated as individual data segments or as unbounded or bounded loops.

A.1.1.3.12.3

Repeated Occurrences of Single Data Segments When a single data segment is allowed to be repeated, it may have a specified maximum number of occurrences defined at each specified position within a given transaction set standard. Alternatively, a segment may be allowed to repeat an unlimited number of times. The notation for an unlimited number of repetitions is >1.

MAY 2004

A.11

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

A.1.1.3.12.4

Loops of Data Segments Loops are groups of semantically related segments. Data segment loops may be unbounded or bounded.

A.1.1.3.12.4.1

Unbounded Loops To establish the iteration of a loop, the first data segment in the loop must appear once and only once in each iteration. Loops may have a specified maximum number of repetitions. Alternatively, the loop may be specified as having an unlimited number of iterations. The notation for an unlimited number of repetitions is >1. A specified sequence of segments is in the loop. Loops themselves are optional or mandatory. The requirement designator of the beginning segment of a loop indicates whether at least one occurrence of the loop is required. Each appearance of the beginning segment defines an occurrence of the loop. The requirement designator of any segment within the loop after the beginning segment applies to that segment for each occurrence of the loop. If there is a mandatory requirement designator for any data segment within the loop after the beginning segment, that data segment is mandatory for each occurrence of the loop. If the loop is optional, the mandatory segment only occurs if the loop occurs.

A.1.1.3.12.4.2

Bounded Loops The characteristics of unbounded loops described previously also apply to bounded loops. In addition, bounded loops require a Loop Start Segment (LS) to appear before the first occurrence and a Loop End Segment (LE) to appear after the last occurrence of the loop. If the loop does not occur, the LS and LE segments are suppressed.

A.1.1.3.12.5

Data Segments in a Transaction Set When data segments are combined to form a transaction set, three characteristics are applied to each data segment: a requirement designator, a position in the transaction set, and a maximum occurrence.

A.1.1.3.12.6

Data Segment Requirement Designators A data segment, or loop, has one of the following requirement designators for health care and insurance transaction sets, indicating its appearance in the data stream of a transmission. These requirement designators are represented by a single character code.
DESIGNATOR M- Mandatory DESCRIPTION This data segment must be included in the transaction set. (Note that a data segment may be mandatory in a loop of data segments, but the loop itself is optional if the beginning segment of the loop is designated as optional.) The presence of this data segment is the option of the sending party.

O- Optional

A.1.1.3.12.7

Data Segment Position The ordinal positions of the segments in a transaction set are explicitly specified for that transaction. Subject to the flexibility provided by the optional requirement designators of the segments, this positioning must be maintained.

A.1.1.3.12.8

Data Segment Occurrence A data segment may have a maximum occurrence of one, a finite number greater than one, or an unlimited number indicated by >1.

A.12

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

A.1.1.3.13

Functional Group
A functional group is a group of similar transaction sets that is bounded by a functional group header segment and a functional group trailer segment. The functional identifier defines the group of transactions that may be included within the functional group. The value for the functional group control number in the header and trailer control segments must be identical for any given group. The value for the number of included transaction sets is the total number of transaction sets in the group. See Figure A.1., Transmission Control Schematic.

A.1.1.4
A.1.1.4.1

Envelopes and Control Structures


Interchange Control Structures
Typically, the term interchange connotes the ISA/IEA envelope that is transmitted between trading/business partners. Interchange control is achieved through several control components. The interchange control number is contained in data element ISA13 of the ISA segment. The identical control number must also occur in data element 02 of the IEA segment. Most commercial translation software products will verify that these two fields are identical. In most translation software products, if these fields are different the interchange will be suspended in error. There are many other features of the ISA segment that are used for control measures. For instance, the ISA segment contains data elements such as authorization information, security information, sender identification, and receiver identification that can be used for control purposes. These data elements are agreed upon by the trading partners prior to transmission and are contained in the written trading partner agreement. The interchange date and time data elements as well as the interchange control number within the ISA segment are used for debugging purposes when there is a problem with the transmission or the interchange. Data Element ISA12, Interchange Control Version Number, indicates the version of the ISA/IEA envelope. The ISA12 does not indicate the version of the transaction set that is being transmitted but rather the envelope that encapsulates the transaction. An Interchange Acknowledgment can be denoted through data element ISA14. The acknowledgment that would be sent in reply to a yes condition in data element ISA14 would be the TA1 segment. Data element ISA15, Test Indicator, is used between trading partners to indicate that the transmission is in a test or production mode. This becomes significant when the production phase of the project is to commence. Data element ISA16, Subelement Separator, is used by the translator for interpretation of composite data elements. The ending component of the interchange or ISA/IEA envelope is the IEA segment. Data element IEA01 indicates the number of functional groups that are included within the interchange. In most commercial translation software products, an aggregate count of functional groups is kept while interpreting the interchange. This count is then verified with data element IEA01. If there is a discrepancy, in most commercial products, the interchange is suspended. The other data element in the IEA segment is IEA02 which is referenced above. See the Appendix B, EDI Control Directory, for a complete detailing of the interchange control header and trailer. The authors recommend that when two transactions with different X12 versions numbers are sent in one interchange control structure (multiple functional groups within one ISA/IEA envelope), the Interchange Control version used should be that of the most recent transaction ver-

MAY 2004

A.13

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

sion included in the envelope. For the transmission of HIPAA transactions with mixed versions, this would be a compliant enveloping structure.

A.1.1.4.2

Functional Groups
Control structures within the functional group envelope include the functional identifier code in GS01. The Functional Identifier Code is used by the commercial translation software during interpretation of the interchange to determine the different transaction sets that may be included within the functional group. If an inappropriate transaction set is contained within the functional group, most commercial translation software will suspend the functional group within the interchange. The Application Senders Code in GS02 can be used to identify the sending unit of the transmission. The Application Receivers Code in GS03 can be used to identify the receiving unit of the transmission. For health care, this unit identification can be used to differentiate between managed care, indemnity, and Medicare. The functional group contains a creation date (GS04) and creation time (GS05) for the functional group. The Group Control Number is contained in GS06. These data elements (GS04, GS05, AND GS06) can be used for debugging purposes during problem resolution. GS08,Version/Release/Industry Identifier Code is the version/release/sub-release of the transaction sets being transmitted in this functional group. Appendix B provides guidance for the value for this data element. The GS08 does not represent the version of the interchange (ISA/IEA) envelope but rather the version/release/sub-release of the transaction sets that are encompassed within the GS/GE envelope. The Functional Group Control Number in GS06 must be identical to data element 02 of the GE segment. Data element GE01 indicates the number of transaction sets within the functional group. In most commercial translation software products, an aggregate count of the transaction sets is kept while interpreting the functional group. This count is then verified with data element GE01. See the Appendix B, EDI Control Directory, for a complete detailing of the functional group header and trailer.

A.1.1.4.3

HL Structures
The HL segment is used in several X12 transaction sets to identify levels of detail information using a hierarchical structure, such as relating dependents to a subscriber. Hierarchical levels may differ from guide to guide. The following diagram, from transaction set 837, illustrates a typical hierarchy.

Dependents

Subscribers

Provider

Each provider can bill for one or more subscribers, each subscriber can have one or more dependents and the subscriber and the dependents can make one or more claims. Each guide states what levels are available, the levels requirement, a repeat value, and whether that level has subordinate levels within a transmission. For implementations compliant with this guide, the repeats of the loops identified by the HL structure shall appear in the hierarchical order specified in BHT01, when those particular hierarchical levels exist. That is, an HL parent loop shall be

A.14

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

followed by the subordinate child loops, if any, prior to commencing a new HL parent loop at the same hierarchical level.

A.1.1.5
A.1.1.5.1

Acknowledgments
Interchange Acknowledgment, TA1
The Interchange or TA1 Acknowledgment is a means of replying to an interchange or transmission that has been sent. The TA1 verifies the envelopes only. Transaction set-specific verification is accomplished through use of the Functional Acknowledgment Transaction Set, 997. See A.1.1.5.2, Functional Acknowledgment, 997, for more details. The TA1 is a single segment and is unique in the sense that this single segment is transmitted without the GS/GE envelope structures. A TA1 can be included in an interchange with other functional groups and transactions. Encompassed in the TA1 are the interchange control number, interchange date and time, interchange acknowledgment code, and the interchange note code. The interchange control number, interchange date and time are identical to those that were present in the transmitted interchange from the sending trading partner. This provides the capability to associate the TA1 with the transmitted interchange. TA104, Interchange Acknowledgment Code, indicates the status of the interchange control structure. This data element stipulates whether the transmitted interchange was accepted with no errors, accepted with errors, or rejected because of errors. TA105, Interchange Note Code, is a numerical code that indicates the error found while processing the interchange control structure. Values for this data element indicate whether the error occurred at the interchange or functional group envelope. The TA1 segment provides the capability for the receiving trading partner to notify the sending trading partner of problems that were encountered in the interchange control structure. Due to the uniqueness of the TA1, implementation should be predicated upon the ability for the sending and receiving trading partners commercial translators to accommodate the uniqueness of the TA1. Unless named as mandatory in the Federal Rules implementing HIPAA, use of the TA1, although urged by the authors, is not mandated. See the Appendix B, EDI Control Directory, for a complete detailing of the TA1 segment.

A.1.1.5.2

Functional Acknowledgment, 997


The Functional Acknowledgment Transaction Set, 997, has been designed to allow trading partners to establish a comprehensive control function as a part of their business exchange process. This acknowledgment process facilitates control of EDI. There is a one-to-one correspondence between a 997 and a functional group. Segments within the 997 can identify the acceptance or rejection of the functional group, transaction sets or segments. Data elements in error can also be identified. There are many EDI implementations that have incorporated the acknowledgment process in all of their electronic communications. Typically, the 997 is used as a functional acknowledgment to a previously transmitted functional group. Many commercially available translators can automatically generate this transaction set through internal parameter settings. Additionally translators will automatically reconcile received acknowledgments to functional groups that

MAY 2004

A.15

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

have been sent. The benefit to this process is that the sending trading partner can determine if the receiving trading partner has received ASC X12 transaction sets through reports that can be generated by the translation software to identify transmissions that have not been acknowledged. As stated previously the 997 is a transaction set and thus is encapsulated within the interchange control structure (envelopes) for transmission. As with any information flow, an acknowledgment process is essential. If an automatic acknowledgment process is desired between trading partners then it is recommended that the 997 be used. Unless named as mandatory in the Federal Rules implementing HIPAA, use of the 997, although recommended by the authors, is not mandated. See Appendix B, EDI Control Directory, for a complete detailing of transaction set 997.

A.2

Other Syntaxes
This Implementation Guide may contain support for additional transmission syntaxes. Additional syntaxes include but are not limited to, eXtensible Markup Language (XML). Such support is included at the discretion of the authors. Inclusion of additional transmission syntaxes does not mandate use of these syntaxes. For example, these syntaxes do not satisfy the HIPAA requirements for standardization unless a future HIPAA rule mandates or allows the additional transmission syntax. Other willing trading partners may agree to exchange these additional syntaxes at their discretion but are under no obligation to do so. If supported, Object Descriptors (ODs) will be included for each loop, segment, and data element defined in this Implementation Guide. Object Descriptors are derived, in part, from the ASC X12N Data Element Dictionaries. See Section 3.1 for information on how to identify any ODs included in this Implementation Guide. The purpose of the ODs is to allow trading partners to communicate in a flexible manner via different transmission syntax while retaining all information. The design includes a naming convention that enables transmitting, validating, and interpreting the data between applications and organizations while being flexible in transport, such as using the Internet. The examples below include X12 syntax and XML, for the identical data content. This is an example of an XML document representing Loop 2000A - Information Source Level and 2100A - Information Source. XML tag names must begin with a letter. Since the Object Descriptors begin with a number, the authors of this Implementation Guide suggest adding an X when constructing XML documents. In the XML example below, carriage returns and indents are added for readability.

A.16

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

XML <HealthCareClaimAcknowledgement> <X277B1_2000A> <X277B1_2000A_HL_InformationSourceHierarchicalLevel X277B1_2000A_HL01_HierachicalIDNumber="1" X277B1_2000A_HL03_HierachicalLevelCode="20" X277B1_2000A_HL04_HierachicalChildCode="1"/> <X277B1_2100A> <X277B1_2100A_NM1_InformationSourceName X277B1_2100A_NM101_EntityIdentifierCode="PR" X277B1_2100A_NM102_EntityTypeQualifier="2" X277B1_2100A_NM103_InformationSourceName="XML Payer Company" X277B1_2100A_NM108_IdentificationCodeQualifier="46" X277B1_2100A_NM109_InformationSourceIdentifier="12345"/> </X277B1_2100A> </X277B1_2000A> </HealthCareClaimAcknowledgement> X12

HL*1**20*1~ NM1*PR*2*XML PAYER COMPANY*****46*12345~

MAY 2004

A.17

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

A.18

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

B EDI Control Directory


B.1 Control Segments
ISA Interchange Control Header Segment IEA Interchange Control Trailer Segment GS Functional Group Header Segment GE Functional Group Trailer Segment TA1 Interchange Acknowledgment Segment

B.2

Functional Acknowledgment Transaction Set, 997

MAY 2004

B.1

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

B.2

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


INTERCHANGE CONTROL HEADER

CONTROL SEGMENTS

ISA

004050X151 002 ISA INTERCHANGE CONTROL HEADER

JANUARY 31, 2003 IMPLEMENTATION

INTERCHANGE CONTROL HEADER


0 000 100
Notes: 1. For compliant implementations under this implementation guide, ISA13, the interchange Control Number, must be a positive (therefore unsigned) number. Therefore, the ISA segment can be considered a fixed record length segment. All positions within each of the data elements must be filled. The first element separator defines the element separator to be used through the entire interchange. The segment terminator used after the ISA defines the segment terminator to be used throughout the entire interchange. Spaces in the example are represented by . for clarity.

1 000 100
STANDARD

Example: ISA 00 .......... 01 SECRET.... ZZ SUBMITTERS.ID.. ZZ RECEIVERS.ID... 930602 1253 ^ 00405 000000905 1 T :~

ISA Interchange Control Header


Purpose: To start and identify an interchange of zero or more functional groups and interchange-related control segments
DIAGRAM

ISA01

I01

ISA02

I02

ISA03

I03

ISA04

I04

ISA05

I05

ISA06

I06

ISA

Author Info Qualifier


M1 ID 2/2

Author Information
M1 AN 10/10

Security Info Qual


M1 ID 2/2

Security Information
M1 AN 10/10

Interchange ID Qual
M1 ID 2/2

Interchange Sender ID
M1 AN 15/15

ISA07

I05

ISA08

I07

ISA09

I08

ISA10

I09

ISA11

I65

ISA12

I11

Interchange Interchange Interchange Interchange


ID Qual
ID

Receiver ID

Date
DT

Time
TM

Repetition Separator
M1 ID 1/1

Inter Ctrl Version Num


M1 ID 5/5

M1

2/2

M1

AN 15/15

M1

6/6

M1

4/4

ISA13

I12

ISA14

I13

ISA15

I14

ISA16

I15

Inter Ctrl Number


M1 N0 9/9

Ack Requested
M1 ID 1/1

Usage Indicator
M1 ID 1/1

Component ~ Elem Sepera


M1 1/1

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

ISA01

I01

Authorization Information Qualifier


CODE DEFINITION

M1

ID

2/2

Code identifying the type of information in the Authorization Information

00

No Authorization Information Present (No Meaningful Information in I02) ADVISED UNLESS SECURITY REQUIREMENTS MANDATE USE OF ADDITIONAL IDENTIFICATION INFORMATION.

113

03

Additional Data Identification

MAY 2004

B.3

CONTROL SEGMENTS

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REQUIRED

ISA02

I02

Authorization Information

M 1 AN

10/10

Information used for additional identification or authorization of the interchange sender or the data in the interchange; the type of information is set by the Authorization Information Qualifier (I01)

REQUIRED

ISA03

I03

Security Information Qualifier


CODE DEFINITION

M1

ID

2/2

Code identifying the type of information in the Security Information

00

No Security Information Present (No Meaningful Information in I04) ADVISED UNLESS SECURITY REQUIREMENTS MANDATE USE OF PASSWORD DATA.

116
01 REQUIRED ISA04 I04

Password M 1 AN 10/10

Security Information

This is used for identifying the security information about the interchange sender or the data in the interchange; the type of information is set by the Security Information Qualifier (I03)

REQUIRED

ISA05

I05

Interchange ID Qualifier

M1

ID

2/2

Code indicating the system/method of code structure used to designate the sender or receiver ID element being qualified

1000002

This ID qualifies the Sender in ISA06.


CODE DEFINITION

01 14 20 27

Duns (Dun & Bradstreet) Duns Plus Suffix Health Industry Number (HIN)
CODE SOURCE 121:

Health Industry Number

Carrier Identification Number as assigned by Health Care Financing Administration (HCFA) Fiscal Intermediary Identification Number as assigned by Health Care Financing Administration (HCFA) Medicare Provider and Supplier Identification Number as assigned by Health Care Financing Administration (HCFA) U.S. Federal Tax Identification Number National Association of Insurance Commissioners Company Code (NAIC) Mutually Defined M 1 AN 15/15

28

29

30 33

ZZ REQUIRED ISA06 I06

Interchange Sender ID

Identification code published by the sender for other parties to use as the receiver ID to route data to them; the sender always codes this value in the sender ID element

B.4

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

CONTROL SEGMENTS

REQUIRED

ISA07

I05

Interchange ID Qualifier

M1

ID

2/2

Code indicating the system/method of code structure used to designate the sender or receiver ID element being qualified

1000003

This ID qualifies the Receiver in ISA08.


CODE DEFINITION

01 14 20 27

Duns (Dun & Bradstreet) Duns Plus Suffix Health Industry Number (HIN)
CODE SOURCE 121:

Health Industry Number

Carrier Identification Number as assigned by Health Care Financing Administration (HCFA) Fiscal Intermediary Identification Number as assigned by Health Care Financing Administration (HCFA) Medicare Provider and Supplier Identification Number as assigned by Health Care Financing Administration (HCFA) U.S. Federal Tax Identification Number National Association of Insurance Commissioners Company Code (NAIC) Mutually Defined M 1 AN 15/15

28

29

30 33

ZZ REQUIRED ISA08 I07

Interchange Receiver ID

Identification code published by the receiver of the data; When sending, it is used by the sender as their sending ID, thus other parties sending to them will use this as a receiving ID to route data to them

REQUIRED

ISA09

I08

Interchange Date
Date of the interchange

M 1 DT

6/6

1000006
REQUIRED ISA10 I09

The date format is YYMMDD. Interchange Time


Time of the interchange

M 1 TM

4/4

1000007
REQUIRED ISA11 I65

The time format is HHMM. Repetition Separator M1 ID 1/1


Type is not applicable; the repetition separator is a delimiter and not a data element; this field provides the delimiter used to separate repeated occurrences of a simple data element or a composite data structure; this value must be different than the data element separator, component element separator, and the segment terminator

REQUIRED

ISA12

I11

Interchange Control Version Number


CODE DEFINITION

M1

ID

5/5

Code specifying the version number of the interchange control segments

00405

Standards Approved for Publication by ASC X12 Procedures Review Board through October 2001

MAY 2004

B.5

CONTROL SEGMENTS

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REQUIRED

ISA13

I12

Interchange Control Number


A control number assigned by the interchange sender

M1

N0

9/9

1000004
REQUIRED ISA14 I13

The Interchange Control Number, ISA13, must be identical to the associated Interchange Trailer IEA02. Acknowledgment Requested M1 ID 1/1
Code indicating senders request for an interchange acknowledgment

1000038

See Section A.1.1.5.1 for interchange acknowledgment information.


CODE DEFINITION

0 1 REQUIRED ISA15 I14

No Interchange Acknowledgment Requested Interchange Acknowledgment Requested (TA1) M1 ID 1/1

Interchange Usage Indicator

Code indicating whether data enclosed by this interchange envelope is test, production or information
CODE DEFINITION

P T REQUIRED ISA16 I15

Production Data Test Data M1 1/1

Component Element Separator

Type is not applicable; the component element separator is a delimiter and not a data element; this field provides the delimiter used to separate component data elements within a composite data structure; this value must be different than the data element separator and the segment terminator

B.6

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


INTERCHANGE CONTROL TRAILER

CONTROL SEGMENTS

IEA

004050X151 002 IEA INTERCHANGE CONTROL TRAILER

IMPLEMENTATION

INTERCHANGE CONTROL TRAILER


5 000 100
STANDARD

Example: IEA1000000905~

IEA Interchange Control Trailer


Purpose: To define the end of an interchange of zero or more functional groups and interchange-related control segments
DIAGRAM

IEA01

I16

IEA02

I12

IEA

Num of Incl Funct Group


M1 N0 1/5

Inter Ctrl Number


M1 N0 9/9

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED REQUIRED

IEA01 IEA02

I16 I12

Number of Included Functional Groups Interchange Control Number


A control number assigned by the interchange sender

M1 M1

N0 N0

1/5 9/9

A count of the number of functional groups included in an interchange

MAY 2004

B.7

CONTROL SEGMENTS
FUNCTIONAL GROUP HEADER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

GS

FUNCTIONAL 002 GS 004050X151 GROUP HEADER

IMPLEMENTATION

FUNCTIONAL GROUP HEADER


4 005 100
STANDARD

Example: GSPISENDER CODERECEIVER CODE1994033108021X004050X151~

GS Functional Group Header


Purpose: To indicate the beginning of a functional group and to provide control information
DIAGRAM

GS01

479

GS02

142

GS03

124

GS04

373

GS05

337

GS06

28

GS

Functional ID Code
M1 ID 2/2

Application Sends Code


M1 AN 2/15

Application Recs Code


M1 AN 2/15

M1

Date
DT 8/8

M1

Time
TM 4/8

Group Ctrl Number


M1 N0 1/9

GS07

455

GS08

480

Responsible Agency Code


M1 ID 1/2

Ver/Release ID Code
M1 AN 1/12

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

GS01

479

Functional Identifier Code


CODE DEFINITION

M1

ID

2/2

Code identifying a group of application related transaction sets

PI REQUIRED GS02 142

Patient Information (275) M 1 AN 2/15

Application Senders Code

Code identifying party sending transmission; codes agreed to by trading partners

1000009
REQUIRED GS03 124

Use this code to identify the unit sending the information. Application Receivers Code M 1 AN 2/15
Code identifying party receiving transmission; codes agreed to by trading partners

1000010
REQUIRED GS04 373

Use this code to identify the unit receiving the information. Date M 1 DT 8/8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEMANTIC:

GS04 is the group date.

1000011
REQUIRED GS05 337

Use this date for the functional group creation date. Time M 1 TM 4/8
Time expressed in 24-hour clock time as follows: HHMM, or HHMMSS, or HHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-59), S = integer seconds (00-59) and DD = decimal seconds; decimal seconds are expressed as follows: D = tenths (0-9) and DD = hundredths (00-99)
SEMANTIC:

GS05 is the group time.

1000012

Use this time for the creation time. The recommended format is HHMM.

B.8

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

CONTROL SEGMENTS

REQUIRED

GS06

28

Group Control Number


Assigned number originated and maintained by the sender
SEMANTIC:

M1

N0

1/9

The data interchange control number GS06 in this header must be identical to the same data element in the associated functional group trailer, GE02.

1000131

For implementations compliant with this guide, GS06 must be unique within a single transmission (that is, within a single ISA to IEA enveloping structure). The authors recommend that GS06 be unique within all transmissions over a period of time to be determined by the sender. GS07 455 Responsible Agency Code M1 ID 1/2
Code identifying the issuer of the standard; this code is used in conjunction with Data Element 480
CODE DEFINITION

REQUIRED

X REQUIRED GS08 480

Accredited Standards Committee X12 M 1 AN 1/12

Version / Release / Industry Identifier Code

Code indicating the version, release, subrelease, and industry identifier of the EDI standard being used, including the GS and GE segments; if code in DE455 in GS segment is X, then in DE 480 positions 1-3 are the version number; positions 4-6 are the release and subrelease, level of the version; and positions 7-12 are the industry or trade association identifiers (optionally assigned by user); if code in DE455 in GS segment is T, then other formats are allowed
CODE SOURCE 881: CODE

Version / Release / Industry Identifier Code


DEFINITION

004050X151

Standards Approved for Publication by ASC X12 Procedures Review Board through October 2001, as published in this implementation guide.

MAY 2004

B.9

CONTROL SEGMENTS
FUNCTIONAL GROUP TRAILER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

GE

FUNCTIONAL 002 GE 004050X151 GROUP TRAILER

IMPLEMENTATION

FUNCTIONAL GROUP TRAILER


3 001 100
STANDARD

Example: GE11~

GE Functional Group Trailer


Purpose: To indicate the end of a functional group and to provide control information
DIAGRAM

GE01

97

GE02

28

GE

Number of TS Included
M1 N0 1/6

Group Ctrl Number


M1 N0 1/9

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

GE01

97

Number of Transaction Sets Included

M1

N0

1/6

Total number of transaction sets included in the functional group or interchange (transmission) group terminated by the trailer containing this data element

REQUIRED

GE02

28

Group Control Number


Assigned number originated and maintained by the sender
SEMANTIC:

M1

N0

1/9

The data interchange control number GE02 in this trailer must be identical to the same data element in the associated functional group header, GS06.

B.10

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


INTERCHANGE ACKNOWLEDGMENT

CONTROL SEGMENTS

TA1

004050X151 002 TA1 INTERCHANGE ACKNOWLEDGMENT

IMPLEMENTATION

INTERCHANGE ACKNOWLEDGMENT
4 001 100 5 001 100
Notes: 1. All fields must contain data. 2. This segment acknowledges the reception of an X12 interchange header and trailer from a previous interchange. If the header/trailer pair was received correctly, the TA1 reflects a valid interchange, regardless of the validity of the contents of the data included inside the header/trailer envelope. 3. See A.1.1.5.1, Interchange Acknowledgment, TA1, for interchange acknowledgment. 4. Use of TA1 is subject to trading partner agreement and is neither mandated or prohibited in the Appendix. Example: TA10000009059401010100A000~

6 007 100 7 007 100 6 001 100


STANDARD

TA1 Interchange Acknowledgment


Purpose: To report the status of processing a received interchange header and trailer or the non-delivery by a network provider
DIAGRAM

TA101

I12

TA102

I08

TA103

I09

TA104

I17

TA105

I18

TA1

Inter Ctrl Number


M1 N0 9/9

Interchange Date
M1 DT 6/6

Interchange Time
M1 TM 4/4

Interchange Ack Code


M1 ID 1/1

Interchange Note Code


M1 ID 3/3

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

TA101

I12

Interchange Control Number


A control number assigned by the interchange sender

M1

N0

9/9

1000017

This number uniquely identifies the interchange data to the sender. It is assigned by the sender. Together with the sender ID it uniquely identifies the interchange data to the receiver. It is suggested that the sender, receiver, and all third parties be able to maintain an audit trail of interchanges using this number. In the TA1, this should be the interchange control number of the original interchange that this TA1 is acknowledging. TA102 I08 Interchange Date
Date of the interchange

1000018
REQUIRED

M 1 DT

6/6

1000019

This is the date of the original interchange being acknowledged. (YYMMDD)

MAY 2004

B.11

CONTROL SEGMENTS

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REQUIRED

TA103

I09

Interchange Time
Time of the interchange

M 1 TM

4/4

1000020
REQUIRED TA104 I17

This is the time of the original interchange being acknowledged. (HHMM) Interchange Acknowledgment Code
CODE DEFINITION

M1

ID

1/1

Code indicating the status of the receipt of the interchange control structure

The Transmitted Interchange Control Structure Header and Trailer Have Been Received and Have No Errors. The Transmitted Interchange Control Structure Header and Trailer Have Been Received and Are Accepted But Errors Are Noted. This Means the Sender Must Not Resend This Data. The Transmitted Interchange Control Structure Header and Trailer are Rejected Because of Errors. M1 ID 3/3

R REQUIRED

TA105

I18

Interchange Note Code


CODE DEFINITION

Code specifying the error found processing the interchange control structure

000 001

No error The Interchange Control Number in the Header and Trailer Do Not Match. The Value From the Header is Used in the Acknowledgment. This Standard as Noted in the Control Standards Identifier is Not Supported. This Version of the Controls is Not Supported The Segment Terminator is Invalid Invalid Interchange ID Qualifier for Sender Invalid Interchange Sender ID Invalid Interchange ID Qualifier for Receiver Invalid Interchange Receiver ID Unknown Interchange Receiver ID Invalid Authorization Information Qualifier Value Invalid Authorization Information Value Invalid Security Information Qualifier Value Invalid Security Information Value Invalid Interchange Date Value Invalid Interchange Time Value Invalid Interchange Standards Identifier Value

002

003 004 005 006 007 008 009 010 011 012 013 014 015 016

B.12

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

CONTROL SEGMENTS

017 018 019 020 021 022 023 024

Invalid Interchange Version ID Value Invalid Interchange Control Number Value Invalid Acknowledgment Requested Value Invalid Test Indicator Value Invalid Number of Included Groups Value Invalid Control Structure Improper (Premature) End-of-File (Transmission) Invalid Interchange Content (e.g., Invalid GS Segment) Duplicate Interchange Control Number Invalid Data Element Separator Invalid Component Element Separator Invalid Delivery Date in Deferred Delivery Request Invalid Delivery Time in Deferred Delivery Request Invalid Delivery Time Code in Deferred Delivery Request Invalid Grade of Service Code

025 026 027 028 029 030

031

MAY 2004

B.13

CONTROL SEGMENTS

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

B.14

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


004050X151 997

004050X151 997

JANUARY 31, 2003 STANDARD

997

Functional Acknowledgment
Functional Group ID: FA
This X12 Transaction Set contains the format and establishes the data contents of the Functional Acknowledgment Transaction Set (997) for use within the context of an Electronic Data Interchange (EDI) environment. The transaction set can be used to define the control structures for a set of acknowledgments to indicate the results of the syntactical analysis of the electronically encoded documents. The encoded documents are the transaction sets, which are grouped in functional groups, used in defining transactions for business data interchange. This standard does not cover the semantic meaning of the information encoded in the transaction sets.

Table 1 - Header
PAGE #
POS. # SEG. ID NAME REQ. DES. MAX USE LOOP REPEAT

0100 ST 0200 AK1 0300 AK2 0400 0500 0600 0700 0800 AK3 AK4 AK5 AK9 SE

Transaction Set Header Functional Group Response Header LOOP ID - AK2 Transaction Set Response Header LOOP ID - AK2/AK3 Data Segment Note Data Element Note Transaction Set Response Trailer Functional Group Response Trailer Transaction Set Trailer

M M O O O M M M

1 1 999999 1 999999 1 99 1 1 1

NOTES: These acknowledgments shall not be acknowledged, thereby preventing an endless cycle of acknowledgments of acknow1/0100 ledgments. Nor shall a Functional Acknowledgment be sent to report errors in a previous Functional Acknowledgment. 1/0100 The Functional Group Header Segment (GS) is used to start the envelope for the Functional Acknowledgment Transaction Sets. In preparing the functional group of acknowledgments, the application senders code and the application receivers code, taken from the functional group being acknowledged, are exchanged; therefore, one acknowledgment functional group responds to only those functional groups from one application receivers code to one application senders 1/0100 1/0200 1/0200 1/0300 code. There is only one Functional Acknowledgment Transaction Set per acknowledged functional group. AK1 is used to respond to the functional group header and to start the acknowledgment for a functional group. There shall be one AK1 segment for the functional group that is being acknowledged. The Functional Acknowledgement is generated at the point of translation, intended for the originator (not any intermediate parties). AK2 is used to start the acknowledgment of a transaction set within the received functional group. The AK2 segments shall appear in the same order as the transaction sets in the functional group that has been received and is being acknowledged. 1/0400 The data segments of this standard are used to report the results of the syntactical analysis of the functional groups of transaction sets; they report the extent to which the syntax complies with the standards or proper subsets of transaction sets and functional groups. They do not report on the semantic meaning of the transaction sets (for example, on the ability of the receiver to comply with the request of the sender).

MAY 2004

B.15

004050X151 997 ST TRANSACTION SET HEADER


TRANSACTION SET HEADER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

ST

TRANSACTION SET HEADER 004050X151 997 ST

IMPLEMENTATION

TRANSACTION SET HEADER


Usage: REQUIRED Repeat: 1

8 007 100

Notes:

1. Use of the 997 transaction is subject to trading partner agreement or accepted usage and is neither mandated nor prohibited in this Appendix.

500
STANDARD

Example: ST9971234004050X151~

ST Transaction Set Header


Level: Header Position: 0100 Loop: ____ Requirement: Mandatory Max Use: 1 Purpose: To indicate the start of a transaction set and to assign a control number Set Notes: 1. These acknowledgments shall not be acknowledged, thereby preventing an endless cycle of acknowledgments of acknowledgments. Nor shall a Functional Acknowledgment be sent to report errors in a previous Functional Acknowledgment. 2. The Functional Group Header Segment (GS) is used to start the envelope for the Functional Acknowledgment Transaction Sets. In preparing the functional group of acknowledgments, the application senders code and the application receivers code, taken from the functional group being acknowledged, are exchanged; therefore, one acknowledgment functional group responds to only those functional groups from one application receivers code to one application senders code. 3. There is only one Functional Acknowledgment Transaction Set per acknowledged functional group.
DIAGRAM

ST01

143

ST02

329

ST03

1705

ST
M1

TS ID Code
ID 3/3

TS Control Number
M1 AN 4/9

Imple Conv Reference


O1 AN 1/35

B.16

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE ELEMENT SUMMARY


REF. DES. DATA ELEMENT

004050X151 997 ST TRANSACTION SET HEADER

USAGE

NAME

ATTRIBUTES

REQUIRED

ST01

143

Transaction Set Identifier Code


Code uniquely identifying a Transaction Set
SEMANTIC:

M1

ID

3/3

The transaction set identifier (ST01) is used by the translation routines of the interchange partners to select the appropriate transaction set definition (e.g., 810 selects the Invoice Transaction Set).
CODE DEFINITION

997 REQUIRED ST02 329

Functional Acknowledgment M 1 AN 4/9

Transaction Set Control Number

Identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set

501

The Transaction Set Control Numbers in ST02 and SE02 must be identical. The number is assigned by the originator and must be unique within a functional group (GS-GE). The number also aids in error resolution research. For example, start with the number 0001 and increment from there. Use the corresponding value in ST02 for this transaction set. ST03 1705 Implementation Convention Reference
Reference assigned to identify Implementation Convention
SEMANTIC:

524
SITUATIONAL

O 1 AN

1/35

The implementation convention reference (ST03) is used by the translation routines of the interchange partners to select the appropriate implementation convention to match the transaction set definition. When used, this implementation convention reference takes precedence over the implementation reference specified in the GS08.

1000139

Used at the discretion of the sender of the transaction to indicate implementation convention used in creating the 997 transaction. When created in compliance with this implementation guide, the value in ST03 will be the same value as stated in this guide for GS08.

MAY 2004

B.17

004050X151 997 AK1 FUNCTIONAL GROUP RESPONSE HEADER


FUNCTIONAL GROUP RESPONSE HEADER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

AK1

004050X151 GROUP RESPONSE HEADER FUNCTIONAL 997 AK1

IMPLEMENTATION

FUNCTIONAL GROUP RESPONSE HEADER


Usage: REQUIRED Repeat: 1

502
STANDARD

Example: AK1CI1~

AK1 Functional Group Response Header


Level: Header Position: 0200 Loop: ____ Requirement: Mandatory Max Use: 1 Purpose: To start acknowledgment of a functional group Set Notes: 1. AK1 is used to respond to the functional group header and to start the acknowledgment for a functional group. There shall be one AK1 segment for the functional group that is being acknowledged. 2. The Functional Acknowledgement is generated at the point of translation, intended for the originator (not any intermediate parties).
DIAGRAM

AK101

479

AK102

28

AK103

480

AK1

Functional ID Code
M1 ID 2/2

Group Ctrl Number


M1 N0 1/9

Ver/Release ID Code
O1 AN 1/12

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

AK101

479

Functional Identifier Code


SEMANTIC:

M1

ID

2/2

Code identifying a group of application related transaction sets AK101 is the functional ID found in the GS segment (GS01) in the functional group being acknowledged.

1000140
REQUIRED

When acknowledging a transaction specified in this implementation guide, the code value in AK101 will be the same value as given for GS01 in this appendix. AK102 28 Group Control Number
Assigned number originated and maintained by the sender
SEMANTIC:

M1

N0

1/9

AK102 is the functional group control number found in the GS segment in the functional group being acknowledged.

B.18

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 997 AK1 FUNCTIONAL GROUP RESPONSE HEADER

SITUATIONAL

AK103

480

Version / Release / Industry Identifier Code

O 1 AN

1/12

Code indicating the version, release, subrelease, and industry identifier of the EDI standard being used, including the GS and GE segments; if code in DE455 in GS segment is X, then in DE 480 positions 1-3 are the version number; positions 4-6 are the release and subrelease, level of the version; and positions 7-12 are the industry or trade association identifiers (optionally assigned by user); if code in DE455 in GS segment is T, then other formats are allowed
SEMANTIC:

AK103 is the version release industry identifier code in the GS segment (GS08) in the functional group being acknowledged. Version / Release / Industry Identifier Code

CODE SOURCE 881:

MAY 2004

B.19

004050X151 997 AK2 AK2 TRANSACTION SET RESPONSE HEADER


TRANSACTION SET RESPONSE HEADER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

AK2

004050X151 997 AK2 AK2 HEADER TRANSACTION SET RESPONSE

IMPLEMENTATION

TRANSACTION SET RESPONSE HEADER


Loop: AK2 TRANSACTION SET RESPONSE HEADER Repeat: 999999 Usage: SITUATIONAL Repeat: 1

9 007 100 503


STANDARD

Notes:

1. Required when communicating information about a transaction set within a functional group identified in AK1.

Example: AK2811000000905~

AK2 Transaction Set Response Header


Level: Header Position: 0300 Loop: AK2 Repeat: 999999 Requirement: Optional Max Use: 1 Purpose: To start acknowledgment of a single transaction set Set Notes: 1. AK2 is used to start the acknowledgment of a transaction set within the received functional group. The AK2 segments shall appear in the same order as the transaction sets in the functional group that has been received and is being acknowledged.

DIAGRAM

AK201

143

AK202

329

AK203

1705

AK2

M1

TS ID Code
ID 3/3

TS Control Number
M1 AN 4/9

Imple Conv Reference


O1 AN 1/35

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

AK201

143

Transaction Set Identifier Code


Code uniquely identifying a Transaction Set
SEMANTIC:

M1

ID

3/3

AK201 is the transaction set ID found in the ST segment (ST01) in the transaction set being acknowledged.

1000141
REQUIRED

When acknowledging a transaction specified in this implementation guide, the code value in AK201 will be the same value as given for ST01 in this implementation guide. AK202 329 Transaction Set Control Number M 1 AN 4/9
Identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set
SEMANTIC:

AK202 is the transaction set control number found in the ST segment in the transaction set being acknowledged.

B.20

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 997 AK2 AK2 TRANSACTION SET RESPONSE HEADER

SITUATIONAL

AK203

1705

Implementation Convention Reference


Reference assigned to identify Implementation Convention
SEMANTIC:

O 1 AN

1/35

AK203 is the implementation convention reference, if any, found in the ST segment (ST03) in the transaction set being acknowledged.

MAY 2004

B.21

004050X151 997 AK2/AK3 AK3 DATA SEGMENT NOTE


DATA SEGMENT NOTE

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

AK3

004050X151 997 AK2/AK3 AK3 DATA SEGMENT NOTE

IMPLEMENTATION

DATA SEGMENT NOTE


Loop: AK2/AK3 DATA SEGMENT NOTE Repeat: 999999 Usage: SITUATIONAL Repeat: 1

2 013 100

Notes:

1. Required and used only when there are errors to report in a transaction and the senders system has the capability to identify and report the data required in this segment.

504
STANDARD

Example: AK3NM1107~

AK3 Data Segment Note


Level: Header Position: 0400 Loop: AK2/AK3 Repeat: 999999 Requirement: Optional Max Use: 1 Purpose: To report errors in a data segment and identify the location of the data segment Set Notes: 1. The data segments of this standard are used to report the results of the syntactical analysis of the functional groups of transaction sets; they report the extent to which the syntax complies with the standards or proper subsets of transaction sets and functional groups. They do not report on the semantic meaning of the transaction sets (for example, on the ability of the receiver to comply with the request of the sender).

DIAGRAM

AK301

721

AK302

719

AK303

447

AK304

720

AK3

Segment ID Code
M1 ID 2/3

Segment Pos in TS
M1 N0 1/6

Loop ID Code
O1 AN 1/4

Segment Syn ~ Error Code


O1 ID 1/3

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

AK301

721

Segment ID Code

M1

ID

2/3

Code defining the segment ID of the data segment in error (See Appendix A Number 77)
CODE SOURCE 77:

X12 Directories

505

This is the 2 or 3 characters which occur at the beginning of a segment.

B.22

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 997 AK2/AK3 AK3 DATA SEGMENT NOTE

REQUIRED

AK302

719

Segment Position in Transaction Set

M1

N0

1/6

The numerical count position of this data segment from the start of the transaction set: the transaction set header is count position 1

506
SITUATIONAL AK303 447

This is a data count, not a segment position in the standard description. Loop Identifier Code O 1 AN 1/4
The loop ID number given on the transaction set diagram is the value for this data element in segments LS and LE

507

Code identifying a loop within the transaction set which is bounded by the related LS and LE segments (corresponding LS and LE segments must have the same value for loop identifier). (Note: The loop ID number given on the transaction set diagram is recommended as the value for this data element in the segments LS and LE.) Use only when there is an error in a loop bounded by segments LS and LE and the senders system has the capability to identify this information. AK304 720 Segment Syntax Error Code O1 ID 1/3
Code indicating error found based on the syntax editing of a segment

1000142
SITUATIONAL

1000133

Required and used only when an error exists and the error can be described by one of the codes listed for this data element.
CODE DEFINITION

1 2 3 4 5 6 7 8

Unrecognized segment ID Unexpected segment Mandatory segment missing Loop Occurs Over Maximum Times Segment Exceeds Maximum Use Segment Not in Defined Transaction Set Segment Not in Proper Sequence Segment Has Data Element Errors

MAY 2004

B.23

004050X151 997 AK2/AK3 AK4 DATA ELEMENT NOTE


DATA ELEMENT NOTE

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

AK4

004050X151 997 AK2/AK3 AK4 DATA ELEMENT NOTE

IMPLEMENTATION

DATA ELEMENT NOTE


Loop: AK2/AK3 DATA SEGMENT NOTE Usage: SITUATIONAL Repeat: 99

4 013 100

Notes:

1. Required and used only when there are errors to report in a data element or composite data element and when the senders system can identify those errors and report the data required in this segment.

509
STANDARD

Example: AK4198711Z~

AK4 Data Element Note


Level: Header Position: 0500 Loop: AK2/AK3 Requirement: Optional Max Use: 99 Purpose: To report errors in a data element or composite data structure and identify the location of the data element
DIAGRAM

AK401

C030

AK402

725

AK403

723

AK404

724

AK4

Position in Segment
M1

Data Elemnt Data Elemnt Copy of Bad ~ Ref Number Error Code Data Elemnt
O1 N0 1/4 M1 ID 1/3 O1 AN 1/99

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

AK401

C030

POSITION IN SEGMENT

M1

Code indicating the relative position of the simple data element or composite data structure in error within a segment, count beginning with 1 for the position immediately following the segment ID; additionally indicating the relative position of a repeating structure in error, count beginning with 1 for the position immediately following the preceding element separator; additionally indicating the relative position of a component of a composite data structure in error, count beginning with 1 for the position following the preceding element or repetition separator

REQUIRED

AK401 - 1

722

Element Position in Segment

N0

1/2

This is used to indicate the relative position of a simple data element, or the relative position of a composite data structure with the relative position of the component within the composite data structure, in error; in the data segment the count starts with 1 for the simple data element or composite data structure immediately following the segment ID

B.24

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 997 AK2/AK3 AK4 DATA ELEMENT NOTE

SITUATIONAL

AK401 - 2

1528

Component Data Element Position in Composite

N0

1/2

To identify the component data element position within the composite that is in error

1000082
SITUATIONAL SITUATIONAL

Used only when an error occurs in a composite data element and the composite data element position can be determined. AK401 - 3 AK402 725 1686 Repeating Data Element Position O O1 N0 N0 1/4 1/4
To identify the specific repetition of a data element that is in error

Data Element Reference Number


ADVISORY: Under CODE SOURCE 77:

Reference number used to locate the data element in the Data Element Dictionary most circumstances, this element is expected to be sent. X12 Directories

1000135

Required and used only when the data element in error has a reference number and the reference number can be determined and reported by the senders system. An example of a reference number (the reference numbers for data elements listed in this guide can be found in the segment detail information shown as data element numbers), is the number 725 which is the reference number for this data element. AK403 723 Data Element Syntax Error Code
CODE DEFINITION

1000136

REQUIRED

M1

ID

1/3

Code indicating the error found after syntax edits of a data element

1 2 3 4 5 6 7 8 9 10 SITUATIONAL AK404 724

Mandatory data element missing Conditional required data element missing. Too many data elements. Data element too short. Data element too long. Invalid character in data element. Invalid code value. Invalid Date Invalid Time Exclusion Condition Violated O 1 AN 1/99

Copy of Bad Data Element


This is a copy of the data element in error
SEMANTIC:

In no case shall a value be used for AK404 that would generate a syntax error, e.g., an invalid character.

1000137

Required and used only when the senders system can capture and report the invalid data element, and only when the value to be used for AK404 is not an invalid character or character that would generate a syntax error.

MAY 2004

B.25

004050X151 997 AK2 AK5 TRANSACTION SET RESPONSE TRAILER


TRANSACTION SET RESPONSE TRAILER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

AK5

004050X151 997 AK2 AK5 TRAILER TRANSACTION SET RESPONSE

IMPLEMENTATION

TRANSACTION SET RESPONSE TRAILER


Loop: AK2/AK3 DATA SEGMENT NOTE Usage: REQUIRED Repeat: 1

511
STANDARD

Example: AK5E5~

AK5 Transaction Set Response Trailer


Level: Header Position: 0600 Loop: AK2 Requirement: Mandatory Max Use: 1 Purpose: To acknowledge acceptance or rejection and report errors in a transaction set
DIAGRAM

AK501

717

AK502

718

AK503

718

AK504

718

AK505

718

AK506

718

AK5

TS Ack Code
M1 ID 1/1

TS Syntax Error Code


O1 ID 1/3

TS Syntax Error Code


O1 ID 1/3

TS Syntax Error Code


O1 ID 1/3

TS Syntax Error Code


O1 ID 1/3

TS Syntax Error Code


O1 ID 1/3

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

AK501

717

Transaction Set Acknowledgment Code

M1

ID

1/1

Code indicating accept or reject condition based on the syntax editing of the transaction set
CODE DEFINITION

Accepted ADVISED

E M

Accepted But Errors Were Noted Rejected, Message Authentication Code (MAC) Failed Rejected ADVISED

W X

Rejected, Assurance Failed Validity Tests Rejected, Content After Decryption Could Not Be Analyzed

B.26

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 997 AK2 AK5 TRANSACTION SET RESPONSE TRAILER

SITUATIONAL

AK502

718

Transaction Set Syntax Error Code Required and used only when an error exists.
CODE DEFINITION

O1

ID

1/3

Code indicating error found based on the syntax editing of a transaction set

1000138

1 2 3

Transaction Set Not Supported Transaction Set Trailer Missing Transaction Set Control Number in Header and Trailer Do Not Match Number of Included Segments Does Not Match Actual Count One or More Segments in Error Missing or Invalid Transaction Set Identifier Missing or Invalid Transaction Set Control Number Authentication Key Name Unknown Encryption Key Name Unknown Requested Service (Authentication or Encrypted) Not Available Unknown Security Recipient Incorrect Message Length (Encryption Only) Message Authentication Code Failed Unknown Security Originator Syntax Error in Decrypted Text Security Not Supported Invalid Transaction Set Implementation Convention Reference Transaction Set Control Number Not Unique within the Functional Group S3E Security End Segment Missing for S3S Security Start Segment S3S Security Start Segment Missing for S3E Security End Segment S4E Security End Segment Missing for S4S Security Start Segment S4S Security Start Segment Missing for S4E Security End Segment

5 6 7 8 9 10

11 12 13 15 16 17 19

23

24

25

26

27

MAY 2004

B.27

004050X151 997 AK2 AK5 TRANSACTION SET RESPONSE TRAILER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

SITUATIONAL

AK503

718

Transaction Set Syntax Error Code

O1

ID

1/3

Code indicating error found based on the syntax editing of a transaction set

512
SITUATIONAL AK504 718

Used only when sender needs to send an additional error code and the preceding data element was used. Use codes as listed in AK502. Transaction Set Syntax Error Code O1 ID 1/3
Code indicating error found based on the syntax editing of a transaction set

512
SITUATIONAL AK505 718

Used only when sender needs to send an additional error code and the preceding data element was used. Use codes as listed in AK502. Transaction Set Syntax Error Code O1 ID 1/3
Code indicating error found based on the syntax editing of a transaction set

512
SITUATIONAL AK506 718

Used only when sender needs to send an additional error code and the preceding data element was used. Use codes as listed in AK502. Transaction Set Syntax Error Code O1 ID 1/3
Code indicating error found based on the syntax editing of a transaction set

512

Used only when sender needs to send an additional error code and the preceding data element was used. Use codes as listed in AK502.

B.28

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


FUNCTIONAL GROUP RESPONSE TRAILER

004050X151 997 AK9 FUNCTIONAL GROUP RESPONSE TRAILER

AK9

004050X151 GROUP RESPONSE TRAILER FUNCTIONAL 997 AK9

IMPLEMENTATION

FUNCTIONAL GROUP RESPONSE TRAILER


Usage: REQUIRED Repeat: 1

513
STANDARD

Example: AK9A111~

AK9 Functional Group Response Trailer


Level: Header Position: 0700 Loop: ____ Requirement: Mandatory Max Use: 1 Purpose: To acknowledge acceptance or rejection of a functional group and report the number of included transaction sets from the original trailer, the accepted sets, and the received sets in this functional group
DIAGRAM

AK901

715

AK902

97

AK903

123

AK904

AK905

716

AK906

716

AK9

Funct Group Ack Code


M1 ID 1/1

Number of TS Included
M1 N0 1/6

Number of Number of Funct Group Funct Group Received TS Accepted TS Error Code Error Code
M1 N0 1/6 M1 N0 1/6 O1 ID 1/3 O1 ID 1/3

AK907

716

AK908

716

AK909

716

Funct Group Funct Group Funct Group ~ Error Code Error Code Error Code
O1 ID 1/3 O1 ID 1/3 O1 ID 1/3

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

AK901

715

Functional Group Acknowledge Code

M1

ID

1/1

Code indicating accept or reject condition based on the syntax editing of the functional group
COMMENT: If AK901 contains the value A or E, then the transmitted functional group is accepted. CODE DEFINITION

Accepted ADVISED

E M

Accepted, But Errors Were Noted. Rejected, Message Authentication Code (MAC) Failed

MAY 2004

B.29

004050X151 997 AK9 FUNCTIONAL GROUP RESPONSE TRAILER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

Partially Accepted, At Least One Transaction Set Was Rejected ADVISED

Rejected ADVISED

W X REQUIRED

Rejected, Assurance Failed Validity Tests Rejected, Content After Decryption Could Not Be Analyzed M1 N0 1/6

AK902

97

Number of Transaction Sets Included

Total number of transaction sets included in the functional group or interchange (transmission) group terminated by the trailer containing this data element

514
REQUIRED REQUIRED SITUATIONAL AK903 AK904 AK905 123 2 716

This is the value in the original GE01. Number of Received Transaction Sets
Number of Transaction Sets received

M1 M1 O1

N0 N0 ID

1/6 1/6 1/3

Number of Accepted Transaction Sets Functional Group Syntax Error Code

Number of accepted Transaction Sets in a Functional Group Code indicating error found based on the syntax editing of the functional group header and/or trailer

1000138

Required and used only when an error exists.


CODE DEFINITION

1 2 3 4

Functional Group Not Supported Functional Group Version Not Supported Functional Group Trailer Missing Group Control Number in the Functional Group Header and Trailer Do Not Agree Number of Included Transaction Sets Does Not Match Actual Count Group Control Number Violates Syntax Authentication Key Name Unknown Encryption Key Name Unknown Requested Service (Authentication or Encryption) Not Available Unknown Security Recipient Unknown Security Originator Syntax Error in Decrypted Text Security Not Supported Incorrect Message Length (Encryption Only) Message Authentication Code Failed

6 10 11 12

13 14 15 16 17 18

B.30

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 997 AK9 FUNCTIONAL GROUP RESPONSE TRAILER

19

Functional Group Control Number not Unique within Interchange S3E Security End Segment Missing for S3S Security Start Segment S3S Security Start Segment Missing for S3E End Segment S4E Security End Segment Missing for S4S Security Start Segment S4S Security Start Segment Missing for S4E Security End Segment O1 ID 1/3

23

24

25

26 SITUATIONAL

AK906

716

Functional Group Syntax Error Code

Code indicating error found based on the syntax editing of the functional group header and/or trailer

515
SITUATIONAL AK907 716

Used only when sender needs to send an additional error code and the preceding data element was used. Use codes as listed in AK905. Functional Group Syntax Error Code O1 ID 1/3
Code indicating error found based on the syntax editing of the functional group header and/or trailer

515
SITUATIONAL AK908 716

Used only when sender needs to send an additional error code and the preceding data element was used. Use codes as listed in AK905. Functional Group Syntax Error Code O1 ID 1/3
Code indicating error found based on the syntax editing of the functional group header and/or trailer

515
SITUATIONAL AK909 716

Used only when sender needs to send an additional error code and the preceding data element was used. Use codes as listed in AK905. Functional Group Syntax Error Code O1 ID 1/3
Code indicating error found based on the syntax editing of the functional group header and/or trailer

515

Used only when sender needs to send an additional error code and the preceding data element was used. Use codes as listed in AK905.

MAY 2004

B.31

004050X151 997 SE TRANSACTION SET TRAILER


TRANSACTION SET TRAILER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

SE

TRANSACTION SET TRAILER 004050X151 997 SE

IMPLEMENTATION

TRANSACTION SET TRAILER


Usage: REQUIRED Repeat: 1

516
STANDARD

Example: SE271234~

SE Transaction Set Trailer


Level: Header Position: 0800 Loop: ____ Requirement: Mandatory Max Use: 1 Purpose: To indicate the end of the transaction set and provide the count of the transmitted segments (including the beginning (ST) and ending (SE) segments)
DIAGRAM

SE01

96

SE02

329

SE

Number of Inc Segs


M1 N0 1/10

TS Control Number
M1 AN 4/9

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

SE01

96

Number of Included Segments

M1

N0

1/10

Total number of segments included in a transaction set including ST and SE segments

REQUIRED

SE02

329

Transaction Set Control Number

M 1 AN

4/9

Identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set

501

The Transaction Set Control Numbers in ST02 and SE02 must be identical. The number is assigned by the originator and must be unique within a functional group (GS-GE). The number also aids in error resolution research. For example, start with the number 0001 and increment from there.

B.32

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

C External Code Sources


77 X12 Directories
SIMPLE DATA ELEMENT/CODE REFERENCES

721, 725
SOURCE

X12.3 Data Element Dictionary X12.22 Segment Directory


AVAILABLE FROM

Data Interchange Standards Association, Inc. (DISA) Suite 430 7600 Leesburg Pike Falls Church, VA 22043
ABSTRACT

The data element dictionary contains the format and descriptions of data elements used to construct X12 segments. It also contains code lists associated with these data elements. The segment directory contains the format and definitions of the data segments used to construct X12 transaction sets.

121

Health Industry Number


SIMPLE DATA ELEMENT/CODE REFERENCES

66/21, 128/HI, 1270/HI, I05/20


SOURCE

Health Industry Number Database


AVAILABLE FROM

Health Industry Business Communications Council 5110 North 40th Street Phoenix, AZ 85018
ABSTRACT

The HIN is a coding system, developed and administered by the Health Industry Business Communications Council, that assigns a unique code number to hospitals other provider organizations, and manufacturers and distributors.

133

Current Procedural Terminology (CPT) Codes


SIMPLE DATA ELEMENT/CODE REFERENCES

128/CPT, 235/CJ, 1270/BS, 1270/AAW


SOURCE

Physicians Current Procedural Terminology (CPT) Manual


AVAILABLE FROM

Order Department American Medical Association 515 North State Street Chicago, IL 60610
MAY 2004

C.1

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER ABSTRACT

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

A listing of descriptive terms and identifying codes for reporting medical services and procedures performed by physicians.

464

Health Industry Level 7 (HL7)


SIMPLE DATA ELEMENT/CODE REFERENCES

756/HL
SOURCE

Health Level Standard Version 2.3


AVAILABLE FROM

Health Level 7 (HL7) Suite 227 3300 Washtenaw Avenue Ann Arbor, MI 48104-4250
ABSTRACT

Health Level Seven Interface Standards describe standards for interfacing health care industry institutional computer applications. Tables designated as HL7 tables are part of the standard because they affect the interpretation of the messages that contain them. These tables are available in an Access database that can be obtained from HL7 Headquarters or ordered via our web site.

507

Health Care Claim Status Category Code


SIMPLE DATA ELEMENT/CODE REFERENCES

1271
SOURCE

Health Care Claim Status Category Code


AVAILABLE FROM

www.wpc-edi.com Washington Publishing Company 5740 Industry Lane, 2nd Floor Frederick, MD 21704
ABSTRACT

Code used to organize the Health Care Claim Status Codes into logical groupings

537

Centers for Medicare and Medicaid Services National Provider Identifier


SIMPLE DATA ELEMENT/CODE REFERENCES

66/XX, 128/HPI
SOURCE

National Provider System

C.2

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE AVAILABLE FROM

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

Centers for Medicare and Medicaid Services Office of Financial Management Division of Provider/Supplier Enrollment C4-10-07 7500 Security Boulevard Baltimore, MD 21244-1850
ABSTRACT

The Centers for Medicare & Medicaid Services will develop the National Provider Identifier (NPI) following publication of the implementing regulation, which has been proposed as the standard unique identifier for each health care provider under the Health Insurance Portability and Accountability Act of 1996.

540

Centers for Medicare and Medicaid Services PlanID


SIMPLE DATA ELEMENT/CODE REFERENCES

66/XV, 128/ABY
SOURCE

PlanID Database
AVAILABLE FROM

Centers for Medicare and Medicaid Services Center of Beneficiary Services, Membership Operations Group Division of Benefit Coordination S1-05-06 7500 Security Boulevard Baltimore, MD 21244-1850
ABSTRACT

The Centers for Medicare and Medicaid Services has joined with other payers to develop a unique national payer identification number. The Centers for Medicare and Medicaid Services is the authorizing agent for enumerating payers through the services of a PlanID Registrar. It may also be used by other payers on a voluntary basis.

663

Logical Observation Identifier Names and Codes (LOINC)


SIMPLE DATA ELEMENT/CODE REFERENCES

128/LOI, 235/LB, 1270/LOI


SOURCE

Logical Observation Identifier Names and Codes (LOINC)


AVAILABLE FROM

Regenstrief Institute 1050 Wishard Blvd., 5th Floor Indianapolis, IN 46202


ABSTRACT

List of descriptive terms and identifying codes for reporting precise test methods in medicine.

MAY 2004

C.3

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

881

Version / Release / Industry Identifier Code


SIMPLE DATA ELEMENT/CODE REFERENCES

480
SOURCE

Data Interchange Standards Association


AVAILABLE FROM

Data Interchange Standards Association, Inc. (DISA) 7600 Leesburg Pike Suite 430 Falls Church, VA 22043
ABSTRACT

Code indicating the version, release, sub-release, and industry identifier of the EDI standard being used, including the GS and GE segments; if code in DE455 in GS segment is X, then in DE 480 positions 1-3 are the version number; positions 4-6 are the release and sub-release, level of the version; and positions 7-12 are the industry or trade association identifiers (optionally assigned by user); if code in DE455 in GS segment is T, then other formats are allowed.

C.4

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

D Change Summary
D.1 Change Summary
This is the first Implementation Guide (IG) for the 275. In future guides, this section will contain a summary of all changes since the previous guide.

MAY 2004

D.1

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

D.2

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

E Data Element Name Index


This appendix contains an alphabetic listing of data elements used in this implementation guide. Consult the Data Element Dictionary for the complete list. Data element names in normal type are generic ASC X12 names. Italic type indicates a health care industry defined name.
Name Definition Transaction Set ID Locator Key H=Header, D=Detail, S=Summary Loop ID Segment ID/Reference Designator Composite ID-Sequence Data Element Number Page Number

Payment Date
Date of payment. 277
D | 2200D | SPA12 | C001-2 | 373 .............. 156

Additional Information Gathered Date


Date additional information provided in transaction was gathered.
D | 2100B | DTP03 |
ADDITIONAL INFORMATION REQUEST CODE

Attachment Information Format Code


| 1251 ...............79

A code that identifies the format of the attachment information being sent in the BIN segment.
D | 2100B | CAT02 |
ATTACHMENT REPORT TYPE CODE

| 756 ................ 81

Additional Information Request Code


Code identifying the additional information requested.
ADDITIONAL INFORMATION REQUEST MODIFIER

Attachment Report Type Code


Code to specify the type of attachment that is related to the claim.
BILL TYPE IDENTIFIER

D | 2000A | STC01 | C043-2 | 1271 ...............69

D | 2100B | CAT01 |

| 755 ................ 81

Additional Information Request Modifier


A code that is used to modify the implicit scope of an Additional Information Request Code
ASSIGNED NUMBER

Bill Type Identifier


A code indicating the specific type of bill or claim.
BINARY DATA

H | 1000D | REF02 |

| 127 ................ 60

D | 2000A | STC10 | C043-2 | 1271 ...............70 D | 2000A | STC11 | C043-2 | 1271 ...............71

Binary Data
A string of octets whch can assume any binary pattern from hexadecimal OO to FF.
BINARY DATA LENGTH NUMBER

Assigned Number
Number assigned for differentiation within a transaction set.
ASSOCIATED OBJECT REFERENCE IDENTIFICATION

H | | BDS03 | D | 2110B | BIN02 |

| 785 ................ 11 | 785 ................ 84

D | 2000A |

LX01

| 554 .................65

Binary Data Length Number


Associated Object Reference Identification
Reference assigned by the application to uniquely identify an object.
H |
ATTACHMENT INFORMATION FORMAT CODE

Expession of the length of following binary data in the number of integral octets of the binary data.
CLAIM SERVICE PERIOD

H | | BDS02 | D | 2110B | BIN01 |

| 784 ................ 11 | 784 ................ 84

| ORI01 |

| 1690 .................6

Claim Service Period


The beginning and end dates for the service period covered by a claim.
H | 1000D | DTP03 |
CLEARINGHOUSE TRACE NUMBER

| 1251 .............. 64

MAY 2004

E.1

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

Clearinghouse Trace Number


Unique tracking number for the transaction assigned by a clearinghouse.
CODE LIST QUALIFIER CODE

Health Care Claim Status Category Code


Code indicating the category of the associated claim status code.
D | 2000A | STC01 | C043-1 | 1271 .............. 69 D | 2000A | STC10 | C043-1 | 1271 .............. 70 D | 2000A | STC11 | C043-1 | 1271 .............. 70

H | 1000D | REF02 |

| 127 ................ 63

Code List Qualifier Code


Code identifying a specific industry code list.
D | 2000A | STC01 | C043-4 | 1270 .............. 69 D | 2000A | STC10 | C043-4 | 1270 .............. 70 D | 2000A | STC11 | C043-4 | 1270 .............. 71

IDENTIFICATION CODE QUALIFIER

Identification Code Qualifier


Code designating the system/method of code structure used for Identification Code (67).
H H H H | | | | 1000A 1000B 1000C 1000D | | | | NM108 NM108 NM108 NM108 | | | | | 66 .................. 42 | 66 .................. 47 | 66 .................. 50 | 66 .................. 55

COMMUNICATION NUMBER QUALIFIER

Communication Number Qualifier


Code identifying the type of communication number.
H | 1000A | PER03 | H | 1000A | PER05 | H | 1000A | PER07 | | 365 ................ 44 | 365 ................ 45 | 365 ................ 45

IMPLEMENTATION CONVENTION REFERENCE IDENTIFIER

CONTACT FUNCTION CODE

Implementation Convention Reference Identifier


Identifies the ANSI Version and Implementation Guide being used for this transaction.
INFORMATION RECEIVER CONTACT COMMUNICATION NUMBER

Contact Function Code


Code identifying the major duty or responsibility of the person or group named.
H | 1000A | PER01 |
DATE TIME PERIOD FORMAT QUALIFIER

H |

ST03

| 1705 .............. 38

| 366 ................ 44

Information Receiver Contact Communication Number


Communication Number for the Individual at information receiver to whom inquiries about this transaction should be directed.
H | 1000A | PER04 | H | 1000A | PER06 | H | 1000A | PER08 |
INFORMATION RECEIVER CONTACT NAME

Date Time Period Format Qualifier


Code indicating the date format, time format, or date and time format.
H | 1000D | DTP02 | D | 2100A | DTP02 | D | 2100B | DTP02 | | 1250 .............. 64 | 1250 .............. 78 | 1250 .............. 79

| 364 ................ 44 | 364 ................ 45 | 364 ................ 45

DATE TIME QUALIFIER

Date Time Qualifier


Code specifying the type of date or time or both date and time.
H | 1000D | DTP01 | D | 2100A | DTP01 | D | 2100B | DTP01 | | 374 ................ 64 | 374 ................ 77 | 374 ................ 79

Information Receiver Contact Name


Individual at information receiver to whom inquiries about this transaction should be directed.
LINE ITEM CONTROL NUMBER

H | 1000A | PER02 |

| 93 .................. 44

ENTITY IDENTIFIER CODE

Line Item Control Number


Entity Identifier Code
Code identifying an organizational entity, a physical location, property or an individual.
H H H H | | | | 1000A 1000B 1000C 1000D | | | | NM101 NM101 NM101 NM101 | | | | | 98 .................. 41 | 98 .................. 47 | 98 .................. 49 | 98 .................. 54

Identifier assigned by the submitter/provider to this line item.


MEDICAL RECORD NUMBER

D | 2000A | REF02 |

| 127 ................ 73

Medical Record Number


A unique number assigned to patient by the provider to assist in retrieval of medical records.
H | 1000D | REF02 |
NUMBER OF INCLUDED SEGMENTS

ENTITY TYPE QUALIFIER

| 127 ................ 61

Entity Type Qualifier


Code qualifying the type of entity.
H H H H | | | | 1000A 1000B 1000C 1000D | | | | NM102 NM102 NM102 NM102 | | | | | 1065 .............. 42 | 1065 .............. 47 | 1065 .............. 50 | 1065 .............. 55

Number of Included Segments


Total number of segments included in a transaction set including ST and SE segments.
H |
OBJECT ATTRIBUTE IDENTIFICATION

SE01

| 96 .................. 12

FILTER ID CODE

Filter ID Code
Code specifying the type of filter used to convert data code values.
HEALTH CARE CLAIM STATUS CATEGORY CODE

Object Attribute Identification


Identification of the attribute applying to the object type.
OBJECT IDENTIFICATION GROUP

H |

| BDS01 |

| 1570 ...............11

H |

| OOI03 |

| 1692 .............. 10

E.2

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

Object Identification Group


Value identifying the group used to link to related object identifications.
H |
OBJECT TYPE QUALIFIER

Provider First Name


The first name of the provider of care submitting a transaction or related to the information provided in or request by the transaction.
PROVIDER IDENTIFIER

| OOI01 |

| 1694 ................ 9

H | 1000C | NM104 |

| 1036 .............. 50

Object Type Qualifier


Code identifying type of object.
PATIENT ACCOUNT NUMBER

Provider Identifier
| 1691 ................ 9

H |

| OOI02 |

Number assigned by the payer, regulatory authority, or other authorized body or agency to identify the provider.
PROVIDER LAST OR ORGANIZATION NAME

Patient Account Number


Unique identification number assigned by the provider to the claim patient to facilitate posting of payment information and identification of the billed claim.
PATIENT FIRST NAME

H | 1000C | NM109 |

| 67 .................. 51

Provider Last or Organization Name


The last name of the provider of care or name of the provider organization submitting a transaction or related to the information provided in or request by the transaction.
PROVIDER MIDDLE NAME

H | 1000D | REF02 |

| 127 ................ 58

Patient First Name


The first name of the individual to whom the services were provided.
PATIENT LAST NAME

H | 1000C | NM103 |

| 1035 .............. 50

H | 1000D | NM104 |

| 1036 .............. 55

Provider Middle Name


The middle name of the provider of care submitting a transaction or related to the information provided in or request by the transaction.
PROVIDER NAME SUFFIX

Patient Last Name


The last name of the individual to whom the services were provided.
H | 1000D | NM103 |
PATIENT MIDDLE NAME

| 1035 .............. 55

H | 1000C | NM105 |

| 1037 .............. 50

Patient Middle Name


The middle name of the individual to whom the services were provided.
PATIENT NAME SUFFIX

Provider Name Suffix


| 1037 .............. 55

H | 1000D | NM105 |

The name suffix of the provider of care submitting a transaction or related to the information provided in or request by the transaction.
H | 1000C | NM107 |
PROVIDER SECONDARY IDENTIFIER

| 1039 .............. 50

Patient Name Suffix


Suffix to the name of the individual to whom the services were provided.
PATIENT PRIMARY IDENTIFIER

Provider Secondary Identifier


Additional identifier for the provider.
RECEIVER IDENTIFIER

H | 1000D | NM107 |

| 1039 .............. 55

H | 1000C | REF02 |

| 127 ................ 53

Patient Primary Identifier


Identifier assigned by the payer to identify the patient
H | 1000D | NM109 |
PAYER OR PROVIDERS CONTROL NUMBER

Receiver Identifier
Number identifying the organization receiving the payment.
RECEIVER NAME

| 67 .................. 56

H | 1000A | NM109 |

| 67 .................. 42

Payer or Providers Control Number


The Payers Claim Control Number from the Request for Additional Information or the Providers Attachment Control Number from the Claim.
D | 2000A | TRN02 |
PROCEDURE CODE

Receiver Name
Name of organization receiving the transaction.
REFERENCE IDENTIFICATION

H | 1000A | NM103 |

| 1035 .............. 42

| 127 ................ 67

Reference Identification
The identification value assigned by the sender for this particular transaction.
H |
REFERENCE IDENTIFICATION QUALIFIER

Procedure Code
Code identifying the procedure, product or service.
PROVIDER FIRST NAME

| REF02 |

| 127 .................. 8

D | 2000A | REF02 |

| 127 ................ 75

Reference Identification Qualifier


Code qualifying the reference identification.
H | | REF01 | H | 1000C | REF01 | H | 1000D | REF01 | | 128 .................. 7 | 128 ................ 52 | 128 ................ 57

MAY 2004

E.3

004050X151 275 ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER


H H H D D D | | | | | | 1000D 1000D 1000D 2000A 2000A 2000A | | | | | | REF01 REF01 REF01 REF01 REF01 REF04 | | | | | | C040-1 | 128 ................ 59 | 128 ................ 61 | 128 ................ 62 | 128 ................ 72 | 128 ................ 74 | 128 ................ 75

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

Trace Type Code


Code identifying the type of reassociation which needs to be performed.
D | 2000A | TRN01 |
TRANSACTION SEGMENT COUNT

| 481 ................ 66

REVENUE CODE

Transaction Segment Count Revenue Code


A code that identifies a specific accommodation, ancillary service or billing calculation.
D | 2000A | REF04 | C040-2 | 127 ................ 76
SECURITY LEVEL CODE

A tally of all segments between the ST and the SE segments including the ST and SE segments.
TRANSACTION SET CONTROL NUMBER

D |

SE01

| 96 .................. 85

Security Level Code


Code indicating the level of confidentiality assigned by the sender to the information following.
SERVICE DATE

Transaction Set Control Number


The unique identification number within a transaction set.
H H H D | | | | | | | | ST02 SE02 ST02 SE02 | | | | | 329 .................. 5 | 329 ................ 12 | 329 ................ 37 | 329 ................ 85

D | 2110B | EFI01 |

| 786 ................ 83

Service Date
Date of service, such as the start date of the service, the end date of the service, or the single day date of the service.
SUBMITTER FIRST NAME

TRANSACTION SET CREATION DATE

Transaction Set Creation Date


Identifies the date the submitter created the transaction.
H |
TRANSACTION SET IDENTIFIER CODE

D | 2100A | DTP03 |

| 1251 .............. 78

| BGN03 |

| 373 ................ 40

Submitter First Name


The first name of the person submitting the transaction or receiving the transaction, as identified by the preceding identification code.
H | 1000B | NM104 |
SUBMITTER IDENTIFIER

Transaction Set Identifier Code


Code uniquely identifying a Transaction Set.
H | H |
TRANSACTION SET PURPOSE CODE

| 1036 .............. 47

| |

ST01 ST01

| |

| 143 .................. 5 | 143 ................ 37

Submitter Identifier
Code or number identifying the entity submitting the claim.
H | 1000B | NM109 |
SUBMITTER LAST OR ORGANIZATION NAME

Transaction Set Purpose Code


Code identifying purpose of transaction set.
TRANSACTION SET REFERENCE NUMBER

| 67 .................. 47

H |

| BGN01 |

| 353 ................ 39

Submitter Last or Organization Name


The last name or the organizational name of the entity submitting the transaction
H | 1000B | NM103 |
SUBMITTER MIDDLE NAME

Transaction Set Reference Number


Number uniquely identifying a transaction set.
VERSION IDENTIFICATION CODE

H |

| BGN02 |

| 127 ................ 40

| 1035 .............. 47

Version Identification Code Submitter Middle Name


The middle name of the person submitting the transaction
TRACE TYPE CODE

Revision level of a particular format, program, technique or algorithm


D | 2100B | CAT03 | | 799 ................ 81

H | 1000B | NM105 |

| 1037 .............. 47

E.4

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

004050X151 102

F
F.1

102 Transaction Set


Associated Data
The Associated Data (102) will be used as an HL7 syntax validation. It can be requested by one of the trading partners. This transaction set is used to acknowledge(accept/reject) the HL7 Standard in the 275 BIN segment.

MAY 2004

F.1

004050X151 102

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

F.2

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


004050X151 102

004050X151 102

APRIL 6, 2004 IMPLEMENTATION

102
PAGE # POS. # SEG. ID NAME

Associated Data

Table 1 - Header
USAGE REPEAT LOOP REPEAT

5 6 7 9 11 12

0100 ST 0200 ORI 0300 0400 0500 0600 REF OOI BDS SE

Transaction Set Header Payer Control Number\Providers Control Number Reference Identification Application Transaction Reference Identification File Format\File Version HL7 Message Response Transaction Set Trailer

R R R R R R

1 1 1 >1 1 1

MAY 2004

F.3

004050X151 102 STANDARD

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

102

Associated Data
Functional Group ID: AC
This X12 Transaction Set contains the format and establishes the data contents of the Associated Data Transaction Set (102) for use within the context of an Electronic Data Interchange (EDI) environment. This transaction set may be used to convey associated data. Associated data is defined as an object, a set of functionally-related information not using the usual transaction set structure in segments. The complete set of information constituting an object, including the information necessary to uniquely identify an object, is defined as a package. Objects may include graphic, text, parametric, tabular, image, spectral, audio, etc. data. The character set repertoire of an object is not governed by the character set repertoire identified for any accompanying transaction sets contained in the interchange. Associated data may be linked with other business transactions as an augmentation to other functional data. Therefore, referencing capabilities properly relating the object to the associated transaction set must be provided. Because user preferences require flexibility within the techniques for referring to an object, no particular methodology is specified. The only requirement is the assignment of an object identification number attributable to the object which should be unique for a sufficient time to avoid any confusion. Multiple references to identify all related transaction sets and objects are permitted. The transaction set is not media dependent, is not limited to a specific transmission protocol, and can be linked to other transaction sets. Interchanges may contain functional groups containing transaction sets, packages, or transaction sets and packages. The transaction set may be included in any functional group within an interchange. Only one package may be conveyed within a single occurrence of an Associated Data Transaction Set.

Table 1 - Header
PAGE #
POS. # SEG. ID NAME REQ. DES. MAX USE LOOP REPEAT

0100 0200 0300 0400 0500 0600 NOTES: 1/0200

ST ORI REF OOI BDS SE

Transaction Set Header Object Reference Identification Reference Information Associated Object Type Identification Binary Data Structure Transaction Set Trailer

M M O M M M

1 1 >1 >1 1 1

The ORI segment shall identify the object identification reference number. This corresponds to the object identification specified in any related applicable transaction set where the REF (or equivalent) segment is used to link the functional data and object(s).

1/0300 1/0400 1/0500

An occurrence of the REF segment will, if needed, identify a unique application transaction reference number specified in the transaction set associated with the object. One occurrence of the OOI segment is mandatory and shall be used for file format identification (Code value 13" in data element 1691). The BDS segment shall contain the object.

F.4

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


TRANSACTION SET HEADER

004050X151 102 ST TRANSACTION SET HEADER

ST

TRANSACTION SET HEADER 004050X151 102 ST

IMPLEMENTATION

TRANSACTION SET HEADER


Usage: REQUIRED Repeat: 1

9 008 100

Notes:

1. Use of the 102 transaction is subject to trading partner agreement or accepted usage and is neither mandated nor prohibited in this Appendix.

0 009 100
STANDARD

Example: ST1021234~

ST Transaction Set Header


Level: Header Position: 0100 Loop: ____ Requirement: Mandatory Max Use: 1 Purpose: To indicate the start of a transaction set and to assign a control number
DIAGRAM

ST01

143

ST02

329

ST03

1705

ST
M1

TS ID Code
ID 3/3

TS Control Number
M1 AN 4/9

Imple Conv Reference


O1 AN 1/35

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

ST01

143

Transaction Set Identifier Code


Code uniquely identifying a Transaction Set
SEMANTIC:

M1

ID

3/3

The transaction set identifier (ST01) is used by the translation routines of the interchange partners to select the appropriate transaction set definition (e.g., 810 selects the Invoice Transaction Set).
CODE DEFINITION

102 REQUIRED ST02 329

Associated Data M 1 AN 4/9

Transaction Set Control Number

Identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set

1000091

The Transaction Set Control Numbers in ST02 and SE02 must be identical. The number is assigned by the originator and must be unique within a functional group (GS-GE). The number also aids in error resolution research. For example, start with the number 0001 and increment from there. Use the corresponding value in ST02 for this transaction set. ST03 1705 Implementation Convention Reference O 1 AN 1/35

1000092
NOT USED

MAY 2004

F.5

004050X151 102 ORI ASC X12N INSURANCE SUBCOMMITTEE PAYER CONTROL NUMBER\PROVIDERS CONTROL NUMBER REFERENCE IDENTIFICATION IMPLEMENTATION GUIDE
OBJECT REFERENCE IDENTIFICATION

ORI

004050X151 102 ORI PAYER CONTROL NUMBER\PROVIDERS CONTROL NUMBER REFERENCE IDENTIFICATION

IMPLEMENTATION

PAYER CONTROL NUMBER\PROVIDERS CONTROL NUMBER REFERENCE IDENTIFICATION


Usage: REQUIRED Repeat: 1

3 009 100 4 009 100


STANDARD

Notes:

1. This Reference Identification would be the number that was given in the TRN Segment in loop 2000A of the 275 Transaction.

Example: ORI1234567~

ORI Object Reference Identification


Level: Header Position: 0200 Loop: ____ Requirement: Mandatory Max Use: 1 Purpose: To identify the object identification reference Set Notes: 1. The ORI segment shall identify the object identification reference number. This corresponds to the object identification specified in any related applicable transaction set where the REF (or equivalent) segment is used to link the functional data and object(s).

DIAGRAM

ORI01

1690

ORI

Assoc. Obj.
M1

Refernce ID
AN 1/36

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

ORI01

1690

Associated Object Reference Identification

M 1 AN

1/36

Reference assigned by the application to uniquely identify an object

1000093

This Reference Identification would be the number that was given in the TRN Segment in loop 2000A of the 275 Transaction.

F.6

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


REFERENCE INFORMATION

004050X151 102 REF APPLICATION TRANSACTION REFERENCE IDENTIFICATION

REF

APPLICATION TRANSACTION REFERENCE IDENTIFICATION 004050X151 102 REF

IMPLEMENTATION

APPLICATION TRANSACTION REFERENCE IDENTIFICATION


Usage: REQUIRED Repeat: 1

5 009 100

Notes:

1. The Reference Identification would be the number that was given in the MSH Segment of the HL7 Message. It is the Message Control ID given in MSH-10.

6 009 100
STANDARD

Example: REFACLRegenstrief0128765419~

REF Reference Information


Level: Header Position: 0300 Loop: ____ Requirement: Optional Max Use: >1 Purpose: To specify identifying information Set Notes: 1. An occurrence of the REF segment will, if needed, identify a unique application transaction reference number specified in the transaction set associated with the object. 1. R0203 At least one of REF02 or REF03 is required.

Syntax:
DIAGRAM

REF01

128

REF02

127

REF03

352

REF04

C040

REF

Reference Ident Qual


M1 ID 2/3

Reference Ident
X1 AN 1/50

Description
X1 AN 1/80

Reference Identifier
O1

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

REF01

128

Reference Identification Qualifier


Code qualifying the Reference Identification
CODE DEFINITION

M1

ID

2/3

ACL

Application Transaction Reference Number This is the number assigned by the system which prepared the HL7 message and is the Message Control ID that was given in MSH-10 of the HL7 message.

1000097

MAY 2004

F.7

004050X151 102 REF APPLICATION TRANSACTION REFERENCE IDENTIFICATION

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

REQUIRED

REF02

127

Reference Identification

X1

AN

1/50

Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SYNTAX:

R0203

1000097
NOT USED NOT USED

This is the number assigned by the system which prepared the HL7 message and is the Message Control ID that was given in MSH-10 of the HL7 message. REF03 REF04 352 C040 Description REFERENCE IDENTIFIER X1 O1 AN 1/80

F.8

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


ASSOCIATED OBJECT TYPE IDENTIFICATION

004050X151 102 OOI FILE FORMAT\FILE VERSION

OOI

004050X151 102 VERSION FILE FORMAT\FILE OOI

IMPLEMENTATION

FILE FORMAT\FILE VERSION


Usage: REQUIRED Repeat: >1

8 009 100

Notes:

1. There would be two OOI segments used in this transaction. They would be linked by using the same group identification in OOI02. One would identify that the format of the BDS segment is HL7. The second would identify that the Attachment Release is 2.1.

9 009 100
STANDARD

Example: OOIA13HL7~ OOIA142.1~

OOI Associated Object Type Identification


Level: Header Position: 0400 Loop: ____ Requirement: Mandatory Max Use: >1 Purpose: To identify attributes and status related to the object Set Notes:
DIAGRAM

1. One occurrence of the OOI segment is mandatory and shall be used for file format identification (Code value 13" in data element 1691).

OOI01

1694

OOI02

1691

OOI03

1692

OOI04

1693

OOI

Object ID Group
M1 AN 1/2

Object Type
Qualifier
ID M1 1/3

Object Attr ID
M1 AN 1/256

Controlling Agency
O1 ID 1/3

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED REQUIRED

OOI01 OOI02

1694 1691

Object Identification Group


To link related object identifications

M 1 AN M1 ID

1/2 1/3

Object Type Qualifier


Code identifying type of object
SEMANTIC:

Object type qualifier (data element 1691) defines the object attribute (either data element 1692 or 1693), instructing the receiving system on how to process and route the object.
CODE DEFINITION

13

File Format This code would be used in the OOI segment that is identifying the use of the HL7 Standard in the BDS segment.

1000199

MAY 2004

F.9

004050X151 102 OOI FILE FORMAT\FILE VERSION

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

14

File Version This code would be used in the OOI segment that is identifying the Attachment Specification Release being used in the BDS Segment.

1000200
REQUIRED

OOI03

1692

Object Attribute Identification


Identification of the attribute applying to the object type

M 1 AN

1/256

1000102
NOT USED OOI04 1693

If OOI02 contains 13 then OOI03 will have HL7 If OOI02 contains 14 then OOI03 will have 2.1 Controlling Agency O1 ID 1/3

F.10

MAY 2004

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE


BINARY DATA STRUCTURE

004050X151 102 BDS HL7 MESSAGE RESPONSE

BDS

HL7 MESSAGE RESPONSE 004050X151 102 BDS

IMPLEMENTATION

HL7 MESSAGE RESPONSE


Usage: REQUIRED Repeat: 1

1 020 100 4 009 100


STANDARD

Notes:

1. This segment will contain the HL7 acknowledgment from the receiving HL7 Translator. See the HL7 Specifications for details.

Example: ORI1234567~

BDS Binary Data Structure


Level: Header Position: 0500 Loop: ____ Requirement: Mandatory Max Use: 1 Purpose: To transfer binary data in a single data segment, convey a critical filter for transmission and allow identification of the end of the data segment through a count; there is no identification of the internal structure of the binary data in this segment Set Notes:
DIAGRAM

1. The BDS segment shall contain the object.

BDS01

1570

BDS02

784

BDS03

785

BDS

Filter ID Code
M1 ID 3/3

Length of Binary Data


M1 N0 1/15

M1

Binary Data
B 1/1

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

BDS01

1570

Filter ID Code
CODE DEFINITION

M1

ID

3/3

Code specifying the type of filter used to convert data code values

ASC REQUIRED BDS02 784

ASCII Filter M1 N0 1/15

Length of Binary Data


The length in integral octets of the binary data
SEMANTIC:

BDS02 is the length of the data in BDS03 after application of the filter indicated by BDS01. For example; a 1000 byte binary file that has been filtered using Base 64 encoding (value B64 in BDS01) will have a value of 1336 in the BDS02.

INDUSTRY: Binary

Data Length Number

1000202
REQUIRED BDS03 785

See the HL7 Specifications for the HL7 acknowledgment details. Binary Data M1 B 1/1
A string of octets which can assume any binary pattern from hexadecimal 00 to FF

MAY 2004

F.11

004050X151 102 SE TRANSACTION SET TRAILER


TRANSACTION SET TRAILER

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

SE

TRANSACTION SET TRAILER 004050X151 102 SE

IMPLEMENTATION

TRANSACTION SET TRAILER


Usage: REQUIRED Repeat: 1

5 010 100

Notes:

1. Use of the 102 transaction is subject to trading partner agreement or accepted usage and is neither mandated nor prohibited in this Appendix.

6 010 100
STANDARD

Example: SE71234~

SE Transaction Set Trailer


Level: Header Position: 0600 Loop: ____ Requirement: Mandatory Max Use: 1 Purpose: To indicate the end of the transaction set and provide the count of the transmitted segments (including the beginning (ST) and ending (SE) segments)
DIAGRAM

SE01

96

SE02

329

SE

Number of Inc Segs


M1 N0 1/10

TS Control Number
M1 AN 4/9

ELEMENT SUMMARY
REF. DES. DATA ELEMENT

USAGE

NAME

ATTRIBUTES

REQUIRED

SE01

96

Number of Included Segments

M1

N0

1/10

Total number of segments included in a transaction set including ST and SE segments

REQUIRED

SE02

329

Transaction Set Control Number

M 1 AN

4/9

Identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set

1000091

The Transaction Set Control Numbers in ST02 and SE02 must be identical. The number is assigned by the originator and must be unique within a functional group (GS-GE). The number also aids in error resolution research. For example, start with the number 0001 and increment from there.

F.12

MAY 2004