For the health care industry to achieve the potential administrative cost savings with Electronic Data Interchange (EDI), standards have been developed and need to be implemented consistently by all organizations. To facilitate a smooth transition into the EDI environment, uniform implementation is critical.

The purpose of this implementation guide is to provide standardized data requirements and content to all users of ANSI ASC X12 Patient Information (275) Transaction Set that focuses on the use of the 275 to send additional information about a claim or encounter. This implementation guide provides a detailed explanation of the transaction set by defining uniform data content, identifying valid code tables, and specifying values applicable for the business use of conveying Additional Information to Support a Health Care Claim or Encounter (275). The intention of the developers of the 275 is represented in this guide.

This implementation guide describes a solution that includes the encapsulation of a Health Level Seven (HL7) Standard within the 275 transaction to support the exchange of clinical data. HL7, www.HL7.org, is an ANSI Accredited Standards Development Organization (SDO) whose domain is clinical and administrative data. See Section 1.7.4 Health Level Seven (HL7) Specification for additional details.

This implementation guide is designed to assist those who send additional supporting information or who receive additional supporting information to a claim or encounter using the 275 format.

Entities that use this implementation of the 275 include, but are not limited to, providers, health plans, third party administrators (TPAs), managed care service organizations, state and federal agencies and their contractors, plan purchasers, and any other entity that processes health care claims, manages the delivery of health care services, or collects health care data. Other business partners affiliated with the 275 include, but are not limited to, billing services, consulting services, vendors of systems, software and EDI translators, and EDI network intermediaries such as automated clearinghouses (ACHs), value added networks (VANs), and telecommunications services.

This implementation guide is based on the October 2003 ASC X12 standards, referred to as Version 5, Release 1, Sub-release 0 (005010).

The unique Version/Release/Industry Identifier Code for transaction sets that are defined by this implementation guide is 005010X210.

The two-character Functional Identifier Code for the transaction set included in this implementation guide:

• PI Patient Information (275)

The Version/Release/Industry Identifier Code and the applicable Functional Identifier Code must be transmitted in the Functional Group Header (GS segment) that begins a functional group of these transaction sets. For more information, see the descriptions of GS01 and GS08 in Appendix C, EDI Control Directory.

There are multiple methods available for sending and receiving business transactions electronically. Two common modes for EDI transactions are batch and real-time.

Batch - In a batch mode the sender does not remain connected while the receiver processes the transactions. Processing is usually completed according to a set schedule. If there is an associated business response transaction (such as a 271 Response to a 270 Request for Eligibility), the receiver creates the response transaction and stores it for future delivery. The sender of the original transmission reconnects at a later time and picks up the response transaction. This implementation guide does not set specific response time parameters for these activities.

Real Time - In real-time mode the sender remains connected while the receiver processes the transactions and returns a response transaction to the sender. This implementation guide does not set specific response time parameters for implementers.

This implementation guide is intended to support use in batch mode. This implementation guide is not intended to support use in real-time mode. A statement that the transaction is not intended to support a specific mode does not preclude its use in that mode between willing trading partners.

There are other usage limitations.

The 275 transaction structure only allows the submitter to send additional information for one claim in each 275. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each claim response. The 275 can accommodate multiple responses for a specific claim. See Section 1.4.1. Response to a Solicited Health Care Claim Request for Additional Information and the LX segment section for additional details.

The 275 is used to:

• Respond to an ASC X12 Health Care Claim Request for Additional Information (277), a paper request or other method for additional information.

• Provide unsolicited additional information to support an ASC X12 Health Care Claim or Encounter (837).

This Implementation Guide was not written with the intent to send attachment data from payer to payer. A specific Implementation Guide for this usage will be developed.

A claim that is subjected to Medical or Utilization review during the adjudication process may be pended by the payer. The payer then solicits specific information to supplement or support the provider's request for payment of services. The payer's request for additional information may be service specific or apply to the entire claim. The 277 Health Care Claim Request for Additional Information is used to transmit the request. The provider uses the 275 to respond.

