To download the PDF version of the Feature Story, click the Download button below.

Download PDF

REPRINT October 2019

HFMA

healthcare financial management association    hfma.org/rcs

Revenue Cycle Strategist


Deciding whether to build or buy robotic process automation systems

By Andrew Woughter, Senior Vice President, Product Strategy, nThrive

Consider a partner's automation expertise and its ability to learn organizational 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 exactly is robotic process automation?

When deciding to build or buy robotic process automation (RPA), healthcare providers must first have a clear understanding of what it is, and what it can do. In simple terms, RPA software enables users to configure or train a robot to emulate the actions of a human being within a process by interacting with other digital systems through user interface and other application controls.

RPA is commonly used for repetitive, simple rule-based tasks however this is a very limited interpretation of it. The robots that can be built with today's technology can be governed by business logic and structured inputs, as well as artificial intelligence to manage complex processes with significant decision-making abilities.

Because terms and their definitions are not standardized within the RPA industry, it is helpful to describe what is meant by the term robot or bot. A robot is the collection of RPA software components that automate a single defined process. In other research, the term robot may be used to describe the machine that runs automations which could be multiple processes. Within revenue cycle management, a bot typically is used to complete a defined process.

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, the 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.

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.


Andrew Woughter
is senior vice president of product strategy, nThrive, and is a member of HFMA's Southern California Chapter (awoughter@nthrive.com).