CMS-0057-F Explained: Deadlines, the Four APIs and Testing Evidence (2027)

Reviewed September 2026. Every date and status below was checked against the Federal Register, the OIRA review lists, CMS's own pages and the HL7 package registry on 25 September 2026.

In brief: CMS-0057-F, the rule most people shorten to CMS-0057, is the CMS Interoperability and Prior Authorization final rule. It obliges Medicare Advantage, Medicaid and CHIP, and federal-exchange plans to decide prior authorization requests within 72 hours (expedited) or 7 calendar days (standard) since 1 January 2026, to give a specific reason on every denial, to publish prior authorization metrics every March, and to run four FHIR APIs (Patient Access with prior authorization data, Provider Access, Payer-to-Payer and Prior Authorization) from 1 January 2027. Commercial plans are not covered. The HL7 Da Vinci CRD, DTR and PAS guides are recommended, not required, but CMS says the X12 278 alone cannot satisfy the API. There is no certification. CMS-0062-P, still a proposal, would require the guides and add drug prior authorization.

CMS-0057-F readiness at a glance

Plan CMS-0057-F as two workstreams: the operational prior authorization changes that applied from 1 January 2026, and the four FHIR APIs due from 1 January 2027 (or the rating period or plan year beginning on or after it). For each, a payer needs working capability and evidence it can show an auditor or a provider partner.

Passing a test kit shows what that kit checks; it is not a certification, and CMS runs no certification program for this rule. Our prior authorization API testing guide lists the scenarios to run and the evidence pack to keep, and our CMS-0057-F implementation team can review which of the four APIs already works in your stack and what is missing.

The compliance date for the APIs is 1 January 2027 for Medicare Advantage organizations and for state Medicaid and CHIP fee-for-service programs; for Medicaid and CHIP managed care plans it is the rating period beginning on or after that date, and for Qualified Health Plan issuers on the federally facilitated exchanges the plan year beginning on or after it. One of the four, the Prior Authorization API, changes how a doctor's software talks to an insurer for the first time since HIPAA created the X12 transactions. The other three open the plan's data to members, to their doctors, and to the next insurer.

This page is the hub of a series that goes from the rule down to the code. It covers who must comply, the correct dates, the clocks, the public metrics, certification (there is none), cost, the X12 278 bridge, HTI-4 and the 1 October 2026 version update, which guide versions to build to, and what is live. Each API and guide then has its own page, linked below.

For the technical side, see how the Prior Authorization API works end to end.

Status as of September 2026

As of 25 September 2026, no CMS-0057-F deadline has moved and no delay or enforcement discretion has been announced for the 2027 APIs. The items below are what changed or was confirmed in the last month, each checked against the primary source on that date.

• No deadline has moved. CMS's Electronic Prior Authorization page, modified 14 September 2026, still says the APIs start on 1 January 2027. There is no CMS-0057-F notice in the Federal Register or on public inspection, and no related rule under OIRA review.
• X12 278 enforcement discretion reaffirmed. CMS's HIPAA enforcement discretion FAQ, updated 21 September 2026, still says HHS will not enforce the X12 278 against covered entities that use an all-FHIR prior authorization API, and still says the 278 alone cannot meet the API requirements.
• CMS-0062-P is still a proposal. Published 14 April 2026, comments closed 15 June 2026. It is not in OIRA's list of rules under review or of reviews completed in the last 30 days, so a final rule is not imminent.
• HTI-5 is at OMB. ONC's HTI-5 final rule (RIN 0955-AA09) has been under OIRA review since 28 July 2026 and has not been published.
• EHR versions change on 1 October 2026. The FY 2027 IPPS final rule moves certified EHRs to CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1 with no transition period (details below).
• 58 insurers have taken the industry pledge. CMS's 10 September 2026 summary counts 58 insurers in the June 2025 prior authorization pledge and reports an estimated 11% reduction in prior authorization volume in some cases.
• Epic's CRD is in production. Epic reports real-time CRD checks live at Ochsner Health, Froedtert ThedaCare Health, Denver Health and Summit Health with UnitedHealthcare, Network Health and Aetna, and sixteen more payers in testing.
• No new readiness data yet. WEDI opened its fourth readiness survey on 7 September 2026; the February 2026 survey remains the latest.