The 277 structure allows the payer to request additional information on multiple claims. However, the 275 transaction structure only allows the submitter to send additional information for one claim in each 275. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each claim response. The 275 can accommodate multiple responses for a specific claim. See the LX segment section for additional details.

In the 277, the payer must specify the period of time in which the provider has to respond to the request for additional information. The 275 response must be received by the payer within the specified timeframe, or the claim in question may proceed to the next phase of the payer's adjudication cycle. (The ultimate disposition of the claim or service line can include payment, rejection, or denial.)

When it is known at the time of billing that the additional information is required by the payer to adjudicate the claim, the provider may submit an unsolicited 275. If done at the same time as the 837, the 275 may be sent within the same interchange (ISA/IEA) as the initial 837. This situation requires separate GS/GE Functional Groups for the 837 and the 275. The 275 may also be sent in a separate interchange than the 837.

Figure 1.1 - Solicited 275 Transaction Flow illustrates the flow of information related to the solicited business flow for the 275 Transaction.

Figure 1.1 - Solicited 275 Transaction Flow

Arrow 1

This represents the submission of the 837 Health Care Claim or Encounter or the 837 Health Care Data reporting from the provider to the payer. In this business model, the 275 attachment with the appropriate imbedded HL7 CDA containing the additional information is not sent at the same time as the claim.

Arrow 2

After the claim is received, the payer may require additional information in support of the health care claim or encounter before adjudication can be completed. The payer then solicits this information by sending the 277 Health Care Claim Request for Additional Information identifying the information needed.

Arrow 3

The provider will respond to the request for additional information by sending the 275 Additional Information to Support a Health Care Claim or Encounter to the payer with the appropriate imbedded HL7 CDA containing the additional information.

Figure 1.2 - Unsolicited 275 EDI Transaction Flow - 837 and 275 in Same Interchange illustrates the flow of information related to the unsolicited business flow for the 275 Transaction when the 837 and the 275 are sent in the same interchange.

Figure 1.2 - Unsolicited 275 EDI Transaction Flow - 837 and 275 in Same Interchange

Arrow 1

This represents the submission of the 837 Health Care Claim or Encounter or the 837 Health Care Data Reporting from the provider to the payer. In this business model, the 275 attachment with the appropriate imbedded HL7 CDA containing the additional information is sent at the same time as the claim within the same data interchange (ISA/IEA) as the associated 837. Each transaction set is contained within its own Functional Group (GS/GE) within the interchange.

Figure 1.3 - Unsolicited 275 EDI Transaction Flow - 837 and 275 in Different Interchange illustrates the flow of information related to the unsolicited business flow for the 275 transaction when the 837 and the 275 are sent in two different interchanges.

Figure 1.3 - Unsolicited 275 EDI Transaction Flow - 837 and 275 in Different Interchange

Arrow 1

This represents the submission of the 837 Health Care Claim or Encounter or 837 Health Care Data Reporting from the provider to the payer.

Arrow 2

In this business model, the 275 attachment with the appropriate imbedded HL7 CDA containing the additional information is sent in a separate data interchange (ISA/IEA) than the associated 837.

The following business terms are used in this implementation guide.

Logical Observation Identifier Names and Codes (LOINC�) Code List
LOINC� codes provide a standard set of universal names and codes for identifying individual laboratory and clinical results as well as other clinical information. LOINC� codes are maintained by Regenstrief Institute, Inc.

The dash "-" character displayed in the LOINC� code (e.g., 18657-7) is part of the LOINC� code. Therefore the dash "-" character must not be used as a delimeter.

There are several acknowledgment implementation transactions available for use. The IG developers have noted acknowledgment requirements in this section. Other recommendations of acknowledgment transactions may be used at the discretion of the trading partners. A statement that the acknowledgment is not required does not preclude its use between willing trading partners.

The 997 informs the submitter that the functional group arrived at the destination. It may include information about the syntactical quality of the functional group.

