For years, prior authorization lived inside the payer’s walls. Providers felt it. Patients waited through it. Executives managed it as a cost center. But the market could not really compare it. That changed on March 31, 2026, when impacted payers under CMS-0057-F had to begin publicly posting certain prior authorization metrics for the previous calendar year. The first scorecard reflects calendar year 2025 – meaning the market is judging payers on pre-rule performance, not on how they are operating today.¹

That timing nuance matters. The first public scorecard is being judged under a new transparency regime, but it reflects a period before the rule’s new process requirements were fully in force. Beginning in 2026, impacted payers other than Qualified Health Plan issuers on the federally facilitated exchanges must send prior authorization decisions within 72 hours for expedited requests and 7 calendar days for standard requests. Beginning in 2026, payers also have to provide a specific reason for denial for medical items and services, regardless of how the request was submitted.²

That is why this rule is bigger than compliance. CMS did not just add another reporting obligation. It made prior authorization more legible. Once a workflow becomes visible and comparable across organizations, it starts to function less like hidden operations and more like a performance signal. That is an inference, but it follows directly from CMS requiring impacted payers to publicly post comparable prior authorization metrics on a recurring basis.¹

The first scorecard is real, but it is still blurry

CMS is specific about what must now be posted publicly for medical items and services subject to prior authorization, excluding drugs. Impacted payers must publish approval and denial percentages, appeal outcomes, extended-review approvals, and average and median decision times for both standard and expedited requests.¹

But the first year of public reporting is still pretty blunt. KFF says the new data offers limited insight, there is no breakdown by service type, no explanation of why denials happened, and prescription drugs are excluded entirely. You can compare payers at a high level, but you cannot yet cleanly separate clinical value from administrative noise. The last point is inference from KFF’s description of the data limits.³

That is the first year. It gets sharper from here.

The smarter executive question is not “How often do you deny?”

The sharper question is this: How much friction do you create per clinically useful intervention?

Call it a Utilization Friction Index if you want shorthand. The point is simple: a process can approve a very high share of requests and still impose major operational drag through documentation churn, status checking, appeals, and wait time. The public reporting requirement does not calculate that index for you, but it does create the raw ingredients for the market to start asking the question. That conclusion is an inference from the metrics CMS requires payers to publish.¹

KFF’s Medicare Advantage analysis shows why this matters. In 2024, Medicare Advantage insurers made 52.8 million prior authorization determinations and 4.1 million were denied in full or in part. Only 11.5% of denials were appealed, but 80.7% of appealed denials were partially or fully overturned. Those overturned requests represent medical care that was ordered by a clinician and ultimately deemed necessary, but potentially delayed because of the extra step of appealing the initial decision.⁴

A high approval rate and a high-friction process are not mutually exclusive. That is the paradox the new transparency regime starts to expose.

2026 is the public scorecard. 2027 is the operational reckoning

CMS’s timeline makes the next inflection point clear. Impacted payers generally had to implement certain provisions by January 1, 2026, but have until primarily January 1, 2027 to meet the API development and enhancement requirements in the final rule. Those API-related requirements include the Patient Access API, Provider Access API, Payer-to-Payer API, and Prior Authorization API.⁵ The Prior Authorization API specifically must be populated with the list of items and services requiring prior auth, the payer’s documentation requirements for those items and services, and must support the creation and exchange of prior authorization requests from providers and responses from payers.

CMS also separately finalized the 2026 process requirements for denial specificity and faster turnaround times.⁶ That is why 2027 is the real operational test. In 2026, a payer can still argue that the public numbers reflect a transition-year baseline. In 2027, the architecture itself starts getting exposed. Once prior auth has to move through more standardized digital rails, the gap between a payer with a modern operating model and one still leaning on portals, phone trees, faxes, and exception queues gets harder to hide. That is inference, but it is grounded in the rule’s shift from public reporting to API-enabled exchange.⁵

Compliance is the mandate. PAS is the path.

There is one technical distinction worth keeping clean. CMS mandates the Prior Authorization API. CMS does not separately mandate PAS as a standalone fifth requirement. But it  strongly recommends that impacted payers develop their APIs to conform with certain implementation guides, and its own overview deck lists the Da Vinci CRD, DTR, and PAS implementation guides as recommended for the Prior Authorization API. That is the difference between compliance and architecture.⁶

From static scorecard to more liquid data

The transparency story also does not stop at a web page. The Patient Access API allows a third-party software application of the enrollee’s choosing to access the data made available through the API. CMS also requires reporting on how many unique patients had their data transferred through the Patient Access API to a health app selected by the patient, including how many had data transferred more than once.⁷

CMS’s 2024 overview deck further says that, beginning in 2027, impacted payers must include certain information about patients’ prior authorization requests and decisions, excluding drugs, in the Patient Access API. That does not create a consumer-grade comparison app overnight. But it does move prior auth away from static website disclosure and closer to app-accessible data in the patient’s hands. The second and third sentences are inference from CMS’s API requirements.⁶

Transparency creates pressure for exemption

The gold-carding angle is real, but it has to be stated carefully. KFF notes that some insurers waive prior authorization requirements for certain providers, including through gold-carding programs, and points to UnitedHealth Group’s decision to launch a national gold-card program that exempts certain providers from prior authorization requirements. KFF also notes that some insurers exempt providers through risk-based contracts.⁴

Separately, the American Medical Association says the federal GOLD CARD Act would exempt physicians from Medicare Advantage prior authorization requirements so long as 90% of their requests were approved in the preceding 12 months, and says the legislation was based on a similar Texas law.⁹

CMS-0057-F does not itself create gold-carding. But once payers are publishing comparable approval rates by service, the market has more grounds to ask why certain predictably-approved providers or service lines are still being run through the tollbooth.

CMS-0057-F does not itself create gold-carding. But transparency makes the logic behind gold-carding harder to ignore. If a provider or service line is predictably approved over time, the market has more reason to ask why the tollbooth is still there. That is inference based on KFF’s description of gold-carding programs and the public reporting regime CMS now requires.^1,4

What this means for health plans and their technology partners

The cleanest way to read CMS-0057-F is not as a narrow compliance story. It is a market-structure story. The first public posting in 2026 reflects calendar year 2025 performance. The API build-out lands primarily in 2027. In between, prior authorization is shifting from a hidden workflow to a more visible, more measurable signal of operational maturity.

Payers that treat this as a documentation exercise will find themselves on the wrong side of that comparison. The ones that use the 2026 window to modernize their prior auth architecture — standardizing decision logic, reducing manual touchpoints, building toward API-ready infrastructure — will be better positioned when 2027 makes the operational gaps legible to the entire market.

That is the window. It is open now.