Prior Authorization Automation: Why Your Staff Still Log Into Nine Payer Portals Every Morning

Why prior authorization automation stalls at the last mile

Walk into an authorization team at 7:30 in the morning. Two people are on hold with payers. One is logged into a portal that requires a security token she has to text a colleague for. A fourth is opening a fax confirmation to check whether yesterday's submission went through, because the payer's portal shows nothing and the fax is the only receipt. On the whiteboard is a list of cases with names and dates, because the practice management system has an authorization field but no concept of a case in progress.

Nothing here is a technology gap in the abstract sense. Every one of these steps has a modern alternative on paper. The X12 278 transaction has existed for years. The Da Vinci implementation guides describe coverage requirements discovery, documentation templates and rules, and an authorization submission flow built on FHIR. The Centers for Medicare and Medicaid Services finalised a rule requiring impacted payers to stand up a prior authorization application programming interface and to meet decision timeframes, with the interface obligations landing in 2027. All true, and none of it changes what your team does tomorrow morning, because the payer on the other end of this specific case has not implemented any of it and will not for a while.

That is the honest framing for this category. Automation here is not about waiting for standards. It is about absorbing a messy external world so your staff stop being the integration layer. Availity, Cohere Health, Waystar and Myndshft each attack a slice of that. Availity is strong where its payer network is strong. Cohere works from the plan side on specific service lines. Waystar bundles authorization into a broader revenue cycle stack. Myndshft focuses on determination and benefit data. What none of them can do for you is know your electronic health record well enough to find the six months of conservative treatment documentation buried in a physical therapy note, or know which of your service lines is actually bleeding.

Problem 1: knowing whether an authorization is required at all

Before anything else, someone has to answer a question that sounds trivial: does this specific procedure, for this specific patient, on this specific plan, need an authorization. The answer depends on the code, the place of service, the plan product line rather than the payer name, the member's benefit design and often the date, because requirement lists change quarterly.

The universal workaround is a shared document. Someone on the team maintains a matrix of payers and procedures, updated when a denial teaches them something. That document is out of date, it lives in one person's head as much as in the file, and it produces two failure modes at once: authorizations submitted that were never required, which wastes days, and services delivered without one that was, which becomes a write off.

What a custom build does: turn that document into a dated rule set with a source and an owner per rule. Every rule carries an effective date, a citation to where it came from, and a confidence level, so a rule sourced from a payer bulletin is treated differently from one inferred from a denial. Then close the loop: every denial for no authorization on file automatically raises a rule review, so the matrix improves from your own outcomes rather than from someone remembering to check a payer website. Where a payer does expose a coverage requirements service, use it, and treat your local rule as the fallback rather than the primary.

Problem 2: the clinical evidence the payer wants is buried in the chart

A payer asking for documentation of failed conservative therapy before an imaging study or a surgery is asking for something that exists. It exists as a sentence in a progress note from four months ago, a physical therapy discharge summary scanned as a PDF, and a medication history that shows two trials of anti inflammatories. Assembling that is a person reading a chart, and it is the single largest labour component of the whole process.

Generic automation tools cannot do this because they do not have chart access at the level required, and the packaged integrations that do exist tend to pull structured data: problems, medications, allergies. The evidence a utilisation reviewer wants is usually narrative.

What a custom build does: a retrieval step over the patient's own record that finds candidate evidence for the specific criterion, presents it to a human with the source note and date visible, and lets them accept or reject each item into the packet. This is the most defensible use of language models in the whole revenue cycle, precisely because a human confirms every item before it leaves the building and the model never asserts anything, it only locates. In our builds the time to assemble a packet drops sharply while the accuracy of what is submitted goes up, because the reviewer sees the actual note instead of retyping a summary from memory.

Problem 3: submission channels are a museum

One payer takes an X12 278. One has a portal with a token. One accepts a fax and returns a fax. One requires a phone call for anything on a named list of procedures. One has a modern application programming interface and a sandbox that works. Your process has to handle all of them and your staff currently do that by being the router.

What a custom build does: one internal authorization case with pluggable submission adapters underneath. The clinical and administrative work is identical regardless of channel, and the channel is a property of the payer product with a fallback chain. When a payer stands up an interface under the newer rules, you add an adapter and the workflow above it does not change. That is the actual insurance policy against a transition that will happen unevenly across your payer mix over several years.

