Shortfalls of Payment Entry Mode; Solutions Requested
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.
Сервис поддержки клиентов работает на платформе UserEcho
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
Your Problem: Grouping of Entries:Improperly allocating funds respective to unit counts (This is my biggest issue with Procentive overall. see below)
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.