Bug Report: Billing Manager Marked as Cleared not working as designed

@sjpadgett The errors are there. The errors are not being reported. We don’t have a dedicated testing group anymore so these broken things have gotten into the codebase.

There is a user going through the system and he is pointing out all of these things in the billing suite that are not right.

Here are a couple of tickets I have in my system for billing issues. Here is the first observation.

I found something that might be of interest to this topic.

I am working on sorting out and correctly resetting the statement counts so I can send all ins due to our biller for follow up. In doing so, I found that the system does appear to know when a given insurance has/has not paid but this isn’t translating to the report writer.
In ss 01 when pulling up a patient and reviewing billing notes, the system reflects that the secondary is due (pointer 0000002). In the collections report from ss 02, the statement has ticked off a count and was reflecting the balance is due to the patient incorrectly.
This almost make it seem that the statement count is allowed to override what is actually happening with the status and bypassing the billing.

I found several more examples of this that also included primary payments being bypassed. I dont understand the logic in the code of course but it appears that the order of the statement should occur only after all insurances have paid and not prior to. Perhaps it’s jumping in there when it shouldnt at all - I’m trying to come up with a scenario why this would be necessary but of course I am lacking the knowledge of any other dependencies that might exist. If there are none, maybe it can be disconnect from what it’s doing to the report writer but re-purposed the prv count and leave it in the system. I’m finding the statement count is useful in giving me the ability to use it as a way to determine what the status of an encounter in the writer and it’s billing status when I’m in that part of the system.

Thoughts?

Edit: Adding how I am adjusting the prv to act more like a aging “Review Code” of sorts so it does both split off the ins vs patient due and also signals what is necessary. I found I can add any positive or negative integer - any letters or other characters result in a “0” result.

Repurposing PRV:

-2 = Primary has not paid
-1 = Secondary has not paid.
0 = Unused
1 = Ins balances paid - patient due balance
2 = Ins balances paid - HCF Due
12 = Ins balances paid - patient due ins and HCF balance
3 = Patient balance due - No Secondary
5 = Private Pay - balance due

Special
-10 = Insurances Due - Problem with coverage/payments.

Here is his next messages

Adding a comment to this as I’m working my way up to current day…

it just occurred to me that something in the system is flagging these statement counts separate from actual events and not a user error. I’m about 6 weeks back (May) now and I’m not finding anything correctly flagged and the only items not on these reports are actual claims that are fulling paid and are excluded via zero balances.

I’m saying this from the point of view that the system might re-flag everything I’ve spent the day fixing and starting all over. Which will make me cry.

Thanks for the supporting words - sometimes I feel I go too far. You know, like how you were saying that your wife says you tend to over explain sometimes? It just means you see it so clearly that to make someone else understand you know how much of the picture needs to be painted. One dab of the brush does not make a Mona Lisa! lol

So I ran across something current. I went into the report writer and in pulling up this month’s claims I came across the attached. It’s been dinged to a -1 and only a memo was posted regarding a denial. The reason was once again mentioned only as Unknown Adj, and It’s been dinged as though a payment was made and has slide to the secondary when it shouldn’t have.

LOL, I suppose I did ask for it, didn’t I! :wink:

For sure we need to set up some automatic billing state reviews and become more interactive with user based on current billing states in postings. Even extending better logging to prove off the many ways user can miss billing progress states for which they may be responsible.
Most the above is from posting which i’ll look into once manager is sorted.

Is the balance incorrect or the fact patient has a balance?
Also, was the demographic billing report patient due incorrect balance ever resolved?
Is patient balance in ledger correct?

Okay i’m going to try again. Can someone please tell me why a biller would want to have the option to Clear a set of claims when they run a batch or download hcfa 1500 forms?
Remember, billed already gets set with normal claim disposal and with the way Clear currently works when selected from confirm prompt, first claims resets then turns around and sets claim and billing status as if a normal batch run!!! (download button and MarkAsCleared get set on submit)

This makes no sense too me or does clear just not work as intended. @brady.miller @sunsetsystems do you remember what clear was meant for? @stephenwaite or @visolveemr maybe can clarify for me. Someone!

most likely Rod wanted clear to be a dry run and the bug is turning around and setting claim and billing status as if a normal batch run

1 Like

My thoughts also! For some reason Rod is not set as author on the process and report script.

I have Validate setup to not set the billed flag. Do you think this is the way we should go? Also should I allow batch to download or just popup log on validate?

sure, sounds fine, guessing have a file downloaded could help with debugging the 837

Okay thanks Stephen. I’m going to replace confirm clear option with just validate option and leave billed unset.

1 Like

Hi Jerry, I’m the user from Sherwin’s previous post that encountered this so maybe I can clarify.

The balance due appears correct - the problem I’m finding is the system incorrectly dings the encounter before all of the insurances have actually paid their portion and changes the prv counts from -2. When this occurs enough times to finally change the prv status to a +1, it changes the status in the demographics as it thinks the amount is now due by the patient. I’ve had to manually process all open claims we have in the collections report writer to correctly reflect this for an accurate insurance and patient aging reports. I’d say I had to adjust 95% of the open claims for this to turn out correctly - at least until the system dings it again and I have to repeat. I am unsure of all of the triggers that are causing this but I did determine that even adding a note on a claim and checking resnd would cause it which was reflected in the claim 2910 in the screenshots from Sherwin’s post.

The ledger in this situation is only changed with note regarding the cause the claim was denied. All balances remain unchanged.

If you need a tester to help sort this out I’d be glad to help and contribute.

Hi @jjalb,
Thanks for the clarification. I will certainly call on you guys to verify any fix I can come up with. First I hope to get manager ready for Sherwin to look over today then I will setup my billing testing database to recreate these issues.
We need to hurry on this stuff so I don’t hold up v5.0.2 release too long…

@juggernautsei @stephenwaite
Here are billing manager changes if you want to play with before I commit:

billing_process.php (19.1 KB)
billing_report.php (81.7 KB)

1 Like

Thanks Jerry, which version of the code are these files for?

502 but if ya patch out the CsrfUtils stuff it prob will work on 501…

Here is comment from encounters.php as to why the cpt codes are in red:
// Pick up any remaining unmatched invoice items from the accounting
// system. Display them in red, as they should be unusual.
No idea why a code can become unattached. I’d track this down before anything because who knows how this could manifest in other problems in billing! I can’t figure out how to make this happen…

Here is PR Billing Manager Update by sjpadgett · Pull Request #2585 · openemr/openemr · GitHub
and there is a demo set up with link in PR

1 Like

Jerry, I ran a diff on the two files before inserting it into 501 and this is what I saw.
The left is 502. I put it in anyway and the form did not work in 501 as expected. So, this is only available in 502 which will be an incentive to upgrade when the new release comes out.

Sorry, I forgot about the new BillingUtilities class. I usually let git or PhpStorm help me with the conflicts between version. Git is good about place marking conflicts but PhpStorm will allow you to select version to overwrite new version where they differ.
For sure Brady or I have no plans to create any new patches for 501 but if you need this for 501, it is doable without too much work.

If you could post a file here for 501 that would be helpful. Thank you.

I’d didn’t say i’d do it. I just suggest it is not too hard to do…

Gotcha!! Working on it now… I’ll post it when I am finished with the diff.