As I promised in my last article, I am revisiting the subject of ERAs and the operating rule changes taking effect on 1/1/14. In previous articles we discussed the benefit of universal availability of the ANSI 835 electronic remittance and how it can improve your revenue cycle management.
There are two more aspects of this rule that will benefit providers. First, the rules include the establishment of timing criteria between the arrival of the payments and the availability of the 835. This is referred to as the “three day rule”. Basically, the rule states that the 835 and the EFT will arrive within 3 business days of each other. It does not say which one will come first, but that when you get one of the transactions, the other will either have been sent already, up to three days in the past, or will arrive up to three days later. This will help facilities match the check to the 835 and react quickly when either transaction is late.
The other area of emphasis is establishing standards for the codes used in the 835 that represent the reasons for adjustments and other notes in the 835. Over the years, these codes have been used subjectively by payers to represent very different transactions from payer to payer. This lack of standardization has prevented detailed automated posting of these transactions for all payers and confusion regarding the information contained in the remittance.
These codes are referenced in the ACA and referred to as:
CARC – Claim Adjustment Reason Codes
RARC – Remittance Advice Remark Codes
CAGC – Claim Adjustment Group Codes
NCPDP – External code List reject codes
The standardization of these codes is intended to help ease current issues associated with the processing of these transactions, including:
- Delays in posting of payments and adjustments
- Manual provider follow up with payers regarding unclear transactions
- Incorrect billing and posting of patient co-pays and deductibles
- Write-offs of billable charges
- Incorrect secondary billing
The ANSI 5010 835 specs do not include any definition of these codes. This has been left to the health plans themselves. Which has led to a built in variance of the definition of these codes that has blurred their meaning when providers attempt to interpret them. Another issue is that these codes are updated frequently, as much as three times a year. This means that payers not current on these updates may continue to use deactivated codes or may not be aware that new codes exist. Many providers and software vendors as well are not informed regarding these code set updates and what they mean so when new codes arrive in 835s, they do not know what to do with them.
The standards begin by restricting where these codes can be used within the 835. As a company that develops software that reads 835s and stores the data in a database, this has been a particular problem over the years. Some payers place transactions regarding adjustments in the “claim area” of the 835 while others place the same information within the charges associated with the claim. While both methods are HIPAA compliant, it makes it very difficult to make certain assumptions regarding whether or not these transactions are actually adjustments to a claim or to specific charges. Payers often use codes or code combinations specific to their health plan or use standardized CARCs and RARCs in a proprietary way.
CAQH/CORE (www.caqh.org) took on the task of developing standards to minimize these issues and the impact that they have on the administrative costs associated with processing these transactions. The approach that they took was to develop a list of common business scenarios regarding the adjudication of claims and to develop standards for each business scenario. They recognized the fact that it would be impossible to identify all business scenarios and develop standards for each one. Even if it could be done, inefficiencies in the process would continue to exist until the project was completed. It was agreed that it was more important to deal with the common business scenarios quickly than to develop some solution that would deal with all of them. They took the approach of dealing with a minimum list of common business scenarios and setting standards for the maximum set of allowable codes.
In the draft rule, they took on the following business scenarios:
- Additional Information Required – Missing, invalid or incomplete documentation
- Additional Information Required – Missing or invalid data
- Billed service not covered by health plan
- Benefit for billed service not separately payable
Along with assistance by WEDI, another standards organization, they developed a maximum set of CARC/RARC/CAGC or CARC/NCPDP Reject Code/CAGC code combinations that could be used for each of these four scenarios. The second set of combinations applies mostly to retail pharmacies. Additional details regarding these code set requirements can be found in this article on the CAQH/CORE web site:
The standards developed for these business scenarios, although not comprehensive, will go a long way toward improving the efficiency of posting these transactions since they apply to a majority of transactions. Over time, expect additional business scenarios to be addressed through the same process.
By Kalon Mitchell – President, MEDTranDirect, Inc.