Section 17.3: RPA (Robotic Process Automation) in Access Operations

17.3.1 The “Why”: A Digital Band-Aid for a Fragmented System

In an ideal world, the standards we discussed previously—NCPDP SCRIPT, X12, and especially HL7 FHIR—would create a seamless, interoperable healthcare ecosystem. Data would flow freely and intelligently between providers and payers, making manual intervention the exception, not the rule. We are, however, decades away from that ideal. Today’s reality is a “messy middle,” a landscape littered with thousands of proprietary web portals, non-standardized PDF forms, and workflows that still rely on the fax machine. The ePA and FHIR-based superhighways are being built, but large parts of the PA process are still stuck on slow, manual country roads.

This is where Robotic Process Automation (RPA) enters the picture. RPA is not a form of deep, systemic integration like an API. It is not a language for exchanging data. Instead, RPA is a pragmatic, surface-level technology designed to solve the problems of today’s imperfect systems. It is a digital “workforce” of software robots, or “bots,” that can be trained to mimic the repetitive, rules-based tasks that humans perform on a computer. Logging into a payer portal? An RPA bot can do that. Navigating to the “Check PA Status” page? A bot can do that. Copying a case number from a spreadsheet and pasting it into the portal’s search field? A bot can do that. Reading the status and pasting it back into the spreadsheet? A bot can do that, too—and it can do it 24 hours a day, without breaks, without typos, and at superhuman speed.

For a PA specialist, RPA is a profoundly important tool because it targets the most frustrating, time-consuming, and low-value parts of your job. It automates the “clicks and keystrokes,” the administrative drudgery that drains your time and energy, freeing you to focus on the tasks that require your clinical expertise: analyzing complex cases, constructing compelling clinical arguments, and speaking directly with providers and payers about nuanced patient needs. This section is a deep dive into the world of RPA. We will explore what it is, how it works, its most powerful applications in the PA space, and, critically, its significant limitations and risks. Understanding RPA is understanding how to build a digital assistant to handle the grunt work, allowing you to operate at the top of your license.

17.3.2 What Exactly Is RPA? A Foundational Deep Dive

Robotic Process Automation is a software technology that allows users to configure a “robot” or “bot” to emulate and integrate the actions of a human interacting within digital systems to execute a business process. RPA bots utilize the user interface (UI) to capture data and manipulate applications just like humans do. They can interpret, trigger responses, and communicate with other systems in order to perform a vast variety of repetitive tasks. Crucially, an RPA bot is not a physical robot, nor is it the same as Artificial Intelligence (AI). It is a software application that runs on a computer, and in its basic form, it is not “intelligent.” It is a master of mimicry, following a predefined script with perfect precision.

Attended vs. Unattended Bots: The Two Types of Digital Workers

RPA bots come in two primary flavors, each suited for different types of tasks. In a mature PA operation, both types are often used in concert.

Masterclass Table: Comparing Attended and Unattended RPA Bots

Attribute	Attended Bots (“Digital Assistants”)	Unattended Bots (“Digital Workforce”)
Operating Model	Lives on a user’s desktop. Is triggered “on-demand” by the human user to perform a specific task. It works alongside the human as an assistant.	Lives on a separate server or virtual machine. Runs 24/7 in the background, processing a queue of tasks automatically based on a schedule or trigger.
Typical PA Use Case	A PA specialist is on the phone with a provider and needs to quickly verify a patient’s formulary alternatives. They click a button on their screen, and an attended bot instantly opens the payer portal, logs in, and pulls up the formulary page, presenting the data to the specialist in seconds.	Every night at 2:00 AM, an unattended bot wakes up, opens the master PA tracking list, identifies all 500 cases that are still “pended,” and then spends the next three hours logging into 25 different payer portals to check the status of each case, updating the master list as it goes.
Trigger	Manual: Started by a human clicking a button or using a hotkey.	Automatic: Triggered by a schedule (e.g., every hour), an event (e.g., a new file arriving in a folder), or a work queue.
Workflow Complexity	Best for automating smaller, discrete parts of a larger human-driven workflow. Helps to accelerate a specific step.	Best for automating entire, end-to-end, high-volume processes that do not require human judgment or intervention.
Analogy	A powerful calculator on your desk that you use when you need it.	An autonomous accounting system that processes all the company’s invoices overnight.

How Do Bots “See”? The Magic of UI Selectors

The core technology that allows an RPA bot to interact with an application is its ability to identify elements on the screen. When a human uses a website, they visually identify a button labeled “Login” and click it. A bot does the same thing, but using the underlying properties of that UI element. This identifier is called a selector.