The Functional Acknowledgment (997) transaction is not required as a response to receipt of a batch transaction compliant with this implementation guide.

The Functional Acknowledgment (997) transaction is not required as a response to receipt of a real-time transaction compliant with this implementation guide.

A 997 Implementation Guide is being developed for use by the insurance industry and is expected to be available for use with this version of this Implementation Guide.

The 999 informs the submitter that the functional group arrived at the destination. It may include information about the syntactical quality of the functional group and the implementation guide compliance.

The Implementation Acknowledgment (999) transaction is not required as a response to receipt of a batch transaction compliant with this implementation guide.

The Implementation Acknowledgment (999) transaction is not required as a response to receipt of a real-time transaction compliant with this implementation guide.

A 999 Implementation Guide is being developed for use by the insurance industry and is expected to be available for use with this version of this Implementation Guide.

The 824 informs the submitter of the results of the receiving application system's data content edits of transaction sets.

The Application Advice (824) transaction is not required as a response to receipt of a batch transaction compliant with this implementation guide.

The Application Advice (824) transaction is not required as a response to receipt of a real-time transaction compliant with this implementation guide.

An 824 Implementation Guide is being developed for use by the insurance industry and is expected to be available for use with this version of this Implementation Guide.

There are one or more transactions related to the transactions described in this implementation guide.

837 Health Care Claim (Institutional, Professional and Dental)

837 Health Care Services Data Reporting

277 Health Care Claim Request for Additional Information

In addition to the ASC X12 transactions listed above, the HL7 CDA standard is related to the 275.

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's billing system. When it is determined that a claim needs additional information to complete the adjudication process, this information can be sent unsolicited in the 275 transaction.

Reporting medical and cost data to state agencies, federal agencies, commercial carriers and those carriers doing business on behalf of state or federal agencies by using the 837 provides relevant health data for statistical analysis. When the 837 does not support all of the data that is necessary for data reporting purposes, the additional information can be sent in the 275 transaction.

Submitting a claim, by using the 837 or another format, is the first step in the claim adjudication process. All data elements found on the original bill have their source from the provider's billing system. When a claim requires supporting documentation to complete the payer's adjudication process, the payer can electronically request the information using the 277 transaction. Data from the original claim is included on the 277 to assist with locating the claim or the supporting information.

The ANSI approved HL7 CDA is the standard being used to represent the attachment content and is imbedded in the 275. These specifications can be found on the HL7 website (WWW.HL7.ORG under Special Interest Groups/Attachments/Publications.) The following documents are included in the attachment package and define how to represent attachment content using the HL7 CDA:

• HL7 Additional Information Specification Implementation Guide - this document defines the conceptual approach for attachments using the HL7 CDA and how the HL7 CDA is constructed for health care claim attachments.This includes the rules for constructing the XML based CDA for attachments, the role of LOINC� in attachments, how the Additional Information Specifications (AIS) are used, and statements that define what constitutes compliance.

• HL7 LOINC� Modifiers - defines the modifier categories, LOINC� modifier codes and how they are used in the 277.

• HL7 Additional Information Specifications (AIS) - the AIS document is used to express additional information content (questions and answers). Each attachment type or category of attachments will be represented in a single AIS.

Trading partner agreements are used to establish and document the relationship between trading partners. A trading partner agreement must not override the specifications in this implementation guide if a transmission is reported in GS08 to be a product of this implementation guide.

A Trading Partner agreement may be used to define the time parameters for submission of the unsolicited 275 in a separate transaction. For example, a payer may specify that the claim will be adjudicated without the information if it is not received within a specific time frame.

Administrative Simplification provisions of the Health Insurance Portability and Accountability Act of 1996 (PL 104-191 - known as HIPAA) direct the Secretary of Health and Human Services to adopt standards for transactions to enable health information to be exchanged electronically and to adopt specifications for implementing each standard.

This implementation guide has been developed for use as an insurance industry implementation guide. At the time of publication it has not been adopted as a HIPAA standard. Should the Secretary adopt this implementation guide as a standard, the Secretary will establish compliance dates for its use by HIPAA covered entities.

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

