277 Transaction Set Listing
008020X330 Health Care Claim Acknowledgment- Loop 2000A - INFORMATION SOURCE LEVELRequired1
- Loop 2100A - INFORMATION SOURCE NAMERequired1
- Loop 2200A - TRANSMISSION RECEIPT CONTROL TRACE IDENTIFIERRequired1
- Loop 2000B - INFORMATION RECEIVER LEVELRequired1
- Loop 2100B - INFORMATION RECEIVER NAMERequired1
- Loop 2200B - INFORMATION RECEIVER TRACE IDENTIFIERRequired1
- Loop 2000C - BILLING PROVIDER LEVELSituational>1
- Loop 2100C - BILLING PROVIDER NAMERequired1
- Loop 2200C - PROVIDER OF SERVICE TRACE IDENTIFIERSituational1
- Loop 2000D - PATIENT LEVELSituational>1
- Loop 2100D - PATIENT NAMERequired1
- Loop 2200D - CLAIM STATUS TRACE NUMBERRequired>1
- Loop 2210DA - TRANSFER TO ENTITY SUPPLEMENTAL INFORMATIONSituational1
- Loop 2210DB - SUPPLEMENTAL STATUS INFORMATIONSituational>1
- Loop 2220D - SERVICE LINE INFORMATIONSituational>1
- Loop 2225DA - TRANSFER TO ENTITY SUPPLEMENTAL INFORMATIONSituational1
- Loop 2225DB - SUPPLEMENTAL STATUS INFORMATIONSituational>1
ISA - INTERCHANGE CONTROL HEADER
- All positions within each of the data elements must be filled.
- 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.
- 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 implementation guide Version/Release/Industry Identifier Code named in Section 1.2.
- This element 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
- The inventory file number of the transmission assigned by the Information Source's system. This number operates as a transaction (batch) control number.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
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 - INFORMATION SOURCE 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 - TRANSMISSION RECEIPT CONTROL TRACE IDENTIFIER
- This is a unique trace number that identifies a specific transaction. This number is assigned by the Information Source.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
DTP*050 - INFORMATION SOURCE RECEIPT DATE
DTP*009 - INFORMATION SOURCE PROCESS DATE
- Payers and clearinghouses often collect claim transmissions throughout the business day. A process which is usually called "batch" is initiated at least once per business day. Some entities may initiate this process more than one time per day. As claim transmission files are processed, EDI reports and or data files are generated from the entity's computer system(s) and are distributed to the Information Receiver.
- The Information Source Process Date applies to the processing of the 837 claim transaction file through a pre-adjudication/electronic data interchange (EDI) system. This date may or may not be the same date as the Information Source Receipt Date.
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.
- For situations where a person such as a single practitioner submits claim transactions to a payer, the entity identified in the Provider of Service Loop (HL03 = 19) will be the same entity identified here in the Information Receiver Loop (HL03 = 21). The difference may be that the trading partner profile set up in the EDI environment is a separate identification scheme from the identification number set up for the entity in the adjudication system.
- In the situation where there is more than one clearinghouse involved in the transmission of the Health Care Claim Acknowledgement as part of the Trading Partner Agreement, this segment will be used to identify the clearinghouse that is passing the information. This segment will be changed to display the information for the next clearinghouse before they continue passing on the transmission. This process will continue until the transmission reaches the initiator of the claim/encounter.
TRN*2 - INFORMATION RECEIVER TRACE IDENTIFIER
- This element contains the value submitted in the BHT03 data element from the 837.
- 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 - INFORMATION RECEIVER STATUS INFORMATION
- This segment will be used to convey information about an entire unit of work (e.g. single transaction of claims). Information contained at this level will be summary details pertaining to the unit of work being acknowledged. Examples include but are not limited to accepted for processing, trading partner not authorized to submit to the Information Source's system, etc.
- See Section 1.4.3 - Status Information (STC) Segment Usage for specific STC segment information, composites and code use.
- 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.
- For this business application acknowledgment, use of the Claim Status Category Code is limited to category types 'A' for batch. For real-time acknowledgements category types 'A' and 'E' may be used except for E0. Use of the category type 'E' is limited to indicating the business application system is unavailable.
- CODE SOURCE 507: Health Care Claim Status Category Code
- This code provides further detail of the status. See Section 1.4.3 Status Information (STC Segment Usage).
- CODE SOURCE 508: Health Care Claim Status Code
- This will be the sum of all CLM02 values (claim charge) for the claims being acknowledged within an ST to SE of a single 837 transaction set.
In situations where the 837 transaction from the Information Receiver is separated (e.g. due to clearinghouse involvement), this amount will be the sum of the CLM02 values for the claims being acknowledged. - Monetary Amounts returned in this element may exceed 10 characters.
- 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.
- See STC01-01 for valid values.
- CODE SOURCE 507: Health Care Claim Status Category Code
- This code provides further detail of the status. See Section 1.4.3 Status Information (STC Segment Usage).
- CODE SOURCE 508: Health Care Claim Status 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.
- See STC01-01 for valid values.
- CODE SOURCE 507: Health Care Claim Status Category Code
- This code provides further detail of the status. See Section 1.4.3 Status Information (STC Segment Usage).
- CODE SOURCE 508: Health Care Claim Status Code
QTY*90 - TOTAL ACCEPTED QUANTITY
- R0204
At least one of QTY02 or QTY04 is required. - E0204
Only one of QTY02 or QTY04 may be present.
- The purpose of this segment is to report the total number of claims accepted by the Information Source.
- For QTY segment balancing, see Section 1.4.5 (Balancing).
QTY*AA - TOTAL REJECTED QUANTITY
- R0204
At least one of QTY02 or QTY04 is required. - E0204
Only one of QTY02 or QTY04 may be present.
- The purpose of this segment is to report the total number of claims rejected for this Information Receiver (e.g. not accepted) by the Information Source.
- For QTY segment balancing, see Section 1.4.5 (Balancing).
AMT*YU - TOTAL ACCEPTED AMOUNT
- The purpose of this segment is to report the total dollar amount of claims accepted by the Information Source.
- For AMT segment balancing, see Section 1.4.5 (Balancing).
- See STC01-03 for valid values.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
AMT*YY - TOTAL REJECTED AMOUNT
- The purpose of this segment is to report the total dollar amount of claims rejected for this Information Receiver (e.g. not accepted) by the Information Source.
- For AMT segment balancing, see Section 1.4.5 (Balancing).
- Monetary Amounts returned in this element may exceed 10 characters.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
HL - BILLING 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*85 - BILLING 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.
TRN*1 - PROVIDER OF SERVICE TRACE IDENTIFIER
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
- This value must be zero (0).
REF - PROVIDER SECONDARY IDENTIFIER
At least one of REF02 or REF03 is required.
QTY*QA - TOTAL ACCEPTED QUANTITY
- R0204
At least one of QTY02 or QTY04 is required. - E0204
Only one of QTY02 or QTY04 may be present.
- The purpose of this segment is to report the total number of claims accepted to the adjudication process by the Information Source for the Billing Provider in this acknowledgment.
- For QTY segment balancing, see Section 1.4.5 (Balancing).
QTY*QC - TOTAL REJECTED QUANTITY
- R0204
At least one of QTY02 or QTY04 is required. - E0204
Only one of QTY02 or QTY04 may be present.
- The purpose of this segment is to report the total number of claims rejected by the Information Source for the Billing Provider.
- For QTY segment balancing, see Section 1.4.5 (Balancing).
AMT*YU - TOTAL ACCEPTED AMOUNT
- The purpose of this segment is to report the total dollar amount of claims (sum of CLM02) accepted by the Information Source for the Billing Provider in this acknowledgment.
- For AMT segment balancing, see Section 1.4.5 (Balancing).
- Monetary Amounts returned in this element may exceed 10 characters.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
AMT*YY - TOTAL REJECTED AMOUNT
- The purpose of this segment is to report the total dollar amount of claims (sum of CLM02) rejected by the Information Source for the Billing Provider in this acknowledgment.
- For AMT segment balancing, see Section 1.4.5 (Balancing).
- Monetary Amounts returned in this element may exceed 10 characters.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
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*2 - CLAIM STATUS TRACE NUMBER
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
- The maximum number of characters to be supported for this qualifier is 35. Characters beyond the maximum are not required to be stored or returned by the receiving system.
STC - CLAIM LEVEL STATUS INFORMATION
- 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.
- For this business application acknowledgment, use of the Claim Status Category Code is limited to category types 'A' for batch. For real-time acknowledgements category types 'A' and 'E' may be used except for E0. Use of the category type 'E' is limited to indicating the business application system is unavailable.
- CODE SOURCE 507: Health Care Claim Status Category Code
- This code provides further detail of the status. See Section 1.4.3 Status Information (STC Segment Usage).
- CODE SOURCE 508: Health Care Claim Status Code
- Zero is an acceptable amount.
- Sum of the charges (CLM02) submitted from original claim. If an original claim is split, report the original claim total here. Note that this amount may be reported in two or more claims.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- 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.
- See STC01-01 for valid values.
- CODE SOURCE 507: Health Care Claim Status Category Code
- This code provides further detail of the status. See Section 1.4.3 Status Information (STC Segment Usage).
- CODE SOURCE 508: Health Care Claim Status 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.
- See STC01-01 for valid values.
- CODE SOURCE 507: Health Care Claim Status Category Code
- This code provides further detail of the status. See Section 1.4.3 Status Information (STC Segment Usage).
- CODE SOURCE 508: Health Care Claim Status Code
REF*1K - PAYER CLAIM CONTROL 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*9A - REPRICED CLAIM NUMBER
At least one of REF02 or REF03 is required.
REF*BLT - INSTITUTIONAL BILL TYPE IDENTIFICATION
At least one of REF02 or REF03 is required.
- See 837 Institutional Implementation Guide for definition of Institutional Bill Type components.
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 respectively. - 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*Y4 - PROPERTY & CASUALTY CLAIM NUMBER
At least one of REF02 or REF03 is required.
REF*WF - EDI CONTROL NUMBER
At least one of REF02 or REF03 is required.
DTP*472 - SERVICE DATE
DTP - CORRECTED DATE OF ILLNESS/INJURY/ACCIDENT
- DTP✱431✱D8✱20220108~
- DTP✱439✱D8✱20221030~
PWK*V4 - TRANSFER TO ENTITY 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.
- This is not for COB reporting or when a service is transferred internally within the payer's system(s).
- The PWK segment is syntactically required in order to use the Transfer to Entity data in Loop ID 2210DA.
PER*IC - TRANSFER TO ENTITY 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.
N1 - TRANSFER TO ENTITY NAME
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
N3 - TRANSFER TO ENTITY ADDRESS
N4 - TRANSFER TO ENTITY 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
PWK*R6 - SUPPLEMENTAL STATUS 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.
- This segment must not be used in place of reporting the highest level of specificity or the most accurate status information in the 2200D STC Segment (STC01, STC10 and STC11).
- This segment must not be used to repeat or duplicate the verbiage associated with the status information reported in the 2200D STC Segment (STC01, STC10 and STC11).
- When claim level information caused the rejection of a claim, it must be reported at the Loop 2200D STC Claim Level Status Information.
- See Section 1.4.3.1 - STC Composite and Code Use Rules, for additional information.
PER*IC - SUPPLEMENTAL STATUS 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.
SVC - SERVICE LINE INFORMATION
Or
When the claim is accepted (2200D STC03 = WQ) and a warning/notification applies to the service line.
- 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.
- If the value in SVC01-01 is "NU", then this element is an NUBC Revenue Code. If the Revenue Code is present in SVC01-02, then SVC04 is not used.
- Value submitted on the original claim.
- Zero is an acceptable amount.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
STC - SERVICE LINE STATUS INFORMATION
- 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.
- For this business application acknowledgment, use of the Claim Status Category Code is limited to category types 'A' for batch. For real-time acknowledgements category types 'A' and 'E' may be used except for E0. Use of the category type 'E' is limited to indicating the business application system is unavailable.
- CODE SOURCE 507: Health Care Claim Status Category Code
- This code provides further detail of the status. See Section 1.4.3 Status Information (STC Segment Usage).
- CODE SOURCE 508: Health Care Claim Status 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.
- See STC01-01 for valid values.
- CODE SOURCE 507: Health Care Claim Status Category Code
- This code provides further detail of the status. See Section 1.4.3 Status Information (STC Segment Usage).
- CODE SOURCE 508: Health Care Claim Status 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.
- See STC01-01 for valid values.
- CODE SOURCE 507: Health Care Claim Status Category Code
- This code provides further detail of the status. See Section 1.4.3 Status Information (STC Segment Usage).
- CODE SOURCE 508: Health Care Claim Status Code
REF*6R - LINE ITEM CONTROL NUMBER
At least one of REF02 or REF03 is required.
REF*XZ - PHARMACY PRESCRIPTION NUMBER
At least one of REF02 or REF03 is required.
- This is the Pharmacy Prescription Number submitted in the 2410 REF02 from the 837 claim.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
DTP*472 - SERVICE DATE
TOO - TOOTH INFORMATION
If either TOO01 or TOO02 is present, then the other is required.
PWK*V4 - TRANSFER TO ENTITY 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.
AND
The entity in this loop is different or not present at the claim level (Loop ID-2210DA). If not required by this implementation guide, do not send.
- This is not for COB reporting or when a service is transferred internally within the payer's system(s).
- The PWK segment is syntactically required in order to use the Transfer to Entity data in Loop ID 2225DA.
PER*IC - TRANSFER TO ENTITY 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.
N1 - TRANSFER TO ENTITY NAME
- R0203
At least one of N102 or N103 is required. - P0304
If either N103 or N104 is present, then the other is required. - C0703
If N107 is present, then N103 is required.
N3 - TRANSFER TO ENTITY ADDRESS
N4 - TRANSFER TO ENTITY 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
PWK*R6 - SUPPLEMENTAL STATUS 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.
- See Section 1.4.3.1 - STC Composite and Code Use Rules, for additional information.
- This segment must not be used in place of reporting the highest level of specificity or the most accurate status information in the 2220D STC Segment (STC01, STC10 and STC11).
- This segment must not be used to repeat or duplicate the verbiage associated with the status information reported in the 2220D STC Segment (STC01, STC10 and STC11).
- When service level information caused the rejection, it must be reported at the Loop 2220D STC Service Level Status Information.
PER*IC - SUPPLEMENTAL STATUS 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.
SE - TRANSACTION SET TRAILER
GE - FUNCTIONAL GROUP TRAILER
IEA - INTERCHANGE CONTROL TRAILER
| | 277 Health Care Claim Acknowledgment (008020X330)SEPTEMBER 2021 Copyright © 2008-21, X12 Incorporated, Format © 2008-21 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 X12 Health Care Claim Acknowledgment (277) implementation guide is a business application level acknowledgment for the X12 Health Care Claim (837) transaction(s). This acknowledges the validity and acceptability of the claims at the pre-processing stage of those requested claims or predeterminations. |
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 X12, Health Care Information Status Notification (277). This implementation guide focuses on the use of the 277 as an acknowledgment of receipt of claim submission(s). 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 claim submission acknowledgment. The intention of the developers of the 277 is represented in this guide. Entities receiving this application of the 277 include, but are not limited to, hospitals, nursing homes, laboratories, physicians, dentists, allied health professional groups, employers and supplemental (i.e., other than primary payer) health care claims adjudication processors. Organizations sending this application of the 277 include payers, who may be insurance companies; Third Party Administrators (TPA); service corporations; state and federal agencies and their contractors; plan purchasers; and any other entity that processes health care claims. Other business partners affiliated with the 277 include billing services; consulting services; vendors of systems; software and EDI translators; and EDI network intermediaries such as health care clearinghouses, value-added networks and telecommunication 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 008020X330. 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 and real-time modes. Willing trading partners may use batch or real-time mode. |
1.3.2 Other Usage LimitationsThere are other usage limitations. There are category Code usage limitations. See Section 1.4.3.1 - STC Composite and Code Use Rules for more information. |
1.4 Business UsageThe X12 Health Care Claim Acknowledgement (277) implementation guide is a business application level acknowledgement for the X12 Health Care Claim (837) transaction(s). This acknowledges the validity and acceptability of the claims at the pre-processing stage. of those requested claims or predeterminations. Claim history parameters may vary by payers and systems. Payers may pre-process claims to determine whether or not to introduce them to their adjudication system. This pre-adjudication process is performed so claims that are incorrectly formatted or missing information can be corrected and resubmitted by the provider. The level of editing in pre-adjudication programs will vary from system to system. Although the level of editing may vary, this transaction provides a standard method of reporting acknowledgement of claims. The business function identifies claims that are accepted for adjudication as well as those that are not accepted. This 277 transaction is the only notification of pre-adjudication claim status. Claims failing the pre-adjudication editing process are not forwarded to the claims adjudication system and therefore are never reported in the X12 Health Care Claim Payment/Advice (835). Claims passing the pre-adjudication editing process are forwarded to the claims adjudication system and handled according to claims processing guidelines. There is a one to one relationship between a single 277CA Transaction Set (ST-SE) and a single 837 Transaction Set (ST-SE) that it acknowledges. To acknowledge multiple 837s (ST-SE), multiple 277CAs (ST-SE) must be used. Final adjudication of claims is reported in the 835. See Section 1.4.4 Figure 1.2 - General X12 Health Care Claim Information Flow for the entire transaction flow. Figure 1.1 - Information Flow of X12 Health Care Claim Acknowledgment |
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 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. 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 or clearinghouse generating the 277 Health Care Claim Acknowledgement. When HL03 = 21, the hierarchical level contains the Information Receiver. This entity expects the response from the Information Source. When HL03 = 19, the hierarchical level contains the Provider of Service. This entity delivered the health care service. When HL03 = PT, the hierarchical level contains the Patient information. This entity is the receiver of the health care service. A detailed view of the segments and data elements used to describe the participants and their relationship is presented below. The segments and data elements are found in Loop ID-2000 and Loop ID-2100. The Information Receiver and the Provider of Service 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 a service bureau entity acting on behalf of the Provider of Service. When this occurs, the service bureau entity is described when the HL03 = 21, and the Provider of Service is described when the HL03 = 19. In other instances, the Information Receiver also is the Provider of Service. When this occurs, the same entity is described at two hierarchical levels (e.g., HL03 = 21 and 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 is a coding example of 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 Provider of Service hierarchical level: HL*3*2*19*1~ The following is a coding example of the Patient Hierarchical level: HL*4*3*PT~ |
1.4.2.1 Defining the "Patient" ParticipantThe Patient information identified in the 277 Claim Acknowledgement Transaction is derived from two possible locations within the 837 Transaction.
|
1.4.3 Status Information (STC) Segment UsageThe primary vehicle for the claim status information in the 277 Transaction is the Status Information (STC) Segment. The level of information returned in the STC Segment may vary from payer to payer. Payers are required to provide the greatest level of detail information. See Section 1.4.3.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 first element in the C043 composite (C043-01) is the Health Care Claim Status Category Code (Code Source 507). The Category Code indicates the level of pre-adjudication status of the claim. This implementation guide will only utilize Category Codes indicating Acknowledgement (Ax) and Errors (Ex). The second element in the C043 composite (C043-02) is the Health Care Claim Status Code (Code Source 508). The Status Code provides more specific information about the claim or line item. The third element in the C043 composite (C043-03) is the Entity Identifier Code (X12 data element 98). The Entity Identifier code is used to clarify the entity when referred to in the status message (CO43-02). The code list identifies an organizational entity, a physical location, property, or an individual. A list of appropriate code values for data element 98 appears within the STC segments in Section 2.4. The fourth element in the C043 composite (C043-04) is the Code List Qualifier Code (X12 data element 1270). This element is Not Used in this version of the implementation guide. 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 X12 website (https://x12.org/codes). This website includes external code lists maintained by X12 and external code lists maintained by others and distributed by WPC on behalf of the maintainer. It provides a maintenance request facility that allows interested parties to request new codes, request changes to existing codes, or view the status of pending requests. |
1.4.3.1 STC Composite and Code Use RulesThe following rules apply to use of the composites and codes within the STC segment:
|
1.4.3.2 Status Messaging for Real-time Claim Adjudication and Real-time Claim Predetermination/EstimationThe 277 Claim Acknowledgment (277CA) is used in the real-time claim adjudication and predetermination/estimation processes in specific situations to return a reply of "not accepted" or "accepted" for a claim submitted in real-time via the 837 Transaction. If a payer responds with an 835 in real-time, a 277CA will not be created. The real-time mode 277CA will be used to provide status on:
Real-time Claim Adjudication All real-time claims that are accepted into adjudication, but can't complete adjudication in real-time mode must be acknowledged using the same Claim Status Category and Claim Status Codes in the first iteration of the STC Segment. This will establish reporting consistency within the health care industry. The real-time 277CA claim status reported for these claims in Loops 2200D Claim Status Trace Number and 2220D Service Line Information, when reporting service level information, must be:
Payers are encouraged to use additional status codes to provide more detail on why the claim could not complete processing in real-time. The additional status messages could help the provider make modifications to their real-time submission processes, data and/or work flow. Claims that are accepted into adjudication for real-time processing but can't be finalized and responded to with the real-time 835 would continue processing. When processing is complete, the claim adjudication results will be reported in the payer's payment cycle 835. Real-time Claim Predetermination/Estimation
OR
Payers are encouraged to used additional status codes to provide more detail on why the claim could not complete processing in real-time. The additional status messages could help the provider make modifications to their real-time submission processes, data and/or work flow. |
1.4.4 277 Transaction UsagesThe 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 health care claim information in the following business scenarios:
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 illustrates the flow of information related to several usages of the 277. Figure 1.2 - General X12 Health Care Claim Information Flow |
1.4.5 BalancingThe quantities and amounts reported in the 277CA MUST balance at two different levels — the Information Receiver level and the Provider level. Both the Information Receiver level (2200B) and the Provider level (2200C) are cumulative values derived from the sum of accepted claims (STC03=WQ), rejected claims (STC03=U) and corresponding amounts (STC04) reported in the Patient Claim level 2200D Loop STC Segments. The 277CA is used to acknowledge all claim types submitted via the 837. Since the 837 can include encounters, fee for service and predeterminations/estimations claims, the total quantities and amounts reported in the 2200B and 2200C Loops will include the counts and amounts for all types of claims submitted in the 837. 1) Information Receiver Level Balancing When the Provider level 2200C is not reported, then the Information Receiver level (2200B) quantities and amounts are directly derived from and MUST balance to the sum of accepted claims (STC03=WQ), rejected claims (STC03=U) and corresponding amounts (STC04) reported in the Patient Claim level 2200D Loop STC Segments. The claim counts and amounts reported in the 2200B Information Receiver Loop must equal the sum of the claim counts and amounts reported in all 2200C Provider Loops as defined below:
2) Provider Level Balancing The claim counts and amounts reported in a 2200C Provider Loop must equal the sum of the claims and amounts reported in the Patient Claim level 2200D Loop STC Segments associated to that provider as defined below:
|
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 Health Care Claim (837)Submission of the 837 Health Care Claim Transaction is the first step toward creation of the Health Care Claim Acknowledgment (277CA) transaction, when trading partners have implemented the 277CA transaction as part of their front-end EDI claims solution. The 277CA transaction acknowledges acceptance or rejection of all claims submitted via the corresponding 837 transaction. |
1.7.2 The Implementation Acknowledgment for Health Care Insurance (999)The 999 Implementation Acknowledgment for Health Care Insurance transaction is designed to respond to one and only one functional group (i.e. GS/GE), but will respond to all transaction sets (i.e. ST/SE) within that functional group. A 999 transaction either accepts or rejects an entire 837 transaction set (ST to SE). There is no granularity in the 999 to act on individual claims. When trading partners have implemented the 999 and 277CA transactions as part of their front-end EDI claims solution, the 277CA must be provided under certain situations. When implemented between trading partners, the 277CA must be sent after the 999 transaction indicates the 837 transaction was "Accepted" (Loop 2000 IK501 code "A") or "Accepted But Errors Were Noted" (Loop 2000 IK501 code "E"). When the 999 IK501 code is "A" or "E", the entire 837 transaction set (all claims) MUST continue on for further business validation and acknowledgment. However, when the 837 is either accepted or accepted with errors, not all claims may result in adjudication. The 277CA must indicate for each claim if it was accepted or rejected. An error in the 837 that precludes creation of a valid 277CA requires the 999 to reject the 837. While the 277CA cannot report syntax issues, it can reflect a claim was rejected for the syntax issues previously identified in a 999 transaction that reflected "Accepted But Errors Were Noted". At the time of publication of this TR3, Claim Status Code "684" would be used in the 277CA for each claim rejected for the syntax errors reported in the 999 where the IK501 code "E" was reported. The 277CA transaction will not be sent when the 837 transaction set was identified as rejected in the 999 transaction (Loop 2000 IK501 code "R"). |
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 structure of the 277 Health Care Information Status Notification and describes the positioning of the business data within the structure. 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 X12 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 (008020X330) defines the X12 requirements for the Health Care Claim Acknowledgment. It is based on version/release/subrelease 008020 of the X12 standards. |