Electronic Prior Authorization: What CMS-0057-F Actually Obliges, and What It Leaves Alone

CMS-0057-F has four principal prior-authorization effects, and conflating them is why most practices cannot say what changed: it shortens specified decision timeframes, requires specific reasons for denials, mandates public reporting of prior-authorization metrics, and requires standards-based APIs. It also contains related patient-consent, education, API-usage-reporting, and Promoting Interoperability provisions this article treats separately. What none of this does is determine which non-drug items and services a payer may subject to prior authorization in the first place.

Ask a practice manager what changed about prior authorization in 2026 and you will usually get an answer about a portal. That is the least consequential part of the rule, and treating it as the substance is how organizations miss the parts they could actually use.

CMS-0057-F (official source), released January 17, 2024, enhances policies from the 2020 Interoperability and Patient Access final rule (official source) (CMS-9115-F) and adds provisions intended to increase data sharing and reduce payer, provider, and patient burden through changes to prior authorization and data exchange practices. Impacted payers were required to implement certain provisions by January 1, 2026, with the API development and enhancement requirements running to at least January 1, 2027.

This article separates the rule into its four independent components, states who is and is not covered, and — most importantly for physicians — identifies the substantive question the rule leaves entirely untouched. Practices that understand the last point stop expecting relief the rule was never designed to deliver, and start using the parts it does deliver.

Who is covered, and who conspicuously is not

Scope determines whether any of this is relevant to a given denial, and practices routinely assert the rule against payers it does not reach.

The impacted payers are Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programmes, Medicaid and CHIP managed care entities, and qualified health plan issuers on the federally facilitated exchanges.

One distinction inside that list is easy to lose and worth stating precisely: CMS's own fact sheet carves qualified health plan issuers on the federally facilitated exchanges out of the specific 72-hour/seven-day decision-timeframe requirement, even though those issuers are impacted payers for the rule's other components. A practice relying on the clock against a marketplace-plan issuer is citing a provision that does not reach that payer for that purpose specifically.

Read the omission carefully. Commercial employer-sponsored coverage is not in that list. Neither, as a general matter, is a self-funded ERISA plan. For many practices, a meaningful share of prior authorization volume can sit outside the rule entirely — the exact proportion depends on a given practice's specific payer mix — which means the decision clocks and reason requirements described below do not attach to that portion.

This produces the operational reality that makes the rule feel less transformative than its coverage suggested. A practice now works two regimes at once: covered plans with defined timeframes and specific-reason denials, and non-covered plans operating as before. Staff have to know which is which before they know what they can demand, and most practices have never built that map.

The first practical step is therefore unglamorous and high-yield: classify your payer mix by whether CMS-0057-F applies. Without that classification, an escalation citing the rule against a non-covered plan wastes the credibility that a correct citation would have earned.

The scope also explains the rule’s theory of change. CMS regulates the programmes it pays for hopes practice generalizes. Whether commercial payers converge voluntarily, under state law, or not at all is an open empirical question, and it is a better story than the rule’s technical requirements.

Component one: the decision clocks

The requirement most directly useful to a practice is the simplest.

For non-drug items and services, impacted payers generally must decide as expeditiously as the patient's condition requires, but no later than 72 hours for expedited requests and seven calendar days for standard requests. QHP issuers on the FFEs are not currently subject to this particular timeframe requirement, even though they are impacted payers for the rule's other components. Shorter state-law requirements and permitted program-specific extensions may also apply, and the exact compliance date varies by payer type — a calendar date for Medicare Advantage and state fee-for-service programs, a rating period for managed-care plans, a plan year for QHP issuers. That is nonetheless a defined, checkable obligation, and it converts a category of complaint that was previously unanswerable — "this is taking too long" — into a factual assertion with a deadline attached.

Using it requires infrastructure most practices lack: a record of when each request was submitted, through what channel, and what response arrived when. Practices that cannot produce a submission timestamp cannot assert a breach, and prior authorization tracking in many organizations lives in a spreadsheet maintained by one person or in nobody’s hands at all.

The classification boundary between expedited and standard is where the clock is most often effectively defeated. The seven-day standard timeframe is materially different from 72 hours for a patient in discomfort or facing a deteriorating condition, and the determination of which track a request belongs to is consequential. When the expedited criteria are met, the provider should clearly request expedited processing and document the clinical basis. Failure to do so may delay recognition of the expedited pathway, though the payer may also independently determine that the standard timeframe could seriously jeopardize the patient's life, health, or ability to attain, maintain, or regain maximum function, and process the request on an expedited basis regardless.