This implementation guide assumes the use of the ASCII format. If a format other than ASCII is used, then the appropriate conversions must be applied wherever ASCII is explicitly required. The contents of the BIN segment must be encoded as text.

When a request for additional information is made, the payer supplies the parameters that assist the provider in locating the claim.These parameters are frequently the patient control number, type of bill, medical record number, procedure code or revenue code, and the date of service. The provider is the source of this information. If the information is found on the original billed claim, the payer returns these data elements in the 277 transaction.

If at the time of billing, the provider determines that additional information is needed for the payer to adjudicate the claim, an unsolicited 275 may be sent. In this usage, the provider supplies the parameters to enable the payer to identify the claim and/or the service(s) that the information supports.

When the additional information is submitted in the 275, it will either be related to the entire claim or for a specific revenue line or service line. The segments used to submit the requested information are more clearly identified by specifying whether the information is related to the Claim Level or Service Line Level.

The TRN segment is required and will either contain the payer's control number, if sent in response to a 277 or the provider's attachment control number, if sent with the 837. See Section 2 for detail segment usage.

The 275 is divided into two tables. Table 1 contains transaction control information.Table 2 contains the detail information for the business function of the transaction.

The following table presents segments that may be used for Claim Level information.

Table 1

The following table presents segments that may be used for line level information.

Table 2

The Transaction Set Header Segment (ST) identifies the transaction set by using 275 as the data value for the transaction set identifier code data element, ST01.The originator of the transaction set assigns the unique control number ST02 which is shown here as 0001. In this example, the originator is the provider. ST03 carries the same value that is populated in GS08 which is the Implementation Version Identifier. For the 275 transaction this is 005010X210.

The 275 transaction structure only allows the submitter to send additional information for one claim in each 275. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each claim response.

The Beginning Segment (BGN) indicates the transaction use. The Transaction Set Purpose Code value of "11" in the BGN01 indicates that this 275 is a response to a 277 Health Care Claim Request for Additional Information. A value of "02" indicates the unsolicited 275 is additional information sent to support an 837 claim or encounter. The originator of the transaction set assigns the unique reference number in BGN02 and the date of creation in BGN03. The Functional Group Header Segment (GS) provides additional identification of the business purpose of multi-functional transaction sets. See Appendix C, EDI Control Directory, for a detailed description of the elements in the GS segment.

The following is an example of the transaction header segments.

ST*275*0001*005010X210~

BGN*11*1*20060724~

For the solicited 275, the participants identified in the 275 are generally the payer, submitter (e.g., service bureau, clearinghouse, provider groups), provider, and patient. The Loop ID 1000 is repeated to define the participants involved in the transaction. The implementation guide specifies the participants in the subsequent loops within the transaction set and refers to these participants, respectively. The transaction participants must be in the following order:

• Payer Name - This entity is the decision maker in the business transaction. For this business use, this entity is the payer, even when the transaction is sent to a clearinghouse for forwarding to a payer.

• Submitter - This entity is the sender of the transaction. For this business use, this entity can be a provider, a provider group, a clearinghouse, a service bureau, an employer, etc.

• Provider - This entity provided the health care service.

• Patient - This is the person who received the services. The additional information is being sent to support the claim or encounter related to those services.

Transaction Participants
A detailed view of the segments and data elements used to describe the participants and their relationships is presented here. The segments and data elements are found in the 1000 Loop and the 2000 Loop. The coding examples are presented sequentially as found within an actual transaction set; however, for reading ease each segment begins on a new line.

The following example demonstrates coding for segments and data elements:

Payer

NM1*PR*2*ABC INSURANCE COMPANY*****PI*12345~

PER*IC*MEDICAL REVIEW DEPARTMENT~

Submitter

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

Provider

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

REF*G2*399999~

Patient

NM1*QC*1*SMITH*JOHN****MI*111223333A~

REF*EJ*JS960503LAB~

DTP*472*RD8*20060701-20060715~

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