When an RPA developer builds a bot, they use a tool (like UiPath Studio or Automation Anywhere’s Bot Creator) to point and click on the elements they want the bot to interact with. The RPA software then records the unique attributes of that element, creating a selector. This selector is like a digital address. For a web application, the selector might look something like this:

<html app='chrome.exe' title='Payer Portal Login' />
<webctrl tag='INPUT' type='submit' name='loginButton' />

This selector tells the bot: “Look for the Chrome browser window with the title ‘Payer Portal Login’. Inside that window, find a web control that is an INPUT element, has a ‘submit’ type, and has the name ‘loginButton’.” When the bot runs, it uses this address to find and click the exact same button every time.

17.3.3 The RPA Lifecycle: From Manual Process to Automated Worker

Deploying an effective RPA bot is not as simple as just recording your clicks. It’s a structured engineering process that requires careful planning, design, development, and testing to create a robot that is reliable, scalable, and resilient. Understanding this lifecycle is key to appreciating the investment required to build a successful automation program.

Stage 1: Process Discovery – Finding the Right Tasks for a Bot

Not all tasks are good candidates for RPA. The single biggest mistake organizations make is trying to automate a process that is too complex, too variable, or requires too much human judgment. The best candidates for RPA share a common set of characteristics.

Masterclass Checklist: Is This PA Task a Good Candidate for RPA?

Characteristic	Description	PA Example (Good Candidate)	PA Example (Bad Candidate)
Highly Repetitive & Manual	The task involves a human performing the same sequence of clicks and keystrokes over and over.	Checking the status of 100 pending PAs by copying and pasting case numbers into a portal.	Writing a complex clinical appeal letter that requires synthesizing information from multiple unstructured progress notes.
Rules-Based	The decision-making in the process can be mapped to a clear set of “if-then” rules. There is little to no human judgment or intuition required.	“If the status is ‘Approved’, update the spreadsheet to ‘Approved’. If the status is ‘Denied’, flag the case for human review.”	Deciding if a patient’s clinical situation warrants an appeal after a denial. This requires clinical judgment.
High Volume & Frequent	The task is performed many times a day or week, consuming a significant number of person-hours.	Processing hundreds of incoming faxed PA determinations daily.	Submitting a one-off compassionate use request for an experimental drug, a process that happens once a year.
Low Exception Rate	The process follows the same standard path the vast majority of the time. There are few variations or unexpected outcomes.	Checking benefits for a standard PPO plan, which has a consistent portal layout and workflow.	Navigating a poorly designed payer portal that frequently crashes, has pop-up windows, and changes its layout depending on the patient’s state.
Structured Digital Inputs	The bot can be fed data from a structured source, like an Excel file, a database, or a work queue.	Reading patient MRNs and case numbers from a daily-generated CSV file.	Trying to extract the needed information from a physician’s handwritten note on a scrap of paper.

The output of the discovery phase is a prioritized list of potential automations and a business case that estimates the potential return on investment (ROI), typically measured in hours saved per year.

Stage 2 & 3: Solution Design & Bot Development

Once a process is chosen, it must be meticulously documented. A developer cannot automate a process they do not understand. This is where your role as a Subject Matter Expert (SME) is invaluable. You work with the RPA developer to create a Process Design Document (PDD), which is a step-by-step blueprint of the workflow, including every click, keystroke, and decision point.

The PDD must also include robust **exception handling**. What should the bot do if the payer portal is down? What if a patient search returns “No Patient Found”? What if the internet connection is lost? A well-designed bot has a plan for every conceivable error, such as taking a screenshot of the error, logging the case number to an “exceptions” file, and moving on to the next case. A poorly designed bot will simply crash at the first unexpected event.

During development, the RPA developer uses a platform like UiPath to translate the PDD into a working automation. They will drag and drop activities like “Open Browser,” “Type Into,” “Click,” and “Get Text,” and link them together with logic (loops, if/then statements). They will configure the selectors for each UI element and build out the exception handling routines. Your role is to be available to answer questions and clarify the nuances of the process.

Stage 4 & 5: Testing, Deployment, and the Never-Ending Maintenance

Before a bot can be unleashed on real patient data, it must be tested into oblivion. This phase, often called User Acceptance Testing (UAT), is where you, the SME, get to try and break the bot. You will provide the developer with test cases, including “happy path” scenarios (where everything works perfectly) and, more importantly, edge cases and known exceptions. What happens if the case number has a letter in it? What if the patient has two active policies? Your job is to validate that the bot performs exactly as specified in the PDD and handles errors gracefully.