This block is updated monthly. If you are scoping the build now, our CMS-0057-F implementation services page sets out how engagements are structured, and the CMS-0057-F readiness assessment gives a first read on where a plan stands.

CMS-0057-F deadlines: the correct dates

CMS-0057-F has three payer dates: 1 January 2026 for the decision clocks and denial reasons, 31 March 2026 for the first public metrics, and 1 January 2027 for the four APIs. Several pages that rank for the rule still print the API date as 2026 or the first report as 2027; both are wrong.

Dates in CMS-0062-P (drug prior authorization from 1 October 2027, required guide versions later) are proposals only, and nothing in the rule text requires real-time decisions.

Who must comply with CMS-0057, and who does not

CMS-0057 applies to impacted payers: Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care plans, and Qualified Health Plan issuers on the federally facilitated exchanges. Commercial and employer-sponsored plans are not impacted payers, and neither are state-based exchange plans. CMS counted 365 parent organizations in its regulatory impact analysis.

That exemption is narrower than it sounds, for two reasons. First, HHS's HIPAA enforcement discretion covers every covered entity, commercial payers and providers included, that uses an all-FHIR prior authorization API instead of the X12 278. Second, CMS-0062-P would adopt FHIR as the HIPAA prior authorization standard for every covered entity if it is finalized. The regulatory obligation stops at the government-funded plans; the technical shift does not.

Because CMS pays these plans, it can condition that money. That chain, CMS to plan to provider, is why the rule has teeth with health plans and only indirect pull with doctors. Enforcement runs through each program's existing oversight: Medicare Advantage contracts, state oversight of Medicaid and CHIP, and QHP certification on the exchanges.

The four APIs and what each must do

CMS-0057-F requires four FHIR APIs by 1 January 2027: Patient Access, Provider Access, Payer-to-Payer and the Prior Authorization API. The Provider Directory API from the 2020 rule continues unchanged.

• Patient Access API, in place since the 2020 rule, now extended with prior authorization requests and decisions: status, dates, items, quantities and the denial reason, available within one business day of a change. Drug prior authorizations are excluded. Plans also report usage metrics to CMS each year. Details, and the gaps most implementations carry, are in our guide to the Patient Access API.
• Provider Access API, new: an in-network provider with an attributed treatment relationship can request a patient's claims and encounters (excluding remittances and cost-sharing), USCDI clinical data and prior authorization data, individually or in bulk, and the payer responds within one business day. Patients may opt out, and the payer must run an attribution process.
• Payer-to-Payer API, new: when a member joins and opts in, the new plan requests the previous five years of history from the previous or concurrent payer, including prior authorizations other than denied ones and their supporting documents. The answering plan responds within one business day. Both flows are covered in Provider Access and Payer-to-Payer APIs.
• Prior Authorization API, new and the only two-way door: it must list which items and services need approval, identify the documentation each requires, accept a request, and return a decision that approves with an end date, denies with a specific reason, or asks for more information. The build is covered in Prior Authorization API requirements.

The four APIs serve different users. The member chooses an app for Patient Access; Provider Access and Payer-to-Payer serve separate exchange contexts; the Prior Authorization API is the only one that takes a request and returns a decision.

What the 72-hour and 7-day clocks require

Since 1 January 2026, impacted payers must decide expedited prior authorization requests within 72 hours and standard requests within 7 calendar days, and every denial must carry a specific reason. The clocks apply to items and services, not drugs, and QHP issuers on the federally facilitated exchanges are exempt from them.

Four details decide whether a plan is actually meeting the clocks.

