275 Implementation Guide

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
. 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
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
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
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
MAY 2004
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
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
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
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
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
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
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
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
Table 1 - Header
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 #
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 #
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
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

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

BEGINNING SEGMENT
004050X151 275 BGN BEGINNING SEGMENT
BGN
BEGINNING 275 BGN 004050X151 SEGMENT
IMPLEMENTATION
BEGINNING SEGMENT
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
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
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.
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

INDIVIDUAL OR ORGANIZATIONAL NAME
004050X151 275 1000A NM1 TRANSACTION RECEIVER
NM1
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
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
REQUIRED
NM102
1065

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

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
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
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
Receiver Contact Communication Number
191
44
MAY 2004
004050X151 275 1000A PER RESPONSE CONTACT
SITUATIONAL
PER05
365
Communication Number Qualifier

SYNTAX:
X1
ID
2/2
P0506
191
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

SYNTAX:
P0506
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
SYNTAX:
X1
ID
2/2
P0708
191
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

SYNTAX:
P0708
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

NM1
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~

DIAGRAM
NM101
98
NM102
1065
NM103
1035
NM104
1036
NM105
1037
NM106
1038
NM1
Entity ID Code
M1 ID 2/3

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

USAGE
NAME
ATTRIBUTES
REQUIRED
NM101
98
M1
ID
2/3

CODE DEFINITION
Submitter M1 ID 1/1

SEMANTIC:

DEFINITION
CODE
1 2 REQUIRED NM103 1035
Person Non-Person Entity X1 AN 1/60

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
SYNTAX:
P0809
DEFINITION
CODE
Electronic Transmitter Identification Number (ETIN) X1 AN 2/80
Identification 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
NOT USED
NM112
1035
O 1 AN
1/60
48
MAY 2004

004050X151 275 1000C NM1 SERVICE PROVIDER INFORMATION
NM1
IMPLEMENTATION
SERVICE PROVIDER INFORMATION

Loop: 1000C SERVICE PROVIDER INFORMATION Repeat: 1 Usage: REQUIRED Repeat: 1
1 016 100
STANDARD
Example: NM11P2ABC HOSPITALSV159999~

DIAGRAM
NM101
98
NM102
1065
NM103
1035
NM104
1036
NM105
1037
NM106
1038
NM1
Entity ID Code
M1 ID 2/3

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
USAGE
NAME
ATTRIBUTES
REQUIRED
NM101
98
M1
ID
2/3

CODE DEFINITION
1P
Provider
MAY 2004
49
REQUIRED
NM102
1065

SEMANTIC:
M1
ID
1/1

DEFINITION
CODE
1 2 REQUIRED NM103 1035
Person Non-Person Entity X1 AN 1/60

SYNTAX:
C1203
INDUSTRY: Provider
Last or Organization Name

O 1 AN 1/35
SITUATIONAL
NM104
1036
Name First
INDUSTRY: Provider
First Name
169
Required when the value in NM102 is 1 and the persons first name is known. If not required, do not send. Name Middle
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
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
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
SYNTAX:
X1
AN
2/80
P0809
INDUSTRY: Provider
Identifier
X1 O1 ID ID 2/2 2/3 1/60
NM110 NM111 NM112
706 98 1035
O 1 AN
MAY 2004
51
004050X151 275 1000C REF PROVIDER SECONDARY IDENTIFICATION

REFERENCE INFORMATION
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
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
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
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

NM1
IMPLEMENTATION
PATIENT NAME
Loop: 1000D PATIENT NAME Repeat: 1 Usage: REQUIRED Repeat: 1
1 018 100
STANDARD
Example: NM1QC1SMITHJOHNHMI987654320~

DIAGRAM
NM101
98
NM102
1065
NM103
1035
NM104
1036
NM105
1037
NM106
1038
NM1
Entity ID Code
M1 ID 2/3

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
USAGE
NAME
ATTRIBUTES
REQUIRED
NM101
98
M1
ID
2/3

CODE DEFINITION
QC
Patient
54
MAY 2004
REQUIRED
NM102
1065

SEMANTIC:
M1
ID
1/1

DEFINITION
CODE
Person X1 AN 1/60

SYNTAX:
C1203
INDUSTRY: Patient
Last Name
O 1 AN 1/35
SITUATIONAL
NM104
1036
Name First
INDUSTRY: Patient
First Name
169
Required when the value in NM102 is 1 and the persons first name is known. If not required, do not send. Name Middle
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
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
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
SYNTAX:
X1
AN
2/80
P0809
INDUSTRY: Patient
Primary Identifier
X1 O1 ID ID 2/2 2/3 1/60
NM110 NM111 NM112
706 98 1035
O 1 AN
56
MAY 2004

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~

