What payers’ first prior authorization numbers needed from providers to be useful

The prior authorization metrics payers posted by March 31, 2026 were rates without volumes, averaged across whole books of business. They became useful to a health system only when paired with its own counts, by payer and service.

Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.

The week

March 31, 2026 was the first deadline for payers covered by CMS’s Interoperability and Prior Authorization final rule (CMS-0057-F) to post prior authorization metrics publicly. The rule covers Medicare Advantage organizations, Medicaid and CHIP programs and their managed care plans, and qualified health plan issuers on the federal exchanges. Each had to publish calendar year 2025 data on a page anyone could reach without logging in. The metrics included the shares of requests approved, denied and approved after appeal, and average and median decision times. Drugs were excluded. Reporting levels differed: contract level for Medicare Advantage, plan level for managed care, state level for fee-for-service and issuer level for exchange plans. The posting followed rules effective January 1, 2026, including seven-day standard and 72-hour expedited decision clocks for most affected payers and specific denial reasons.

For years, providers argued about prior authorization with anecdotes and payers answered with averages. The March 2026 postings gave everyone the same averages in public. That was progress, but it was half a dataset. The payer metrics were percentages and decision times, aggregated across a contract, a plan or a whole state. They did not include request counts, did not break results down by service, and could not show what happened to one hospital’s requests.

A health system could turn the public numbers into something it could manage against only by supplying the other half. We see three parts to that work: understanding what the payer half contained, building the provider half, and using the combination where it changes decisions.

The payer half: what the postings contained

Each posting answered a narrow set of questions about one payer’s book of business. What share of standard and expedited requests did it approve or deny? What share was approved after appeal? How long, on average and at the median, did decisions take? Those are useful facts, especially the appeal overturn rate. A high share of denials reversed on appeal suggests that initial reviews are rejecting requests that meet criteria, which is a pattern providers can raise directly.

The limits were built in. Rates without volumes cannot show whether a plan handled a hundred requests or a million. Medicare Advantage figures at contract level may blend very different markets. Averages can hide a long tail of slow decisions. Definitions also varied. A request withdrawn and resubmitted, or approved after extra documentation, might be counted differently by different payers. Formats varied too, because CMS’s template was optional. Comparing two payers’ headline rates was therefore risky. Comparing one payer’s rate with a provider’s own experience of that payer was much safer.

The provider half: counts the payer did not publish

Most health systems could not answer basic questions about their own prior authorization activity without manual work. How many requests went to each payer last year, for which services, through which channel? How many were denied, appealed and overturned? How long did each take from submission to decision? Requests move through payer portals, fax, phone and clearinghouse transactions, and status often lives in staff notes rather than structured fields.

Building the provider half means capturing a small set of fields for every request in the revenue cycle or practice management system. The fields are payer and plan, service or procedure code, ordering department, submission channel, submission time, decision time, decision, denial reason and appeal outcome. The January 2026 requirement for specific denial reasons made that last field far more useful, because reasons can now be grouped and tracked. Some of this data can be pulled from portals and electronic transactions. Some requires a change in how staff close out a request.

This is operations work with a modest technology component. It needs an owner in revenue cycle, a short data definition agreed with clinical departments, and a monthly report that someone reads. Without it, the public metrics remain trivia.

The combination: where it changes decisions

Put side by side, the two halves support three decisions that the public data alone could not.

The first is the payer conversation. Suppose a plan reports high approval rates and short turnaround, but a hospital’s own experience with it is much worse. The gap then points somewhere specific: a service line, a documentation pattern or a submission channel. That moves joint operating meetings from complaints to a shared fact base, using numbers the payer itself published. The seven-day standard clock can be tracked the same way, with missed clocks escalated through provider relations.

The second is staffing. Prior authorization teams are often sized by headcount history. Volume by payer, combined with each payer’s denial and appeal patterns, shows where the work actually sits. A payer with frequent denials and appeals consumes far more staff time per request than one with routine approvals, even at similar volumes. That supports moving staff to the payers and services that need them, and setting service levels the team can meet.

There is a workforce effect as well. Prior authorization roles have high turnover in many revenue cycle departments, partly because the work feels endless and unmeasured. A team that can see each payer’s published commitments next to its own results, and that has a defined escalation path when clocks are missed, is managing a relationship rather than absorbing whatever arrives. That is a better job, and it is easier to staff and train for.

The third is automation. Many health systems were evaluating tools to automate submission and status checks ahead of the January 2027 API requirements. Automation pays most where volume is high, approval is routine and turnaround is slow. It pays least where denials are frequent and a clinical response is needed. Only the combined dataset shows which payer and service pairs fall into which group.

With hindsight

Most required plans did post. An independent tracker, AuthDenied, reported that 92% of plans required to publish 2025 metrics had done so by late July 2026, according to an August analysis by Forvis Mazars. Usability was another matter. A KFF review in August found the postings hard to locate and interpret, reported as percentages without counts, inconsistent in format, thin on response-time detail and without service-level breakdowns. KFF noted that CMS’s July 2026 template updates and a 2026 proposed rule aimed to close some of these gaps, though not the lack of service categories.

Those findings confirm the shape of the problem. The public metrics were a reference point, not a management tool. Health systems that captured their own request-level data could use them. The January 2027 API deadline will add electronic submission and real-time status, and the same internal data will decide how well those APIs are used.

  • prior authorization
  • CMS-0057-F
  • revenue cycle
  • payer transparency
  • Medicare Advantage