We have spent over 10,000 hours designing, building and managing the operation of complex revenue cycle robotics process automation (RPA) projects.
We have implemented RPA solutions (bots) that interact with more than 10 external applications to complete one process, or that required thousands of lines of code and hundreds of unique use case scenarios. Our bots have covered single processes as well as multiple, linked ones where the output from one bot is used by the next one. When we started the RPA journey we assumed that after all our careful planning and design, our bots would be able to, out of the box, solve for 50% of the incoming volume (the “Replacement Factor”) and leave the other 50% of more complex transactions for human operators. We were surprised as we realized that testing limitations and changes to external systems, outside of our control, resulted in an initial Replacement Factor that varied between 30% and 40%. The purpose of this paper is to share lessons learned and provide strategies to continuously improve the degree of automation and the Replacement Factor of a given RPA solution.
For most healthcare providers, PHI handling limitations and IT security requirements severely limits the testing of RPA projects that access external systems. Normally, when testing a new IT solution, dummy or very old data is selected to represent the desired use cases and run through a test system to detect potential issues. Prior to go live, fixes can then be developed for problems discovered during testing. If the data set is large enough, and the testing diligent, systems can go live with minimal surprises. The difficulty with RPA solutions that interact with external data, e.g.: a payer or vendor benefits or authorization site, is that current patient information is required. The payer’s website will not return information on dummy data or validate an authorization for a patient with a date of service from two years ago. Because of this, not all problem scenarios will be uncovered during system or user acceptance testing. These limitations require a re-definition of the go-live sequence and particularly of the “are we done yet” date.
Bugs vs. Updates vs. New Scenarios
Situations where the bot cannot complete the assigned task and where work instead needs to be transferred to an operator will negatively impact the Replacement Factor and the project’s financial return. We have identified four distinct post-go live error situations that impact the bots’ completion of their work during production: Type 1. a “bug”, where the bot should have followed one path and instead followed another or none at all, or where the bot should have returned one number and instead returned another number; Type 2. an external change, where the bot functions correctly but encounters a change in the external environment that it was not programmed to resolve, for example, the layout of a payer’s website has changed and the information is not where the bot is looking for it; Type 3. an inconsistent external link, such as a vendor system where the information across all payers does not get updated on the same cycle, which causes the bot to complete the task sometimes but not be able to find the patient’s information on others; and Type 4. a new situation that was not uncovered during design and testing, for example, the external vendor website returns three insurances for a given patient but the bot was programmed to only expect two. Irrespective of the scenario, the production (post go-live) system should be set up to identify and quickly resolve the issues encountered.
Ongoing Performance Management
Type 1 errors can generally be prevented through careful process design and testing. Bots follow rules of the type what/if/then, null, compare and can perform mathematical computations. They cannot “think” or draw inferences, which means that designing and coding for RPA should be more thorough than doing it for human users. RPA projects require very detailed process flows, the recording of system screen flows and of every operator click and actions for each of the use cases identified. This effort, coupled with careful coding and testing, should eliminate most Type 1 errors. Unfortunately, Type 2-4 errors are, by nature, very hard to predict. For this reason, it is imperative that an RPA system be designed to quickly identify, isolate and correct these issues. In our experience, continuous process improvement requires the following levers:
a. Process Design:
It is a best practice to design revenue cycle systems that access external sites so that all volume to be automated goes through the bots first and anything that the bots cannot solve, for whatever reason, is referred to an operator. This approach can potentially minimize the risk of an error seriously impacting overall performance and results as there will always be someone ready to catch the unprocessed transaction. All type 2-4 errors will, with this approach, be forwarded to a person for resolution. To identify these errors, and create a plan to correct them, the bot Replacement Factor should be tracked daily, as this is an excellent indicator of the health of the overall automation. Any unexpected decrease or increase in the Replacement Factor should be investigated. In addition, it is good practice to train operators to identify and report situations where the bot transferred unexpectedly.
b. Ongoing Improvement Cycle:
In addition to daily Replacement Factor tracking, reporting is required to identify the specific accounts and transactions that the bots are not able to complete. This information provides the basis to aggregate and analyze potential root causes. All errors should be quickly investigated. Experienced operators can then be asked to develop and document the required solution. This potential fix can then be coded, tested and put into production. This ongoing cycle constantly improves the Replacement Factor and significantly reduces overall costs over time. Initially, the problems that impact the Replacement Factor will be easy to identify and correct. Overtime, the solutions will become more complex and require more creative options.
c. Human brain power vs. cognitive analytics and artificial intelligence (collectively “Big Data”):
We are often asked to consider designing “expert” systems or cognitive automation solutions, in conjunction with RPA, for revenue cycle applications to facilitate ongoing machine learning and continuous process improvement. These Big Data solutions are certainly sexy and make one feel part of our industry’s leading edge. However, but for HIM applications, most problems encountered in the rest of the revenue cycle, with the exception of discussing an account with a payer representative or with a patient, are fairly lineal, respond well to two-dimensional cause and effect logic, and can be expressed in relatively simple rules. These rules typically reside in the minds of experienced operators. Even though it is possible to process vast amounts of information through Big Data analytics and derive a new rule, it is frequently easier, faster and cheaper to gather a few experienced hands, discuss the options, identify a preferred solution, and create a rule within the RPA application. Even those instances where, to complete a transaction, an operator needs to go through several databases and perform calculations and comparisons, are easily expressed as rules that an RPA application can interpret. Big Data most likely would have come up with a similar conclusion, but not before significant programming and cost.
d. Post Go-live Organization
Continuous process improvement requires the identification of some key roles: subject matter experts, these are the experienced operators on whom to rely to identify solutions to operational issues identified during production, as well as to test potential fixes; a business analyst, who will be able to translate the process changes required into language that will be understood by developers; and developers, to code the changes into the RPA application. In addition, there should be a person or group charged with deciding how to prioritize the improvement opportunities identified. A simple matrix, such as the one presented below, can be used to that effect.
Conclusion:
The process described will, irrespective of the initial Replacement Factor achieved post go-live, result in a continuous improvement cycle. Given the difficulty of forecasting all possible operational scenarios before go-live, and the time that would be involved in going through that effort, it is often more efficient and cost effective to launch an RPA application with a handful of rules and use cases, gather performance data and rely on the continuous improvement process described in this paper to hone in on the most promising additional rules.
This publication contains general information only and Deloitte is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or other professional advice or services. This publication is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor.
Deloitte shall not be responsible for any loss sustained by any person who relies on this publication.
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.
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.