DIAGRAM
REF01
128
REF02
127
REF03
352
REF04
C040
REF

M1 ID 2/3
Reference Ident
X1 AN 1/50
Description
X1 AN 1/80
O1
ELEMENT SUMMARY
USAGE
NAME
ATTRIBUTES
REQUIRED
REF01
128

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
REQUIRED
REF02
127
X1
AN
1/50
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

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~

DIAGRAM
REF01
128
REF02
127
REF03
352
REF04
C040
REF

M1 ID 2/3
Reference Ident
X1 AN 1/50
Description
X1 AN 1/80
O1
ELEMENT SUMMARY
USAGE
NAME
ATTRIBUTES
REQUIRED
REF01
128

CODE DEFINITION
M1
ID
2/3
BLT
Billing Type
MAY 2004
59
004050X151 275 1000D REF INSTITUTIONAL TYPE OF BILL
REQUIRED
REF02
127
X1
AN
1/50
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

004050X151 275 1000D REF MEDICAL RECORD NUMBER
REF
MEDICAL RECORD 1000D REF 004050X151 275 NUMBER
IMPLEMENTATION
MEDICAL RECORD NUMBER

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~

DIAGRAM
REF01
128
REF02
127
REF03
352
REF04
C040
REF

M1 ID 2/3
Reference Ident
X1 AN 1/50
Description
X1 AN 1/80
O1
ELEMENT SUMMARY
USAGE
NAME
ATTRIBUTES
REQUIRED
REF01
128

CODE DEFINITION
M1
ID
2/3
EA REQUIRED REF02 127
Medical Record Identification Number X1 AN 1/50
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
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
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

DIAGRAM
REF01
128
REF02
127
REF03
352
REF04
C040
REF

M1 ID 2/3
Reference Ident
X1 AN 1/50
Description
X1 AN 1/80
O1
ELEMENT SUMMARY
USAGE
NAME
ATTRIBUTES
REQUIRED
REF01
128

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
X1
AN
1/50
SYNTAX:
R0203
INDUSTRY: Clearinghouse
Trace Number
1000185
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
DTP
INSTITUTIONAL CLAIM SERVICE 004050X151 275 1000D DTP DATE
IMPLEMENTATION
INSTITUTIONAL CLAIM SERVICE DATE

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

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
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
TRN
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
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
Referenced Transaction Trace Numbers Used when responding to a 277.
1000169
REQUIRED TRN02 127
M 1 AN
1/50
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
STC
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
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
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
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
REQUIRED
STC10 - 1
1271
Industry Code
SEMANTIC:
AN
1/30
INDUSTRY: Health
CODE SOURCE 507:

107
REQUIRED STC10 - 2 1271
This is the Category Code. Industry Code

SEMANTIC:
AN
1/30
CODE SOURCE 663:
Information Request Modifier
(LOINC)
1000170
SEMANTIC:
O O
ID ID
2/3 1/3

CODE DEFINITION
LOI

SITUATIONAL
STC11
C043
HEALTH CARE CLAIM STATUS
O1
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
INDUSTRY: Health
CODE SOURCE 507:

107
This is the Category Code.
70
MAY 2004
REQUIRED
STC11 - 2
1271
Industry Code
SEMANTIC:
AN
1/30
CODE SOURCE 663:
Information Request Modifier
(LOINC)
1000170
SEMANTIC:
O O
ID ID
2/3 1/3

CODE DEFINITION
LOI

NOT USED
STC12
933
Free-Form Message Text
O 1 AN
1/264
MAY 2004
71
004050X151 275 2000A REF SERVICE LINE ITEM IDENTIFICATION

REF
IMPLEMENTATION
SERVICE LINE ITEM IDENTIFICATION

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~

Level: Detail Position: 0500 Loop: LX Requirement: Optional Max Use: 5 Purpose: To specify identifying information Syntax:
DIAGRAM
REF01
128
REF02
127
REF03
352
REF04
C040
REF

M1 ID 2/3
Reference Ident
X1 AN 1/50
Description
X1 AN 1/80
O1
ELEMENT SUMMARY
USAGE
NAME
ATTRIBUTES
REQUIRED
REF01
128

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
REQUIRED
REF02
127
X1
AN
1/50
SYNTAX:
R0203
INDUSTRY: Line
Item Control Number
1000087
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

REF
004050X151 OR REVENUEREF PROCEDURE 275 2000A CODE
IMPLEMENTATION
PROCEDURE OR REVENUE CODE

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~

Level: Detail Position: 0500 Loop: LX Requirement: Optional Max Use: 5 Purpose: To specify identifying information Syntax:
DIAGRAM
REF01
128
REF02
127
REF03
352
REF04
C040
REF

