The Healthcare Eligibility Paradox

The healthcare industry standardized the electronic eligibility check more than two decades ago, as part of HIPAA's administrative simplification push. A provider sends a 270 inquiry, the payer returns a 271 response, and the exchange takes seconds. By the numbers it worked: CAQH's latest Index puts electronic adoption of eligibility verification at 96%, the highest of any administrative transaction in healthcare.

Now hold that number next to two others. Registration and eligibility errors are the largest single category of claim denials, about a quarter of them. And CAQH estimates the industry still leaves $18.4 billion a year on the table in eligibility verification, a figure that grew 12% last year while denial rates kept climbing.

A transaction that is 96% electronic should not be the leading source of denials. We never understood why it is until we started running eligibility checks in production for our customers and saw where the work actually goes.

What the 271 response misses

The eligibility transaction answers "does this member have active coverage with this payer." The question a provider actually needs answered is closer to "can we treat this patient, under this program, with this provider, and get paid for it."

For one of our customers, a care coordination organization working with Medicaid populations, "eligible" means the patient exists in the payer's system, coverage is active for the right plan, they are not enrolled in a D-SNP or another program that reassigns responsibility for their care, and they are not already assigned to a competing provider. The 271 answers the first two conditions on a good day. The rest is simply not in the transaction. It lives in the payer's portal, in fields the standard was never extended to carry.

At scale this gap is the whole job. One customer runs 60% of verifications through APIs and does the remaining 40% by hand in portals, and it is the 40% their back office is staffed for. Another ran multiple eligibility API vendors on the same patients and got different answers from each, so a human had to adjudicate anyway.

There is a general lesson here about standards in healthcare: adoption statistics measure whether the pipe exists, not whether what flows through it settles the matter. The 270/271 pipe exists nearly everywhere. It settles maybe half the question, so the industry built a second system on top, made of humans, browser tabs, and payer portals. That second system is invisible in the adoption numbers.

Why the obvious fixes stall

Every operations leader reaches for the same three things, in roughly the same order.

First, more APIs. Correct as far as it goes, but the payers where eligibility is most nuanced, Medicaid managed care above all, are precisely the ones with the thinnest coverage. And there is a nastier trap: when teams cannot trust the API's answer enough to bill against it, they re-verify by hand, paying for the automation and the manual process it was supposed to replace.

Second, RPA, which is largely the same thing sold at enterprise prices. Traditional automation assumes the interface holds still, and payer portals do not: captchas, two-factor codes, session limits, redesigns that ship without notice. One customer came to us losing roughly 30% of automated runs to login and workflow failures.

Third, more people, usually offshore. This is the fix that actually stuck, and its success is the problem: outsourcing made the gap economically tolerable, so nothing ever forced it closed. Anyone who has run a BPO relationship knows what it costs though. Every process change becomes a retraining project for a team twelve time zones away, applying rules written against US insurance concepts they may not fully understand. And people at volume make people mistakes: a misread screen, a skipped step, a rule applied from memory a month after it changed. So costs scale with volume, knowledge leaves with attrition, and the overhead keeps compounding into the hundreds of billions the US system spends on administration.

All three fail the same way. The ground truth sits in a website built for a human, and the actual work is reading that screen and applying your rules to what it says. APIs cannot see the screen, scripts cannot survive it changing, and people cannot apply rules perfectly ten thousand times in a row.

Rules at scale

That is what AI actually changes. An agent driving a browser can log in, run the search, read the result, and apply the rules exactly as written, without getting tired and without forgetting last month's update. For the first time the full job is within reach of software, not just the message-passing around it.

To be concrete about how we solve this at Champ: we do not rip out the API layer. Where a clearinghouse or payer API returns an answer a customer can confidently bill against, we use it, because it is the cheapest check there is. Everything else routes to browser agents that work the portal the way a person would, log in, search, read the screen, decide. For some customers that means a blended pipeline, APIs first with portal agents catching the fallout the APIs cannot settle. For others, usually those with a Medicaid-heavy payer mix, the APIs are more noise than signal and every check goes straight to the portal. Either way, the result comes back in one shape: the same answer format and the same accuracy standard, regardless of which source produced it.

But the naive version of this pitch, point an agent at the portal and let it improvise, does not survive production. The architecture around the model matters more than the model. In practice our eligibility workflows are mostly not AI: browser steps run scripted first (fill these fields, click search, snapshot the page) and hand off to an agent only when the page stops matching expectations. The model gets exactly one decision, made from what the browser captured, and its answer has to come from a fixed set of outcomes rather than free text. Outcomes you can route on, audit, and hold to an accuracy bar.

Just as important is what happens when a run fails, because some always do. Every check is a case with a status, including ones that mean "a human needs to look," with a recording of what the agent saw. And no workflow starts out trusted: new ones run with human review or in shadow mode against the existing process until measured accuracy says otherwise. Our longest-running eligibility workflows have been through dozens of revisions: they grew as the portals taught us their edge cases, then shrank as those lessons hardened into fewer, more precise steps. That shape, expand, then harden, then shrink, is the signature of automation that is actually working. Anyone whose healthcare automation worked on the first try has not run it at volume yet.

The beachhead

Eligibility sits at the front of the revenue cycle, where an error is cheapest to catch and most expensive to miss; a wrong answer compounds into a denied claim, an incorrect first bill, and sometimes a lost patient. That same position makes it the ideal first workflow to hand to software: high volume, explicit rules, and output you can verify against your current process before you trust it.

The real point is bigger. The last era of healthcare administration made transactions electronic, succeeded all the way to 96%, and it was not enough, because the work around the transaction stayed human. The next era is about automating that work. Prior authorization, benefits verification, claims follow-up: they all have the same shape, and they will fall in the same order, to teams that treat this as an operations discipline rather than a demo.

If some version of that second system, humans adjudicating payer websites at scale, is running inside your organization, bring us one workflow. We will show you what can be automated, what still needs a person, and what it takes to run it safely in production.