Using Process Automation to Improve Auto-adjudication

The need to measure success — or the lack thereof — is critical to any business. A healthcare payer is no exception, and typically looks at its auto-adjudication (AA) rate for medical claims. This refers to the percentage of claims that pass automatically through the payer’s claims system with no human intervention. Some payers use different terms — such as pass-through rate, or first-pass rate, or operational first-pass rate.

This is an important number for various reasons. First, it’s a key performance indicator (KPI) that measures the efficiency of the company’s paying the claims. Many believe that having a high AA rate means the organization is providing efficient services to its customers with a high quality standard and for the lowest price possible. In fact, this number is so important for some organizations that it has become a KPI for executive bonuses.

Still, as advances continue in medicine and medical care, and medical codes and regulations become more complex, there’s an increasing likelihood of over- or under-paying claims through AA. Do we really know the amount of money wasted because the system auto-adjudicated claims? And what about the reverse of that — claims that the company pended for review by a human, especially an expensive human (nurse, doctor) through medical review, when the answer was obvious? I have seen situations where the cost of a person reviewing a claim was more than the cost of just paying the claim!

How Some Use the AA Rate

Some payers use the AA rate as a measure of potential cost savings for planned improvements. Yes, this can help determine which cost-cutting projects to approve. But you have to be careful how you use this, because it’s usually not as accurate as you might think.

For example, let’s say a company wants to reduce operational costs in its claims department. A standard way to incorporate the AA rate into the cost calculation is to divide the remaining AA rate into the operational budget. This will give you a cost-per-AA percentage. So, if your budget is $6 million per year and your AA rate is 85%, then your cost-per- AA percentage remaining is $6 million divided by 15, or $400,000. I have seen cost-per-AA percentages as low as $200K and as high as $2.5 million. One would tend to think that each percentage of improvement will yield that amount of cost savings; so, in this example, it would mean each percentage point of improvement would save $400,000.

But Not So Fast . . .

However, it’s not that simple. This is especially true if you’re using process automation, or robotic process automation (RPA), to help improve your AA rate.

Let’s say your improvement project is to automate the processing of pended claims. You need to identify claims that can give you the biggest impact on your AA rate. Typically, this is done by identifying the top errors — that is, the top edit codes. The natural thing to do would be to choose the edit codes that are on the most claims. So, perhaps you choose the most common edit codes, and the total number of claims with those edit codes is enough to provide a potential improvement of 1%. But there are several things you still need to consider:

  • First, what is the success rate you expect? In other words, of the [x] thousands of claims that the automation solution handles, what percent will it actually finalize and count toward the AA rate?
  • Second, are there edit codes you cannot automate? These tend to land with some of the edit codes you have marked for automation, If there are such codes, you may want to reevaluate your automation opportunities. Any claim that contains an edit code that can’t be automated will still have to be touched by a human. That claim therefore won’t count toward AA improvement. After doing your analysis to determine potential success rate, you will most likely end up with a success rate of somewhere between 30% and 50%. This means you need to identify another set of edit codes to get back to the expected 1% improvement.
  • Another issue with this approach is that you really won’t get a 1% improvement. The reason is that some of the edit codes you choose could be very simple to work, and therefore doesn’t take a lot of FTEs. As a result, your cost savings calculation is going to be short of expected.

An Alternate Method

There is another way. Instead of measuring your success by your AA rate, measure it by the average cost to process a claim.

This approach will allow you to reduce costs in several ways — including automating claims processing — but without the constraint of improving the AA rate. In the long run, you reach the same goal as AA improvement: cost savings. However, now you can automate errors with no regard to the potential improvement in AA. You no longer worry about other errors that might be on a claim. After all, any work being done by the automation solution reduces the time a human spends on the claim.

You can also implement workforce improvements using analytics tools to help your users be more productive. In turn, this reduces the cost of a claim, because users are able to work more claims in the same amount of time. Instead of measuring the cost per claim (which could be difficult), perhaps you can measure the cost per percentage point of AA rate. Through automation and/or enhanced workforce productivity, you could reduce costs. This means the cost of each percentage of AA will go down — even if you don’t improve the AA itself.

A Win-win Way to Measure Success

Here’s the bottom line. If your overall goal is to reduce costs, then you should look at alternatives to improving your AA rate. If you choose to implement the claim cost or cost-per-AA percentage, you will still improve your AA rate; but you also will save a lot more money and become more efficient and accurate, which also will reduce rework.

