275 implementation guide

National Electronic Data InterchangeTransaction Set Implementation Guide

AdditionalInformation toSupport a HealthCare Claim or Encounter

275ASC X12N 275 (004050X151)

May 2004

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275IMPLEMENTATION GUIDE ADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER

MAY 2004 1

© 2004 WPCCopyright for the members of ASC X12N by Washington Publishing Company.

.

Contact Washington Publishing Company for more Information.

www.wpc-edi.com

Third Printing

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 copyrightedmaterial from Health Level Seven, Inc. Please consult www.HL7.org for additional information.

004050X151 • 275 ASC X12N • INSURANCE SUBCOMMITTEEADDTL INFO TO SUPPORT A HEALTH CARE CLAIM OR ENCOUNTER IMPLEMENTATION GUIDE

2 MAY 2004

Table of Contents1 Purpose and Business Overview .................................... 7

1.1 Document Purpose........................................................................... 71.1.1 Trading Partner Agreements ................................................... 81.1.2 HIPAA Role in Implementation Guides .................................. 8

1.2 Version and Release ....................................................................... 8

1.3 Business Use and Definition........................................................ 91.3.1 Response to a Health Care Claim Request for

Additional Information............................................................. 91.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 .......................................................... 122.2.1 Table 1 Transaction Control Information ............................. 13

2.2.1.1 Transaction Identification and Purpose .................. 132.2.1.2 NM1 Loop Participants Identification Structure ...... 14

2.2.2 Table 2 Detail Information ..................................................... 172.2.2.1 Claim Level Additional Information ......................... 172.2.2.2 Revenue or Service Line Level Additional

Information.............................................................. 20

2.3 Interaction with Other Transaction Sets................................ 232.3.1 Request for Additional Information (277) ............................ 242.3.2 The Claim (837) ...................................................................... 242.3.3 The Functional Acknowledgment (997) ............................... 242.3.4 Associated Data (102)............................................................ 24

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

3.1 Presentation Examples................................................................. 25

3.2 Implementation Usage .................................................................. 303.2.1 Industry Usage ....................................................................... 303.2.2 Loops ...................................................................................... 30

3.3 Transaction Set Listing................................................................. 313.3.1 Implementation ...................................................................... 313.3.2 X12 Standard .......................................................................... 33

3.4 275 Segment Detail......................................................................... 36ST 275 Transaction Header ......................................... 37

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


MAY 2004 3

REF Provider Secondary Identification........................... 52NM1 Patient Name.......................................................... 54REF Patient Account Number......................................... 57REF Institutional Type of Bill ........................................... 59REF Medical Record Number......................................... 61REF Claim Identification Number for Clearing

Houses and Other Transmission Intermediaries..... 62DTP Institutional Claim Service Date.............................. 64

LX Assigned Number ................................................... 65TRN Payer’s Control Number/Provider’s Control

Number................................................................... 66STC Status Information .................................................. 68REF Service Line Item Identification............................... 72REF Procedure or Revenue Code.................................. 74DTP Service Line Date of Service .................................. 77DTP Date Additional Information Was Submitted ........... 79CAT Category of Patient Information Service................. 80EFI Electronic Format Identification .............................. 82BIN Binary Data Segment ............................................. 84SE 275 Transaction Set Trailer..................................... 85

4 EDI Transmission Examples for BusinessUsages .............................................................................................. 87

A Nomenclature..............................................................................A.1

A.1 ASC X12 Nomenclature ...............................................................A.1A.1.1 Interchange and Application Control Structures ...............A.1

A.1.1.1 Interchange Control Structure ...............................A.1A.1.1.2 Application Control Structure Definitions and

Concepts ...............................................................A.2A.1.1.3 Business Transaction Structure Definitions and

Concepts ...............................................................A.5A.1.1.4 Envelopes and Control Structures.......................A.13A.1.1.5 Acknowledgments ...............................................A.15

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

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

B.1 Control Segments ..........................................................................B.1ISA Interchange Control Header.................................................B.3IEA Interchange Control Trailer ..................................................B.7GS Functional Group Header .....................................................B.8GE Functional Group Trailer ....................................................B.10

TA1 Interchange Acknowledgment ........................................... B.11

B.2 Functional Acknowledgment Transaction Set, 997 .......B.15ST Transaction Set Header ......................................................B.16

AK1 Functional Group Response Header.................................B.18AK2 Transaction Set Response Header ....................................B.19AK3 Data Segment Note .............................................................B.20AK4 Data Element Note ..............................................................B.22AK5 Transaction Set Response Trailer .....................................B.24


4 MAY 2004

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

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

77 X12 Directories ......................................................................C.1121 Health Industry Number .......................................................C.1133 Current Procedural Terminology (CPT) Codes ..................C.1464 Health Industry Level 7 (HL7) ..............................................C.2507 Health Care Claim Status Category Code...........................C.2537 Centers for Medicare and Medicaid Services National

Provider Identifier .................................................................C.2540 Centers for Medicare and Medicaid Services PlanID ........C.3663 Logical Observation Identifier Names and Codes

(LOINC) ..................................................................................C.3881 Version / Release / Industry Identifier Code .......................C.4

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 5


6 MAY 2004

1 Purpose and BusinessOverview

1.1 Document PurposeFor the health care industry to achieve the potential administrative cost savingsassociated with Electronic Data Interchange (EDI), standards have been devel-oped and need to be implemented consistently by all organizations. To facilitate asmooth transition into the EDI environment, uniform implementation is critical.

The purpose of this implementation guide is to provide standardized data require-ments 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 tosend additional information about a claim or encounter. This implementationguide provides a detailed explanation of the transaction set by defining uniformdata content, identifying valid code tables, and specifying values applicable forthe business use of conveying Additional Information to Support a HealthCare Claim or Encounter (275). The intention of the developers of the 275 isrepresented in the guide.

This implementation guide describes a solution that includes the encapsulation ofa Health Level Seven (HL7) Standard within the 275 transaction. HL7 is an ANSIAccredited Standards Development Organization (SDO) whose domain is clinicaland administrative data. HL7’s mission is: “To provide standards for the ex-change, management and integration of data that supports clinical patient careand the management, delivery and evalution of healthcare services. Specifically,to create flexible, cost effective approaches, standards, guidelines, methodolo-gies, and related services for interoperability between healthcare information sys-tems”.

HL7 is widely used in the United States as well as many other countries. For thepurpose of this recommendation, the HL7 ANSI approved standard being pro-posed is the Clinical Document Architecture (CDA), as tailored for Claims Attach-ments. CDA is a standard that expresses data using Extensible Markup Lan-guage (XML).

This implementation guide is designed to assist those who send additional sup-porting information or who receive additional supporting information to a claim orencounter 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 organiza-tions, state and federal agencies and their contractors, plan purchasers, and anyother entity that processes health care claims, manages the delivery of healthcare services, or collects health care data. Other business partners affiliated withthe 275 include but are not limited to billing services; consulting services, vendorsof systems, software and EDI translators, and EDI network intermediaries suchas Automated Clearing Houses (ACHs), Value Added Networks (VANs), and tele-communications services.


MAY 2004 7

1.1.1 Trading Partner AgreementsIt is appropriate and prudent for payers to have trading partner agreements thatgo with the standard Implementation Guides. This is because there are 2 levelsof scrutiny that all electronic transactions must go through.

First is standards compliance. These requirements MUST be completely de-scribed in the Implementation Guides for the standards, and NOT modified byspecific trading partners.

Second is the specific processing, or adjudication, of the transactions in eachtrading partner’s individual system. Since this will vary from site to site (e.g.,payer to payer), additional documentation which gives information regarding theprocessing, or adjudication, will prove helpful to each site’s 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 thestandard 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 clari-fication, and should not be required for acceptance of a transaction as valid.

1.1.2 HIPAA Role in Implementation GuidesAdministrative Simplification provisions of the Health Insurance Portability andAccountability Act of 1996 (PL 104-191 - known as HIPAA) direct the Secretary ofHealth and Human Services to adopt standards for transactions to enable healthinformation to be exchanged electronically and to adopt specifications for imple-menting each standard.

This implementation guide has been developed for use as an insurance industryimplementation guide. At the time of publication it has not been adopted as aHIPAA standard. Should the Secretary adopt this implementation guide as astandard, the Secretary will establish compliance dates for its use by HIPAA cov-ered entities.

1.2 Version and ReleaseThis implementation guide is based on the October, 2001 ASC X12 standards, re-ferred to as Version 4, Release 5 (004050).

This implementation guide will incorporate the use of the ANSI accreditedStandard Development Organization (SDO) HL7 Clinical Document Architecture(CDA) in the Binary Data Segment (BIN) within the 275 transaction.


8 MAY 2004

1.3 Business Use and DefinitionThe ASC X12N 275 Patient Information transaction set is intended to meet theparticular needs of the health care industry. The ASC X12N 275 Additional Infor-mation to Support a Healthcare Claim or Encounter is used to:

• Respond to an ASC X12N 277 Health Care Claim Request for Additional Infor-mation or a paper request for additional information.

• Provide unsolicited additional information to support an ASC X12N 837 HealthCare Claim or Encounter sent within the same transmission.

Other intended uses of the 275 transaction set includes the request and re-sponse of patient information from provider to provider and to provide unsolicitedadditional information to support an X12N 837 Health Care Claim or Encounter insupport of statistical reporting and regulatory requirements. These uses are notsupported by this Implementation Guide. This Implementation Guide was not writ-ten with the intent to send attachment data from payer to payer.

1.3.1 Response to a Health Care Claim Request forAdditional InformationTypically, a claim that is subjected to Medical or Utilization review during the adju-dication process is suspended by the payer. The payer then requests specific in-formation to supplement or support the providers request for payment of the serv-ices. The payer’s request for additional information may be service specific or ap-ply to the entire claim, the 277 is used to transmit the request. The provider usesthe 275 to respond to the previously mentioned request.

The 277 structure allows the payer to request additional information on multipleclaims. However, the 275 transaction structure only allows the submitter to sendadditional information for one claim in each 275. A separate Transaction SetHeader/Trailer (ST/SE) must be sent for each claim response. The 275 can ac-commodate multiple responses for a specific claim. See the LX segment sectionfor additional details.

In the 277, the payer must specify the period of time in which the provider has torespond to the request for additional information. The 275 response must be re-ceived by the payer within the specified timeframe, or the claim in question willproceed to the next phase of the payer’s adjudication cycle. The ultimate disposi-tion of the claim or service line can include, but is not limited to, rejection, or de-nial.

1.3.2 Unsolicited Additional Information to Supportan 837 Health Care Claim sent within the sametransmissionIn situations where specific additional information is required by the payer to com-plete the adjudication process, and the provider is aware of the need for this addi-tional information at the time of billing, they may include a 275 within the same in-terchange (ISA/IEA) of the initial 837. This situation will require separate GS/GEFunctional Groups for the 837 and the 275. This eliminates the need for thepayer 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 9

used as the main matching criteria. This value must be unique for each attach-ment.

1.4 Information FlowsFigure 1.1 illustrates the flow of information related to all uses of the 275 Addi-tional Information to Support a Health Care Claim or Encounter.

Arrow 1Shows that claims can be transmitted in either of two methods, with or without anattachment.

837 - Standalone Claimor837+275 (+ HL7) - Claim plus attachment information with HL7 embedded inthe 275, sent in the same transmission (ISA/IEA) as the claim. SeparateGS/GE Functional Groups will be required.

Arrow 2Some claims will require additional information to be sent to the payer before theadjudication cycle can be completed. If that information was not sent with theclaim, the request for additional information will be made by the payer.

Arrow 3The provider will respond to the request for additional information by sending the275 transaction set to the payer. This transaction will contain the Additional Infor-mation to Support a Health Care Claim or Encounter, which will be expressed asHL7.

Arrow 4The Health Care Claim Remittance (835) Transaction Set is sent to the providerwhen the claim has completed the adjudication process.

ProvidersHospitals

SpecialistsPCPs

Payers

275(+HL7)

277

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

837837+275(+HL7)

835

Figure 1.1. ANSI Standard EDI Health Care Transaction Flow


10 MAY 2004

2 Data OverviewThis section introduces the structure of the 275 and describes the positioning ofthe business data within that structure. Familiarity with ASC X12 nomenclature,segments, data elements, hierarchical levels, and looping structures is recom-mended. For a review, see Appendix A, ASC X12 Nomenclature, and AppendixB, EDI Control Directory.

2.1 Overall Data ArchitectureTwo formats or views are used to present the transaction set: the implementationview and the standard view. Figure 2.1, 275 Transaction Set Listing, shows the

Table 1 - HeaderPOS. # SEG. ID NAME USAGE REPEAT LOOP REPEAT

0100 ST 275 Transaction Header R 10200 BGN Beginning Segment R 1

LOOP ID - 1000A TRANSACTION RECEIVER 1 0500 NM1 Transaction Receiver R 10900 PER Response Contact S 1

LOOP ID - 1000B SUBMITTER INFORMATION 1 0500 NM1 Submitter Information R 1

LOOP ID - 1000C SERVICE PROVIDER INFORMATION 1 0500 NM1 Service Provider Information R 11000 REF Provider Secondary Information S 5

LOOP ID - 1000D PATIENT NAME 1 0500 NM1 Patient Name R 11000 REF Patient Account Number R 11000 REF Institutional Type of Bill S 11000 REF Medical Record Number S 11000 REF Claim Identification Number for Clearing Houses and

Other Transmission IntermediariesS 1

1050 DTP Institutional Claim Service Date S 1

Table 2 - DetailPOS. # SEG. ID NAME USAGE REPEAT LOOP REPEAT

LOOP ID - 2000A ASSIGNED NUMBER >1 0100 LX Assigned Number R 10150 TRN Payer’s Control Number/Provider’s Control Number R 10175 STC Status Information S 10500 REF Service Line Item Identification S 10500 REF Procedure or Revenue Code S 1

LOOP ID - 2100A SERVICE LINE DATE OF SERVICE 1 0600 DTP Service Line Date of Service S 1

LOOP ID - 2100B DATE ADDITIONAL INFORMATIONWAS SUBMITTED

1

0600 DTP Date Additional Information Was Submitted R 10700 CAT Category of Patient Information Service R 1

LOOP ID - 2110B ELECTRONIC FORMATIDENTIFICATION

1

0900 EFI Electronic Format Identification R 11000 BIN Binary Data R 11100 SE 275 Transaction Set Trailer R 1

Figure 2.1. 275 Transaction Set Listing


MAY 2004 11

implementation view. This view displays only the segments and their designatedhealth care names described in this implementation guide. The intent of the imple-mentation view is to clarify the purpose and use of the segments by restrictingthe view to display only those segments used with their assigned health carenames. This implementation view is also repeated in Section 3.

The standard view is presented in Section 3, Transaction Set. The standard viewdisplays all segments available within the transaction set with their assigned ASCX12 names.

2.2 Data Use by Business UseThe 275 is divided into two tables. Table 1 contains transaction control informa-tion and is presented in 2.2.1. Table 2 contains the detail information for the busi-ness function of the transaction and is presented in 2.2.2.

When a request for additional information is made, the payer supplies the pa-rameters that assist the provider in locating the claim. These parameters are fre-quently the patient account number, type of bill, medical record number, proce-dure code or revenue code, and the date of service. The provider is the source ofthis information. If the information is found on the original billed claim, the payerreturns these data elements in the ASC X12N 277 Health Care Claim Requestfor Additional Information.

When the additional information is returned in the 275, it will either be related tothe entire claim or for a specific revenue line or service line. The segments usedto return the requested information are more clearly identified by specifyingwhether 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, ifsent 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 ClaimLevel information.

Loop ID Segment ID Segment Name Business Purpose

1000D Patient Name NM1 Patient Name Name of Patient

REF Patient Account Number Provider’s Patient Account Number

REF Institutional Type Of Bill Institutional Type of Bill

REF Medical Record Number Medical Record number from the original claim

REF Claim Identification Numberfor Clearing Houses andOther TransmissionIntermediaries

A claim identification number for Clearing Houses andOther Transmission Intermediaries.

DTP Institutional Claim ServiceDate

Institutional Claim Service Date

2000A Assigned Number LX Assigned Number A sequence number that starts at 1 and is incremented by1 when the loop is repeated.

TRN Payer’s Control Number/Provider’s Control Number

Control Number assigned by either the Payer or Provider.

STC Status Information Echo back the STC segment that was given in the 277

2100B Date AdditionalInformation Submitted

DTP Date Additional InformationWas Submitted

The 275 Submittal Date. Needed in order to use the BINSegment

CAT Category of PatientInformation Service

Used to identify the type of information that will be in theBIN

2110B Electronic FormatIdentification

EFI Electronic FormatIdentification

Security Level of Data. Needed in order to use BINSegment

BIN Binary Data Data in HL7 standard


12 MAY 2004

The following table presents the developers’ view of segments returned for Serv-ice Line Level information.

Loop ID Segment ID Segment Name Business Purpose

1000D Patient Name NM1 Patient Name Name of Patient

REF Patient Account Number Provider’s Patient Account Number

REF Institutional Type Of Bill Institutional Type of Bill

REF Medical Record Number Medical Record number from the original claim

REF Claim Identification Numberfor Clearing Houses andOther TransmissionIntermediaries

A claim identification number for Clearing Houses andOther Transmission Intermediaries.

DTP Institutional Claim ServiceDate

Institutional Claim Service Date

2000A Assigned Number LX Assigned Number A sequence number that starts at 1 and is incremented by1 when the loop is repeated.

TRN Payer’s Control Number/Provider’s Control Number

Control Number assigned by either the Payer or Provider.

STC Claim Status Information Echo back the STC segment that was given in the 277

REF Service Line ItemIdentification

Line Item control number

REF Procedure or Revenue Code Specific Revenue Code or Procedure Code that additionalinformation supports

2100A Service Line Date of Service

DTP Service Line Date of Service Service Line Date of Service

2100B Date Additional Infor-mation Submitted

DTP Date Additional InformationWas Submitted

The 275 Submittal Date. Needed in order to use the BINSegment

CAT Category of PatientInformation Service

Used to identify the type of information that will be in theBIN

2110B Electronic FormatIdentification

EFI Electronic FormatIdentification

Security Level of Data. Needed in order to use BINSegment

BIN Binary Data Data in HL7 standard

2.2.1 Table 1 Transaction Control InformationTable 1 is named the Header Level. The purpose of Table 1 is to identify the trans-action, distinguish the business purpose, and identify the participants. See Figure2.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 using275 as the data value for the transaction set identifier code data element, ST01.The originator of the transaction set assigns the unique control number ST02which is shown here as 0001. In this example, the originator is the provider. ST03carries the same value that is populated in GS08 which is the ImplementationVersion Identifier. For the 275 transaction this is 004050X151.

The 275 transaction structure only allows the submitter to send additional infor-mation 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 TransactionSet Purpose Code value of “11" in the BGN01 indicates that this 275 is a re-sponse to a 277 Health Care Claim Request for Additional Information. Avalue of ”02" indicates that this 275 is additional information for an 837 claim orencounter in the same transmission. The originator of the transaction set assigns


MAY 2004 13

the unique reference number in BGN02 and the date of creation in BGN03. TheFunctional Group Header Segment (GS) provides additional identification of thebusiness purpose of multi-functional transaction sets. See Appendix B, EDI Con-trol 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 aHealth Care Claim or Encounter follows. See Appendix A, ASC X12 Nomencla-ture, for descriptions of data element separators (e.g., *) and segment termina-tors (e.g., ~). See the HL7 documents for XML tag names to be used in the BINsegment.

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 transac-tion. 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 thesubsequent loops within the transaction set and refers to these participants, re-spectively, in the following order and terms:

• Transaction Receiver - This entity is the decision maker in the business transac-tion. For this business use, this entity is the payer, even when the transaction issent 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 bu-reau, an employer, etc.

• Provider -This entity delivered the health care service.

Table 1 - HeaderPOS. # SEG. ID NAME USAGE REPEAT LOOP REPEAT

0100 ST 275 Transaction Header R 10200 BGN Beginning Segment R 1

LOOP ID - 1000A TRANSACTION RECEIVER 1 0500 NM1 Transaction Receiver R 10900 PER Response Contact S 1

LOOP ID - 1000B SUBMITTER INFORMATION 1 0500 NM1 Submitter Information R 1

LOOP ID - 1000C PROVIDER INFORMATION 1 0500 NM1 Provider Information R 11000 REF Provider Secondary Information S 5

LOOP ID - 1000D PATIENT NAME 1 0500 NM1 Patient Name R 11000 REF Patient Account Number R 11000 REF Institutional Type of Bill S 11000 REF Medical Record Number S 11000 REF Claim Identification Number for Clearing Houses and


1050 DTP Institutional Claim Service Date S 1

Figure 2.2. Table 1 - Header Level


14 MAY 2004

• Patient - This is the person who received the services. The additional informa-tion 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 partici-pants and their relationships is presented here. The segments and data ele-ments are found in the 1000 Loop and the 2000 Loop. The coding examples arepresented sequentially as found within an actual transaction set; however, forreading 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 = 40This value indicates that the participant is a receiver.

NM102 = 2This value indicates that the entity is a nonperson. An entity that is a person isidentified with a value of “1”. When the entity is a person, NM103 and NM104contain the last and first names, respectively.

NM103 = ABC INSURANCE COMPANYThis value identifies the Information Source as “ABC INSURANCE COMPANY”.

NM108 = 46This value identifies the next data element as the assigned Payer Identification.

NM109 = 12345The 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 commu-nications 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 additionalinformation from the provider.

The following example demonstrates the identification of the entity to whom theprovider should return the additional information:

PER*IC*MEDICAL REVIEW DEPARTMENT~Within the PER,

PER01 = ICThis value indicates that the person or group named is the Information Contact.

PER02 = MEDICAL REVIEW DEPARTMENTThis 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 Patient1000D loop level for this implementation. The provider’s patient account number,the institutional Type of Bill, the Medical Record Number and the Claim Identifica-tion 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 = EJThis value indicates that the next data element contains the Patient AccountNumber.

REF02 = JS960503LABThe value shown is the actual Patient Account Number assigned by the providerfor 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 clearinghouses 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 occur-rence specifies the Claim Statement Period as supplied by the claim originatorand is only required for institutional claims. The dates must be returned by theprovider 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 = 434This value indicates Statement Period Date. This means that the data element foundin DTP03 represents the statement from and through dates for the claim.

DTP02 = RD8This value indicates that the next data element, DTP03, is a range of dates ex-pressed in the format CCYYMMDD-CCYYMMDD.

DTP03 = 20030705-20030715This represents the actual statement from and through Dates found on the origi-nal claim.

2.2.2 Table 2 Detail InformationThe structure used in Table 2 is based on the 2000A loop. The 2000A and it’s sub-ordinate loops (loops 2100A, 2100B, 2110B) specify the additional informationprovided to support a claim or encounter.

Figure 2.3, Table 2 - Detail Level, presents the segments used in Table 2 of the275. These segments define the specific information that can be sent.

2.2.2.1 Claim Level Additional Information

The following is a coding example of the 275 when providing claim level addi-tional information.

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

Table 2 - DetailPOS. # SEG. ID NAME USAGE REPEAT LOOP REPEAT

LOOP ID - 2000A ASSIGNED NUMBER >1 0100 LX Assigned Number R 10150 TRN Payer’s Control Number/Provider’s Control Number R 10175 STC Status Information S 10500 REF Service Line Item Identification S 10500 REF Procedure or Revenue Code S 1

LOOP ID - 2100A SERVICE LINE DATE OF SERVICE 1 0600 DTP Service Line Date of Service S 1


1

0600 DTP Date Additional Information Was Submitted R 10700 CAT Category of Patient Information Service R 1


1

0900 EFI Electronic Format Identification R 11000 BIN Binary Data Segment R 11100 SE 275 Transaction Set Trailer R 1

Figure 2.3. Table 2 - Detail Level


MAY 2004 17

BIN*10*XXXXXXXXXX~

LX Segment

The LX segment begins the detailed additional information that is being sent tothe payer. The occurrence is 1 or more. The LX loop will begin each time the sub-mitter is starting another response to a different STC or sending another type ofadditional 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 ofsegments that follow. The LX01 sequence number must start at 1 and incrementby 1.

NOTE:Each 275 must only reference one claim. However, the LX loop allows for multi-ple attachments to any one claim.

TRN Segment

The Trace Segment (TRN) is a required segment. The 2000A TRN segment con-tains either the payers or the providers control number. In the unsolicited 275transaction, the TRN segment will contain the providers control number to link the275 attachment data to the 837 claim or encounter. In the solicited 275, the TRNsegment will contain the payers control number that was originally sent in the2200D loop TRN segment of the 277.

The following is a coding example of the TRN segment:

TRN*2*1722634842~TRN01 = 2The value in TRN01 will be “2” when this transaction is a response to a 277.

TRN02 = 1722634842The value shown is the payers control number that was given in the 2200D or2200E loop TRN segment of the 277. This value must be returned in the TRNsegment 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 sametransmission, the originator of the transaction will place the Attachment ControlNumber that was given in the PWK segment of the 837 claim or encounter inTRN02 of the 275.

