Claim Adjustment Codes in secondary x12 billing

alexvolin wrote on Monday, September 15, 2014:

We are trying to start electronic x12 submission of secondary bills (primary x12 works just fine) for our client who is an out-of-network provider. It means that there are no any contractual limitations and if a primary payment is reduced or even fully denied (equals zero because this service is not covered) then the balance must be submitted to the secondary payer as a patient responsibility but not as a contractual adjustment of fees.

We do not receive ERA 835 so we have to enter payments and adjustments manually. In the secondary x12 batch we need to get something like CAS * PR * 96 or CAS* PR * 204. Unfortunately we could not find how to do that. Looks like in the ‘Batch Payments’ there are only the charge adjustments (CAS * CO), deductibles (PR * 1) and takebacks. The MSP codes appeared to be not working at all (I could not find any string of code storing these selections into db and all reason_code fields in the ar_activity table are either NULLs or empty). We are using v4.1.2(7) on AWS Linux.

I tried the EOB entry. I added “Not Covered’ option with the type of ‘Other pt resp’ to the Adjustment Reasons list. But it gave me only PR*2 which is a Coinsurance and may not be appropriate in this case.

Am I missing something here? Is there any workaround for this (except manual editing of a file)? And also how can we add an adjustment to the claim level (CAS before AMT*D in CLM section)?

fsgl wrote on Monday, September 15, 2014:

Add another Adjustment Reason to Lists, such as OON (out-of-network). Click the W link in the EOB Posting Invoice, after the primary has paid & choose the new adjustment reason. This effectively will make the remaining balance the patient’s responsibility.

Details of the 837P are irrelevant because there is no point submitting to secondary insurers which won’t pay out-of-network practices. Avoid Batch Payments, post in the EOB screen & everything should be right as rain.

visolveemr wrote on Wednesday, September 17, 2014:

Based on our understanding, there are two problems.

a. In the batch payments (during Manual Payment posting), the MSP code is not saved properly for new payments; But is saved properly during edit.
b. The MSP codes like 96 and 204 are not handled properly in X12 Claim generation.

Thanks
OpenEMR Customization/Support Team,
ViSolve Inc
services@visolve.com
Demo’s @ ViSolve Demo Library

alexvolin wrote on Tuesday, September 23, 2014:

We submit to secondary insurers who cover out-of-network practices AFTER the primary insurance denied an out-of-network claim. In this case (COB – Coordination of Benefits) they are very sensitive to details.

Unfortunately EOB posting doesn’t work either. As I wrote before I added a ‘Not Covered’ adjustment reason but the result was that all patient responsibilites (except deductible) were added together and just one CAS * PR * 2 was generated for the total amount. This is not good for the COB claim.

alexvolin wrote on Tuesday, September 23, 2014:

The MSP code is saved during edit if and only if there is a non-zero amount in the Payment column. For the non-covered or other fully denied services it just doesn’t work. And you absolutely right that MSP codes aren’t handled properly in x12 claim. Not only CAS * PR * 2 is generated instead of the real msp code but also another old problem is still there – generating of multiple CAS segments. It was discussed here:

http://sourceforge.net/p/openemr/discussion/202505/thread/74dfb2c5/#e16a

fsgl wrote on Tuesday, September 23, 2014:

Batch Payments works great for Medicare remittances but not so well for anything else. It handles adjustment & deductible with automatic selection of the appropriate MSP codes, but not Takeback. The user must use EOBs for more complex tasks.

If a new Adjustment Reason is paired with the incorrect Type, the W link won’t work for amounts denied by insurance if it’s the patient’s responsibility. If the Type, Other Patient Responsibility, is ineffective; use Comment. See attachment a.

For those claims with out-of-network coverage, it would not make sense to add an OON Adjustment Reason. Use Noncovered Service instead or whatever the user desires for claims with no out-of-network coverage, coupled with the correct Type.

There is an example for Jane Seymour in the Weekly Demo, which resets on 9/29. The batch.txt is the corresponding 837P.

Regarding the problem with multiple CAS segments, the workaround is fairly simple. When sequestration began, we thought it was necessary to divide the write-off into 45 & 253 adjustments. Office Ally informed us that they are unable to handle the breakdown, therefore we lumped the two into 45, as one adjustment.

There has been no problem with our claims using only the 45 or with the way we handled the 92015 charge over the past 2 years. Once the Adjustment Reason has been properly set up & all write-offs are combined into the 45 adjustment code, the user should not have to muck about in the 837P.

alexvolin wrote on Sunday, October 05, 2014:

Thank you for your comments. We agree about CAS * CO * 45. The reason for write-off really doesn’t matter. The problem is with the CAS * PR. Whatever Reason Type we select to pair with our custom Adjustment Reason it always generates CAS * PR * 2 which essentially means ‘coinsurance’. The same thing is in your example. Some insurance plans do not cover coinsurance as a patient liability but pay for non-covered services.

As I understand now after your explanation we need to extend the Reason Type list to include some other codes, say CAS * PR * 96. Is it hardcoded? In what file? Can I just add a new Reason Type in my local copy without messing up other parts of code?

fsgl wrote on Sunday, October 05, 2014:

It is correct that MSP 2 = coinsurance. Medicare never pays on the 92015 because it is a non-covered service. Technically there should be a 49 in that segment, but none of the secondary insurers has ever refused payment, provided that Refraction is part of the patient’s coverage. The secondary insurers are not concerned about the details why the primary did not pay; only that it was not paid & if it, the secondary, has the liability.

If the practice is submitting 837P’s via a clearinghouse that is demanding other MSP codes, it’s almost a reason to change the clearinghouse. Office Ally asks for a simpler rather than a more complex 837P.

The 3 MSP’s are hardcoded. Try looking first in openemr/library/gen_x12 _837_inc.php.

Impossible to predict if the customization will cause additional problems.

cmswest wrote on Tuesday, November 25, 2014:

Prior to this fix every claim adjustment was coded as a 45. Since the logic did not possess the skill to sum and put into one adjusment like fsgl’s math club the elec. claims were rejected.

This will help those who post with 835s to submit secondary claims.