Council Post: RCM Stacks Are Digital: Why Are Billers Doing Everything By Hand?

Oleg Nesterov is the founder and CEO of MindK, which builds AI agents and custom software for U.S. healthcare revenue cycle management.

getty

Healthcare revenue cycle management (RCM) is a solved problem if you believe stats from vendors. Eligibility runs 96% electronically by CAQH's count, and claims often move down standardized rails. Ads now sell AI in revenue cycle management as the path to an "autonomous" back office. But walk onto any billing floor, and you may see people log in to payer portals by hand, rekey data that already exists and work denials one at a time.

This is true for all tasks that require both judgment and keystrokes. Prior auth is only 40% fully electronic. Attachments sit at 24% in medical spaces and are falling. Appeals, follow-ups and exceptions often don't get a standard transaction at all. Every day, I talk to medical billers who verify benefits mostly by hand.

In this space, I've found that everything with a standard transaction gets automated, and everything that requires deciding and then acting gets a work queue and a person to sit in it.

AI arrived in revenue cycle management with a promise of change, but it did not reach execution.

A coordination system tells a person what to do. An execution system does it. RCM leveraged the first for two decades and called it the second. The AI revolution promised to change all of that. According to MGMA, 68% of medical groups reported adding or expanding AI tools in 2025. In another MGMA poll with a different set of 260 respondents, 68% said AI had not led them to redesign a single role or change staffing.

The reason for this is in what these tools can actually do. Most RCM AI recommends. It scores a denial by the likelihood of overturn, drafts the appeal letter and flags a documentation gap before submission. Then it routes the task back to a person to log in and finish. The human still produces the keystrokes.

Coordination has real value. But it does not free your staff from logging in to up to 11 or more portals a day. Every forced login is software admitting it cannot take the action itself and handing it to someone who can. A single prior authorization can mean checking eligibility in portal one, submitting in portal two, reading status in portal three and documenting in an EHR that connects to none of them. This fully electronic process can still take, from what I've seen in the industry, 10 minutes or more of manual work.

This is why a practice can roll out AI across every function and end the year with the same number of billers logging in to the same portals. Anywhere a workflow ends with a human typing into a payer's website, the AI advised and a person executed.

You still can't out-appeal the payer's AI by hand.

On the other side, payers have already automated decisions. According to the 2025 CAQH Index, more than half of health plans now use AI in administrative workflows, against roughly a quarter of providers. A denial engine reads a claim, applies current policy and returns a decision in seconds. On the provider side, the response is a person opening a portal, reading the denial reason, pulling the record and assembling an appeal by hand.

According to HFMA, up to 65% of denied claims are never reworked. There are more defensible denials than there are biller-hours to defend them, so the appeal window closes before anyone reaches the claim.

This is why "appeal more aggressively" is not a plan. A team that doubles its appeal volume by working nights still loses ground if denials arrive faster than any human queue can get through them.

The fix is an execution layer, and being 'agentic' does not automatically make it happen.

The alternative is an execution layer that acts. It logs in to the portal, reads the denial or the policy, decides what the claim needs and takes the next step itself, up to and including placing the call to the payer. The work that used to end at a human can then end at a completed action.

A real execution layer works both ends of the denial. An "agentic" solution is not an execution layer unless it meets the following criteria:

• It must log in to portals and deal with credentials, two-factor authentication and session timeouts—the unglamorous 80% of the job.

• It must read explanation-of-benefits files, remittances, denial letters and payer policy PDFs—all of it unstructured, inconsistent and frequently scanned.

• It must decide, appeal, correct, resubmit or write off—under payer-specific rules that change every month.

• It must act, including on the phone. A meaningful share of payer work still ends in a phone call, and an agent that cannot call a payer does not help billers.

"Agentic" on a vendor's slide does not guarantee any of this. Most tools carrying the label still read and recommend, then hand the action back to your biller.

There is a test any buyer can run inside any demo: Count how many logins the product removes and ask whether it changes the org chart or simply hands your team a better queue. If the headcount and the logins look the same after you go live, you bought a dashboard with a new adjective.

The clock is ticking.

There is a deadline attached to this. CMS-0057-F requires payers to expose FHIR APIs, including for prior authorization, by January 1, 2027. That converts execution from brittle screen-scraping into a clean engineering problem. Being ready to consume those APIs on day one is a huge opportunity. Given build lead times, that readiness is decided now, not in December 2026.

So, change the question you ask of AI in healthcare revenue cycle management. Stop grading it on what it knows and start grading it on what it closes. Your stack already has a nervous system. It is time it grew hands.​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?