Claim Acknowledgement Standard v3.2


UHIN 277 Claim Acknowledgement Standard is compatible with all HIPAA requirements.

Purpose: The purpose of this Standard is to provide a standardized claim acknowledgement in response to a claim submission. This transaction will be used to report on the status of a claim/encounter at the pre-adjudication processing stage (i.e. before the payer is legally required to keep a history of the claim/encounter).

Edits on submitted claims are often referred to as “front end” edits. These edits may vary from payer to payer, but must be reported in a standardized format. This transaction acknowledges claims that are accepted and those that are not, on a per claim basis.

Applicability: This Standard applies to 5010 Claim acknowledgements to the HIPAA X12 claim/encounter (837) transactions.


  1. UHIN requires the use of the ASC X12N 005010X214 277CA Health Care Claim Acknowledgement transaction in addition to other commonly non-HIPAA acknowledgements. The 277CA is required by Uniform Billing Rule 590-164.

See the Washington Publishing Company web site ( to purchase a copy of the implementation guide.

  1. Connectivity guidelines are specified in the UHIN Connectivity Companion Guide.
  2. Provider Responsibilities:
    • Providers are responsible for assigning a unique claim/encounter identifier (called the Patient Control Number, PCN) in the CLM01 of the 837 (Health Care Claim/Encounter) transactions. This number must be unique to each claim/encounter or providers will have difficulty identifying claims/encounters in the EDI status reports received from payers.
    • Providers must have software at their end to be able to receive and translate the transaction.
    • Providers must establish one of the UHIN approved connection types including as found in the Technical Reference Manual; SOAP over HTTP web services, SOAP + WSDL, HTTP MIME Multipart, Secure File Transfer Protocol (SFTP).
  1. Payer Responsibilities:
    • Payers will return the information in the Claim Acknowledgement reports for batch claims as shown in Appendix A “277 Claim Acknowledgement Mapping”:
    • Payers will use the Claim/Encounter Status codes for this transaction in the manner detailed in the implementation guide. If a payer needs a code that is not within the national code list, then it is the responsibility of the payer to alert the UHIN Standards Committee to convene the UHIN Codes Committee to review the new code(s) needed. Only official national codes may be used. To see the list of official codes go to
    • When a payer returns a status with the category code of “A2" (claim/encounter accepted for adjudication), the payer must also send their claim/encounter control number in REF02 for Loop 2200D when REF01=1K).

Acknowledgement Categories:

    • A0 Acknowledgement/Forwarded - The claim/encounter has been forwarded to another entity. In cases where a trading partner (e.g., a repricer) is passing the claim/encounter onto the destination payer the code “A0 - Acknowledgement/Forwarded” will be used when the claim/encounter is accepted by the trading partner. In these cases, the trading partner would utilize the batch mode response detailed in item (d) below, and would use codes ”A0" for claims/encounters which passed their ”front-end“ edits, or ”A3" for /encounters which were rejected. The trading partner does not return their claim/encounter identification number in A3 responses. No further response is necessary.
    • A1 Acknowledgement/Receipt – The claim/encounter has been received. This does not mean that the claim has been accepted for adjudication.
    • A2 Acknowledgement/Acceptance into adjudication system - The claim/encounter has been accepted into the adjudication system. The payer claim/encounter control number will be returned on claims/encounters with the “A2" status code.
    • A3 Acknowledgement/Returned as non-processable claim - The claim/encounter has been rejected and has not been entered into the adjudication system.
    • A4 Acknowledgement/Not Found – The claim/encounter cannot be found in the adjudication system.
    • A5 Acknowledgement/Split Claim - The claim/encounter has been split upon acceptance into the adjudication system.
    • A6 Acknowledgement/Rejected for Missing Information - The claim/encounter is missing the information specified in the Status details and has been rejected.
    • A7 Acknowledgement/Rejected for Invalid Information - The claim/encounter has invalid information as specified in the Status details and has been rejected.
    • A8 Acknowledgement / Rejected for relational field in error.

Error Categories:

    • E1 Response not possible - System Status
    • E2 Information Holder is not responding; resubmit at a later time.
    • E3 Correction required – relational fields in error
    • E4 Trading partner agreement specific requirement not met: Data correction required. (Note: A status code identifying the type of information requested must be sent).

When a Claim Status Code 21 [Missing or Invalid Information] is used, additional STCs are required to be sent, to clarify what data is missing or invalid.

  • Batch Response Mode:

When an 837 transaction (ST-SE transaction) is initially received by a trading partner, the Claim Acknowledgement must be returned on a batch-for-batch basis with Claim/Encounter (837) transactions if the original claim/encounter transaction was accepted in a valid format (i.e., 997 report shows acceptance of the functional group).

  • Response Time:

Payers are required to return the batch EDI-Claim/Encounter Status within 3 business days of receiving a Claim/Encounter (837) transaction.

  • Handling Replacement Claims/Encounters.

A replacement claim/encounter is one which uses the value of “7” in CLM05-3. 

Payers may reject replacement claims/encounters if the payer trace number is not included in the duplicate corrected claim/encounter (Loop ID-2300, REF01=G8), or if the payer trace number included in the replacement claim/encounter is incorrect (e.g., a payer claim/encounter number which was assigned to a different provider). 

  • Handling duplicate claims/encounters

Payers may reject or accept duplicate claims/encounters during the ‘front end’ editing process.  This is a business decision on the part of the claim/encounter receiver.

  • UHIN Connection:

Payers must establish one of the UHIN approved connection types including as found in the Technical Reference Manual; SOAP over HTTP web services, SOAP + WSDL, HTTP MIME Multipart, Secure File Transfer Protocol (SFTP).

  • Batch Rejection:

A batch rejection should only be used when the error generated applies to all claims in the batch.





Version 3

A* 3.1






















*A = Amendment







Click below to download a copy of this document.

0 out of 0 found this helpful



Article is closed for comments.