CMS-0057-F is the CMS Interoperability and Prior Authorization Final Rule, finalized in 2024. It requires impacted payers to implement four FHIR-based APIs and to streamline the prior authorization process — including shorter decision timeframes, specific denial reasons, and public reporting of prior authorization metrics. It expands and supersedes much of the earlier CMS-9115-F Interoperability and Patient Access rule.

What is the CMS-0057-F deadline?

The operational prior-authorization provisions (7-day standard / 72-hour expedited decision timeframes, specific denial reasons, and public PA metrics reporting around March 31, 2026) generally begin January 1, 2026. The API development and enhancement requirements are generally due January 1, 2027. Exact compliance dates can vary by payer type.

What are the four mandated FHIR APIs?

Patient Access API (expanded to include prior authorization information), Provider Access API, Payer-to-Payer API, and the Prior Authorization API (which implements the Da Vinci PARDD stack: Coverage Requirements Discovery, Documentation Templates & Rules, and Prior Authorization Support).

Who is impacted by CMS-0057-F?

Roughly 365 parent organizations: Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-Facilitated Exchanges.

What technical standards does CMS-0057-F require?

FHIR R4.0.1, US Core Implementation Guide STU 3.1.1, SMART App Launch 1.0.0, FHIR Bulk Data (Flat FHIR) STU 1, OpenID Connect Core 1.0, and USCDI data content per 45 CFR 170.215. The prior authorization API is built on the HL7 Da Vinci PARDD implementation guides.

How many payers are ready?

As of the October 2025 WEDI survey, about 43% of payers (and 47% of providers) had not yet begun implementation. A later March 2026 wave showed improvement — roughly 10% of payers not started — but a large share remained early in the work, with many at or below 25% completion on the Patient Access API. The window is open but closing.

PARDD refers to the prior authorization API stack built on HL7 Da Vinci implementation guides: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), and Prior Authorization Support (PAS). Together they let providers discover coverage requirements, gather required documentation, and submit prior authorization requests electronically — automating a process that is largely manual today.

How does Health1st help with CMS-0057-F?

Health1st uses AI to map your legacy claims, X12 (837/835/278), and clinical data to US Core FHIR R4.0.1 — the slowest, most manual part of the program — and helps you stand up all four APIs on the mandated stack, including the Da Vinci PARDD prior authorization workflow. Mappings are versioned, explainable, and reviewed by your team, with conformance testing and audit trails for attestation.

Regulatory Guide · CMS-0057-F

Four FHIR APIs. One deadline: January 1, 2027.

CMS-0057-F requires impacted payers to stand up Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization (PARDD) APIs on a mandated FHIR stack. Here's exactly what the rule requires — and how to be ready.

Operational provisions begin Jan 1, 2026 · APIs due Jan 1, 2027
~365 impacted payer organizations · ~43% not started (Oct 2025)
Stack: FHIR R4.0.1 · US Core STU 3.1.1 · SMART · Bulk Data · OIDC · USCDI

Solutions for payers

HL7 v2.5.1 · ADT^A01inbound

MSH|^~\&|EPIC|HOSP|H1ST|DST|202601..||ADT^A01|
PID|1||MRN12345^^^HOSP^MR||DOE^JOHN^A||
    19701225|M|||123 MAIN ST^^AUSTIN^TX
PV1|1|I|ICU^101^A|||...admit...
DG1|1|I10|E11.9^Type 2 diabetes mellitus

PID → Patient

PV1 → Encounter

DG1 → Condition

AIMapping
Agent

validate · normalize · map

FHIR R4 · Bundleoutbound

{ "resourceType": "Patient",
  "identifier": [{ "value": "MRN12345" }],
  "name": [{ "family": "Doe",
             "given": ["John","A"] }],
  "gender": "male",
  "birthDate": "1970-12-25" }

{ "resourceType": "Condition",
  "code": { "coding": [{
    "system": "…/icd-10-cm",
    "code": "E11.9" }] } }

US CoreR4.0.1validated

In short

CMS-0057-F — the CMS Interoperability and Prior Authorization Final Rule — requires impacted payers to implement four FHIR APIs (Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization/PARDD). Operational provisions — shorter decision timeframes (7 days standard / 72 hours expedited), specific denial reasons, and public prior-authorization reporting — generally begin January 1, 2026, and the API requirements are generally due January 1, 2027. The mandated stack is FHIR R4.0.1, US Core STU 3.1.1, SMART App Launch 1.0.0, Bulk Data STU 1, OpenID Connect 1.0, and USCDI. Roughly 365 payer organizations are impacted, and as of October 2025 about 43% had not started.

mandated FHIR APIs

Patient · Provider · P2P · PARDD

Jan 1, 2027

API compliance deadline

provisions begin 2026

~365

impacted payer orgs

MA · Medicaid/CHIP · FFE QHP

~43%

not started

WEDI survey, Oct 2025

What the rule requires

The four mandated FHIR APIs

CMS-0057-F expands and supersedes much of the earlier CMS-9115-F Patient Access rule, adding provider access, payer-to-payer exchange, and an automated prior authorization API.

Patient Access API (expanded)

Members retrieve claims, encounters, and clinical data via third-party apps over SMART on FHIR — expanded under CMS-0057-F to include prior authorization information (excluding drugs).

Provider Access API

In-network providers access patient claims and USCDI clinical data for treatment, with patient attribution and opt-out handling built into the exchange.

Payer-to-Payer API

When a member changes plans, their claims and clinical history transfer between the prior and current payer via FHIR — with member opt-in.