NM1*PR*2*ABC INSURANCE COMPANY*****PI*12345~

Within the NM1 segment,

NM101 = PR
This value indicates that the receiver is a payer.

NM102 = 2
This value indicates that the entity is a non-person. An entity that is a person is identified with a value of "1". When the entity is a person, NM103 and NM104 contain the last and first names, respectively.

NM103 = ABC INSURANCE COMPANY
This value identifies the Information Source as "ABC INSURANCE COMPANY".

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

NM109 = 12345
The NM109 value is the actual identification code associated with NM108 (e.g., PI).The identification code listed in NM109 refers to ABC INSURANCE Company.

PER Segment at the 1000A Loop
For the solicited 275 the PER segment of the Transaction Receiver NM1 (Loop 1000A) is used to identify the entity who is expecting to receive the additional information from the provider.The payer uses the PER segment in the 277 to specify the communications contact who should receive the additional information when returned by the provider. This segment is required in the 275 only when the information is present in the 2210D PER segment of the 277.

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

PER*IC*MEDICAL REVIEW DEPARTMENT~

Within the PER,

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

PER02 = MEDICAL REVIEW DEPARTMENT
This value is the person or group name.

REF Segment at the 1000D Loop
The REF segment can be repeated a maximum of four times at the Patient 1000D loop level for this implementation. The REF segment is used to provide the Patient Control Number, the Institutional Type of Bill, the Medical Record Number and the Claim Identification Number for Clearinghouses and Other Transmission Intermediaries.

The following are coding examples of the REF segment:

REF*EJ*JS960503LAB~

REF*EA*STHH12345~

REF*D9*23235~

REF*BLT*111~

Within the REF,

REF01 = EJ
This value indicates that the next data element contains the Patient Control Number.

REF02 = JS960503LAB
The value shown is the actual Patient Control Number assigned by the provider for the claim.

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

When REF01 is BLT, REF02 contains the institutional type of bill (e.g. 111).

The order of the REF segments is not significant.

DTP Segment at the 1000D Loop
This segment occurs once at the 1000D loop for this implementation. The DTP at this level specifies the Claim Service Date found on the original claim.

The following are coding examples of the DTP segment:

DTP*472*RD8*20060705-20060715~

Within the DTP,

DTP01 = 472
This value indicates the Date of Service. This means that the data element found in DTP03 represents the date of service for the claim.

DTP02 = RD8
This value indicates that the next data element, DTP03, is a range of dates expressed in the format CCYYMMDD-CCYYMMDD. When the DTP02 value is D8 DTP03 is a single date.

DTP03 = 20060705-20060715
This represents the actual claim service Dates found on the original claim.

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

LX*1~

TRN*2*1722634842~

STC*R4:18682-5::LOI~

DTP*368*D8*20060724~

CAT*AE*HL~

EFI*05~

BIN*3117*......~

The BIN segment in this example does not display the HL7 CDA. Please refer to the HL7 specifications for an example of the CDA. For purposes of this example the CDA is represented by ......

LX Segment
The LX segment begins the detailed additional information that is being sent to the payer. The occurrence is 1 or more. The LX loop will begin each time the submitter is starting another response to a different STC or sending another type of attachment for a specific claim.

The following is a coding example of the LX segment:

LX*1~

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

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

TRN Segment
The Trace Segment (TRN) is a required segment. The 2000A TRN segment contains either the payer's or the provider's control number.

• In the solicited 275, the TRN segment will contain the payer's control number that was originally sent in the 2200D TRN segment of the 277.

• In the unsolicited 275, the TRN segment will contain the attachment control number found in the 2300 PWK06 of the 837 to link the 275 attachment data to the 837 claim or encounter.

The following is a coding example of the TRN segment:

TRN*2*1722634842~

TRN01 = 2
The value in TRN01 will be "2" when this transaction is a response to a 277.

TRN02 = 1722634842
The value shown is the payer's control number that was given in the 2200D loop TRN segment of the 277. This value must be returned in the TRN segment of the 2000A loop in the 275.

