CMS-0057-F: Payers Build the APIs, Providers Attest. Here Is Who Owes What.

What CMS-0057-F Actually Is

CMS-0057-F is the CMS Interoperability and Prior Authorization Final Rule. The 0057 is a CMS rule number, not a code, a form, or a measure, which is worth saying because the number gets searched far more often than the rule’s name.

Its purpose is to move prior authorization off fax machines and phone calls and onto standards-based APIs, and to make plan data available to patients, to providers, and to other plans. The rule does that by regulating health plans, not by regulating the practices and hospitals that send them requests.

That distinction is the single most useful thing to get right about this rule, and it is the thing most often garbled. If you are reading a requirements document that says your practice must build a prior authorization API by January 2027, the document is wrong.

Who Must Comply, And With What

Two groups have obligations under this rule. They are very different in size.

Notably, the measure that lands on providers was finalized as an attestation rather than the numerator-and-denominator measure originally proposed. A clinician or hospital reports yes or no, or claims an applicable exclusion. It is not a volume threshold, and it does not require a build.

For anyone who is neither, and there are many, the rule still matters commercially. If you sell software to impacted payers, your roadmap now has a fixed date in it.

The Four APIs, Named

Most coverage of this rule refers to “FHIR APIs” collectively. That is not enough to scope anything, because the four differ substantially in effort and in who consumes them.

• Patient Access API: Lets a patient’s chosen application retrieve their claims, encounters, clinical data and, under this rule, their prior authorization information. The rule extends an existing requirement rather than creating one from nothing.
• Provider Access API: Lets a provider retrieve a patient’s data from the payer, with attribution and opt-out handling. This is the one most often underestimated, because it needs patient attribution logic and an opt-out mechanism that did not previously exist.
• Payer-to-Payer API: Moves a member’s data when they change plans. Effort concentrates in identity matching and in the operational process around member consent, not in the endpoint itself.
• Prior Authorization API: Supports submitting a request, checking status, and returning a decision with the reason when denied. This is the one the rule is named after and the one with the most workflow attached.

Each API is defined against a FHIR implementation guide, and the guides are not all equally settled. A useful question for any vendor conversation is which guide and which version a given endpoint is built against, and whether that guide is required by the rule or merely recommended. Treating a recommended implementation guide as mandatory is the most common way this scope inflates.

The Provider Obligation, In Full

This section exists because the best-ranked coverage of CMS-0057-F does not mention it at all.

Providers do not build APIs under this rule. They report a measure. Specifically, CMS added an Electronic Prior Authorization measure to the Promoting Interoperability performance category of MIPS, and the equivalent for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program.

What that means in practice:

• It is an attestation: Yes, no, or an exclusion. Not a percentage, not a count.
• It starts with the CY2027 performance period for MIPS eligible clinicians, affecting the CY2029 payment year. Hospitals and CAHs report for the CY2027 EHR reporting period.
• Exclusions are available, which matters for clinicians whose specialties rarely submit prior authorization requests.

The practical consequence for a provider organization is that the work is in being able to answer yes rather than in building anything. That usually means confirming your EHR supports electronic prior authorization against payers that now expose it, and that clinicians actually use it rather than reverting to the portal.

What Changes In Prior Authorization Itself

Regardless of which side you sit on, the operational changes are the part clinicians will notice.

1. Decision timelines compress: Impacted payers must issue decisions within 72 hours for expedited requests and 7 calendar days for standard requests: For organizations used to longer and less predictable turnarounds, this changes staffing and follow-up assumptions more than it changes technology.
2. Denials must carry a reason: When a request is denied, the payer must provide a specific reason. This is a small sentence in the rule with a large effect on appeals workflow, because a specific reason is actionable in a way that a generic denial is not.
3. Certain metrics become public: Payers must publicly report prior authorization data annually, which creates a comparison surface that did not previously exist.

We cover the broader question of how decision support fits into clinical workflow separately in clinical decision support systems; this page stays on the rule.

The Prior Authorization API, For The People Building It

This is the section for engineering and product teams at payers and at the vendors serving them.

The Prior Authorization API is not a single endpoint. It has to support three distinct interactions: submitting a request, checking status, and returning a decision with its reason. Each has different latency expectations and different failure modes, and the third is the one that carries the compliance obligation about denial reasons.

Three things reliably cause trouble:

1. Attribution and opt-out: The Provider Access API needs to know which providers are attributed to which members, and members can opt out. That logic frequently does not exist in a payer’s current stack and is not a FHIR problem at all.
2. Which implementation guide, and which version: The rule references guides at different levels of obligation. Deciding early which are required and which are optional prevents a scope conversation from reopening late.
3. Documentation requirements: Requests routinely carry attachments and supporting documentation, and modelling that cleanly is more work than modelling the request itself.

The natural adjacency for anyone already working in this area is CDS Hooks, which solves the related problem of putting a payer’s answer in front of a clinician at the moment they are ordering, rather than in a separate portal. If a prior authorization requirement can surface at order entry, the request starts from a better place. Our CDS Hooks guide covers the mechanism and the technical implementation detail covers the request and response contract.

To be clear about what we have and have not done: we build FHIR integrations and decision support against EHR workflows, and that is directly adjacent work. We have not delivered a CMS-0057-F prior authorization API program, and nothing here should be read as a claim that we have.

The Adjacent Rule Worth Knowing About

Separately from CMS-0057-F, CMS proposed CMS-1850-P, which would create the first Medicare payment pathway for software that provides AI-enabled decision support, moving 36 HCPCS codes into New Technology Ambulatory Payment Classifications.

It is worth knowing about for a reason that has nothing to do with deadlines. Reimbursement is the question every conversation about clinical AI eventually reaches and most content avoids. A defined payment pathway changes how a hospital evaluates buying decision-support software, because it changes whether the software is a cost or a billable service.

We are not tracking a comment period here and we are not filing comments. The reason to pay attention is the direction of travel, not a date.