Major billing issues with 5.0.2 - Please help

[Joel (Joel Erickson)]

Our billing problems with 5.0.2(1) have mainly been with the Edit Payments screen under Fees:Batch Payments:Search Payment. If we distribute all payments at one time after saving a New Payment everything seems to work OK. If we come back to Batch Payments and search for a payment, and if the oldest service date is in the top row (the list sorts on date of service) has a modifier with the cpt code, then the page crashes and you have to delete the entire payment and start again. If the oldest service date has no modifier, payments of newer service dates can still be distributed and all payments appear to be processed correctly.

This happens with patches 1, 2, and 3. We are running Openemr in Firefox (now 77.0.1) on Windows 10 currently using XAMPP 7.3.18 (PHP 7.3.18). We had initially installed 5.0.2(1) on XAMPP 7.4.4 and got all the errors. Seems to be no difference between 7.3.x and 7.4.x.

Concerning the wiki “What are the correct PHP settings”, we set all the php.ini settings according to an earlier version of wiki that suggested using “error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT”. I will add ~E_DEPRECIATED to that statement and test again.

Also, the last item in that recommended list of PHP settings “mysqli.allow_local_infile = On” is remmed out in PHP 7.3 and 7.4. I have not removed the semicolon to unrem it. I am going to try making that change as well. After seeing what DEPRECIATED does.

Thank you all for this thread!

[sjpadgett (Jerry P)]

I’m looking into this specific issue now and do see a couple potential problems but i’ve not been able to recreate the issue as you’re seeing it. Still, I preserver.

I’m testing now on PHP7.2 and PHP7.4 will for sure show problems w/o error log settings. Unsure about PHP7.3.

[nursejeff (Jeff Guillory)]

@Jerry P

Thanks for responding.

I found php.ini at /etc/php/7.3/apache2

So, I am using version 7.3.

There were multiple changes (8 of 12) that had to made in order to reach the recommend PHP settings.

I hope this helps.

Jeff

[nursejeff (Jeff Guillory)]

@Joel

There were two setting that were reemed out in my PHP7.3:
max_input_vars = 1000 - I had to unrem and change it to 3000 and
mysqli.allow_local_infile = On - I unremmed is also.

I had to add ~E_NOTICE to the error reporting line. ~E_STRICT and ~E_DEPRECATED were switched. I did not change that. I assume it doesn’t make a difference which order it came in.

Jeff

[sjpadgett (Jerry P)]

So did this help? Also for mature billing sites with a lot of volume max_input_vars = 3000 may not be enough.

[jjalb (John Jalbert)]

My apologies in advance - this is not meant to hijack the thread of the OP but to supplement and flesh out additional issues in this area as the opportunity presented itself.

@nursejeff and anyone else following this thread:

We’ve seen issues with the manual batch posting of $0 payments being seen in the system as a “payment” regardless if it was a non payment (ie; a wrongful denial or other situation where follow up is required) or an actual legitimate $0 payment thus kicking automatically to the patient balance. It’s made a mess of our aging reports as claims that should be showing on insurance aging appear on the patient list instead and to correct it’s necessary to manually review aging monthly and resetting the claim status (ie; -2,-1, 1, etc) where necessary.

Have you or anyone else come across this? It’s leaving insurance claims (secondaries to medicare in our case) unpaid and in a void and patient balances are wrong. Needless to say this isn’t helping timely billing of insurances or patients who anticipate another billing problem if it’s not caught in time.

This only appears to occur with the manual batches where we do not receive an electronic ERA to auto post. @juggernautsei and I have been trying to figure this one out for a while and would love to get a fix for it - using purely ERA files to avoid this simply isn’t realistic (as most of us in the US know dealing with payer sources) and this is the closest post to a problem in this area as I’ve seen yet.

This has been noted since 5.0.1 when we went live and are now on 5.0.2(1) on and 18.04 Linux on AWS.

[PeggyG (Peggy Guillory)]

Yes, we are seeing the same issue, @nursejeff is my other half. We have also identified an issue when posting patient payments affecting the patient balance adversely or not showing in the daily report at all. The are however listing on the bottom of the patients ledger page in what appears to be a new item showing all payments made by the patient. It however, is not attaching to the line item it is being posted to.

