A/R report Ins Co vs Patient

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 :slight_smile:
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.

I’m only one guy though!

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;

Are you looking at claim and/or billing table for billing process?

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

ok, yeah, that’s a bug that we’ve seen before, we usually set the statement count to zero on the invoice page.

Can you walk me though that: “set the statement count to zero on the invoice page”.

I’m not sure how to do this without going into the database itself.

from past encounters billing view, click on CPT and then you’ll see the statement count (statements sent) entry box

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.

1 Like

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.

I found the status codes.

hi @juggernautsei, are you talking about posting from an 835 or manually posting?

the claims status report is run from the collections report with Due Ins set

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