A/R report Ins Co vs Patient


(Sherwin Gaddis) #42

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.


(Stephen Waite) #43

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.


(Sherwin Gaddis) #44

@stephenwaite Could you post of screenshot of the invoice page? Thanks


(Stephen Waite) #45


(Sherwin Gaddis) #46

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.


(Sherwin Gaddis) #47

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.


(Stephen Waite) #48

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


(Sherwin Gaddis) #49

@stephenwaite
Thanks for the feedback.
Could you share with me what triggers the last level billed change?


(Stephen Waite) #50

hi @juggernautsei, in the 835 posting or manual?


(Sherwin Gaddis) #51

In the 835 posting, is what I am looking for.


(Stephen Waite) #52

hi @juggernautsei, here it is


(Sherwin Gaddis) #53

We are not trying to fix the manual posting. We are trying to fix the miss marking of the batch payments. When using the batch payments, the system drops the responsibility without regard to the proper conditions for that change. Any record entered into the system will drop the responsibility from INS1 to INS2 and this should not be. We have outlined above the proper conditions for when the responsibility should change. That is what I am working on now.


(Stephen Waite) #54

hi @juggernautsei, sounds good, thank you. However batch payments is a manual process. The EOB posting using an 835 is considered electronic.

Not trying to nitpick just want to help optimize the workflow.