[nursejeff (Jeff Guillory)]

@sjpadgett to answer your question, No, changing the settings to PHP did not help.

She commented that it did not fix the old errors. She does not know if it will fix futures posting because she hasn’t gotten to that yet.

I have been using OpenEMR for about 10 years. My backup file is 10.2 GB’s. Should I increase my max_input_vars?

[sjpadgett (Jerry P)]

@nursejeff

Should I increase my max_input_vars?

I would to be safe. 3000 is the remmend but i’d bump another 1000. That can solve a posting problem in batch payments. However looks like workflow changed from 501 where:

Shouldn’t be in Edit Payments. Those buttons are for New Payments.
These are the button to be used for Edit Payments:

[jjalb (John Jalbert)]

Thank you @PeggyG, I appreciate the info and validation. I’ll assemble some data for this issue and make a seperate post in the upcoming weeks.

[sjpadgett (Jerry P)]

Hi @Joel @stephenwaite @juggernautsei @nursejeff @PeggyG @jjalb and anyone wishing to test this fix for us.

I have found numerous bugs in Batch Payments where many issues, seen and unseen, will occur. This is a major revision to Batch Payments.

Here are some details: for this: https://drive.google.com/file/d/14eo766CZNiNkUxYYHhBVhcrhNvgTrk9G/view?usp=sharing