• The channel does not matter. CMS's summary says the specific denial reason is required "regardless of the method" of the request, so fax, phone and portal requests are held to the same standard as API requests.
• A decision has three valid shapes. CMS's Prior Authorization API FAQ says a response approves (with an end date or circumstance), denies with a specific reason, or requests more information.
• Managed care runs on its own calendar. Medicaid managed care plans and CHIP managed care entities comply from the rating period beginning on or after 1 January 2026.
• Real time is not required. CMS's FAQ says the final rule "did not include a requirement for impacted payers to use the Prior Authorization API to make real-time decisions." The clocks are the requirement; real-time answers are an industry commitment, not a rule.

Staffing alone rarely closes the gap. The work that does is triage on arrival, automation of clean approvals, and a clock per request that the whole team can see. CMS-0062-P would add drug timeframes (24 hours expedited and 72 hours standard for some programs, 24 hours for all requests in Medicaid and CHIP), but that is proposed only.

The public prior authorization metrics

Impacted payers must post prior authorization metrics for the previous calendar year on their own website by 31 March each year, starting with calendar 2025 data in March 2026. Medicare Advantage reports at contract level, states at state level, managed care plans at plan level and marketplace issuers at issuer level, using a CMS template.

The nine metrics are: the list of items and services that need prior authorization; the percentage of standard requests approved; denied; and approved after appeal; the percentage where the timeframe was extended and the request approved; the percentages of expedited requests approved and denied; and the average and median time to decision for standard and for expedited requests. Approvals after appeal count as approvals, appeals aggregate every level, and each request in an episode of care counts separately.

Separately, payers report Patient Access API usage to CMS each year: the number of unique patients whose data went to an app, and the number whose data went more than once. CMS-0062-P proposes more metrics, including drug prior authorization metrics and usage metrics for the other APIs, and CMS's FAQ pages now point to it.

AuthDenied, an independent tracker of the posted metrics, reported in its July 2026 snapshot that 1,281 of 1,378 required plans had posted, that the median denial rate was 7.2% in Medicare Advantage and 12 to 14% in Medicaid, CHIP and marketplace plans, and that only 7.3% of denials were appealed. We cite these as reported; check the tracker for its denominators and method. The point for a plan is that the numbers are now a public table anyone can sort.

Is there a CMS-0057-F certification?

No. CMS does not certify payers or vendors for CMS-0057-F; impacted payers self-attest and must be able to show the APIs work. A vendor claiming CMS certification for this rule is describing something that does not exist.

What exists instead is evidence. CMS expects payers to implement the APIs and then routinely test and monitor them. A defensible file holds conformance runs against ONC's Inferno test kits, validator output, connectathon logs, and records of live exchanges with an EHR, a hub and another payer. We explain how payers prove CMS-0057-F compliance without a certification, and our CMS-0057-F testing guide walks through Inferno, the HL7 Foundry bundle and the sandboxes that make up that evidence pack.

ONC certification does exist on the EHR side: the HTI-4 criteria certify EHR developers, not payers. That distinction is covered in the HTI-4 section below.

What it costs: CMS's own estimate

CMS's regulatory impact analysis put the ten-year cost of the rule at $1.6 billion, with a low estimate of $0.8 billion and a high of $2.3 billion, spread across 365 parent organizations. It estimated savings for physician practices of at least $15.8 billion and 220 million hours over ten years.

Treat these as a floor. Commenters told CMS the estimates were "significantly understated", and CMS replied that they had not supplied data it could use. WEDI's February 2026 survey found 25% of responding payers expecting to spend more than $5 million, up from 15% in October 2025. The biggest unbudgeted items are usually not the APIs: they are turning medical policy documents into structured rules for DTR, and connecting delegated review vendors.

The loop that did not exist before

The Prior Authorization API replaces a fax-and-phone loop with a conversation between the EHR and the payer that starts when the clinician signs the order. Three HL7 Da Vinci guides carry that conversation.

Before the rule, a clinic learns from a PDF or a portal that a service needs approval, phones or faxes a request with clinical notes, and waits, with no reason on the denial and no visibility of where the request is.

After the rule, the EHR fires a CDS Hook to the payer when the clinician signs the order, and the payer answers in about five seconds: covered, approval needed, documents needed. That is Da Vinci CRD (Coverage Requirements Discovery). If documentation is needed, the payer sends a questionnaire with logic that pre-fills answers from the chart; that is Da Vinci DTR. The completed form becomes a FHIR request submitted through Da Vinci PAS and the X12 278, with a 15-second target for a synchronous answer and a subscription that pushes the decision back when the payer needs longer.

