Prior Authorization Automation Problems: The 7 That Waste Staff Days, and How to Avoid Them

Why does the scope get set at automating submissions so often?

Because submission is the visible step. Everyone can picture a form going to a payer, the standards exist on paper, and a demo of an automated submission looks like progress. So the project gets scoped around channels.

Submission is not the job. Chasing is the job, and evidence assembly is the cost. A case sits with a payer, nobody proactively tells you anything, and a coordinator checks a portal every morning while the service stays unscheduled. Meanwhile the reviewer is reading charts. A build that perfects submission and ignores both leaves your headcount exactly where it was, which is the outcome most disappointed authorization projects actually produced.

The fix is scope order. The first release should cover the requirement rule engine, case management with urgency based queues, clinical evidence retrieval with human confirmation, and submission through only your two or three highest volume channels. That is the $85,000 to $170,000, twelve to eighteen week shape in our delivery experience. Broad channel coverage, appeals and analytics belong in phase two, because they are additive once the case model is stable and they are a distraction before it is.

What goes wrong when the payer requirement matrix becomes a rule set?

The matrix is a shared document maintained from denials, and it is wrong in two directions at once.

Rules were added when a denial taught someone something, so the document over-represents whatever went badly recently. Rules that were true three years ago are still there because nothing prompts a removal. Nobody records where a rule came from, so a requirement sourced from a payer bulletin sits beside one inferred from a single denial with no way to tell them apart. And the requirement depends on the plan product line rather than the payer name, which most matrices collapse, so a rule that is correct for one product gets applied to another.

The failure is importing it as truth. What you get is a system that confidently tells staff no authorization is needed, which produces services delivered without one and written off after the fact.

What works is dating every rule with a source, an owner and a confidence level, so a bulletin sourced rule is treated differently from an inferred one, and then closing the loop: every denial for no authorization on file automatically raises a rule review. The matrix then improves from your own outcomes rather than from somebody remembering to check a payer website. Where a payer exposes a coverage requirements service, use it as primary and keep your local rule as fallback rather than the other way round.

Why do payer portal and chart integrations break after launch?

Portals break constantly and by design. Screen scraping a payer portal is tempting because it removes a login from someone's morning, and it fails on every layout change while some payer terms of use restrict it outright. Reserve it for a payer whose volume genuinely justifies the maintenance, and tell your team plainly that it will break rather than letting them build a routine around it.

Chart integrations break more quietly and more expensively. Evidence retrieval is only as good as chart access, and access degrades in ways nobody watches: a scanned document type stops being indexed after an upgrade, a specialty department moves onto a different instance, an interface starts delivering notes with the narrative stripped. Retrieval keeps running and keeps finding less, and because the output is candidate evidence rather than an error, nobody notices for a month.

The defence is coverage monitoring rather than error monitoring. Track how often retrieval finds candidate evidence per criterion and per department against its own history, and alert on a drop. Then keep one internal case model with pluggable submission adapters underneath, so the clinical and administrative work stays identical regardless of channel. When a payer stands up a standards based interface, you add an adapter and nothing above it changes. That is the actual insurance policy against a transition that will happen unevenly across your payer mix for years.

What happens when authorization consumption against claims is not covered?

You win the authorization and lose the money anyway, which is the most demoralising failure mode in the category because your team did everything right.

An approval carries an authorization number, an approved unit count, a date range and sometimes a required site of care. If any of those does not travel correctly onto the claim, the service is denied after it has been delivered. Units are the classic case: a course of therapy authorised for twelve visits, fourteen delivered, two written off, discovered at remittance. Site of care is the quiet one, where a procedure authorised for an outpatient setting is performed somewhere else because the schedule moved.

Most builds stop at approval because that is where the authorization team's responsibility ends organisationally. The team that fought for the authorization is not the team that bills, so nobody owns the handoff and no system spans it.

Treat 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 whole build and it is routinely left out of first releases because it looks like a billing feature.

Should you build custom or configure what you already own?

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 building would be a distraction from hiring one more person who can actually see patients. This is the right answer for a lot of organisations and we say it often.

Waystar makes sense if you want authorization inside a broader revenue cycle stack you already run. Cohere Health is a rational purchase on the plan side for the service categories they focus on. Myndshft is aimed at determination and benefit data. None of them are weak products, and none of them can know your chart well enough to find six months of conservative treatment documentation in it, or know which of your service lines is actually bleeding.

Build when authorization is concentrated and expensive: a health system where imaging, orthopaedics and infusion generate most of the volume, an ambulatory surgery network, or a specialty group with recurring courses of therapy. The signal we look for is a headcount: once four or more people work authorization full time, the arithmetic favours building, and the softer benefit of not losing the rule knowledge when one of them resigns is worth more than the labour saving.

How do hidden costs get into the quote?

Electronic health record instance count is the first, and it is rarely asked about. Evidence retrieval is only as good as chart access, so three instances after two acquisitions is three integrations rather than one, and a quote written without that question is incomplete.

Service line breadth is the second. Imaging, surgery, infusion, durable medical equipment and behavioural health each have different criteria shapes, and a rule engine that handles one well does not automatically handle the others.

Payer mix is the third, because every additional submission channel is real work and the long tail of low volume payers costs more per case than the top three. Appeals and peer to peer are the fourth and they roughly double the case model, so they belong in a separate phase with their own price.

Then two that never appear. Rule set maintenance, which is a continuing operating cost with a named owner rather than a project deliverable. And the parallel running period, where staff work the old way on a sample alongside the new system, which is what surfaces the rules nobody wrote down and needs to be planned and staffed rather than absorbed.

What separates a build that works from one that fails here?

Ask how they will find evidence of failed conservative therapy in a chart. If the answer covers structured data only, they will automate the easy tenth. What you want is retrieval over narrative notes and scanned documents, presenting each candidate with its source note and date, letting a human accept or reject it into the packet. The model locates, it never asserts, and a person confirms everything before it leaves the building. That is the most defensible use of language models anywhere in the revenue cycle precisely because accountability stays with the reviewer.

Ask how the case queue is ordered. Submission date is the wrong answer and it is the default in most systems, which is why urgent cases age. The right ordering combines clinical urgency with scheduled service date, so a case for a procedure booked on Thursday outranks an older case for something unscheduled. That requires the system to see your scheduling data, and it is precisely the connection packaged tools do not have.

Ask what happens when a payer stands up a standards based interface. The right answer is that submission is an adapter behind a stable internal case model, so the change is additive rather than a migration.

Then settle ownership in writing before kickoff: the code, the infrastructure and specifically the accumulated payer rule set. At Digital Heroes the client owns the repository from the first commit. The rule set in particular is built from your own denials over years, and it should never sit inside a vendor product where you cannot take it with you.