There is no CMS-0057-F audit checklist. Here is what actually gets checked in 2027.

Search "CMS-0057-F audit" and most results imply a formal review process with a defined checklist. CMS has not published one, and CMS does not certify payer APIs at all. What exists is self-testing, oversight under each program's existing authority, and two mechanisms that are already public. Here is what that means in practice, sourced directly from the final rule and CMS's own compliance FAQ.

Joel Onwuemene · Interoplix LLC · July 2026

The compliance signal that is public today

Before any API deadline, CMS-0057-F already created a paper trail. Beginning January 1, 2026, impacted payers had to start meeting operational requirements, and the first output of those requirements became public on March 31, 2026.

Payers must publicly report, on their own website, annual prior authorization metrics covering:

• The percentage of standard prior authorization requests approved, aggregated across all items and services
• The percentage of standard requests denied, aggregated across all items and services
• The percentage of expedited requests denied, aggregated across all items and services
• The average and median time between request submission and determination, for standard requests
• The average and median time between request submission and determination, for expedited requests
• The list of all items and services requiring prior authorization (excluding drugs)

Payers must also provide a specific reason for every denial, regardless of how the request came in (portal, fax, email, mail, or phone), and meet the 72-hour expedited / 7-calendar-day standard decision timeframe. The decision timeframe requirement does not apply to QHP issuers on the Federally Facilitated Exchanges; the denial-reason and metrics requirements still do.

Oversight runs through each program's existing authority, not a new audit

CMS's own Compliance and Enforcement FAQ answers this directly: "each CMS program oversees compliance under existing program authorities and responsibilities for each type of impacted payer. Oversight and compliance procedures vary among these CMS programs, and CMS may choose from an array of possible enforcement actions, based on a payer's status in the program, previous compliance actions, and corrective action plans." Patients and providers can also submit an inquiry or complaint to the appropriate authority for their coverage type.

Just as important, and easy to miss: CMS does not require API certification at all. On the predecessor Patient Access API rule, which CMS-0057-F builds on, the same FAQ states plainly that "CMS does not require that payers certify their APIs." Instead, payers are required to conduct their own routine testing and monitoring and to update systems as needed, including verifying privacy and security features required under HIPAA. There is no CMS-run certification step to pass. The obligation is to test yourself, keep testing, and be able to show it.

CMS names the tools it expects that self-testing to run on. The ONC-developed Inferno tool, free and open source, tests FHIR APIs for conformance with the Da Vinci and CARIN implementation guides referenced in the rule. The Da Vinci PAS Test Kit, built on the same framework, tests Prior Authorization Support IG conformance for both payer (server) and EHR (client) implementations. Both are free, both are named directly in CMS's own FAQ, and neither requires a vendor relationship to use.

For evaluation mechanics, CMS points to each program's existing tools: Medicare Advantage plans are evaluated using annual survey instruments, states use their contract vehicle with managed care plans to complete assessments, and QHP issuers on the FFEs are evaluated through the annual QHP certification application process. None of these is a CMS-0057-F-specific audit built from scratch; they are the pre-existing oversight mechanisms each program already runs.

As of this writing, CMS has not published a CMS-0057-F-specific audit protocol or checklist. Compliance runs through whichever of these existing channels already governs the payer, not a new one. That is worth stating plainly, because content implying otherwise is guessing.

MIPS attestation creates a second data trail, on the provider side

Separately from payer oversight, CMS added an "Electronic Prior Authorization" measure to the MIPS Promoting Interoperability performance category. It is an attestation measure, not a numerator/denominator measure: eligible clinicians report yes or no, or claim an exclusion.

MIPS eligible clinicians must attest "yes" to requesting a prior authorization electronically via a Prior Authorization API, using data from certified EHR technology, for at least one medical item or service, beginning with the CY 2027 performance period (CY 2029 MIPS payment year). Eligible hospitals and critical access hospitals report the same measure beginning with the CY 2027 EHR reporting period.

This does not certify a payer's API. But if a payer's Prior Authorization API does not actually complete a real transaction with a given EHR, the first visible symptom may be providers unable to attest "yes," not a notice to the payer. It is worth watching as an indirect signal, not treating as a compliance certificate either way.

Required standards vs. recommended guides

The final rule names six required standards and implementation specifications for the four APIs: USCDI, HL7 FHIR Release 4.0.1, the HL7 FHIR US Core IG (STU 3.1.1), the HL7 SMART Application Launch Framework IG (Release 1.0.0), FHIR Bulk Data Access (Flat FHIR, v1.0.0 STU 1), and OpenID Connect Core 1.0.

The Da Vinci CRD, DTR, PAS, PDex, PDex US Drug Formulary, and PDex Plan-Net implementation guides, along with the CARIN IG for Blue Button and SMART App Launch IG 2.0.0 for backend services, are recommended, not required. CMS "strongly encourages" their use to reduce burden and increase interoperability, but a reviewer citing you for skipping one would be applying a standard the rule does not set.

One more nuance the rule settles directly: HHS is using enforcement discretion on the HIPAA X12 278 prior authorization transaction standard. A covered entity that implements an all-FHIR-based Prior Authorization API under CMS-0057-F, without using X12 278, will not be enforced against under HIPAA Administrative Simplification for that choice.

What to actually have ready by 2027

• A metrics pipeline that produces the required numbers. This was already due starting March 31, 2026. If it cannot run today, that gap is current, not future.
• Documented conformance to the six required standards as the legal baseline, run through Inferno and the Da Vinci PAS Test Kit rather than asserted, with a written rationale for which recommended Da Vinci IGs you adopted and why, since "recommended" is not "optional in practice" once providers expect them.
• Attribution and consent mechanics that work end to end: the Provider Access opt-out and Payer-to-Payer opt-in processes, tested against real patient records, not just present in a data model.
• A documented record of who assessed the build and how. There is no CMS certification step to pass, only a requirement to self-test and be able to show it. When a review does happen, through whichever existing channel applies to your payer type, "we checked" is a weaker answer than a dated, written assessment from someone other than the team that built it.