STC Segment

The purpose of the STC segment in loop 2000A is for the provider to return theLogical Observation Identifier Names and Codes (LOINC) Code List code thatidentifies the payers question from the STC segment of the 277. For further de-tails, 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 levelof the 277 is populated with this value it indicates that the request for informationis conveyed at the service line level STC. Esentially it “points” you to the serviceline level to identify the request.


18 MAY 2004

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

STC*R3:18682-5::LOI~Within the STC,

STC01-1 = R3This value indicates that the claim has been suspended for additional informa-tion/documentation.

STC01-2 = 18682-5This LOINC code value indicates ambulance certification.

STC01-4 = LOIThis 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 informa-tion was submitted to the payer. This segment is required in order to use the BINsegment.

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 = 368This value is the date/time qualifier element. When the value is “368”, the datefound in DTP03 is known to be the submitted date.

DTP02 = D8This value is the date/time period format qualifier. When this value is “D8”, the for-mat of the date in DTP03 is known to be CCYYMMDD.

DTP03 = 20030724The 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 re-ported 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 = AEThis value indicates the data in the BIN segment will be an attachment.

CAT02 = HLThe value shown indicates the data within the BIN segment will be in the HL7Standard.

EFI Segment

The EFI segment in the 2110B loop is required. It is used to convey the level ofconfidentiality 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 = 05This 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. Itallows for the use of the HL7 standard in cases where it is not a HIPAA adoptedattachment and requires it in cases where it is a HIPAA adopted standard.

BIN*10*XXXXXXXXXX~Within the BIN,

BIN01 = 10This represents the number of bytes of data that will follow. BIN02 is where theHL7 standard begins and will be ended by the segment delimiter.

NOTE:For complete details on the HL7 documentation for claims attachments, pleasesee the HL7 Additional Information Specification Implementation Guide and theassociated Additional Information Specificiation attachment documents accompa-nying 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 ad-ditional 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*XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX~

LX Segment

The LX segment begins the detailed additional information that is being sent tothe payer. The occurrence is 1 or more. The LX loop will begin each time theprovider is starting another response to a different STC or sending another typeof 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 ofsegments that follow. The LX01 sequence number must start at 1 and incrementby 1.

TRN Segment


20 MAY 2004

The Trace Segment (TRN) is a required segment. The TRN segment serves twopurposes. First, the attachment control number, when transmitted in the unsolic-ited 275 transaction will contain the key information the provider utilizes to extractpatient medical record information or attachment data needed to support theclaim or encounter. The second scenario involves a solicited response to a re-quest for additional information from a payer. In this situation, the attachment con-trol number contains the key in the payer’s system to trace and match the re-sponse to the appropriate request for additional information.

The following is a coding example of the TRN segment:

TRN*2*1722634842~TRN01 = 2The 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 = 1722634842The value shown is the payers control numbers that was given in the 2200D loopTRN segment of the 277. This value must be returned in the TRN segment of the2000A loop in the 275.

When submitting additional information to support an 837 claim within the sametransmission, the originator of the transaction will replicate the Attachment Con-trol 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 theLOINC 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 serv-ice line level:

STC*R3:11504-8::LOI~Within the STC,

STC01-1 = R3This value indicates that the claim has been suspended for additional informa-tion/documentation.

STC01-2 = 11504-8This LOINC code value indicates the description of a surgical procedure.

STC01-4 = LOIThis value indicates the table used for STC01-2 was the Logical ObservationIdentifier Names and Codes (LOINCTM) Code List.

REF Segment at Loop 2000A

The REF segment identifies the specific revenue/service line in question or it canbe used to identify the line item control number. On both institutional and profes-sional claims there could be additional information that is sent for multiple serv-ices.

The following are coding examples of the REF segment: Identifying a specificrevenue/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 = CPTThis value indicates that the next data element contains the procedure code.

REF02 = 44499The value shown is the procedure code that was submitted on the claim in ques-tion. The payer returns the value in the SVC segment of the 277. It is also usedby the provider when submitting additional information to support a claim. Thiselement can be used to match the additional information to a particular reve-nue/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, theDTP segment identifies the date the service was performed and is only usedwhen 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 = 472This value is the date/time qualifier element. When the value is “472", the datefound in DTP03 is known to be the date of service.

DTP02 = D8This value is the date/time period format qualifier. When this value is “D8", the for-mat of the date in DTP03 is known to be CCYYMMDD.

DTP03 = 20030804The date, represented in DTP03, is the date of service, as defined by the priorqualifiers.

DTP Segment - Date Additional Information was Summitted

The DTP segment in the 2100B loop identifies the date the additional informationwas 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 = 368This value is the date/time qualifier element. When the value is “368", the datefound in DTP03 is known to be the submitted date.

DTP02 = D8This value is the date/time period format qualifier. When this value is “D8", the for-mat of the date in DTP03 is known to be CCYYMMDD.

DTP03 = 20030826The date range represented in DTP03 is the submitted date for the additional in-formation reported in the BIN segment.

CAT Segment


22 MAY 2004

The CAT segment in loop 2100B conveys the type of information and the formattype 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 = AEThis value indicates the data in the BIN segment will be an attachment.

CAT02 = HLThe value shown indicates the data within the BIN segment will be in the HL7 for-mat.

EFI Segment

The EFI segment in the 2110B loop is required. It is used to convey the level ofconfidentiality 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 = 05This 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. Itallows for the use of the HL7 standard in cases where it is not a HIPAA adoptedattachment and requires it in cases where it is a HIPAA adopted standard.

BIN*52*XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX~Within the BIN,

BIN01 = 52This represents the number of bytes of data that will follow.

BIN02 is where the HL7 Standard begins and will be ended by the segment de-limiter.

NOTE:For complete details on the HL7 documention on claims attachments, please seethe HL7 Additional Information Specification Implementation Guide and the asso-ciated Additional Information Specification Attachment documents that accom-pany the Implementation Guide.

2.3 Interaction with Other Transaction SetsThis section presents an overview of related ASC X12N transaction sets and dis-cusses their direct or indirect interaction with the 275 Additional Information toSupport 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 theclaim adjudication process. All data elements found on the original bill have their


MAY 2004 23

source from the provider’s billing system. When a claim does not include enoughinformation to complete the payer’s adjudication process, the payer can electroni-cally request the information using the 277 Health Care Claim Request for Addi-tional Information (X150). Data from the original claim is included on the 277 toassist 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 provider’sbilling system. When a claim needs additional information to complete the adjudi-cation process, the provider can send an unsolicited 275 Additional Information toSupport a Health Care Claim or Encounter (X151) within the same Interchangeas the 837.

2.3.3 The Functional Acknowledgment (997)The Functional Acknowledgment (997) transaction is used upon request by oneof 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 toSupport a Health Care Claim or Encounter (275)

• the provider to acknowledge receipt of a Health Care Claim Request for Addi-tional Information (277)

• the payer to acknowledge the receipt of an Additional Information to Sup-port 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 canbe requested by one of the trading partners. This transaction set is used to ac-knowledge (accept/reject) the HL7 standard in the 275 BIN segment. This trans-action is based on mutual agreement between trading partners, unless mandatedunder HIPAA. If not mandated the authors strongly suggest the use of the 102Transaction.


24 MAY 2004

3 Transaction SetNOTESee Appendix A, Nomenclature, to review the transaction set structure, includingdescriptions of segments, data elements, levels, and loops.

3.1 Presentation ExamplesThe ASC X12 standards are generic. For example, multiple trading communitiesuse the same PER segment to specify administrative communication contacts.Each community decides which elements to use and which code values in thoseelements are applicable.

This implementation guide uses a format that depicts both the generalized stand-ard and the insurance industry-specific implementation. In this implementationguide, 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 subsec-tions within the main sections:

3.3 Transaction Set Listing

There are two sub-sections under this general title. The first sub-sectionconcerns 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 thisimplementation. It also serves as an index to the segment detail.

STANDARD

This section is included as a reference. The implementation guidereference 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 forthis 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 im-plementation guide, describe the format of the transaction set that follows.


26 MAY 2004

IMPLEMENTATION

800 Insurance Transaction Set

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

53 010 ST Transaction Set Header R 154 020 BPR Financial Information R 160 040 TRN Reassociation Key R 162 050 CUR Non-US Dollars Currency S 165 060 REF Receiver ID S 166 060 REF Version Number S 168 070 DTM Production Date S 1

PAYER NAME 1 70 080 N1 Payer Name R 172 100 N3 Payer Address S 175 110 N4 Payer City, State, Zip S 176 120 REF Additional Payer Reference Number S 178 130 PER Payer Contact S 1

PAYEE NAME 1 79 080 N1 Payee Name R 181 100 N3 Payee Address S 182 110 N4 Payee City, State, Zip S 184 120 REF Payee Additional Reference Number S >1

Each segment is assigned anindustry specific name. Notused segments do not appear

Each loop is assigned anindustry specific name

Indicates thatthis section isthe implementationand not the standard

Segmentrepeats andloop repeatsreflect actualusage

R=RequiredS=Situational

Individual segments and entire loops are repeated Position Numbers and Segment IDs retain their X12 values

Figure 1. Transaction Set Key — Implementation

STANDARD

800 Insurance Transaction SetFunctional Group ID: XX

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

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

010 ST Transaction Set Header M 1020 BPR Beginning Segment M 1030 NTE Note/Special Instruction O >1040 TRN Trace O 1

Indicates thatthis section is identicalto the ASC X12 standard

See Appendix A, ASCX12 Nomenclature for acomplete description ofthe standard

Figure 2. Transaction Set Key — Standard


MAY 2004 27

IMPLEMENTATION

PAYER NAMELoop: 1000A — PAYER IDENTIFICATION Repeat: 1

Usage: SITUATIONAL

Repeat: 1

Loop OD: 800_A1_1000A

Segment OD: 800_A1_1000A_N1

Advisory: Under most circumstances, this segment is expected to be sent.

Notes: 1. This N1 loop provides the name/address information for the payer. Thepayer’s secondary identifying reference number should be provided inN104, if necessary.

Example: N1✽ PR✽ INSURANCE COMPANY OF TIMBUCKTU✽ NI✽ 88888888~

IndustryUsage

IndustrySegmentRepeat

Industry assigned Loop ID and Loop Name

Industry assigned Segment Name

Industry Loop Repeat

Example

Industry Notes

Object Descriptors, see Appendix A.2for additional information

Figure 3. Segment Key — Implementation

STANDARD

N1 NameLevel: Header

Position: 080

Loop: N1 Repeat: 200

Requirement: Optional

Max Use: 1

Purpose: To identify a party by type of organization, name and code

Syntax: 1 R0203At least one of N102 or N103 is required.

2 P0304If either N103 or N104 is present, then the other is required.

X12 Syntax Notes

X12 ID and Name

X12 Level

X12 Position Number

X12 Loop Information

X12 Requirement

X12 Maximum Use

Figure 4. Segment Key — Standard

DIAGRAM

N101 98 N102 93 N103 66 N104 67 N105 706 N106 98

N1 ✽ Entity IDCode

✽ Name ✽ ID CodeQualifier

✽ IDCode

✽ EntityRelat Code

✽ Entity IDCode

~

M 1 ID 2/2 X 1 AN 1/35 X 1 ID 1/2 X 1 AN 2/20 O 1 ID 2/2 O 1 ID 2/2

Segment ID

RequirementDesignator

Minimum/Maximum Length

Indicates aRequired Element

Indicates a NotUsed Element

ElementDelimiter

AbbreviatedElement Name

DataType

SegmentTerminator

ElementRepeat

Indicates aSituational Element

Figure 5. Segment Key — Diagram


28 MAY 2004

ELEMENT SUMMARY

USAGEREF.DES.

DATAELEMENT NAME ATTRIBUTES

SITUATIONAL EQ01 1365 Service Type Code X 99 ID 2/3Code identifying the classification of service

OD: 270A1_2110C_EQ01__ServiceType Code

SYNTAX: R0102

SEMANTIC: Position of data in the repeating data element conveys nosignificance.

90147 Not used if EQ02 is used.

CODE DEFINITION

1 Medical Care

2 SurgicalSITUATIONAL EQ02 C003 COMPOSITE MEDICAL PROCEDURE

IDENTIFIERX 1

To identify a medical procedure by its standardized codes andapplicable modifiers

OD: 270A1_2110C_EQ02_C003

90147 Not used if EQ01 is used.REQUIRED EQ02 - 1 235 Product/Service ID Qualifier M ID 2/2

Code identifying the type/source of the descriptive numberused in Product/Service ID (234)

OD: 270A1_2110C_EQ02_C00301_ProductServiceIDQualifier

INDUSTRY: Product or Service ID Qualifier

ALIAS: Procedure Code Qualifier

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

AD American Dental Association CodesCODE SOURCE 135: American Dental Association Codes

CJ Current Procedural Terminology (CPT) CodesCODE SOURCE 133: Current Procedural Terminology (CPT)Codes

Selected Code Values

Industry Note

Industry Usages:See the followingpage for completedescriptions

Data ElementNumber Element Repeat

Object Descriptor, seeAppendix A.2 foradditional information

X12 Syntax Note

X12 Semantic Note

Reference Designator

Composite Number

See Appendix C forexternal code sourcereference

Industry NameSee Appendix E fordefinition

Alias Name

Figure 6. Segment Key — Element Summary


MAY 2004 29

3.2 Implementation Usage

3.2.1 Industry UsageIndustry Usage describes when loops, segments, and elements are to be sent.The three choices for Usage are required, not used, and situational. To avoid con-fusion, these are named differently than the X12 standard Condition Designators(mandatory, optional, and relational).

Required this loop/segment/element must always be sent when complyingwith this implementation guide.

Not Used this loop/segment/element must never be sent when complyingwith this implementation guide.

Situational use of this loop/segment/element varies, depending on data con-tent and business context as described in the defining rule. Thedefining rule is documented in a note attached to the item. Theitem is required when the situation defined in the note is true; oth-erwise the item is not used.

3.2.2 LoopsLoop usage within ASC X12 transactions and their implementation guides can beconfusing. Care must be used to read the loop requirements in terms of the con-text or location within the transaction.

• A nested loop can be used only when the associated higher level loop isused.

• The usage of a loop is the same as the usage of its beginning segment.

If a loop’s beginning segment is Required, the loop is Required and must oc-cur at least once unless it is nested in a loop that is not being used.

If a loop’s beginning segment is Situational, the loop is Situational.

• Subsequent segments within a loop can be sent only when the beginningsegment is used.

Required segments in Situational loops occur only when the loop is used.


30 MAY 2004

3.3 Transaction Set Listing

3.3.1 Implementation

This section lists the levels, loops, and segments contained in this implementa-tion. It also serves as an index to the segment detail. Refer to section 3.1 Presen-tation Examples for detailed information on the components of theImplementation section.

ASC X12N • INSURANCE SUBCOMMITTEEIMPLEMENTATION GUIDE

MAY 2004 31

004050X151 • 275

APRIL 28, 2004IMPLEMENTATION

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 0100 ST 275 Transaction Header R 139 0200 BGN Beginning Segment R 1

LOOP ID - 1000A TRANSACTION RECEIVER 1 41 0500 NM1 Transaction Receiver R 143 0900 PER Response Contact S 1

LOOP ID - 1000B SUBMITTER INFORMATION 1 46 0500 NM1 Submitter Information R 1

LOOP ID - 1000C SERVICE PROVIDER INFORMATION 1 49 0500 NM1 Service Provider Information R 152 1000 REF Provider Secondary Identification S 5

LOOP ID - 1000D PATIENT NAME 1 54 0500 NM1 Patient Name R 157 1000 REF Patient Account Number R 159 1000 REF Institutional Type of Bill S 161 1000 REF Medical Record Number S 162 1000 REF Claim Identification Number for Clearing Houses and


64 1050 DTP Institutional Claim Service Date S 1

Table 2 - Detail


LOOP ID - 2000A ASSIGNED NUMBER >1 65 0100 LX Assigned Number R 166 0150 TRN Payer’s Control Number/Provider’s Control Number R 168 0175 STC Status Information S 172 0500 REF Service Line Item Identification S 174 0500 REF Procedure or Revenue Code S 1

LOOP ID - 2100A SERVICE LINE DATE OF SERVICE 1 77 0600 DTP Service Line Date of Service S 1


1

79 0600 DTP Date Additional Information Was Submitted R 180 0700 CAT Category of Patient Information Service R 1


1

82 0900 EFI Electronic Format Identification R 184 1000 BIN Binary Data Segment R 185 1100 SE 275 Transaction Set Trailer R 1

ASC X12N • INSURANCE SUBCOMMITTEE004050X151 • 275 IMPLEMENTATION GUIDE

32 MAY 2004

3.3.2 X12 Standard

This section is included as a reference. The implementation guide reference clari-fies actual usage. Refer to section 3.1 Presentation Examples for detailed infor-mation on the components of the X12 Standard section.

ASC X12N • INSURANCE SUBCOMMITTEEIMPLEMENTATION GUIDE 004050X151 • 275

MAY 2004 33

STANDARD

275 Patient InformationFunctional Group ID: PI

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

Table 1 - Header

PAGE # POS. # SEG. ID NAME REQ. DES. MAX USE LOOP REPEAT

0100 ST Transaction Set Header M 10200 BGN Beginning Segment O 10300 DTM Date/Time Reference O 30400 TRN Trace O 5

LOOP ID - NM1 >1 0500 NM1 Individual or Organizational Name O 10600 IN1 Individual Identification O 10700 DMG Demographic Information O 30800 PRV Provider Information O 10900 PER Administrative Communications Contact O 21000 REF Reference Information O 51050 DTP Date or Time or Period O 1

LOOP ID - NM1/NX1 5 1100 NX1 Property or Entity Identification O 11200 N3 Party Location O 11300 N4 Geographic Location O 1

Table 2 - Detail


LOOP ID - LX >1 0100 LX Transaction Set Line Number O 10150 TRN Trace O 10175 STC Status Information O 10200 NM1 Individual or Organizational Name O 10300 PRV Provider Information O 10400 PER Administrative Communications Contact O 10500 REF Reference Information O 5

LOOP ID - LX/DTP >1 0600 DTP Date or Time or Period O 10700 CAT Category of Patient Information Service O 1


34 MAY 2004

0800 PID Product/Item Description O 1

LOOP ID - LX/DTP/EFI 1 0900 EFI Electronic Format Identification O 11000 BIN Binary Data Segment M 11100 SE Transaction Set Trailer M 1

NOTES:

1/0500 Loop NM1 identifies a single patient; it also identifies other entities or individuals which include the requester, responder

or other organizations.

1/0800 The PRV segment is only used in Loop NM1 when identifying a requestor or responder who is also a provider.

2/0150 The TRN segment in Loop LX identifies a previously sent transaction set. The LX loop provides supporting or additional in-

formation for that item when TRN is used.

2/0175 The STC segment in LX loop identifies the status and action requested in a prior transaction when the response is pro-

vided in this transaction.

2/0200 The NM1 segment in loop LX identifies an individual provider within a responder group.


MAY 2004 35

3.4 275 - Segment DetailThis section specifies the segments, data elements, and codes for this implemen-tation. Refer to section 3.1 Presentation Examples for detailed information on thecomponents of the Segment Detail section.


36 MAY 2004

STTRANSACTION SET HEADER 004050X151 • 275 • ST275 TRANSACTION HEADER

IMPLEMENTATION

275 TRANSACTION HEADERUsage: REQUIRED

Repeat: 1

54 Example: ST✽ 275✽ 0001✽ 004050X151~

STANDARD

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 ✽ TS IDCode ✽ TS Control

Number ✽ Imple ConvReference ~

M 1 ID 3/3 M 1 AN 4/9 O 1 AN 1/35

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED ST01 143 Transaction Set Identifier Code M 1 ID 3/3Code uniquely identifying a Transaction Set

SEMANTIC: The transaction set identifier (ST01) is used by the translation routinesof 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 transactionset that will follow the ST segment. Each X12 standard has atransaction set identifier code that is unique to that transaction set.

CODE DEFINITION

275 Patient Information

REQUIRED ST02 329 Transaction Set Control Number M 1 AN 4/9Identifying control number that must be unique within the transaction setfunctional group assigned by the originator for a transaction set

142 The Transaction Set Control Number in ST02 and SE02 must beidentical. This unique number also aids in error resolutionresearch. Submitters could begin sending transactions using thenumber 0001 in this element and increment from there. The numbermust be unique within a specific functional group (GS-GE) andinterchange (ISA-IEA), but can repeat in other groups andinterchanges.

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • STIMPLEMENTATION GUIDE 275 TRANSACTION HEADER

MAY 2004 37

REQUIRED ST03 1705 Implementation Convention Reference O 1 AN 1/35Reference assigned to identify Implementation Convention

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

INDUSTRY: Implementation Convention Reference Identifier

190 004050X151This field contains the same value as GS08. Some translatorproducts strip off the ISA and GS segments prior to application (ST-SE) processing. Providing the information from the GS08 at thislevel will ensure that the appropriate application mapping is utilizedat translation time.

004050X151 • 275 • ST ASC X12N • INSURANCE SUBCOMMITTEE275 TRANSACTION HEADER IMPLEMENTATION GUIDE

38 MAY 2004

BGNBEGINNING SEGMENT 004050X151 • 275 • BGNBEGINNING SEGMENT

IMPLEMENTATION

BEGINNING SEGMENTUsage: REQUIRED

Repeat: 1

55 Example: BGN✽ 11✽ 1✽ 20030701~

STANDARD

BGN Beginning Segment

Level: Header

Position: 0200

Loop: ____


Max Use: 1

Purpose: To indicate the beginning of a transaction set

Syntax: 1. C0504If BGN05 is present, then BGN04 is required.

DIAGRAM

BGN01 353 BGN02 127 BGN03 373 BGN04 337 BGN05 623 BGN06 127

BGN ✽ TS PurposeCode ✽ Reference

Ident ✽ Date ✽ Time ✽ TimeCode ✽ Reference

IdentM 1 ID 2/2 M 1 AN 1/50 M 1 DT 8/8 X 1 TM 4/8 O 1 ID 2/2 O 1 AN 1/50

BGN07 640 BGN08 306 BGN09 786

✽ TransactionType Code

✽ ActionCode

✽ SecurityLevel Code ~

O 1 ID 2/2 O 1 ID 1/2 O 1 ID 2/2

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED BGN01 353 Transaction Set Purpose Code M 1 ID 2/2Code identifying purpose of transaction set

CODE DEFINITION

02 Add

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

11 Response

1000159 Used when submitting Attachment information inresponse to a 277.

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • BGNIMPLEMENTATION GUIDE BEGINNING SEGMENT

MAY 2004 39

REQUIRED BGN02 127 Reference Identification M 1 AN 1/50Reference information as defined for a particular Transaction Set or as specifiedby the Reference Identification Qualifier

SEMANTIC: BGN02 is the transaction set reference number.

INDUSTRY: Transaction Set Reference Number

1000084 The originator of the transaction set assigns the unique referencenumber in BGN02 and the date of creation in BGN03.

REQUIRED BGN03 373 Date M 1 DT 8/8Date expressed as CCYYMMDD where CC represents the first two digits of thecalendar year

SEMANTIC: BGN03 is the transaction set date.

INDUSTRY: Transaction Set Creation Date

NOT USED BGN04 337 Time X 1 TM 4/8

NOT USED BGN05 623 Time Code O 1 ID 2/2

NOT USED BGN06 127 Reference Identification O 1 AN 1/50

NOT USED BGN07 640 Transaction Type Code O 1 ID 2/2

NOT USED BGN08 306 Action Code O 1 ID 1/2

NOT USED BGN09 786 Security Level Code O 1 ID 2/2

004050X151 • 275 • BGN ASC X12N • INSURANCE SUBCOMMITTEEBEGINNING SEGMENT IMPLEMENTATION GUIDE

40 MAY 2004

NM1INDIVIDUAL OR ORGANIZATIONAL NAME 004050X151 • 275 • 1000A • NM1TRANSACTION RECEIVER

IMPLEMENTATION

TRANSACTION RECEIVERLoop: 1000A — TRANSACTION RECEIVER Repeat: 1

Usage: REQUIRED

Repeat: 1

143 Example: NM1✽ 40✽ 2✽ ABC INSURANCE COMPANY✽✽✽✽✽ 46✽ 12345~

STANDARD

NM1 Individual or Organizational Name

Level: Header

Position: 0500

Loop: NM1 Repeat: >1


Max Use: 1

Purpose: To supply the full name of an individual or organizational entity

Set Notes: 1. Loop NM1 identifies a single patient; it also identifies other entities orindividuals which include the requester, responder or other organizations.

Syntax: 1. P0809If either NM108 or NM109 is present, then the other is required.

2. C1110If NM111 is present, then NM110 is required.


DIAGRAM

NM101 98 NM102 1065 NM103 1035 NM104 1036 NM105 1037 NM106 1038

NM1 ✽ Entity IDCode ✽ Entity Type

Qualifier ✽ Name Last/Org Name ✽ Name

First ✽ NameMiddle ✽ Name