The honest limit: a deadline governs when an answer must arrive, not what the answer may be. A payer that issues a denial within the applicable deadline has complied with the CMS-0057-F timing requirement — that does not establish that the denial itself complied with applicable coverage, medical-necessity, reviewer-qualification, notice, or appeal requirements, which continue to apply independently of this rule. The clocks address delay, which was a real harm, and leave the substance of the decision untouched.

Component two: denials must state a specific reason

The second component is less discussed and, over time, probably more consequential than the clocks.

Under the rule, denials must include a specific reason for the denial. The prior authorization API is likewise specified to communicate approval — including the end date or circumstance — denial with a specific reason, or a request for more information.

Why this matters is a point about appeals rather than about transparency. A vague or generic denial reason can make a focused, merits-based appeal substantially harder to build, because the practice may not know which criterion or missing element actually drove the decision — existing appeal rights do not disappear because the stated reason was inadequate, but exercising them well becomes guesswork. A denial that identifies its actual basis is answerable: the practice can address the specific criterion, demonstrate it is met, or determine that a different submission or appeal route is the right one.

The second-order effect is what makes this component structurally significant. Requiring specific reasons creates an auditable trail across denials. A payer whose stated reasons are internally inconsistent across similar cases, or that cites a criterion its own published policy does not contain, has generated a record. That record is usable by practices, regulators, and journalists in a way that "denied — not medically necessary" never was.

Realizing any of that depends on practices actually reading and retaining stated reasons rather than treating a denial as a binary outcome to be resubmitted against. Most do not, which means the component’s value is currently unrealized in the field.

The reason-giving requirement also has a downstream effect worth noting. A payer that must state a specific reason has generated a record that can be compared across cases — the same auditability logic that makes refusal records decisive under the information blocking rule (Information Blocking and Its Exceptions: Sharing as the Regulatory Default), where an actor’s undocumented refusal is close to an undefendable one.

Component three: public reporting of metrics

The third component operates at a different level and is aimed at a different audience.

Impacted payers must publicly report prior authorization metrics — in substance, volumes, approvals and denials, and decision timeframes. CMS has published a prior authorization metrics report overview and template as an example of how such reporting may be structured, alongside Medicare fee-for-service prior authorization and pre-claim review statistics for prior fiscal years.

For an individual practice this changes nothing about an individual case. Its significance is that it converts assertions about payer behaviour into checkable claims. Before public reporting, a practice’s experience of a payer’s denial rate was anecdote against the payer’s aggregate assurance, and the payer held the data.

The caution is that CMS prescribes the categories of metric that must be reported, but the final rule does not specify every denominator or require use of a single template — payers do not have unlimited freedom to invent the reported measures, but real definitional latitude remains within the prescribed categories. Denial rates depend on what counts as a denial — whether requests closed for insufficient information or withdrawn requests are included. Decision timeframes depend on when the clock is treated as starting, and program rules may permit a defined extension in specified circumstances rather than an open-ended restart. Approval rates measured after appeal look materially different from approval rates on initial determination.

None of that makes the metrics useless — CMS has also published a recommended, though not mandatory, reporting template with expected numerators and denominators — but it makes them evidence requiring interpretation. The interrogation this calls for is the subject of the companion piece on what to ask about approval speed claims (What Journalists Should Ask About Approval-Speed Claims), and the reporting questions in public reporting of PA metrics (Public Reporting of Prior-Authorization Metrics).

The interpretive trap here is not unique to prior authorization, and it is worth recognising in its general form: a metric produced by the party being measured, using definitions that party chose, will tend to describe the definitions rather than the conduct. The same problem in the setting of patient-safety reporting — where better instrumentation makes recorded harm rise and a transparent system looks worse than an opaque one — is examined in low-resource safety systems (Low-Resource Safety Systems: What the Global Action Plan Asks of Countries That Cannot Buy Their Way to Safety).

Gold-carding, and the exemption question the rule left open

One reform that physicians consistently rank above everything in CMS-0057-F (official source) is absent from it, and understanding why clarifies what the rule is.

Gold-carding — exempting physicians with consistently high approval rates from prior authorization for specified services — addresses volume rather than process. A physician approved on ninety-eight percent of requests for a procedure is generating administrative work on both sides with almost no adjudicative content. Exempting them removes the transaction rather than accelerating it.

CMS-0057-F does not require this. As set out above, the rule regulates the process of prior authorization and leaves untouched what may be subject to it. Decision clocks, specific-reason denials, public metrics, and standardized interfaces all presuppose that a request is being made.