TRN01 will be a "1" when this transaction is additional information for an 837. When submitting additional information to support an 837 claim, the originator of the transaction will place the Attachment Control Number that was given in the 2300 loop PWK06 element of in the 837 claim or encounter in TRN02 of the 275.

STC Segment
The purpose of the STC segment in loop 2000A is for the provider to return the Logical Observation Identifier Names and Codes (LOINC�) Code List code that identifies the payer's question from the STC segment of the 277. For further details, refer to the 277 Implementation Guide. The STC segment is not used for unsolicited attachments.

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

STC*R3:18682-5::LOI~

Within the STC,

STC01-1 = R3
This value indicates that the claim has been suspended for additional information/documentation.

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

STC01-4 = LOI
This value indicates that table used for STC01-2 was the LOINC� code list.

DTP Segment
The DTP segment at the start of the 2100B loop identifies the date the attachment information was submitted to the payer. This segment is syntactically required in order to use the 2100B loop.

The following is a coding example of the DTP segment at the claim level:

DTP*368*D8*20060724~

Within the DTP,

DTP01 = 368
This value is the date/time qualifier element. When the value is "368", the date found in DTP03 is the submitted date.

DTP02 = D8
This value is the date/time period format qualifier. When this value is "D8", the format of the date in DTP03 is CCYYMMDD.

DTP03 = 20060724
The date represented in DTP03 is the submitted date for this information.

CAT Segment
The CAT segment in loop 2100B conveys the format of the HL7 CDA attachment information sent in BIN02.

The following is a coding example of the CAT segment at the claim level:

CAT*AE*HL~

Within the CAT,

CAT01 = AE
This value indicates the data in the BIN segment will be an attachment.

CAT02 = HL
The value specifies that the content of BIN02 is an HL7 CDA computer decision variant formatted according to HL7 specifications.

When CAT02=IA, the value specifies that the content of BIN02 is an electronic image. "IA" is never used when sending attachment information adopted under HIPAA.

When CAT02 = MB, the value specifies that the content of BIN02 is an HL7 CDA human decision non-XML (images or scanned image documents) variant formatted according to the HL7 specifications.

When CAT02 = TX, the value specifies that the content of BIN02 is an HL7 CDA human decision XML markup variant formatted according to HL7 specifications.

EFI Segment
The EFI segment in the 2110B loop is required. It is used to convey the level of confidentiality of the information in the BIN segment.

The following is a coding example of the EFI segment at the claim level:

EFI*05~

Within the EFI,

EFI01 = 05
This value represents that the security level has been defined as personal.

BIN Segment
The BIN segment in this example does not display the HL7 CDA. Please refer to the HL7 specifications for an example of the CDA attachment content. The BIN segment is used to hold the additional information. It allows for the use of the HL7 standard using the 275 transaction as the envelope.

BIN*3117*......~

Within the BIN,

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

Senders must ensure that the count in BIN01 is equal to the byte count of the contents in BIN02.

BIN02 = ......
BIN02 is where the HL7 standard begins and will be ended by the segment delimiter. The BIN segment in this example does not display the HL7 CDA. Please refer to the HL7 specifications for an example of the CDA. For purposes of this example the CDA is represented by ......

The segment terminator used in the 275 transaction must not be used within the data content of BIN02.

It has been noted that line constraints, transfer protocols, zip programs or conversion processes may insert additional control characters such as, line feeds or carriage returns or other special characters into a transaction. If this occurs in BIN02, the sender's stated count in BIN01 may no longer be equal to the received contents of the data in BIN02.

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

LX*1~

TRN*2*1722634842~

STC*R3:11504-8::LOI~

REF*FJ*1234~

REF*CPT*44397**YJ:00012~

DTP*472*D8*20060704~

DTP*368*D8*20060724~

CAT*AE*HL~

EFI*05~

BIN*3117*......~

LX Segment
The LX segment begins the detailed additional information that is being sent to the payer. The occurrence is 1 or more. The LX loop will begin each time the provider is starting another response to a different STC or sending another type of additional information for a specific claim.

