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.
from @jjalb:
I thought myself through this a bit and have some additional thoughts and
possible solution.
It appears the system isn’t taking into account that a 0$ payment could be
either a valid payment (where the entire amount would go to a deductible) vs a
straight up denial with reason. The difference between these is
A- An actual payment would reflect a $0 payment with an adjustment for the
approved.
B- A denial would only reflect a $0 amount absent of any adjustments as it
hasn’t been processed and have a reason for the denial.
In the case where it would not (B), it was my impression that when the “rsnd”
box is ticked it then allows the follow up field to be populated to reflect the
denial reason and when this happened the system would not mark that payment as
being paid but re-queue it to being unpaid and due. In looking at the walk
through it becomes evident that the “rsnd” box is not the mechanism that
triggers a bypass and appears to do nothing more than allowing the Follow Up
field to be populated.
I don’t know how the back end of this is constructed to say what the intention
of the rsnd/followup section was meant to do, but linking these actions might
prove to be a solution for both Ins1 and Ins2 scenarios. All this to say is
absent of affecting other areas that might be connected to these functions in
the code (ie;what might break elsewhere from re-arranging this).
As an additional thought, it might be a good idea to create a button that
directly allows a manual resetting of which insurance is queued up for payment.
The current work around of going to posting of payments and manually changing it
is rather an obscure route.
Thoughts?
My observers @juggernautsei
I have spent the better part of a night looking through the code to see if I could follow the logic. I can to a point and then it grows cloudy.
Still looking for the trigger that sets the value of the bill_process.
It is not as straightforward or documented.
Aye.
hi @juggernautsei @jjalb , you could have a valid payment of $0 with no adjustment if the charge isn’t over the allowable. A denial vs a denied claim: could be needing more attention to the first insurance and you might not want to post the $0 payment.
Find it much easier to process and post using the invoice page. The manual marking of due insurance is also provided there.
Are you spending a lot of time posting insurance payments? You should be able to get an 835 for electronic posting.
I might have found a little more on why the claims are re-appearing in the billing manager - which might tie into the fix we are looking at for denials re-queueing here as well as the function of that follow up box.
The attached claim ended back up in the billing manager from some event occurring on 1/31 - I looked closer and found the follow up box had been checked to add a note of the codes from Medicare that noted this was to go the patient’s deductible. We dont need it to requeue to the primary since the primary paid but only a note was added. It’s almost like in this case it did re-queue to the primary for another claim to be processed - which isnt needed here.
So the check box needs to not mark the claim as re-qeued for purpose of the billing manager, but it does need to not mark the claim as done with primary so it will appear correctly in the aging reports.
Your thoughts please.
I think this conditional formatting should prevent any zero dollar posting from being marked as an insurance having been paid.
A single condition should get it but I put in a redundant 2nd condition just to cover the bases of what would normally be posted for a valid payment that should allow it to pass.
Parameter Notes to clarify what I’m thinking here:
i. A valid payment will have both an adjustment and an allowed amount along with the payment. Checkbox = unchecked.
ii. A payment of Zero dollars is a valid payment IF an allowed and adjustment amounts are included. Checkbox = unchecked.
ii. A denial will have neither allowed or adjusted but only a payment of Zero dollars. Checkbox = checked + follow up reason.
Last level billed should not change under these conditions.
hi @juggernautsei, sounds pretty good, it’s nice to fix up the manual posting but pretty much everyone these days posts medicare electronically and it works pretty well in OpenEMR.
https://www.palmettogba.com/internet/elearn2.nsf/jj_edi_enroll/story.html
@stephenwaite
Thanks for the feedback.
Could you share with me what triggers the last level billed change?