The consequence is a mismatch between what the rule delivers and what physicians experience as the burden. Faster decisions on the same volume of requests is an improvement; it is not the improvement most practices want. And because the rule's public reporting requirement will produce aggregate approval-rate data, it may contribute to broader scrutiny of prior-authorization utilization generally — but the required percentages are aggregated across all covered items and services at the contract, state, plan, or issuer level, not broken out by service class. CMS-0057-F does not currently mandate the service-specific approval-rate data that a genuine gold-carding argument for a particular procedure would need.

That is worth noting as the mechanism by which the rule could indirectly matter more than its text. Transparency requirements sometimes generate the evidence for substantive reform they do not themselves enact.

Gold-carding is being addressed at state level for state-regulated commercial insurance, alongside the timeframe and criteria-disclosure provisions discussed below. Any specifics stated here would be stale, and ERISA preemption means a state statute may not reach a self-funded plan in the same way it reaches a fully insured one — though ERISA claims-procedure requirements, other federal protections, and plan documents can still apply to that volume. The practical instruction is to know which of your payers sit outside both CMS-0057-F and applicable state law — for that group, the applicable analysis runs through ERISA, other federal law, plan procedures, or the participation agreement you negotiated, not through a state gold-carding statute.

Component four: the four APIs

The fourth component is the engineering mandate, and it is the part most coverage treats as the whole rule.

Four HL7 FHIR R4 (hl7.org) APIs are in scope. The Patient Access API, established under the 2020 rule, is expanded to include prior authorization information — with drugs excluded under current CMS-0057-F. A pending proposed rule, CMS-0062-P (April 2026), would extend electronic prior authorization to drugs among other expansions; as of this writing it remains proposed and is not part of current obligations unless and until finalized. A Provider Access API requires impacted payers to share claims, encounter, and clinical data with in-network providers who have a treatment relationship with the patient. A Payer-to-Payer API supports data transfer when a member changes coverage. And a Prior Authorization API supports submission and communicates approval, denial with specific reason, or a request for more information.

The Payer-to-Payer requirement has a history worth knowing, because it explains the rule’s tone. CMS-9115-F, the 2020 rule, finalized a non-API payer-to-payer exchange requirement. In December 2021, CMS announced it would exercise enforcement discretion and not take action on that provision while implementation challenges were addressed through future rulemaking. CMS-0057-F replaced that approach with an enforceable, FHIR-based Payer-to-Payer API requirement — one that also requires affirmative patient opt-in and generally limits required data exchange to records with a date of service within five years of the request. A regulator returning to a provision it had paused, to reissue it as a specified, enforceable API, is making a point about the first attempt.

On the demand side, CMS-0057-F finalized an Electronic Prior Authorization attestation measure beginning with the CY 2027 MIPS performance period (CY 2029 payment year) and the CY 2027 EHR reporting period for eligible hospitals and CAHs. A MIPS-eligible clinician subject to the measure must attest that at least one qualifying non-drug prior authorization was submitted electronically through a Prior Authorization API using certified EHR technology, or claim an applicable exclusion; eligible hospitals and CAHs carry a parallel requirement. The measure is unscored in its first year, but reporting is still required for participants subject to it, and it is this specific mechanism — not a universal mandate on every practice — that makes provider-side adoption more than optional for the clinicians and hospitals it reaches.

Implementation guidance in this space comes substantially from the HL7 Da Vinci (official source) project. That guidance is not itself the regulation, and conflating an implementation guide with a legal requirement is a common and expensive error.

The Provider Access API, and the obligation nobody asked for

One of the four interfaces creates a capability physicians did not request and will have to decide what to do with.

The Provider Access API requires impacted payers to make available claims and encounter data, specified USCDI clinical data classes and elements, and certain prior-authorization information to attributed in-network or enrolled providers with a treatment relationship with the patient. The payer must maintain an attribution process connecting patients to those providers, and patients must be permitted to opt out of Provider Access exchange with all providers under this policy. Framed as burden reduction, it is more accurately described as a change in what a treating physician can see — and therefore in what a treating physician may be expected to have seen.

The clinical value is genuine. A payer holds a longitudinal view no single practice has: claims across every provider the patient has seen, medications filled rather than merely prescribed, encounters at facilities with no data-sharing relationship with your practice. For a patient with fragmented care, that view answers questions the chart cannot.