Robotic Process Automation: Part II of a five-part series

Part II: Creating a Process Automation Strategy

It’s simple, right? You bought a robotic process automation (RPA) tool, thinking you were going to automate a bunch of processes and save the company millions.

It worked fine for a couple of simple processes, but now you’re not sure what to automate next. Even worse, after only a few months, the automation robots you implemented are having issues. What happened? It was all working on Friday!

Your main problem isn’t that you chose the wrong automation tool (although that might also be an issue). Your problem is that you didn’t put together an automation strategy, before you bought the tool.

So, What’s an Automation Strategy?

An automation strategy is planning and management of your automation initiative. A typical automation strategy should answer the following questions:

  • Which processes do we want to automate?
  • With which applications will we have to interact?
  • Who maintains those applications, and how often are they updated?
  • Who needs to know that we have automation running against the applications?
  • How do we find new automation opportunities?
  • How do we get notified before changes are made to an application?
  • Is there test data available, so we don’t have to test with production data?
  • With what security rules and regulations do we have to be compliant?
  • Which departments (e.g., IT, Security, HR) need to be involved?
  • What resources will need to be involved, and for how long?
  • What’s the overall cost of implementing the solution?
    Hint: the automation product is probably the least expensive part of the solution.

To be sure, even with all of those items to manage, automation provides a high return on your investment. I have helped many companies implement automation into their environments and, for every one of them, it’s always been worth the time and expense. It’s definitely worth the time and money to implement process automation but, to have real success with it, you must do it the right way.

Five Steps

Here are my five steps to implement a successful automation strategy:

  1. Don’t reinvent the wheel.
    Talk to someone who has already implemented a successful strategy. Maybe it’s a manager of another group in your organization, or a trusted partner. Copying another successful implementation in the same industry is the best way to get started quickly.
    Another option is to find a vendor that understands your industry and your problems. There are a lot of automation tools out there, and many are very generic. Consequently, most vendors don’t have specific domain expertise. To them, all automation is the same. I can tell you: it’s not! There’s a big difference between automating a simple desktop task and automating, for example, complex medical claims.
    Do a Web search to find the right vendor and solution; but don’t search for automation or even robotic process automation; you’ll find very generic solutions from vendors who have no expertise in your area. Instead, make your searches specific — for example, automating medical claims.
  2. Pick your team carefully.
    Yes, that’s right: you’ll need an automation team. It should consist of at least one business analyst, one technical person (this could be an IT resource), at least one programmer (someone has to “build” the software robots), and a decision-maker or approval committee (to decide “What do we automate next?”). You also should have a subject matter expert (SME), but this role could — and should — be rotated among several people. Each SME has expertise with certain processes so, engage only the best SME for the process you intend to automate next.
  3. Define your process.
    Your process should start with identifying the next (or first) automation opportunity. It should also include the method used to identify automation opportunities; and, before you begin your first one, you should have a list of five to 10 opportunities. In fact: for each opportunity, you should be able to calculate the potential ROI, and that should be the highest criterion on which you base the decision to automate a process. However, basing it on cost is only one option. You could use the “squeaky wheel” approach. This is where you choose to automate processes that draw the most employee complaints. Although this might result in minimal cost savings, it could be worth it to make your users happier!
    Once you define the list of automation opportunities, you need to implement them. The rest of the process should be defining the requirements with the SME, validating the business rules with the business analyst, documenting the step-by-step instructions with business rules, and providing those rules to the programmer for creation of the software robot.
    Testing is critical. Make sure that (a.) you have valid test data that truly represents real, production data and (b.) it can emulate all of the scenarios implemented in the robot. That’s the only way to test your robot fully before it moves to production.
  4. Have a backup plan.
    What happens if you have 10 robots running all day and, suddenly, they all stop? Let’s say that, up to this point, your automation solution has been so successful that you were able to eliminate 50 FTEs. But now, you don’t have the people to do the work and your robots aren’t running. Your backup plan must take into account this nasty scenario and others like it.
  5. Measure, measure, measure.
    Make sure your software robots provide the data related to the work they’re doing. This is some of the most valuable data in your organization. Use an analytics tool (if your automation product doesn’t already have one built into it) and analyze the data. What you’ll get from it is not only what your robots did but, more importantly, what they didn’t do. Of course, what they didn’t do is what they should do. That can help you understand how to improve your robots and the value of doing so.