After passing UAT, the bot is deployed into the production environment. For an unattended bot, this means it’s set up on its server and the schedule is activated. A “hypercare” period follows, where the bot’s performance is closely monitored for the first few weeks to catch any unforeseen issues. And then begins the long-term reality of RPA: maintenance. As we’ve discussed, whenever a payer updates a portal or an internal application changes, the bot is at risk of breaking. A successful RPA program is not a “set it and forget it” endeavor; it requires a dedicated resource to constantly monitor bot performance and quickly remediate any issues to keep the digital workforce running smoothly.

17.3.4 Masterclass: Top RPA Use Cases in Prior Authorization Operations

Now let’s move from theory to practice. Where can RPA have the most dramatic impact on a PA team’s daily operations? The following are some of the most common and highest-value use cases currently being deployed in health systems and specialty pharmacies.

Use Case #1: Automated PA Status Checking (The “Portal Bot”)

The Problem: A significant portion of a PA specialist’s day is spent on the mind-numbingly repetitive task of checking the status of pending PAs. This involves manually logging into dozens of different payer portals, navigating to the right page, and copy-pasting case numbers from a master worklist. It’s a classic example of a high-volume, low-judgment task that is a perfect fit for an unattended bot.

The Automated Workflow:

1. Trigger: The bot is scheduled to run every hour (or at a set time, e.g., overnight).
2. Input: The bot opens a shared spreadsheet or accesses a database table containing all PAs with a “Pending” status. The required inputs are Patient Name, DOB, Insurance ID, and the Payer-specific Case Number.
3. Process Loop: For each case in the list, the bot performs the following steps:
   • Identifies the Payer.
   • Launches a web browser and navigates to that Payer’s specific portal URL.
   • Securely retrieves the appropriate login credentials from a credential vault.
   • Enters the username and password and clicks the login button. It will have built-in logic to handle multi-factor authentication if necessary.
   • Navigates through the portal’s menus to the PA status lookup page.
   • Enters the required patient identifiers and the case number into the search fields.
   • “Scrapes” (extracts) the status text from the results page (e.g., “Approved,” “Denied – More Information Needed,” “Pended – Medical Director Review”).
   • Logs out of the portal.
4. Output: The bot writes the scraped status, the current date, and any determination details (like an approval number or expiration date) back into the master worklist, updating the case’s status from “Pending.”
5. Exception Handling: If the portal is down, the login fails, or the case number is not found, the bot logs the error, flags that specific case in the worklist for “Manual Review,” and proceeds to the next case.

Use Case #2: Intelligent Data Extraction from Faxes (The “OCR Bot”)

The Problem: Despite the rise of ePA, many payers still communicate determinations and requests for information via fax. This creates a mountain of unstructured PDF documents that must be manually reviewed, identified, and triaged. A specialist has to read each fax, figure out which patient it belongs to, identify the determination, and then manually update the patient’s record and route the document.

This use case often involves a more advanced form of RPA that is augmented with AI, specifically Optical Character Recognition (OCR) and sometimes Natural Language Processing (NLP). This is often called “Intelligent Automation” or “Intelligent Document Processing.”

The Automated Workflow:

1. Trigger: The bot constantly monitors a specific network folder or email inbox where an e-fax server deposits all incoming faxes as PDF files.
2. Process (for each new PDF):
   • The bot opens the PDF.
   • It sends the document to an OCR engine. The OCR engine converts the image of the text into machine-readable text.
   • Data Extraction: The bot then uses predefined rules and patterns (or a trained AI model) to search the text for key pieces of information:
     • Patient Name (looking for labels like “Patient:” or “RE:”)
     • Date of Birth
     • Case Number / Authorization Number
     • Keywords indicating the determination (e.g., “Approved,” “Authorized,” “Denied,” “Not Medically Necessary,” “Additional Information Required”).
   • Data Validation: The bot might cross-reference the extracted Patient Name and DOB with a patient database to find the correct patient record (MRN). This confirms it has identified the right person.
   • Action & Routing: Based on the extracted data, the bot performs an action.
     • If “Approved”: It updates the PA status in the master list to “Approved,” enters the auth number and expiration date, and moves the PDF to an “Approved Faxes” archive folder.
     • If “Denied”: It updates the status to “Denied” and assigns a task to a senior PA specialist for appeal review.
     • If “More Info Needed”: It updates the status and assigns a task to the case owner to gather the requested clinicals.
     • If Confidence is Low: If the OCR engine cannot confidently extract the key data (e.g., the fax quality is poor), it routes the PDF to a human “exceptions” queue for manual review.