As a matter of this article’s own analysis rather than an established legal rule, the availability itself may carry a consequence worth naming before it is tested in litigation: information that is available and accessible occupies a different position from information that could not be obtained. CMS-0057-F itself does not establish a clinical standard of care or a duty to query the Provider Access API in any specific circumstance. Whether or how the availability of payer-supplied longitudinal information eventually influences expectations of reasonable information review would depend on evolving professional practice, available technology, the specific clinical circumstances, and applicable state law’ none of that currently exists as settled authority. The mirror-image obligation — the duty not to impede information that others are entitled to receive — is the subject of information blocking and its exceptions (Information Blocking and Its Exceptions: Sharing as the Regulatory Default), and the two rules bind the same organizations through the same systems.

There is a corresponding practical problem the rule does not solve. The feed is not purely claims data — it includes specified USCDI clinical data classes and certain prior-authorization information alongside claims and encounter data — but the claims-derived portion remains structured for adjudication, can lag real time, and carries diagnosis codes selected for reimbursement rather than for clinical precision. A physician treating that stream as a clinical record will be misled in predictable directions — which is the substance of the argument in interoperability without comprehensibility (Interoperability Without Comprehensibility).

The defensible posture is neither ignoring the API nor treating it as a chart. It is deciding, explicitly and as a matter of practice policy, in which clinical situations payer data will be queried — and recording that decision, so the practice can say what its standard is rather than having one inferred.

What the rule deliberately does not do

This is the section a physician should read first, because it defines the ceiling on what any of the above can deliver.

CMS-0057-F itself generally does not determine which non-drug items and services a payer may subject to prior authorization, establish gold-card exemptions, or create new substantive medical-necessity criteria — CMS has stated its intent was to streamline existing prior authorization rather than discourage its use. Other federal program rules governing Medicare Advantage utilization management and coverage criteria, other federal law, state law, and existing coverage requirements may independently constrain what a payer may require. The rule does require the Prior Authorization API to disclose the payer's own list of items and services requiring prior authorization and its documentation requirements, which is disclosure of scope, not a limit on it.

It therefore addresses the process of prior authorization and leaves the institution intact. Requests must be decided faster, denials must say why, aggregate numbers must be published, and the transaction must run over standardized interfaces. A payer may continue to require authorization for the same services on largely the same criteria, denying them within the applicable deadline with a specific reason, reported accurately in public metrics, over a compliant API — in full compliance with CMS-0057-F, subject to whatever independent limits other federal or state law may impose.

Saying this plainly is not cynicism, and it matters for two reasons. First, practices expecting substantive relief will read the rule as a failure and disengage from the parts that are genuinely useful. Second, the rule’s framing invites the confusion: language about reducing burden and streamlining describes process improvement, and is easy to hear as a promise about volume.

The substantive questions — whether a service should require authorization at all, what criteria are legitimate, who should be accountable when an algorithm participates in the decision — sit outside this rule. Two of them are the subject of algorithmic PA and human accountability (Algorithmic Prior Authorization and Human Accountability) and peer-to-peer review (Peer-to-Peer Review in Prior Authorization: Clinical Conversation, Coverage Process, and the Limits of Informal Reconsideration).

What the 2020 rule did, and why that history matters

CMS-0057-F is a second attempt, and reading it without the first attempt in view leads organizations to misjudge how much of it will actually happen on schedule.

The Interoperability and Patient Access final rule (official source) (CMS-9115-F), published in May 2020, established the Patient Access API and required payer-to-payer data exchange. The Patient Access API was implemented. The payer-to-payer requirement was not API-based, and it was not enforced.

CMS-0057-F returns to that provision and rebuilds it as an enforceable API requirement with a specification and a deadline. A regulator revisiting an unenforced mandate to reissue it in stronger form is making an implicit statement about the first attempt, and the statement is worth hearing: voluntary or unspecified data-exchange obligations, in this sector, do not self-execute.

The operational lesson for practices is a calibrated scepticism rather than dismissal. Deadlines in this area have slipped, been subject to enforcement discretion, and in one prominent case gone effectively unenforced for years. A practice that has restructured its workflow around an API being available on a given date has taken on a risk the regulatory history does not support.

The corresponding lesson is that the capabilities do eventually arrive, and the practices positioned to use them are those that instrumented their own side first. The six-field log described below is useful on day one regardless of any payer’s API readiness, which is precisely why it is the right first investment: it is the one asset whose value does not depend on someone else meeting a deadline.

Where the friction will actually be

A rule that mandates interfaces produces a predictable set of practical failures, and they are not the ones organizations plan for.

Asymmetric readiness is the first. Payers had to stand up APIs; practices had to be able to use them. The rule does not fund or universally require provider-side API capability — though specified MIPS-eligible clinicians, eligible hospitals, and CAHs do carry a 2027 attestation requirement, discussed below — and a practice whose EHR does not support the transaction, or whose vendor charges for the module, experiences a mandated API as an inaccessible one regardless.

