ok, will play around with batch posting, never use it personally because am always trying to get 835s, like with medicare, should be posting electronically whenever possible for ease of use
like if you use office ally for electronic claim submission you could sign up for ERA from them
There was a company that used to post on the OpenEmr community forum, that developed their own billing software modules for OpenEMR. The last I remember they were promoting this module along with off site servers for use. That was a couple of years ago.
Can anyone point me in their direction?
Messed up billing messes up an entire practice. Can someone, who is using OpenEMR 5.0.2 report to me, that they are having no problems with the billing since upgrading. Am I the only one?
One option is for me to downgrade back to 5.0.1(7). The billing did not have these current bugs.
Jeff Guillory
Lumberton, TX
hi @nursejeff, we’re working on the batch payments and will have something upcoming and definitely in time for patch 4
@PeggyG, do you use ERA for any posting? like posted above it’s pretty easy to get an 835 for your most common payments, what clearinghouse do you use?
Is anyone or everyone running PHP7.4 after upgrade?
@StephenWaite , We have not used ERA in the past, my head biller has always had problems in the past with ERA posting(not open emr). Looks like we need to give it a try anyway. Old habits die hard. I am using @nursejeff login due to being at home and not having my password. Peggy G
First thing that needs to be cleared up for any issues in v5.0.2 is error logging. v5.0.2 was a transitional release to support PHP 7+. There can still be recorded errors that will effect workflow such as deprecated warnings that are sometimes hard to spot.
We recommend(I insist) the following:
https://www.open-emr.org/wiki/index.php/FAQ#What_are_the_correct_PHP_settings_.28can_be_found_in_the_php.ini_file.29.3F
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!
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.
@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
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
So did this help? Also for mature billing sites with a lot of volume max_input_vars = 3000 may not be enough.
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.
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.
@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?
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:
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.
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
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:
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.
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.
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
Can you please instruct me on how to take zip file and install it where it needs to be installed to try the upgrade?
