Major billing issues with 5.0.2 - Please help

[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.

[sjpadgett (Jerry P)]

@nursejeff

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

I’ve done hundreds of these and have never seen this happen. What browser and versions are you using?

The other stuff I don’t understand. Are you also using front payments and/or EOB posting after batch payments to fix batch payments or what is your workflow?
I need more to go on please.

[sjpadgett (Jerry P)]

@jjalb This is following your workflow so you see it can work. I’m using only batch payments. What is different is what we need to figure out.
The amounts 0.00 not showing is written that way by original author because query specifically excludes 0 payments and setting to empty for some reason. I’m hesitant to change. In reality, all the 0 payment is doing is advancing insurance to next level and making a note why. Again the AR entry reflects the amounts correctly.

I don’t know what to fix!

[jjalb (John Jalbert)]

Thanks for peeking back under the hood on this.

@sjpadgett

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.

There are two ways to access this EOB Invoice screen -
Reports>Collections; Enter search criteria and select the invoice in question. (Method used in my example)
and alternatively a differenct direcxt to what appears to be the same screen:
Fees>Posting Payments search by patient name/etc and pull up the EOB Invoice.

Ref this in graphic 06 - I am currently resetting the reflected “0” to a -1 in the statements sent field or whatever is needed. Of note and IIRC, there have been a few instances where the primary payer denied repeatedly and each time the denial was posted in the way the status ticked down from -2 to -1 and finally to a zero. I haven’t caught this happening since we now only accept traditional medicare and never have issues with their claims but I’m mentioning it as an extension of this issue we find with the secondary denials.

I presumed just on logical flow that marking the tick box as follow up on posting would do something to the effect of preventing the advance of a claim forward to the next insurance level since an actual claim payment was zero “and” tick box was not “null” and there was a narrative in the follow up reason.

@sjpadgett

I’m thinking of some kind of review panel showing overall status allowing modifications if necessary.

The EOB Invoice panel that already exists could be probably used to add this - all of the pertinent payment data on the claim already exists.

@sjpadgett

This is following your workflow so you see it can work. I’m using only batch payments. What is different is what we need to figure out.
The amounts 0.00 not showing is written that way by original author because query specifically excludes 0 payments and setting to empty for some reason. I’m hesitant to change. In reality, all the 0 payment is doing is advancing insurance to next level and making a note why. Again the AR entry reflects the amounts correctly.

I don’t know what to fix!

I agree and we dont need to “fix” one thing and break a dozen others - we’ll keep hammering on this and narrowing it down - I’m glad to test.

In your example below - the payment from Orange Colors Inc - did you enter that as a $0 payment or leave it blank? And, does this patient have a tertiary ins? I see one primary payment dropping the -3 to a -2 (correct), and then a non entry/denial dropping to a -1 (dropping to the tertiary here). This would be the same scenario I walked though except with the addition of the tertiary - it would drop to the patient balance instead.

To eliminate any differences in server environments - if you have a test server I can log into and walk through this it might be helpful to take out as many variables as possible. If it’s something my system is doing differently/incorrectly we might be able to pick it out vs changing code and give you a chance to review the code as it applies.

[sjpadgett (Jerry P)]

@jjalb

In your example below - the payment from Orange Colors Inc - did you enter that as a $0 payment or leave it blank? And, does this patient have a tertiary ins?

Yes and yes. You have to enter a payment value of some value or it will error and not allow allocate.
Second, I did have a tertiary insurance so that is the difference between us. So using patient with only primary/secondary then ins advances to patient due.

However, this is what it’s supposed to do! The only problem I see here is user shouldn’t need to select insurance company where only the insurance company for the patient’s insurance level should be allowed. In my test, I could use any insurance company. Imo, that shouldn’t be allowed.

So help me get the jest here: You want to record that the secondary denied the claim but keep insurance level at the denied insurance level(Ins2) so you can submit a HCFA 1500(or such), true?
I would think the place to do that would be a billing note rather than recording a 0 payment.
i.e

@jjalb

I presumed just on logical flow that marking the tick box as follow up on posting would do something to the effect of preventing the advance of a claim forward to the next insurance level since an actual claim payment was zero “and” tick box was not “null” and there was a narrative in the follow up reason.

@jjalb

I am currently resetting the reflected “0” to a -1 in the statements sent field

Resetting statement count should not effect last level closed. But on this, like so much other in billing, I’m unsure.

Simply said, this to me appears to be working as designed however, I don’t do billing so I can’t be sure.
Maybe @stephenwaite or @juggernautsei have an opinion.

And thanks for getting back to me. I slept in today…

[jjalb (John Jalbert)]

@sjpadgett

However, this is what it’s supposed to do! The only problem I see here is user shouldn’t need to select insurance company where only the insurance company for the patient’s insurance level should be allowed. In my test, I could use any insurance company. Imo, that shouldn’t be allowed.

So help me get the jest here: You want to record that the secondary denied the claim but keep insurance level at the denied insurance level(Ins2) so you can submit a HCFA 1500(or such), true?
I would think the place to do that would be a billing note rather than recording a 0 payment.

This is correct in the scenario I posted. A denial can be for a bounty of other issues - insurance companies in NA are a persnickety bunch regardless of the rules even up to delays in payments to meet measures internally… When a $0 payment is received sometimes it is included in a batch of other payments from the same secondary that weren’t at $0 so it is unavoidable. This is the accounting portion of the system and I’d be interested to hear how others deal with posting and keeping track of non payments absent of them becoming lost. Aside from writing off lost revenue or passing the due balance onto the patient, there has to be some sort of mechanism in place to prevent this.

@sjpadgett

Resetting statement count should not effect last level closed. But on this, like so much other in billing, I’m unsure.

Oddly it appears to - I don’t know how these triggers are set up being a non developer but I came across this trying to find a workaround.

@sjpadgett

And thanks for getting back to me. I slept in today…

Np! I saw your last post was a late one - I hoped it was due to a time change and not actually 3 in the monrin…
I am sorry this took so long to get back on - I needed some available time and bandwidth to try and break what you had fixed and look for other issues. I saw your closing post on githib on this (I think it was only open for a day lol) and was surprised folks dont give feedback on these issues - it’s really an investment and in the best interest of everyone to strengthen the platform.