The request-for-more-information path is the second, and it deserves care rather than the loosest reading. CMS-0057-F does not establish a uniform rule that a request for more information restarts the clock; the regulatory timeframe generally runs from receipt of the original request, though applicable program rules may permit a defined extension — often up to 14 calendar days — under specified circumstances, such as the enrollee or provider requesting it, or the plan demonstrating a need for more information that serves the enrollee’s interest. Practices should nonetheless track elapsed time from first submission to final determination, separately from the regulatory deadline itself, because only the first measure describes what the patient experienced.

The urgency classification boundary is the third, as discussed above.

The fourth is scope confusion — staff invoking the rule against non-covered commercial plans, which trains payer representatives to discount citations that are correct.

The fifth is metric interpretation. Payer-produced numbers with payer-chosen definitions will be quoted as though they settle questions they cannot settle.

None of these is a reason to disengage. They are the reason a practice needs its own submission-to-determination record, which is the single highest-value thing it can build in this area and the one thing the rule does not provide.

What a practice should actually build

The rule creates rights that are only usable with records, and the records are the practice’s responsibility.

The minimum viable instrument is a prior authorization log with six fields: payer and whether CMS-0057-F applies; date and time of first submission; track requested, expedited or standard, and the documented clinical basis for urgency; every payer communication with its date, including requests for more information; the final determination with its stated reason recorded verbatim; and elapsed time from first submission to final determination.

That log does four things nothing else can. It establishes whether a timeframe was breached, which is otherwise unprovable. It preserves stated denial reasons, making merits-based appeal possible. It measures true elapsed duration across information requests, which is the number that describes patient experience. And in aggregate it produces the practice’s own denial and delay data — independent of payer-published metrics and definitionally under the practice’s control.

The last point is the strategic one. Public reporting gives practices payer-defined numbers. A practice with its own log can compare a payer’s published performance against its own experience of that payer, and a divergence is a finding — usable in escalation, in contract negotiation, with a regulator, or with a reporter.

The cost is real but bounded: a handful of fields captured at the point of work. Practices that attempt reconstruction at the point of dispute produce nothing usable, for the same reason set out in the information blocking context — retrospective records are visibly retrospective.

The structural critique worth making

Four observations about the design, offered on the view that the rule is a genuine improvement over what preceded it.

First, process regulation without substantive limits has a predictable equilibrium. If the volume and criteria of prior authorization are untouched, a payer can comply fully while a practice’s aggregate burden is unchanged or higher — faster, better-documented, more numerous denials are a coherent compliant outcome. The rule will be judged against expectations of relief it did not undertake to provide.

Second, the rule places its principal build obligation on one side of a two-sided transaction. Payers face deadlines and technical mandates; providers receive no funding and no universal capability mandate, though specified MIPS-eligible clinicians, eligible hospitals, and CAHs carry a 2027 attestation requirement without a corresponding funding mechanism. As this article’s own analysis rather than a documented finding, the benefits most readily accrue to practices with the capital to fund vendor access, which plausibly correlates with size — a distributional question worth testing against CMS’s regulatory impact analysis and vendor-cost data rather than assuming.

Third, the request-for-more-information extension mechanism is worth watching rather than assuming settled: it permits a defined extension under specified conditions rather than an open-ended restart, but any deadline regime containing a conditional extension creates an incentive to manage the exception rather than the underlying timeline, and that is worth monitoring in practice.

Fourth, self-reported metrics with self-chosen definitions are weak accountability. Without standardized definitions of denial, of clock start, and of adjudication, published numbers are not comparable across payers, and non-comparable numbers presented as public accountability tend to produce confident misreading rather than scrutiny.

The rule is still worth engaging with. Deadlines and stated reasons are real gains, and practices that build the record to use them will get value. But it should be understood as plumbing and procedure, not as a decision about what prior authorization is for.

How this should be reported

A note for the journalists in this audience, because the rule is being covered in a way that will produce misleading stories for years.

Do not report deadlines as outcomes. That impacted payers were required to implement provisions by January 2026 establishes an obligation, not a fact about the world. The reportable questions are whether the APIs are in production, whether they are usable by practices of ordinary size, and whether decision timeframes are being met — none of which follows from the date.

Do not accept payer-published metrics as findings. As set out above, CMS prescribes the metric categories but not every denominator, and timeframe compliance depends on when the clock is treated as starting and what defined extension, if any, was applied. Any story quoting an improved denial rate without establishing those definitions is reporting a definitional artefact. The right question to a payer is not "what is your denial rate" but "what does your denominator include, and under what specific, rule-permitted circumstances do you extend the clock."

