Frequently Asked Questions About CMS-0057-F

CMS-0057-F is a federal final rule titled "Advancing Interoperability and Improving Prior Authorization Processes." Published by the Centers for Medicare & Medicaid Services in January 2024, it requires impacted payers to implement FHIR-based APIs for health data exchange and to reform prior authorization processes with faster decision timelines and public transparency reporting.

It amends 42 CFR Parts 422, 431, 435, 438, 440, 457, and 45 CFR Part 156 (RIN 0938-AU87), and builds on the 2020 CMS Interoperability and Patient Access final rule (85 FR 25510).

CMS identifies 365 parent payer organizations across six categories:

• Medicare Advantage (MA) organizations
• State Medicaid fee-for-service (FFS) programs
• State CHIP FFS programs
• Medicaid managed care plans (MCOs, PIHPs, PAHPs)
• CHIP managed care entities (MCOs, PIHPs, PAHPs)
• Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs)

Excluded: Stand-alone dental plans (SADPs), FF-SHOP-only issuers, State-based Exchanges on the Federal Platform (SBE-FPs), and State-based Exchanges operating their own platforms (SBEs).

Not directly. The rule does not mandate Medicare FFS compliance. However, CMS stated its intention for Medicare FFS to be a "market leader on data exchange" and to voluntarily comply by the same compliance dates. CMS solicited public comments on applying these provisions to Medicare FFS and is considering them for future rulemaking.

No. CMS-0057-F applies only to the payer categories listed above — primarily government-regulated health programs and QHPs on the federal exchanges. Employer-sponsored plans (group health plans under ERISA) are not subject to these requirements, though CMS has encouraged all payers to consider voluntary adoption.

CMS received nearly 900 timely pieces of correspondence in response to the proposed rule published in December 2022 (87 FR 76238). The final rule addresses in-scope comments and incorporates modifications based on commenter feedback, most notably delaying API compliance dates from 2026 to 2027.

CMS-0057-F mandates four FHIR-based APIs:

• Patient Access API — enhanced to include prior authorization data alongside existing claims and clinical data
• Provider Access API — new API giving providers access to patient data held by payers
• Payer-to-Payer API — new API for automated data exchange when patients change health plans
• Prior Authorization API — new API enabling electronic PA requirement discovery, documentation retrieval, and request submission

Yes. CMS refers to each API as a single API to describe the required functionality, but acknowledges that payers may implement each using one or multiple APIs depending on their architecture. The rule is functionally prescriptive — not technically prescriptive about how many endpoints or services a payer deploys, so long as all required capabilities are available.

Through the Patient Access API, payers must give patients access to:

• Adjudicated claims and encounter data (including provider remittances and patient cost-sharing)
• All data classes and elements in the USCDI content standard (45 CFR 170.213)
• Laboratory results maintained by the payer
• Prior authorization information (new in CMS-0057-F)

Two key differences: First, the Provider Access API excludes provider remittances and patient cost-sharing to protect contractual rate confidentiality. Second, it uses backend service authentication (system-to-system) rather than the consumer-facing SMART App Launch flow used by the Patient Access API. The Provider Access API also includes a patient opt-out mechanism, whereas the Patient Access API is always available to the patient directly.

Payers must exchange up to five years of patient data. The proposed rule would have required the entire patient health record, but CMS modified this in the final rule, determining that five years of data is sufficient for care continuity and prior authorization continuation without imposing excessive burden. For patients with concurrent payers, data must be exchanged at least quarterly.

The proposed rule referred to the Prior Authorization API as the "Prior Authorization Requirements, Documentation, and Decision API" (PARDD API). CMS simplified the name to just "Prior Authorization API" in the final rule for clarity. This name change does not alter any substantive requirements — the capabilities (PA requirement discovery, documentation retrieval, and request/decision exchange) remain the same.

Impacted payers (except QHP issuers on the FFEs) must respond to:

• Urgent/expedited PA requests: within 72 hours
• Standard PA requests: within 7 calendar days

These timeframes apply regardless of how the PA request is received — whether through the API, fax, phone, or portal. They take effect January 1, 2026, one year before the API mandate.

No. The prior authorization API and process requirements explicitly exclude drugs of any type: prescription drugs, self-administered drugs, provider-administered drugs, pharmacy-dispensed drugs, and hospital-administered drugs. Drug PA involves distinct processes, standards, and regulatory frameworks not addressed in this rule. However, drug claims data is still included in the Patient Access API as part of the patient's health record.

Payers must provide a specific reason for the denial in the notice sent to providers. Generic or boilerplate denial language — such as "does not meet medical necessity criteria" without further detail — is no longer compliant. This requirement addresses one of the most persistent provider pain points cited in public comments and takes effect January 1, 2026.

