Revenue Cycle Automation: Where Bots Stop, AI Starts

What RPA solved in RCM, and what it didn't

RPA removed copy-and-paste work between portals and billing systems, which is why it became the first step in most revenue cycle automation programmes. It did not remove judgement work. Bots follow fixed rules on stable screens, so they fail when a payer changes a form or a denial needs interpretation.

What did healthcare RPA actually fix?

Healthcare RPA proved itself on high-volume, repetitive tasks with a clear right answer. Eligibility lookups, claim status checks, payment posting from remittances and patient demographic updates all fit that pattern.

Microsoft's own Power Automate desktop flow documentation describes the model plainly: recorded UI actions and scripted steps that replay on a schedule or trigger. That is a good fit when the input is structured and the screen is predictable.

Where do bots break?

The failure mode is maintenance. A bot that clicks through a payer portal depends on that portal's layout, login flow and session handling, and payers change these without notice.

Bots also cannot read an explanation of benefits that arrives as a scanned PDF, or decide whether a denial is worth appealing. In our experience, teams that stretch RPA over those tasks often end up with exception queues that grow faster than the work the bots remove. That is our observation rather than a measured figure, so test it against your own exception counts. This is the gap RCM automation now fills with AI.

Denials: the workflow that defeats rules engines

Denials resist rules engines because each one needs context: the payer's reason code, the clinical record, the contract terms and the appeal deadline. Claims denial automation therefore works as a pipeline with human approval, not a single bot.

Why is a denial harder than a claim submission?

Submission is a structured transaction in the X12 837 format. A denial arrives as a remittance (835) with CARC and RARC codes, often alongside a letter, a portal message or a phone call.

The same code can mean different things for different payers and plans. A rules engine can route a denial, but it cannot decide whether the documentation in the chart supports an appeal.

Is the denial worth fighting?

The public evidence says many denials are wrong. The HHS Office of Inspector General's 2022 review of Medicare Advantage found that 13% of prior authorization denials and 18% of payment denials met Medicare coverage and billing rules, meaning the services should have been approved or paid.

That finding concerns one programme and one period, so treat it as evidence that appeals have a basis, not as a forecast for your own mix.

What does an AI-assisted denial pipeline look like?

A workable design has four stages:

1. Classify the denial by reason code and payer.
2. Pull the relevant chart and claim data.
3. Draft the appeal with citations to the record.
4. Queue it for a biller to approve before anything is sent.

The Anthropic tool use documentation describes the pattern for letting a model call defined functions rather than act freely. In RCM that means the model can fetch a remittance or a note, but only your code submits anything. Our AI workflow automation work follows the same split.

Where do eligibility, coding and posting fit in revenue cycle automation?

Eligibility and posting suit RPA or direct API integration. Coding and document intake suit AI with human review. Matching each step to the right layer is the main design decision in revenue cycle automation.

Eligibility and prior authorization

Eligibility checks use the X12 270/271 transaction where the payer supports it, which is cheaper and sturdier than driving a portal. Use a bot only for payers with no usable electronic route.

Prior authorization is changing. The CMS Interoperability and Prior Authorization final rule (CMS-0057-F) requires affected payers to offer prior authorization APIs and meet set decision timeframes. Check the current dates for your payer mix before building a portal bot that the rule may make redundant.

Coding and document intake

Coding assistance is where AI earns its place, because the input is clinical text and the output is a recommendation. Keep a certified coder as the approver, and log which suggestions were accepted.

Document intake is similar. Faxes, scanned referrals and payer letters need extraction before anything downstream can run, which is the job of document AI.

Payment posting and reconciliation

Posting from an 835 file is structured and rules-driven, so it should be automated end to end. The exceptions are the valuable part: short pays, unmatched remittances and bundled payments.

Route those to a worklist with the evidence attached. A reconciliation report that shows variance by payer is more useful than a faster posting rate.

What compliance constraints shape the build?