• Remainder calculations inconsistent.
• Totals calculation errors.
• Save from edit/search problems.
• Workflow issues
• Hidden Global account confusing.(added a view global account balance for a given payment and can reapply amount back to payment in case of mistakes)
• Corrupt source code in edit payments
• Modal instead of Dialog for edit payments. (Replaced modal to near full screen dialog for first 4 links in search payments.
• Ability to recalculate edited payments in UI.
• Added some auto scrolls to scroll to near current working tables.
• This pre patch also includes some chart loading performance tuning I learned by profiling both 5.0.2 and upcoming v6.0.0 release. I’ve seen a performance increase of up to 50% faster chart loading.

The attached zip is a patch 4 pre release that includes all patches 1-3 plus what is the current master for patch 4. I added a tag to version to indicate the pre patch in about:

Before applying this patch please follow backup best practices for your site. I have tested this zip from a new 5.0.1(1) install so, should be good to go.

Important that you run sql_patch.php after following normal patching procedure.
Some screenshots:

And so forth. Good luck and I hope this will finally get Batch Payments useful so, let me know so we can get patch 4 out to everyone.
Let me know if trouble downloading from my drive as file is to large to host on forum.

[juggernautsei (Sherwin Gaddis)]

I just pulled the patch from your google drive with no problem. I will install it this evening and we will update you in a week. @jjalb will be the tester.

[sjpadgett (Jerry P)]

I have a strong feeling I may need to add some sort of clean up mechanism for past sins created by bugs.
Mainly if insurances are tracking correctly.

I will be tracking results and comments using this issue: Batch Payments Rework · Issue #3708 · openemr/openemr · GitHub

[nursejeff (Jeff Guillory)]

Can you please instruct me on how to take zip file and install it where it needs to be installed to try the upgrade?

[sjpadgett (Jerry P)]

Hi Jeff,
Download zip from above then install like a normal patch. This zip is just like a normal patch release and has everything from patch 1-3 plus most everything for upcoming patch 4 release once I get the new Dicom viewer done.

[jjalb (John Jalbert)]

I’m starting to test this out of our dev server. @sjpadgett what is the best format to forward any issues I encounter? Once I encounter a problem I generally create a screenshot walkthrough on the process that got me there for clarity of workflows.

[jjalb (John Jalbert)]

@sjpadgett @stephenwaite @juggernautsei @nursejeff @PeggyG @Joel

My apologies for taking so long on this - trying to navigate a economic pandemic in addition to the medical one has made this difficult to get to.
On the tail of my previous question I found the link to the github issue that was posted earlier - I missed it until today and see it was closed so I’ll post here.

I ran through this and can’t find any errors occurring that @PeggyG reflected - those do appear to be fixed and I’m not finding any similar issues but I am finding a different one that ties into my previous comment above. Good job to the devs on these fixes and upgrades along the way.

As I walked through this looking for any bugs I had hoped in particular the -2 -1 prv issue I mentioned before in the aging reports (collections) would have found it’s way to a fix - I know considerable effort was put forward fixing these billing issues as with other bugs.

My practice sees patients with Medicare as primary and usually some sort of secondary payer. The issue I found was in the case of denials where any sort of follow up is required and a zero ($0.00) payment is sent and entered into the system, that payment would not reflect accordingly as being denied in the billing system and even more importantly, what is being posted the system sees as a payment even if the follow up field has been updated then results in the patient being billed AND that insurance due claim for the secondary no longer appears on the insurance aging reports. The only work around we’ve had up to this point was to change the “0” in the payment section back to a “-1” and rerun the report. But to keep up with this a full manual review of the entire patient due balance report is necessary.
The reason I am raising this issue here instead of a post on it’s own accord is that the ability we had to go back into the claim and change the “null” field back to a -1 to compensate has changed in this patch and I am unable to fix these errors. As best I can tell I am unable to override the system to change a 0 to a -1 as I can with my production version absent of the patch which if others encounter this same issue, it could be a problem for many. I ran through this on a cloned server for testing the preliminary patch from our production server running 5.0.2(1) on Ubuntu 18.04.
Also some notations about the follow up reason appear as “Unknown Reason” on the EOB screen - so something there is disconnected there as well. @juggernautsei and myself have gone through this on occasion and the workarounds have sufficed but with that gone at this moment billing is about to get messy from the billing standpoint if this is released as you can imagine.

I know the majority of payments are uploaded into the system via the X12 protocols but the reality is with some secondaries we come across this isn’t possible so manual entry in this manner is necessary.

Graphics below should reflect the issues as a walk through.

[nursejeff (Jeff Guillory)]

I was able to install the trial patch without issue and gave it a couple of weeks for my billers to determine any changes good or bad. What I hear from them is that the problems persist. They tell me that they have to go through the entire payment history to find the true amounts owed or not. They say it is random among patients, sometimes it works, sometimes not.

I instructed my biller to explain on paper what is happening and I am posting it below:

Notes from my biller:

When posting patients payments for their copays or allowable for office visit, if patient has a lab draw or injection charge on the day of visit then the payment post to the lab or injection and then makes the patient account showing a credit balance.

On some not all secondary ins and on some primary payments when posting in batch payments to patients accounts the screen will go blank and the payment will not post. Then I have to go to patients Dashboard and post payment in fees and payment screen and then it shows as it was a patient payment not insurance payment.

And when you try to post payments in fee and posting screen then the payment will post but, post date as 00-00-0000 and then will not show up on daily balance sheet.

Hope this will help, thanks for all you do.

[sjpadgett (Jerry P)]

I just went through payments again and while say a 0.00 is not reflected on refresh, it is correctly recorded in database. I think problem here is the on the secondary denial(just a word) even if a balance is due, insurance is still advancing to tertiary.
Anyway, i’ll spend some time on this but guys please, don’t leave me hanging for weeks. I think everything is okay and move on. Especially if I have questions.

[sjpadgett (Jerry P)]

@jjalb

According to code this is the way it’s always been, Not saying it should be but, AR records correctly.

@jjalb

This is worrisome because it works until you say, delete a distribution and reenter. This indicates that the encounter flags last_level_billed and last_level_closed don’t reflect current AR status. i.e they’re not getting updated in certain payment work flows. Like if change the insurance level on an edit, code doesn’t update the encounter and that’s where the main insurance status comes from.

In the end I tried the workflow you showed and collections showed correct insurance level ie -1
I can’t readily see why you’re getting tertiary closed to cause you to advance to patient due. After posting the zero payment, insurance should be at -1 where that worked for me. Obviously this has been an ongoing issue for you and we need to figure out what’s different or what i’m missing.

Where are you doing the -1 reset you mentioned?

I’m thinking of some kind of review panel showing overall status allowing modifications if necessary.
I worry about past errors catching up after fixing with last patch.

I’m looking code over again to see what I can see. Any additional clues will help and sorry for rambling.