Okay, i’ll have to think about that for a minute. In that case, a denial claim status of 7 gets set so if the status gets reset in manager then the only notice biller has is in claim history.
Everybody run out and give their billers a raise
Maybe what we need is a claims re-submit button that will only turn on based on claim status…
but that doesn’t fix this issue. I’m unclear. Did this work in v501 and not v502?
it’s working on prod v501 for my client just not for @PeggyG and @rmagauran and when Ray upgraded it still wasn’t working leading him to think there’s a database change made by a biller
We need a claim status report in manager. Nothing involved. Perhaps a popup that shows exactly what the billing tables statuses are for selected claim, in plain english. Also would list claim history with that claims status for the version that created the history item.
Looking at four PID flagged by my billers that are coming up as “Patient Due” instead of the “Insurance Due”:
they all have secondary insurances
the billing process has flagged them as last_billed = 1, ie. primary insurance is done
they should seen by sl_eob_search.php as needing secondary billing
I find they have all had statements sent out to patients, which for some reason the system flags them as “Patient Due” not "Insurance Due”. While I go deeper into this bug, I did notice that I can change the “number of statements” sent out (to = ‘-1’), and these once again appear as Insurance Due.
UPDATE form_encounter SET stmt_count = ‘-1’ WHERE form_encounter.id = XXX;
I would also note that when you are looking at the Past Encounters and Documents page, click “To Billing view”. This page uses the function ‘ar_responsible_party’ from library/invoice_summary.inc.php
Here, if the secondary needs billing, it is font-color red, even if it shows up as Patient Due in the Posting area.
It seems that the Posting page uses the form_encounter::stmt_count value to decide if insurance is done? I cannot find out in the code where this is happening though… If I change this value to -1, then the encounter goes back into “Insurance Due”.
This does show up but how do you save this? If you try to only change the Statements Sent = 0, a JS pop-up says there is nothing to change, and no ajax query is sent either. Is there another way to change this from the GUI?
thought @sjpadgett put a global in the billing category for zero $ postings in 5.0.2 but not seeing it right away
work around is to Disable Auto Adjustment Calculations in EOB Posting in billing globals and then choose adm adjust as a dropdown reason and choose save and exit, it won’t save a new entry but will record the new statement count
I think I just added the disable auto adjust. The stm count work flow comes up a lot. Tell me what you guys need done and i’ll add to my backport for fax feature.
Make a list and i’ll fix any other while in this code.
Someone in the forums is now experiencing this same problem. I could not do as Stephen suggested - it would not save with no new monetary data, just an adjustment code. So I went into DB and did this:
UPDATE form_encounter set stmt_count =0 WHERE stmt_count = 2 ORDER BY id DESC
We will see on Monday if that worked for posting - billers have been unable to update EOBs received for 2 months! When I go into Patients dashboard, now they show insurance due amount correctly.
hi @rmagauran, you’re probably aware that you might be setting an account pending insurance that was receiving personal due bills after insurance had been posted
The consensus in my office is that the “Statement” flag was incorrectly set to “2” before an insurance remit was done. Problem is this may happen to encounters set to=3 or other. So I instructed the billers to do as you stated above: when posting reset the statements to “0”. I was unable to save a posting using the technique you showed above - set statement count to “0” and add a phony adj reason. It doesn’t work without actual payment data, at least not here…
At least we have a path forward. This is only slightly less annoying than the “authentication Error” from CSRF problems which I am being inundated with from everyone.
looks like there is a bug with the display after you disable auto adjust and then save a posting with the adm adjust because it does actually save even though it looks like it doesn’t take
@jjalb
“I am finding that same bug when an insurance denial comes in it dings the collections aging reports incorrectly from a -2 to a -1 etc when it’s entered as such”. He posted this information a week ago.
Has anyone built a claim status report? @stephenwaite
Where can I find a list of what the status numbers mean? I think I can build a report over the weekend.
@stephenwaite
We are doing a conference call now to see what was going. I added the new code to the system this morning and they are seeing good results now.
When there is an insurance denial and that is processed with a 0.00 entry. The system changes the bill_process column from -2 to -1. There should be a check to see if the amount is zero. If it is, the bill_process should stay -2. It should only change if there is an amount greater than zero entered.