If you carefully plan and take advantage of the knowledge and experience of others, you will have a successful automation strategy. Remember: don’t automate unless you have a strategy in place ahead of time!

Part III: Choosing the Right Process Automation Solution.

Robotic Process Automation: Part I of a five-part series

Part I: What Is RPA, and Why Should CIOs Care?

Robotic process automation (RPA) has become very popular in the last couple of years. It’s become such a mainstream topic that you can find RPA-related articles in publications such as the New York Times1 and the Wall Street Journal2. So, what is RPA, and why has it become so popular?

Automation — specifically, process automation — has been around for more than a decade. However, RPA is a specific type of process automation. The robotic part means a software robot that mimics a human. More to the point, it means software that interacts with the same applications and interfaces that humans use. It’s important to understand this: it has many implications; and it’s the major distinguishing characteristic among process automation, business process automation (BPA), and robotic process automation.

There are several reasons RPA has become popular in recent years. Businesses are constantly under pressure to reduce costs, but they can’t rely on their IT departments to be responsive to their needs. RPA allows businesses to use automation without requiring IT involvement. Mind you, that approach is not best! However, it can help them implement a solution much faster. Even some IT departments have embraced RPA, because it’s easy to implement and requires no application or infrastructure changes. This allows the IT departments to deliver value to the business more quickly and efficiently. However, many see it as merely a Band-Aid® for legacy applications in which they don’t want to invest.

Part of a Strategy

It’s a fact that automation reduces costs — in some cases, dramatically. But most CIOs don’t see RPA as strategic. Instead, they view RPA as a tactical approach that’s best for the business users or individual IT departments to use on a case-by-case basis. Still, CIOs should embrace RPA for what it is, rather than avoiding it for what it’s not. Yes, RPA is a Band-Aid for some situations, but it’s also an effective way to save money quickly. To be sure, a company should use RPA as part of an overall automation strategy or a digital transformation initiative. The company should not use RPA as a “one-off” solution for one process and one department.

RPA tools also have limitations. Why? Because, in most cases, the entire targeted process is running on a desktop PC. As a result, that limits you to the flexibility of the RPA tool and the robustness (or lack thereof) of the desktop environment. If your process has complex logic, it’s less likely that an RPA tool can automate it. Also, there are certain types of application interfaces that work well for humans, but are a challenge for automation. Two examples are mainframe applications and Web-based applications. You usually can access both using server-based technology that’s more powerful and more accurate than a default desktop interface allows.

A Better Way

Why not use the best of both worlds? That would be a server-based process automation solution that utilizes RPA technology to interact with the desktop applications when it makes sense to do so.

Here’s an example. Let’s say you have a process that uses a client/server application, a Web-based application, and a mainframe application, along with some standard desktop applications such as Excel® and Outlook®. With a pure RPA tool, you will have to create a process that runs on the desktop and interacts with all of these applications. If the logic isn’t too complex, then you might be okay, but it’s still a lot of applications with which to interact. However, if the logic is complex — well, good luck. This will be a challenge for most RPA tools.

A better approach is to have a server-based solution that runs all of the business logic and process information. This gives it the power to process complex logic and keep track of the hundreds of software robots that could be running at any one time. Such an approach also enables the server to connect directly with the Web-based application, using standard Web services. This eliminates otherwise required “screen-scraping” on the desktop or navigating a browser’s document object model (DOM). Ideally, the server-based solution can also access the mainframe applications directly on the network without “screen-scraping” a desktop-based mainframe emulator. (Of course, the desktop applications have to reside on a desktop, and that’s where the RPA tool comes into play. However, there is no need for complex logic to run on the desktop, since the logic is running where it should be: on the server.)

This approach allows you to take advantage of the RPA tools that are getting much attention, while still implementing them in a more robust, server-based environment that can be part of a strategic automation initiative. This is no Band-Aid approach. And it’s something a CIO can and should embrace: yes, bring in RPA and allow the business units to use it, but control it and implement it in a centralized, enterprise-level environment.

Part II: Creating a Process Automation Strategy.
Band-Aid is a registered trademark of Johnson & Johnson Services, Inc. Excel and Outlook are registered trademarks of Microsoft Corporation.