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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
According to code this is the way itâs always been, Not saying it should be but, AR records correctly.
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.