PrefixM 1 ID 2/3 M 1 ID 1/1 X 1 AN 1/60 O 1 AN 1/35 O 1 AN 1/25 O 1 AN 1/10

NM107 1039 NM108 66 NM109 67 NM110 706 NM111 98 NM112 1035

✽ NameSuffix ✽ ID Code

Qualifier ✽ IDCode ✽ Entity

Relat Code ✽ Entity IDCode ✽ Name Last/

Org Name ~

O 1 AN 1/10 X 1 ID 1/2 X 1 AN 2/80 X 1 ID 2/2 O 1 ID 2/3 O 1 AN 1/60

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED NM101 98 Entity Identifier Code M 1 ID 2/3Code identifying an organizational entity, a physical location, property or anindividual

CODE DEFINITION

40 Receiver

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 1000A • NM1IMPLEMENTATION GUIDE TRANSACTION RECEIVER

MAY 2004 41

REQUIRED NM102 1065 Entity Type Qualifier M 1 ID 1/1Code qualifying the type of entity

SEMANTIC: NM102 qualifies NM103.

CODE DEFINITION

2 Non-Person Entity

REQUIRED NM103 1035 Name Last or Organization Name X 1 AN 1/60Individual last name or organizational name

SYNTAX: C1203

INDUSTRY: Receiver Name

NOT USED NM104 1036 Name First O 1 AN 1/35

NOT USED NM105 1037 Name Middle O 1 AN 1/25

NOT USED NM106 1038 Name Prefix O 1 AN 1/10

NOT USED NM107 1039 Name Suffix O 1 AN 1/10

REQUIRED NM108 66 Identification Code Qualifier X 1 ID 1/2Code designating the system/method of code structure used for IdentificationCode (67)

SYNTAX: P0809

CODE DEFINITION

46 Electronic Transmitter Identification Number (ETIN)

1000143 Established by Trading Partner Agreement.

XV Health Care Financing Administration PlanIDRequired if the National PlanID is mandated for use.Otherwise, one of the other listed codes may beused.CODE SOURCE 540: Centers for Medicare and Medicaid ServicesPlanID

REQUIRED NM109 67 Identification Code X 1 AN 2/80Code identifying a party or other code

SYNTAX: P0809

INDUSTRY: Receiver Identifier

NOT USED NM110 706 Entity Relationship Code X 1 ID 2/2

NOT USED NM111 98 Entity Identifier Code O 1 ID 2/3

NOT USED NM112 1035 Name Last or Organization Name O 1 AN 1/60

004050X151 • 275 • 1000A • NM1 ASC X12N • INSURANCE SUBCOMMITTEETRANSACTION RECEIVER IMPLEMENTATION GUIDE

42 MAY 2004

PERADMINISTRATIVE COMMUNICATIONS CONTACT 004050X151 • 275 • 1000A • PERRESPONSE CONTACT

IMPLEMENTATION

RESPONSE CONTACTLoop: 1000A — TRANSACTION RECEIVER

Usage: SITUATIONAL

Repeat: 1

1000160 Notes: 1. Required when the value in BGN01 is 11 and the 277 designates aspecific contact for the return of the requested information. This is theperson/department to whom the information must be returned. If notrequired, do not send.

1000204 2. When the communication number represents a telephone number inthe United States and other countries using the North AmericanDialing Plan (for voice, data, fax, etc.), the communication numbershould always include the area code and phone number using theformat AAABBBCCCC. Where AAA is the area code, BBB is thetelephone number prefix, and CCCC is the telephone number (e.g.(534)224-2525 would be represented as 5342242525). The extensionwhen applicable, should be included in the communication numberimmediately after the telephone number.

61 Example: PER✽ IC✽ MEDICAL REVIEW DEPARTMENT~

STANDARD

PER Administrative Communications Contact

Level: Header

Position: 0900

Loop: NM1


Max Use: 2

Purpose: To identify a person or office to whom administrative communications should bedirected

Syntax: 1. P0304If either PER03 or PER04 is present, then the other is required.

2. P0506If either PER05 or PER06 is present, then the other is required.

3. P0708If either PER07 or PER08 is present, then the other is required.

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 1000A • PERIMPLEMENTATION GUIDE RESPONSE CONTACT

MAY 2004 43

DIAGRAM

PER01 366 PER02 93 PER03 365 PER04 364 PER05 365 PER06 364

PER ✽ ContactFunct Code ✽ Name ✽ Comm

Number Qual ✽ CommNumber ✽ Comm

Number Qual ✽ CommNumber

M 1 ID 2/2 O 1 AN 1/60 X 1 ID 2/2 X 1 AN 1/256 X 1 ID 2/2 X 1 AN 1/256

PER07 365 PER08 364 PER09 443

✽ CommNumber Qual ✽ Comm

Number ✽ Contact InqReference ~

X 1 ID 2/2 X 1 AN 1/256 O 1 AN 1/20

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED PER01 366 Contact Function Code M 1 ID 2/2Code identifying the major duty or responsibility of the person or group named

CODE DEFINITION

IC Information Contact

REQUIRED PER02 93 Name O 1 AN 1/60Free-form name

INDUSTRY: Information Receiver Contact Name

1000186 Return information given at the 2100A, 2200D or 2200E loop of the277.

SITUATIONAL PER03 365 Communication Number Qualifier X 1 ID 2/2Code identifying the type of communication number

SYNTAX: P0304

191 Required when the PER segment in the 2100A, 2210D or 2210Eloops of the 277 include the information. If not required, do notsend.

CODE DEFINITION

ED Electronic Data Interchange Access Number

EM Electronic Mail

FX Facsimile

TE Telephone

SITUATIONAL PER04 364 Communication Number X 1 AN 1/256Complete communications number including country or area code whenapplicable

SYNTAX: P0304

INDUSTRY: Information Receiver Contact Communication Number


004050X151 • 275 • 1000A • PER ASC X12N • INSURANCE SUBCOMMITTEERESPONSE CONTACT IMPLEMENTATION GUIDE

44 MAY 2004


SYNTAX: P0506


CODE DEFINITION


EM Electronic Mail

EX Telephone Extension

FX Facsimile

TE Telephone


SYNTAX: P0506




SYNTAX: P0708


CODE DEFINITION


EM Electronic Mail

EX Telephone Extension

FX Facsimile

TE Telephone


SYNTAX: P0708



NOT USED PER09 443 Contact Inquiry Reference O 1 AN 1/20

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 1000A • PERIMPLEMENTATION GUIDE RESPONSE CONTACT

MAY 2004 45

NM1INDIVIDUAL OR ORGANIZATIONAL NAME 004050X151 • 275 • 1000B • NM1SUBMITTER INFORMATION

IMPLEMENTATION

SUBMITTER INFORMATIONLoop: 1000B — SUBMITTER INFORMATION Repeat: 1

Usage: REQUIRED

Repeat: 1

192 Notes: 1. This segment is used to provide the submitter information.

146 Example: NM1✽ 41✽ 2✽ ABC BILLING SERVICE✽✽✽✽✽ 46✽ X100~

STANDARD


Level: Header

Position: 0500



Max Use: 1






DIAGRAM

NM101 98 NM102 1065 NM103 1035 NM104 1036 NM105 1037 NM106 1038

NM1 ✽ Entity IDCode

✽ Entity TypeQualifier

✽ Name Last/Org Name

✽ NameFirst

✽ NameMiddle

✽ NamePrefix

M 1 ID 2/3 M 1 ID 1/1 X 1 AN 1/60 O 1 AN 1/35 O 1 AN 1/25 O 1 AN 1/10

NM107 1039 NM108 66 NM109 67 NM110 706 NM111 98 NM112 1035




Org Name ~


004050X151 • 275 • 1000B • NM1 ASC X12N • INSURANCE SUBCOMMITTEESUBMITTER INFORMATION IMPLEMENTATION GUIDE

46 MAY 2004

ELEMENT SUMMARY

USAGEREF.DES.



CODE DEFINITION

41 Submitter



CODE DEFINITION

1 Person

2 Non-Person Entity


SYNTAX: C1203

INDUSTRY: Submitter Last or Organization Name

SITUATIONAL NM104 1036 Name First O 1 AN 1/35Individual first name

INDUSTRY: Submitter First Name

150 Required when the value in NM102 equals 1 and the person’s firstname is known. If not required, do not send.

SITUATIONAL NM105 1037 Name Middle O 1 AN 1/25Individual middle name or initial

INDUSTRY: Submitter Middle Name

170 Required when the value in NM102 equals 1 and the person’smiddle name/initial is known. If not required, do not send.


NOT USED NM107 1039 Name Suffix O 1 AN 1/10


SYNTAX: P0809

CODE DEFINITION

46 Electronic Transmitter Identification Number (ETIN)


SYNTAX: P0809

INDUSTRY: Submitter Identifier



ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 1000B • NM1IMPLEMENTATION GUIDE SUBMITTER INFORMATION

MAY 2004 47


004050X151 • 275 • 1000B • NM1 ASC X12N • INSURANCE SUBCOMMITTEESUBMITTER INFORMATION IMPLEMENTATION GUIDE

48 MAY 2004

NM1INDIVIDUAL OR ORGANIZATIONAL NAME 004050X151 • 275 • 1000C • NM1SERVICE PROVIDER INFORMATION

IMPLEMENTATION

SERVICE PROVIDER INFORMATIONLoop: 1000C — SERVICE PROVIDER INFORMATION Repeat: 1

Usage: REQUIRED

Repeat: 1

1000161 Example: NM1✽ 1P✽ 2✽ ABC HOSPITAL✽✽✽✽✽ SV✽ 159999~

STANDARD


Level: Header

Position: 0500



Max Use: 1






DIAGRAM

NM101 98 NM102 1065 NM103 1035 NM104 1036 NM105 1037 NM106 1038





NM107 1039 NM108 66 NM109 67 NM110 706 NM111 98 NM112 1035




Org Name ~


ELEMENT SUMMARY

USAGEREF.DES.



CODE DEFINITION

1P Provider

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 1000C • NM1IMPLEMENTATION GUIDE SERVICE PROVIDER INFORMATION

MAY 2004 49



CODE DEFINITION

1 Person

2 Non-Person Entity


SYNTAX: C1203

INDUSTRY: Provider Last or Organization Name


INDUSTRY: Provider First Name

169 Required when the value in NM102 is 1 and the person’s first nameis known. If not required, do not send.


INDUSTRY: Provider Middle Name

151 Required when the value in NM102 is 1 and the person’s middlename/initial is known. If not required, do not send.


SITUATIONAL NM107 1039 Name Suffix O 1 AN 1/10Suffix to individual name

INDUSTRY: Provider Name Suffix

1000162 Required when the value in NM102 is 1 and the Suffix is known. Ifnot required, do not send.


SYNTAX: P0809

CODE DEFINITION

24 Employer’s Identification Number

1000163 Use only when value in BGN01 is 02 and the code isin NM108 of loop 2010AA of the 837.

34 Social Security Number

1000163 Use only when value in BGN01 is 02 and the code isin NM108 of loop 2010AA of the 837.

FI Federal Taxpayer’s Identification Number

SV Service Provider Number

1000164 Use only when the value in BGN01 is 11. Return theprovider number from the 277.

004050X151 • 275 • 1000C • NM1 ASC X12N • INSURANCE SUBCOMMITTEESERVICE PROVIDER INFORMATION IMPLEMENTATION GUIDE

50 MAY 2004

XX Health Care Financing Administration NationalProvider IdentifierRequired value if the National Provider ID ismandated for use. Otherwise, one of the other listedcodes must be used.CODE SOURCE 537: Centers for Medicare and Medicaid ServicesNational Provider Identifier


SYNTAX: P0809

INDUSTRY: Provider Identifier




ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 1000C • NM1IMPLEMENTATION GUIDE SERVICE PROVIDER INFORMATION

MAY 2004 51

REFREFERENCE INFORMATION 004050X151 • 275 • 1000C • REFPROVIDER SECONDARY IDENTIFICATION

IMPLEMENTATION

PROVIDER SECONDARY IDENTIFICATIONLoop: 1000C — SERVICE PROVIDER INFORMATION

Usage: SITUATIONAL

Repeat: 5

1000126 Notes: 1. Required when a secondary Identification number is necessary toidentify the entity. The primary identification number should bereported in NM108/09 in this loop. If not required, may provide atsender’s discretion.

1000127 2. If the reason the number being used in this REF can be met by theNPI, reported in the NM108/09 of this loop, then this REF is not used.

1000144 Example: REF✽ 1C✽ 565656~

STANDARD

REF Reference Information

Level: Header

Position: 1000

Loop: NM1


Max Use: 5

Purpose: To specify identifying information

Syntax: 1. R0203At least one of REF02 or REF03 is required.

DIAGRAM

REF01 128 REF02 127 REF03 352 REF04 C040

REF ✽ ReferenceIdent Qual ✽ Reference

Ident ✽ Description ✽ ReferenceIdentifier ~

M 1 ID 2/3 X 1 AN 1/50 X 1 AN 1/80 O 1

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED REF01 128 Reference Identification Qualifier M 1 ID 2/3Code qualifying the Reference Identification

CODE DEFINITION

0B State License Number

1A Blue Cross Provider Number

1B Blue Shield Provider Number

1C Medicare Provider Number

004050X151 • 275 • 1000C • REF ASC X12N • INSURANCE SUBCOMMITTEEPROVIDER SECONDARY IDENTIFICATION IMPLEMENTATION GUIDE

52 MAY 2004

1D Medicaid Provider Number

1E Dentist License Number

1G Provider UPIN Number

1H CHAMPUS Identification Number

1J Facility ID Number

B3 Preferred Provider Organization Number

BQ Health Maintenance Organization Code Number

EI Employer’s Identification Number

FH Clinic Number

G2 Provider Commercial Number

G5 Provider Site Number

LU Location Number

SY Social Security Number

1000128 The Social Security Number may not be used forMedicare.

TJ Federal Taxpayer’s Identification Number

U3 Unique Supplier Identification Number (USIN)

X5 State Industrial Accident Provider Number

REQUIRED REF02 127 Reference Identification X 1 AN 1/50Reference information as defined for a particular Transaction Set or as specifiedby the Reference Identification Qualifier

SYNTAX: R0203

INDUSTRY: Provider Secondary Identifier

NOT USED REF03 352 Description X 1 AN 1/80

NOT USED REF04 C040 REFERENCE IDENTIFIER O 1

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 1000C • REFIMPLEMENTATION GUIDE PROVIDER SECONDARY IDENTIFICATION

MAY 2004 53

NM1INDIVIDUAL OR ORGANIZATIONAL NAME 004050X151 • 275 • 1000D • NM1PATIENT NAME

IMPLEMENTATION

PATIENT NAMELoop: 1000D — PATIENT NAME Repeat: 1

Usage: REQUIRED

Repeat: 1

1000181 Example: NM1✽ QC✽ 1✽ SMITH✽ JOHN✽ H✽✽✽ MI✽ 987654320~

STANDARD


Level: Header

Position: 0500



Max Use: 1






DIAGRAM

NM101 98 NM102 1065 NM103 1035 NM104 1036 NM105 1037 NM106 1038





NM107 1039 NM108 66 NM109 67 NM110 706 NM111 98 NM112 1035




Org Name ~


ELEMENT SUMMARY

USAGEREF.DES.



CODE DEFINITION

QC Patient

004050X151 • 275 • 1000D • NM1 ASC X12N • INSURANCE SUBCOMMITTEEPATIENT NAME IMPLEMENTATION GUIDE

54 MAY 2004



CODE DEFINITION

1 Person


SYNTAX: C1203

INDUSTRY: Patient Last Name


INDUSTRY: Patient First Name

169 Required when the value in NM102 is 1 and the person’s first nameis known. If not required, do not send.


INDUSTRY: Patient Middle Name

151 Required when the value in NM102 is 1 and the person’s middlename/initial is known. If not required, do not send.


SITUATIONAL NM107 1039 Name Suffix O 1 AN 1/10Suffix to individual name

INDUSTRY: Patient Name Suffix

171 Required when the value in NM102 is 1 and the suffix is known. Forexample, I, II, III, IV, JR, SR. If not required, do not send.


SYNTAX: P0809

CODE DEFINITION

MI Member Identification Number

153 The code “MI” is intended to be the subscriber’sidentification number as assigned by the payer.Payers use different terminology to convey thesame number. Therefore the 275 Workgrouprecommends using MI - Member IdentificationNumber to convey the following terms: Insured’s ID,Subscriber’s ID, Health Insurance Claim Number(HIC), etc.

MI is also intended to be used in claims submitted tothe Indian Health Service/Contract Health Services(IHS/CHS) Fiscal Intermediary for the purpose ofreporting the Tribe Residency Code (Tribe CountyState).

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 1000D • NM1IMPLEMENTATION GUIDE PATIENT NAME

MAY 2004 55

ZZ Mutually Defined

1000145 The value ’ZZ’ when used in this data element shallbe defined as “HIPAA Individual Identifier” if thisidentifier is adopted for use. Under the HealthInsurance Portability and Accountability Act of 1996,the secretary of the Department of Health andHuman Services may adopt a standard IndividualIdentifier for use in this transaction.


SYNTAX: P0809

INDUSTRY: Patient Primary Identifier




004050X151 • 275 • 1000D • NM1 ASC X12N • INSURANCE SUBCOMMITTEEPATIENT NAME IMPLEMENTATION GUIDE

56 MAY 2004

REFREFERENCE INFORMATION 004050X151 • 275 • 1000D • REFPATIENT ACCOUNT NUMBER

IMPLEMENTATION

PATIENT ACCOUNT NUMBERLoop: 1000D — PATIENT NAME

Usage: REQUIRED

Repeat: 1

1000188 Notes: 1. Required when the 277 includes this value or when the 275 isunsolicited.

65 Example: REF✽ EJ✽ ME1234~

STANDARD


Level: Header

Position: 1000

Loop: NM1


Max Use: 5



DIAGRAM

REF01 128 REF02 127 REF03 352 REF04 C040



M 1 ID 2/3 X 1 AN 1/50 X 1 AN 1/80 O 1

ELEMENT SUMMARY

USAGEREF.DES.



CODE DEFINITION

EJ Patient Account Number

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

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 1000D • REFIMPLEMENTATION GUIDE PATIENT ACCOUNT NUMBER

MAY 2004 57


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 theirneeds. However, the HIPAA maximum requirement to be supportedby any responding system is “20”. Characters beyond “20” are notrequired to be stored nor returned by any 837 receiving system.

1000205 For a solicited 275, this value must be identical to the patientaccount number from the 2200D or 2200E REF segment in the 277.



004050X151 • 275 • 1000D • REF ASC X12N • INSURANCE SUBCOMMITTEEPATIENT ACCOUNT NUMBER IMPLEMENTATION GUIDE

58 MAY 2004

REFREFERENCE INFORMATION 004050X151 • 275 • 1000D • REFINSTITUTIONAL TYPE OF BILL

IMPLEMENTATION

INSTITUTIONAL TYPE OF BILLLoop: 1000D — PATIENT NAME

Usage: SITUATIONAL

Repeat: 1

1000206 Notes: 1. Required when the Institutional Type of Bill from the submitted claimis available in the payer’s system and is included in the 2200D/2200EREF segment of the 277. If not required, may be provided at thesender’s discretion.

20 2. Not used for Professional Claims.

67 Example: REF✽ BLT✽ 111~

STANDARD


Level: Header

Position: 1000

Loop: NM1


Max Use: 5



DIAGRAM

REF01 128 REF02 127 REF03 352 REF04 C040



M 1 ID 2/3 X 1 AN 1/50 X 1 AN 1/80 O 1

ELEMENT SUMMARY

USAGEREF.DES.



CODE DEFINITION

BLT Billing Type

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 1000D • REFIMPLEMENTATION GUIDE INSTITUTIONAL TYPE OF BILL

MAY 2004 59


SYNTAX: R0203

INDUSTRY: Bill Type Identifier

1000207 The value in REF02 corresponds to a concatenation of Facility TypeCode (CLM05-1) and Claim Frequency Type Code (CLM05-3) fromthe ASC X12N 837 claim transaction or this is the value from theloop 2200D/2200E REF02 of the 277.



004050X151 • 275 • 1000D • REF ASC X12N • INSURANCE SUBCOMMITTEEINSTITUTIONAL TYPE OF BILL IMPLEMENTATION GUIDE

60 MAY 2004

REFREFERENCE INFORMATION 004050X151 • 275 • 1000D • REFMEDICAL RECORD NUMBER

IMPLEMENTATION

MEDICAL RECORD NUMBERLoop: 1000D — PATIENT NAME

Usage: SITUATIONAL

Repeat: 1

1000117 Notes: 1. Required when the Medical Record Number is submitted on theoriginal claim. If not required, may be provided at the sender’sdiscretion.

127 Example: REF✽ EA✽ STHH12345~

STANDARD


Level: Header

Position: 1000

Loop: NM1


Max Use: 5



DIAGRAM

REF01 128 REF02 127 REF03 352 REF04 C040



M 1 ID 2/3 X 1 AN 1/50 X 1 AN 1/80 O 1

ELEMENT SUMMARY

USAGEREF.DES.



CODE DEFINITION

EA Medical Record Identification Number


SYNTAX: R0203

INDUSTRY: Medical Record Number

1000085 This is the Medical Record Number from the original claim.



ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 1000D • REFIMPLEMENTATION GUIDE MEDICAL RECORD NUMBER

MAY 2004 61

REFREFERENCE INFORMATION 004050X151 • 275 • 1000D • REFCLAIM ID NUMBER FOR CLEARING HOUSES AND OTHER TRANSMISSION INTERMEDIARIES

IMPLEMENTATION

CLAIM IDENTIFICATION NUMBER FORCLEARING HOUSES AND OTHERTRANSMISSION INTERMEDIARIES

Loop: 1000D — PATIENT NAME

Usage: SITUATIONAL

Repeat: 1

1000183 Notes: 1. Required when transmission intermediaries (Automated ClearingHouses and others) need to attach their own unique claim number. Ifnot required, do not send.

1000184 2. Although this REF is supplies for transmission intermediaries toattach their own unique claim number to a claim/encounter, recipientsare not required under HIPAA to return this number in any HIPAAtransaction. Trading partners may voluntarily agree to this interactionif they wish.

STANDARD


Level: Header

Position: 1000

Loop: NM1


Max Use: 5



DIAGRAM

REF01 128 REF02 127 REF03 352 REF04 C040



M 1 ID 2/3 X 1 AN 1/50 X 1 AN 1/80 O 1

ELEMENT SUMMARY

USAGEREF.DES.



CODE DEFINITION

D9 Claim Number

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

62 MAY 2004


SYNTAX: R0203

INDUSTRY: Clearinghouse Trace Number

1000185 The value carried in this element is limited to a maximum of 20positions.



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

MAY 2004 63

DTPDATE OR TIME OR PERIOD 004050X151 • 275 • 1000D • DTPINSTITUTIONAL CLAIM SERVICE DATE

IMPLEMENTATION

INSTITUTIONAL CLAIM SERVICE DATELoop: 1000D — PATIENT NAME

Usage: SITUATIONAL

Repeat: 1

15 Notes: 1. This is required for Institutional Claims and is the Statement From andThrough dates. If not required, do not send.

1000167 Example: DTP✽ 434✽ RD8✽ 20030720-20030724~

STANDARD

DTP Date or Time or Period

Level: Header

Position: 1050

Loop: NM1


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/TimeQualifier ✽ Date Time

format Qual ✽ Date TimePeriod ~

M 1 ID 3/3 M 1 ID 2/3 M 1 AN 1/35

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED DTP01 374 Date/Time Qualifier M 1 ID 3/3Code specifying type of date or time, or both date and time

INDUSTRY: Date Time QualifierCODE DEFINITION

434 Statement

REQUIRED DTP02 1250 Date Time Period Format Qualifier M 1 ID 2/3Code indicating the date format, time format, or date and time format

SEMANTIC: DTP02 is the date or time or period format that will appear in DTP03.

CODE DEFINITION

RD8 Range of Dates Expressed in Format CCYYMMDD-CCYYMMDD

REQUIRED DTP03 1251 Date Time Period M 1 AN 1/35Expression of a date, a time, or range of dates, times or dates and times

INDUSTRY: Claim Service Period

195 This is the Statement From and Through dates.

004050X151 • 275 • 1000D • DTP ASC X12N • INSURANCE SUBCOMMITTEEINSTITUTIONAL CLAIM SERVICE DATE IMPLEMENTATION GUIDE

64 MAY 2004

LXTRANSACTION SET LINE NUMBER 004050X151 • 275 • 2000A • LXASSIGNED NUMBER

IMPLEMENTATION

ASSIGNED NUMBERLoop: 2000A — ASSIGNED NUMBER Repeat: >1

Usage: REQUIRED

Repeat: 1

189 Notes: 1. Within the LX, LX01 is the sequence number of the segments thatfollow. The LX01 sequence number must start at 1 and increment by 1.

1000190 2. The LX segment can be repeated to respond to multiple questions onan individual claim. The 275 transaction structure only allows thesubmitter to send one claim in each 275. A separate Transaction SetHeader/Trailer (ST/SE) must be sent for each claim.

