I am using Frame, but everyone else including my billers are using Tabs.
This is curious. My OpenEMR will not convert to Tabs.
My setting is Tabs but as you can see, I’m in Frames.
What is wrong with my system? Yes, I logged out and logged back in.
Jeff
click on the cog in the upper right to change your user setting which are probably overriding the globals
Ok, fixed the tabs issue, sorry, I got distracted.
Any other thoughts on our billing issue. Would my setting of Frames mess up the billing system?
Jeff
nice, no, are they using the above images to post or do they use batch payments?
We typically post insurance payments from Batch Payments. When we click on the "Show Primary complete it does gives us the outstanding 2ndary claim line however it also gives us every paid closed claim line also as in 2nd screen shot.
, when we input payment and click on post it goes to this next screen.
then if we "search payment to see if it is posted correctly it shows as unapplied.
at that time it also does not reflect payment in our daily balance.
there’s definitely a bug in batch payments
Stephen, this also randomly happens with posting a large medicare eob even if one claim does not have a modifier.
We are also having an issue of posting a copay or patient payment at the time of service. It will post on the ledger but not to the correct date of service and then does not reflect on the “financial report” to balalnce at the end of the day.
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.