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 for all users of the ASC X12 Health Care Claim Request for Additional Information (277). This implementation guide focuses on the use of the 277 by a health care payer to request additional information to support a health care claim or encounter. The use of the 277 for this specific business purpose is the reason for this separate implementation guide.

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 focus of the 277 Request for Additional Information. The intention of the developers of the 277 is represented in the guide.

This implementation guide is designed to assist those who request or who receive requests to supplement claim review using the 277 format. The entities requesting additional health care information include, but are not limited to, insurance companies, 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 or manages the delivery of health care services.

Other business partners affiliated with the 277 include billing services, health care providers, consulting services, vendors of systems, software and EDI translators, and EDI network intermediaries such as Automated Clearing Houses (ACHs), Value-Added Net-works (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 005010X213.

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

• HN Health Care Information Status Notification (277)

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 no other usage limitations.

The ASC X12 Health Care Claim Request for Additional Information (277) implementation guide addresses usage of the 277 as a request for additional information to support a health care claim or encounter. The 277 transaction provides the mechanism for asking questions or making requests for information about specific claims or service lines. The actual answer or additional information response is provided in the ASC X12 Additional Information to Support a Health Care Claim or Encounter (275).

The 277 has the capability to request information for multiple claims and patients. However the 275 transaction structure only allows the submitter to send one claim in each 275. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each claim. The LX segment within the 275 can be repeated to respond to multiple questions on an individual claim.

Figure 1.1 - General Claim Status Information Flow

1.4.3.1 STC Composite and Code Use Rules

The following rules apply to use of the composites and codes within the STC segment:

• Each STC segment defines a single request for additional information. A maximum of three LOINC� codes can be used to define the request.

• The STC segment at the 2200D claim level is situational; it is required when requesting information at the claim level.

• The request for additional information can be asked at the claim level, service line level, or at both levels.

• Multiple requests for additional information for the same claim and/or line must be conveyed with separate STC segments.

• STC01 is required and describes the question or the requested information. For example, LOINC� code 18657-7 is requesting the Rehabilitation treatment plan, plan of treatment (narrative).

• STC10 and STC11 are situational and are used to provide greater specificity to the request. LOINC� modifier codes are used to qualify the scope of the request for information and are only used in STC10 and STC11. Any LOINC� modifier can be used in STC10 or STC11. STC10 must be used before STC11.

  For example, the STC10 LOINC� modifier code of 18803-7 qualifies the STC01 to include all data of the selected type that represents all observations made thirty days or fewer before the starting date of service for this claim.

• General versus specific: When requesting additional information, payers are strongly encouraged to be as specific as possible in their LOINC� code assignment to avoid general requests for additional information.

  For example: 'operative report' versus 'medical records'.

The hierarchical level structure is used to identify and relate the participants involved in the transaction. The relationships between the hierarchical levels are described by the hierarchical level code data elements, also known as HL01 and HL02.The data element, HL03, identifies the participants within the transaction. The participants described are as follows:

When HL03 = 20, the hierarchical level contains the Information Source. This entity is the decision maker in the business transaction. For this business use, this entity is the payer who is requesting additional information for the specified claims.

When HL03 = 21, the hierarchical level contains the Information Receiver. This entity is the recipient of the request for additional information from Information Source.This entity will be identified via their electronic ID. For this business use, this entity can be a provider, a provider group, a claims clearinghouse, a service bureau, etc.

When HL03 = 19, the hierarchical level contains the Provider of Service. This entity delivered the health care service. Provider of Service is generic in that this could be the entity that originally submitted the claim (Billing Provider) or may be the entity that provided or participated in some aspect of the health care (Rendering Provider).

When HL03 = PT the hierarchical level contains the Patient information. This entity is the recipient of the health care service rendered for which additional information is being requested.

The Information Receiver and the Service Provider hierarchical levels have a unique relationship. Information Receiver refers to the entity that processes the detailed information contained within the transaction set. In some cases, the Information Receiver is an entity acting on behalf of the Service Provider. When this occurs, the entity is described when HL03 = 21, and the Provider of Service is described when HL03 = 19. In other instances, the Information Receiver is also the Service Provider. When this occurs, the same entity is described at two hierarchical levels - when HL03 = 21 and when HL03 = 19.

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 the coding of the segments and data elements within the Information Source hierarchical level:

HL*1**20*1~

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

The following is a coding example of the Information Receiver hierarchical level:

HL*2*1*21*1~

NM1*41*2*XYZ SERVICE*****46*X67E~

The following is a coding example of the Service Provider hierarchical level:

HL*3*2*19*1~

NM1*1P*2*HOME MEDICAL*****XX*1666666666~

The following is a coding example of the Patient Hierarchical level:

HL*4*3*PT~

NM1*QC*1*MANN*JOHN****MI*345678901~

Unlike the Transaction Participants, specific claim and service detail information is not given a hierarchical level. Claim and service information is positioned in the Patient hierarchical level. The specific claim(s) for which information is being requested is described in Loop 2200, while the service information follows the claim data in Loop 2220.

A payer may request additional information in support of a claim at the claim level, service line level, or at both locations. The STC segments at the claim and service level are used to express the specific information the payer requires from the provider to complete the adjudication process for the identified claim.

See Section 1.4.3.1 - STC Composite and Code Use Rules for additional information.

When a request for additional information is made, the payer supplies the parameters that assist providers in locating the claim and data within their system.These parameters are frequently the patient control number, medical record number, and dates of service which are sent in Loop 2200.

The 277 transaction is used for requesting additional information about a specific claim. The additional information response must be able to be associated with the original request in the payer's adjudication system. The association of the request and additional information is accomplished with a trace number identified in the TRN Segment (TRN02).

The 277 Request for Additional Information, Loop 2200D TRN segment conveys the payer's claim control number. This identification number is assigned by the payer's system. This identifier is used by the payer to associate the additional information response to the appropriate claim.

When the additional information response is sent in an ASC X12 275 transaction, this number is returned in the 2000A TRN segment.The payer needs to receive this number back with the response to complete the association process.

Within the 2200D loop, various identifiers can be sent by the payer to help providers identify the patient's claim or services within their system. These identifiers are reported in REF segments.

The following are examples of these REF segment identifiers:

The DTP segment occurs twice at the 2200D level and specifies the claim service dates and the response due date.

The response due date is supplied by the Information Source (Payer) to indicate the date the requested information must be returned. Should this date pass without the requested information being supplied by the Information Receiver, the payer may decide to allow the claim to proceed through the adjudication process based upon the information already received in the claim.

The 2210D Loop, Claim Supplemental Information, is situational and can be used for internal work flow routing by the Information Source.The payer uses the segments within this loop to identify the entity who is expecting to receive the additional information from the provider. When the additional information is returned using the 275, only the Payer Response Contact Information, PER segment, is returned in the 1000A Loop of the 275. Payers may optionally decide to provide information on other methods (non EDI) such as fax, email address, mailing address, etc. for the return of attachment data.

When the requested information is more clearly identified by specifying the claim service line, Loop 2220 is used.The service information follows the Loop 2200 claim data. Some payers' adjudication systems support service line information requests.

For service line requests for additional information, the SVC segment is used to report the actual service (procedure) data. A specific service date is also required when requesting additional information at the service line level.

The STC segment is used to express the specific information the payer requires from the provider to complete the adjudication process for the identified claim. A payer may request additional information in support of a claim, at the claim level, service line level, or at both locations.

See Section 1.4.3.1 - STC Composite and Code Use Rules for additional information.

The STC segment contains three iterations of the C043 (Health Care Claim Status) composite within STC01, STC10 and STC11.

The Health Care Claim Status composite (C043) consists of four elements:

• The first element in the C043 composite (C043-01) is the Health Care Claim Status Category Code, Code Source 507. The Category Code indicates the type of request for additional information. While the code source includes multiple values, the only valid codes for this business use are the Request for Additional Information Codes (R-prefix).

• The second element in the C043 composite (C043-02) is the Logical Observation Identifier Names and Codes (LOINC�), Code Source 663.The LOINC� codes contain the detail information about the actual question and modifiers. Refer to the HL7 specifications for additional information on LOINC� codes and their modifiers.

  Note: The dash "-" character displayed in a LOINC� code (e.g., 18657-7) is part of the LOINC� code. Please refer to Section B.1.1.2.5 - Delimiters for further information.

• The third element in the C043 composite (C043-03) is the Entity Identifier Code (ASC X12 data element 98). This element is not used within this implementation.

• The fourth element in the C043 composite (C043-04) is the Code List Qualifier Code (ASC X12 data element 1270). The Code List Qualifier Code is used to identify that the second element of the composite contains a LOINC� code. For the purposes of this implementation, this element must always contain the value "LOI".

The Category Codes and LOINC� codes are code lists external to the ASC X12 standards. See Appendix A, External Code Sources, for more information on these code sources.

A committee of healthcare industry representatives from payer, provider and vendor organizations maintains the Health Care Claim Status Category Codes, Code Source 507. The code list is updated after each ASC X12 trimester meeting. Version specific code additions or deactivations are noted on the code lists.

The Blue Cross Blue Shield Association (BCBSA) is the owner of the Health Care Claim Status Category Code list. The primary distribution source is the Washington Publishing Company web site (www.wpc-edi.com). This web site offers an online conferencing facility that allows interested parties to submit requests for new codes, changes to existing codes, or simply view comments on pending requests. Individuals who are unable to access the Internet may contact BCBSA directly.

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 ASC X12 Health Care Claim Request for Additional Information (277) implementation guide addresses usage of the 277 as a request for additional information to support a health care claim or encounter. The 277 transaction provides the mechanism for asking questions or making requests for information about specific claims or service lines. The actual answer or additional information response is provided in the ASC X12 Additional Information to Support a Health Care Claim or Encounter (275).

The 277 has the capability to request information for multiple claims and patients. However the 275 transaction structure only allows the submitter to send one claim in each 275. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each claim. The LX segment within the 275 can be repeated to respond to multiple questions on an individual claim.

Figure 1.1 - General Claim Status Information Flow

1.4.1 Transaction Participants

The hierarchical level structure is used to identify and relate the participants involved in the transaction. The relationships between the hierarchical levels are described by the hierarchical level code data elements, also known as HL01 and HL02.The data element, HL03, identifies the participants within the transaction. The participants described are as follows:

When HL03 = 20, the hierarchical level contains the Information Source. This entity is the decision maker in the business transaction. For this business use, this entity is the payer who is requesting additional information for the specified claims.

When HL03 = 21, the hierarchical level contains the Information Receiver. This entity is the recipient of the request for additional information from Information Source.This entity will be identified via their electronic ID. For this business use, this entity can be a provider, a provider group, a claims clearinghouse, a service bureau, etc.

When HL03 = 19, the hierarchical level contains the Provider of Service. This entity delivered the health care service. Provider of Service is generic in that this could be the entity that originally submitted the claim (Billing Provider) or may be the entity that provided or participated in some aspect of the health care (Rendering Provider).

When HL03 = PT the hierarchical level contains the Patient information. This entity is the recipient of the health care service rendered for which additional information is being requested.

The Information Receiver and the Service Provider hierarchical levels have a unique relationship. Information Receiver refers to the entity that processes the detailed information contained within the transaction set. In some cases, the Information Receiver is an entity acting on behalf of the Service Provider. When this occurs, the entity is described when HL03 = 21, and the Provider of Service is described when HL03 = 19. In other instances, the Information Receiver is also the Service Provider. When this occurs, the same entity is described at two hierarchical levels - when HL03 = 21 and when HL03 = 19.

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 the coding of the segments and data elements within the Information Source hierarchical level:

HL*1**20*1~

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

The following is a coding example of the Information Receiver hierarchical level:

HL*2*1*21*1~

NM1*41*2*XYZ SERVICE*****46*X67E~

The following is a coding example of the Service Provider hierarchical level:

HL*3*2*19*1~

NM1*1P*2*HOME MEDICAL*****XX*1666666666~

The following is a coding example of the Patient Hierarchical level:

HL*4*3*PT~

NM1*QC*1*MANN*JOHN****MI*345678901~

1.4.2 Claim and Service Information

Unlike the Transaction Participants, specific claim and service detail information is not given a hierarchical level. Claim and service information is positioned in the Patient hierarchical level. The specific claim(s) for which information is being requested is described in Loop 2200, while the service information follows the claim data in Loop 2220.

A payer may request additional information in support of a claim at the claim level, service line level, or at both locations. The STC segments at the claim and service level are used to express the specific information the payer requires from the provider to complete the adjudication process for the identified claim.

See Section 1.4.3.1 - STC Composite and Code Use Rules for additional information.

1.4.2.1 The Claim

When a request for additional information is made, the payer supplies the parameters that assist providers in locating the claim and data within their system.These parameters are frequently the patient control number, medical record number, and dates of service which are sent in Loop 2200.

1.4.2.1.1 Claim Association of the 277 with the 275

The 277 transaction is used for requesting additional information about a specific claim. The additional information response must be able to be associated with the original request in the payer's adjudication system. The association of the request and additional information is accomplished with a trace number identified in the TRN Segment (TRN02).

The 277 Request for Additional Information, Loop 2200D TRN segment conveys the payer's claim control number. This identification number is assigned by the payer's system. This identifier is used by the payer to associate the additional information response to the appropriate claim.

When the additional information response is sent in an ASC X12 275 transaction, this number is returned in the 2000A TRN segment.The payer needs to receive this number back with the response to complete the association process.

1.4.2.1.2 Claim Level Identifiers

Within the 2200D loop, various identifiers can be sent by the payer to help providers identify the patient's claim or services within their system. These identifiers are reported in REF segments.

The following are examples of these REF segment identifiers:

1.4.2.1.3 Claim Level Dates

The DTP segment occurs twice at the 2200D level and specifies the claim service dates and the response due date.

The response due date is supplied by the Information Source (Payer) to indicate the date the requested information must be returned. Should this date pass without the requested information being supplied by the Information Receiver, the payer may decide to allow the claim to proceed through the adjudication process based upon the information already received in the claim.

1.4.2.1.4 Claim Supplemental Information

The 2210D Loop, Claim Supplemental Information, is situational and can be used for internal work flow routing by the Information Source.The payer uses the segments within this loop to identify the entity who is expecting to receive the additional information from the provider. When the additional information is returned using the 275, only the Payer Response Contact Information, PER segment, is returned in the 1000A Loop of the 275. Payers may optionally decide to provide information on other methods (non EDI) such as fax, email address, mailing address, etc. for the return of attachment data.

1.4.2.2 The Service

When the requested information is more clearly identified by specifying the claim service line, Loop 2220 is used.The service information follows the Loop 2200 claim data. Some payers' adjudication systems support service line information requests.

For service line requests for additional information, the SVC segment is used to report the actual service (procedure) data. A specific service date is also required when requesting additional information at the service line level.

1.4.3 277 Status Information (STC) Segment Usage

The STC segment is used to express the specific information the payer requires from the provider to complete the adjudication process for the identified claim. A payer may request additional information in support of a claim, at the claim level, service line level, or at both locations.

See Section 1.4.3.1 - STC Composite and Code Use Rules for additional information.

The STC segment contains three iterations of the C043 (Health Care Claim Status) composite within STC01, STC10 and STC11.

The Health Care Claim Status composite (C043) consists of four elements:

• The first element in the C043 composite (C043-01) is the Health Care Claim Status Category Code, Code Source 507. The Category Code indicates the type of request for additional information. While the code source includes multiple values, the only valid codes for this business use are the Request for Additional Information Codes (R-prefix).

• The second element in the C043 composite (C043-02) is the Logical Observation Identifier Names and Codes (LOINC�), Code Source 663.The LOINC� codes contain the detail information about the actual question and modifiers. Refer to the HL7 specifications for additional information on LOINC� codes and their modifiers.

  Note: The dash "-" character displayed in a LOINC� code (e.g., 18657-7) is part of the LOINC� code. Please refer to Section B.1.1.2.5 - Delimiters for further information.

• The third element in the C043 composite (C043-03) is the Entity Identifier Code (ASC X12 data element 98). This element is not used within this implementation.

• The fourth element in the C043 composite (C043-04) is the Code List Qualifier Code (ASC X12 data element 1270). The Code List Qualifier Code is used to identify that the second element of the composite contains a LOINC� code. For the purposes of this implementation, this element must always contain the value "LOI".

The Category Codes and LOINC� codes are code lists external to the ASC X12 standards. See Appendix A, External Code Sources, for more information on these code sources.

A committee of healthcare industry representatives from payer, provider and vendor organizations maintains the Health Care Claim Status Category Codes, Code Source 507. The code list is updated after each ASC X12 trimester meeting. Version specific code additions or deactivations are noted on the code lists.

The Blue Cross Blue Shield Association (BCBSA) is the owner of the Health Care Claim Status Category Code list. The primary distribution source is the Washington Publishing Company web site (www.wpc-edi.com). This web site offers an online conferencing facility that allows interested parties to submit requests for new codes, changes to existing codes, or simply view comments on pending requests. Individuals who are unable to access the Internet may contact BCBSA directly.

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.

1.4.3.1 STC Composite and Code Use Rules

The following rules apply to use of the composites and codes within the STC segment:

• Each STC segment defines a single request for additional information. A maximum of three LOINC� codes can be used to define the request.

• The STC segment at the 2200D claim level is situational; it is required when requesting information at the claim level.

• The request for additional information can be asked at the claim level, service line level, or at both levels.

• Multiple requests for additional information for the same claim and/or line must be conveyed with separate STC segments.

• STC01 is required and describes the question or the requested information. For example, LOINC� code 18657-7 is requesting the Rehabilitation treatment plan, plan of treatment (narrative).

• STC10 and STC11 are situational and are used to provide greater specificity to the request. LOINC� modifier codes are used to qualify the scope of the request for information and are only used in STC10 and STC11. Any LOINC� modifier can be used in STC10 or STC11. STC10 must be used before STC11.

  For example, the STC10 LOINC� modifier code of 18803-7 qualifies the STC01 to include all data of the selected type that represents all observations made thirty days or fewer before the starting date of service for this claim.

• General versus specific: When requesting additional information, payers are strongly encouraged to be as specific as possible in their LOINC� code assignment to avoid general requests for additional information.

  For example: 'operative report' versus 'medical records'.

1.4.4 277 Transaction Usages

The Health Care Information Status Notification (277) transaction set has multiple implementation conventions to meet various business needs of the health care industry. The transaction set can be used to provide healthcare claim information in the following business scenarios:

• ASC X12 Health Care Claim Request for Additional information (277), which is a payer's request for additional information to support a health care claim. This function is supported in this implementation guide.

• ASC X12 Health Care Claim Status Request and Response (276/277), where the 277 is a response to a request for claim status information. This function is not supported in this implementation guide.

• ASC X12 Health Care Claim Acknowledgement (277), which is a business application response to the ASC X12 837 claim/encounter transactions. This function is not supported in this implementation guide.

• ASC X12 Health Care Claim Pending Status Information (277), which is used as a listing of pended claims in a payer's system. This function is not supported in this implementation guide.

Figure 1.2 - General ASC X12 Health Care Claim Information Flow illustrates the flow of information related to several usages of the 277. The multiple uses of the 277 claim status are differentiated by values in the ST and BHT Segments of Table 1 data. Element BHT06, in addition to the ST03 and GS08 values, is used to distinguish between these varied business functions. The various 277 - BHT06 code values are:

• DG - Response (Health Care Claim Status Request and Response)

• NO - Notice (Health Care Claim Pending Status Information)

• RQ - Request (Care Claim Request for Additional Information)

• TH - Receipt Acknowledgment Advice (Health Care Claim Acknowledgment)

Figure 1.2 - General ASC X12 Health Care Claim Information Flow

The Health Care Information Status Notification (277) transaction set has multiple implementation conventions to meet various business needs of the health care industry. The transaction set can be used to provide healthcare claim information in the following business scenarios:

• ASC X12 Health Care Claim Request for Additional information (277), which is a payer's request for additional information to support a health care claim. This function is supported in this implementation guide.

• ASC X12 Health Care Claim Status Request and Response (276/277), where the 277 is a response to a request for claim status information. This function is not supported in this implementation guide.

• ASC X12 Health Care Claim Acknowledgement (277), which is a business application response to the ASC X12 837 claim/encounter transactions. This function is not supported in this implementation guide.

• ASC X12 Health Care Claim Pending Status Information (277), which is used as a listing of pended claims in a payer's system. This function is not supported in this implementation guide.

Figure 1.2 - General ASC X12 Health Care Claim Information Flow illustrates the flow of information related to several usages of the 277. The multiple uses of the 277 claim status are differentiated by values in the ST and BHT Segments of Table 1 data. Element BHT06, in addition to the ST03 and GS08 values, is used to distinguish between these varied business functions. The various 277 - BHT06 code values are:

• DG - Response (Health Care Claim Status Request and Response)

• NO - Notice (Health Care Claim Pending Status Information)

• RQ - Request (Care Claim Request for Additional Information)

• TH - Receipt Acknowledgment Advice (Health Care Claim Acknowledgment)

Figure 1.2 - General ASC X12 Health Care Claim Information Flow

No special business terms are used in this implementation guide.

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.

Submitting a claim using the 837 is the first step in the claim adjudication process. The data elements found on the original claim have their source from the provider's billing system. When additional supporting information is required for a claim to complete the payer's adjudication process, the payer can request the information from the provider using the 277 Request for Additional Information. Data from the original claim is returned to the provider on the 277 to facilitate locating the claim or the supporting information.

When a claim requires supporting medical 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 the provider with locating the claim or the supporting information. The provider may return the supporting medical documentation by sending the 275 transaction, Additional Information to Support a Health Care Claim or Encounter. The provider will return the medical documentation along with various data elements from the 277 to facilitate association of the response to the request within the payer's adjudication system.

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.

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 structures of the 277. Familiarity with ASC X12 nomenclature, segments, data elements, hierarchical levels, and looping structure is recommended. For a review, see Appendix B, Nomenclature and Appendix C, EDI Control Directory.

The transaction set is divided into two levels, or tables, Table 1 and Table 2.

Table 1

Table 1 is named the Header Level and contains the transaction control information. The ST segment identifies the start of a transaction and the specific transaction set. The BHT identifies the transactions business purpose and the hierarchical structure used in Table 2.

Table 2

Table 2 is named the Detail Level because it contains the detail information for the business function of the transactions. This table uses the hierarchical level structure. Each hierarchical level (HL) is a series of loops, which are identified by numbers and letters. The hierarchical level that identifies the patient is Loop ID-2000D. The patient name is contained in Loop ID-2100D. Specific claim details begin with Loop ID-2200D.

The following are HL segment coding examples and the data element significance within the HL segments:

• HLs are sequentially numbered. The sequential number is found in HL01, which is the first data element in the HL segment.

• The second element, HL02, indicates the sequential number of the parent hierarchical level to which this hierarchical level is subordinate. The absence of a data value in HL02, indicates it is the highest hierarchical level. In this example, the Information Source is the highest parent. The Information Receiver level is subordinate to the Information Source hierarchical level numbered 1 (HL01 =1). The provider of service level is subordinate to the Information Receiver hierarchical level numbered 2 (HL01=2), etc.

• The data value in data element HL03 describes the hierarchical level entity. For example, when HL03 = 20, the hierarchical level is the Information Source.When HL03 = PT, the hierarchical level is the Patient.

• Data element HL04 indicates whether or not child (subordinate) hierarchical exist. A value of "1" indicates subordinate hierarchical levels exist. A value of "0" or the absence of a data value indicates that no subordinate hierarchical levels exist.

NOTE

See Appendix B, Nomenclature, to review the transaction set structure, including descriptions of segments, data elements, levels, and loops.

The ASC X12 standards are generic. For example, multiple trading communities use the same PER segment to specify administrative communication contacts. Each community decides which elements to use and which code values in those elements are applicable.

This implementation guide uses a format that depicts both the generalized standard and the insurance industry-specific implementation. In this implementation guide, IMPLEMENTATION specifies the requirements for this implementation. X12 STANDARD is included as a reference only.

The transaction set presentation is comprised of two main sections with subsections within the main sections:

2.3 Transaction Set Listing

There are two sub-sections under this general title. The first sub-section concerns this implementation of a generic X12 transaction set. The second sub-section concerns the generic X12 standard itself.

This section lists the levels, loops, and segments contained in this implementation. It also serves as an index to the segment detail.

This section is included as a reference.

2.4 Segment Detail

There are three 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.

This section is included as a reference.

This section is included as a reference. It provides a pictorial view of the standard and shows which elements are used in this implementation.

This section specifies the implementation details of each data element.

These illustrations (Figures 2.1 through 2.5) are examples and are not extracted from the Section 2 detail in this implementation guide. Annotated illustrations, presented below in the same order they appear in this implementation guide, describe the format of the transaction set that follows.

Figure 2.1 - Transaction Set Key - Implementation

Figure 2.2 - Transaction Set Key - Standard

Figure 2.3 - Segment Key - Implementation

Figure 2.4 - Segment Key - Diagram

Figure 2.5 - Segment Key - Element Summary

Industry Usage describes when loops, segments, and elements are to be sent when complying with this implementation guide. The three choices for Usage are required, not used, and situational. To avoid confusion, these are named differently than the X12 standard Condition Designators (mandatory, optional, and relational).

A transmitted transaction complies with an implementation guide when it satisfies the requirements as defined within the implementation guide. The presence or absence of an item (loop, segment, or element) complies with the industry usage specified by this implementation guide according to the following table.