156 Example: LX✽ 1~

STANDARD

LX Transaction Set Line Number

Level: Detail

Position: 0100

Loop: LX Repeat: >1


Max Use: 1

Purpose: To reference a line number in a transaction set

DIAGRAM

LX01 554

LX ✽ AssignedNumber

M 1 N0 1/6

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED LX01 554 Assigned Number M 1 N0 1/6Number assigned for differentiation within a transaction set

189 Within the LX, LX01 is the sequence number of the segments thatfollow. The LX01 sequence number must start at 1 and incrementby 1.

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 2000A • LXIMPLEMENTATION GUIDE ASSIGNED NUMBER

MAY 2004 65

TRNTRACE 004050X151 • 275 • 2000A • TRNPAYER’S CONTROL NUMBER/PROVIDER’S CONTROL NUMBER

IMPLEMENTATION

PAYER’S CONTROL NUMBER/PROVIDER’SCONTROL NUMBER

Loop: 2000A — ASSIGNED NUMBER

Usage: REQUIRED

Repeat: 1

27 Notes: 1. Payer’s Control Number is the value from the TRN segment loop2200D/2200E of the 277.

1000168 2. Provider’s Control Number is the value from PWK06 loop 2300 of the837 submitted within the same Interchange. This is the main matchingcriteria and must be unique on a per attachment basis.

1000191 3. The TRN02 value must be the same in each iteration of the 2000A loopwhen the value in TRN02 is the Payer’s control number.

104 Example: TRN✽ 2✽ 1234567~

STANDARD

TRN Trace

Level: Detail

Position: 0150

Loop: LX


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 itemwhen TRN is used.

DIAGRAM

TRN01 481 TRN02 127 TRN03 509 TRN04 127

TRN ✽ Trace TypeCode ✽ Reference

Ident ✽ OriginatingCompany ID ✽ Reference

Ident ~

M 1 ID 1/2 M 1 AN 1/50 O 1 AN 10/10 O 1 AN 1/50

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED TRN01 481 Trace Type Code M 1 ID 1/2Code identifying which transaction is being referenced

CODE DEFINITION

1 Current Transaction Trace Numbers

196 Used when sending a 275 to support an 837 withinthe same interchange.

004050X151 • 275 • 2000A • TRN ASC X12N • INSURANCE SUBCOMMITTEEPAYER’S CONTROL NUMBER/PROVIDER’S CONTROL NUMBER IMPLEMENTATION GUIDE

66 MAY 2004

2 Referenced Transaction Trace Numbers

1000169 Used when responding to a 277.

REQUIRED TRN02 127 Reference Identification M 1 AN 1/50Reference information as defined for a particular Transaction Set or as specifiedby the Reference Identification Qualifier

SEMANTIC: TRN02 provides unique identification for the transaction.

INDUSTRY: Payer or Provider’s Control Number

ALIAS: Payer Control Identifier

1000192 When the value in BGN02 is 11, this number will be the payer’scontrol number that is in the 2200D/2200E loop, TRN02 of the 277.This value must be the same in each LX loop.

1000193 When the value in BGN02 is 02, this number is the unique controlnumber that the provider assigned for the attachment. It mustmatch the number in PWK06 loop 2300 of the 837 within the sameinterchange. This is the main matching criteria and must be uniqueon a per attachment basis.

NOT USED TRN03 509 Originating Company Identifier O 1 AN 10/10

NOT USED TRN04 127 Reference Identification O 1 AN 1/50

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 2000A • TRNIMPLEMENTATION GUIDE PAYER’S CONTROL NUMBER/PROVIDER’S CONTROL NUMBER

MAY 2004 67

STCSTATUS INFORMATION 004050X151 • 275 • 2000A • STCSTATUS INFORMATION

IMPLEMENTATION

STATUS INFORMATIONLoop: 2000A — ASSIGNED NUMBER

Usage: SITUATIONAL

Repeat: 1

175 Notes: 1. This segment is required when the value in BGN01 is 11 and the 277STC01 value is not 19016-5. When the 277 contains the STC01 claimlevel place holder of R0:19016-5::LOI, this information must not bereturned in the 275. If not required, do not send.

32 2. This segment is not used when sending a 275 to support an 837 withinthe same interchange.

188 Example: STC✽ R3:18682-5::LOI~

STANDARD

STC Status Information

Level: Detail

Position: 0175

Loop: LX


Max Use: 1

Purpose: To report the status, required action, and paid information of a claim or serviceline

Set Notes: 1. The STC segment in LX loop identifies the status and action requested in aprior transaction when the response is provided in this transaction.

DIAGRAM

STC01 C043 STC02 373 STC03 306 STC04 782 STC05 782 STC06 373

STC ✽ Health CareStat Claim ✽ Date ✽ Action

Code ✽ MonetaryAmount ✽ Monetary

Amount ✽ Date

M 1 O 1 DT 8/8 O 1 ID 1/2 O 1 R 1/18 O 1 R 1/18 O 1 DT 8/8

STC07 591 STC08 373 STC09 429 STC10 C043 STC11 C043 STC12 933

✽ PaymentMethod Code ✽ Date ✽ Check

Number ✽ Health CareStat Claim ✽ Health Care

Stat Claim ✽ Free-FormMessage Txt ~

O 1 ID 3/3 O 1 DT 8/8 O 1 AN 1/16 O 1 O 1 O 1 AN 1/264

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED STC01 C043 HEALTH CARE CLAIM STATUS M 1Used 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.

004050X151 • 275 • 2000A • STC ASC X12N • INSURANCE SUBCOMMITTEESTATUS INFORMATION IMPLEMENTATION GUIDE

68 MAY 2004

REQUIRED STC01 - 1 1271 Industry Code M AN 1/30Code indicating a code from a specific industry code list

SEMANTIC:

C043-01 is used to specify the logical groupings of Health Care ClaimStatus Codes (See Code Source 507).

INDUSTRY: Health Care Claim Status Category Code

CODE SOURCE 507: Health Care Claim Status Category Code

107 This is the Category Code.


SEMANTIC:

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 Information Request Code

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

1000170 This will be the LOINC Code that defines the additionalinformation that was requested.

NOT USED STC01 - 3 98 Entity Identifier Code O ID 2/3

REQUIRED STC01 - 4 1270 Code List Qualifier Code O ID 1/3Code identifying a specific industry code list

SEMANTIC:

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 andCodes (LOINC)

NOT USED STC02 373 Date O 1 DT 8/8

NOT USED STC03 306 Action Code O 1 ID 1/2

NOT USED STC04 782 Monetary Amount O 1 R 1/18

NOT USED STC05 782 Monetary Amount O 1 R 1/18


NOT USED STC07 591 Payment Method Code O 1 ID 3/3


NOT USED STC09 429 Check Number O 1 AN 1/16

SITUATIONAL STC10 C043 HEALTH CARE CLAIM STATUS O 1Used to convey status of the entire claim or a specific service line

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

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 2000A • STCIMPLEMENTATION GUIDE STATUS INFORMATION

MAY 2004 69


SEMANTIC:






SEMANTIC:


INDUSTRY: Additional Information Request Modifier





SEMANTIC:


CODE DEFINITION



SITUATIONAL STC11 C043 HEALTH CARE CLAIM STATUS O 1Used to convey status of the entire claim or a specific service line

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


SEMANTIC:





004050X151 • 275 • 2000A • STC ASC X12N • INSURANCE SUBCOMMITTEESTATUS INFORMATION IMPLEMENTATION GUIDE

70 MAY 2004


SEMANTIC:


INDUSTRY: Additional Information Request Modifier





SEMANTIC:


CODE DEFINITION



NOT USED STC12 933 Free-Form Message Text O 1 AN 1/264

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 2000A • STCIMPLEMENTATION GUIDE STATUS INFORMATION

MAY 2004 71

REFREFERENCE INFORMATION 004050X151 • 275 • 2000A • REFSERVICE LINE ITEM IDENTIFICATION

IMPLEMENTATION

SERVICE LINE ITEM IDENTIFICATIONLoop: 2000A — ASSIGNED NUMBER

Usage: SITUATIONAL

Repeat: 1

1000149 Notes: 1. This segment is required when the additional information isassociated with the service line or revenue line information. If notrequired, may be provided at the sender’s discretion.

95 2. If this segment is used, then there will be a REF segment that containsthe Procedure Code or Revenue Code.

76 Example: REF✽ FJ✽ 1234~

STANDARD


Level: Detail

Position: 0500

Loop: LX


Max Use: 5



DIAGRAM

REF01 128 REF02 127 REF03 352 REF04 C040



M 1 ID 2/3 X 1 AN 1/50 X 1 AN 1/80 O 1

ELEMENT SUMMARY

USAGEREF.DES.



CODE DEFINITION

6R Provider Control Number

1000171 Used when the value in BGN01 is 02. This is theProvider Control that is reported in the 837 on theoriginal claim.

FJ Line Item Control Number

1000172 Used when the value in BGN01 is 11. This is the LineItem Control Number that is reported in the 277.

004050X151 • 275 • 2000A • REF ASC X12N • INSURANCE SUBCOMMITTEESERVICE LINE ITEM IDENTIFICATION IMPLEMENTATION GUIDE

72 MAY 2004


SYNTAX: R0203

INDUSTRY: Line Item Control Number

1000087 This is the provider control number or the line item control numberthat is associated with the additional information.



ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 2000A • REFIMPLEMENTATION GUIDE SERVICE LINE ITEM IDENTIFICATION

MAY 2004 73

REFREFERENCE INFORMATION 004050X151 • 275 • 2000A • REFPROCEDURE OR REVENUE CODE

IMPLEMENTATION

PROCEDURE OR REVENUE CODELoop: 2000A — ASSIGNED NUMBER

Usage: SITUATIONAL

Repeat: 1

1000150 Notes: 1. This segment is required when the Service Line Item IdentificationREF Segment is used. If not required, may be provided at the sender’sdiscretion.

48 2. This segment will convey service line or revenue code informationthat is associated with the additional information. This matches thevalue in the 837 SV101-2, SV201-2, or SV301-2 or the 277 SVC01-2.

74 Example: REF✽ CPT✽ 44499~

STANDARD


Level: Detail

Position: 0500

Loop: LX


Max Use: 5



DIAGRAM

REF01 128 REF02 127 REF03 352 REF04 C040



M 1 ID 2/3 X 1 AN 1/50 X 1 AN 1/80 O 1

ELEMENT SUMMARY

USAGEREF.DES.



CODE DEFINITION

CPT Current Procedural Terminology Code

1000173 Used to convey the Procedure Code (HCPCS Level I(CPT) or Level II) reported in the 837 or the 277.

CODE SOURCE 133: Current Procedural Terminology (CPT) Codes

F8 Original Reference Number

1000195 Used to convey the CDT-3 code.

004050X151 • 275 • 2000A • REF ASC X12N • INSURANCE SUBCOMMITTEEPROCEDURE OR REVENUE CODE IMPLEMENTATION GUIDE

74 MAY 2004

FO Drug Formulary Number

1000174 Used to convey the National Drug Code (NDC) in 5-4-2 format reported in the 837 or the 277.

PRT Product Type

1000203 This code is used for the Universal Product Numberor when the 277 SVC01-1 has the value of UX.

This code set is not allowed for use under HIPAA atthe time of this writing. The qualifier can only beused:

1) If a new rule names the Universal Product Codeas an allowable code set under HIPAA.2) For Property & Casualty claims/encounters thatare not covered under HIPAA.

YJ Revenue Source

1000175 Used to convey the Revenue Code reported in the837 or the 277.

ZZ Mutually Defined

1000196 Used to convey HEIC and Alternative Link codes.


SYNTAX: R0203

INDUSTRY: Procedure Code

1000177 When the service line item is identified with both a procedure codeand a revenue code, the revenue code must be reported in REF04.


SITUATIONAL REF04 C040 REFERENCE IDENTIFIER O 1To identify one or more reference numbers or identification numbers as specifiedby the Reference Qualifier

SYNTAX:

P0304If either C04003 or C04004 is present, then the other is required.P0506If either C04005 or C04006 is present, then the other is required.

1000197 This element is required when the service line is identified withboth a procedure code and a revenue code. If not required, do notsend.

REQUIRED REF04 - 1 128 Reference Identification Qualifier M ID 2/3Code qualifying the Reference Identification

CODE DEFINITION

YJ Revenue Source

1000175 Used to convey the Revenue Code reported in the837 or the 277.

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 2000A • REFIMPLEMENTATION GUIDE PROCEDURE OR REVENUE CODE

MAY 2004 75

REQUIRED REF04 - 2 127 Reference Identification M AN 1/50Reference information as defined for a particular Transaction Set or asspecified by the Reference Identification Qualifier

INDUSTRY: Revenue Code

NOT USED REF04 - 3 128 Reference Identification Qualifier X ID 2/3

NOT USED REF04 - 4 127 Reference Identification X AN 1/50

NOT USED REF04 - 5 128 Reference Identification Qualifier X ID 2/3

NOT USED REF04 - 6 127 Reference Identification X AN 1/50

004050X151 • 275 • 2000A • REF ASC X12N • INSURANCE SUBCOMMITTEEPROCEDURE OR REVENUE CODE IMPLEMENTATION GUIDE

76 MAY 2004

DTPDATE OR TIME OR PERIOD 004050X151 • 275 • 2100A • DTPSERVICE LINE DATE OF SERVICE

IMPLEMENTATION

SERVICE LINE DATE OF SERVICELoop: 2100A — SERVICE LINE DATE OF SERVICE Repeat: 1

Usage: SITUATIONAL

Repeat: 1

1000151 Notes: 1. This segment is required when the date of service is not reported atthe claim level. If not required, may be provided at the sender’sdiscretion.

1000152 2. This segment is required for Institutional Claims to report Service Linelevel date of service on outpatient claims when revenue, procedure,HEIC or Drug codes are reported in the 2400 loop SV2 segment in the837.

1000153 Example: DTP✽ 472✽ D8✽ 20030724~

STANDARD


Level: Detail

Position: 0600

Loop: LX/DTP Repeat: >1


Max Use: 1


DIAGRAM

DTP01 374 DTP02 1250 DTP03 1251



M 1 ID 3/3 M 1 ID 2/3 M 1 AN 1/35

ELEMENT SUMMARY

USAGEREF.DES.




472 Service

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 2100A • DTPIMPLEMENTATION GUIDE SERVICE LINE DATE OF SERVICE

MAY 2004 77



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

CODE DEFINITION

D8 Date Expressed in Format CCYYMMDD

RD8 Range of Dates Expressed in Format CCYYMMDD-CCYYMMDD


INDUSTRY: Service Date

004050X151 • 275 • 2100A • DTP ASC X12N • INSURANCE SUBCOMMITTEESERVICE LINE DATE OF SERVICE IMPLEMENTATION GUIDE

78 MAY 2004

DTPDATE OR TIME OR PERIOD 004050X151 • 275 • 2100B • DTPDATE ADDITIONAL INFORMATION WAS SUBMITTED

IMPLEMENTATION

DATE ADDITIONAL INFORMATION WASSUBMITTED

Loop: 2100B — DATE ADDITIONAL INFORMATION WAS SUBMITTED Repeat:1

Usage: REQUIRED

Repeat: 1

161 Example: DTP✽ 368✽ D8✽ 20030724~

STANDARD


Level: Detail

Position: 0600

Loop: LX/DTP Repeat: >1


Max Use: 1


DIAGRAM

DTP01 374 DTP02 1250 DTP03 1251



M 1 ID 3/3 M 1 ID 2/3 M 1 AN 1/35

ELEMENT SUMMARY

USAGEREF.DES.




368 Submittal

1000179 Date information is submitted.



CODE DEFINITION

D8 Date Expressed in Format CCYYMMDD


INDUSTRY: Additional Information Gathered Date

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 2100B • DTPIMPLEMENTATION GUIDE DATE ADDITIONAL INFORMATION WAS SUBMITTED

MAY 2004 79

CATCATEGORY OF PATIENT INFORMATION SERVICE 004050X151 • 275 • 2100B • CATCATEGORY OF PATIENT INFORMATION SERVICE

IMPLEMENTATION

CATEGORY OF PATIENT INFORMATIONSERVICE

Loop: 2100B — DATE ADDITIONAL INFORMATION WAS SUBMITTED

Usage: REQUIRED

Repeat: 1

79 Example: CAT✽ AE✽ HL~

STANDARD

CAT Category of Patient Information Service

Level: Detail

Position: 0700

Loop: LX/DTP


Max Use: 1

Purpose: To specify categories of patient information service

Syntax: 1. C0302If CAT03 is present, then CAT02 is required.

2. P0405If either CAT04 or CAT05 is present, then the other is required.

3. C0605If CAT06 is present, then CAT05 is required.

4. C0704If CAT07 is present, then CAT04 is required.

DIAGRAM

CAT01 755 CAT02 756 CAT03 799 CAT04 1270 CAT05 1271 CAT06 1271

CAT ✽ Report TypeCode ✽ Report

Transm Code ✽ VersionID ✽ Code List

Qual Code ✽ IndustryCode ✽ Industry

CodeO 1 ID 2/2 X 1 ID 1/2 O 1 AN 1/30 X 1 ID 1/3 X 1 AN 1/30 O 1 AN 1/30

CAT07 799

✽ VersionID ~

O 1 AN 1/30

004050X151 • 275 • 2100B • CAT ASC X12N • INSURANCE SUBCOMMITTEECATEGORY OF PATIENT INFORMATION SERVICE IMPLEMENTATION GUIDE

80 MAY 2004

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED CAT01 755 Report Type Code O 1 ID 2/2Code indicating the title or contents of a document, report or supporting item

INDUSTRY: Attachment Report Type CodeCODE DEFINITION

AE Attachment

REQUIRED CAT02 756 Report Transmission Code X 1 ID 1/2Code defining timing, transmission method or format by which reports are to besent

SYNTAX: C0302

INDUSTRY: Attachment Information Format Code

ALIAS: Industry Report Transmission Code

33 Format of the attachment information that will be in the BINsegment.

CODE DEFINITION

HL Health Industry Level 7 Interface Standards (HL7)Format

1000155 Required for Claim Attachment types named underHIPAA.

CODE SOURCE 464: Health Industry Level 7 (HL7)

IA Electronic Image

1000198 This qualifier must not be used when exchangingattachments adopted under HIPAA. Whenexchanging HIPAA adopted attachments the CAT02must always be “HL”. “IA” may be used whenexchanging attachments NOT adopted under HIPAA,so also may the HL qualifier be used in theseinstances. It is up to mutually agreeing TP’s tochoose which qualifier to use in cases whereattachments are either not yet adopted or notadopted (for some other reason) under HIPAA.

SITUATIONAL CAT03 799 Version Identifier O 1 AN 1/30Revision level of a particular format, program, technique or algorithm

SYNTAX: C0302

INDUSTRY: Version Identification Code

1000157 Required when it is necessary to further qualify CAT02. If notrequired, may be provided at the sender’s discretion.

NOT USED CAT04 1270 Code List Qualifier Code X 1 ID 1/3

NOT USED CAT05 1271 Industry Code X 1 AN 1/30

NOT USED CAT06 1271 Industry Code O 1 AN 1/30

NOT USED CAT07 799 Version Identifier O 1 AN 1/30

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 2100B • CATIMPLEMENTATION GUIDE CATEGORY OF PATIENT INFORMATION SERVICE

MAY 2004 81

EFIELECTRONIC FORMAT IDENTIFICATION 004050X151 • 275 • 2110B • EFIELECTRONIC FORMAT IDENTIFICATION

IMPLEMENTATION

ELECTRONIC FORMAT IDENTIFICATIONLoop: 2110B — ELECTRONIC FORMAT IDENTIFICATION Repeat: 1

Usage: REQUIRED

Repeat: 1

80 Example: EFI✽ 05~

STANDARD

EFI Electronic Format Identification

Level: Detail

Position: 0900

Loop: LX/DTP/EFI Repeat: 1


Max Use: 1

Purpose: To provide basic information about the electronic format of the interchange data

Syntax: 1. C0504If EFI05 is present, then EFI04 is required.

2. C0706If EFI07 is present, then EFI06 is required.

3. C0908If EFI09 is present, then EFI08 is required.

4. P1516If 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 ✽ SecurityLevel Code ✽ Free-Form

Message Txt ✽ SecurityTech Code ✽ Version

ID ✽ ProgramID ✽ Version

IDM 1 ID 2/2 O 1 AN 1/264 O 1 ID 2/2 X 1 AN 1/30 O 1 AN 1/30 X 1 AN 1/30

EFI07 801 EFI08 799 EFI09 800 EFI10 789 EFI11 803 EFI12 804

✽ InterchangeFormat ✽ Version

ID ✽ CompressionTechnique ✽ Draw Sheet

Size Code ✽ FileName ✽ Block

TypeO 1 AN 1/30 X 1 AN 1/30 O 1 AN 1/30 O 1 AN 2/2 O 1 AN 1/64 O 1 AN 1/4

EFI13 787 EFI14 788 EFI15 799 EFI16 1570

✽ RecordLength ✽ Block

Length ✽ VersionID ✽ Filter

ID Code ~

O 1 N 1/15 O 1 N 1/5 X 1 AN 1/30 X 1 ID 3/3

004050X151 • 275 • 2110B • EFI ASC X12N • INSURANCE SUBCOMMITTEEELECTRONIC FORMAT IDENTIFICATION IMPLEMENTATION GUIDE

82 MAY 2004

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED EFI01 786 Security Level Code M 1 ID 2/2Code indicating the level of confidentiality assigned by the sender to theinformation following

CODE DEFINITION

05 Personal

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

NOT USED EFI02 933 Free-Form Message Text O 1 AN 1/264

NOT USED EFI03 797 Security Technique Code O 1 ID 2/2

NOT USED EFI04 799 Version Identifier X 1 AN 1/30

NOT USED EFI05 802 Program Identifier O 1 AN 1/30


NOT USED EFI07 801 Interchange Format O 1 AN 1/30


NOT USED EFI09 800 Compression Technique O 1 AN 1/30

NOT USED EFI10 789 Drawing Sheet Size Code O 1 AN 2/2

NOT USED EFI11 803 File Name O 1 AN 1/64

NOT USED EFI12 804 Block Type O 1 AN 1/4

NOT USED EFI13 787 Record Length O 1 N 1/15

NOT USED EFI14 788 Block Length O 1 N 1/5


NOT USED EFI16 1570 Filter ID Code X 1 ID 3/3

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • 2110B • EFIIMPLEMENTATION GUIDE ELECTRONIC FORMAT IDENTIFICATION

MAY 2004 83

BINBINARY DATA SEGMENT 004050X151 • 275 • 2110B • BINBINARY DATA SEGMENT

IMPLEMENTATION

BINARY DATA SEGMENTLoop: 2110B — ELECTRONIC FORMAT IDENTIFICATION

Usage: REQUIRED

Repeat: 1

184 Notes: 1. This is used to send additional information in the HL7 format.

163 2. It is recommended that BIN02 not be larger than 64 megabytes.

1000123 Example: BIN✽ 7✽ xxxxxxx~

STANDARD

BIN Binary Data Segment

Level: Detail

Position: 1000

Loop: LX/DTP/EFI


Max Use: 1

Purpose: To transfer binary data in a single data segment and allow identification of theend of the data segment through a count; there is no identification of the internalstructure of the binary data in this segment

DIAGRAM

BIN01 784 BIN02 785

BIN ✽ Length ofBinary Data ✽ Binary

Data ~

M 1 N0 1/15 M 1 B 1/1

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED BIN01 784 Length of Binary Data M 1 N0 1/15The length in integral octets of the binary data

INDUSTRY: Binary Data Length Number

1000109 This number should represent all of the characters in the BIN02data element.

REQUIRED BIN02 785 Binary Data M 1 B 1/1A string of octets which can assume any binary pattern from hexadecimal 00 to FF

004050X151 • 275 • 2110B • BIN ASC X12N • INSURANCE SUBCOMMITTEEBINARY DATA SEGMENT IMPLEMENTATION GUIDE

84 MAY 2004

SETRANSACTION SET TRAILER 004050X151 • 275 • SE275 TRANSACTION SET TRAILER

IMPLEMENTATION

275 TRANSACTION SET TRAILERUsage: REQUIRED

Repeat: 1

83 Example: SE✽ 17✽ 0001~

STANDARD

SE Transaction Set Trailer

Level: Detail

Position: 1100

Loop: ____


Max Use: 1

Purpose: To indicate the end of the transaction set and provide the count of thetransmitted segments (including the beginning (ST) and ending (SE) segments)

DIAGRAM

SE01 96 SE02 329

SE ✽ Number ofInc Segs ✽ TS Control

Number ~

M 1 N0 1/10 M 1 AN 4/9

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED SE01 96 Number of Included Segments M 1 N0 1/10Total number of segments included in a transaction set including ST and SEsegments

INDUSTRY: Transaction Segment Count

111 Do not include the segments contained within the HL7 format.However, include the entire BIN segment as one segment in thecount.

REQUIRED SE02 329 Transaction Set Control Number M 1 AN 4/9Identifying control number that must be unique within the transaction setfunctional group assigned by the originator for a transaction set