M1 ID 2/3
Reference Ident
X1 AN 1/50
Description
X1 AN 1/80
O1
ELEMENT SUMMARY
USAGE
NAME
ATTRIBUTES
REQUIRED
REF01
128

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
Original Reference Number Used to convey the CDT-3 code.
1000195
74
MAY 2004
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
X1
AN
1/50
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 DEFINITION
ID
2/3
YJ
Revenue Source Used to convey the Revenue Code reported in the 837 or the 277.
1000175
MAY 2004
75
REQUIRED
REF04 - 2
127
AN
1/50
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

004050X151 275 2100A DTP SERVICE LINE DATE OF SERVICE
DTP
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~

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

M1 ID 2/3
Date Time Period

M1 AN 1/35
ELEMENT SUMMARY
USAGE
NAME
ATTRIBUTES
REQUIRED
DTP01
374
Date/Time Qualifier
INDUSTRY: Date
CODE
M1
ID
3/3
Time Qualifier
DEFINITION
472
Service
MAY 2004
77
REQUIRED
DTP02
1250

SEMANTIC:
M1
ID
2/3
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
Date
78
MAY 2004

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~

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

M1 ID 2/3
Date Time Period

M1 AN 1/35
ELEMENT SUMMARY
USAGE
NAME
ATTRIBUTES
REQUIRED
DTP01
374
Date/Time Qualifier
INDUSTRY: Date
CODE
M1
ID
3/3
Time Qualifier
DEFINITION
368
Submittal Date information is submitted.
1000179
REQUIRED DTP02 1250

SEMANTIC:
M1
ID
2/3
DEFINITION
CODE
D8 REQUIRED DTP03 1251
Date Expressed in Format CCYYMMDD M 1 AN 1/35
Date Time Period

Information Gathered Date
MAY 2004
79
004050X151 275 2100B CAT CATEGORY OF PATIENT INFORMATION SERVICE

CATEGORY OF PATIENT INFORMATION SERVICE
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

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

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
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
USAGE
NAME
ATTRIBUTES
REQUIRED
BIN01
784

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

TRANSACTION SET TRAILER
004050X151 275 SE 275 TRANSACTION SET TRAILER
SE
275 TRANSACTION SE 004050X151 275 SET TRAILER
IMPLEMENTATION
275 TRANSACTION SET TRAILER

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

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
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
86
MAY 2004
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
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
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
<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
<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
<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
<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
</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
<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
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
<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
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
<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
</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
</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
<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
<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
<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
</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
<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
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
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
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
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
</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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
A.18
MAY 2004
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
B.2
MAY 2004

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

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
USAGE
NAME
ATTRIBUTES
REQUIRED REQUIRED
IEA01 IEA02
I16 I12
Number of Included Functional Groups Interchange Control Number

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

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

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

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
USAGE
NAME
ATTRIBUTES
REQUIRED
TA101
I12
Interchange Control Number

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
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
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
B.14
MAY 2004

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

ST
TRANSACTION SET HEADER 004050X151 997 ST
IMPLEMENTATION

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~

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

O1 AN 1/35
B.16
MAY 2004

USAGE
NAME
ATTRIBUTES
REQUIRED
ST01
143

SEMANTIC:
M1
ID
3/3
CODE DEFINITION
Functional Acknowledgment M 1 AN 4/9
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
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
AK1
004050X151 GROUP RESPONSE HEADER FUNCTIONAL 997 AK1
IMPLEMENTATION
FUNCTIONAL GROUP RESPONSE HEADER

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
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
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
004050X151 997 AK1 FUNCTIONAL GROUP RESPONSE HEADER
SITUATIONAL
AK103
480
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
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

O1 AN 1/35
ELEMENT SUMMARY
USAGE
NAME
ATTRIBUTES
REQUIRED
AK201
143

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
SEMANTIC:
AK202 is the transaction set control number found in the ST segment in the transaction set being acknowledged.
B.20
MAY 2004
004050X151 997 AK2 AK2 TRANSACTION SET RESPONSE HEADER
SITUATIONAL
AK203
1705
Implementation Convention Reference

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
AK3
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
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
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
AK4
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
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
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
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

O1 ID 1/3

O1 ID 1/3

O1 ID 1/3

O1 ID 1/3
ELEMENT SUMMARY
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
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
SITUATIONAL
AK503
718
Transaction Set Syntax Error Code
O1
ID
1/3
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. Transaction Set Syntax Error Code O1 ID 1/3
512
512
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

FUNCTIONAL GROUP RESPONSE TRAILER
004050X151 997 AK9 FUNCTIONAL GROUP RESPONSE TRAILER
AK9
004050X151 GROUP RESPONSE TRAILER FUNCTIONAL 997 AK9
IMPLEMENTATION
FUNCTIONAL GROUP RESPONSE TRAILER

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