All impacted payers must publicly report prior authorization metrics including approval rates, denial rates, average response times, and related performance measures. This public reporting requirement is designed to create transparency and allow providers, patients, and regulators to compare payer performance. Reporting begins January 1, 2026.

CMS strongly recommends three HL7 Da Vinci IGs for the Prior Authorization API:

• Da Vinci CRD (Coverage Requirements Discovery) — real-time checks from EHR to determine if PA is needed
• Da Vinci DTR (Documentation Templates & Rules) — FHIR Questionnaires defining required clinical data, enabling auto-population from EHR
• Da Vinci PAS (Prior Authorization Support) — structured electronic submission of PA requests and receipt of decisions

These are strongly recommended but not formally mandated. The required base standard is HL7 FHIR R4.0.1.

CMS originally proposed API compliance dates in 2026 but delayed to 2027 in response to commenter feedback. CMS determined that an approximately three-year implementation window (from rule finalization in early 2024 to January 2027) would be sufficient time for payers to recruit and train staff, build or update APIs, and update operational procedures. The prior authorization process requirements remain at 2026.

It depends on the payer type:

• State Medicaid & CHIP FFS programs: May request an extension of the compliance dates or a full exemption from certain requirements in specific circumstances
• QHP issuers on the FFEs: May request an exception from API requirements, conditioned on annual CMS approval of a narrative justification
• MA organizations: No extension pathway — must meet the January 1, 2027 deadline
• Medicaid managed care plans & CHIP managed care entities: Compliance is enforced through their state's managed care contracts

CMS will use existing enforcement mechanisms specific to each payer type. For MA organizations, this may include compliance actions, civil monetary penalties, or contract termination. For Medicaid managed care plans, states enforce compliance through managed care contracts. For QHP issuers, CMS acts through the FFE oversight process. CMS has emphasized that the three-year implementation window should be sufficient for all payers.

No. QHP issuers on the FFEs are exempt from the mandated PA response timeframes (72 hours urgent / 7 days standard). However, they are required to implement the Prior Authorization API, publicly report PA metrics, and include specific denial reasons in PA notices.

HL7 FHIR Release 4.0.1, codified at 45 CFR 170.215(a)(1). This is the base interoperability standard for all four mandated APIs. CMS allows payers to voluntarily adopt newer FHIR versions ahead of regulatory updates, provided the newer version does not disrupt end users' ability to access data.

The United States Core Data for Interoperability (USCDI), referenced at 45 CFR 170.213. CMS finalized a direct reference to this regulation, meaning the content requirement automatically updates as ONC adopts new USCDI versions — payers don't need to wait for new CMS rulemaking. Currently, USCDI v1 (expiring January 1, 2026) and USCDI v3 are the adopted standards.

Yes. CMS finalized a policy allowing payers to voluntarily use updated versions of any required standard, specification, or implementation guide before CMS formally adopts them through regulation. The only condition is that the updated version must not disrupt end users' ability to access data through the API. This gives payers flexibility to stay current with evolving HL7 and ONC standards.

The ONC HTI-1 final rule (89 FR 1192, January 9, 2024) reorganized the structure of 45 CFR 170.215 to more clearly delineate the purpose and scope of each technical standard. CMS-0057-F references the updated HTI-1 citations for all required standards, ensuring alignment between the two rules. The standards themselves are substantively the same; HTI-1 primarily affected the regulatory citation structure.

No. The rule applies to QHP issuers on the Federally-facilitated Exchanges (FFEs) only. State-based Exchanges on the Federal Platform (SBE-FPs) — even though they enroll through HealthCare.gov — are not FFEs and are not subject to these requirements. State-based Exchanges operating their own platforms are also excluded. CMS encourages these exchanges to adopt similar policies voluntarily.

CMS aligns the rule with Executive Order 13985 on advancing racial equity and notes that some patient populations are disproportionately affected by current PA inefficiencies. The rule emphasizes ensuring that app-based data access is available to individuals with disabilities, limited English proficiency, low literacy, and those facing geographic or economic barriers to technology. CMS solicited comments on preventing the rule's policies from exacerbating disparities or creating unintended inequities.

Yes. Under the HIPAA Privacy Rule (45 CFR 164.502(g)), a personal representative — such as a parent, guardian, or person with medical power of attorney — may generally exercise the patient's right to access health information. For many processes in CMS-0057-F, including Patient Access API data retrieval and Payer-to-Payer API opt-in, a personal representative can act on the patient's behalf as permitted by applicable law.

Starting with the CY 2027 performance period (affecting MIPS 2029 payment year), eligible clinicians must report an "Electronic Prior Authorization" measure under the Promoting Interoperability performance category. CMS modified this from the proposed numerator/denominator approach to a yes/no attestation (or exclusion if applicable). The same measure applies to eligible hospitals and CAHs under the Medicare Promoting Interoperability Program beginning with the CY 2027 EHR reporting period.