142 The Transaction Set Control Number in ST02 and SE02 must beidentical. This unique number also aids in error resolutionresearch. Submitters could begin sending transactions using thenumber 0001 in this element and increment from there. The numbermust be unique within a specific functional group (GS-GE) andinterchange (ISA-IEA), but can repeat in other groups andinterchanges.

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 275 • SEIMPLEMENTATION GUIDE 275 TRANSACTION SET TRAILER

MAY 2004 85

004050X151 • 275 • SE ASC X12N • INSURANCE SUBCOMMITTEE275 TRANSACTION SET TRAILER IMPLEMENTATION GUIDE

86 MAY 2004

4 EDI Transmission Examplesfor Business UsagesOverviewThe 277 Health Care Claim Request for Additional Information has been writtento be able to send questions concerning claims requiring attachment information.

The 275 Additional Information to Support a Health Care Claim or Encounter hasbeen written to be able to send answers to standard attachments electronically.

The following scenarios have used the Rehabilitative Services (Psychiatric Reha-bilitation discipline) and the Ambulance Additional Information Specification book-lets as well as the HL7 documentation that accompanies this ImplementationGuide. These attachment examples are being used to show how to code the 275.

Scenario One - Electronic request, response is returned on pa-per/fax:Scenario one depicts the utilization of the 277 and a response that is faxed to thepayer in a Medicare Part A institutional environment. One claim has been elec-tronically transmitted to the Medicare Part A fiscal intermediary through the use ofa third party billing service (clearinghouse). In this scenario, the claim has beenaccepted into the claims adjudication system and requires additional information.The Psychiatric Rehabilitation attachment is needed and is being requested sothe claim can continue processing through the adjudication process.

A 277 transaction is sent to the provider for the purpose of requesting additionalinformation. The provider responds to the request by faxing the necessary paperdocumentation to the payer. In this scenario, the provider does not generate a275 transaction.

Medicare Part A Fiscal Intermediary, ABC Insurance Company, has a NationalPayer Identification (PlanID) of 12345. The payer received one ASC X12N 837 In-stitutional 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 aservice date of August 12, 2003, for Jack J. Jackson. Mr. Jackson’s MedicareHealth Insurance Claim Number is 987654320. The hospital assigned a patientaccount number of JACKSON123 and a medical record number of STHHL12345.

ABC Insurance Company assigned a payer internal control number of1822634845. On August 24, 2003, a 277 request for the psychiatric rehabilitationdocumentation was generated with a response due date of September 23, 2003.The 277 specifies the Payer contact information of the Medical Review Depart-ment at ABC Insurance Company, with a fax number of 999-999-9999.

277 Request for Additional Information TransmissionST*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 DescriptionScenario two depicts the utilization of the 277 and 275 in a Medicare Part A insti-tutional environment. Two claims have been electronically transmitted to the Medi-care Part A fiscal intermediary through the use of a third party billing service(clearinghouse). In this scenario, both claims have been accepted into the claimsadjudication system and require additional information in order to continue proc-essing. A 277 transaction is sent to the provider for the purpose of requesting ad-ditional information. The provider responds to the request giving the necessary in-formation in a 275 transaction.

Medicare Part A Fiscal Intermediary, ABC Insurance Company, has a NationalPayer Identification (PlanID) of 12345. The payer received two ASC X12N 837 In-stitutional 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 aservice date of August 12, 2003, for Jack J. Jackson. Mr. Jackson’s MedicareHealth Insurance Claim Number is 987654320. The hospital assigned a patientaccount number of JACKSON123 and a medical record number of STHHL12345.

ABC Insurance Company assigned a payer internal control number of1822634840. On August 24, 2003, a 277 request for the psychiatric rehabilitationdocument was generated with a response due date of September 23, 2003.

The second claim for Peter M. Jones was submitted for inpatient services (BillType 111) with service dates of August 7 to August 12, 2003. Mr Jones’ MedicareHealth Insurance Claim Number is 987654321. The hospital assigned a patientaccount number of JONES123 and a medical record number of STHHL12378.

ABC Insurance Company assigned a payer internal control number of1822634845. On August 24, 2003, a 277 request for the psychiatric rehabilitationdocument was generated with a response due date of September 23, 2003.

277 Request for Additional Information TransmissionST*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 orEncounterThe 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/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3/cdalevelone_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/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3/cdalevelone_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 ThreeDescription Scenario three depicts the utilization of the unsolicited ASC X12N275 in an institutional 837 claim environment. This example shows two claimswith one of the claims having a 275 Additional Information being transmitted elec-tronically to the Medicare Part A fiscal intermediary through the use of a thirdparty billing service (clearinghouse).

ABC Insurance Company has a Payer Identifier (Payer ID) of 12345 and is aMedicare Part A Intermediary. The insurance company received an electronic 837claim transmissions from XYZ Services, a clearing house with submitter numberA222222221, on behalf of St. Holy Hills Hospital whose Part A provider number is3999000B with a Employer Tax ID of 99-1234567.

XYZ Services’ address is 234 Main Street, Miami, FL 33132-3111 and the contactperson is Jane Doe. St. Holy Hills Hospital’s address is 2345 Winter Blvd, Miami,FL 33132-3111.


MAY 2004 107

The transmission contains two Institutional claims. The first claim submitted is forambulance services (Bill Type 131) rendered on September 15, 2003 for Jack JJackson. Mr Jackson’s Medicare Health Insurance Claim Number is 987654323.The hospital assigned a patient control number of JACKSON123 and medical re-cord number of STHHL12345. Mr Jackson’s 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 ambu-lance run so rather than wait for a request, St Holy Hills Hospital has sent the am-bulance 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 onJune 14, 2003 on behalf of Joe Smith. Mr Smiths’ Medicare Health InsuranceClaim Number is 987654324. The Hospital’s patient control number is SMITH123and 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 exam-ple.

Institutional TransmissionISA*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 ex-ample.

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/cdalevelone_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 ASC X12 Nomenclature

A.1.1 Interchange and Application Control StructuresAppendix A is provided for guidance about the X12 syntax, usage, and related in-formation. 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) ap-ply unless specifically modified in Sections 1, 2, or 3 of this guide or unless spe-cific statements are made in this appendix or Appendix B about specific imple-mentations, 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 ensurethe integrity and maintain the efficiency of the interchange. Each business group-ing of data is called a transac-tion set. For instance, a groupof benefit enrollments sentfrom a sponsor to a payer isconsidered a transaction set.

Each transaction set containsgroups of logically relateddata in units called segments.For instance, the N4 segmentused in the transaction setconveys the city, state, ZIPCode, and other geographicinformation. A transaction setcontains multiple segments,so the addresses of the differ-ent parties, for example, canbe conveyed from one com-puter to the other. An analogywould be that the transactionset is like a freight train; thesegments are like the train’scars; and each segment cancontain several data elementsthe same as a train car canhold multiple crates.

The sequence of the ele-ments within one segment isspecified by the ASC X12standard as well as the se-quence of segments in thetransaction set. In a more con-ventional computing environ-

Communications Transport Protocol

Interchange Control Header

Functional Group Header

Transaction Set Header

Transaction Set Trailer

Detail Segmentsfor example, Benefit Enrollment



Detail Segmentsfor example, Claim Payment



Functional Group Header

Functional Group Trailer

Functional Group Trailer

Interchange Control Trailer

Communications Transport Trailer

FU

NC

TIO

NA

L G

RO

UP

FU

NC

TIO

NA

L G

RO

UP IN

TE

RC

HA

NG

E E

NV

EL

OP

E

CO

MM

UN

ICA

TIO

NS

EN

VE

LO

PE

Detail Segmentsfor example, Benefit Enrollment

ISA

GS

ST

ST

SE

SE

GE

GS

ST

SE

GE

IEA

Figure A.1. Transmission Control Schematic


MAY 2004 A.1

ment, the segments would be equivalent to records, and the elements equivalentto fields.

Similar transaction sets, called “functional groups,” can be sent together within atransmission. Each functional group is prefaced by a group start segment; and afunctional group is terminated by a group end segment. One or more functionalgroups are prefaced by an interchange header and followed by an interchangetrailer. Figure A.1., Transmission Control Schematic, illustrates this interchangecontrol.

The interchange header and trailer segments envelop one or more functionalgroups or interchange-related control segments and perform the following func-tions:

1. Define the data element separators and the data segment terminator.

2. Identify the sender and receiver.

3. Provide control information for the interchange.

4. Allow for authorization and security information.

A.1.1.2 Application Control Structure Definitions and Con-cepts

A.1.1.2.1 Basic Structure

A data element corresponds to a data field in data processing terminology. Adata segment corresponds to a record in data processing terminology. The datasegment begins with a segment ID and contains related data elements. A controlsegment 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 controlsegment is used primarily to convey control information and to group data seg-ments.

A.1.1.2.2 Basic Character Set

The section that follows is designed to have representation in the common char-acter code schemes of EBCDIC, ASCII, and CCITT International Alphabet 5. TheASC X12 standards are graphic-character-oriented; therefore, common characterencoding schemes other than those specified herein may be used as long as acommon mapping is available. Because the graphic characters have an impliedmapping across character code schemes, those bit patterns are not providedhere.

The basic character set of this standard, shown in Figure A.2., Basic CharacterSet, includes those selected from the uppercase letters, digits, space, and spe-cial characters as specified below.

A...Z 0...9 ! “ & ’ ( ) * +

’- . / : ; ? = “ ” (space)

Figure A.2. Basic Character Set


A.2 MAY 2004

A.1.1.2.3 Extended Character Set

An extended character set may be used by negotiation between the two partiesand includes the lowercase letters and other special characters as specified inFigure A.3., Extended Character Set.

a..z % ~ @ [ ] _ {

} \ | < > # $

Figure A.3. Extended Character Set

Note that the extended characters include several character codes that have mul-tiple graphical representations for a specific bit pattern. The complete list appearsin other standards such as CCITT S.5. Use of the USA graphics for these codespresents no problem unless data is exchanged with an international partner.Other problems, such as the translation of item descriptions from English toFrench, arise when exchanging data with an international partner, but minimizingthe use of codes with multiple graphics eliminates one of the more obvious prob-lems.

For implementations compliant with this guide, either the entire extended charac-ter set must be acceptable, or the entire extended character set must not beused. In the absence of a specific trading partner agreement to the contrary, trad-ing partners will assume that the extended character set is acceptable. Use ofthe extended character set allows the use of the “@” character in email ad-dresses within the PER segment. Users should note that characters in the ex-tended character set, as well as the basic character set, may be used as delimit-ers 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. Thecommon notation for these groups is also provided, together with the charactercoding in three common alphabets. In the Matrix A.1., Base Control Set, the col-umn 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 ef-fect on most communication protocols. These are represented by:

NOTATION NAME EBCDIC ASCII IA5BEL bell 2F 07 07HT horizontal tab 05 09 09LF line feed 25 0A 0AVT vertical tab 0B 0B 0B

FF form feed 0C 0C 0CCR carriage return 0D 0D 0DFS file separator 1C 1C 1CGS group separator 1D 1D 1DRS record separator 1E 1E 1EUS unit separator 1F 1F 1FNL new line 15Matrix A.1. Base Control Set

The Group Separator (GS) may be an exception in this set because it is used inthe 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 transmis-sion system. These are shown in Matrix A.2., Extended Control Set.

NOTATION NAME EBCDIC ASCII IA5SOH start of header 01 01 01STX start of text 02 02 02ETX end of text 03 03 03

EOT end of transmission 37 04 04ENQ enquiry 2D 05 05ACK acknowledge 2E 06 06DC1 device control 1 11 11 11DC2 device control 2 12 12 12DC3 device control 3 13 13 13DC4 device control 4 3C 14 14NAK negative acknowledge 3D 15 15SYN synchronous idle 32 16 16ETB end of block 26 17 17Matrix A.2. Extended Control Set

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 seg-ment can be considered in implementations compliant with this guide (see Appen-dix B, ISA Segment Note 1) to be a 105 byte fixed length record, followed by asegment terminator. The data element separator is byte number 4; the repetitionseparator is byte number 83; the component element separator is byte number105; and the segment terminator is the byte that immediately follows the compo-nent element separator.

Once specified in the interchange header, the delimiters are not to be used in adata element value elsewhere in the interchange. For consistency, this implemen-tation guide uses the delimiters shown in Matrix A.3., Delimiters, in all examplesof EDI transmissions.

CHARACTER NAME DELIMITER* Asterisk Data Element Separator^ Caret Repetition Separator: Colon Subelement Separator

~ Tilde Segment TerminatorMatrix A.3. Delimiters

The delimiters above are for illustration purposes only and are not specific recom-mendations or requirements. Users of this implementation guide should be awarethat an application system may use some valid delimiter characters within the ap-plication data. Occurrences of delimiter characters in transmitted data within adata element can result in errors in translation programs. The existence of aster-isks (*) within transmitted application data is a known issue that can affect transla-tion software.


A.4 MAY 2004

A.1.1.3 Business Transaction Structure Definitions and Con-cepts

The ASC X12 standards define commonly used business transactions (such as ahealth care claim) in a formal structure called “transaction sets.” A transaction setis composed of a transaction set header control segment, one or more data seg-ments, and a transaction set trailer control segment. Each segment is composedof the following:

• A unique segment ID

• One or more logically related data elements each preceded by a data elementseparator

• A segment terminator

A.1.1.3.1 Data Element

The data element is the smallest named unit of information in the ASC X12 stand-ard. Data elements are identified as either simple or component. A data elementthat occurs as an ordinally positioned member of a composite data structure isidentified as a component data element. A data element that occurs in a segmentoutside the defined boundaries of a composite data structure is identified as asimple data element. The distinction between simple and component data ele-ments is strictly a matter of context because a data element can be used in eithercapacity.

Data elements are assigned a unique reference number. Each data element hasa name, description, type, minimum length, and maximum length. For ID typedata elements, this guide provides the applicable ASC X12 code values and theirdescriptions or references where the valid code list can be obtained.

A simple data element within a segment or a composite data element may havean attribute indicating that it may occur once or a specific number of times morethan once. The number of permitted repeats are defined as an attribute in the indi-vidual 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 ofthe data element value is the number of character positions used except asnoted for numeric, decimal, and binary elements.

The data element types shown in Matrix A.4., Data Element Types, appear in thisimplementation guide.

SYMBOL TYPENn NumericR DecimalID IdentifierAN StringDT DateTM TimeB BinaryMatrix A.4. Data Element Types

The data element minimum and maximum lengths may be restricted in this imple-mentation 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 re-garding 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 optionalleading sign representing a value in the normal base of 10. The value of a nu-meric data element includes an implied decimal point. It is used when the posi-tion of the decimal point within the data is permanently fixed and is not to betransmitted with the data.

This set of guides denotes the number of implied decimal positions. The repre-sentation for this data element type is “Nn” where N indicates that it is numericand n indicates the number of decimal positions to the right of the implied deci-mal point.

If n is 0, it need not appear in the specification; N is equivalent to N0. For nega-tive values, the leading minus sign (-) is used. Absence of a sign indicates a posi-tive value. The plus sign (+) should not be transmitted.

EXAMPLEA transmitted value of 1234, when specified as numeric type N2, represents avalue of 12.34.

Leading zeros should be suppressed unless necessary to satisfy a minimumlength requirement. The length of a numeric type data element does not includethe optional sign.

A.1.1.3.1.2 Decimal

A decimal data element may contain an explicit decimal point and is used for nu-meric values that have a varying number of decimal positions. This data elementtype is represented as “R.”

The decimal point always appears in the character stream if the decimal point isat any place other than the right end. If the value is an integer (decimal point atthe right end) the decimal point should be omitted. For negative values, the lead-ing minus sign (-) is used. Absence of a sign indicates a positive value. The plussign (+) should not be transmitted.

Leading zeros should be suppressed unless necessary to satisfy a minimumlength requirement. Trailing zeros following the decimal point should be sup-pressed unless necessary to indicate precision. The use of triad separators (forexample, the commas in 1,000,000) is expressly prohibited. The length of a deci-mal type data element does not include the optional leading sign or decimal point.

EXAMPLEA transmitted value of 12.34 represents a decimal value of 12.34.

For implementation of this guide under the rules promulgated under the Health In-surance Portability and Accountability Act (HIPAA), decimal data elements inData Element 782 (Monetary Amount) will be limited to a maximum length of 10characters including reported or implied places for cents (implied value of 00 afterthe decimal point). Note the statement in the preceding paragraph that the deci-mal 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 codesthat 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 necessaryto satisfy a minimum length. An identifier is always left justified. The repre-sentation 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 extendedcharacter sets. The string data element must contain at least one non-space char-acter. The significant characters shall be left justified. Leading spaces, when theyoccur, are presumed to be significant characters. Trailing spaces should be sup-pressed unless they are necessary to satisfy a minimum length. The repre-sentation 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 orCCYYMMDD format in which CC is the first two digits of the calendar year, YY isthe last two digits of the calendar year, MM is the month (01 to 12), and DD is theday 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-characterdates (millennium compliant) in the format CCYYMMDD. The only date data ele-ment that is in format YYMMDD is the Interchange Date data element in the ISAsegment, and also used in the TA1 Interchange Acknowledgment, where the cen-tury 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 for-mat in which HH is the hour for a 24 hour clock (00 to 23), MM is the minute (00to 59), SS is the second (00 to 59) and d..d is decimal seconds. The repre-sentation for this data element type is “TM.” The length of the data element deter-mines the format of the transmitted time.

EXAMPLETransmitted data elements of four characters denote HHMM. Transmitted dataelements 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 re-peating data elements. Repeating data elements are adjacent data elements thatoccur 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 repeatingdata element in a specific location in the transaction that are permitted in a com-pliant implementation. Adjacent occurrences of the same repeating simple dataelement or composite data structure in a segment shall be separated by a repeti-tion 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 simpledata elements, each, except the last, followed by a sub-element separator. The fi-nal data element is followed by the next data element separator or the segmentterminator. 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, semanticnotes, and comments. Each component within the composite is further charac-terized by a reference designator and a condition designator. The reference des-ignators and the condition designators are described below.

A composite data structure within a segment may have an attribute indicating thatit may occur once or a specific number of times more than once. The number ofpermitted repeats are defined as an attribute in the individual segment where therepeated composite data structure occurs.

A.1.1.3.4 Data Segment

The data segment is an intermediate unit of information in a transaction set. Inthe data stream, a data segment consists of a segment identifier, one or morecomposite data structures or simple data elements each preceded by a data ele-ment separator and succeeded by a segment terminator.

Each data segment has a unique two- or three-character identifier, a name, and apurpose. The identifier serves as a label for the data segment. A segment can befurther defined through the use of syntax notes, semantic notes, and comments.Each simple data element or composite data structure within the segment is fur-ther 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 segmentunits within the same segment, or among two or more component data elementswithin the same composite data structure. For a complete description of the rela-tional 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 se-mantic note within a particular segment. A semantic note provides important addi-tional information regarding the intended meaning of a designated data element,particularly a generic type, in the context of its use within a specific data seg-ment. Semantic notes may also define a relational condition among data ele-ments in a segment based on the presence of a specific value (or one of a set ofvalues) in one of the data elements.

A.1.1.3.7 Comments

A segment comment provides additional information regarding the intended useof the segment.

A.1.1.3.8 Reference Designator

Each simple data element or composite data structure in a segment is provided astructured code that indicates the segment in which it is used and the sequentialposition within the segment. The code is composed of the segment identifier fol-lowed by a two-digit number that defines the position of the simple data elementor composite data structure in that segment.

For purposes of creating reference designators, the composite data structure isviewed as the hierarchical equal of the simple data element. Each componentdata element in a composite data structure is identified by a suffix appended tothe 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 positionof 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 struc-ture that contains seven component data elements, the reference designatorfor 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. Itis provided so that users will have information about the general standard. Imple-mentation guides may impose other conditions designators. See implementationguide section 3.1 Presentation Examples for detailed information about the imple-mentation 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 tobe present or not present in a particular segment.

DESIGNATOR DESCRIPTIONM- Mandatory The designation of mandatory is absolute in the sense that there is no

dependency on other data elements. This designation may apply to eithersimple data elements or composite data structures. If the designation applies toa composite data structure, then at least one value of a component dataelement in that composite data structure shall be included in the data segment.

O- Optional The designation of optional means that there is no requirement for a simpledata element or composite data structure to be present in the segment. Thepresence of a value for a simple data element or the presence of value for anyof the component data elements of a composite data structure is at the optionof the sender.

X- Relational Relational conditions may exist among two or more simple data elements withinthe same data segment based on the presence or absence of one of those dataelements (presence means a data element must not be empty). Relationalconditions are specified by a condition code (see table below) and the referencedesignators of the affected data elements. A data element may be subject tomore than one relational condition.

The definitions for each of the condition codes used within syntax notes aredetailed below:

CONDITION CODE DEFINITIONP- Paired or Multiple If any element specified in the relational condition is

present, then all of the elements specified must bepresent.

R- Required At least one of the elements specified in the conditionmust be present.

E- Exclusion Not more than one of the elements specified in thecondition may be present.

C- Conditional If the first element specified in the condition ispresent, then all other elements must be present.However, any or all of the elements not specified asthe first element in the condition may appear withoutrequiring that the first element be present. The orderof the elements in the condition does not have to bethe same as the order of the data elements in thedata segment.


MAY 2004 A.9

L- List Conditional If the first element specified in the condition is

present, then at least one of the remaining elementsmust be present. However, any or all of the elementsnot specified as the first element in the condition mayappear without requiring that the first element bepresent. The order of the elements in the conditiondoes not have to be the same as the order of the dataelements 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 thesegment is used. At least one component data element of a composite data struc-ture that is indicated as mandatory must not be empty if the segment is used. Op-tional simple data elements and/or composite data structures and their precedingdata element separators that are not needed should be omitted if they occur atthe end of a segment. If they do not occur at the end of the segment, the simpledata element values and/or composite data structure values may be omitted.Their absence is indicated by the occurrence of their preceding data elementseparators, in order to maintain the element’s or structure’s position as defined inthe data segment.

Likewise, when additional information is not necessary within a composite, thecomposite may be terminated by providing the appropriate data element separa-tor 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 fortransferring 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 ofthe loop shall consist of the loop header (LS segment) and the loop trailer (LEsegment). The loop header defines the start of a structure that must contain oneor more iterations of a loop of data segments and provides the loop identifier forthis loop. The loop trailer defines the end of the structure. The LS segment ap-pears only before the first occurrence of the loop, and the LE segment appearsonly after the last occurrence of the loop. Unbounded looping structures do notuse 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) andthe transaction set trailer (SE segment). The transaction set header identifies thestart and identifier of the transaction set. The transaction set trailer identifies theend of the transaction set and provides a count of the data segments, which in-cludes 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 startsand identifies one or more related transaction sets and provides a control numberand 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 ofcontained transaction sets.

A.1.1.3.11.4 Relations among Control Segments

The control segment of this standard must have a nested relationship as isshown and annotated in this subsection. The letters preceding the control seg-ment name are the segment identifier for that control segment. The indentation ofsegment identifiers shown below indicates the subordination among control seg-ments.

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 partof 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 ofthe 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 usedwithin one functional group. Also more than one LS/LE pair, each representing abounded 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 be-tween trading partners. The transaction set consists of a transaction set headersegment, one or more data segments in a specified order, and a transaction settrailer 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 isthe first data element of the Transaction Set Header Segment (ST). A user as-signed transaction set control number in the header must match the control num-ber in the Trailer Segment (SE) for any given transaction set. The value for thenumber of included segments in the SE segment is the total number of segmentsin 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 seg-ments 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 specifiedmaximum number of occurrences defined at each specified position within agiven transaction set standard. Alternatively, a segment may be allowed to repeatan unlimited number of times. The notation for an unlimited number of repetitionsis “>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 beunbounded 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 appearonce and only once in each iteration. Loops may have a specified maximum num-ber of repetitions. Alternatively, the loop may be specified as having an unlimitednumber of iterations. The notation for an unlimited number of repetitions is “>1.”

A specified sequence of segments is in the loop. Loops themselves are optionalor mandatory. The requirement designator of the beginning segment of a loop in-dicates whether at least one occurrence of the loop is required. Each appearanceof the beginning segment defines an occurrence of the loop.

The requirement designator of any segment within the loop after the beginningsegment applies to that segment for each occurrence of the loop. If there is amandatory requirement designator for any data segment within the loop after thebeginning segment, that data segment is mandatory for each occurrence of theloop. 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 tobounded loops. In addition, bounded loops require a Loop Start Segment (LS) toappear before the first occurrence and a Loop End Segment (LE) to appear afterthe last occurrence of the loop. If the loop does not occur, the LS and LE seg-ments 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 charac-teristics are applied to each data segment: a requirement designator, a position inthe 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 forhealth care and insurance transaction sets, indicating its appearance in the datastream of a transmission. These requirement designators are represented by asingle character code.

DESIGNATOR DESCRIPTIONM- Mandatory 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 isoptional if the beginning segment of the loop is designated as optional.)

O- Optional The presence of this data segment is the option of the sending party.