The following is a coding example of the LX segment:

LX*1~

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

TRN Segment
The Trace Segment (TRN) is a required segment. The TRN segment serves two purposes.

• In the unsolicited 275, the TRN segment will contain the attachment control number found in the 2300 PWK06 of the 837 to link the 275 attachment data to the 837 claim or encounter.

• In the solicited 275, the TRN segment will contain the payer's control number that was originally sent in the 2200D loop TRN segment of the 277.

The following is a coding example of the TRN segment:

TRN*2*1722634842~

TRN01 = 2
The value in TRN01 will be "2" when this transaction is a response to a 277.

TRN01 will be "1" when this transaction is additional information to support an 837.

TRN02 = 1722634842
The value shown is the payer's control number that was given in the 2200D loop TRN segment of the 277. This value must be returned in the TRN segment of the 2000A loop in the 275.

When submitting additional information to support an 837, the value in TRN02 will be the same as the Attachment Control Number that was given in the PWK segment of the 837.

STC Segment
The purpose of the STC segment in loop 2000A is for the provider to return the LOINC� code that identifies the payer's question in the STC segment of the 277.

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

STC*R3:11504-8::LOI~

Within the STC,

STC01-1 = R3
This value indicates that the claim has been suspended for additional information/documentation.

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

STC01-4 = LOI
This value indicates that table used for STC01-2 was the LOINC� code list.

REF Segment at Loop 2000A
The REF segment identifies the service line item identification, the service line procedures and the procedure code modifiers in question. There could be additional information that is sent for multiple services.

The following is a coding example of the REF segment for the service line identification:

REF*FJ*1234~

Within the REF,

REF01=FJ. This value indicates that the next element contains the line item control number.

REF02=1234, the value shown is the line item control number submitted on the claim in question.

The following is a coding example of the REF segment for the service line procedure/revenue code:

REF*CPT*44397**YJ:00012~

Within the REF,

REF01 = CPT
This value indicates that the next data element contains the procedure code.

REF02 = 44397
The value shown is the procedure code that was submitted on the claim in question.

REF04 = YJ:00012
The YJ value indicates that the next component data element contains the revenue code. The 00012 value is the revenue code that was submitted on the claim in question.

These are just a few examples of all the qualifiers that are available in this REF segment. Additional qualifiers are explained in Section 3.

DTP Segment
This DTP segment is in the 2100A loop. At this location and in this example, the DTP segment identifies the date the service was performed and is only used when the additional information applied to a specific service line.

The following is a coding example of the DTP segment at the service line level:

DTP*472*D8*20060704~

Within the DTP segment in the 2100A loop,

DTP01 = 472
This value is the date/time qualifier element. When the value is "472", the date found in DTP03 is the date of service.

DTP02 = D8
This value is the date/time period format qualifier. When this value is "D8", the format of the date in DTP03 is CCYYMMDD. When the value is RD8 the format of the date in DTP03 is CCYYMMDD-CCYYMMDD.

DTP03 = 20060704
The date in DTP03 is the date of service.

DTP Segment - Date Additional Information was Submitted
The DTP segment in the 2100B loop identifies the date the additional information was submitted. This segment is required.

The following is a coding example of the DTP segment at the service line level:

DTP*368*D8*20060724~

Within the DTP segment in the 2100B loop,

DTP01 = 368
This value is the date/time qualifier element. When the value is "368", the date in DTP03 is the submitted date.

DTP02 = D8
This value is the date/time period format qualifier. When this value is "D8", the format of the date in DTP03 is CCYYMMDD.

DTP03 = 20060724
The date in DTP03 is the date of the 275 transaction.

CAT Segment
The CAT segment in loop 2100B conveys the format of the HL7 CDA attachment information sent in BIN02.

The following is a coding example of the CAT segment at the service line level:

CAT*AE*HL~

Within the CAT,

CAT01 = AE
This value indicates the data in the BIN segment will be an attachment.