CLEAN CLAIMS QUICK HINTS

1. REVIEW CLEAN CLAIMS RATE (CCR) REGULARLY
Track your CCR daily.
Make it part of standard staff communication – the good as well as the bad!
Other metrics to track include: daily errors; daily claim submission; what is returned from the clearing house; rejected claims (ones that never cleared the editor); and Medicare T-status claims and payer rejection reports.
Share successes with you team, but also address issues as they arise and create an actionable plan. This will prevent errors from building up, and keep everyone on the same page.
2. REVIEW BRIDGE ROUTINES
Perform a comprehensive review of all bridge routines.
Understand the problem that each bridge is intended to fix.
Assess whether the bridge is ACTUALLY fixing it!
Bridge routines require periodic review to ensure that they are not unintentionally making problems worse.
3. ENGAGE STAFF IN THE CCR DISCUSSION
Establish brief daily meetings of less than 15 minutes (we call them Huddles) with your billers regarding outcomes, what they are observing on claims, and the opportunities for automation.
This is a crucial step early in the process; though it will remain valuable, you may be able to scale back to every other day once the lines of communication have been established.
Going from “meetings” to “discussions” will change the feel of the conversation, making staff feel that there is less risk to being communicative, leading to improvement in outcomes.
4. SYSTEMIZE SOLUTIONS
Where you find a pattern of common edit, look for ways to eliminate manual intervention.
Does a bridge routine need to be created?
Does a change need to occur in the host system or an upstream process?
If manual intervention is required, ensure all of your billers are resolving the edit in a standard manner.
When systemizing solutions to CCR, remember that you may also need to pursue changes outside of PFS or Revenue Cycle.
5. DOCUMENT EVERY CHANGE
Create a change control log of what is being fixed; who is requesting the change; what benefits are expected; and the date the change is implemented.
OA log can avoid confusion later, and help track how the system is being used.
This insight can be invaluable when requirements are altered, or when trying to address similar problems.