RFI Browser

Back  RFI # 1893: CARC code validation

Formal vs. Informal Help Informal Formal


Cathy Brock


We've been using the BHT04 date to validate all of our non medical codesets per the final rule which states they are valid at the time the transaction is initiated.
We have a payer that is telling us that we should be using the remit date (DTP573) as a secondary payer to validate the RARC/CARC codes.
If we are using the BHT date, which should be the date the claim was created, how would we ever get a claim where the BHT date is after the remit date? This would indicate that the BHT date is being changed along the processing path and is not the valid date.
What date should we be using to validate non medical code sets as a secondary payer?
Is using the BHT date accurate to use as a primary payer?

Submitter Assigned Keywords

CARC RARC code validation


The validity criteria for each non-medical code list is determined by the owner of the specific list. There is no single date that can be used for validation in all situations. For instance, the owners of the Claim Adjustment Reason Codes state their policy in an FAQ on www.wpc-edi.com that currently reads:

When populated, this date identifies that the code can no longer be used in original business messages after that date. The code can only be used in derivative business messages (messages where the code is being reported from the original business message). For example, a Claim Adjustment Reason Code with a Stop date of 02/01/2007 would not be able to be used by a health plan in a CAS segment in a claim payment/remittance advice transaction (835) dated after 02/01/2007 as part of an original claim adjudication (CLP02 values like "1", "2", "3" or "19"). The code would still be able to be used after 02/01/2007 in derivative transactions, as long as the original usage was prior to 02/01/2007. Derivative transactions include: secondary or tertiary claims (837) from the provider or health plan to a secondary or tertiary health plan, an 835 from the original health plan to the provider as a reversal of the original adjudication (CLP02 value "22"). The deactivated code is usable in these derivative transactions because they are reporting on the valid usage (pre-deactivation) of the code in a previously generated 835 transaction. "

As to the remit date being before the BHT date, by definition a secondary claim would be created after the receipt of the remittance advice from the primary payer. Therefore, the remit date related to the primary payer's adjudication must be prior to the BHT date of the claim to the secondary payer. This applies to all prior payers on later claims as well.

In addition, the BHT date can be different than the original date of the claim from the provider, especially if the claim passed through multiple intermediaries. The BHT date is the date that the 837 was created by the sender of that transaction within the Functional Group and Interchange. IIt is a technical date, and not a business date, and may not be related to the business creation date of the claim. Validation should take this into consideration.


Future guides include a new date identifying the original claim creation date on each claim within an 837.
Submission 1/13/2014
Status Date 2/7/2014
Status F - Final
Primary References
Document 005010X222
Section2320 CAS
External Code ListCODE SOURCE 139: Claim Adjustm
Secondary References
RFI ID 2365
Document 005010X223A1
Section2320 CAS
External Code ListClaim Adjustment Reason Code