The CAQH Index, which tracks how the US healthcare industry runs its administrative transactions, found in its 2025 report that electronic prior authorisation had reached only about 40% adoption, leaving most authorisations tied to manual portals and faxes, with claim attachments lagging further behind still. From inside a claims operation, those two figures describe something concrete: the steps your examiners still work by hand, one claim at a time, and the place where most of the recoverable cost in a healthcare claims automation programme is hiding.
The claims operation that scales by examiner
Most payers and third-party administrators grew their claims capacity the only way that was ever available to them: by hiring examiners. When volume rose, the queue got longer, and the answer was another seat on the floor. That works until it doesn’t, and the point where it stops working is what we call the Manual Wall, the growth ceiling a service operation hits when throughput is set by how many trained people are on the queue rather than by the systems underneath them.
Healthcare claims hit that wall hard, because a claim is not a single transaction. It is a regulated case file that moves through eligibility verification, coding and edit validation, adjudication against plan and medical policy, and, when it goes wrong, denials and appeals. Each step has documentation requirements and its own compliance exposure. An examiner opens the file, checks member eligibility in one system, validates codes against an edit engine, pulls a clinical attachment from a portal, applies the plan rules, and records the decision. Multiply that by a book of business and the cost base has a shape, and the shape is a room full of people doing skilled clerical work.
This is the same structural problem we mapped in the claims-automation pillar and worked through for property and casualty in insurance claims automation. Healthcare is the same case-file pattern under a different regulator. The vocabulary shifts to adjudication, prior auth, and appeals, and the oversight shifts to CMS and HIPAA, but the operational signature is identical: volume is carried by examiners, and examiners scale in a straight line with volume.
Why the timing matters now
For most of the last decade a payer could treat manual claims handling as a cost of doing business and simply staff to it. That option is narrowing now, because two regulatory pressures are putting a clock on work that used to have none.
The first is the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F). For impacted payers, which include Medicare Advantage organisations, state Medicaid and CHIP programmes, and Qualified Health Plan issuers on the federally facilitated exchanges, it sets firm prior-authorisation decision windows, generally 72 hours for urgent requests and seven calendar days for standard ones, with operational requirements that began phasing in in January 2026 and a set of required FHIR APIs, including a Prior Authorization API, due by January 2027. Those windows do not stretch when your intake spikes. If a payer is holding prior-auth turnaround by adding reviewers, a volume surge forces a choice between more headcount and missed statutory deadlines.
The second is the pressure that has been building since the No Surprises Act came into force in January 2022. The Act routed a large and growing category of out-of-network billing disputes into federal independent dispute resolution, and the arbitration entities and health-plan teams handling that caseload have largely absorbed it by adding analysts. That is the manual wall arriving through the front door of a specific, regulated workflow, and it is exactly the kind of volume that automation is built to take.
Why do healthcare claims stay so manual?
They stay manual because the parts that resist automation are the parts everyone notices, and the parts that automate well are the parts nobody has bothered to separate out. A medical-necessity judgment on a complex case genuinely needs a clinician or a senior examiner. That truth gets generalised into “claims work is judgment work,” and the generalisation quietly protects a large volume of clerical work that needs no judgment at all.
The CAQH figures make the split visible. Claim status and payment have moved substantially to electronic transactions across the industry, while prior authorisation and attachments have lagged, still sitting well under half electronic by the 2025 Index. Prior auth and documentation are precisely the steps where a person logs into a payer portal, retypes clinical data, chases a missing attachment, and waits. That is data movement a person does because the systems were never connected, and none of it is medical judgment.
Which brings in the Human API problem: staff are the integration layer between the core claims platform, the clearinghouse, the coding and edit engine, and the various portals a single claim touches. An examiner re-keys the same member and provider data across several screens because the alternative, a real integration, was never built. That re-keying surfaces only as the examiner headcount you need and as the error rate on the days the queue runs long, never as a line item of its own.
What can you automate in a medical claim, and what stays with people?
The useful move is to walk the case file step by step and mark each step as clerical or judgment, because the automatable money is not spread evenly across the claim. It clusters in the clerical steps, and in healthcare those are unusually well defined.
Eligibility and benefit verification is rules-based lookup and reconciliation, and it automates cleanly. Coding and edit validation, running a claim against the edit engine and flagging mismatches, is high-volume pattern work that software handles better than a tired examiner at four in the afternoon. Document and attachment intake, classifying what arrived and pulling the data off it, is now well within reach of document AI. Prior-authorisation intake and status, the logging-in and portal-chasing that CAQH shows is still mostly manual, is the highest-value target of all because it carries both a heavy clerical load and a regulatory clock. Claim-status and remittance work, the “where is my claim” traffic, automates almost entirely.
What stays with people is the genuinely discretionary work: medical-necessity determinations on complex cases, contested adjudications where plan language is ambiguous, and the judgment calls inside an appeal. Automating the clerical wrapper is what gives those people the time to do that work properly, rather than spending most of the day on data entry wrapped around the decision.
What should a payer or TPA automate first?
Start where the volume is highest and the rules are clearest, because that is where automation returns the most and fails the least. In a healthcare claims operation, that combination points hard at prior authorisation and attachment handling. Both are high-volume, both are largely manual by the industry’s own numbers, and prior auth now carries the CMS decision clock on top. Fixing intake and data extraction at that step tends to release capacity across everything downstream, because the adjudication queue has been waiting on a person to assemble and key the file.
The discipline we apply to sequencing is simple, and it matters more than the tooling: we do not build an automation unless it removes enough manual load to pay for itself, and we prove that number before writing code. Surfacing exactly where the handling cost and the deadline risk concentrate is what we built our Profit Leak Diagnostic to do at Digital Forms. It is common to walk into an operation certain that adjudication is the bottleneck and find that the real drain is attachment handling two steps upstream, starving every queue behind it.
Once the highest-value target is clear, the first build should be deliberately narrow. We keep it to a single workflow that can go live in weeks and show a measurable result inside the engagement, which is what an Operations Sprint is for. A payer does not need an eighteen-month platform replacement to take the prior-auth intake queue off human hands. It needs one workflow automated and measured and running in production, with the freed capacity and the evidence to justify the next one.
How does automation help you hold CMS prior-authorisation timelines?
A statutory decision window is a promise about elapsed time, and elapsed time in a manual process is mostly waiting: waiting for an attachment to arrive, then waiting for a file to reach the top of a queue. Automating intake, classification, and data extraction compresses that waiting directly. The request is recognised, the file is assembled, and the clock is tracked from the moment the request lands, rather than from the moment a person happens to open it.
Automated timeline tracking is the quieter half of the benefit. Instead of a supervisor manually watching which prior-auth requests are approaching their 72-hour or seven-day limit, the system surfaces the at-risk files as an exception queue and leaves the rest to run. That turns a compliance clock the team currently babysits into something that only demands attention when a file is genuinely about to breach, which is also how you stay ready for the public reporting the rule phases in.
Automation or a new claims platform?
When the manual load becomes obvious, the instinct is often to blame the core claims platform and start shopping for a replacement. Sometimes the platform really is the constraint. More often a platform migration and a case-file automation programme answer two different questions, and buying the first does not deliver the second. A new adjudication system still needs someone to read the clinical attachment, still needs prior-auth requests pulled from payer portals it does not control, and still leaves the examiner bridging between the clearinghouse and the edit engine. Unless the surrounding manual work is automated on purpose, a migration can move the Human API problem from an old screen to a new one and call it progress.
The practical takeaway is that automating the claim case file is worth doing on its own timeline, whatever is or is not happening with the platform. The work that consumes examiner hours lives in the gaps between systems, and closing those gaps is a separate project from replacing any single system.
What this looks like in a real operation
Take a mid-market TPA administering health and workers-comp claims, described as a pattern rather than a named client. The adjudication floor is staffed to peak volume, examiners spend a large share of the day on attachment retrieval and portal logins rather than on adjudication decisions, and a team lead spends part of every day manually checking which prior-auth requests are close to their deadline. A recent uptick in caseload has already put another hiring round on the table.
Automate attachment intake and data extraction first, and the examiner’s day changes composition: the clerical load shrinks and the same headcount clears more files, so the hiring conversation pauses. Add automated prior-auth intake and timeline tracking, and the team lead’s manual deadline-watch becomes an exception queue that surfaces only the files at genuine risk. In our experience, the majority of the hours in a routine claim are clerical rather than clinical, which is why moving that layer to software is what lets throughput climb while headcount holds flat. The exact figures vary by book of business, and any hard number a payer sees quoted should be treated as illustrative until it has been measured against their own operation.
Where a payer should start
If this is recognisable, the first move is measurement, ahead of any platform decision or hiring approval. Get an honest count of where examiner hours actually go across the claim, which steps carry the regulatory clock, and what a single claim costs to handle end to end. That number is usually the thing nobody has, and putting a figure on the cost of manual claims handling is what makes the sequencing decisions obvious.
From there the order follows the evidence rather than the sales pitch: automate the highest-volume clerical step first, keep the first build small enough to land in weeks, measure it against the baseline you captured, and decide the next step from the result. The instinct to hire against a backlog is understandable, and we have written before about why adding examiners does not clear it. The reason is structural: headcount added to a manual process scales the cost of the process, not the capacity of the system.
The regulatory clock on prior authorisation is not going to slow down, and neither is the caseload that runs through it. The question worth sitting with is whether the next volume increase reaches your operation as another hiring plan or as a workflow that can absorb it.
