How to Get the Most Out of Your Relationship with Your Revenue Cycle Management Partner
By Mark Droste
Revenue Cycle Consultant
In a crowded industry marketing messages about software capabilities are constantly served up to people looking for solutions to transform their revenue cycle, making it easier to manage for providers such as Urgent Cares, Imaging Centers, Laboratories, Ambulance Services, Hospitals and many more. There is a cautionary tale to tell when the organization skips performing a side-by-side exploratory review of current and proposed software solutions and how it may impact the future workflow state.
Every Revenue Cycle Management (RCM) department, group, and company have a workflow that exists due to a combination of software capabilities, staffing levels, skillset, and environment. Success and failure often subtly lie in the details.
The common sales pitch, “we can handle insurance eligibility checking with the claim scrubber you already have”, on the surface seems to make sense until the workflow impact is fully understood. What you gain vs. what you could lose are tradeoffs that should be investigated before the cutover, otherwise the impact could be a complete surprise which turns into a deep dive review of the revenue cycle triggering buyer’s remorse when the data points to an unexpected outcome.
To shed some light, a story shared by a valued customer of tevixMD unfolds after new people joining the management team decided to go with a proposed cutover to the claim scrubber without fully understanding the impact to workflow.
A few months into the cutover, 35% of their Accounts Receivable (AR) was stuck in a “failed eligibility” status in the claim scrubber. This triggered a postmortem review of the bottleneck scenario impacting over 170,000 claims stuck in a holding pattern. The review provided the reasons and insights that turned into lessons learned, and a reason to go back to a better way of capturing insurance eligibility information offered by the original insurance validation vendor with a proven track record.
Majority of errors were related to incorrect patient demographics such as first name, last name, date of birth, and social security number.
The new vendor did not run a demographic check prior to the eligibility request. A scrub of patient demographics prior to the eligibility check significantly increases the accuracy of the request due to the way data is presented and updated. Example, first name Bob is really Robert, or Debbie is really Deborah, and the last name Schafer can be spelled three different ways or have a hyphen with a maiden name. Demographic scrubbing greatly increases the success rate however is not offered as a standard offering by many vendors before the insurance validation request.
Eligibility requests/responses are flagged as either “passed” or “failed”, accounts missing required information often is listed in the “failed” category. The problem is if the request is missing required information prior to submission the vendor should let you know it is in a state of “incomplete” not “failed”. Knowing what data element is required but missing before a request is made helps to assign resources dedicated to obtaining the required information needed to make a valid request. The new vendor did not make this distinction which added to the backlog. Another challenge is if the insurance company is offline for maintenance or simply network issues how is the request tracked?
The importance of different status, not just pass or fail statuses.
The original vendor has four statuses: “Passed” insurance is valid, “Incomplete” missing the necessary information per payer requirements to initiate check, “Need Review” = the payer system is down and the request needs to be submitted again, and Red status = “Failed”
The claim scrubber vendor only had “Passed” and “Failed” status. If the information submitted to the payer was incomplete the claim showed up as a failed which would drive costs up for the false status because the person working the claim would start looking for new insurance instead of correcting the missing information.
A claims scrubber by default is a back-end tool not designed to be used as a front-end tool for registration. In this scenario, using the claims scrubber; required a full registration, LIS order generated, information sent to the AR system, and claim file sent to claim scrubber for the checking to work. Providers need eligibility checking software in the front-end. Waiting several days until the claim is sent to the claim scrubber before actions are taken is an unnecessary waste of valuable time to determine if the patient has valid insurance. Most organizations have a bill hold that is a few days long, that block of time should be utilized to perform insurance eligibility checking and work identified exceptions. Working the claim day one vs. waiting for the bill hold to expire to be sent to the claim scrubber is optimal use of time and resources. When the client switched to the claim scrubber this block of extra time was no longer available. Compounding this further the work fell on different groups, originally office support staff worked the failed insurance eligibility checks during the bill hold period, after the cut over to the claim scrubber the workload shifted and become intertwined with other billing issues requiring the coding, billing, and follow-up teams to chase down the information in addition to the complex time-consuming work they were already performing prior to the cutover.
Identifying valid insurance at time of registration by default updates all downstream systems, LIS, AR system, Claim Scrubber. This approach sidesteps having to update/sync multiple systems by hand.
Switching to the claim scrubber for the updates requires staff to update the AR (Accounts Receivable) and billing system now considered upstream systems manually, adding unnecessary steps to keep all systems synchronized which in the end adds more busy work translating into higher labor costs.
When and where the insurance checking takes place can be a labor savings, moving this process to the claim scrubber that operates in the back-end of the revenue cycle is simply put, a step backwards in efficiency and use of resources. Identifying the insurance at the front of the Revenue Cycle Management process sends the correct information to the downstream systems by default resulting in a significant time savings.
Insurance validation, checking the record on file vs. insurance discovery, checking multiple possible insurance not on file are two different approaches to obtaining the patient’s insurance.
Prior to the cutover to the claim scrubber the original vendor performed insurance validation for the insurance record on file and switched to insurance discovery if the one on file was incorrect. The claim scrubber only checked what was on file.
An organization should have a dedicated single-source-of-truth for insurance eligibility checking. Maintaining a dedicated database helps front-end and back-end teams manage the workload, share the results, provide an audit trail of the efforts, and monitor productivity efficiency.
The original vendor encouraged all teams to use the insurance eligibility checking application this opened communications and shared the results for all involved. The queue-based approach balanced out workload and provided a way to track productivity and results. When the organization moved to the claim scrubber vendor this cut everyone in the front-end, consisting of registration and patient service centers from using it as the workflow and access was structured for the back-end billing office.
Once information is captured there is a better way to enter it into your billing system than typing it in. Either have the software embedded in your billing system or have a way to move updates from the eligibility checking system to the billing system without typing to minimize data entry challenges.
Original vendor had two ways of updating the information from the payor to the AR (Accounts Receivable).
Transfer Agent – this feature’s value becomes apparent when upon successful insurance validation is completed the user opens the account in the AR or LIS system and with one click of a mouse the system is updated with the validated insurance information. The success of this feature is based on proper one time mapping the fields in the AR or LIS, this cuts out having to type which minimizes human error.
Insurance verification and discovery embedded in AR or LIS – once setup the user is working inside their AR or LIS system no need to type or transfer the updated information, this also minimizes human error.
When the client switched to the claim scrubber the two types of functionalities mentioned above was lost - typing by hand and human errors came back to haunt the client.
Patient pay is becoming more prevalent in Revenue Cycle Management. Looking up of test prices, checking remaining deductible or copay, taking payments, and managing payment plans is becoming a must have feature in the front-end. Having this embedded in eligibility checking software is a huge bonus.
Simply put this is not a core focus for a claim scrubber which is intended to be used in the back-end by the billing team.
The importance of having the correct tools at registration.
Recommended approach, insurance eligibility checking occurring in the front-end at registration or before charge generation accelerates the identification of valid insurance days before a bill hold expires and the claim is released to the claim scrubber. If the registration occurs at the patient service center (PSC) or remote draw site this workload falls on those individuals to obtain the valid information. If the validation or discovery of insurance is not completed at this stage, then by default will move to the end of day batch checking which includes demographic checks, with the results dropped into queues that the billing department can work during the bill hold period.
The ability to produce reports that will give organizations the static first pass attempt with breakdown by error reason.
The original vendor had dynamic view showing what was left to process and a static view of the first attempt with reason breakdown imagine blending this data with the ordering location to look for high volume offenders.
Migration to the claim scrubber vendor provided a dynamic snapshot the day the report was run of the remaining claims which is good for operations however the snapshot did not have the option of static views, as when claims are cleared they will fall off the report.
Insurance validation that occurs in real-time on demand and in bulk submission you see the results immediately.
Using the claim scrubber moved the workflow away from on demand at point of registration to a scheduled job to submit the file to payers. This submission approach was not in real-time.
Insurance validation should have the ability to update an incorrect policy number with a valid one when submitted in a bulk request.
Original vendor would update the request with an updated policy number when an incorrect policy is submitted in the request. This feature was lost when the client switched to the claim scrubber.
Know average industry statistics for returning correct insurance information.
The original vendor has a proven 95-99% accuracy rate, when the client switched to claim scrubber vendor the accuracy rate was 60-65%.
The lesson, know you success rate and compare your established baseline to the new vendor if you switch. This spoke volumes about the effectiveness of switching from a dedicated insurance validation and discovery to a claim scrubber. This was the tripping scale to cause the client to rethink their claim scrubber approach and switch back to the original vendor.
Insurance discovery is becoming more in demand as an expected feature
Original vendor performed insurance discovery hitting the payer direct in real-time. The claim scrubber vendor hit a static database instead of a real-time connection to the payer.
Eligibility validation vendors should have permutations for what is required to submit a successful request
This feature visually displays all the different combinations of information required based on the individual payer’s requirement to submit a successful request.
The original vendor had patented permutations outlining what data elements required to submit a valid request to a payer. If the required data elements are not present the request would be deemed as status of “incomplete”. The permutations provides bullet list of what is required by the payer and can be a great learning tool for staff to follow.
Putting it in prospective using dedicated insurance eligibility and discovery software vs. claim scrubber
Listing out a side-by-side comparison is an important step in the right direction. Using a tool specifically designed for insurance verification and insurance discovery has many advantages. Looking at a claim scrubber to perform this service has trade off’s that should become apparent when looking over the side-by-side comparison. If your current vendor or Revenue Cycle Management partner does not have some of these feature sets then use this as a guide for shopping for insurance validation vendors who are solely dedicated to this process. In the end know your baseline so you can monitor the effectiveness of your new vendor. Losing key functionality will inevitability impact your labor costs and may impact your performance and efficiency.