A.1.1.3.12.7 Data Segment Position

The ordinal positions of the segments in a transaction set are explicitly specifiedfor that transaction. Subject to the flexibility provided by the optional requirementdesignators 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 greaterthan 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 func-tional group header segment and a functional group trailer segment. The func-tional identifier defines the group of transactions that may be included within thefunctional group. The value for the functional group control number in the headerand trailer control segments must be identical for any given group. The value forthe number of included transaction sets is the total number of transaction sets inthe group. See Figure A.1., Transmission Control Schematic.

A.1.1.4 Envelopes and Control Structures

A.1.1.4.1 Interchange Control Structures

Typically, the term “interchange” connotes the ISA/IEA envelope that is transmit-ted between trading/business partners. Interchange control is achieved throughseveral “control” components. The interchange control number is contained indata element ISA13 of the ISA segment. The identical control number must alsooccur in data element 02 of the IEA segment. Most commercial translation soft-ware products will verify that these two fields are identical. In most translationsoftware 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 meas-ures. For instance, the ISA segment contains data elements such as authoriza-tion information, security information, sender identification, and receiver identifica-tion that can be used for control purposes. These data elements are agreed uponby the trading partners prior to transmission and are contained in the written trad-ing partner agreement. The interchange date and time data elements as well asthe interchange control number within the ISA segment are used for debuggingpurposes when there is a problem with the transmission or the interchange.

Data Element ISA12, Interchange Control Version Number, indicates the versionof the ISA/IEA envelope. The ISA12 does not indicate the version of the transac-tion set that is being transmitted but rather the envelope that encapsulates thetransaction. An Interchange Acknowledgment can be denoted through data ele-ment ISA14. The acknowledgment that would be sent in reply to a “yes” conditionin data element ISA14 would be the TA1 segment. Data element ISA15, Test Indi-cator, is used between trading partners to indicate that the transmission is in a“test” or “production” mode. This becomes significant when the production phaseof the project is to commence. Data element ISA16, Subelement Separator, isused by the translator for interpretation of composite data elements.

The ending component of the interchange or ISA/IEA envelope is the IEA seg-ment. Data element IEA01 indicates the number of functional groups that are in-cluded within the interchange. In most commercial translation software products,an aggregate count of functional groups is kept while interpreting the inter-change. This count is then verified with data element IEA01. If there is a discrep-ancy, in most commercial products, the interchange is suspended. The other dataelement in the IEA segment is IEA02 which is referenced above.

See the Appendix B, EDI Control Directory, for a complete detailing of the inter-change control header and trailer. The authors recommend that when two trans-actions with different X12 versions numbers are sent in one interchange controlstructure (multiple functional groups within one ISA/IEA envelope), the Inter-change 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 withmixed 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 iden-tifier code in GS01. The Functional Identifier Code is used by the commercialtranslation software during interpretation of the interchange to determine the dif-ferent transaction sets that may be included within the functional group. If an inap-propriate transaction set is contained within the functional group, most commer-cial translation software will suspend the functional group within the interchange.The Application Sender’s Code in GS02 can be used to identify the sending unitof the transmission. The Application Receiver’s Code in GS03 can be used toidentify the receiving unit of the transmission. For health care, this unit identifica-tion can be used to differentiate between managed care, indemnity, and Medi-care. The functional group contains a creation date (GS04) and creation time(GS05) for the functional group. The Group Control Number is contained inGS06. These data elements (GS04, GS05, AND GS06) can be used for debug-ging purposes during problem resolution. GS08,Version/Release/Industry Identi-fier Code is the version/release/sub-release of the transaction sets being transmit-ted in this functional group. Appendix B provides guidance for the value for thisdata element. The GS08 does not represent the version of the interchange(ISA/IEA) envelope but rather the version/release/sub-release of the transactionsets that are encompassed within the GS/GE envelope.

The Functional Group Control Number in GS06 must be identical to data element02 of the GE segment. Data element GE01 indicates the number of transactionsets within the functional group. In most commercial translation software prod-ucts, an aggregate count of the transaction sets is kept while interpreting the func-tional group. This count is then verified with data element GE01.

See the Appendix B, EDI Control Directory, for a complete detailing of the func-tional 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 detailinformation using a hierarchical structure, such as relating dependents to a sub-scriber. Hierarchical levels may differ from guide to guide. The following diagram,from transaction set 837, illustrates a typical hierarchy.

Each provider can bill for one or more subscribers, each subscriber can have oneor more dependents and the subscriber and the dependents can make one ormore claims. Each guide states what levels are available, the level’s requirement,a repeat value, and whether that level has subordinate levels within a transmis-sion.

For implementations compliant with this guide, the repeats of the loops identifiedby 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

Dependents Subscribers Provider


A.14 MAY 2004

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

A.1.1.5 Acknowledgments

A.1.1.5.1 Interchange Acknowledgment, TA1

The Interchange or TA1 Acknowledgment is a means of replying to an inter-change or transmission that has been sent. The TA1 verifies the envelopes only.Transaction set-specific verification is accomplished through use of the Func-tional Acknowledgment Transaction Set, 997. See A.1.1.5.2, Functional Acknow-ledgment, 997, for more details. The TA1 is a single segment and is unique in thesense that this single segment is transmitted without the GS/GE envelope struc-tures. A TA1 can be included in an interchange with other functional groups andtransactions.

Encompassed in the TA1 are the interchange control number, interchange dateand time, interchange acknowledgment code, and the interchange note code.The interchange control number, interchange date and time are identical to thosethat were present in the transmitted interchange from the sending trading partner.This provides the capability to associate the TA1 with the transmitted inter-change. TA104, Interchange Acknowledgment Code, indicates the status of theinterchange control structure. This data element stipulates whether the transmit-ted interchange was accepted with no errors, accepted with errors, or rejected be-cause of errors. TA105, Interchange Note Code, is a numerical code that indi-cates the error found while processing the interchange control structure. Valuesfor this data element indicate whether the error occurred at the interchange orfunctional group envelope.

The TA1 segment provides the capability for the receiving trading partner to notifythe sending trading partner of problems that were encountered in the interchangecontrol structure.

Due to the uniqueness of the TA1, implementation should be predicated upon theability for the sending and receiving trading partners commercial translators to ac-commodate the uniqueness of the TA1. Unless named as mandatory in the Fed-eral 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 TA1segment.

A.1.1.5.2 Functional Acknowledgment, 997

The Functional Acknowledgment Transaction Set, 997, has been designed to al-low trading partners to establish a comprehensive control function as a part oftheir business exchange process. This acknowledgment process facilitates con-trol of EDI. There is a one-to-one correspondence between a 997 and a func-tional group. Segments within the 997 can identify the acceptance or rejection ofthe functional group, transaction sets or segments. Data elements in error canalso be identified. There are many EDI implementations that have incorporatedthe acknowledgment process in all of their electronic communications. Typically,the 997 is used as a functional acknowledgment to a previously transmitted func-tional group. Many commercially available translators can automatically generatethis transaction set through internal parameter settings. Additionally translatorswill 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 partnercan determine if the receiving trading partner has received ASC X12 transactionsets through reports that can be generated by the translation software to identifytransmissions that have not been acknowledged.

As stated previously the 997 is a transaction set and thus is encapsulated withinthe interchange control structure (envelopes) for transmission.

As with any information flow, an acknowledgment process is essential. If an “auto-matic” acknowledgment process is desired between trading partners then it is rec-ommended that the 997 be used. Unless named as mandatory in the FederalRules implementing HIPAA, use of the 997, although recommended by theauthors, is not mandated.

See Appendix B, EDI Control Directory, for a complete detailing of transaction set997.

A.2 Other SyntaxesThis Implementation Guide may contain support for additional transmission syn-taxes. Additional syntaxes include but are not limited to, eXtensible Markup Lan-guage (XML). Such support is included at the discretion of the authors.

Inclusion of additional transmission syntaxes does not mandate use of these syn-taxes. For example, these syntaxes do not satisfy the HIPAA requirements forstandardization unless a future HIPAA rule mandates or allows the additionaltransmission syntax. Other willing trading partners may agree to exchange theseadditional 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 arederived, in part, from the ASC X12N Data Element Dictionaries. See Section 3.1for 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 flexiblemanner via different transmission syntax while retaining all information. The de-sign includes a naming convention that enables transmitting, validating, and inter-preting the data between applications and organizations while being flexible intransport, 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 - InformationSource Level and 2100A - Information Source. XML tag names must begin with aletter. Since the Object Descriptors begin with a number, the authors of this Imple-mentation Guide suggest adding an “X” when constructing XML documents. Inthe 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>

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

• IEAInterchange Control Trailer Segment

• GSFunctional Group Header Segment

• GEFunctional Group Trailer Segment

• TA1Interchange Acknowledgment Segment

B.2 Functional Acknowledgment TransactionSet, 997


MAY 2004 B.1


B.2 MAY 2004

004050X151 • 002

JANUARY 31, 2003ISAINTERCHANGE CONTROL HEADER 004050X151 • 002 • ISAINTERCHANGE CONTROL HEADER

IMPLEMENTATION

INTERCHANGE CONTROL HEADER1000000 Notes: 1. For compliant implementations under this implementation guide,

ISA13, the interchange Control Number, must be a positive (thereforeunsigned) number. Therefore, the ISA segment can be considered afixed record length segment. All positions within each of the dataelements must be filled. The first element separator defines theelement separator to be used through the entire interchange. Thesegment terminator used after the ISA defines the segment terminatorto be used throughout the entire interchange. Spaces in the exampleare represented by “.” for clarity.

1000001 Example: ISA✽ 00✽ ..........✽ 01✽ SECRET....✽ ZZ✽ SUBMITTERS.ID..✽ ZZ✽

RECEIVERS.ID...✽ 930602✽ 1253✽ ^✽ 00405✽ 000000905✽ 1✽ T✽ :~

STANDARD

ISA Interchange Control Header

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

DIAGRAM

ISA01 I01 ISA02 I02 ISA03 I03 ISA04 I04 ISA05 I05 ISA06 I06

ISA ✽ Author InfoQualifier ✽ Author

Information ✽ SecurityInfo Qual ✽ Security

Information ✽ InterchangeID Qual ✽ Interchange

Sender IDM 1 ID 2/2 M 1 AN 10/10 M 1 ID 2/2 M 1 AN 10/10 M 1 ID 2/2 M 1 AN 15/15

ISA07 I05 ISA08 I07 ISA09 I08 ISA10 I09 ISA11 I65 ISA12 I11

✽ InterchangeID Qual ✽ Interchange

Receiver ID ✽ InterchangeDate ✽ Interchange

Time ✽ RepetitionSeparator ✽ Inter Ctrl

Version NumM 1 ID 2/2 M 1 AN 15/15 M 1 DT 6/6 M 1 TM 4/4 M 1 ID 1/1 M 1 ID 5/5

ISA13 I12 ISA14 I13 ISA15 I14 ISA16 I15

✽ Inter CtrlNumber ✽ Ack

Requested ✽ UsageIndicator ✽ Component

Elem Sepera ~

M 1 N0 9/9 M 1 ID 1/1 M 1 ID 1/1 M 1 1/1

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED ISA01 I01 Authorization Information Qualifier M 1 ID 2/2Code identifying the type of information in the Authorization Information

CODE DEFINITION

00 No Authorization Information Present (NoMeaningful Information in I02)

113 ADVISED UNLESS SECURITY REQUIREMENTSMANDATE USE OF ADDITIONAL IDENTIFICATIONINFORMATION.

03 Additional Data Identification

ASC X12N • INSURANCE SUBCOMMITTEEIMPLEMENTATION GUIDE CONTROL SEGMENTS

MAY 2004 B.3

REQUIRED ISA02 I02 Authorization Information M 1 AN 10/10Information used for additional identification or authorization of the interchangesender or the data in the interchange; the type of information is set by theAuthorization Information Qualifier (I01)

REQUIRED ISA03 I03 Security Information Qualifier M 1 ID 2/2Code identifying the type of information in the Security Information

CODE DEFINITION

00 No Security Information Present (No MeaningfulInformation in I04)

116 ADVISED UNLESS SECURITY REQUIREMENTSMANDATE USE OF PASSWORD DATA.

01 Password

REQUIRED ISA04 I04 Security Information M 1 AN 10/10This is used for identifying the security information about the interchange senderor the data in the interchange; the type of information is set by the SecurityInformation Qualifier (I03)

REQUIRED ISA05 I05 Interchange ID Qualifier M 1 ID 2/2Code indicating the system/method of code structure used to designate thesender or receiver ID element being qualified

1000002 This ID qualifies the Sender in ISA06.

CODE DEFINITION

01 Duns (Dun & Bradstreet)

14 Duns Plus Suffix

20 Health Industry Number (HIN)

CODE SOURCE 121: Health Industry Number

27 Carrier Identification Number as assigned by HealthCare Financing Administration (HCFA)

28 Fiscal Intermediary Identification Number asassigned by Health Care Financing Administration(HCFA)

29 Medicare Provider and Supplier IdentificationNumber as assigned by Health Care FinancingAdministration (HCFA)

30 U.S. Federal Tax Identification Number

33 National Association of Insurance CommissionersCompany Code (NAIC)

ZZ Mutually Defined

REQUIRED ISA06 I06 Interchange Sender ID M 1 AN 15/15Identification code published by the sender for other parties to use as the receiverID to route data to them; the sender always codes this value in the sender IDelement

ASC X12N • INSURANCE SUBCOMMITTEECONTROL SEGMENTS IMPLEMENTATION GUIDE

B.4 MAY 2004

REQUIRED ISA07 I05 Interchange ID Qualifier M 1 ID 2/2Code indicating the system/method of code structure used to designate thesender or receiver ID element being qualified

1000003 This ID qualifies the Receiver in ISA08.

CODE DEFINITION

01 Duns (Dun & Bradstreet)

14 Duns Plus Suffix

20 Health Industry Number (HIN)

CODE SOURCE 121: Health Industry Number

27 Carrier Identification Number as assigned by HealthCare Financing Administration (HCFA)

28 Fiscal Intermediary Identification Number asassigned by Health Care Financing Administration(HCFA)

29 Medicare Provider and Supplier IdentificationNumber as assigned by Health Care FinancingAdministration (HCFA)

30 U.S. Federal Tax Identification Number

33 National Association of Insurance CommissionersCompany Code (NAIC)

ZZ Mutually Defined

REQUIRED ISA08 I07 Interchange Receiver ID M 1 AN 15/15Identification code published by the receiver of the data; When sending, it is usedby the sender as their sending ID, thus other parties sending to them will use thisas a receiving ID to route data to them

REQUIRED ISA09 I08 Interchange Date M 1 DT 6/6Date of the interchange

1000006 The date format is YYMMDD.

REQUIRED ISA10 I09 Interchange Time M 1 TM 4/4Time of the interchange

1000007 The time format is HHMM.

REQUIRED ISA11 I65 Repetition Separator M 1 ID 1/1Type is not applicable; the repetition separator is a delimiter and not a dataelement; this field provides the delimiter used to separate repeated occurrencesof a simple data element or a composite data structure; this value must bedifferent than the data element separator, component element separator, and thesegment terminator

REQUIRED ISA12 I11 Interchange Control Version Number M 1 ID 5/5Code specifying the version number of the interchange control segments

CODE DEFINITION

00405 Standards Approved for Publication by ASC X12Procedures Review Board through October 2001


MAY 2004 B.5

REQUIRED ISA13 I12 Interchange Control Number M 1 N0 9/9A control number assigned by the interchange sender

1000004 The Interchange Control Number, ISA13, must be identical to theassociated Interchange Trailer IEA02.

REQUIRED ISA14 I13 Acknowledgment Requested M 1 ID 1/1Code indicating sender’s request for an interchange acknowledgment

1000038 See Section A.1.1.5.1 for interchange acknowledgment information.

CODE DEFINITION

0 No Interchange Acknowledgment Requested

1 Interchange Acknowledgment Requested (TA1)

REQUIRED ISA15 I14 Interchange Usage Indicator M 1 ID 1/1Code indicating whether data enclosed by this interchange envelope is test,production or information

CODE DEFINITION

P Production Data

T Test Data

REQUIRED ISA16 I15 Component Element Separator M 1 1/1Type is not applicable; the component element separator is a delimiter and not adata element; this field provides the delimiter used to separate component dataelements within a composite data structure; this value must be different than thedata element separator and the segment terminator


B.6 MAY 2004

IEAINTERCHANGE CONTROL TRAILER 004050X151 • 002 • IEAINTERCHANGE CONTROL TRAILER

IMPLEMENTATION

INTERCHANGE CONTROL TRAILER1000005 Example: IEA✽ 1✽ 000000905~

STANDARD

IEA Interchange Control Trailer

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

DIAGRAM

IEA01 I16 IEA02 I12

IEA ✽ Num of InclFunct Group ✽ Inter Ctrl

Number ~

M 1 N0 1/5 M 1 N0 9/9

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED IEA01 I16 Number of Included Functional Groups M 1 N0 1/5A count of the number of functional groups included in an interchange

REQUIRED IEA02 I12 Interchange Control Number M 1 N0 9/9A control number assigned by the interchange sender


MAY 2004 B.7

GSFUNCTIONAL GROUP HEADER 004050X151 • 002 • GSFUNCTIONAL GROUP HEADER

IMPLEMENTATION

FUNCTIONAL GROUP HEADER1000054 Example: GS✽ PI✽ SENDER CODE✽ RECEIVER

CODE✽ 19940331✽ 0802✽ 1✽ X✽ 004050X151~

STANDARD

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 ✽ FunctionalID Code ✽ Application

Send’s Code ✽ ApplicationRec’s Code ✽ Date ✽ Time ✽ Group Ctrl

NumberM 1 ID 2/2 M 1 AN 2/15 M 1 AN 2/15 M 1 DT 8/8 M 1 TM 4/8 M 1 N0 1/9

GS07 455 GS08 480

✽ ResponsibleAgency Code ✽ Ver/Release

ID Code ~

M 1 ID 1/2 M 1 AN 1/12

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED GS01 479 Functional Identifier Code M 1 ID 2/2Code identifying a group of application related transaction sets

CODE DEFINITION

PI Patient Information (275)

REQUIRED GS02 142 Application Sender’s Code M 1 AN 2/15Code identifying party sending transmission; codes agreed to by trading partners

1000009 Use this code to identify the unit sending the information.

REQUIRED GS03 124 Application Receiver’s Code M 1 AN 2/15Code identifying party receiving transmission; codes agreed to by trading partners

1000010 Use this code to identify the unit receiving the information.

REQUIRED GS04 373 Date M 1 DT 8/8Date expressed as CCYYMMDD where CC represents the first two digits of thecalendar year

SEMANTIC: GS04 is the group date.

1000011 Use this date for the functional group creation date.

REQUIRED GS05 337 Time M 1 TM 4/8Time expressed in 24-hour clock time as follows: HHMM, or HHMMSS, orHHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-59), S =integer seconds (00-59) and DD = decimal seconds; decimal seconds areexpressed 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 isHHMM.


B.8 MAY 2004

REQUIRED GS06 28 Group Control Number M 1 N0 1/9Assigned number originated and maintained by the sender

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

1000131 For implementations compliant with this guide, GS06 must beunique within a single transmission (that is, within a single ISA toIEA enveloping structure). The authors recommend that GS06 beunique within all transmissions over a period of time to bedetermined by the sender.

REQUIRED GS07 455 Responsible Agency Code M 1 ID 1/2Code identifying the issuer of the standard; this code is used in conjunction withData Element 480

CODE DEFINITION

X Accredited Standards Committee X12

REQUIRED GS08 480 Version / Release / Industry Identifier Code M 1 AN 1/12Code indicating the version, release, subrelease, and industry identifier of the EDIstandard being used, including the GS and GE segments; if code in DE455 in GSsegment is X, then in DE 480 positions 1-3 are the version number; positions 4-6are the release and subrelease, level of the version; and positions 7-12 are theindustry or trade association identifiers (optionally assigned by user); if code inDE455 in GS segment is T, then other formats are allowed

CODE SOURCE 881: Version / Release / Industry Identifier Code

CODE DEFINITION

004050X151 Standards Approved for Publication by ASC X12Procedures Review Board through October 2001, aspublished in this implementation guide.


MAY 2004 B.9

GEFUNCTIONAL GROUP TRAILER 004050X151 • 002 • GEFUNCTIONAL GROUP TRAILER

IMPLEMENTATION

FUNCTIONAL GROUP TRAILER1000013 Example: GE✽ 1✽ 1~

STANDARD

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 ofTS Included ✽ Group Ctrl

Number ~

M 1 N0 1/6 M 1 N0 1/9

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED GE01 97 Number of Transaction Sets Included M 1 N0 1/6Total 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 M 1 N0 1/9Assigned number originated and maintained by the sender

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


B.10 MAY 2004

TA1INTERCHANGE ACKNOWLEDGMENT 004050X151 • 002 • TA1INTERCHANGE ACKNOWLEDGMENT

IMPLEMENTATION

INTERCHANGE ACKNOWLEDGMENT1000014 Notes: 1. All fields must contain data.

1000015 2. This segment acknowledges the reception of an X12 interchangeheader and trailer from a previous interchange. If the header/trailerpair was received correctly, the TA1 reflects a valid interchange,regardless of the validity of the contents of the data included insidethe header/trailer envelope.

1000076 3. See A.1.1.5.1, Interchange Acknowledgment, TA1, for interchangeacknowledgment.

1000077 4. Use of TA1 is subject to trading partner agreement and is neithermandated or prohibited in the Appendix.

1000016 Example: TA1✽ 000000905✽ 940101✽ 0100✽ A✽ 000~

STANDARD

TA1 Interchange Acknowledgment

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

DIAGRAM

TA101 I12 TA102 I08 TA103 I09 TA104 I17 TA105 I18

TA1 ✽ Inter CtrlNumber ✽ Interchange

Date ✽ InterchangeTime ✽ Interchange

Ack Code ✽ InterchangeNote Code ~

M 1 N0 9/9 M 1 DT 6/6 M 1 TM 4/4 M 1 ID 1/1 M 1 ID 3/3

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED TA101 I12 Interchange Control Number M 1 N0 9/9A control number assigned by the interchange sender

1000017 This number uniquely identifies the interchange data to the sender.It is assigned by the sender. Together with the sender ID it uniquelyidentifies the interchange data to the receiver. It is suggested thatthe sender, receiver, and all third parties be able to maintain anaudit trail of interchanges using this number.

1000018 In the TA1, this should be the interchange control number of theoriginal interchange that this TA1 is acknowledging.

REQUIRED TA102 I08 Interchange Date M 1 DT 6/6Date of the interchange

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


MAY 2004 B.11

REQUIRED TA103 I09 Interchange Time M 1 TM 4/4Time of the interchange

1000020 This is the time of the original interchange being acknowledged.(HHMM)

REQUIRED TA104 I17 Interchange Acknowledgment Code M 1 ID 1/1Code indicating the status of the receipt of the interchange control structure

CODE DEFINITION

A The Transmitted Interchange Control StructureHeader and Trailer Have Been Received and HaveNo Errors.

E The Transmitted Interchange Control StructureHeader and Trailer Have Been Received and AreAccepted But Errors Are Noted. This Means theSender Must Not Resend This Data.

R The Transmitted Interchange Control StructureHeader and Trailer are Rejected Because of Errors.

REQUIRED TA105 I18 Interchange Note Code M 1 ID 3/3Code specifying the error found processing the interchange control structure

CODE DEFINITION

000 No error

001 The Interchange Control Number in the Header andTrailer Do Not Match. The Value From the Header isUsed in the Acknowledgment.

002 This Standard as Noted in the Control StandardsIdentifier is Not Supported.

003 This Version of the Controls is Not Supported

004 The Segment Terminator is Invalid

005 Invalid Interchange ID Qualifier for Sender

006 Invalid Interchange Sender ID

007 Invalid Interchange ID Qualifier for Receiver

008 Invalid Interchange Receiver ID

009 Unknown Interchange Receiver ID

010 Invalid Authorization Information Qualifier Value

011 Invalid Authorization Information Value

012 Invalid Security Information Qualifier Value

013 Invalid Security Information Value

014 Invalid Interchange Date Value

015 Invalid Interchange Time Value

016 Invalid Interchange Standards Identifier Value


B.12 MAY 2004

017 Invalid Interchange Version ID Value

018 Invalid Interchange Control Number Value

019 Invalid Acknowledgment Requested Value

020 Invalid Test Indicator Value

021 Invalid Number of Included Groups Value

022 Invalid Control Structure

023 Improper (Premature) End-of-File (Transmission)

024 Invalid Interchange Content (e.g., Invalid GSSegment)

025 Duplicate Interchange Control Number

026 Invalid Data Element Separator

027 Invalid Component Element Separator

028 Invalid Delivery Date in Deferred Delivery Request

029 Invalid Delivery Time in Deferred Delivery Request

030 Invalid Delivery Time Code in Deferred DeliveryRequest

031 Invalid Grade of Service Code


MAY 2004 B.13


B.14 MAY 2004

004050X151 • 997

JANUARY 31, 2003STANDARD