Do not report burden reduction without asking whose. The rule imposes obligations on payers and creates capabilities practices must fund themselves. A story about reduced administrative burden should establish whether small independent practices can transact against these APIs at all, and at what vendor cost.

And do not report the rule as addressing prior authorization’s scope. It does not, anywhere. A story implying that CMS has curtailed what payers may require authorization for is inaccurate, and it is the single most common error in coverage of this rule (official source).

The genuinely underreported story is the asymmetry: a regulator compelled one side of a transaction to build standardized infrastructure, left the other side to buy its own access, and described the result as burden reduction. Whether that produced relief or a new fixed cost for small practices is an empirical question nobody has yet answered.

Where state law is moving

One boundary condition matters for practices whose payer mix sits mostly outside CMS-0057-F (official source).

As set out above, the rule reaches Medicare Advantage, Medicaid and CHIP managed care and fee-for-service, and qualified health plan issuers on the federally facilitated exchanges. Commercial employer-sponsored coverage generally is not within it. Most self-funded ERISA plans sit outside CMS-0057-F and are generally not directly subject to state insurance prior-authorization mandates in the same manner as fully insured plans — but they are not beyond law: ERISA claims-procedure requirements, other applicable federal protections, plan documents, administrative appeals, and contractual provisions may still apply.

That leaves a coverage gap of real size, and it is being addressed — unevenly — at state level. A number of states have enacted prior authorization legislation addressing decision timeframes, disclosure of criteria, gold-carding for high-approval-rate physicians, and continuity of authorization across plan years. These statutes reach state-regulated commercial insurance, which is precisely the population CMS-0057-F does not.

Two cautions before relying on any of it. State prior authorization law varies substantially in scope and in what it actually requires, and it changes session to session; anything asserted here would be stale. And ERISA preemption limits what state law can do about self-funded plans, which means even a strong state statute may not reach a significant share of a practice’s commercial volume.

The practical instruction follows from the payer classification exercise recommended above, and extends it. The classification should have three categories rather than two: covered by CMS-0057-F, covered by applicable state law, and a third category best labeled not covered by CMS-0057-F — evaluate applicable state law, ERISA or other federal law, plan procedures, and contract terms separately. Knowing which of your payers sit in that third category tells you where a CMS-0057-F citation has no statutory backing, and where the analysis has to run through ERISA, other federal protections, or the participation agreement instead.

The clinical cost the rule does not measure

A final observation, because the rule's framing is administrative and the harm it addresses is not only administrative.

A seven-day standard decision timeframe is a substantial improvement over an indefinite one. It is also, for a patient in pain or facing a condition that is deteriorating, seven days. The 72-hour expedited clock exists for genuinely urgent cases, which is why the classification boundary discussed above is more consequential than it appears — a request defaulted to the standard track has cost the patient four days that the rule made available.

The clinical effects of authorization delay are not captured in any metric the rule requires. Published payer metrics will report volumes, approvals, denials, and timeframes. They will not report medication interruptions during a coverage transition, deterioration during a waiting period, treatment abandonment, or the substitution of a less appropriate covered option for an appropriate one — which is frequently how a delay resolves in practice.

This matters for how the rule should be assessed. A payer reporting full compliance with decision timeframes has told you nothing about clinical impact, and it would be a mistake to read compliance as evidence of adequacy.

It also matters for what practices should record. The six-field log described above captures administrative fact. A practice that additionally records instances where a delay or denial produced a documented clinical consequence — an interruption, a deterioration, an abandoned course of treatment — is building the only evidence base that speaks to the question the metrics cannot answer. That record is what makes an escalation, a regulatory complaint, or a conversation with a journalist substantive rather than anecdotal.

It is also, in aggregate, the material from which the case for substantive reform is eventually built. Nobody else is collecting it, because the only people positioned to see it are the practices doing the work.

Patients face the same system from the other side, with less information and no leverage over the process. The patient-facing account of how prior authorization works, what a denial actually means, and what routes exist is in the prior authorization patient guide (Prior Authorization: What It Is, Why It Can Delay Care, and What You Can Do).

What implementation actually requires on the provider side

The rule places obligations on payers and creates work for providers. The provider-side work is not described anywhere in the regulation, which is why organizations discover it late.

Four things have to be true before a practice can transact against a Prior Authorization API.

The EHR or intermediary must support the transaction. Certified health IT does not automatically include it, and support varies by product, version, and license tier. This is a question to put to a vendor in writing, naming the specific capability.

