The best prior authorization software for a health plan is not a product name but a fit to a set of rules: from 2026 its reviews must finish inside 72 hours or 7 calendar days for Medicare Advantage and Medicaid, every denial must reach the provider with a specific reason, an adverse medical necessity decision must be reviewed by a qualified professional before it issues, and from 2027 the plan must run a Prior Authorization API. Software that cannot show how it meets each of those is not the best for a plan, however well it reads charts. The twelve questions below are the ones a VP of utilization management, a procurement lead and a CIO's team should put to any vendor, each paired with the rule that makes it necessary. Botminds' Prior Authorization Automation is one answer to them, and the guide says plainly where it fits and where a plan would need something else.
Twelve questions to ask any prior authorization software vendor, and the rule behind each
- Show me the 7-day and 72-hour clocks on every request, per line of business.
Medicare Advantage: 7 calendar days standard and 72 hours expedited (422.568, 422.572). Medicaid managed care by rating period. ERISA and state rules differ.
- Can anything in the system issue a denial without a licensed reviewer?
An adverse medical necessity decision must be reviewed by a physician or other appropriate professional first (422.566(d)).
- For every criterion met, show me the passage and the page.
Decisions must rest on the member’s medical history, physician recommendations and clinical notes (422.101(c)).
- For every criterion open, show me what was searched.
Documentation denials are where OIG found records already in the case file.
- Write me the specific reason for a denial, from the review itself.
Required for the provider by every channel from 2026 (422.122(a)); the member’s notice must state specific reasons (422.568(e)).
- Which policy and edition did you apply, Medicare’s or ours?
Medicare coverage first; internal criteria only where not fully established, and published (422.101(b)(6)).
- How do you ask providers for missing records, and inside which clock?
Extensions are narrow and need written reasons (422.568(b)(2)); HIPAA limits requests to the minimum necessary.
- Can urgency or the clock be changed by the software?
A physician-supported expedite request must be expedited when the physician says the standard clock could seriously jeopardise the member (422.570).
- Produce our public prior authorization metrics from the same decisions.
Posted each year by 31 March at contract level (422.122(c)).
- How does your review connect to the Prior Authorization API we must run in 2027?
Required from 1 January 2027 (422.122(b)); drug prior authorization through it is only proposed.
- Show me the record of who did what, for one request.
Every agent step, decision and setting change, for audit and appeal.
- What do we pay you for, and what penalises a wrong denial?
Peer-reviewed commentary links vendor-run prior authorization with more denials and more appeal reversals.
What is the best prior authorization software for health plans?
The one whose answers to the twelve questions a plan's compliance team, medical director and auditors would accept, on the plan's own requests. Speed matters, but it is the easiest property to demonstrate and the least informative: any system is fast on clean examples. The harder properties are whether every tick can be traced to a page, whether a "not found" means absent, whether a denial is impossible without a licensed reviewer, and whether the reason written to the provider is specific. Those are the properties the 2026 rules test and the ones a demonstration hides.
The evidence base offers little help in choosing. A systematic review published in September 2026 found 16 studies of AI in prior authorization, most reporting technical metrics rather than operational results, with high analysis bias and limited generalizability in the authors' assessment (JMCP). A vendor's published accuracy figure is, at best, one of those technical metrics on someone else's data. The plan's own pilot is the only evidence that applies to it.
Provider prior authorization software vs payer review software
They sit on opposite sides of the same transaction and are judged by different rules. Software sold as prior authorization software may help a provider's office submit requests or help a plan's reviewers decide them, and a health plan needs the second. A plan evaluating vendors should first check which side a product was built for.
Two kinds of prior authorization software, judged by different rules
Who uses it
Provider-sideFront-desk and clinical staff in hospitals and physician offices.
Payer reviewUM nurses, physician reviewers, intake coordinators and supervisors at the plan or its delegate.
The job
Provider-sideFind out whether a service needs approval, fill the form, attach records, track status.
Payer reviewRead what arrived against the policy, ask for what is missing, decide inside the clock, write the notice.
Success looks like
Provider-sideApproval obtained with the fewest resubmissions.
Payer reviewA right decision, on time, with a file and a specific reason that survive appeal and audit.
Rules it must meet
Provider-sidePayer submission rules; the provider’s own documentation duties.
Payer reviewDecision clocks, professional review of denials, specific reasons, notices, public metrics, the 2027 API.
Where AI fits
Provider-sideAssembling and submitting the request.
Payer reviewReading and citing the record; never deciding a denial.
Prior Authorization Automation is payer review software. It takes requests from the provider portal, fax and electronic X12 278 transactions, in any order, and works with the plan's clinical records, medical policies, eligibility, claims history and notice templates. It does not help a provider's office prepare requests, and it is not a plan's whole utilization management platform: it sits beside the systems a plan already runs and does the reading, citing and drafting in front of the reviewer, the arrangement the guide to utilization management software lays out.
The rules prior authorization software has to meet in 2026 and 2027
Three dates and one proposal define the requirements. CMS-0057-F's operational provisions, the clocks, specific denial reasons and public metrics, began in 2026; its API requirements begin in 2027; and a further rule on drug prior authorization was proposed in April 2026 and is not yet law.
The CMS-0057-F calendar a plan's software has to meet
1 Jan 2026
72-hour and 7-day clocks and specific denial reasons, Medicare Advantage and Medicaid fee-for-service
Medicaid managed care: rating periods from that date
31 Mar 2026
first public prior authorization metrics posted, for calendar 2025
then every 31 March
1 Jan 2027
Prior Authorization, Provider Access and Payer-to-Payer APIs
Medicaid managed care by rating period
1 Oct 2027
proposed date for drug prior authorization through the API
CMS-0062-P: a proposal, not law
CMS put the value of getting this right in its own terms: its regulatory impact analysis estimated minimal potential savings of $15 billion to $16 billion over ten years from the rule's prior authorization improvements, an illustrative estimate built on survey inputs (89 FR 8758).
Does prior authorization software support the CMS API?
It has to connect to it, but the API is the plan's obligation, not a feature to tick. From 1 January 2027 a Medicare Advantage organization must run a Prior Authorization API that lists the items and services needing prior authorization, supports a HIPAA-compliant request and response, reports whether each request is approved, denied with a specific reason, or pended for more information, and:
“Can identify all documentation required by the MA organization for approval of any items or services that require prior authorization”
42 CFR 422.122(b)(2), the Prior Authorization API requirement from 1 January 2027
That clause reaches back into review. A plan cannot list the documentation each service requires unless its policies are written as criteria with the records that prove them, which is exactly what review software built on cited criteria produces. On standards, CMS's fact sheet says covered entities that implement an all-FHIR Prior Authorization API without the X12 278 "will not be enforced against under HIPAA Administrative Simplification", allowing "a FHIR-only or FHIR and X12 combination API" (CMS).
Drugs are the open question. CMS-0062-P proposes that impacted payers support electronic prior authorization for all drugs through the Prior Authorization API and NCPDP standards from 1 October 2027 (91 FR 19890; the CMS-0057-F summary sets the proposal beside the rules already in force). Comments closed in June 2026; nothing is final. A vendor that sells "CMS-0062 compliance" today is selling a proposal. Ask any vendor, Botminds included, exactly which part of the API it provides and which part the plan's interoperability platform must; the solution's own role is reading requests, including 278 transactions, and producing the decision, criteria and reason that an API response would carry.
Which rule each question tests, and what a good answer shows
| Question area | Rule | A good answer shows |
|---|---|---|
| Clocks | 42 CFR 422.568, 422.572; 438.210(d) | The time left on each request, alerts before it falls due, and the plan’s other lines of business on their own clocks. |
| Who decides | 42 CFR 422.566(d) | No path by which software issues an adverse decision; physician sign-off recorded. |
| Evidence | 42 CFR 422.101(c) | A quoted passage and page behind each criterion, opened in one click. |
| Criteria | 42 CFR 422.101(b)(6); 422.137 | Each policy marked Medicare or plan, with edition and effective date. |
| Reasons | 42 CFR 422.122(a); 422.568(e) | A drafted reason naming criterion, evidence and what would change the answer. |
| Metrics | 42 CFR 422.122(c) | The posted percentages computed from the same signed decisions. |
| API | 42 CFR 422.122(b) | A clear split between the vendor’s role and the plan’s API platform. |
| Oversight | Plan accountability for delegated work | A full record of who did what, and contract terms that penalise wrong denials. |
How do you evaluate prior authorization vendors?
On your own closed requests, scored by your own reviewers, with pass marks set in advance. A demonstration on the vendor's examples tests the vendor's examples. A replay of last quarter's requests, weighted toward denials later overturned and toward long records, tests the plan's actual problem, and the twelve questions above become observable: the clock is on the screen or it is not, the page opens or it does not, the reason is specific or it is not. The four-week pilot sets out the sample, the data and the scorecard. A plan choosing a company to review requests for it, rather than software for its own nurses, is choosing among utilization management vendors, where the questions turn to delegation and oversight.
Question 1, answered on screen: every request with its clock, line of business and criteria
Two evaluation habits save months. Have the plan's physician reviewers, not its IT team, score the denials and contradictions, because they are the ones who will sign. And ask each vendor to show a request where its software declined to do something: marked a criterion open rather than guessing, refused to tick without a passage, stopped at a physician. A system that has never stopped is a system whose limits have never been tested. The limits of each of the solution's agents are set out in prior authorization AI agents: what each does, and never does.
Question 11, answered: every step of one request, with what it found and when
What do you pay a prior authorization vendor for?
Ask before price, because the payment model shapes the decisions. A peer-reviewed commentary in Health Affairs Scholar in September 2026, an argument rather than a new study, warned:
“Vendors now play major roles in star-rating maximization, risk-code capture, and prior authorization, with evidence that vendor-conducted prior authorization yields higher denial rates and more appeal reversals than reviews conducted internally by insurers.”
Health Affairs Scholar, September 2026, peer-reviewed commentary on vendors in Medicare Advantage
OIG's 2026 skilled nursing report found that plans later overturned 97% of the appealed denials issued by one contractor, and recommended that CMS collect request-level data that include contractor information (OEI-09-24-00331). The practical test for a buyer is whether anything in the contract rewards a denial or penalises an overturn. Medicare's own WISeR model, which pays its technology participants a share of averted spending, adjusts that share for accuracy, timeliness and provider experience; the WISeR guide reads that design. Software that the plan licenses and its own reviewers operate avoids the incentive problem, as long as no feature recommends denials.
How much does prior authorization software cost, and how to compare offers?
No public source gives reliable prices, and vendors price differently: per member per month, per request reviewed, per seat, or as a share of savings. Compare offers by converting each to a cost per decided request at the plan's own volume, then set that against the plan's own cost per request today: nurse and physician minutes, records requests, notices, and the cost of overturned denials described in writing the specific reason and the denial-rate guide. A share-of-savings price should be read with the commentary above in mind.
Include the costs that do not appear on a quote: connecting fax lines, portal and 278 feeds, eligibility, claims history and notice templates; loading and maintaining policies by edition; and the reviewer time spent checking the software's output. Software that saves reading time but requires a nurse to re-read the chart to trust it has saved nothing. That is the case for citations: a cited tick is checked in seconds.
Question 9, answered: the published metrics from the same decisions the reviewers signed
Where Prior Authorization Automation fits, and where it does not
It fits a plan whose reviewers spend their time finding pages: medical services with long clinical records, criteria that turn on dated treatment history, and clocks that leave no room to read twice. Its six agents read every page as it arrives, cite the passage for each criterion, name what is missing and draft the request and the notice; nurses approve, physicians decide any denial, and every step is recorded. Who may decide what, the clocks and alerts, and how records are requested are settings the plan controls. The design target is 12 minutes of nurse time for a request that arrives as a cited checklist, a target to be measured in the plan's own pilot.
It is not the right tool, on its own, for four needs. A plan that wants approvals with no human touch will find that a nurse clicks every approval by default. A plan whose main volume is pharmacy prior authorization should test that separately, since the solution's policies and screens are built around medical services and CMS's own rules treat drugs separately. A plan that needs provider-side submission tools needs a different product. And the 2027 API is an integration the plan runs; the solution supplies the decisions, criteria and reasons that feed it, not the API itself.
Questions people ask
What should prior authorization software do for a health plan?
Take each request from intake to a decision-ready file inside the federal clock: check eligibility, find the policy in force, read the clinical records against each criterion with citations, request what is missing, and draft the notice with a specific reason. It should leave approvals and denials to licensed reviewers and record every step for audit.
What is the difference between provider and payer prior authorization software?
Provider software helps a hospital or physician office find out whether approval is needed, submit the request and track it. Payer software helps a health plan's reviewers decide the request under its rules: clocks, professional review of denials, specific reasons and public metrics. The two meet in the X12 278 transaction and, from 2027, the Prior Authorization API.
What questions should you ask a prior authorization vendor?
Start with the twelve on this page: the clocks, who can deny, the evidence behind each criterion, what "not found" means, the specific reason, the policy edition, records requests, urgency, public metrics, the 2027 API, the record of who did what, and what the vendor is paid for. Each maps to a federal rule a plan is audited against.
Is AI prior authorization software allowed to deny requests?
Not on its own in Medicare Advantage: an adverse medical necessity decision must be reviewed by a physician or other appropriate health care professional before it issues, under 42 CFR 422.566(d). CMS said in the CMS-0057-F preamble that decisions involving AI must still meet the rules on clinical decision-making and specific reasons.
How long does it take to implement prior authorization software?
A pilot on closed requests can run in four weeks once data is exported; going live depends on how many connections a plan wants on day one, such as portal, fax, X12 278, eligibility, claims and notices. Loading medical policies by edition is often the longest single task, and worth doing whatever the plan buys.