Shortfalls of Payment Entry Mode; Solutions Requested

John 4 years ago in Payments/ERA Modules updated by Valerie McNamara 4 years ago 2

Buckle up, this is a deep dive.

To understand the nature of the question, it is important to first understand that when my organization sends claims, each day usually has more than one service line for the same code, because clients attend more than one "group" in one day and the services are billed separately. So as a result, we have multiple service lines, for the same client, on the same day, with the same code.

When posting payments, my organization requires payments to be applied in proportion to the number of units to which that payment is being applied.

With this in mind, I am trying to find a way to prevent Procentive the following universal problems:

—Automatically adjusting off money that I want to leave as a balance

—Applying co-pays more than once on treatment days where we bill 2 separate "chunks" of time rather than all units on a single service line

—Improperly allocating funds respective to unit counts (This is my biggest issue with procentive overall. see below)

When, for example, the allowed amount (B6) is 50% of what was submitted, The claim is sent as 3 units and 1 unit of the same code, but the remit bundles these into one lump sum for 4 units. So, Procentive will:

-Put all the money on the line with 3 units

-Adjust the remaining balance

-Adjust 100% of the remaining 1 unit. 

In this scenario, I need to manually tab through every field in payment entry mode to ensure that 3/4 of what was paid goes on the line with 3 units, and 1/4 goes to the line with 1 unit. The only time Procentive gets this right is when B6=100% of submitted charges. Adjustments, specifically, are causing the imbalance. 

(Using the "allocate payment" dialog is not a viable solution, it only works when [B6=100%] OR [there is only 1 CAS code AND all claims paid are in a contiguous time span AND only one client account is being paid on the remit.])

I don't know if this is something that can be fixed on the user end (I have tried messing around with the "rules" for the payment entry mode, and while useful for other tasks, I could not solve any of these problems using them, or any other settings within procentive.) This is a major time drain when payment posting, especially when there are copay/coinsurance/deductible involved. To speed things up I usually just apply the copay to one line where possible, but the payment per unit rule is not something I can do differently. 

Am I overlooking something that I could be utilizing? Can systems engineers write new code to address this? Do we need to change our billing process entirely if we want to avoid this problem? I have been trying to find a solution to this for over a year and I am completely stumped.

System works fine! You will not be getting the full amount (100%). The adjustment is what is adjusted that Insurance will not pay. It is a loss. You bill what you bill and you get what you get. Welcome to the insurance world.

John! We understand your pain and have been trying to work with Procentive to come up with a good solution for quite some time as well.  Unfortunately we have not been able to come up with any good solutions....here is what I can help with or routes we have ventured down.

 Your Problem:Automatically adjusting off money that I want to leave as a balance

  • This is also a problem for us, we want to leave any unpaid balances as items to be worked in the future so we have to manually zero these out each time.  It takes a long time to post an era when you have to manually zero these out.
  • there was no solution offered by Procentive as their recommendation is to adjust these off and call it good, our organization works each one of these and would write off later if necessary (after review).
  • Also it would be nice if you could get these "ADJUSTMENTS" to color each time they show up so you can manually take a look at these but that is not an option either

Your Problem: Grouping of Entries:Improperly allocating funds respective to unit counts (This is my biggest issue with Procentive overall. see below)

  • This is also a problem for us.  We were told that it could possibly be fixed if we submitted and paid for an enhancement.  
  • For the time being our work around is to split each code out separately when we push out the billings (which takes a lot of time) Billing>+>Select Program> Select Code> Select Payer> send out, this is time intensive but was the only solution offered
  • We also had a hard time with these if we needed to go back and do billing adjustments (take-backs or adjustments) it was then taking back all and only paying back a portion.

We feel your pain, hope this helps.  We are willing to brainstorm with some of the other work around we have discovered. Unfortunately we have not had any luck with solutions either.