Someone must know which payers are live. Payer readiness varies, and a practice that has not mapped which of its payers can actually receive an electronic request will default to portals and fax for most volume regardless of what the rule requires.

Workflow must change. An electronic request that still requires staff to assemble clinical documentation by hand has moved the submission channel without reducing the work. The gains come from documentation that is assembled from the record rather than retyped, and that is a configuration project, not a switch.

And someone must own the deadline tracking. As set out above, the entitlements this rule creates are evidentiary; a practice that cannot produce a submission timestamp cannot assert a breach of any timeframe.

The cost question deserves a plain answer, stated with appropriate hedging: vendors can charge for modules, interface work, and in some cases per-transaction fees, and this article is not aware of a dedicated CMS reimbursement mechanism for that specific cost. For a small practice the arithmetic can favour continuing to use portals for most volume — though the 2027 attestation measure means at least one electronic submission becomes a reporting necessity for covered clinicians and hospitals regardless of the broader cost-benefit calculation.

That is the distributional point made elsewhere in this article, stated operationally. The practical mitigation is to ask the vendor for pricing before assuming capability, and to compare it against the volume of authorizations the practice actually submits.

How this interacts with the other federal mandate

CMS-0057-F and the information-blocking regulations regulate different actors under different legal tests — CMS-0057-F reaches defined impacted payers and specified MIPS/Promoting Interoperability participants, while information blocking applies to health care providers, developers of certified health IT, HINs, and HIEs. Some organizations occupy both frameworks, and frequently the same systems and vendor relationships sit underneath both. Treating them as separate projects wherever they do overlap is a common and expensive mistake.

The information blocking framework asks whether an actor interfered with access, exchange, or use of electronic health information. CMS-0057-F (cms.gov) requires specific FHIR (hl7.org) APIs to exist and function for defined payers. They are different rules with different enforcement, but they operate on overlapping plumbing and the same vendor relationships — the analysis in information blocking and its exceptions (Information Blocking and Its Exceptions: Sharing as the Regulatory Default).

Three practical consequences.

Vendor negotiation should cover both. A practice negotiating API access without addressing the capabilities its information blocking posture depends on is negotiating half its position, and the vendor holds both.

Configuration decisions answer to both. A default setting that limits what is released may be an information blocking exposure; a default that governs what is transmitted to a payer may be a CMS-0057-F question. The same engineer changes both, usually without either analysis in front of them.

And the Provider Access API sits precisely at the intersection. Payer data flowing to a treating provider is data the provider then holds, and it should determine whether and how that information is incorporated into its own records and whether it falls within the regulatory definition of electronic health information for information-blocking purposes — receipt alone does not automatically resolve that determination or create an identical onward-sharing obligation for every data element received. A practice that gains access without asking that question has acquired a capability without yet knowing what, if anything, it must do with it.

The organizational fix is the same one recommended for information blocking: one named person who holds both mandates, because the failure mode is not ignorance of either rule but the absence of anyone who sees them together.

What to ask your payers and your vendor now

The rule creates entitlements that only materialise when someone asks for them. Two short conversations, held deliberately, extract most of the available value.

With each covered payer, in writing. Which of our requests are within the scope of the decision timeframes? At what moment do you treat the clock as starting? What happens to it when you request additional information — does it pause, extend, or restart? Where are your published prior authorization metrics, and what definitions do they use for a denial and for an adjudicated request? Is your Prior Authorization API in production, and what is required of us to submit through it?

That third question is the one that matters most and is almost never asked. As set out above, a permitted extension — not an open-ended restart — is the mechanism by which compliant timeframes can still coexist with longer real-world duration than a patient experiences as “within seven days.” A payer’s answer, in writing, is worth having.

With your vendor, also in writing. Does our licensed configuration support the Prior Authorization API transaction, and at what cost? Does it support the Provider Access API? What is the implementation timeline and what professional services are required? Are there per-transaction fees? And what happens to our capability at renewal?

Ask the vendor questions alongside your information blocking requirements rather than separately — the same product governs both, and the same contract prices both.

Why in writing matters here: capability claims made verbally in a sales context have a way of becoming license-tier questions at implementation. A written answer is either accurate or a document you can point at.

And if a covered payer will not answer the clock question, that is itself worth recording. A practice with a log showing repeated timeframe questions and no substantive response has built something a regulator, or a journalist, can use.

Reading a payer’s published metrics properly

Public reporting is the component with the longest reach, because it produces material anyone can examine. Reading it well requires knowing where the definitional choices sit, and there are five.