Prior Authorization API (PARDD)

Automates prior authorization end-to-end via the Da Vinci PARDD stack: Coverage Requirements Discovery, Documentation Templates & Rules, and Prior Authorization Support.

The mandated stack

Exactly which standards you must implement

CMS-0057-F doesn't just say 'use FHIR.' It specifies versions. Health1st maps your data to precisely this stack.

FHIR R4.0.1

The base HL7 FHIR release for all four APIs.

US Core IG STU 3.1.1

The US Core Implementation Guide profiles for conformant resources.

SMART App Launch 1.0.0

App authorization and launch framework for API access.

FHIR Bulk Data STU 1

Flat FHIR for population-scale export (Provider Access, Payer-to-Payer).

OpenID Connect Core 1.0

Identity layer for authenticating API clients and users.

USCDI

The United States Core Data for Interoperability data content, per 45 CFR 170.215.

The timeline

From operational provisions to API compliance

The rule phases in: prior-authorization operations in 2026, the four APIs by 2027, then ongoing operation and attestation.

1
Jan 1, 2026 — Operational provisions begin
Shortened decision timeframes take effect: 7 calendar days for standard prior authorization decisions and 72 hours for expedited. Payers must also send specific denial reasons.
2
~Mar 31, 2026 — First public PA reporting
Impacted payers begin publicly reporting aggregated prior authorization metrics on their websites, increasing transparency and accountability.
3
Jan 1, 2027 — API compliance due
The four FHIR APIs — Patient Access (expanded), Provider Access, Payer-to-Payer, and Prior Authorization (PARDD) — must be implemented on the mandated stack. Exact dates can vary by payer type.
4
Ongoing — Operate & attest
Maintain conformance, keep reporting PA metrics, and preserve audit evidence. Compliance is a standing operational obligation, not a one-time go-live.

Who is impacted

Roughly 365 parent payer organizations

If you're one of these payer types, CMS-0057-F applies to you.

Medicare Advantage organizations

MA plans must implement all four APIs and the streamlined prior authorization provisions.

State Medicaid & CHIP (FFS)

Fee-for-service Medicaid and CHIP programs are in scope for the API and prior-auth requirements.

Medicaid & CHIP managed care

Medicaid managed care organizations and CHIP managed care entities must comply.

FFE QHP issuers

Qualified Health Plan issuers on the Federally-Facilitated Exchanges are impacted.

The risk of waiting. Missing the deadline is more than a technical slip — it creates audit and attestation exposure, and the public prior-authorization metrics reporting makes readiness visible to members, providers, and regulators. The slowest part of the program is converting legacy data to conformant FHIR, which is exactly where AI mapping saves months.

How Health1st gets you there

How to meet CMS-0057-F

A five-step path that puts AI on the mapping bottleneck and keeps your team in control of every claims and clinical field that ships.

1
Assess your data estate against the mandated stack
Inventory your claims warehouse, X12 feeds (837/835/278), clinical data, and existing member APIs, and map every gap against FHIR R4.0.1, US Core STU 3.1.1, SMART App Launch 1.0.0, Bulk Data STU 1, OpenID Connect 1.0, and USCDI content.
2
Map your data models to US Core FHIR with AI
Use AI-drafted mappings to convert internal claims and clinical models and X12 messages into US Core FHIR profiles, reviewed and approved by your team with versioning and audit trails.
3
Stand up the four mandated APIs
Implement Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization (PARDD) APIs on SMART App Launch and OpenID Connect, using FHIR Bulk Data for population-scale exchange.
4
Implement the prior authorization workflow
Deploy the Da Vinci PARDD stack — Coverage Requirements Discovery, Documentation Templates & Rules, and Prior Authorization Support — to automate the auth decision loop within the shortened 7-day standard / 72-hour expedited timeframes.
5
Conformance-test, attest, and monitor
Validate against US Core and the Da Vinci implementation guides, capture audit evidence for attestation, report public prior-authorization metrics, and monitor the APIs in production to stay compliant after go-live.

Explore the pieces in depth — the payer solution and the prior authorization (PARDD) workflow.

Solutions for Payers Prior Authorization (PARDD)

Why AI mapping matters here

The deadline is fixed. The mapping work is what varies.

Standing up FHIR endpoints is well-understood. The multi-quarter risk is converting years of X12 and proprietary claims and clinical data into conformant US Core FHIR — by hand.

Weeks, not quarters, on mapping

The Mapping Agent drafts field- and segment-level mappings from X12 and your data models to US Core; your team reviews instead of hand-building.

Audit-ready by construction

Every mapping is versioned and explainable, with audit trails you can present for attestation — not reconstructed after the fact.

PARDD, handled

The hardest API is prior authorization. Health1st implements the Da Vinci CRD/DTR/PAS stack so the auth decision loop runs within the mandated timeframes.

Security & Compliance

Enterprise-grade trust, stated honestly

Protecting PHI is non-negotiable. Here's exactly where our certifications stand — no overclaiming.

HIPAAActive

Compliant · BAAs available

SOC 2 Type IIIn Progress

Audit in progress

HITRUST CSFOn Roadmap

On roadmap

HL7 · FHIRCore

Native, by design

AWS HIPAA-eligible infrastructure · Business Associate Agreements (BAAs) · Encryption in transit & at rest · See our security details →

CMS-0057-F: frequently asked questions

Be ready for CMS-0057-F before January 2027.

Bring your X12 and claims samples. We'll show a live mapping to US Core FHIR and walk your team through the four-API path.