A/R report Ins Co vs Patient

Day-to-Day Users
#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.

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

#44

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

#45

Screenshot%20from%202020-01-31%2016-35-40
Screenshot%20from%202020-01-31%2016-35-401263×776 66.8 KB

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

image
image1846×841 275 KB

#47

image
image1272×414 161 KB

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.

#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

#49

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

#50

hi @juggernautsei, in the 835 posting or manual?

#51

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

#52

hi @juggernautsei, here it is

1 Like
#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.

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

#55

hi @sjpadgett, finally dawned on me :sunny: it’s to set the claim to insurance pending. Say you had sent a patient statement to someone but you had to rebill insurance. If you didn’t reset bill process then they would get a bill on the next statement run when it should be pending ins…

#56

looking to run the following script to move those that show as pt due to pending ins

started issue


<?php

require_once("../globals.php");
require_once("$srcdir/patient.inc");


// grab those encounters that were affected on 3-7-20
$q = "SELECT * FROM `form_encounter` WHERE last_level_billed = last_level_closed and last_stmt_date = '2020-03-07'
      ORDER BY `date` DESC";

$r = sqlStatement($q);

// build a list of those that need fixing
$cntr = 0;
while ($f = sqlFetchArray($r)) {
    // get the important fields from the form_encounter table
    $eid = $f['id'];
    $pid = $f['pid'];
    $enc = $f['encounter'];
    $dos = $f['date'];
    $lb = $f['last_level_billed'];
    $lc = $f['last_level_closed'];

    // get the patient balance for the encounter
    $pt_bal = get_patient_balance($pid, false, $enc);

    // get the number of insurances
    $insarr = getEffectiveInsurances($pid, $dos);
    $inscount = count($insarr);
    
    // we need the statement count since if it's non-zero openemr think's it's pt due 
    // this should probably be decoupled down the road
    $stmt_count = $f['stmt_count'];

    // we only care about non-zero balances and those that have less levels closed than insurances
    if (($pt_bal != '0.00' || $pt_bal != '-0.00') && ($lc < $inscount)) {
        echo "pid $pid has encounter no $enc id $eid dos $dos and balance is $pt_bal last level billed is
        $lb and last level closed is $lc and inscount is $inscount cntr is $cntr stmt count is $stmt_count";
        echo "</br>";
        $cntr++;

        // going to run this sql statement after sanity checking
        echo "UPDATE form_encounter SET stmt_count = 0 where id = $eid </br>";
    }
}
#57

Button needs renaming! The logic is same as always unless I made a booboo when I created the new popup. My gut tells me that the clear button doesn’t need to be enabled at all times. Need to add a claim status in manager to give a clear indication of current claim status to biller with options to reset various claim options.
If you folks will give me a little guidance to what you think these option should be or how you’d like to see this issue addressed, i’ll spend some time implementing.

Meantime, i’m going to walk back through the Clear logic to see if i’ve created a bug or if more clarification of action is needed. Most certainly need to handle stm count better.

1 Like