The denominator. What counts as a request? If requests closed for insufficient information, withdrawn requests, or requests never formally adjudicated are excluded, the denial rate is computed on a filtered population and will be lower than experience suggests.

The numerator. What counts as a denial? A request closed administratively for missing documentation may not be recorded as a denial, though it functioned as one for the patient.

The clock start. Timeframe compliance depends entirely on when the clock is treated as beginning. Where a permitted, defined extension applies, elapsed real-world duration and reported duration can diverge — which is why the practice-side measure that matters is time from first submission to final determination.

The appeal treatment. An approval rate measured after appeals is a different number from an approval rate on initial determination, and the gap between them is itself informative about first-pass quality.

The unit of aggregation. Rates published across all service lines conceal the variation that matters. A payer with a high overall approval rate may deny most requests in one category.

The practical use of all this is comparative rather than absolute. A practice with its own log can hold a payer's published figures against its own record of that payer, and a divergence is a finding with somewhere to go — escalation, contract negotiation, a regulator, or a reporter. Absent that comparison, published metrics are a payer's account of itself, and quoting them as though they settle a question is how transparency requirements end up producing confident misreading rather than scrutiny.

What to do now

Classify your payer mix by whether CMS-0057-F applies — Medicare Advantage, Medicaid/CHIP managed care and FFS, and FFE qualified health plans are in; commercial and most self-funded plans are not.

Build the six-field prior authorization log. Without submission timestamps you cannot assert a breach of any timeframe.

Mark urgency deliberately and document the clinical basis; defaulting to standard forfeits the 72-hour clock.

Record stated denial reasons verbatim. A vague reason does not eliminate appeal rights, but it makes a focused, merits-based appeal substantially harder to build.

Measure elapsed time from first submission to final determination, not from the last resubmission.

Confirm your EHR or clearinghouse can actually transact against the Prior Authorization API, and what your vendor charges for it.

Read published payer metrics for their definitions before quoting them — denial, clock start, and adjudication are all definitionally contestable.

Verify the Promoting Interoperability attestation measure against current CMS rulemaking before relying on it operationally.

Process rights are worthless without process records

Every entitlement this rule creates is evidentiary. A 72-hour deadline is meaningful only to a practice that can show when it submitted. A specific-reason requirement helps only a practice that retained the reason. A public metric is checkable only against a practice’s own comparable data.

The principal build obligation is on payers, though specified MIPS-eligible clinicians, eligible hospitals, and CAHs carry their own 2027 attestation requirement, discussed below. A practice that treats this as a rule to be complied with by others will experience it as a portal change. A practice that builds a six-field log acquires the ability to assert breaches, support a merits-based appeal, and hold published metrics against its own experience; the effort required scales with volume and current documentation habits rather than being fixed. The rule delivers what a practice is instrumented to collect, and nothing more.

General educational information—not legal or medical advice

This article describes federal regulatory requirements for physicians, administrators, and journalists. It is not legal advice and creates no professional relationship. Implementation dates, applicability determinations, and Promoting Interoperability measure specifications are set and revised through rulemaking, and enforcement discretion may apply. Confirm current requirements with CMS primary sources and qualified counsel before relying on any date or obligation described here.

Questions worth asking

Which of our payers are actually covered by this rule, and does our staff know which?

Can we produce a submission timestamp for any given prior authorization request?

What proportion of our requests are submitted as standard when an expedited basis existed?

Are stated denial reasons being retained, or discarded on resubmission?

What is our true elapsed time from first submission to final determination, across information requests?

How does a payer’s published metric compare with our own record of that payer — and can we show the divergence?

Takeaway

CMS-0057-F has four principal effects: it shortens specified decision timeframes, requires denials to state a specific reason, mandates public reporting of prescribed metrics, and requires four FHIR APIs for a defined set of government-programme payers, alongside related patient-consent, reporting, and 2027 provider-attestation provisions. It does not determine what prior authorization may be required for. The gains are real and substantially evidentiary — most usable by practices that instrument their own submissions — and the principal build obligation sits with payers, even though specified clinicians and hospitals now carry their own 2027 attestation duty.

Sources and Authorities

The sources below are provided so readers can confirm the governing text and current agency guidance. Laws, regulations, agency pages, and implementation dates can change; time-sensitive requirements should be checked against the current official source.

CMS — Interoperability and Prior Authorization Final Rule CMS-0057-F — cms.gov

CMS — Interoperability Policies and Regulations — cms.gov

ASTP/ONC — Information Blocking — healthit.gov

45 C.F.R. Part 171 — ecfr.gov

HHS OCR — Right of Access — hhs.gov