Inside Trinity Health's Revenue Cycle Automation RPA

What Is RPA in Revenue Cycle Automation?

Robotic process automation (RPA) uses software bots to repeat fixed, rules-based steps across screens and systems: logging into a payer portal, checking eligibility, and posting the result back to the EHR, without a person doing it by hand.

In a hospital's revenue cycle, that means bots working the front end (registration, eligibility, prior authorization) and the back end (claims status, denial routing, payment posting). The bots do not decide anything. They follow the same script a trained clerk would follow, just faster and around the clock.

Trinity Health, Sutter Health, Providence, and Intermountain Health have all invested in RPA for exactly these tasks. A mid-size health system processes millions of these transactions a year, and federal rules are pushing the same direction: CMS projects that moving claims attachments off fax and mail alone will save the industry $781.98 million a year, the exact manual work bots replace.

How Is Trinity Health Automating Its Revenue Cycle with RPA?

Trinity Health, one of the largest Catholic health systems in the US, is consolidating multiple electronic health record and revenue cycle platforms onto a single system, and using RPA bots to keep claims moving during that migration.

That combination, a legacy IT migration plus heavy RPA use, is common. Bots absorb repetitive work (rekeying data between systems, checking eligibility across payers, chasing claim status) while the underlying platforms get unified. They do not need the migration to finish first; they sit on top of whatever screen exists today and get rebuilt when that screen changes.

The risk sits in that last sentence. A bot built against today's portal breaks the day the portal's layout changes. Health systems mid-migration tend to budget bot maintenance as an ongoing line item, not a one-time build.

Where Do the Bots Actually Sit in the Workflow?

RPA in revenue cycle clusters around four points: eligibility verification, claims status checks, prior authorization status, and denial routing, the highest-volume, most repetitive tasks in the chain.

Eligibility verification means a bot logging into a payer portal before every visit to confirm coverage is active. Claims status means a bot checking, days after submission, whether a claim was accepted, rejected, or is still sitting in a queue. Denial routing means a bot reading a denial code and sending the claim to the right queue, appeals, coding review, or write-off, instead of a person sorting a fax.

None of these four require a decision. That is exactly why they were automated first.

How Do Sutter Health, Providence, and Intermountain Compare?

All three run RPA at meaningful scale in revenue cycle, but at different points on the maturity curve, from early pilots to close to 500 bots in production.

None of the four started with an enterprise-wide rollout. Each began with one narrow, high-volume process and expanded only after it held up in production.

Where Does RPA Deliver Real Return in Revenue Cycle?

RPA pays back fastest on tasks with three traits: high volume, a stable screen, and a single correct answer. Eligibility checks and claims status checks qualify. Judgment calls do not.

A bot that checks eligibility for 40,000 visits a month replaces 40,000 manual logins, at a cost that does not scale with volume the way headcount does. The same logic applies to claims status checks and routine payment posting. A claim is either active or it is not; there is no interpretation required.

Return drops off fast once interpretation enters: reading a denial letter to find root cause, deciding whether a claim is worth appealing, or reconciling a partial payment against a contract's actual terms. Those need a trained person or a system that can read and reason, not just click.

Where Does RPA Hit a Wall?

RPA breaks whenever the screen it was built against changes, and it cannot make a judgment call. Both happen constantly in a real revenue cycle.

A payer redesigns its portal, and every bot built against the old layout stops working until someone rebuilds it. A denial code the bot has never seen does not get routed correctly, it gets stuck. Unstructured input, a scanned explanation of benefits, a fax, a PDF with the denial reason buried in a paragraph, is exactly where rule-based bots fail, because there is no fixed field to read.

Harvard Business School research on EHR adoption found administrative costs did not fall automatically just because a hospital digitized. The tool alone does not change the outcome; the process behind it does.

RPA vs AI Agents: What's Actually Different?

RPA executes fixed steps on structured screens. AI agents read unstructured input, apply judgment, and decide what to do next, which is why the two are increasingly paired rather than treated as substitutes.

An RPA bot can check claim status on a fixed schedule. An AI agent can read a denial letter, classify the reason, draft an appeal, and flag the cases that need a human to look twice, the kind of capability documented in Microsoft's RPA training path and offered directly by vendors like UiPath's healthcare automation platform.

For a health system, that split matters operationally. RPA teams manage bot scripts; an AI agent development effort manages models, prompts, and guardrails. Treating them as one team with one roadmap avoids the two later colliding on the same workflow.

How Should a Health System Sequence the Investment?

Map where staff time actually goes before buying any bot. Automate the highest-volume, most rules-based step first, and only then add AI agents for the judgment calls.

Most revenue cycle automation projects fail the same way: a team buys an RPA license, builds a bot for whichever process is loudest in a meeting, and finds six months later that the bot automated a process nobody had actually fixed. The fix is sequencing: audit the workflow, confirm the process itself is sound, then automate it.

A broken workflow assessment is the fastest way to find out which revenue cycle steps are worth automating today and which need a redesign first. Document-heavy steps, prior authorization forms, denial letters, EOBs, usually need document AI before RPA can touch them at all.

What Does This Cost, and What's the Payback?

Cost scales with scope, not with the word "automation." A single-process pilot runs in weeks; a system-wide rollout across dozens of payer portals runs for months and needs an ongoing maintenance budget.

The real cost driver is not bot licenses, it is integration work: connecting bots to legacy EHR screens, handling exceptions instead of failing silently, and rebuilding scripts when a payer portal changes. Health systems that treat RPA as a one-time build routinely underbudget this by half.

Viithiisys runs CTO-as-a-Service engagements from $100 an hour for exactly this scoping and governance work: deciding what to automate, in what order, before committing to a platform. For a contained pilot, that scoping plus a working prototype can follow the same shape as a Moonship MVP, a working build in 30 days, rather than a year-long platform commitment.

Is Your Revenue Cycle Ready for Automation?

If nobody can say exactly where your eligibility, claims status, and denial routing time goes today, that is the answer: audit before you automate.

Viithiisys has been building integration-heavy, compliance-sensitive software since 2007, engineering out of Mohali in India's Chandigarh tricity with a Canadian office in Markham, Ontario, for clients including Paytm, Snapdeal, IKEA, Nestle, Shiprocket, and Vikram Solar. We have not run a hospital's revenue cycle, and we will not pretend otherwise. What we bring is the same discipline those projects required: AI workflow automation and systems integration work that survives contact with a legacy system nobody fully documented.

If you want a second opinion on where your automation budget should go first, book 30 minutes and bring your current workflow map.