HIPAA, payer contracts and audit requirements decide how a revenue cycle build is structured. They limit where data can travel, what a model may see, and who must approve an automated action.

HIPAA and business associate agreements

The HHS HIPAA Security Rule guidance sets administrative, physical and technical safeguards for electronic protected health information. For automation that means access controls for bot accounts, encrypted storage, and audit logs of what each bot touched.

Every vendor that processes that data, including a model provider, needs a business associate agreement. If a provider will not sign one, its API cannot see claim or chart text.

Minimum necessary and de-identification

Send a model only the fields the task needs. A denial classifier needs the reason code and a short note, not the full demographic record.

Redact identifiers before text leaves your boundary where you can, and keep the mapping on your side. This costs engineering time but narrows both the breach surface and the audit conversation.

Human approval and audit trails

Payer submissions create legal exposure, particularly around billing accuracy. Design the system so that a named person approves anything that reaches a payer, and every AI suggestion is stored with its inputs and the decision taken.

That record is what you will need if a payer or auditor asks why a claim was appealed or changed.

How do cost and payback in revenue cycle automation vary by claim volume?

Payback depends on how much manual work exists to remove, not on the technology chosen. Volume decides which approach is sensible, and Viithiisys scopes each build after a discovery call rather than publishing a rate.

Which approach fits which volume?

These bands are illustrative groupings for planning, not benchmarks from any survey or client data. Real organisations sit between them, and payer mix often matters more than raw claim count.

• Low volume (single clinic or small billing office). Start with off-the-shelf clearinghouse and PM-system features plus one targeted bot. The main cost is licences and set-up time. Payback shows up as hours saved on one or two repetitive tasks.
• Medium volume (multi-site group or regional biller). Start with API integration for eligibility and posting, and an AI-assisted denial worklist. The main cost is integration with the PM/EHR system and payer variety. Payback shows up as a lower denial backlog and faster follow-up.
• High volume (hospital system or large RCM vendor). Build the full pipeline: intake, coding assist, denials and reconciliation. The main cost is governance, testing, monitoring and exception handling. Payback shows up as reduced touch time per claim and fewer write-offs.

What should you measure first?

Before you buy anything, record these four numbers:

• Touch time per claim
• First-pass acceptance rate
• Denial rate by reason
• Days in accounts receivable

Without a baseline, any payback figure is a guess. Re-measure after each workflow goes live so you can see which change moved which number.

How are engagements usually scoped?

The common shape is a fixed scope for a first workflow, then a fractional or phased basis for the rest. A single denial or intake workflow is a sensible first slice because it is small enough to scope tightly. Agree the delivery timeline in discovery, once the payer mix and system access are known.

Big SI vs specialist partner

Large systems integrators suit programmes spanning dozens of sites and legacy platforms. A specialist partner suits a defined workflow, faster delivery and direct access to the engineers building it.

When does a big SI make sense?

Choose a large integrator when the programme crosses many entities, needs a global delivery bench or must sit inside an existing enterprise agreement. The trade-off is overhead: more layers, longer mobilisation and junior staffing on the build.

When does a specialist fit better?

A specialist fits when one workflow, such as denials, holds most of the value and the team can scope it tightly.

By our own count, Viithiisys has shipped software since 2007 across 500+ projects, working from Mohali with an office in Markham, Ontario. We do not cite healthcare client results here, and you should ask any vendor, us included, for references in your specific payer environment.

For the platform side, see our enterprise software development work and the wider solutions we build. Where billing systems need connecting, AI integration covers the plumbing.

What to ask in the first call

Put these questions to every vendor:

• Who writes the code?
• How are exceptions handled?
• What happens when a payer portal changes?
• How is model output logged?
• What is the plan to retire bots as payers adopt APIs?

If you want the workflow itself assessed before you pick a partner, our broken workflow assessment maps where your revenue cycle steps sit on the bot-versus-AI line and which one to automate first. It costs you a short conversation and a walk-through of the workflow, and you keep the findings whichever partner you choose. To discuss scope directly, use the contact form.