In vendor-reported pilots presented at HL7 Da Vinci and industry sessions, somewhere between half and 80% of CRD calls returned "no approval needed". Those figures are self-reported, but the direction is consistent: that one answer removes most of the phone calls, and it is why experienced implementers build CRD first.

The X12 278 bridge and enforcement discretion

An impacted payer can run its Prior Authorization API entirely on FHIR without sending an X12 278, because HHS announced on 28 February 2024 that it will not enforce the HIPAA 278 standard against covered entities that use an all-FHIR prior authorization API. CMS reaffirmed that position in the FAQ it updated on 21 September 2026.

The same FAQ closes the other door: a payer cannot meet the API requirement with the X12 278 alone, because the 278 "cannot meet the other requirements", namely publishing which services need approval and what documentation each needs. In practice most plans run both rails. Their utilization management systems, clearinghouses and delegated review vendors still speak X12, so the FHIR API sits in front and a translation layer carries each request across. The PAS guide describes exactly that: an intermediary converts the FHIR Bundle into an X12 278 plus any unsolicited 275 attachments, and makes the full FHIR Bundle available to the payer.

The detailed element-level mapping between PAS and the 278 is published by X12, not HL7, and needs an X12 licence. Round-trip fidelity is where these bridges fail: an HCR code with no FHIR equivalent in the response, or a supporting document that never reaches the reviewer. CMS-0062-P would go further and replace the 278 with FHIR as the HIPAA standard, but only if it is finalized.

HTI-4 and the 1 October 2026 IPPS version update

HTI-4 is how the rule reaches providers: ONC finalized it on 31 July 2025, inside the FY 2026 IPPS final rule, and it added three certification criteria for EHRs: 170.315(g)(31) for CRD, (g)(32) for DTR and (g)(33) for PAS. The FY 2027 IPPS final rule, published 4 August 2026 and effective 1 October 2026, then moved those criteria to CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1, replacing 2.0.1 with no transition period.

The same FY 2027 rule updated other standards in 45 CFR 170.215: CARIN Blue Button 2.2.0, US Drug Formulary 2.1.0, Plan-Net 1.2.0 and CDex 2.1.0, while PDex stays at 2.1.0. It also finalized the hospital Electronic Prior Authorization measure: optional for 10 bonus points in 2027, required from 2028, and in 2027 any one of (g)(31) to (g)(33) counts. The matching MIPS change for clinicians is only proposed, in the CY 2027 Physician Fee Schedule proposed rule.

Two practical effects follow. First, from 1 October 2026 the EHRs calling a payer's CRD, DTR and PAS endpoints are being certified to the 2.2 guides, so a payer that serves only 2.0.1 or 2.1 will meet newer clients. Second, CMS cannot order physicians to use the APIs, but it can make the EHR ready and reward its use, which is why Epic shipped CRD, DTR and PAS in its February 2026 version and went live with CRD in August. Providers will not adopt one app per payer; the EHR is the door, and a payer's job is to be reachable through it. HTI-5, now at OIRA, proposes to keep (g)(31) to (g)(33).

Which IG versions to build to

Build the payer side to CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1, and keep a 2.0.1 or 2.1 path open for EHR partners that have not moved. That is the version family certified EHRs must use from 1 October 2026 and the one CMS-0062-P proposes to require.

The reasoning, in three parts. CMS's standards page lists the 2.0.x and 2.1.0 versions of each guide and flags the older ones as derived from standards that expired on 1 January 2026 (USCDI v1, US Core 3.1.1 and SMART 1.0.0). The guides themselves did not expire: HTI-4 adopted CRD, DTR and PAS 2.0.1 into 170.215, and the FY 2027 IPPS rule replaces them with the 2.2 versions. And CMS lets payers use newer versions ONC has approved, as long as the change does not disrupt an end user's access to the data. With the 2.2 guides now in 170.215, our reading is that a payer can build to 2.2 today under CMS-0057-F without waiting for CMS-0062-P; have counsel confirm that before it goes into a contract.