997 Functional AcknowledgmentFunctional Group ID: FA

This X12 Transaction Set contains the format and establishes the data contents of theFunctional Acknowledgment Transaction Set (997) for use within the context of an ElectronicData Interchange (EDI) environment. The transaction set can be used to define the controlstructures for a set of acknowledgments to indicate the results of the syntactical analysis of theelectronically encoded documents. The encoded documents are the transaction sets, which aregrouped in functional groups, used in defining transactions for business data interchange. Thisstandard does not cover the semantic meaning of the information encoded in the transactionsets.

Table 1 - Header


0100 ST Transaction Set Header M 10200 AK1 Functional Group Response Header M 1

LOOP ID - AK2 999999 0300 AK2 Transaction Set Response Header O 1

LOOP ID - AK2/AK3 999999 0400 AK3 Data Segment Note O 10500 AK4 Data Element Note O 990600 AK5 Transaction Set Response Trailer M 10700 AK9 Functional Group Response Trailer M 10800 SE Transaction Set Trailer M 1

NOTES:

1/0100 These acknowledgments shall not be acknowledged, thereby preventing an endless cycle of acknowledgments of acknow-

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

tion Sets. In preparing the functional group of acknowledgments, the application sender’s code and the application re-

ceiver’s code, taken from the functional group being acknowledged, are exchanged; therefore, one acknowledgment

functional group responds to only those functional groups from one application receiver’s code to one application sender’s

code.

1/0100 There is only one Functional Acknowledgment Transaction Set per acknowledged functional group.

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

1/0200 The Functional Acknowledgement is generated at the point of translation, intended for the originator (not any intermediate

parties).

1/0300 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 acknow-

ledged.

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

STTRANSACTION SET HEADER 004050X151 • 997 • STTRANSACTION SET HEADER

IMPLEMENTATION

TRANSACTION SET HEADERUsage: REQUIRED

Repeat: 1

1000078 Notes: 1. Use of the 997 transaction is subject to trading partner agreement oraccepted usage and is neither mandated nor prohibited in thisAppendix.

500 Example: ST✽ 997✽ 1234004050X151~

STANDARD


Level: Header

Position: 0100

Loop: ____


Max Use: 1


Set Notes: 1. These acknowledgments shall not be acknowledged, thereby preventing anendless cycle of acknowledgments of acknowledgments. Nor shall aFunctional Acknowledgment be sent to report errors in a previousFunctional Acknowledgment.

2. The Functional Group Header Segment (GS) is used to start the envelopefor the Functional Acknowledgment Transaction Sets. In preparing thefunctional group of acknowledgments, the application sender’s code andthe application receiver’s code, taken from the functional group beingacknowledged, are exchanged; therefore, one acknowledgment functionalgroup responds to only those functional groups from one applicationreceiver’s code to one application sender’s code.

3. There is only one Functional Acknowledgment Transaction Set peracknowledged functional group.

DIAGRAM

ST01 143 ST02 329 ST03 1705



M 1 ID 3/3 M 1 AN 4/9 O 1 AN 1/35

004050X151 • 997 • ST ASC X12N • INSURANCE SUBCOMMITTEETRANSACTION SET HEADER IMPLEMENTATION GUIDE

B.16 MAY 2004

ELEMENT SUMMARY

USAGEREF.DES.




CODE DEFINITION

997 Functional Acknowledgment


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

524 Use the corresponding value in ST02 for this transaction set.

SITUATIONAL ST03 1705 Implementation Convention Reference O 1 AN 1/35Reference assigned to identify Implementation Convention

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

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

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 997 • STIMPLEMENTATION GUIDE TRANSACTION SET HEADER

MAY 2004 B.17

AK1FUNCTIONAL GROUP RESPONSE HEADER 004050X151 • 997 • AK1FUNCTIONAL GROUP RESPONSE HEADER

IMPLEMENTATION

FUNCTIONAL GROUP RESPONSE HEADERUsage: REQUIRED

Repeat: 1

502 Example: AK1✽ CI✽ 1~

STANDARD

AK1 Functional Group Response Header

Level: Header

Position: 0200

Loop: ____


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 theacknowledgment for a functional group. There shall be one AK1 segmentfor 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 ✽ FunctionalID Code

✽ Group CtrlNumber

✽ Ver/ReleaseID Code ~

M 1 ID 2/2 M 1 N0 1/9 O 1 AN 1/12

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED AK101 479 Functional Identifier Code M 1 ID 2/2Code identifying a group of application related transaction sets

SEMANTIC: AK101 is the functional ID found in the GS segment (GS01) in thefunctional group being acknowledged.

1000140 When acknowledging a transaction specified in this implementationguide, the code value in AK101 will be the same value as given forGS01 in this appendix.

REQUIRED AK102 28 Group Control Number M 1 N0 1/9Assigned number originated and maintained by the sender

SEMANTIC: AK102 is the functional group control number found in the GS segmentin the functional group being acknowledged.

004050X151 • 997 • AK1 ASC X12N • INSURANCE SUBCOMMITTEEFUNCTIONAL GROUP RESPONSE HEADER IMPLEMENTATION GUIDE

B.18 MAY 2004

SITUATIONAL AK103 480 Version / Release / Industry Identifier Code O 1 AN 1/12Code indicating the version, release, subrelease, and industry identifier of the EDIstandard being used, including the GS and GE segments; if code in DE455 in GSsegment is X, then in DE 480 positions 1-3 are the version number; positions 4-6are the release and subrelease, level of the version; and positions 7-12 are theindustry or trade association identifiers (optionally assigned by user); if code inDE455 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.

CODE SOURCE 881: Version / Release / Industry Identifier Code

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 997 • AK1IMPLEMENTATION GUIDE FUNCTIONAL GROUP RESPONSE HEADER

MAY 2004 B.19

AK2TRANSACTION SET RESPONSE HEADER 004050X151 • 997 • AK2 • AK2TRANSACTION SET RESPONSE HEADER

IMPLEMENTATION

TRANSACTION SET RESPONSE HEADERLoop: AK2 — TRANSACTION SET RESPONSE HEADER Repeat: 999999

Usage: SITUATIONAL

Repeat: 1

1000079 Notes: 1. Required when communicating information about a transaction setwithin a functional group identified in AK1.

503 Example: AK2✽ 811✽ 000000905~

STANDARD

AK2 Transaction Set Response Header

Level: Header

Position: 0300

Loop: AK2 Repeat: 999999


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 thereceived functional group. The AK2 segments shall appear in the sameorder as the transaction sets in the functional group that has been receivedand is being acknowledged.

DIAGRAM

AK201 143 AK202 329 AK203 1705

AK2 ✽ TS IDCode ✽ TS Control


M 1 ID 3/3 M 1 AN 4/9 O 1 AN 1/35

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED AK201 143 Transaction Set Identifier Code M 1 ID 3/3Code uniquely identifying a Transaction Set

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

1000141 When acknowledging a transaction specified in this implementationguide, the code value in AK201 will be the same value as given forST01 in this implementation guide.

REQUIRED AK202 329 Transaction Set Control Number M 1 AN 4/9Identifying control number that must be unique within the transaction setfunctional group assigned by the originator for a transaction set

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

004050X151 • 997 • AK2 • AK2 ASC X12N • INSURANCE SUBCOMMITTEETRANSACTION SET RESPONSE HEADER IMPLEMENTATION GUIDE

B.20 MAY 2004

SITUATIONAL AK203 1705 Implementation Convention Reference O 1 AN 1/35Reference assigned to identify Implementation Convention

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

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 997 • AK2 • AK2IMPLEMENTATION GUIDE TRANSACTION SET RESPONSE HEADER

MAY 2004 B.21

AK3DATA SEGMENT NOTE 004050X151 • 997 • AK2/AK3 • AK3DATA SEGMENT NOTE

IMPLEMENTATION

DATA SEGMENT NOTELoop: AK2/AK3 — DATA SEGMENT NOTE Repeat: 999999

Usage: SITUATIONAL

Repeat: 1

1000132 Notes: 1. Required and used only when there are errors to report in atransaction and the sender’s system has the capability to identify andreport the data required in this segment.

504 Example: AK3✽ NM1✽ 10✽✽ 7~

STANDARD

AK3 Data Segment Note

Level: Header

Position: 0400

Loop: AK2/AK3 Repeat: 999999


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 thesyntactical analysis of the functional groups of transaction sets; they reportthe extent to which the syntax complies with the standards or propersubsets of transaction sets and functional groups. They do not report on thesemantic meaning of the transaction sets (for example, on the ability of thereceiver to comply with the request of the sender).

DIAGRAM

AK301 721 AK302 719 AK303 447 AK304 720

AK3 ✽ Segment IDCode ✽ Segment Pos

in TS ✽ Loop IDCode ✽ Segment Syn

Error Code ~

M 1 ID 2/3 M 1 N0 1/6 O 1 AN 1/4 O 1 ID 1/3

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED AK301 721 Segment ID Code M 1 ID 2/3Code 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 asegment.

004050X151 • 997 • AK2/AK3 • AK3 ASC X12N • INSURANCE SUBCOMMITTEEDATA SEGMENT NOTE IMPLEMENTATION GUIDE

B.22 MAY 2004

REQUIRED AK302 719 Segment Position in Transaction Set M 1 N0 1/6The numerical count position of this data segment from the start of the transactionset: the transaction set header is count position 1

506 This is a data count, not a segment position in the standarddescription.

SITUATIONAL AK303 447 Loop Identifier Code O 1 AN 1/4The loop ID number given on the transaction set diagram is the value for this dataelement in segments LS and LE

507 Code identifying a loop within the transaction set which is boundedby the related LS and LE segments (corresponding LS and LEsegments must have the same value for loop identifier). (Note: Theloop ID number given on the transaction set diagram isrecommended as the value for this data element in the segmentsLS and LE.)

1000142 Use only when there is an error in a loop bounded by segments LSand LE and the sender’s system has the capability to identify thisinformation.

SITUATIONAL AK304 720 Segment Syntax Error Code O 1 ID 1/3Code indicating error found based on the syntax editing of a segment

1000133 Required and used only when an error exists and the error can bedescribed by one of the codes listed for this data element.

CODE DEFINITION

1 Unrecognized segment ID

2 Unexpected segment

3 Mandatory segment missing

4 Loop Occurs Over Maximum Times

5 Segment Exceeds Maximum Use

6 Segment Not in Defined Transaction Set

7 Segment Not in Proper Sequence

8 Segment Has Data Element Errors

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 997 • AK2/AK3 • AK3IMPLEMENTATION GUIDE DATA SEGMENT NOTE

MAY 2004 B.23

AK4DATA ELEMENT NOTE 004050X151 • 997 • AK2/AK3 • AK4DATA ELEMENT NOTE

IMPLEMENTATION

DATA ELEMENT NOTELoop: AK2/AK3 — DATA SEGMENT NOTE

Usage: SITUATIONAL

Repeat: 99

1000134 Notes: 1. Required and used only when there are errors to report in a dataelement or composite data element and when the sender’s system canidentify those errors and report the data required in this segment.

509 Example: AK4✽ 1✽ 98✽ 7✽ 11Z~

STANDARD

AK4 Data Element Note

Level: Header

Position: 0500

Loop: AK2/AK3


Max Use: 99

Purpose: To report errors in a data element or composite data structure and identify thelocation of the data element

DIAGRAM

AK401 C030 AK402 725 AK403 723 AK404 724

AK4 ✽ Positionin Segment ✽ Data Elemnt

Ref Number ✽ Data ElemntError Code ✽ Copy of Bad

Data Elemnt ~

M 1 O 1 N0 1/4 M 1 ID 1/3 O 1 AN 1/99

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED AK401 C030 POSITION IN SEGMENT M 1Code indicating the relative position of the simple data element or composite datastructure in error within a segment, count beginning with 1 for the positionimmediately following the segment ID; additionally indicating the relative positionof a repeating structure in error, count beginning with 1 for the positionimmediately following the preceding element separator; additionally indicating therelative position of a component of a composite data structure in error, countbeginning with 1 for the position following the preceding element or repetitionseparator

REQUIRED AK401 - 1 722 Element Position in Segment M N0 1/2This is used to indicate the relative position of a simple data element, orthe relative position of a composite data structure with the relativeposition of the component within the composite data structure, in error;in the data segment the count starts with 1 for the simple data elementor composite data structure immediately following the segment ID

004050X151 • 997 • AK2/AK3 • AK4 ASC X12N • INSURANCE SUBCOMMITTEEDATA ELEMENT NOTE IMPLEMENTATION GUIDE

B.24 MAY 2004

SITUATIONAL AK401 - 2 1528 Component Data Element Position inComposite

O N0 1/2

To identify the component data element position within the compositethat is in error

1000082 Used only when an error occurs in a composite dataelement and the composite data element position can bedetermined.

SITUATIONAL AK401 - 3 1686 Repeating Data Element Position O N0 1/4To identify the specific repetition of a data element that is in error

SITUATIONAL AK402 725 Data Element Reference Number O 1 N0 1/4Reference number used to locate the data element in the Data Element Dictionary

ADVISORY: Under most circumstances, this element is expected to be sent.

CODE SOURCE 77: X12 Directories

1000135 Required and used only when the data element in error has areference number and the reference number can be determined andreported by the sender’s system.

1000136 An example of a reference number (the reference numbers for dataelements listed in this guide can be found in the segment detailinformation shown as data element numbers), is the number 725which is the reference number for this data element.

REQUIRED AK403 723 Data Element Syntax Error Code M 1 ID 1/3Code indicating the error found after syntax edits of a data element

CODE DEFINITION

1 Mandatory data element missing

2 Conditional required data element missing.

3 Too many data elements.

4 Data element too short.

5 Data element too long.

6 Invalid character in data element.

7 Invalid code value.

8 Invalid Date

9 Invalid Time

10 Exclusion Condition Violated

SITUATIONAL AK404 724 Copy of Bad Data Element O 1 AN 1/99This is a copy of the data element in error

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

1000137 Required and used only when the sender’s system can capture andreport the invalid data element, and only when the value to be usedfor AK404 is not an invalid character or character that wouldgenerate a syntax error.

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 997 • AK2/AK3 • AK4IMPLEMENTATION GUIDE DATA ELEMENT NOTE

MAY 2004 B.25

AK5TRANSACTION SET RESPONSE TRAILER 004050X151 • 997 • AK2 • AK5TRANSACTION SET RESPONSE TRAILER

IMPLEMENTATION

TRANSACTION SET RESPONSE TRAILERLoop: AK2/AK3 — DATA SEGMENT NOTE

Usage: REQUIRED

Repeat: 1

511 Example: AK5✽ E✽ 5~

STANDARD

AK5 Transaction Set Response Trailer

Level: Header

Position: 0600

Loop: AK2


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 AckCode ✽ TS Syntax

Error Code ✽ TS SyntaxError Code ✽ TS Syntax

Error Code ✽ TS SyntaxError Code ✽ TS Syntax

Error Code ~

M 1 ID 1/1 O 1 ID 1/3 O 1 ID 1/3 O 1 ID 1/3 O 1 ID 1/3 O 1 ID 1/3

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED AK501 717 Transaction Set Acknowledgment Code M 1 ID 1/1Code indicating accept or reject condition based on the syntax editing of thetransaction set

CODE DEFINITION

A Accepted

ADVISED

E Accepted But Errors Were Noted

M Rejected, Message Authentication Code (MAC)Failed

R Rejected

ADVISED

W Rejected, Assurance Failed Validity Tests

X Rejected, Content After Decryption Could Not BeAnalyzed

004050X151 • 997 • AK2 • AK5 ASC X12N • INSURANCE SUBCOMMITTEETRANSACTION SET RESPONSE TRAILER IMPLEMENTATION GUIDE

B.26 MAY 2004

SITUATIONAL AK502 718 Transaction Set Syntax Error Code O 1 ID 1/3Code indicating error found based on the syntax editing of a transaction set

1000138 Required and used only when an error exists.

CODE DEFINITION

1 Transaction Set Not Supported

2 Transaction Set Trailer Missing

3 Transaction Set Control Number in Header andTrailer Do Not Match

4 Number of Included Segments Does Not MatchActual Count

5 One or More Segments in Error

6 Missing or Invalid Transaction Set Identifier

7 Missing or Invalid Transaction Set Control Number

8 Authentication Key Name Unknown

9 Encryption Key Name Unknown

10 Requested Service (Authentication or Encrypted)Not Available

11 Unknown Security Recipient

12 Incorrect Message Length (Encryption Only)

13 Message Authentication Code Failed

15 Unknown Security Originator

16 Syntax Error in Decrypted Text

17 Security Not Supported

19 Invalid Transaction Set Implementation ConventionReference

23 Transaction Set Control Number Not Unique withinthe Functional Group

24 S3E Security End Segment Missing for S3S SecurityStart Segment

25 S3S Security Start Segment Missing for S3ESecurity End Segment



ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 997 • AK2 • AK5IMPLEMENTATION GUIDE TRANSACTION SET RESPONSE TRAILER

MAY 2004 B.27


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







004050X151 • 997 • AK2 • AK5 ASC X12N • INSURANCE SUBCOMMITTEETRANSACTION SET RESPONSE TRAILER IMPLEMENTATION GUIDE

B.28 MAY 2004

AK9FUNCTIONAL GROUP RESPONSE TRAILER 004050X151 • 997 • AK9FUNCTIONAL GROUP RESPONSE TRAILER

IMPLEMENTATION

FUNCTIONAL GROUP RESPONSE TRAILERUsage: REQUIRED

Repeat: 1

513 Example: AK9✽ A✽ 1✽ 1✽ 1~

STANDARD

AK9 Functional Group Response Trailer

Level: Header

Position: 0700

Loop: ____


Max Use: 1

Purpose: To acknowledge acceptance or rejection of a functional group and report thenumber 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 2 AK905 716 AK906 716

AK9 ✽ Funct GroupAck Code ✽ Number of

TS Included ✽ Number ofReceived TS ✽ Number of

Accepted TS ✽ Funct GroupError Code ✽ Funct Group

Error CodeM 1 ID 1/1 M 1 N0 1/6 M 1 N0 1/6 M 1 N0 1/6 O 1 ID 1/3 O 1 ID 1/3

AK907 716 AK908 716 AK909 716

✽ Funct GroupError Code ✽ Funct Group

Error Code ✽ Funct GroupError Code ~

O 1 ID 1/3 O 1 ID 1/3 O 1 ID 1/3

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED AK901 715 Functional Group Acknowledge Code M 1 ID 1/1Code indicating accept or reject condition based on the syntax editing of thefunctional group

COMMENT: If AK901 contains the value “A” or “E”, then the transmitted functionalgroup is accepted.

CODE DEFINITION

A Accepted

ADVISED

E Accepted, But Errors Were Noted.

M Rejected, Message Authentication Code (MAC)Failed

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 997 • AK9IMPLEMENTATION GUIDE FUNCTIONAL GROUP RESPONSE TRAILER

MAY 2004 B.29

P Partially Accepted, At Least One Transaction SetWas Rejected

ADVISED

R Rejected

ADVISED

W Rejected, Assurance Failed Validity Tests

X Rejected, Content After Decryption Could Not BeAnalyzed

REQUIRED AK902 97 Number of Transaction Sets Included M 1 N0 1/6Total number of transaction sets included in the functional group or interchange(transmission) group terminated by the trailer containing this data element

514 This is the value in the original GE01.

REQUIRED AK903 123 Number of Received Transaction Sets M 1 N0 1/6Number of Transaction Sets received

REQUIRED AK904 2 Number of Accepted Transaction Sets M 1 N0 1/6Number of accepted Transaction Sets in a Functional Group

SITUATIONAL AK905 716 Functional Group Syntax Error Code O 1 ID 1/3Code indicating error found based on the syntax editing of the functional groupheader and/or trailer

1000138 Required and used only when an error exists.

CODE DEFINITION

1 Functional Group Not Supported

2 Functional Group Version Not Supported

3 Functional Group Trailer Missing

4 Group Control Number in the Functional GroupHeader and Trailer Do Not Agree

5 Number of Included Transaction Sets Does NotMatch Actual Count

6 Group Control Number Violates Syntax

10 Authentication Key Name Unknown

11 Encryption Key Name Unknown

12 Requested Service (Authentication or Encryption)Not Available

13 Unknown Security Recipient

14 Unknown Security Originator

15 Syntax Error in Decrypted Text

16 Security Not Supported

17 Incorrect Message Length (Encryption Only)

18 Message Authentication Code Failed

004050X151 • 997 • AK9 ASC X12N • INSURANCE SUBCOMMITTEEFUNCTIONAL GROUP RESPONSE TRAILER IMPLEMENTATION GUIDE

B.30 MAY 2004

19 Functional Group Control Number not Unique withinInterchange


24 S3S Security Start Segment Missing for S3E EndSegment











ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 997 • AK9IMPLEMENTATION GUIDE FUNCTIONAL GROUP RESPONSE TRAILER

MAY 2004 B.31

SETRANSACTION SET TRAILER 004050X151 • 997 • SETRANSACTION SET TRAILER

IMPLEMENTATION

TRANSACTION SET TRAILERUsage: REQUIRED

Repeat: 1

516 Example: SE✽ 27✽ 1234~

STANDARD


Level: Header

Position: 0800

Loop: ____


Max Use: 1


DIAGRAM

SE01 96 SE02 329


Number ~

M 1 N0 1/10 M 1 AN 4/9

ELEMENT SUMMARY

USAGEREF.DES.





004050X151 • 997 • SE ASC X12N • INSURANCE SUBCOMMITTEETRANSACTION SET TRAILER IMPLEMENTATION GUIDE

B.32 MAY 2004

C External Code Sources77 X12 Directories

SIMPLE DATA ELEMENT/CODE REFERENCES

721, 725

SOURCE

X12.3 Data Element DictionaryX12.22 Segment Directory

AVAILABLE FROM

Data Interchange Standards Association, Inc. (DISA)Suite 4307600 Leesburg PikeFalls Church, VA 22043

ABSTRACT

The data element dictionary contains the format and descriptions of data ele-ments used to construct X12 segments. It also contains code lists associatedwith these data elements. The segment directory contains the format and defini-tions of the data segments used to construct X12 transaction sets.

121 Health Industry NumberSIMPLE DATA ELEMENT/CODE REFERENCES

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

SOURCE

Health Industry Number Database

AVAILABLE FROM

Health Industry Business Communications Council5110 North 40th StreetPhoenix, AZ 85018

ABSTRACT

The HIN is a coding system, developed and administered by the Health IndustryBusiness Communications Council, that assigns a unique code number to hospi-tals other provider organizations, and manufacturers and distributors.

133 Current Procedural Terminology (CPT) CodesSIMPLE DATA ELEMENT/CODE REFERENCES

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

SOURCE

Physicians’ Current Procedural Terminology (CPT) Manual

AVAILABLE FROM

Order DepartmentAmerican Medical Association515 North State StreetChicago, IL 60610


MAY 2004 C.1

ABSTRACT

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

464 Health Industry Level 7 (HL7)SIMPLE DATA ELEMENT/CODE REFERENCES

756/HL

SOURCE

Health Level Standard Version 2.3

AVAILABLE FROM

Health Level 7 (HL7)Suite 2273300 Washtenaw AvenueAnn Arbor, MI 48104-4250

ABSTRACT

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

507 Health Care Claim Status Category CodeSIMPLE DATA ELEMENT/CODE REFERENCES

1271

SOURCE

Health Care Claim Status Category Code

AVAILABLE FROM

www.wpc-edi.comWashington Publishing Company5740 Industry Lane, 2nd FloorFrederick, MD 21704

ABSTRACT

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

537 Centers for Medicare and Medicaid Services NationalProvider IdentifierSIMPLE DATA ELEMENT/CODE REFERENCES

66/XX, 128/HPI

SOURCE

National Provider System


C.2 MAY 2004

AVAILABLE FROM

Centers for Medicare and Medicaid ServicesOffice of Financial ManagementDivision of Provider/Supplier EnrollmentC4-10-077500 Security BoulevardBaltimore, MD 21244-1850

ABSTRACT

The Centers for Medicare & Medicaid Services will develop the National ProviderIdentifier (NPI) following publication of the implementing regulation, which hasbeen proposed as the standard unique identifier for each health care provider un-der the Health Insurance Portability and Accountability Act of 1996.

540 Centers for Medicare and Medicaid Services PlanIDSIMPLE DATA ELEMENT/CODE REFERENCES

66/XV, 128/ABY

SOURCE

PlanID Database

AVAILABLE FROM

Centers for Medicare and Medicaid ServicesCenter of Beneficiary Services, Membership Operations GroupDivision of Benefit CoordinationS1-05-067500 Security BoulevardBaltimore, MD 21244-1850

ABSTRACT

The Centers for Medicare and Medicaid Services has joined with other payers todevelop a unique national payer identification number. The Centers for Medicareand Medicaid Services is the authorizing agent for enumerating payers throughthe services of a PlanID Registrar. It may also be used by other payers on a vol-untary basis.

663 Logical Observation Identifier Names and Codes(LOINC)SIMPLE DATA ELEMENT/CODE REFERENCES

