Operations
What Prior Authorization Software Automates
Quick Answer
Prior authorization software reliably automates submission, status tracking and some requirement checks. It rarely manages what happens after approval, when the authorization must match the units, dates, location and rendering provider on the claim, and that gap is where multi-location practices lose money. For most groups the practical path is to buy the submission rail, pilot it against their own payer mix, and track every approval in a ledger they control.
Prior authorization is a health plan's requirement that a provider get approval before a service or medication is covered. For a multi-location practice it is also a daily operational job that runs through schedulers, clinicians and billers in every office.
When we review prior authorization software with a practice group, the first question we ask is not which platform is best. It is which jobs disappear and which stay with your staff. This post maps the seven jobs inside an authorization, shows which ones vendors automate, and sets out how we would pilot a platform and close the gap it leaves before you sign.
What Prior Authorization Software Automates and What Stays Manual
Prior authorization software automates submission and status tracking well, automates requirement checks partially, and leaves the post-approval work almost entirely to your staff. The workload behind that split is large.
The American Medical Association's survey of 1,000 physicians in late 2024 found that practices complete an average of 39 prior authorization requests per physician, per week, that physicians and their staff spend an average of 13 hours a week on them, and that 40% of physicians have staff who work exclusively on prior authorizations.
That volume is why the distinction matters. Software that removes keystrokes from submission still leaves a long tail of work, and the table below shows where it sits across the lifecycle of one authorization.
| Job | What software automates today | What stays with your staff |
|---|---|---|
| Check if auth is required | Partial rule checks and payer lookups | Plan nuance, delegated UM exceptions, site-of-service logic |
| Assemble clinical documentation | Templates and attachment workflow | Medical necessity and chart review |
| Submit the request | Strong automation through portals and APIs | Residual payers and delegated vendors |
| Track status | Polling, alerts and work queues | Follow-up where portals do not integrate |
| Manage the approval as inventory | Weak or absent | Units, dates, site, provider and CPT match |
| Re-authorize before expiry | Some reminders | Ownership and schedule coordination |
| Work denials and appeals | Routing and deadline reminders | Clinical argument and appeal strategy |
Most vendors handle the third and fourth jobs well, the first partially, and very little of the last three. We walk through each job below in the order a request moves through a practice.
1. Determine If the Service Needs Authorization
A scheduler or front-office lead matches the plan, the CPT code and the site of service against payer rules. Software helps with rule libraries and payer lookups, and that removes the easy cases.
The hard cases stay manual, including Medicare Advantage plan exceptions, Medicaid managed care rules and delegated utilization management vendors that apply their own criteria. The common mistake is assuming a rules engine knows every plan in your local market. Spot-check its answers against last month's denials before you trust it.
2. Assemble the Clinical Packet
Clinical staff or an authorization team gather notes, imaging, labs and history that show medical necessity. Software can prompt for missing attachments and fill templates.
It cannot decide what evidence persuades a reviewer for a given payer and service. We see practices get the best results when one experienced person owns the packet standards for each high-volume service line and the software enforces that checklist.
3. Submit Through the Right Channel
Submission is where prior authorization software is strongest. Electronic prior authorization through payer portals, clearinghouses and APIs replaces faxing and manual portal entry for most large payers.
What remains is the residue, meaning payers and delegated vendors outside the platform's integrations. The measure that this job is solved is the share of last quarter's volume that went out without anyone logging into a portal by hand.
4. Track Status and Answer Requests for Information
Platforms poll for status, raise alerts on pends and route requests for more information into work queues. That replaces a lot of follow-up calling.
Where a portal or vendor does not integrate, a person still checks by hand. The mistake we see is measuring the platform on its best payers and never counting the follow-up still done outside it.
5. Manage the Approval as Inventory
An approval is not a yes. It is a bounded allowance, with approved units or visits, a valid date range, a site of service, a rendering provider, a CPT set and an authorization number.
This is the job most vendors do not own, and it is where revenue leaks. A practice needs a record of every active authorization with what has been used against it, checked before each visit is scheduled rather than after the claim denies.
6. Re-Authorize Before the Approval Expires
When a course of treatment runs long, the group needs to request a new authorization before the old one lapses. Platforms can send reminders, but someone has to own the schedule and act on them.
You can tell this job is under control when no visit is booked past an authorization's end date. The common failure is a reminder that goes to a shared inbox nobody watches.
7. Work Denials, Peer-to-Peer Reviews and Appeals
When the answer is no, the practice decides whether to challenge it, gathers evidence and sometimes schedules a peer-to-peer review between physicians. Software routes the case and tracks deadlines.
The clinical argument and the decision to appeal remain human work. Track appeal outcomes by payer and service, because that data tells you where packet standards need to change.
Where Practices Lose Money After an Authorization Is Approved
Most prior authorization write-offs happen after approval, when authorized work quietly stops being authorized. We see the same five failures across multi-location groups:
- A service performed after the authorization's end date, so the claim denies and the problem surfaces only after billing.
- Visit thirteen on a twelve-visit authorization, common in therapy, pain, orthopedics, infusion and imaging.
- The authorization issued for one location while the patient is seen at another.
- The authorization naming one rendering provider while the service is billed under a different one.
- An authorization number that never reaches the claim from the schedule or the note.
These failures appear months later as denials, underpayments or write-offs because the systems are split. The practice management system knows the claim, the schedule knows the date and location, and the note knows the clinical justification. No single prior authorization software vendor owns that join, which is the same location problem we describe in which location caused this denial.
How the Five Vendor Categories Compare on Real Coverage
Buyers' guides group very different products under prior authorization software, so compare by category before comparing brands. Each category removes a different slice of work and leaves a different slice behind.
| Category | What it removes | What it leaves | Typical failure |
|---|---|---|---|
| Clearinghouse or multi-payer portal, such as Availity | One login for a broad submission rail | Inventory, clinical work, payer leftovers | Delegated UM and carve-outs stay manual |
| RCM suite module | Some workflow inside the billing stack | Deep auth logic across locations | Edge cases stay manual |
| PA-specific automation platform | Submission, status checks, routing | Post-approval ledger | Looks complete in a demo, solves half |
| EHR-native authorization module | Some context from the chart | Cross-system joins and coverage gaps | Weak across multiple systems |
| Outsourced human service | Staff headcount on your side | Process ownership and data hygiene | You buy labor, not control |
That taxonomy is more useful than a ranking. When we compare automated prior authorization from CoverMyMeds, Waystar, Myndshft or another platform, the question is never only if it submits. It is how much of your payer mix it actually covers and what it leaves for people.
How to Pilot Prior Authorization Automation Before You Buy
A good pilot tests prior authorization software against your own payer mix and your own leakage, not the vendor's demo data. These are the steps we would follow with a multi-location group, in order:
- Pull last quarter's authorizations from your practice management system and group them by payer and delegated utilization management vendor, sorted by volume.
- Compare that list with the platform's live portal coverage, not its marketing count of payers, and calculate the share of volume left outside it.
- Quantify authorization-related denials and write-offs for the last two quarters by reason code, so the pilot has a baseline.
- Measure staff time by lifecycle job rather than as one block of authorization labor.
- Run the pilot in one or two locations with a mixed payer profile, and keep a control location on the current process.
- Agree success measures up front, such as share of submissions sent without manual portal work, time to decision and authorization-related denials per hundred visits.
- Ask each vendor which payers are on the live list, which delegated vendors are excluded, how units, dates, locations and provider changes are tracked, and how the note, schedule and claim are reconciled.
The residue you find in the second step decides the rest. If a meaningful share of volume sits outside the platform, a second platform rarely shrinks it. It usually creates another queue.
When a Thin Internal Ledger Is Worth Building
For a multi-location group the honest answer is usually to buy the submission rail and build the authorization ledger. Do not build your own prior authorization submission engine. That is commodity infrastructure, and federal rules are pushing it further toward standard rails.
The layer no prior authorization software vendor owns is a single record per patient and service episode, holding payer, plan, member, CPT set, approved units, date range, site of service, rendering provider and authorization number, joined to the schedule and rendered services. It should warn before a violation, not after a denial. This is the kind of healthcare workflow software we build, and it is where healthcare software development pays back fastest for operators.
We would build that ledger when several of these are true:
- Monthly authorization volume is meaningful.
- You operate multiple locations.
- You run more than one practice management or EHR system.
- A large share of volume sits outside one vendor's portal list.
- Authorization-related denials are large enough to measure.
- Your practice management system exposes a usable API or export.
The counter-case matters too. If you run one location on one practice management system with a concentrated payer mix, buy the platform and stop there. Our work with multi-location healthcare groups, including practice-operations work with Apex Dental Partners, is the basis for this view, and the related build-or-buy question at the front desk is covered in the front-desk eligibility tax.
What CMS-0057-F Changes in 2026 and 2027, and What It Leaves Alone
CMS-0057-F standardizes how impacted payers handle prior authorization for items and services, but it does not manage a practice's authorization inventory. The final rule, published in the Federal Register on February 8, 2024, sets decision timeframes of 72 hours for expedited requests and 7 calendar days for standard requests, with compliance dates in 2026. It also requires a specific reason for each denial and public reporting of prior authorization metrics.
The rule adds a Prior Authorization API with compliance dates in 2027, generally starting January 1, 2027. The API runs on HL7 FHIR, and HL7's Da Vinci Prior Authorization Support implementation guide describes how a request and response travel over it.
Impacted payers include Medicare Advantage organizations, state Medicaid and CHIP programs, Medicaid and CHIP managed care, and Qualified Health Plan issuers on the Federally-facilitated Exchanges, although those exchange issuers are exempt from the decision timeframes.
What it leaves alone matters as much. The process and API requirements exclude drugs, most employer-sponsored plans sit outside the rule, and nothing in it assembles the clinical packet or tracks units against an approval. In our view the rail gets better and the ledger stays the practice's job.
Buy the Rail, Pilot It, and Own the Ledger
Prior authorization software is becoming a commodity rail for submission and status. The margin sits in the ledger, where an approval lives after it is granted and where a multi-location group either protects revenue or loses it quietly. We would pilot the rail against your own payer mix, then own the ledger.
If you want a second view on a pilot plan or a ledger design, the team at Better Software can walk through it with you.
Frequently Asked Questions
What Is the Difference Between Pre Authorization and Prior Authorization?
In practice the terms are used interchangeably, and both mean getting approval before a service is performed. We treat them as one process and check the payer manual for the exact term, because the required documents and decision timelines are set by the payer, not by the name used for the request.
What Do You Need for a Prior Authorization?
We usually gather patient and plan details, the CPT or HCPCS code, diagnosis codes, clinical notes and any evidence of medical necessity. Many payers also require the site of service, the rendering provider and the requested units or visit count, so we capture those before the request goes out.
How Often Are Prior Authorizations Approved?
There is no universal approval rate, because it varies by payer, service line and documentation quality. We recommend measuring your own approval rate by payer and CPT code. Under the federal prior authorization rule, impacted payers must also publish prior authorization metrics, which gives practices a benchmark to compare against.
Can Billing Software Manage Prior Authorizations?
Billing software can store an authorization number and attach it to a claim, and some suites include submission tools. In our experience it rarely tracks units, date ranges, locations and rendering providers against each scheduled visit, which is where prior authorization revenue actually leaks for multi-location groups.
What's the Difference Between an EHR's Built-In Prior Auth Tool and a Dedicated Platform?
An EHR's built-in tool sees the chart, so it is convenient inside one system. A dedicated platform usually covers more payers and portals. We suggest the built-in tool for a single EHR with a concentrated payer mix, and a dedicated platform when prior authorization volume spans several systems or many payers.
About the author
Better Software Team
Product and engineering team
Better Software Team is the product and engineering team at Better Software. We build custom software for established businesses in healthcare, energy and finance.