Deciding whether to build or buy robotic process automation systems

• A rule of thumb is to deploy bots for transactions with a payback period of less than 12 months.
• Maintenance is the biggest factor organizations overlook with robotic process automation implementation. When underlying systems change, the bot must be re-trained based on those changes.
• Providers must consider an RPA partner’s level of expertise and knowledge, not only of RPA but also the organization’s processes.

Robotic process automation (RPA) is expected to have a transformative impact on revenue cycle management in the next few years, automating much of the rudimentary tasks in healthcare while also improving efficiencies and reducing costs.

The trade-offs between a home-grown approach to RPA versus contracting with a supplier to deploy RPA is something every provider should consider. But first, healthcare organizations should define their automation needs and understand the critical impact of regular maintenance.

What can RPA do?

First, it’s important to define what RPA can do so revenue cycle leaders can determine what processes will be automated. This is one of the most common questions regarding RPA. It is sometimes easier to explain what RPA can’t do. Because RPA is a digital software, the most obvious limitations are any steps in a process that exist outside the digital world. If a physical object must be handled, then RPA isn’t the right tool. Humans or physical robots are required.

However, many non-digital processes can be modified to enable automation. This includes processes that require printing documents or receipt of physical paper. Once items are scanned into the digital world, RPA can start having an impact.

See related sidebar: What exactly is robotic process automation?

Some specific ways to apply RPA within revenue cycle processes include the following:

• Work claim denials
• Preventing claim denials
• Managing authorizations
• Triggering inpatient notifications
• Eligibility research
• Working billing edits in claims’ scrubbers
• Managing most cash posting functions
• Managing lockbox correspondence
• Validating underpayment flags on paid claims
• Managing initial claim attachment processes
• Monitoring governmental eligibility changes
• Identifying correct payer/plan code selection at registration
• Loading large data files into systems when no direct interface exists

With such broad use cases for RPA, it is easy to see why significant ROI can be achieved with the deployment of bots. At nThrive we have experienced more than 900% ROI on labor cost savings by deploying a bot to automate and work certain claim denials. A rule of thumb is to deploy bots when the full payback period is less than 12 months. With such financial benefits and so many places to start, it is easy to get excited and just want to build bots right now. However, there are risks that need to be considered before jumping headlong into RPA deployment.

Don’t overlook maintenance

The biggest factor organizations overlook with RPA initiatives is the fact that bots require maintenance. A bot works on existing systems and websites, and when the underlying systems change, the bot must be re-trained based on the changes.

Some use this as a reason to dismiss the use of RPA. This seems to be the equivalent of suggesting that people should not buy cars because cars require maintenance and can break down. Instead, people should just walk everywhere? If organizations fail to have a plan to address RPA maintenance requirements, they likely will find themselves with a broken-down bot eventually. However, there are several ways to mitigate the impact and cost of maintaining bots.

A much less talked about risk with RPA is complacency with the current process. Providers must not let themselves simply take a bad process and just do it faster. Processes should be evaluated and optimized for an automated environment without resource constraints. It is likely that an organization’s current processes are not as efficient or effective as they could be because they were developed in an environment with constrained resources. These organizations only work the way they do now because that was the best they could do before automating processes.

Once the process is automated, it is also just as important to have a plan in place to regularly determine and implement underlying process improvements.

Build or buy?

The most obvious benefits to the do-it-yourself (DIY) approach to RPA is a lower initial cost. However, if organizations are not careful with this approach to RPA, it can result in higher maintenance costs that may make it worth working with a partner.

Although any organization can license an RPA platform and train/hire a team of engineers to build bots, the idea that organizational leaders know their processes better than anyone often leads to the idea that they should directly manage the development of bots. Why? It allows organizations to emulate their processes, with access to their own data, systems and infrastructure. That sense of control and protecting access is a driving factor for many organizations who take a DIY approach to RPA. Ownership of the intellectual property for the deployed bots is another benefit of a DIY approach.

Deciding to work with an RPA partner has it benefits as well for healthcare organizations. When taking on a new initiative, especially a complicated one, it is necessary to honestly evaluate existing capacity and organizational capability.

Most partners have developed expertise in RPA and can provide lessons from both failure and success to make the RPA initiative as smooth as possible. However, providers must consider the partner’s level of expertise and knowledge, not only of RPA but also the organization’s processes. For example, do providers want to be explaining to their partner what an 837 transaction set is or an 835 electronic remittance advice is or the value of the code?

An ideal partner understands the details of the organization’s processes to optimize them prior to automating. Any RPA partner can document the steps taken to appeal a denial, but the right partner can leverage RPA to prevent denials in the first place.

What else should providers know?

Providers must understand their existing strengths, evaluate what they are willing to invest and have a strategy to use RPA
as an innovative tool to transform their revenue cycle processes. If any of those areas is not 100% clear, an RPA partner can help begin the RPA journey and get the provider moving more quickly. An RPA partner can also help the organization’ technology team reach a stage where they can develop bots on their own. Ultimately, the key to successfully integrating bots into the revenue cycle could well be a hybrid approach.

One thing is certain, the robots are coming. Choosing to ignore them and continuing with labor-intensive processes that can be automated to improve efficiencies and reduce costs, could cause healthcare organizations to struggle in today’s highly competitive healthcare market.