One warning from experience: portal automation via screen scraping is tempting and it is fragile. It breaks on every layout change and some payer terms of use restrict it. Use it only where the volume justifies the maintenance and be explicit with your team that it will break.

Problem 4: status chasing is the actual labour

Submitting is not the job. Chasing is the job. A case sits with the payer, nobody tells you anything, and the service is unscheduled while a coordinator checks a portal each morning.

Packaged tools return a status where the payer exposes one. Where the payer does not, they show you the last known state, which is what your team already has.

What a custom build does: make waiting a first class state with an expected response clock derived from the plan's own stated timeframes, escalation rules when the clock is breached, and a queue ordered by clinical urgency and scheduling pressure rather than by submission date. A case for a patient with a procedure booked on Thursday should outrank a case submitted a week earlier for something not yet scheduled, and no packaged tool knows your schedule. Feed authorization state back into scheduling so a booking without a valid authorization is visible to the scheduler at the moment of booking rather than discovered on the morning of the procedure.

Problem 5: the authorization is approved and nobody downstream learns

An approval arrives with an authorization number, an approved unit count, a date range and sometimes a specific site of care. If any of that is not carried onto the claim correctly the service gets denied anyway, and the team that fought for the authorization is not the team that bills. Units are the classic failure: a course of therapy authorised for twelve visits, fourteen delivered, two written off, and nobody noticed until the remittance.

What a custom build does: hold the authorization as a consumable object. Approved units decrement as services are delivered, the date range is checked against service dates, the site of care is checked against where the service was actually performed, and a threshold alert fires before units run out rather than after. This is one of the fastest paybacks in the build.

What a prior authorization build costs and how long it takes

A first release covering the requirement rule engine, case management with urgency based queues, clinical evidence retrieval with human confirmation, and submission through your two or three highest volume channels runs $85,000 to $170,000 and ships in 12 to 18 weeks in our delivery experience. A full platform adding broader channel coverage including standards based submission, appeals workflow, authorization consumption tracking against claims, scheduling integration, payer performance analytics and a plan side determination engine runs $220,000 to $500,000 phased over 8 to 14 months.

What drives cost up on the provider side: the number of distinct electronic health record instances, because evidence retrieval is only as good as chart access. Service line breadth, since imaging, surgery, infusion, durable medical equipment and behavioural health each have different criteria shapes. Payer mix, because every additional submission channel is real work. And whether you want peer to peer and appeals in scope, which doubles the case model.

On the plan side the drivers are different: criteria authoring and versioning, delegated vendor arrangements for specific service categories, and the decision timeframe and interface obligations under the newer federal rules.

What keeps it down: one service line with concentrated volume, the three payers that generate most of your authorizations, and no appeals in phase one.

Build versus buy, and when buying is right

Buy if you are a small or mid sized practice with moderate volume and a payer mix well covered by a network product. Availity through its payer connections, or the authorization module in whichever clearing house you already use, gets you most of the benefit for a fraction of the cost, and a build would be a distraction from hiring one more person who can actually see patients.

Build when authorization is concentrated and expensive. A health system where imaging, orthopaedics and infusion generate most of the volume, an ambulatory surgery network, a specialty group with recurring courses of therapy, or any organisation where the requirement matrix is a document and the clinical evidence pull is the bottleneck. The specific signal we look for is a full time equivalent count: once you have four or more people whose job is authorization chasing, the arithmetic favours building, and the softer benefit of not losing that knowledge when someone resigns is worth more than the labour saving.

On the plan side, build when your utilisation management criteria are genuinely proprietary or when you are managing a service category no vendor covers well. Otherwise Cohere Health for the categories they focus on is a rational purchase.

How to choose a developer for prior authorization software

Ask how they will find evidence of failed conservative therapy in a chart. If the answer only covers structured data, they will build a system that automates the easy ten percent and leaves the labour untouched. You want retrieval over narrative notes with the source document shown to a human before anything is submitted.

Ask how their case queue is ordered. Submission date is the wrong answer. Clinical urgency combined with scheduled service date is the right one, and it requires them to have thought about your scheduling system.

Ask what they will do when a payer stands up a standards based interface in two years. The right answer is that submission is an adapter behind a stable internal case model, so the change is additive.

Ask who owns the code, the infrastructure and the accumulated payer rule set, and settle it in writing before kickoff. At Digital Heroes the client owns the repository from the first commit. The rule set in particular is an asset you build from your own denials over years, and it should never sit inside a vendor's product where you cannot take it with you.