In brief: CMS-0057-F obliges Medicare Advantage, Medicaid and CHIP, and federal-exchange plans to decide prior authorization requests within 72 hours (expedited) or 7 days (standard) since 1 January 2026, to give a specific reason on every denial, to publish prior authorization metrics each March, and to run four FHIR APIs (Patient Access with prior authorization data, Provider Access, Payer-to-Payer and Prior Authorization) from the 2027 compliance dates. Commercial plans are not covered by the rule. The HL7 Da Vinci CRD, DTR and PAS guides are recommended, not required, but CMS says the X12 278 alone cannot satisfy the API. Real-time decisions are not required. CMS-0062-P, still a proposal, would require the guides and add drug prior authorization.
From 1 January 2027, CMS-0057-F requires impacted payers to operate four FHIR APIs. The compliance date is 1 January 2027 for Medicare Advantage organizations and for state Medicaid and CHIP fee-for-service programs (states may request an extension or exemption from CMS); 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 them, the Prior Authorization API, changes how a doctor's software talks to an insurer for the first time since HIPAA created the X12 transactions in 1996. The other three open the plan's data to members, to their doctors, and to the next insurer.
This is the first post in a series that goes from the rule down to the code. Here we cover what CMS-0057-F is, who it applies to, what it demands and when, why CMS wrote it, how it reaches providers through EHR certification, which HL7 Da Vinci guides and versions it names, and what is actually live as of September 2026. The next posts take CRD, DTR and PAS one at a time, then the architecture for a plan with delegated vendors, then how to test.
Everything here is sourced from the rule, the CMS FAQ pages, the HL7 guides and public monitoring data, with links in the Sources section. Where a figure comes from a vendor presentation or a third-party tracker we say so and have not independently verified it.
Who is obligated, and who is not
CMS-0057-F applies to what the rule calls 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. CMS counted about 365 parent organizations in its regulatory impact analysis. Commercial and employer-sponsored plans are not impacted payers, and neither are state-based exchange plans.
That exemption is narrower than it sounds, for two reasons. First, in February 2024 HHS announced enforcement discretion under HIPAA: it will not take action against any covered entity, commercial payers and providers included, that uses an all-FHIR prior-authorization API instead of the X12 278 transaction. Second, the proposed follow-on rule, CMS-0062-P, would adopt FHIR as the HIPAA prior-auth standard for every covered entity about two years after it is finalised. The regulatory obligation stops at the government-funded plans; the technical shift does not.
Because CMS pays these plans per member, 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. We come back to the provider side below.
What the rule demands, by date
The rule was released on 17 January 2024 and published in the Federal Register on 8 February 2024 (89 FR 8758). Its obligations arrive in two waves.
Since 1 January 2026, in force now. Impacted payers must decide expedited prior-auth requests within 72 hours and standard requests within seven calendar days. Marketplace plans are exempt from the timeframes. Every denial must carry a specific reason, whatever channel the request came through: portal, fax, phone or API. And payers had to start collecting the metrics they would publish.
Posted by 31 March 2026, already public. Nine prior-auth metrics for calendar 2025 on the payer's own website: 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 expedited requests. Medicare Advantage reports at contract level, states at state level, managed-care plans at plan level, marketplace issuers at issuer level. CMS provides a reporting template. Approvals after appeal count as approvals in the total, appeals aggregate every level, and each request in an episode of care counts separately.
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, that more than half of appealed denials were overturned, and that only 7.3% of denials were appealed. We cite these as reported; check the tracker for its denominators and method. What matters for a plan is that the numbers are now a public table anyone can sort, and next year's table will include the first full year under the seven-day clock.
By 1 January 2027. Four FHIR APIs in production:
- Patient Access API, which has existed since the 2020 rule, now extended with prior authorization requests and decisions: status, dates, expiry, items, quantities and the denial reason, available within one business day of any change and kept for at least a year after the last status change. Drug prior authorizations are excluded, as are provider remittances and enrollee cost-sharing. Plans also report usage metrics to CMS each year: unique patients whose data went to an app, and how many pulled more than once.
- 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 must respond within one business day of the request. Patients may opt out, and the payer must have an attribution process and educational material for members and providers.
- Payer-to-Payer API, new: when a member joins, the new plan asks them to opt in and name previous or concurrent payers, then requests five years of history including approved prior authorizations and their supporting documents. The old plan answers within one business day. Concurrent payers exchange at least quarterly.
- Prior Authorization API, new and the only two-way door: it must publish which services need approval, state what documentation each requires, accept a request, and return a decision with an approval period or a specific denial reason.
Providers get a measure of their own. The MIPS Promoting Interoperability program adds an Electronic Prior Authorization measure: attest to at least one request made through a payer's API, or claim an exclusion. CMS's own page (August 2026) notes the hospital version is an optional bonus in 2027 and mandatory from 2028.
The Provider Directory API from the 2020 rule continues unchanged: a public, unauthenticated FHIR directory updated within 30 days.
The four APIs serve different users. In the first lane, the member chooses an app; the payer supplies the permitted data to that app. Provider Access and Payer-to-Payer serve separate exchange contexts.
Why CMS wrote it
The rule's fact sheet leads with provider burden. The AMA's physician surveys report roughly 12 to 13 hours of practice time a week on prior authorization and a large majority of physicians saying it delays care; CMS's electronic prior authorization page estimates the annual cost per provider in the tens of thousands of dollars. The AMA survey is linked in the Sources; the specific numbers change each survey year.
The oversight case came from the HHS Office of Inspector General. In April 2022 (report OEI-09-18-00260) it sampled 250 prior-auth denials and 250 payment denials from the 15 largest Medicare Advantage organizations. Thirteen percent of the prior-auth denials met Medicare coverage rules; those patients would have been approved under original Medicare. Eighteen percent of payment denials met both Medicare and plan billing rules. The causes were plans applying clinical criteria beyond Medicare's, "insufficient documentation" findings despite adequate records, and manual and system errors. All three of the OIG's recommendations to CMS were implemented between 2023 and 2025.
CMS's regulatory impact analysis priced the whole rule at $1.56 billion over ten years (range $0.8 to $2.3 billion), with the federal government carrying about $793 million through capitation and Medicaid match, against at least $15.8 billion and 220 million hours saved by physician practices over 2027 to 2036. Per organization it priced the Prior Authorization API at 10,880 hours and about $1.14 million, Provider Access at 2,800 hours and $270,000, Payer-to-Payer at 916 hours and $96,000, plus 25% a year to maintain. CMS acknowledged in the rule that commenters called these figures "significantly understated" and that it lacked data to revise them. WEDI's March 2026 readiness survey (linked in the Sources) reports a quarter of responding payers expecting to spend over $5 million.
The loop that did not exist before
The clearest way to see what the Prior Authorization API changes is to draw the old and new loops.
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. There is no reason on the denial and no visibility of where the request is. Nothing in that loop is faster than a person.
After the rule, the EHR fires a CDS Hook to the payer when the clinician signs the order. The payer answers in about five seconds: covered, approval needed, documents needed. That is Coverage Requirements Discovery, or CRD. If documentation is needed, the payer sends a questionnaire with logic that pre-fills answers from the chart; that is Documentation Templates and Rules, DTR. The completed form becomes a FHIR request submitted through Prior Authorization Support, PAS, with a target of 15 seconds for a synchronous answer and a subscription that pushes the decision back when the payer needs longer. The clinician sees the decision in the chart, the member sees it through Patient Access, and every request feeds the public metrics.
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 by the vendors involved, but the direction is consistent: that one answer removes most of the phone calls, and it is why experienced implementers advise building CRD first.
CRD discovers requirements, DTR gathers documentation, and PAS carries the request and response. Additional information can be needed before a decision is reached.
How the rule reaches providers: HTI-4 and the EHR
CMS cannot order physicians to use these APIs. It works through the EHR vendors instead, and the mechanism is worth understanding because it explains why Epic moved.
ONC's certification rules for health IT live at 45 CFR 170.315. HTI-1 (January 2024) set the data baseline: USCDI v3 by 1 January 2026, SMART App Launch version 2, public endpoint publication monitored by ONC's Lantern tool. The HTI-4 amendments added three certification criteria for provider prior authorization right after the g10 API criterion: coverage requirements discovery as a CRD client, documentation templates and rules, and prior authorization support. A clinician attesting to the MIPS electronic prior-auth measure needs certified health IT that can do this.
The effect arrived on schedule. Epic's release documentation describes native CRD, DTR and PAS in its February 2026 version as "constructed around the Da Vinci 2.1 FHIR IG, though it does not follow it exactly," and Epic announced on 17 August 2026 that real-time CRD checks were live with UnitedHealthcare, Aetna and Network Health, with more payers in testing (links in the Sources). MEDITECH, athenahealth, eClinicalWorks, Oracle Health, Modernizing Medicine and TruBridge were named in CMS's 13 May 2026 press release on electronic prior authorization early adopters. Providers will not adopt a separate app per payer; a health system's staff shown a single-payer SMART app at a Da Vinci session put it as "I can't have 40 apps." The EHR is the door, and a payer's job is to be reachable through it. If you integrate with Epic today, our Epic FHIR API integration work is the starting point for the CRD and DTR registrations.
The actors, so the rest of the series makes sense
A prior-auth request touches more organizations than the two names on it. The patient. The provider and the EHR vendor whose software fires the hooks. The layer in between: clearinghouses that carry X12 today, hubs like Availity that connect many providers to many payers, and the TEFCA networks that move documents. Inside the plan: the utilization-management team that owns the medical policy, the delegated review vendors who decide whole categories (imaging, genetic testing, home health, DME, behavioral health), the pharmacy benefit manager that holds drug data, and whichever FHIR platform or vendor the plan bought. Above them: CMS, ONC, HL7 Da Vinci, WEDI, the OIG and the states.
Two of these actors decide whether an implementation works, and neither of them owns a FHIR server. The UM team's policies are usually documents, and DTR needs them as structured, reviewed criteria before questionnaires and rules can be written. The delegated vendors are usually not connected, and the plan's single API must answer for all of them. WEDI's readiness surveys name policy content and vendor coordination among the top challenges, and they are where most of the unbudgeted effort goes.
The standards: required, recommended, and expiring
The rule requires standards and recommends implementation guides. The required floor, cross-referenced from ONC's 45 CFR 170.215, is FHIR R4 (4.0.1), US Core, SMART App Launch, OpenID Connect and USCDI. The recommended guides are HL7 Da Vinci's: CARIN Blue Button for claims, PDex for clinical and prior-auth data and for the Provider Access and Payer-to-Payer flows, Plan-Net for the directory, and CRD, DTR and PAS for prior authorization.
Three things about versions trip people up. First, the versions CMS named in 2024 (US Core 3.1.1, SMART 1.0.0, USCDI v1, and the 2.0.x Da Vinci guides) are marked on CMS's standards page as expired on 1 January 2026; the operative set is US Core 6.1.0, SMART 2.0.0, USCDI v3, CARIN 2.1.0, PDex 2.1.0, Plan-Net 1.2.0, and CRD, DTR and PAS 2.1.0. Second, payers may move to newer versions ONC has approved as long as the move "does not disrupt an end user's ability to access the data," and CMS-0062-P proposes to make that automatic. Third, the guides are "strongly recommended," not required, under this rule, but CMS's own FAQ says the X12 278 alone "cannot meet the other requirements," so the guides are the only published way to satisfy the four capabilities, and 0062-P would require them outright. Build to 2.1 now and plan for the 2.2 family by 2028. One caution for the rest of this series: where we quote a requirement from a 2.2 guide, it does not automatically bind a 2.1 implementation; check the version you are building to.
Two common misreadings, settled by the CMS FAQs. Real-time decisions are not required: "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. And the guides being recommended does not make the capabilities optional.
What is live today
As of the first week of September 2026, the picture is uneven. Flexpa's public directory of payer Patient Access endpoints, the 2021 API, listed 541 payer endpoints across 424 organizations in our 2 September 2026 snapshot: 345 connected, 32 broken, 41 unavailable, 13 in progress and 110 of unknown status (Flexpa's own status labels). "Connected" means an app can complete OAuth and pull claims; it says nothing about the three new APIs. Some broken endpoints belong to national plans, and by our count several state Medicaid agencies have no working endpoint listed.
Provider Access and Payer-to-Payer are not yet live at scale. The HL7 Da Vinci implementation tracker shows a small number of payers in development, and Availity's payer-to-payer cohort announcement describes payers in end-to-end testing rather than production. The Prior Authorization API is arriving mainly through Epic's program. Cambia Health Solutions (Regence) has described in public Da Vinci sessions building CRD, DTR and PAS in-house from 2022 with real-time responses for most eligible requests; treat that as the payer's own account. Aetna's public developer portal lists all six APIs by name, which is unusual among national payers whose portals mostly list Patient Access and Provider Directory.
Usage of Patient Access remains modest. Flexpa's November 2025 review of 493 payers found most require non-standard OAuth scopes and undocumented limits, and that unresponsive payers leave app developers "in limbo for 1+ years." The API exists on paper; the developer experience is what makes it real.
What comes next: CMS-0062-P
The proposed follow-on rule was published on 14 April 2026 and comments closed on 15 June 2026. No final rule had been published when this was written, so everything in this section is a proposal that may change. It would make the Da Vinci guides required, with current versions on 1 January 2027 and the 2.2 family by 1 January 2028; extend prior authorization to drugs from 1 October 2027 on two rails, FHIR for medical-benefit drugs and NCPDP SCRIPT for pharmacy-benefit drugs, with 24-hour decisions for Medicaid; require every payer to publish its endpoints and capability statements to CMS within 60 days of the final rule; add six prior-auth metrics, fifteen drug metrics and usage metrics for all four APIs; and replace the X12 278 with FHIR as the HIPAA standard about two years later. Its impact analysis adds a second wave of cost while plans are still finishing the first.
What to do with four months
If you are at an impacted plan, three questions sort your situation. Which of the four APIs exist today, does Patient Access actually work when a member's app calls it, and could you answer a Provider Access request within one business day? Are your prior-auth rules in a database or in documents? Have you chosen a platform, and what does it not cover: your policies, your delegated vendors, your connection to the doctors' systems?
If you build or run software for plans, the order of work is settled by experience: the data plane and identity, then CRD because "is approval needed" is the largest win and needs no policy content, then DTR and PAS, then conformance against the Inferno kits and a connectathon. The next post in this series takes CRD apart, from CDS Hooks discovery to the five-second answer.
Nirmitee builds these APIs and the plumbing under them: FHIR servers that pass the government test suites, SMART and Backend Services, the CDS Hooks and questionnaire services, the PAS server and the X12 bridge, and the policy digitization that DTR needs. Our CMS-0057-F interoperability suite page has the readiness assessment; our FHIR integration services and HL7 integration services pages cover the rest of the stack.
Explore the CMS-0057-F series
- CMS-0057-F Explained: Requirements and 2027 API Deadlines (this article)
- Da Vinci CRD Explained: Coverage Requirements Discovery
Related reading on this site: CMS-0057-F readiness: what to scope before you write any code, CMS-0062-P explained, What is electronic prior authorization? and CMS interoperability rules in 2026. - Da Vinci DTR Explained: Questionnaires, CQL and Prior Authorization - Da Vinci PAS Explained: FHIR Prior Authorization and X12 278 - CMS-0057-F Payer Architecture for Delegated Vendors - CMS-0057-F API Testing: Inferno, Sandboxes and Evidence
Sources
- CMS-0057-F final rule, 89 FR 8758 (8 February 2024)
- CMS-0057-F rule text (PDF)
- CMS-0057-F fact sheet
- CMS standards and implementation guides by API (updated 14 April 2026)
- CMS Prior Authorization API FAQs
- CMS Patient Access API FAQs
- CMS Provider Access API FAQs
- CMS FAQs on the HIPAA transaction enforcement discretion
- CMS-0062-P proposed rule, Federal Register 2026-07205 (14 April 2026)
- CMS-0062-P fact sheet
- HHS OIG report OEI-09-18-00260 (April 2022)
- HL7 Da Vinci CRD 2.2.1 (current) and 2.1.0
- HL7 Da Vinci DTR 2.2.0 (current) and 2.1.0
- HL7 Da Vinci PAS 2.2.1 (current) and 2.1.0
- HL7 Da Vinci PDex 2.2.0
- Epic: payers, providers and Epic launch real-time prior authorization checks (August 2026)
- HIT Consultant on Epic CRD deployment (17 August 2026)
- open.epic playbooks
- Flexpa endpoint directory (snapshot taken 2 September 2026)
- Flexpa, State of the Payer Patient Access API (November 2025)
- AuthDenied prior authorization denial-rate tracker
- WEDI survey, March 2026
- WEDI survey, December 2025
- AMA prior authorization physician survey
- ONC Lantern project
- Availity payer-to-payer cohort announcement
- Burden Reduction and Patient Access API metrics (HL7 Confluence, April 2025)
- CMS press release on electronic prior authorization early adopters, 13 May 2026 (cms.gov newsroom).
- HL7 Da Vinci and WEDI recorded sessions, 2025 to 2026, for vendor-reported pilot figures.
