A billing manager at a multi-specialty group we work with keeps a spreadsheet of where her team's hours go. The largest single line is not appeals or coding questions. It is checking claim status on payer portals: log in, search the claim, read the screen, type the result into the practice management system, next claim. Her team of six spends about 45 hours a week doing it. When a vendor demonstrated a software robot doing the same thing overnight, she was ready to sign that afternoon.
We asked her to wait a month. The difference between an automation that returns 40 hours a week and one that becomes a second job for her most technical biller comes down to which tasks she picks, how exceptions are handled, and credential and payer terms questions the demo never raised.
This piece is a practical guide to RPA in medical billing: what robotic process automation actually is, which billing office tasks it handles well, which ones break, what to ask about compliance, and how to run a pilot that produces a real answer in 60 days.
Key takeaways
- RPA is software that operates your existing applications the way a person does, by clicking, typing and reading screens; it follows rules and does not exercise judgment, which makes it good at repetitive portal work and poor at anything that needs a decision.
- Claim status checks, eligibility lookups on portals that lack a full electronic response, remittance downloads and rule-based posting are the tasks that pay back; denial appeals, coding and anything behind a CAPTCHA or per-login multifactor prompt are the tasks that do not.
- Every bot needs its own user credentials, a business associate agreement with the vendor, an audit log and a written check of each payer portal's terms of use before it touches protected health information.
- Payer interoperability rules taking effect January 1, 2027 will give many payers standard APIs for prior authorization and claims data, so a bot built today for those tasks should be treated as a bridge, not a permanent fixture.
What RPA is and is not
Robotic process automation, or RPA, is a category of software that automates work by driving other software through its user interface. A bot logs into the payer portal with a username and password, types a claim number into the search box, waits for the page, reads the status field and writes the result into your practice management system, exactly as a biller would. It runs on a schedule or on a trigger, it keeps a log, and it stops when it sees something it was not programmed for.
It is not artificial intelligence, although vendors increasingly bundle the two. A rules-based bot does exactly what it was told; it does not decide whether a denial is worth appealing or which CPT code fits a note. It is also not integration. If your clearinghouse already offers a 276/277 claim status transaction (the electronic inquiry and response) or a 270/271 eligibility transaction that returns what you need, a bot doing the same work on a portal is the slower and more fragile choice.
The tasks that work
The best RPA candidates share four traits: high volume, stable rules, a stable screen, and a low cost of error. In billing offices, that points to a short list.
| Task | Fit for RPA | Why |
|---|---|---|
| Claim status checks on payer portals for claims over 30 days with no remit | Strong | High volume, identical steps, result is a status code the bot copies |
| Eligibility verification on portals where the 271 response lacks benefit detail | Strong | Runs the night before; exceptions (inactive, no match) go to a work queue |
| Downloading remittances and EOBs from portals that do not send electronic remits | Strong | Scheduled, file-based, easy to verify |
| Prior authorization status checks and reference number capture | Good | Stable steps; the request itself still needs a person |
| Posting patient payments from a lockbox or payment vendor file | Good | Rule-based matching on account number and amount |
| Small-balance adjustments under a written policy threshold | Good | Clear rule, low value per error |
| Denial appeals and reconsiderations | Poor | Requires judgment, reading notes and writing an argument |
| Coding or charge review | Poor | Clinical judgment; error cost is a compliance problem |
| Anything behind a CAPTCHA or a one-time code on each login | Poor | Bots must not bypass bot-detection, and sharing a person's authentication device breaks the audit trail |
Here is a worked example for the claim status task. The group in the opening has about 2,400 claims a month that pass 30 days without a remittance and need a status check. A biller averages four minutes per check, including logging the result: 160 hours a month across the team. A bot runs each check in about 30 seconds and hits an exception it cannot resolve on about 15 percent of claims (claim not found, portal timeout, an unexpected status). That leaves 360 exceptions for a person to work at four minutes each, or 24 hours. Net return: roughly 136 hours a month, before the time spent maintaining the bot. Even after maintenance, that is most of a full-time position redirected to appeals, which is work that actually brings money in.
The tasks that break
Bots break when the screen changes. Payer portals redesign pages, move buttons and rename fields several times a year, and each change can stop a bot cold until someone updates it. A practice with bots on eight portals should expect something to break most months. Ask each vendor who repairs breaks, at what cost, and how fast, and get the answer in writing.
Bots also break on judgment. A denial worklist bot that files a reconsideration for every CO-197 (precertification absent) will file some that should have been written off and miss the ones where the authorization exists under a different number. Our position is that anything involving a decision about a claim stays with a person, and the bot's job is to put the information in front of that person faster. The denial management work our team does relies on people reading remits and notes; the automation feeds the queue.
The third failure mode is unstructured documents. Reading a scanned paper EOB with optical character recognition and posting from it sounds like automation, but OCR misreads amounts and account numbers often enough that every posted line needs verification, which erases the saving.
The compliance questions to ask before signing
A bot that logs into payer portals and reads patient data is handling protected health information, and the vendor who hosts or maintains it is a business associate under HIPAA. Get a business associate agreement signed before any build starts. Ask where the bot runs (your server, the vendor's cloud, or a workstation in your office), where credentials are stored and how they are encrypted, and whether the bot's actions are logged in a way you can review.
Give every bot its own user account in every system it touches, with the minimum access the task needs. A bot running under a biller's login destroys the audit trail: nobody can tell later which actions were hers and which were the machine's, and if she leaves, the bot leaves with her password. Payer portals are the hard case, because many require multifactor authentication tied to a person's phone. Do not route a person's one-time codes to a bot; if the portal offers a service account or an API, use that, and if it offers neither, the task may not be automatable on that portal.
Read each portal's terms of use. Several payer and clearinghouse portals restrict or prohibit automated access, and a bot that violates the terms can get the practice's account suspended, which is a far larger operational problem than the hours you were saving. When the terms are unclear, ask the payer's provider relations contact in writing. And check your own contracts: some practice management vendors restrict scripted access to their systems too.
Where the payer APIs fit
The reason to treat portal bots as a bridge is a rule CMS finalized on January 17, 2024, the Interoperability and Prior Authorization final rule. It requires Medicare Advantage plans, state Medicaid and CHIP programs, Medicaid managed care plans and qualified health plans on the federal exchange to implement standardized APIs, including a prior authorization API and a provider access API, with most of the API requirements taking effect January 1, 2027. The same rule already requires those payers, starting in 2026, to decide standard prior authorization requests within seven calendar days and expedited requests within 72 hours, and to give specific denial reasons.
When those APIs are live and your practice management or clearinghouse vendor connects to them, a bot that scrapes authorization status off a portal becomes unnecessary for those payers. Plan the investment accordingly: automate the portal tasks that hurt now, and ask your billing system vendor what its API roadmap looks like before you build anything elaborate.
A 60-day pilot that produces an answer
Pick one task from the strong column, on one or two portals, with clear volume. Claim status is the usual choice. Before the bot runs, measure the manual baseline for two weeks: how many checks, how many minutes each, how many resulted in an action. Write the rules the bot will follow and, more importantly, the rules for what it does when it is unsure: stop, log, and put the claim in an exception queue with a screenshot. Build the exception queue into your existing worklist so nobody has to check a second system.
Run the bot in parallel with the manual process for two weeks, comparing results claim by claim, then let it run alone for four weeks. Track four numbers weekly: checks completed, exception rate, number of times the bot stopped because the portal changed, and hours the team actually redirected. At day 60, you will know whether the exception rate is falling as rules are refined, whether the portal has been stable, and whether the saved hours are real. If the exception rate is stuck above 25 percent or the bot broke more than twice, that task or that portal is not a good fit, and the pilot has done its job by telling you so cheaply. Practices that use our billing service get this automation as part of the workflow rather than as a project.
Questions we hear
Is RPA the same as the AI tools our EHR vendor is advertising?
No. RPA follows fixed rules through the user interface. AI tools make probabilistic judgments, such as suggesting a code or drafting an appeal. Some products combine the two. Evaluate the rules part on reliability and the AI part on accuracy against your own records, and never let either post a claim or a code without a person accountable for it.
Do we need an IT person on staff to run bots?
You need someone who owns the bots: watches the logs, triages exceptions and coordinates repairs with the vendor. In a small practice that is usually a senior biller with a few hours a week, not a developer. If the vendor cannot make the tool manageable by that person, it is the wrong vendor for a small practice.
Will payers block our bot?
Some will, either through terms of use or through technical controls. Ask before building, use service accounts where offered, and keep the bot's request rate at a human pace. A bot hammering a portal at machine speed is the fastest way to lose the account.
What to do this week
- List your team's repetitive portal tasks with weekly hours and volume, and mark which ones already have a working 276/277 or 270/271 transaction through your clearinghouse.
- Pick the single highest-hour task without an electronic alternative as the pilot candidate and start the two-week manual baseline.
- Pull the terms of use for the two portals involved and read the sections on automated access.
- Ask two vendors for a BAA, a description of credential storage, a sample audit log and their average repair time when a portal changes.
- Ask your practice management vendor, in writing, when it will connect to payer prior authorization and claims APIs under the 2027 requirements.
