277 Transaction Set Listing
008020X340 Health Care Claim Request for Additional Information- Loop 2000A - INFORMATION SOURCE LEVELRequired1
- Loop 2100A - PAYER NAMERequired1
- Loop 2000B - INFORMATION RECEIVER LEVELRequired1
- Loop 2100B - INFORMATION RECEIVER NAMERequired1
- Loop 2000C - SERVICE PROVIDER LEVELRequired>1
- Loop 2100C - SERVICE PROVIDER NAMERequired1
- Loop 2000D - PATIENT LEVELRequired>1
- Loop 2100D - PATIENT NAMERequired1
- Loop 2200D - PAYER CLAIM CONTROL NUMBERRequired>1
- Loop 2210D - CLAIM SUPPLEMENTAL INFORMATIONSituational1
- Loop 2220D - SERVICE LINE INFORMATIONSituational>1
ISA - INTERCHANGE CONTROL HEADER
- For compliant implementations under this implementation guide, ISA13, the interchange Control Number, must be a positive unsigned number. Therefore, the ISA segment can be considered a fixed record length segment.
- The first element separator defines the element separator to be used through the entire interchange.
- Spaces in the example interchanges are represented by "." for clarity.
- The ISA segment terminator defines the segment terminator used throughout the entire interchange.
- All positions within each of the data elements must be filled.
- The Interchange Control Number, ISA13, must be identical to the associated Interchange Trailer IEA02.
- Must be a positive unsigned number and must be identical to the value in IEA02.
GS*HN - FUNCTIONAL GROUP HEADER
ST*277 - TRANSACTION SET HEADER
- This element must be populated with the guide identifier named in Section 1.2.
- This field contains the same value as GS08. Some translator products strip off the ISA and GS segments prior to application (ST-SE) processing. Providing the information from the GS08 at this level will ensure that the appropriate application mapping is utilized at translation time.
BHT*0085 - BEGINNING OF HIERARCHICAL TRANSACTION
HL - INFORMATION SOURCE LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
NM1*PR - PAYER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
PER*IC - PAYER CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
- When the communication number represents a telephone number in the United States and other countries using the North American Dialing Plan (for voice, data, fax, etc.), the communication number must always include the area code and phone number using the format AAABBBCCCC where AAA is the area code, BBB is the telephone number prefix, and CCCC is the telephone number. Therefore, the following telephone number (555) 555-1234 would be represented as 5555551234. Do not submit long distance access numbers, such as 1, in the telephone number. Telephone extensions, when applicable, must be submitted in the next element immediately following the telephone number. When submitting telephone extensions, only submit the numeric extension, do not include data that indicates an extension, such as "ext" or "x-".
- This PER Segment provides general payer customer support information and is not returned in the 275.
HL - INFORMATION RECEIVER LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
NM1*41 - INFORMATION RECEIVER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
HL - SERVICE PROVIDER LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
NM1*1P - SERVICE PROVIDER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
OR
Use when the provider is not in the United States or its territories and has received an NPI.
HL - PATIENT LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
NM1*QC - PATIENT NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
TRN*1 - PAYER CLAIM CONTROL NUMBER
- This is the Control Number assigned by the payer. This number is used by the Payer to connect the request to the response. This number must be returned in the 275 response in the 2000A TRN02 data element.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
STC - CLAIM LEVEL STATUS INFORMATION
- See Section 1.4.4 - Status Information (STC) Segment Usage for specific STC segment information related to the hierarchical level, composites and code use.
- The codes in this STC segment must be returned in the 275 Additional Information to Support a Health Care Claim or Encounter response in the 2000A STC.
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- Use Requests for Additional Information "R" type Category Codes only.
- CODE SOURCE 507: Health Care Claim Status Category Code
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- Use Requests for Additional Information "R" type Category Codes only.
- CODE SOURCE 507: Health Care Claim Status Category Code
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- Use Requests for Additional Information "R" type Category Codes only.
- CODE SOURCE 507: Health Care Claim Status Category Code
REF*X1 - PROVIDER'S ASSIGNED CLAIM IDENTIFIER
At least one of REF02 or REF03 is required.
- The maximum number of characters to be supported for this field is '35'. Characters beyond the maximum are not required to be stored nor returned by any 837-receiving system.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
REF*BLT - INSTITUTIONAL BILL TYPE IDENTIFICATION
At least one of REF02 or REF03 is required.
- Concatenate the 837I CLM05-01 (Facility Type Code) and CLM05-03 (Claim Frequency Code) values.
Code Source 236: Uniform Billing Claim Form Bill Type
Code Source 235: Claim Frequency Type Code - Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
REF*EA - MEDICAL RECORD IDENTIFICATION NUMBER
At least one of REF02 or REF03 is required.
REF*D9 - CLAIM IDENTIFIER FOR TRANSMISSION INTERMEDIARIES
At least one of REF02 or REF03 is required.
REF*Y4 - PROPERTY & CASUALTY CLAIM NUMBER
At least one of REF02 or REF03 is required.
REF*3H - CASE REFERENCE IDENTIFIER
At least one of REF02 or REF03 is required.
REF*X9 - ATTACHMENT REQUEST TRACKING IDENTIFIER
At least one of REF02 or REF03 is required.
REF*Q4 - PRIOR ATTACHMENT REQUEST TRACKING IDENTIFIER
At least one of REF02 or REF03 is required.
DTP*472 - SERVICE DATE
DTP*106 - RESPONSE DUE DATE
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.
PWK*OZ - CLAIM SUPPLEMENTAL INFORMATION
- P0506
If either PWK05 or PWK06 is present, then the other is required. - P1011
If either PWK10 or PWK11 is present, then the other is required.
PER*RE - PAYER RESPONSE CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
- When the communication number represents a telephone number in the United States and other countries using the North American Dialing Plan (for voice, data, fax, etc.), the communication number must always include the area code and phone number using the format AAABBBCCCC where AAA is the area code, BBB is the telephone number prefix, and CCCC is the telephone number. Therefore, the following telephone number (555) 555-1234 would be represented as 5555551234. Do not submit long distance access numbers, such as 1, in the telephone number. Telephone extensions, when applicable, must be submitted in the next element immediately following the telephone number. When submitting telephone extensions, only submit the numeric extension, do not include data that indicates an extension, such as "ext" or "x-".
- The data in this PER is used by the payer for routing the requested information within their system. This data must be returned by the provider. In the 275 Transaction, this data is returned in the 1000A loop PER Segment, Payer Response Contact Information.
N3 - PAYER RESPONSE CONTACT ADDRESS
N4 - PAYER RESPONSE CONTACT CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
SVC - SERVICE LINE INFORMATION
- C003-01 qualifies C003-02 and C003-08.
- If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
- C003-03 modifies the value in C003-02 and C003-08.
- C003-04 modifies the value in C003-02 and C003-08.
- C003-05 modifies the value in C003-02 and C003-08.
- C003-06 modifies the value in C003-02 and C003-08.
- C003-07 is the description of the procedure identified in C003-02.
- C003-08 represents the ending value in the range in which the code occurs.
- C003-09 modifies the value in C003-02 and C003-08.
- C003-10 modifies the value in C003-02 and C003-08.
- C003-11 modifies the value in C003-02 and C003-08.
- C003-12 modifies the value in C003-02 and C003-08.
STC - SERVICE LINE STATUS INFORMATION
- See Section 1.4.4 - Status Information (STC) Segment Usage for specific STC segment information related to the hierarchical level, composites and code use.
- The codes in this STC segment must be returned in the 275 Additional Information to Support a Health Care Claim or Encounter response in the 2000A STC.
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- Use Requests for Additional Information "R" type Category Codes only.
- CODE SOURCE 507: Health Care Claim Status Category Code
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- Use Requests for Additional Information "R" type Category Codes only.
- CODE SOURCE 507: Health Care Claim Status Category Code
- C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
- C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
- C043-03 identifies the entity associated with the Health Care Claim Status Code.
- C043-04 is used to identify the Code Source referenced in C043-02.
- Use Requests for Additional Information "R" type Category Codes only.
- CODE SOURCE 507: Health Care Claim Status Category Code
REF*6R - LINE ITEM CONTROL NUMBER
At least one of REF02 or REF03 is required.
DTP*472 - SERVICE DATE
TOO - TOOTH INFORMATION
If either TOO01 or TOO02 is present, then the other is required.
SE - TRANSACTION SET TRAILER
GE - FUNCTIONAL GROUP TRAILER
IEA - INTERCHANGE CONTROL TRAILER
| | 277 Health Care Claim Request for Additional Information (008020X340)JANUARY 2022 Copyright © 2008-22, X12 Incorporated, Format © 2008-22 Washington Publishing Company. Exclusively published by the Washington Publishing Company. No part of this publication may be distributed, posted, reproduced, stored in a retrieval system, or transmitted in any form or by any means without the prior written permission of the copyright owner. All rights reserved. Abstract The Health Care Claim Request for Additional Information Implementation Guide describes the use of the X12 Health Care Information Status Notification (277) transaction set to request additional information to support a health care claim or encounter. |
PrefaceX12 standards are developed to identify the broadest data requirements for a transaction set. Type 3 Technical Reports (TR3), also known as implementation guides, define the explicit data requirements for a specific business purpose. Trading partners who implement according to the instructions in this TR3 can exchange data consistently with multiple trading partners. As X12 does not define transport requirements, trading partners define their specific transport requirements separately. |
1.1 Implementation Purpose and ScopeFor the health care industry to achieve the potential administrative cost savings with Electronic Data Interchange (EDI), standards have been developed to facilitate consistent implementation 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 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 Clearinghouses, Value-Added Networks (VANs), and telecommunications services. |
1.2 Version InformationThis implementation guide is based on the October 2020 X12 standards, referred to as Version 8, Release 2 (008020). The unique Version/Release/Industry Identifier Code for transaction sets that are defined by this implementation guide is 008020X340. The two-character Functional Identifier Code for the transaction set included in this implementation guide:
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. |
1.3.1 Batch and Real-Time UsageThere 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 or transmits the response transaction back to the sender of the original transaction. The sender of the original transmission reconnects at a later time and picks up the response transaction. Note: The sender of the original transmission may not always be the entity that picks up the response transaction at a later time (e.g. Provider submitting through a clearinghouse.) 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 was based on requirements for batch mode. Willing trading partners may use batch or real-time mode. |
1.3.2 Other Usage LimitationsThere are no other usage limitations. |
1.4 Business UsageThe 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 X12 standard response is provided in the 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 Health Care Transaction FlowEach X12 implementation guide explains how to use X12 transaction sets to meet a single defined business purpose. The diagrams found at https://www.x12.org/flow depict the business functions supported by the X12 health care implementation guides. |
1.4.2 Transaction ParticipantsThe 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 claim(s). 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~ The following is a coding example of the Information Receiver hierarchical level: HL*2*1*21*1~ The following is a coding example of the Service Provider hierarchical level: HL*3*2*19*1~ The following is a coding example of the Patient Hierarchical level: HL*4*3*PT~ |
1.4.3 Claim and Service InformationUnlike 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.4.1 - STC Composite and Code Use Rules for additional information. |
1.4.3.1 The ClaimWhen 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 Provider's Assigned Claim Identifier, medical record number, and dates of service which are sent in Loop 2200. |
1.4.3.1.1 Claim Association of the 277 with the 275The 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 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.3.1.2 Claim Level IdentifiersWithin 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.3.1.3 Claim Level DatesThe 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.3.1.4 Claim Supplemental InformationThe 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.3.2 The ServiceWhen 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.4 277 Status Information (STC) Segment UsageThe 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.4.1 - STC Composite and Code Use Rules for additional information. The STC segment contains three iterations of the Health Care Claim Status composite data element (C043) within STC01, STC10 and STC11. Multiple STC segments may be sent when needed to fully explain the claim status. The Health Care Claim Status composite (C043) consists of four elements:
The Category Codes and LOINC® codes are code lists external to the X12 standards. See Appendix A, External Code Sources, for more information on these code sources. A committee of health care industry representatives from payer, provider and vendor organizations maintains the Health Care Claim Status Category Codes and Health Care Claim Status Codes (Code Sources 507 and 508). They are updated after each X12 Standing Meeting. Version specific code additions or deactivations are noted on the code lists. The primary distribution source is the Washington Publishing Company website (www.wpc-edi.com). This website 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. 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.4.1 STC Composite and Code Use RulesThe following rules apply to use of the composites and codes within the STC segment:
|
1.4.5 277 Transaction UsesThe 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:
Figure 1.2 - General 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:
Figure 1.2 - General X12 Health Care Claim Information Flow |
1.5 Business TerminologyTo ensure consistent use of terms, definitions, and acronyms across X12 products, X12 maintains the Wordbook, a comprehensive corporate glossary. The included terms are either proprietary to X12, cite definitions published by another authority, or represent common terms and definitions that are relevant to X12's work. The terms and definitions defined in the Wordbook are used in X12 work products when applicable, without modification or revision. The Wordbook can be referenced online at wordbook.x12.org. |
1.6 Transaction AcknowledgmentsThe purpose of transaction acknowledgments is to report to the sender whether the transaction being acknowledged was accepted or rejected. The X12 Technical Report Type 2, Acknowledgment Reference Model provides guidance on several control structures and transaction set standards intended to augment EDI auditing and control systems. |
1.7 Related TransactionsThere are one or more transactions related to the transactions described in this implementation guide. |
1.7.1 The Claim (837)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. |
1.7.2 The Health Care Patient Information (275)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. |
1.8 Trading Partner AgreementsTrading 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. |
1.9 Transaction ComplianceThere are three types of compliance that may be relevant to a transmitted transaction. Compliance with implementation guide requirements Compliance with state and federal regulation Compliance with trading partner contractual agreements |
1.9.1 Transaction Compliance with Implementation Guide RequirementsA transaction complies with X12 implementation guide requirements if the transaction satisfies all format and content rules and constraints specified in the applicable X12 standards and the implementation guide (also known as a TR3) itself. Should additional clarification of an X12 implementation guide requirement be desired, two options are available.
X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that are not TR3-compliant based on its own business process. A receiver may specify its business rules in a trading partner agreement or companion document. As stated in §1.8, these documents do not override TR3 requirements, nor change how transaction compliance with this TR3 is determined. |
1.9.2 Transaction Compliance with State and Federal RegulationsThis 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 state or federal standard. Should this implementation guide be adopted as a standard, the adopting authority will establish compliance dates for its use by impacted entities. X12 is not the authority for determining compliance with regulatory requirements that might further constrain implementation guide requirements. Questions of compliance for regulatory requirements should be directed to the governing authority. X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that do not comply with applicable regulatory requirements as specified by the applicable regulation(s) or governing authority. |
1.9.3 Transaction Compliance with Contractual RequirementsX12 is not the authority for determining compliance with contractual requirements that might further constrain implementation guide requirements. Questions of compliance for contractual requirements should be directed to the contracting entity. X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that do not comply with contractual requirements as specified by the applicable contract or contracting entity. |
1.10 Data OverviewThis section introduces the structures of the 277. Familiarity with X12 nomenclature, segments, data elements, hierarchical levels, and looping structure is recommended. For a review, see Appendix B, X12 Control and Guidance and Appendix C, EDI Control Directory. |
1.10.1 Overall Data ArchitectureTwo formats, or views, are used to present the transaction set: the implementation view and the standard view. The intent of the implementation view is to clarify the purpose and use of the segments by restricting the view to display only those segments used with their assigned health care names. The implementation view for the 277 is presented in Section 2.3.1, Implementation. The standard view for the 277 displays all segments available within the transaction set with their assigned X12 names. This view is presented in Section 2.3.2, X12 Standard. The transaction set is divided into two levels, or tables, Table 1 and Table 2. Table 1 Table 2 The following are HL segment coding examples and the data element significance within the HL segments:
|
2.1 Presentation ExamplesThe 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: 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. 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 |
2.2.1 Industry UsageIndustry 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).
|
2.2.1.1 Determining Transaction Compliance with Industry Usage RequirementsA transmitted transaction complies with the governing implementation guide when it satisfies the requirements as defined within the implementation guide. Specifically, 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.
|
2.2.2 LoopsLoop requirements depend on the context or location of the loop within the transaction. See Appendix B for more information on loops.
|
3. ExamplesBusiness scenario examples for use of this transaction can be found on the X12 Examples website at http://examples.x12.org. The X12 Examples website provides convenient access to examples of X12 transaction transmissions, including the data stream and a description of the associated scenario. |
| Â | ||||
Appendix A. External Code SourcesPrior to this publication, X12 TR3s contained a subset of the overall Code Source Directory, formerly known as Appendix A of X12.3. External code lists are not part of the X12 standard and are provided for information purposes only. The full listing is available in Glass, X12's On-Line viewer. Read more about Glass here: https://glasshelp.x12.org/. Where an external code source is referenced in this publication, the implementer is required to use only the codes from that list. Codes must be reported as listed in the code source (e.g. with leading zeroes). Implementers must follow the instructions for code use that are supplied by the code set owner. | ||||
| Â | ||||
B.1.1 Referenced and Related StandardsThis technical report is based on the X12 EDI standard which comprises a series of interdependent publications. Implementers are advised to consult these publications when using this technical report. The following standards are required to interpret, understand, and use this technical report:
The following guideline is useful to interpret, understand, and use this technical report:
The following reference model is useful to interpret, understand, and use this technical report:
All of the documents above are available online using links to X12's Online Viewer. | ||||
| Â | ||||
B.1.1.1 Transmission Control SchematicRefer to X12.5 - Interchange Control Structures, Section 3.5 - Order of Control Segments, and Chapter 5 Interchange Segment Specifications. Similar transaction sets, called "functional groups," can be sent together within a transmission. Each functional group is prefaced by a group start segment; and a functional group is terminated by a group end segment. One or more functional groups are prefaced by an interchange header and followed by an interchange trailer. Figure B.1 - Transmission Control Schematic, illustrates this interchange control. Figure B.1 - Transmission Control Schematic | ||||
| Â | ||||
B.1.1.2 Constraints applicable to the suite of TR3sRefer to X12.6 - Application Control Structure, Section 3.2.8 - Minimums/Maximums. Data element minimum and maximum lengths are set by the X12 standard. This implementation guide may further restrict minimum and maximum lengths within the bounds set by the standard. Such restrictions may occur implicitly by virtue of the allowed qualifier for the data element, or they may be stated explicitly in a note attached to the element or in the general limitations below. | ||||
| Â | ||||
B.1.1.2.1 Maximum Length of Data Element 127 Reference IdentificationThe current X12 standard allows a maximum length greater than 50 characters for data element 127. For implementations governed by this implementation guide, unless another value is specified in an attached note, the maximum length of each occurrence of this data element is constrained to 50 characters. | ||||
| Â | ||||
B.1.1.2.2 Maximum Length of Data Element 782 Monetary AmountFor implementations governed by this implementation guide, unless another value is specified for an instance of Data Element 782 within Section 2 (Transaction Set), each occurrence of Data Element 782 (Monetary Amount) will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). Note that the decimal point and leading sign, if sent, are not part of the character count. EXAMPLE
| ||||
| Â | ||||
B.1.1.3 DecimalWhile the X12 standard supports usage of exponential notation, this guide prohibits that usage. | ||||
Appendix D. Change SummaryThis Implementation Guide (008020X340) defines the X12 requirements for the Health Care Claim Request for Additional Information. It is based on version/release/subrelease 008020 of the X12 standards. |