The baseline underneath is FHIR R4 (4.0.1), US Core 6.1.0, SMART App Launch 2.0.0 and USCDI v3. For the data-sharing APIs, CMS lists CARIN Blue Button and PDex 2.1.0; HL7 published PDex 2.2.0 on 22 August 2026, but ONC's 170.215 still names 2.1.0. Version drift is real work: the Availity team described moving payers from Da Vinci 2.0 to 2.1 as something that "doesn't look like much when you look at the specification" until the mapping and dual running start. Running two versions side by side, as the servers below do, is the cheapest way to absorb it.

Open-source CRD, DTR and PAS servers tested with Inferno

Nirmitee publishes open-source payer servers for all three Da Vinci prior authorization guides, and each has been run against ONC's Inferno test kits on the public inferno.healthit.gov instance. The results, with the session links, are published in each repository as conformance evidence.

• Open-source Da Vinci CRD server (Inferno results): 136 pass and 0 fail on the CRD Server v2.2.1 suite, and 86 pass and 0 fail on v2.0.1 (CRD Test Kit v0.14.2).
• Open-source Da Vinci PAS server (Inferno results): 84 of 84 on the PAS Server v2.2.1 suite and 68 of 68 on v2.0.1 (PAS Test Kit v0.15.2).
• Open-source Da Vinci DTR server (Inferno results): 43 pass and 2 fail on the DTR Payer Server v2.2.0 suite, and 17 pass and 2 fail on v2.0.1 (DTR Test Kit v0.18.0). It passes the DTR payer server suites apart from two Inferno test-kit issues (one open, one fixed upstream and awaiting deployment), filed as #130 and #131.

Each server is written twice, in Go and in .NET, with identical results, runs two guide versions side by side, and uses a synthetic health plan with synthetic members. They are CMS-0057-F-aligned reference builds tested with ONC's Inferno test kits; in a payer rollout the same services connect to the payer's own policies, utilization management system and delegated vendors. Inferno checks conformance to the requirements it tests, which is exactly the evidence the no-certification model asks a payer to keep.

The actors in a prior authorization request

A prior authorization request touches more organizations than the two names on it, and the two that decide whether an implementation works do not own a FHIR server: the utilization management team and the delegated review vendors.

Around them sit the patient, the provider and the EHR vendor whose software fires the hooks; clearinghouses that carry X12 today and hubs that connect many providers to many payers; the pharmacy benefit manager that holds drug data; and CMS, ONC, HL7 Da Vinci, WEDI and the states above them. The UM team's policies are usually documents, and DTR needs them as structured, reviewed criteria. The delegated vendors are usually not connected, and the plan's single API must answer for all of them. WEDI's surveys name delegated third parties and digitizing prior authorization policies among the top challenges. Our payer reference architecture for delegated vendors shows one way to put that together.

What is live today

As of September 2026, the Prior Authorization API is arriving mainly through Epic, while Provider Access and Payer-to-Payer are not yet live at scale. Patient Access, the 2021 API, is live broadly but unevenly.

Epic's post names the first CRD production sites (Ochsner Health, Froedtert ThedaCare Health, Denver Health and Summit Health) and the live payers (UnitedHealthcare, Network Health and Aetna), with sixteen more payers in testing; press coverage dated the launch 17 August 2026. UnitedHealthcare's public interoperability page now describes all four APIs, with Provider Access and the Prior Authorization API marked "Coming soon". Cambia Health Solutions (Regence) has described in public Da Vinci sessions running CRD, DTR and PAS in-house since 2022; treat that as the payer's own account.

For Patient Access, Flexpa's public directory listed 541 payer endpoints across 424 organizations in our 2 September 2026 snapshot, of which 345 were connected and the rest broken, unavailable, in progress or unknown. "Connected" means an app can complete OAuth and pull claims; it says nothing about the three new APIs. Statuses change daily, so check the directory before drawing conclusions about any one payer.

