No apology needed. I just want to be sure we are on same page. I get the user is frustrated and agree with you this needs to be address, finally…
I see two ways to do this: one is to create an async/await confirm dialog so we can add several buttons with their own event handlers or two, create a promise/fulfilled for each billing button.
I think I can write an async/await alert/confirm function we can use global in OpenEMR with this being a good use case.
Maybe so we can get in 502. Give me a day or two…
1 Like
I think that is very understandable. Thanks!
Some notes or corrections.
Clear sets payer_type to what is currently set in UI. Also payer type is broken which makes me wonder for how long( it is always set to primary or secondary)! Clear sets billed flag true and claim status to 2 (billed). Also clears the process_time, process_file and target.
Billing billed status is always set true and bill process and claim status is set to 2 along with process_time, process_file and batch target set to appropriate values whenever a batch is generated.
All you PHP experts, though I never use shortcut this way, did this break in recent PHP versions or is this not acceptable in any version?
$payer_type = $payer_type == 'T' ? 3 : $payer_type == 'S' ? 2 : 1;
Evals to 2 or 1 ie ignores first conditional ‘T’!
How much of an issue is it the wrong payer type was being set in claims? Did we fix issues down the billing line because of this and now by fixing is going to break something else?
Are alert billing folks simply resetting to correct payer type in EOB?
I haven’t seen many issues for billing from 501, are they there and not being reported?
Any other issues, besides feature requests, need to be addressed while i’m in billing manager?
@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! 
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