SE
TRANSACTION SET TRAILER 004050X151 997 SE
IMPLEMENTATION

516
STANDARD
Example: SE271234~

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
USAGE
NAME
ATTRIBUTES
REQUIRED
SE01
96
M1
N0
1/10
REQUIRED
SE02
329
M 1 AN
4/9
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
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

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

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
A listing of descriptive terms and identifying codes for reporting medical services and procedures performed by physicians.
464
Health Industry Level 7 (HL7)

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

1271
SOURCE

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

66/XX, 128/HPI
SOURCE
National Provider System
C.2
MAY 2004
ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE AVAILABLE FROM
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

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)

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
881

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
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
D.2
MAY 2004
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
Clearinghouse Trace Number

Unique tracking number for the transaction assigned by a clearinghouse.
CODE LIST QUALIFIER 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

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

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

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

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

Code qualifying the reference identification.
H | | REF01 | H | 1000C | REF01 | H | 1000D | REF01 | | 128 .................. 7 | 128 ................ 52 | 128 ................ 57
MAY 2004
E.3

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

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

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
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
F.2
MAY 2004

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

ST
TRANSACTION SET HEADER 004050X151 102 ST
IMPLEMENTATION

9 008 100
Notes:
0 009 100
STANDARD
Example: ST1021234~

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

O1 AN 1/35
ELEMENT SUMMARY
USAGE
NAME
ATTRIBUTES
REQUIRED
ST01
143

SEMANTIC:
M1
ID
3/3
CODE DEFINITION
Associated Data M 1 AN 4/9
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

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

004050X151 102 REF APPLICATION TRANSACTION REFERENCE IDENTIFICATION
REF
APPLICATION TRANSACTION REFERENCE IDENTIFICATION 004050X151 102 REF
IMPLEMENTATION
APPLICATION TRANSACTION REFERENCE IDENTIFICATION

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~

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

M1 ID 2/3
Reference Ident
X1 AN 1/50
Description
X1 AN 1/80
O1
ELEMENT SUMMARY
USAGE
NAME
ATTRIBUTES
REQUIRED
REF01
128

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
REQUIRED
REF02
127
X1
AN
1/50
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

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

BINARY DATA STRUCTURE
004050X151 102 BDS HL7 MESSAGE RESPONSE
BDS
HL7 MESSAGE RESPONSE 004050X151 102 BDS
IMPLEMENTATION
HL7 MESSAGE RESPONSE

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

M1 N0 1/15
M1
Binary Data
B 1/1
ELEMENT SUMMARY
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

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

SE
TRANSACTION SET TRAILER 004050X151 102 SE
IMPLEMENTATION

5 010 100
Notes:
6 010 100
STANDARD
Example: SE71234~

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
USAGE
NAME
ATTRIBUTES
REQUIRED
SE01
96
M1
N0
1/10
REQUIRED
SE02
329
M 1 AN
4/9
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

275 Implementation Guide

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

275 Implementation Guide

Enviado por

Direitos autorais:

Formatos disponíveis

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

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.

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

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

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

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

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

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

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

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

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

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

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

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

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

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

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

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

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

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

1 Purpose and Business Overview

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

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

Trading Partner Agreements

HIPAA Role in Implementation Guides

Version and Release

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

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

Business Use and Definition

Response to a Health Care Claim Request for Additional Information

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

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

Providers Hospitals Specialists PCPs

277 Payers 275(+HL7)

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

Figure 1.1. ANSI Standard EDI Health Care Transaction Flow

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

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

Overall Data Architecture

0100 0150 0175 0500 0500

LX TRN STC REF REF

0600 DTP 0700 CAT

0900 EFI 1000 BIN 1100 SE

Figure 2.1. 275 Transaction Set Listing

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

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

Data Use by Business Use

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

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

Table 1 Transaction Control Information

Transaction Identification and Purpose

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

ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE

Figure 2.2. Table 1 - Header Level

NM1402*ABC INSURANCE COMPANY*****4612345~ PERIC*MEDICAL REVIEW DEPARTMENT~

NM1412*XYZ BILLING SERVICE*****46*X100~

NM11P2ST HOLY HILLS JOSEPH HOSPITAL ****SV*399999~

NM1QC1SMITHJOHN****MI111223333A~ REFEJJS960503LAB~ DTP434RD820030701-20030715~

NM1402*ABC INSURANCE COMPANY*****46*12345~

PERICMEDICAL REVIEW DEPARTMENT~

REFEJJS960503LAB~ REFBLT131~ REFEASTHH12345~ REFD923235~

LX1~ TRN21722634842~ STCR3:18682-5::LOI~ DTP368D820030724~ CATAEHL~ EFI05~