What comes next: CMS-0062-P

CMS-0062-P is the proposed follow-on rule, published 14 April 2026 with comments closed on 15 June 2026, and as of 25 September 2026 it is neither final nor under OIRA review. Everything in this section is a proposal that may change.

As proposed, it would make payers use CRD, DTR and PAS version 2.2; extend prior authorization to drugs on two rails, FHIR for medical-benefit drugs and NCPDP SCRIPT for pharmacy-benefit drugs; set drug decision times; require payers to report their API endpoints to CMS within 60 days of the effective date; add drug prior authorization metrics and usage metrics for the Provider Access, Payer-to-Payer and Prior Authorization APIs; and replace the X12 278 with FHIR as the HIPAA prior authorization standard. Our CMS-0062-P proposed rule explainer tracks it.

Where to start

Start with three questions: which of the four APIs exist today and actually return data, whether your prior authorization rules live in a database or in documents, and what your platform does not cover (policies, delegated vendors, connections to the doctors' systems). The answers set the order of work.

The order that experienced teams follow is the data plane and identity first, then CRD, because "is approval needed" is the largest win and needs no questionnaire content, then DTR and PAS, then conformance against the Inferno kits and a connectathon. The CMS-0057-F implementation planning kit turns that into a plan, and our readiness scoping guide lists what to scope before any code is written.

Explore the CMS-0057-F series

• CMS Prior Authorization API: FHIR requirements for 2027
• Da Vinci CRD explained: Coverage Requirements Discovery
• Da Vinci DTR: questionnaires, CQL rules and implementation
• Da Vinci PAS explained: FHIR prior authorization and X12 278
• Patient Access API: CMS-9115 gaps and the 2027 additions
• Payer-to-Payer and Provider Access APIs
• CMS-0057-F payer architecture for delegated vendors and the delegated entity problem
• CMS-0057-F API testing: Inferno, sandboxes and evidence
• CMS-0057 compliance without a certification program
• CMS-0062-P explained and what electronic prior authorization means

Need help turning the rule into running APIs? Our healthcare interoperability team builds the FHIR, CDS Hooks, questionnaire and PAS services and the X12 bridge behind them, and our healthcare AI agents practice automates the review work that the clocks put pressure on. Talk to our team.

Sources

• CMS-0057-F final rule, 89 FR 8758 (8 February 2024), including the regulatory impact analysis
• CMS-0057-F fact sheet
• CMS Electronic Prior Authorization page (modified 14 September 2026)
• CMS, Electronic Prior Authorization: Industry Commitments and Finalized and Proposed Rulemaking (10 September 2026, PDF)
• CMS APIs and relevant standards and implementation guides
• CMS Prior Authorization API FAQ (modified 21 September 2026)
• CMS HIPAA transaction enforcement discretion FAQ (modified 21 September 2026)
• CMS Patient Access API FAQ
• CMS Provider Access API FAQ (modified 10 September 2026)
• CMS Payer-to-Payer API FAQ
• FY 2027 IPPS/LTCH final rule, FR doc 2026-15833 (ONC 170.215 updates, effective 1 October 2026)
• FY 2026 IPPS final rule including HTI-4, FR doc 2025-14681
• HTI-5 proposed rule, FR doc 2025-23896 and the OIRA review list (RIN 0955-AA09)
• CMS-0062-P proposed rule, FR doc 2026-07205 (14 April 2026)
• HL7 Da Vinci CRD 2.2.1, DTR 2.2.0, PAS 2.2.1 and PDex 2.2.0
• ONC Inferno test kits
• Epic: payers, providers and Epic launch real-time prior authorization checks and HIT Consultant coverage (17 August 2026)
• UnitedHealthcare interoperability APIs page
• WEDI readiness survey results (March 2026) and fall 2026 survey announcement
• Flexpa endpoint directory (snapshot 2 September 2026)
• AuthDenied prior authorization metrics tracker
• Availity remark on Da Vinci version drift: recorded session, youtube.com/watch?v=x3CN3wJqlOA (spoken remarks, auto-captioned)