Revenue cycle management is one of the few areas where providers can both increase revenue and significantly reduce costs with relatively simple, low tech solutions.
However, revenue cycle has historically been hindered by staff shortages which, coupled with high turnover, underinvestment in technology and a dearth of qualified leadership, has led to chronic underperformance. This has forced many providers to outsource and oftentimes offshore significant components of their revenue generating processes. The recent advent of robotics process automation (RPA) provides an additional performance enhancement option. The purpose of this paper is to explore how organizations can combine RPA with business process outsourcing (BPO) and offshoring to achieve significant performance improvements.
Do you have to choose between RPA and BPO?
BPO is, at its core, a labor substitution strategy. Labor intensive processes are moved to locations where labor is cheaper and/or more efficient. BPO companies are generally much better than their clients at standardizing and simplifying complex processes and at recruiting and training large numbers of employees. In addition, these firms tend to thrive at process management and rely on tight production tracking and incentives to yield sizable productivity increases, when compared to the legacy client’s processes.
RPA is, in its most basic form, programming code that performs tasks typically executed by an end-user. Software, commonly known as a “bot”, is used to capture and interpret information from IT applications to enable transaction processing, data manipulation and communication across systems. The programming is designed to replicate end-user activity, such as performing a series of clicks, creating a reconciliation report, entering data into a website or workflow tool, or taking a specific action based on an existing data point. The range of capabilities, and the minimal IT requirements, makes RPA an attractive and cost effective option for many health care providers.
RPA is best suited to execute rules-based transactions and move data between systems or between external websites and/or systems. By itself, the technology does not provide voice capabilities, is not capable of learning, and cannot easily “interact” with people. It can, however, execute rules and tasks with singular precision, non-stop, 24/7. RPA offers a quantum leap in cost over BPO and offshoring. For example, if 15 to 20 FTEs were replaced by bots, the RPA cost (licenses, equipment and annual support) could be approximately 25% of the in-house staffed project costs. This is approximately half the cost of an offshore BPO. In addition, RPA in some respects, can provide high repeatability and execution quality and does not suffer from turnover and the necessary cost of sourcing, recruiting and training replacement staff, which can result in an additional 3% to 5% overall cost increase.
The difference in cost and capabilities between bots and humans, and between in-house and outsourced staff, presents an opportunity to structure projects that create attractive roles for in-house management and staff while at the same time reap the performance and cost benefits of combining RPA with BPO. Keeping in mind that bots are best for routine, repetitive, non-voice tasks and that humans thrive in complex environments, a simple framework to structure a revenue cycle project could be as follows:
• Potential RPA processes:
o Access insurance websites for eligibility verification and benefits determination
o Find authorization and/or referral (internal system and/or payer website) and ensure it covers the required procedures
o Perform simple billing edits identified by the claim scrubber
o Bill a secondary insurance (if not already automated on the scrubber)
o Rebill a claim
o Move an account to next responsible party (if not already automated)
o Verify account status on website and prompt the next action based on status
o Write-off an account balance
o Prompt simple credit balance refunds
o Generate a medical records request
o Retrieve and email a medical record
o Post cash
• Potential in-house or BPO processes
o Patient call for procedure schedule/reschedule
o Payer agent call to obtain eligibility, benefits, new authorization or new referral
o Payer agent call to discuss account status and appeal denials/underpayments
o Account research and analysis (e.g.: denials and payment variances)
o Root cause analysis
o Patient call to discuss account status and self-pay responsibility
In this context, we are using in-house or BPO as a single category to indicate that most activities performed by the in-house team could be performed by an outsourced team with adequate training. This approach ignores some state and government agencies that require that their accounts be accessed only from the US. In the case of offshore BPO, the in-house/BPO category should be broken down into US and offshore activities based on state and government agency requirements. Note that after transactions are identified and allocated to bots, what remains are either transactions that require patient or payer interactions or ones that need higher level thinking.
BPO vs RPA Business Cases
To illustrate the impact of BPO and RPA staffing models, we constructed a hypothetical cost comparison between four strategic options: 1) an all in-house staffing operation, 2) an in-house plus offshore BPO staffing operation, 3) an in-house plus RPA staffing operation, and 4) an in-house plus BPO plus RPA staffing operation.
A key component in any cost comparison for RPA projects is the speed of the bot over traditional human labor. While some RPA vendors tout bot speeds of up to 15 times human speed, our experience for revenue cycle projects is that external website and systems refresh rates, as well as limitations in hours of operation for internal and external systems, result in bot speeds closer to three to five times human speeds. In our comparisons, we assumed that bots would be three times faster than humans for processes that access external websites or systems and five times for other processes.
Additionally, as RPA takes over simpler tasks, the average complexity that remains both in-house and offshore will increase. To accommodate this condition, we added a 4% average cost increase for the remaining in-house and offshore resources, after the RPA conversion. We further assumed that any RPA eligible task performed by BPO would be replaced by bots and that the allocation of in-house vs. BPO staff maximizes the relative costs and talent of these resources.
Under the above assumptions, an in-house/BPO project would reduce the overall staffing costs of a revenue cycle operation by 20%, when compared with the all in-house option. An in-house/RPA project would reduce costs by 26%. Finally, an in-house/BPO/RPA staffing plan would reduce the overall staffing costs by a staggering 38% when compared against an all in-house staffing plan in this hypothetical scenario.
Business Case Cost Assumptions:
1) Model based on a large, metropolitan provider with centralized patient access and business office
2) $ 50,000 per year for the fully loaded in-house FTE cost (i.e.: salary, benefits, management, HR and IT support, turnover, IT licenses, etc.)
3) $ 27,000 per production BPO FTE is a conservative figure for medium size offshore BPO projects
4) $ 250,000 for Bot licenses and ongoing support
5) The cost benefit comparisons exclude one-time set-up, training and potential consulting fees
The savings from our hypothetical project don’t take into account 2% to 3% annual raises, the 3% to 5% cost of attrition, or that many BPO contracts include cost of living adjustments. If these were included, the additional savings over a five to ten-year period would be significant.
Many providers have already outsourced some components of their revenue cycle process. Most common are insurance/benefits verification, claim statusing, follow up and collections and parts of cash posting. In these cases, an analysis could be undertaken to identify parts of the outsourced processes that could be performed by RPA and the BPO contract restructured accordingly. Our experience indicates that some sophisticated offshore BPO vendors are replacing FTEs with bots and sometimes keeping the savings. Providers should discuss this trend with their vendors and consider contract adjustments.
Implementation Considerations
The level of effort to structure a fruitful BPO relationship is significant. Files need to be configured, tested and shared weekly or daily between the parties. Meetings should be arranged at least weekly to discuss outcomes. The client also needs to dedicate sufficient staff to perform quality control on vendor performance and provide feedback, as required, to improve results. No vendor starts with the specific account and payer knowledge that the client has developed over the years. On average, it takes several months of constant interaction between BPO vendor and client to maximize results.
RPA and BPO implementations share many of the same characteristics. Files have to be configured and transferred. As with BPO, extensive testing is needed before RPA can be set into unattended production. Where the solutions differ is on the level of detail required to translate a process and its nuances into instructions that a bot can execute. For RPA, each step in the process needs to be documented in detail and analyzed from the perspective of a system that cannot think or draw inferences. For example, for a bot, St. James and Saint James are different entities, while a person would generally recognize them as the same. Instructions will be needed to tell the bot that they are the same.
BPO and RPA projects are most successful when transforming a stable, well documented process with defined performance measures. Having standardization and a performance baseline provides an easy way to check progress and measure and correct performance shortcomings. Even though unstable and ill-defined processes have been and will continue to be outsourced or put through an RPA solution, our experience indicates that these are more expensive to implement, take longer to achieve the target performance, and result in higher RPA and BPO operating and support costs.
Bots, like any automation, introduce two new variables into the staffing equation: recovering from the backlog produced by an internal or external system downtime, and/or dealing with sudden volume increases. With people centric processes, these issues are typically handled through incurring overtime or adding temp labor. With a newly automated process, fewer in-house staff are available to stay overtime and work through the backlog created by the system downtime. Given the complexity of most healthcare systems, hiring temps is generally not a timely option. For this reason, bot capacity should always be higher than what’s required to maintain the process at steady state. With the average incremental cost of a bot license and the supporting computer hovering around $6,000 per year, having some extras provides relatively cheap insurance.
The organization structure should be adapted to accommodate a new operating environment if any positions have been outsourced or replaced by automation. The organization may choose to release or repurpose the extra capacity provided by the new solutions. Alternatively, the department may be able to take on additional volume, either through acquisition or service expansion. It is also important to consider the remaining staff – if and how they should be restructured, as well as their new required skillset. If bots work the more routine, repeatable tasks, then staff are left with the more complex exceptions. Take the example of using bots to automate the authorization process as part of financial clearance. If the bots are able to retrieve most authorizations online, staff would be responsible for calling payers and providers and validating whether an authorization is needed, or for resolving a more complicated missing authorization. The skillset required to accomplish this task has become more narrowly defined and more complex. Organizations should change job descriptions, training and hiring practices in accordance with the updated business processes. Furthermore, productivity standards (in-house and BPO) may need to be re-evaluated and updated based on the assumption that remaining human tasks will be more complicated and take longer to complete.
Getting Started
Several key steps come to mind when thinking about how to structure hybrid (in-house/BPO/RPA) organizations and operating model:
1. Understand and document RPA and BPO capabilities and limitations. For example:
a. Walk your process front to back, in detail, and document:
i. All the steps required for the process to be completed
ii. Decisions to be made at each step
iii. Separate the decisions that only humans can make from rules that can be programmed (the RPA rules)
iv. For human decisions, separate complex, nuanced issues that require years of knowledge from simpler issues on which new people can be easily trained. The former are good candidates for in-house staff and the rest for BPO
b. For RPA rules and functions
i. Create detailed maps of all RPA to system and website interactions at a sufficient detail to tell the bot where to go and what to do
ii. Document exceptions and ambiguous steps
iii. Create paths to handle exceptions and either eliminate ambiguity or move that step to a human
c. For non-RPA rules and functions
i. Understand the level of sophistication of the BPO partner and scope to determine what they can do
ii. Whatever BPO cannot do or you do not want them to do, assign to in-house staff
2. Prepare a business case
a. Determine, from the above process, a preliminary division of labor and costs
b. Work with BPO partner, RPA vendors and sometimes even consultants to determine one-time and ongoing costs
3. Develop a pilot implementation plan
a. Select processes to pilot, for both RPA and BPO
b. Work closely with IT to understand timeframes and limitations
c. Select a team to manage the overall implementation
d. Determine what will happen to staff replaced by the new technology and prepare a plan to repurpose or exit
e. Create a communications plan
4. Launch the first pilot(s) and learn as you go
a. Most successful pilot(s) will require rapid iterations from stakeholders to address any unexpected issues and/or enhance the solution.
b. Keep detailed documentation of any and all modifications for easy reference
Bottom line
RPA and BPO should be considered as complementary and not as competing technologies. Whether a provider is already outsourcing parts of revenue cycle or performing all processes in-house, restructuring to take advantage of the combined efficiencies of RPA and BPO could bring about sizable cost reductions and potentially, minor revenue improvements.
About Deloitte
Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee (“DTTL”), its network of member firms, and their related entities. DTTL and each of its member firms are legally separate and independent entities. DTTL (also referred to as “Deloitte Global”) does not provide services to clients. In the United States, Deloitte refers to one or more of the US member firms of DTTL, their related entities that operate using the “Deloitte” name in the United States and their respective affiliates. Certain services may not be available to attest clients under the rules and regulations of public accounting. Please see www.deloitte.com/about to learn more about our global network of member firms.
This communication contains general information only, and none of Deloitte Touche Tohmatsu Limited, its member firms, or their related entities (collectively, the “Deloitte Network”) is, by means of this communication, rendering professional advice or services. Before making any decision or taking any action that may affect your finances or your business, you should consult a qualified professional adviser. No entity in the Deloitte Network shall be responsible for any loss whatsoever sustained by any person who relies on this communication.
Copyright © 2018 Deloitte Development LLC. All rights reserved.
The views, opinions and positions expressed within these guest posts are those of the author alone and do not represent those of Becker's Hospital Review/Becker's Healthcare. The accuracy, completeness and validity of any statements made within this article are not guaranteed. We accept no liability for any errors, omissions or representations. The copyright of this content belongs to the author and any liability with regards to infringement of intellectual property rights remains with them.