128/LOI, 235/LB, 1270/LOI

SOURCE

Logical Observation Identifier Names and Codes (LOINC)

AVAILABLE FROM

Regenstrief Institute1050 Wishard Blvd., 5th FloorIndianapolis, IN 46202

ABSTRACT

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


MAY 2004 C.3

881 Version / Release / Industry Identifier CodeSIMPLE DATA ELEMENT/CODE REFERENCES

480

SOURCE

Data Interchange Standards Association

AVAILABLE FROM

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

ABSTRACT

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


C.4 MAY 2004

D Change Summary

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


MAY 2004 D.1


D.2 MAY 2004

E Data Element Name IndexThis appendix contains an alphabetic listing of data elements used in this im-plementation guide. Consult the Data Element Dictionary for the completelist. Data element names in normal type are generic ASC X12 names. Italictype indicates a health care industry defined name.

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

Additional InformationGathered DateDate additional information provided intransaction was gathered.D | 2100B | DTP03 | - | 1251 ...............79

ADDITIONAL INFORMATION REQUEST CODE

Additional Information RequestCodeCode identifying the additional informationrequested.D | 2000A | STC01 | C043-2 | 1271 ...............69

ADDITIONAL INFORMATION REQUEST MODIFIER

Additional Information RequestModifierA code that is used to modify the implicit scopeof an Additional Information Request CodeD | 2000A | STC10 | C043-2 | 1271 ...............70D | 2000A | STC11 | C043-2 | 1271 ...............71

ASSIGNED NUMBER

Assigned NumberNumber assigned for differentiation within atransaction set.D | 2000A | LX01 | - | 554 .................65

ASSOCIATED OBJECT REFERENCE IDENTIFICATION

Associated Object ReferenceIdentificationReference assigned by the application touniquely identify an object.H | | ORI01 | - | 1690 .................6

ATTACHMENT INFORMATION FORMAT CODE

Attachment Information FormatCodeA code that identifies the format of theattachment information being sent in the BINsegment.D | 2100B | CAT02 | - | 756 ................ 81

ATTACHMENT REPORT TYPE CODE

Attachment Report Type CodeCode to specify the type of attachment that isrelated to the claim.D | 2100B | CAT01 | - | 755 ................ 81

BILL TYPE IDENTIFIER

Bill Type IdentifierA code indicating the specific type of bill orclaim.H | 1000D | REF02 | - | 127 ................ 60

BINARY DATA

Binary DataA string of octets whch can assume any binarypattern from hexadecimal OO to FF.H | | BDS03 | - | 785 ................ 11D | 2110B | BIN02 | - | 785 ................ 84

BINARY DATA LENGTH NUMBER

Binary Data Length NumberExpession of the length of following binary datain the number of integral octets of the binarydata.H | | BDS02 | - | 784 ................ 11D | 2110B | BIN01 | - | 784 ................ 84

CLAIM SERVICE PERIOD

Claim Service PeriodThe beginning and end dates for the serviceperiod covered by a claim.H | 1000D | DTP03 | - | 1251 .............. 64

CLEARINGHOUSE TRACE NUMBER

H=Header, D=Detail, S=Summary

Loop ID

Segment ID/Reference Designator

Composite ID-Sequence

Data Element Number

Page Number

Name

Definition

Transaction Set ID

Locator Key


MAY 2004 E.1

Clearinghouse Trace NumberUnique tracking number for the transactionassigned by a clearinghouse.H | 1000D | REF02 | - | 127 ................ 63

CODE LIST QUALIFIER CODE

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

COMMUNICATION NUMBER QUALIFIER

Communication NumberQualifierCode identifying the type of communicationnumber.H | 1000A | PER03 | - | 365 ................ 44H | 1000A | PER05 | - | 365 ................ 45H | 1000A | PER07 | - | 365 ................ 45

CONTACT FUNCTION CODE

Contact Function CodeCode identifying the major duty or responsibilityof the person or group named.H | 1000A | PER01 | - | 366 ................ 44

DATE TIME PERIOD FORMAT QUALIFIER

Date Time Period FormatQualifierCode indicating the date format, time format, ordate and time format.H | 1000D | DTP02 | - | 1250 .............. 64D | 2100A | DTP02 | - | 1250 .............. 78D | 2100B | DTP02 | - | 1250 .............. 79

DATE TIME QUALIFIER

Date Time QualifierCode specifying the type of date or time or bothdate and time.H | 1000D | DTP01 | - | 374 ................ 64D | 2100A | DTP01 | - | 374 ................ 77D | 2100B | DTP01 | - | 374 ................ 79

ENTITY IDENTIFIER CODE

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

ENTITY TYPE QUALIFIER

Entity Type QualifierCode qualifying the type of entity.H | 1000A | NM102 | - | 1065 .............. 42H | 1000B | NM102 | - | 1065 .............. 47H | 1000C | NM102 | - | 1065 .............. 50H | 1000D | NM102 | - | 1065 .............. 55

FILTER ID CODE

Filter ID CodeCode specifying the type of filter used toconvert data code values.H | | BDS01 | - | 1570 ...............11

HEALTH CARE CLAIM STATUS CATEGORY CODE

Health Care Claim StatusCategory CodeCode indicating the category of the associatedclaim status code.D | 2000A | STC01 | C043-1 | 1271 .............. 69D | 2000A | STC10 | C043-1 | 1271 .............. 70D | 2000A | STC11 | C043-1 | 1271 .............. 70

IDENTIFICATION CODE QUALIFIER

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

IMPLEMENTATION CONVENTION REFERENCE IDENTIFIER

Implementation ConventionReference IdentifierIdentifies the ANSI Version and ImplementationGuide being used for this transaction.H | | ST03 | - | 1705 .............. 38

INFORMATION RECEIVER CONTACT COMMUNICATION NUMBER

Information Receiver ContactCommunication NumberCommunication Number for the Individual atinformation receiver to whom inquiries aboutthis transaction should be directed.H | 1000A | PER04 | - | 364 ................ 44H | 1000A | PER06 | - | 364 ................ 45H | 1000A | PER08 | - | 364 ................ 45

INFORMATION RECEIVER CONTACT NAME

Information Receiver ContactNameIndividual at information receiver to whominquiries about this transaction should bedirected.H | 1000A | PER02 | - | 93 .................. 44

LINE ITEM CONTROL NUMBER

Line Item Control NumberIdentifier assigned by the submitter/provider tothis line item.D | 2000A | REF02 | - | 127 ................ 73

MEDICAL RECORD NUMBER

Medical Record NumberA unique number assigned to patient by theprovider to assist in retrieval of medical records.H | 1000D | REF02 | - | 127 ................ 61

NUMBER OF INCLUDED SEGMENTS

Number of Included SegmentsTotal number of segments included in atransaction set including ST and SE segments.H | | SE01 | - | 96 .................. 12

OBJECT ATTRIBUTE IDENTIFICATION

Object Attribute IdentificationIdentification of the attribute applying to theobject type.H | | OOI03 | - | 1692 .............. 10

OBJECT IDENTIFICATION GROUP


E.2 MAY 2004

Object Identification GroupValue identifying the group used to link torelated object identifications.H | | OOI01 | - | 1694 ................ 9

OBJECT TYPE QUALIFIER

Object Type QualifierCode identifying type of object.H | | OOI02 | - | 1691 ................ 9

PATIENT ACCOUNT NUMBER

Patient Account NumberUnique identification number assigned by theprovider to the claim patient to facilitate postingof payment information and identification of thebilled claim.H | 1000D | REF02 | - | 127 ................ 58

PATIENT FIRST NAME

Patient First NameThe first name of the individual to whom theservices were provided.H | 1000D | NM104 | - | 1036 .............. 55

PATIENT LAST NAME

Patient Last NameThe last name of the individual to whom theservices were provided.H | 1000D | NM103 | - | 1035 .............. 55

PATIENT MIDDLE NAME

Patient Middle NameThe middle name of the individual to whom theservices were provided.H | 1000D | NM105 | - | 1037 .............. 55

PATIENT NAME SUFFIX

Patient Name SuffixSuffix to the name of the individual to whom theservices were provided.H | 1000D | NM107 | - | 1039 .............. 55

PATIENT PRIMARY IDENTIFIER

Patient Primary IdentifierIdentifier assigned by the payer to identify thepatientH | 1000D | NM109 | - | 67 .................. 56

PAYER OR PROVIDER’S CONTROL NUMBER

Payer or Provider’s ControlNumberThe Payer’s Claim Control Number from theRequest for Additional Information or theProvider’s Attachment Control Number from theClaim.D | 2000A | TRN02 | - | 127 ................ 67

PROCEDURE CODE

Procedure CodeCode identifying the procedure, product orservice.D | 2000A | REF02 | - | 127 ................ 75

PROVIDER FIRST NAME

Provider First NameThe first name of the provider of care submittinga transaction or related to the informationprovided in or request by the transaction.H | 1000C | NM104 | - | 1036 .............. 50

PROVIDER IDENTIFIER

Provider IdentifierNumber assigned by the payer, regulatoryauthority, or other authorized body or agency toidentify the provider.H | 1000C | NM109 | - | 67 .................. 51

PROVIDER LAST OR ORGANIZATION NAME

Provider Last or OrganizationNameThe last name of the provider of care or nameof the provider organization submitting atransaction or related to the informationprovided in or request by the transaction.H | 1000C | NM103 | - | 1035 .............. 50

PROVIDER MIDDLE NAME

Provider Middle NameThe middle name of the provider of caresubmitting a transaction or related to theinformation provided in or request by thetransaction.H | 1000C | NM105 | - | 1037 .............. 50

PROVIDER NAME SUFFIX

Provider Name SuffixThe name suffix of the provider of caresubmitting a transaction or related to theinformation provided in or request by thetransaction.H | 1000C | NM107 | - | 1039 .............. 50

PROVIDER SECONDARY IDENTIFIER

Provider Secondary IdentifierAdditional identifier for the provider.H | 1000C | REF02 | - | 127 ................ 53

RECEIVER IDENTIFIER

Receiver IdentifierNumber identifying the organization receivingthe payment.H | 1000A | NM109 | - | 67 .................. 42

RECEIVER NAME

Receiver NameName of organization receiving the transaction.H | 1000A | NM103 | - | 1035 .............. 42

REFERENCE IDENTIFICATION

Reference IdentificationThe identification value assigned by the senderfor this particular transaction.H | | REF02 | - | 127 .................. 8

REFERENCE IDENTIFICATION QUALIFIER

Reference IdentificationQualifierCode qualifying the reference identification.H | | REF01 | - | 128 .................. 7H | 1000C | REF01 | - | 128 ................ 52H | 1000D | REF01 | - | 128 ................ 57


MAY 2004 E.3

H | 1000D | REF01 | - | 128 ................ 59H | 1000D | REF01 | - | 128 ................ 61H | 1000D | REF01 | - | 128 ................ 62D | 2000A | REF01 | - | 128 ................ 72D | 2000A | REF01 | - | 128 ................ 74D | 2000A | REF04 | C040-1 | 128 ................ 75

REVENUE CODE

Revenue CodeA code that identifies a specific accommodation,ancillary service or billing calculation.D | 2000A | REF04 | C040-2 | 127 ................ 76

SECURITY LEVEL CODE

Security Level CodeCode indicating the level of confidentialityassigned by the sender to the informationfollowing.D | 2110B | EFI01 | - | 786 ................ 83

SERVICE DATE

Service DateDate of service, such as the start date of theservice, the end date of the service, or thesingle day date of the service.D | 2100A | DTP03 | - | 1251 .............. 78

SUBMITTER FIRST NAME

Submitter First NameThe first name of the person submitting thetransaction or receiving the transaction, asidentified by the preceding identification code.H | 1000B | NM104 | - | 1036 .............. 47

SUBMITTER IDENTIFIER

Submitter IdentifierCode or number identifying the entity submittingthe claim.H | 1000B | NM109 | - | 67 .................. 47

SUBMITTER LAST OR ORGANIZATION NAME

Submitter Last or OrganizationNameThe last name or the organizational name of theentity submitting the transactionH | 1000B | NM103 | - | 1035 .............. 47

SUBMITTER MIDDLE NAME

Submitter Middle NameThe middle name of the person submitting thetransactionH | 1000B | NM105 | - | 1037 .............. 47

TRACE TYPE CODE

Trace Type CodeCode identifying the type of reassociation whichneeds to be performed.D | 2000A | TRN01 | - | 481 ................ 66

TRANSACTION SEGMENT COUNT

Transaction Segment CountA tally of all segments between the ST and theSE segments including the ST and SEsegments.D | | SE01 | - | 96 .................. 85

TRANSACTION SET CONTROL NUMBER

Transaction Set ControlNumberThe unique identification number within atransaction set.H | | ST02 | - | 329 .................. 5H | | SE02 | - | 329 ................ 12H | | ST02 | - | 329 ................ 37D | | SE02 | - | 329 ................ 85

TRANSACTION SET CREATION DATE

Transaction Set Creation DateIdentifies the date the submitter created thetransaction.H | | BGN03 | - | 373 ................ 40

TRANSACTION SET IDENTIFIER CODE

Transaction Set Identifier CodeCode uniquely identifying a Transaction Set.H | | ST01 | - | 143 .................. 5H | | ST01 | - | 143 ................ 37

TRANSACTION SET PURPOSE CODE

Transaction Set Purpose CodeCode identifying purpose of transaction set.H | | BGN01 | - | 353 ................ 39

TRANSACTION SET REFERENCE NUMBER

Transaction Set ReferenceNumberNumber uniquely identifying a transaction set.H | | BGN02 | - | 127 ................ 40

VERSION IDENTIFICATION CODE

Version Identification CodeRevision level of a particular format, program,technique or algorithmD | 2100B | CAT03 | - | 799 ................ 81


E.4 MAY 2004

F 102 Transaction SetF.1 Associated Data

The Associated Data (102) will be used as an HL7 syntax validation. It can be re-quested by one of the trading partners. This transaction set is used to acknow-ledge(accept/reject) the HL7 Standard in the 275 BIN segment.

004050X151 • 102ASC X12N • INSURANCE SUBCOMMITTEEIMPLEMENTATION GUIDE

MAY 2004 F.1

004050X151 • 102ASC X12N • INSURANCE SUBCOMMITTEE

IMPLEMENTATION GUIDE

F.2 MAY 2004

004050X151 • 102

APRIL 6, 2004IMPLEMENTATION

102 Associated Data

Table 1 - Header


5 0100 ST Transaction Set Header R 16 0200 ORI Payer Control Number\Provider’s Control Number

Reference IdentificationR 1

7 0300 REF Application Transaction Reference Identification R 19 0400 OOI File Format\File Version R >111 0500 BDS HL7 Message Response R 112 0600 SE Transaction Set Trailer R 1


MAY 2004 F.3

STANDARD

102 Associated DataFunctional Group ID: AC

This X12 Transaction Set contains the format and establishes the data contents of theAssociated Data Transaction Set (102) for use within the context of an Electronic DataInterchange (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 theusual transaction set structure in segments. The complete set of information constituting anobject, including the information necessary to uniquely identify an object, is defined as apackage. 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 repertoireidentified for any accompanying transaction sets contained in the interchange.

Associated data may be linked with other business transactions as an augmentation to otherfunctional data. Therefore, referencing capabilities properly relating the object to the associatedtransaction set must be provided. Because user preferences require flexibility within thetechniques for referring to an object, no particular methodology is specified. The onlyrequirement is the assignment of an object identification number attributable to the object whichshould be unique for a sufficient time to avoid any confusion. Multiple references to identify allrelated 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 groupscontaining transaction sets, packages, or transaction sets and packages. The transaction setmay be included in any functional group within an interchange. Only one package may beconveyed within a single occurrence of an Associated Data Transaction Set.

Table 1 - Header


0100 ST Transaction Set Header M 10200 ORI Object Reference Identification M 10300 REF Reference Information O >10400 OOI Associated Object Type Identification M >10500 BDS Binary Data Structure M 10600 SE Transaction Set Trailer M 1

NOTES:

1/0200 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 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/0400 One occurrence of the OOI segment is mandatory and shall be used for file format identification (Code value “13" in data

element 1691).

1/0500 The BDS segment shall contain the object.


F.4 MAY 2004

STTRANSACTION SET HEADER 004050X151 • 102 • STTRANSACTION SET HEADER

IMPLEMENTATION

TRANSACTION SET HEADERUsage: REQUIRED

Repeat: 1


1000090 Example: ST✽ 102✽ 1234~

STANDARD


Level: Header

Position: 0100

Loop: ____


Max Use: 1


DIAGRAM

ST01 143 ST02 329 ST03 1705



M 1 ID 3/3 M 1 AN 4/9 O 1 AN 1/35

ELEMENT SUMMARY

USAGEREF.DES.




CODE DEFINITION

102 Associated Data



1000092 Use the corresponding value in ST02 for this transaction set.

NOT USED ST03 1705 Implementation Convention Reference O 1 AN 1/35

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 102 • STIMPLEMENTATION GUIDE TRANSACTION SET HEADER

MAY 2004 F.5

ORIOBJECT REFERENCE IDENTIFICATION 004050X151 • 102 • ORIPAYER CONTROL NUMBER\PROVIDER’S CONTROL NUMBER REFERENCE IDENTIFICATION

IMPLEMENTATION

PAYER CONTROL NUMBER\PROVIDER’SCONTROL NUMBER REFERENCEIDENTIFICATION

Usage: REQUIRED

Repeat: 1

1000093 Notes: 1. This Reference Identification would be the number that was given inthe TRN Segment in loop 2000A of the 275 Transaction.

1000094 Example: ORI✽ 1234567~

STANDARD

ORI Object Reference Identification

Level: Header

Position: 0200

Loop: ____


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 relatedapplicable transaction set where the REF (or equivalent) segment is usedto link the functional data and object(s).

DIAGRAM

ORI01 1690

ORI ✽ Assoc. Obj.Refernce ID

M 1 AN 1/36

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED ORI01 1690 Associated Object Reference Identification M 1 AN 1/36Reference assigned by the application to uniquely identify an object

1000093 This Reference Identification would be the number that was givenin the TRN Segment in loop 2000A of the 275 Transaction.

004050X151 • 102 • ORI ASC X12N • INSURANCE SUBCOMMITTEEPAYER CONTROL NUMBER\PROVIDER’S CONTROL NUMBER REFERENCE IDENTIFICATION IMPLEMENTATION GUIDE

F.6 MAY 2004

REFREFERENCE INFORMATION 004050X151 • 102 • REFAPPLICATION TRANSACTION REFERENCE IDENTIFICATION

IMPLEMENTATION

APPLICATION TRANSACTION REFERENCEIDENTIFICATION

Usage: REQUIRED

Repeat: 1

1000095 Notes: 1. The Reference Identification would be the number that was given inthe MSH Segment of the HL7 Message. It is the Message Control IDgiven in MSH-10.

1000096 Example: REF✽ ACL✽ Regenstrief0128765419~

STANDARD


Level: Header

Position: 0300

Loop: ____


Max Use: >1


Set Notes: 1. An occurrence of the REF segment will, if needed, identify a uniqueapplication transaction reference number specified in the transaction setassociated with the object.


DIAGRAM

REF01 128 REF02 127 REF03 352 REF04 C040



M 1 ID 2/3 X 1 AN 1/50 X 1 AN 1/80 O 1

ELEMENT SUMMARY

USAGEREF.DES.



CODE DEFINITION

ACL Application Transaction Reference Number

1000097 This is the number assigned by the system whichprepared the HL7 message and is the MessageControl ID that was given in MSH-10 of the HL7message.

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 102 • REFIMPLEMENTATION GUIDE APPLICATION TRANSACTION REFERENCE IDENTIFICATION

MAY 2004 F.7


SYNTAX: R0203

1000097 This is the number assigned by the system which prepared the HL7message and is the Message Control ID that was given in MSH-10of the HL7 message.



004050X151 • 102 • REF ASC X12N • INSURANCE SUBCOMMITTEEAPPLICATION TRANSACTION REFERENCE IDENTIFICATION IMPLEMENTATION GUIDE

F.8 MAY 2004

OOIASSOCIATED OBJECT TYPE IDENTIFICATION 004050X151 • 102 • OOIFILE FORMAT\FILE VERSION

IMPLEMENTATION

FILE FORMAT\FILE VERSIONUsage: REQUIRED

Repeat: >1

1000098 Notes: 1. There would be two OOI segments used in this transaction. Theywould be linked by using the same group identification in OOI02. Onewould identify that the format of the BDS segment is HL7. The secondwould identify that the Attachment Release is 2.1.

1000099 Example: OOI✽ A✽ 13✽ HL7~OOI✽ A✽ 14✽ 2.1~

STANDARD

OOI Associated Object Type Identification

Level: Header

Position: 0400

Loop: ____


Max Use: >1

Purpose: To identify attributes and status related to the object

Set Notes: 1. One occurrence of the OOI segment is mandatory and shall be used for fileformat identification (Code value “13" in data element 1691).

DIAGRAM

OOI01 1694 OOI02 1691 OOI03 1692 OOI04 1693

OOI ✽ Object IDGroup ✽ Object Type

Qualifier ✽ Object AttrID ✽ Controlling

Agency ~

M 1 AN 1/2 M 1 ID 1/3 M 1 AN 1/256 O 1 ID 1/3

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED OOI01 1694 Object Identification Group M 1 AN 1/2To link related object identifications

REQUIRED OOI02 1691 Object Type Qualifier M 1 ID 1/3Code 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 toprocess and route the object.

CODE DEFINITION

13 File Format

1000199 This code would be used in the OOI segment that isidentifying the use of the HL7 Standard in the BDSsegment.

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 102 • OOIIMPLEMENTATION GUIDE FILE FORMAT\FILE VERSION

MAY 2004 F.9

14 File Version

1000200 This code would be used in the OOI segment that isidentifying the Attachment Specification Releasebeing used in the BDS Segment.

REQUIRED OOI03 1692 Object Attribute Identification M 1 AN 1/256Identification of the attribute applying to the object type

1000102 If OOI02 contains 13 then OOI03 will have HL7If OOI02 contains 14 then OOI03 will have 2.1

NOT USED OOI04 1693 Controlling Agency O 1 ID 1/3

004050X151 • 102 • OOI ASC X12N • INSURANCE SUBCOMMITTEEFILE FORMAT\FILE VERSION IMPLEMENTATION GUIDE

F.10 MAY 2004

BDSBINARY DATA STRUCTURE 004050X151 • 102 • BDSHL7 MESSAGE RESPONSE

IMPLEMENTATION

HL7 MESSAGE RESPONSEUsage: REQUIRED

Repeat: 1

1000201 Notes: 1. This segment will contain the HL7 acknowledgment from the receivingHL7 Translator. See the HL7 Specifications for details.

1000094 Example: ORI✽ 1234567~

STANDARD

BDS Binary Data Structure

Level: Header

Position: 0500

Loop: ____


Max Use: 1

Purpose: To transfer binary data in a single data segment, convey a critical filter fortransmission and allow identification of the end of the data segment through acount; there is no identification of the internal structure of the binary data in thissegment

Set Notes: 1. The BDS segment shall contain the object.

DIAGRAM

BDS01 1570 BDS02 784 BDS03 785

BDS ✽ FilterID Code ✽ Length of

Binary Data ✽ BinaryData ~

M 1 ID 3/3 M 1 N0 1/15 M 1 B 1/1

ELEMENT SUMMARY

USAGEREF.DES.


REQUIRED BDS01 1570 Filter ID Code M 1 ID 3/3Code specifying the type of filter used to convert data code values

CODE DEFINITION

ASC ASCII Filter

REQUIRED BDS02 784 Length of Binary Data M 1 N0 1/15The length in integral octets of the binary data

SEMANTIC: BDS02 is the length of the data in BDS03 after application of the filterindicated by BDS01. For example; a 1000 byte binary file that has been filteredusing Base 64 encoding (value ’B64’ in BDS01) will have a value of 1336 in theBDS02.

INDUSTRY: Binary Data Length Number

1000202 See the HL7 Specifications for the HL7 acknowledgment details.

REQUIRED BDS03 785 Binary Data M 1 B 1/1A string of octets which can assume any binary pattern from hexadecimal 00 to FF

ASC X12N • INSURANCE SUBCOMMITTEE 004050X151 • 102 • BDSIMPLEMENTATION GUIDE HL7 MESSAGE RESPONSE

MAY 2004 F.11

SETRANSACTION SET TRAILER 004050X151 • 102 • SETRANSACTION SET TRAILER

IMPLEMENTATION

TRANSACTION SET TRAILERUsage: REQUIRED

Repeat: 1


1000106 Example: SE✽ 7✽ 1234~

STANDARD


Level: Header

Position: 0600

Loop: ____


Max Use: 1


DIAGRAM

SE01 96 SE02 329


Number ~

M 1 N0 1/10 M 1 AN 4/9

ELEMENT SUMMARY

USAGEREF.DES.





004050X151 • 102 • SE ASC X12N • INSURANCE SUBCOMMITTEETRANSACTION SET TRAILER IMPLEMENTATION GUIDE

F.12 MAY 2004

275 implementation guide

Documents