How to evaluate prior authorization software

What this software does

Prior authorization software sits between your EHR, your clearinghouse and the payers. It takes referrals and orders, checks the patient’s coverage, works out whether the payer requires authorization for the service, gathers the documentation the payer asks for, submits the request through whatever channel the payer accepts, and tracks each request to approval, denial or a request for more information. The aim is that every request has an owner and a status before the patient arrives, rather than surfacing as a denied claim afterwards.

Products differ most in where they stop. Some cover eligibility checks and denial follow-up as well; others handle only submission. Some build documentation packets from the EHR; others expect staff to attach them. Decide early which steps you are buying and which stay with your EHR, clearinghouse and billing system.

The rules that shape the work

Most of the federal rules fall on payers, not providers, but they change what your software will be able to connect to. The main one is the CMS Interoperability and Prior Authorization final rule (CMS-0057-F), published in February 2024. It applies to Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities and Qualified Health Plan issuers on the Federally-facilitated Exchanges. Employer plans and other commercial coverage are outside it.

• Since January 1, 2026. Impacted payers other than Exchange plans must send decisions within 72 hours for expedited requests and seven calendar days for standard requests. Payers must give a specific reason for a denial, whatever method was used to send the request, and post prior authorization metrics on their websites each year, with the first set due by March 31, 2026.
• From January 1, 2027. Payers must generally offer a FHIR Prior Authorization API that lists the items and services needing authorization, identifies documentation requirements, accepts a request and returns an approval, a denial with its reason, or a request for more information. Exact compliance dates vary by type of payer. Drugs are excluded from these requirements.
• The HIPAA transaction. The adopted standard for authorization requests is the X12 278 (version 5010) under 45 CFR 162.1302. HHS said it would use enforcement discretion so that payers can meet the rule with an all-FHIR API or a FHIR and X12 combination; payers may also offer an X12-only transaction.
• Proposed, not final. In April 2026 CMS and HHS proposed extending these requirements to drugs and adopting FHIR specifications as HIPAA standards for authorization and related eligibility transactions. Comments closed on June 15, 2026. Check its status before relying on it.
• Hospitals and clinicians. The 2024 rule added an Electronic Prior Authorization measure to the Medicare Promoting Interoperability Program and MIPS. The FY 2027 hospital inpatient final rule made it optional, with bonus points, for hospitals and critical access hospitals in CY 2027, and required (attest yes or claim an exclusion) from CY 2028. CMS has proposed changes for MIPS clinicians in the CY 2027 Physician Fee Schedule rulemaking, so check the final rule.

Many states also have their own prior authorization laws for the plans they regulate.

Who should be on the evaluation team

• Patient access and prior authorization leads, who know which payers and services generate the most work.
• Referral coordinators and specialists, who will work the queue every day.
• Revenue cycle and denial management, who can show which authorization failures end up as denied claims.
• Clinical department managers and a clinician, because documentation requests land on their staff.
• EHR, integration and clearinghouse owners, who know which interfaces and payer connections actually exist.
• Privacy and information security, because requests carry clinical documentation.

Questions to ask and things to test

• Bring your highest-volume services and payers and ask to see how the rules for them would be configured, and how each rule shows when it was last reviewed.
• Follow a request for a payer with no electronic route from start to finish. What does the specialist do, and is the item still tracked?
• Watch a request for more information arrive and see whether it reaches the right clinician’s team with the payer’s question attached.
• Check your clearinghouse. Which of your payers support electronic eligibility and 278 transactions through it today?
• Ask about payer APIs. Which FHIR prior authorization APIs can the product use now, and how will new payer connections be added as they appear?
• Review the EHR interfaces for orders, documentation retrieval and write-back with your own integration team.
• Look at the reports for denials, pending requests and expiring authorizations, and compare them with how you manage the work today.

Common limits to probe

• Payer portals. Where a payer accepts requests only on its own portal, a person still submits them there.
• Payer decisions. Software makes requests complete and visible; approval stays with the payer, and no product can promise an outcome.
• Medical necessity. Documentation comes from your clinicians. Software can gather it, not write it.
• Rules upkeep. Payer rules change often. Ask who keeps them current after go-live and how.
• Connections vary. Electronic eligibility, 278 transactions and payer APIs depend on each payer and your clearinghouse.
• Claims and appeals. Check whether the product submits claims or posts payments, and who writes appeal letters.

Implementation risks

• Starting with every payer. Configure rules for the payers and services that matter most first, and expand from there.
• Interface gaps. If orders or documents do not flow from the EHR, staff fall back to re-keying. Test the interfaces with real orders before go-live.
• Clearinghouse enrollment. Some payers need enrollment before electronic transactions work. Start it early.
• Two worklists. If the EHR and the new tool both hold authorization status, write-back has to keep them aligned, or scheduling and billing will act on different facts.
• Measuring the change. Record your current turnaround times and authorization-related denials before go-live, so you can see whether anything improved.
• Access to clinical data. Review who can see request packets, at your organization and at the vendor.

Related reading on this site

Requirement pages: HIPAA.

In the glossary: Prior authorization, X12, FHIR, Revenue cycle, CMS.

This guide describes the category, not any one product. It is general information, not legal advice: for what a rule requires of your organization, read the rule itself or ask your counsel.