999 Implementation Acknowledgment for Health Care Insurance Standard

Follow

UHIN Implementation Acknowledgment for Health Care Insurance Standard is compatible with all HIPAA Requirements.

Purpose

The purpose of this Standard is to detail the Standard transaction for the reporting of transmission receipt and transaction and/or functional group X12 and Implementation Guide Errors (TR3).  This Standard adopts the use of the ASC X12 999 transaction. 

Applicability 

This Standard applies to all X12 ‘batch’ transactions. The 999 would be sent by both payers and providers to acknowledge receipt of batch transactions.

Trading partners outside of the UHIN community may choose to use a 997 as an acknowledgement response.  It is not intent of the UHIN Community to require the 999 and the 997. 

Details

999 Requirements

The Implementation Acknowledgment for Health Care Insurance transaction will be the ASC X12N 999 transaction. A copy of the 999 transaction may be purchased at the WWW.WPC-EDI.COM. The purpose of the 999 is to acknowledge receipt of and/or to send the results of a syntactical and IG guide (TR3) analysis of the acknowledged transaction.  The 999 can act as a method of verifying that a trading partner has downloaded (received past their mailbox) the transaction.

Payers

Fast Batch: If the payer does not respond within 1 minute the network will send a message to the provider indicating that the payer is not available.

Fast batch responses: no 999 is expected from the receipt of a fast batch response.  However, 999s may be sent if the incoming (from the provider) fast batch transaction has X12 or Implementation Guide (TR3) errors.

Batch: A 999 will be required in response to any batch transaction.  For normal business the 999 would be returned within 1 business day.

Operating Rules: Phase III Rule (350): Health Care Claim Payment Advice (835) Infrastructure Rule

 4.2 Health Care Claim Payment/Advice Batch Acknowledgement Requirements

These requirements for use of acknowledgements for batch mode places parallel responsibilities on both receivers of the v5010 X12 835 and senders of the v5010 X12 835 for sending and accepting v5010 X12 999 acknowledgements. The goal of this approach is to adhere to the principles of EDI in assuring that transactions sent are accurately received and to facilitate health plan correction of errors in their outbound transactions.

 This rule adds to the Phase I and II CORE infrastructure rules requirements by specifying the use of the ASC X12 005010X231A1 Implementation Acknowledgement for Health Care Insurance (999) when conducting the v5010X12 835.

**While CORE rule 350 stipulates the use of a 999 (section 4.2), this requirement has specifically not been adopted by HHS. See 45 CFR Parts 160 and 162**

Providers

  1. Providers are allowed to return a 999 on all incoming batch transactions. If the 999 is not used, error reporting will need to be addressed between trading partners by whatever means are deemed appropriate.
  2. Users are required to send only the following segments in the 999: ST, AK1, AK9, and SE when acknowledging a compliant transaction. When acknowledging a transaction with errors all appropriate segments must be sent.
  3. The 999 transactions will be sent and received from point to point (e.g. provider A endpoint to payer C endpoint or from provider A endpoint to repricer B endpoint. Provider A endpoint would not receive a 999 from Payer C endpoint if sending transaction through Repricer B endpoint.) See example below.

 

mceclip0.png

  1. The endpoint shall generate the 999. Each endpoint is responsible for creating appropriate reports to track 999’s.
  2. Recipients are responsible for deleting old 999 files as needed. Translators will have a utility to allow recipients to accomplish this.

TA1 Requirements

  1. All users[1] may send a TA1 if an error is detected at the Interchange level (i.e., one of the error messages in TA1 was applicable). The use of the TA1 is determined by trading partner agreement. If the receiving trading partner chooses not to use the TA1 and can identify the sender they must contact the submitting entity to identify the failed transaction. UHINet will support the exchange of the TA1 Transaction.
  2. When used, the endpoint shall generate the TA1 (TA1 is only used when there is an applicable syntactical error at the Interchange level). Each end point is responsible for creating appropriate reports to track TA1 records.
  3. Recipients are responsible for deleting old TA1 files as needed. Translators will have a utility to allow recipients to accomplish this.

Unique Global Tracking Number

The GS06 will be used as the unique global number for 999 tracking purposes.  This means the GS06 values are unique within an ISA/IEA and the GS06 values are also unique across interchanges.  It is required UHIN users maintain unique GS06 values over a minimum of a 60-day period, but a year is recommended.

IMPLEMENTATION ISSUES

  1. All endpoints on the network must be able to accept and generate 999s.
  2. Providers and payers must train staff regarding use of the 999.
  3. This standard will need to be reviewed as versioning may change at the national level.
  4. Implementation Dates:
    • This Standard is effective when a trading partner begins to send batch 5010 HIPAA transactions.
    • For providers, the translator must be able to turn on individual payers one at a time as payers begin sending and receiving 999s.
  5. It is recommended that provider translators generate a 999-reconciliation screen, which contains the following elements as a minimum data set:
    • Date batch transaction was sent (according to providers computer)
    • Time batch transaction was sent (according to providers computer)
    • GS06 value of the batch transaction (unique transaction control number)
    • TPN of entity who received the batch transaction (ISA08)
    • 999 received? Y/N
    • Date 999 was sent (according to 999-senders computer)
    • Time 999 was sent (according to 999-senders computer)
    • 999 Functional Group Status (accepted, accepted with errors, rejected)
  6. There may be some systems that are unable to report more than 999 errors in a 999 transaction. Those systems would be exempt from this Standard.

 

History: (MM/DD/YY)

 

Original

A* 1

A* 2

A* 3

A* 4

A* 5

A* 6

ORIGINATION DATE

02/03/09

 

 

02/09/09

7/10/13

 

 

APPROVAL DATE

 

 

 

08/05/09

9/11/13

 

 

EFFECTIVE DATE

 

 

 

09/05/09

11/6/2013

 

 

* A = Amendment

 

[1] This includes but is not limited to Route Servers sending to Router Clients and Router Clients sending to Route servers

 

 Click below to download a copy of this document.

0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.