Here is the weird thing. I went ahead and uploaded those two ERA’s into a snapshot of the same database where the ar_session and ar_activity tables were empty. It worked fine and no funds were undistributed. I attempted it again with the snapshot of the database with full ar_session and ar_activity tables and it gave me the same undistributed fund issue.
right, it’s only setup to post an ERA once
Correct. It seems that one encounter was on two different ERA’s, one of which the claim was denied. After talking with Tony, he is under the impression that OpenEMR doesn’t know how to handle new adjustment codes. I am investigating this as we speak. Also, since OpenEMR is primarily geared towards general health, my client is not in the GP field. Some of the adjustment codes may be causing this issue.
adjustment codes have been updated in master, openemr/BillingUtilities.php at master · openemr/openemr · GitHub
Thanks. I had tomake some minor adjustments because my client is on 500, not 501.
Right off the bat, I see a missing adjustment code of ‘243’ in that file.
ok, recently pointed out that there’s a class of codes here as well, openemr/edih_835_code_class.php at master · openemr/openemr · GitHub
maybe we could eliminate redundancies and consolidate the classes
for 5.0.0 you could add the codes here, openemr/adjustment_reason_codes.php at rel-500 · openemr/openemr · GitHub
I pulled the codes from the first file and did that already. I also pulled in the codes into the remark_codes.php in the billing folder.
1 Like
With a little more investigation I think I can fix this bug. I’ll keep you updated as the process completes.
1 Like
payers can do creative denials, instead of using denied claim openemr/edih_835_code_class.php at master · openemr/openemr · GitHub they can say it’s processed with 1 2 or 3 and then follow with an adjustment code that results in no payment and needs follow up
Its looking like the ERA reader in EDI history pulls from edih_835_code_class.php and the sl_eob_process.php pulls from the adjustment_reason_codes.php. The code is all over the place. The other issue I have is these codes are hard coded in these files when they should be pulled from a table in the database.
actually, matrix just improved list options for long lists and may be best to put all edi codes there. better yet, leave in classes, consolidate and add addendum codes as a last check if code is not in class. I like this option bestest 
1 Like
I think that is what happened. I need to follow up with the billing supervisor about this. maybe her insight can help me.
He everyone,
After doing a lot of troubleshooting I discovered that one of the issues is related to co-pays. It appears that when a copay is prepaid and the ERA file is uploaded after I get the following error:
“EOB charge amount $x for this code does not match our invoice”.
When I removed the line in the ar_session table that had the co-pay I was able to upload the ERA without issues. So, the code is misbehaving for their workflow. I know that the issue of undistributed funds is common in OpenEMR, so for now I am going to assume that this is not caused by their custom work.
This explains why the file uploaded fine when I had the blank ar_session table. Instead of having them change their workflow I will go through the code to find a fix.
1 Like
I’ve noticed that for the adjustment codes that result in no payment, we get the same behavior in 501. Basically, OpenEMR updates the accounts receivable table as if its been paid even if no payment came through. This is specifically for 243 adjustment code which is a ‘creative denial’ as @stephenwaite called it.
more information that might help someone else with the same problem:
After looking at other customers’ databases, I noticed that there are customers whom have never gotten an adjustment code and there are some who received several thousand. So this explains why only a few customers run into the undistributed funds. It seems that no code exists that handles Adjustment codes.
hi @growlingflea, adjustment codes should be the norm when billing insurance unless billing the exact allowable fee like is sometimes done with Medicare since they publish their schedule
probably could put a catch for CAS*CO*96 or CAS*PR*96 near this prevent claim balancing for MIPS incentive adjustments by stephenwaite · Pull Request #2369 · openemr/openemr · GitHub
If I understand you correctly: there are insurance adjustment codes that when returned, need to be caught to prevent claim balancing.
The other thing that I noticed is that there are several files that list the adjustment codes and I’m wondering if it would be worth the effort to parse those files and create a table that has all of the adjustment codes with the ability to say “balance” or “not balance”. I imagine that some of the codes should trigger a red-flag.
I am of the opinion that hard coding any information that changes on a yearly basis (or any time frame) is a bad idea.
Thoughts?