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?
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.
It 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.