University of Utah Health’s revenue cycle automation shows that RPA works best when it attacks boring, repeatable work before it tries to “transform” everything. The strongest lesson from its case is simple: start with high-volume tasks, prove savings, then expand with tight controls. In revenue cycle, that often means claim status checks, payer portal updates, eligibility work, denial routing, and account follow-up.
TLDR: University of Utah Health’s RPA revenue cycle case shows how automation can cut manual clicks, reduce follow-up delays, and free staff for more complex accounts. For example, if a team spends 3 minutes checking one claim status, automating 1,000 checks can save about 50 staff hours. A mature RPA program may not remove the hard parts of revenue cycle, but it can remove the repetitive work that slows teams down every single day. The biggest win comes when bots, analysts, and revenue cycle leaders share clear rules and clean data.
Why this case matters
Revenue cycle teams live inside queues, portals, spreadsheets, worklists, and exception reports. The work is vital, but much of it is painfully repetitive. Staff may log into a payer portal, search for an account, copy a status, paste it into the billing system, and move to the next one. Then they do it again. And again.
That is where robotic process automation, or RPA, fits. In the University of Utah Health case, the value was not in replacing revenue cycle knowledge. It was in giving staff relief from manual transactions that did not require judgment every time.
Honestly, it feels absurd when trained billing staff spend extra minutes waiting for payer pages to load or retyping data that already exists in another system. RPA helps by acting like a digital worker. It follows rules, logs into systems, captures information, and updates records.
Lesson 1: Start with the ugliest repetitive work
The best automation candidates are not always glamorous. They are usually the tasks that people complain about because they drain time and attention. In revenue cycle, this can include:
- Checking claim status across payer portals
- Updating account notes
- Moving accounts between work queues
- Validating insurance eligibility
- Pulling remittance or denial data
- Creating daily reports from multiple systems
University of Utah Health’s approach reflects a practical rule: do not automate confusion. If a process has clear steps, stable inputs, and a large volume, it becomes a better candidate. If staff still argue about the right workflow, automation will only expose the mess faster.
Lesson 2: Measure time saved, not just tasks completed
RPA reports can make leaders smile with counts like “10,000 transactions completed.” That number matters, but it is not enough. Revenue cycle leaders need to know what those transactions replaced.
A better measure is hours returned to the team. If one claim follow-up takes 2.5 minutes and a bot completes 8,000 in a month, that equals more than 333 staff hours. That is time the department can shift toward denials, patient calls, underpayments, and exceptions.
The University of Utah Health case shows why automation should be tied to operational metrics, such as:
- Reduced aged accounts receivable
- Faster claim follow-up
- Lower manual touch volume
- Improved queue completion rates
- More accounts worked before timely filing limits
Lesson 3: Keep humans in charge of judgment
RPA is excellent at rule-based work. It is weak when context changes often. A bot can check whether a claim is pending, denied, paid, or missing information. It can copy the result into the account. But it should not make every appeal decision on its own.
That is where University of Utah Health’s lesson is useful. Automation should create a clean handoff. The bot does the search and sorting. Staff handle complex denials, payer disputes, coding concerns, medical necessity issues, and patient-sensitive cases.
The goal is not to remove expertise. The goal is to stop wasting expertise on copy-and-paste work.
Lesson 4: Build governance before scaling
RPA can get messy fast. One bot becomes five. Five become twenty. Then no one remembers who owns which one, what system access each bot has, or what happens when a payer changes a website button.
That is why governance matters early. A health system needs clear answers to basic questions:
- Who approves a new automation?
- Who validates the process rules?
- Who monitors failed transactions?
- Who handles bot access and password controls?
- Who updates the bot when payer screens change?
The catch is that bots are not “set and forget.” Payer portals time out. Screens change. Required fields move. One tiny change can add 20 seconds to every transaction or stop the bot outright. A support model is not optional.
Lesson 5: Choose processes with stable rules and clean inputs
Revenue cycle has plenty of variation. That causes trouble for automation. If an account has missing data, odd payer rules, or unclear ownership, a bot may fail or send the item to an exception queue.
University of Utah Health’s case points to a useful filter: pick processes with repeatable paths. For example, a bot can work well when the payer portal requires the same search steps each time. It can work even better when the billing system has consistent account identifiers, payer names, dates of service, and claim numbers.
Before automation, teams should clean up:
- Standard work instructions
- Payer naming conventions
- Queue definitions
- Required data fields
- Exception codes
Bad data does not become better because a bot touches it. It just moves faster.
Lesson 6: Treat RPA as workforce support, not a threat
RPA projects can make staff nervous. That is understandable. Revenue cycle employees may hear “automation” and assume job cuts. A better message is more honest: bots take the repetitive work so staff can work accounts that need thinking.
In a hospital or academic health system, the hardest revenue cycle work still needs people. Denials require payer knowledge. Patient billing issues require care. Prior authorization problems require follow-up. Underpayments require analysis.
Leaders should explain exactly what the bot will do and what it will not do. They should also ask staff where the friction is. The best automation ideas often come from people who are tired of clicking through the same screen 200 times before lunch.
Lesson 7: Match automation to revenue impact
Not every automation deserves the same priority. A task may be annoying but low value. Another task may directly affect cash, denials, or timely filing. The stronger choice is usually the one tied to measurable revenue cycle impact.
University of Utah Health’s RPA case is useful because it shows the need to connect automation to business outcomes. Revenue cycle leaders should rank candidates by:
- Volume: How many transactions occur each week?
- Time burden: How long does each one take manually?
- Error risk: How often do manual mistakes happen?
- Cash impact: Does the task affect payment speed?
- Stability: Are the rules consistent enough for a bot?
A simple scoring model keeps the program focused. It also helps avoid pet projects that sound exciting but save little time.
What revenue cycle leaders can copy
Health systems do not need to copy every detail of University of Utah Health’s program. They can copy the operating principles. Start small. Pick visible pain points. Track hours saved. Keep people involved. Fix bad processes before building bots around them.
A practical first project might be claim status automation for one high-volume payer. The team can compare 30 days of manual work against 30 days of bot-assisted work. If the bot completes 85% of checks successfully and routes 15% to staff, that is still a major gain. The staff can spend their time on the accounts that truly need attention.
FAQ
What is the main lesson from the University of Utah Health RPA revenue cycle case?
The main lesson is that RPA works best on high-volume, rule-based work. It should reduce manual effort while staff focus on complex accounts and payer issues.
Which revenue cycle tasks are best for RPA?
Good candidates include claim status checks, eligibility verification, payer portal lookups, account updates, denial routing, and routine reporting.
Does RPA replace revenue cycle staff?
Not in a well-run program. It supports staff by removing repetitive work. Human teams still handle judgment, appeals, exceptions, and patient-sensitive issues.
How should a health system measure RPA success?
It should track hours saved, bot success rate, exception rate, queue reduction, cash impact, denial improvements, and changes in aged accounts receivable.
What is the biggest risk with revenue cycle automation?
The biggest risk is automating a broken or unclear process. If rules, data, and ownership are messy, the bot will create faster confusion.
How should an organization start?
It should begin with one well-defined process, one payer or work queue, and a clear baseline. After results are proven, the team can expand carefully.
