CMS-0057-F Enforcement: Preparing for the 2027 Deadline

The clock is ticking for healthcare payers. CMS-0057-F — the Interoperability and Prior Authorization Final Rule, finalized in January 2024 — sets a hard full-compliance deadline of January 1, 2027, with operational prior-authorization decision-timeline requirements already in effect since January 1, 2026.

By the 2027 deadline, impacted payers — Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the Federally-facilitated Exchanges — must implement and maintain a series of FHIR-based APIs. But beyond just “having an API,” the rule introduces strict new requirements for data exchange and operational transparency.

Note: CMS-0057-F is often confused with the 2020 rule CMS-9115-F, the “Interoperability and Patient Access Final Rule.” CMS-9115-F is the predecessor; CMS-0057-F extends and tightens its API obligations, adds a Prior Authorization API, and reframes the Payer-to-Payer requirement as an active data-exchange API rather than a notice-based workflow.

The Four APIs of CMS-0057-F

CMS-0057-F mandates four distinct FHIR-based APIs. Payers who are already operating the 2020-era CMS-9115-F Patient Access and Provider Directory APIs must extend them and stand up net-new endpoints.

1. Patient Access API (expanded)

The 2020 Patient Access API must now include prior-authorization information — request status, approved items and services, and the clinical reason for any denial — in addition to the existing claims, encounter, and clinical-data obligations.

Technical Risk: Prior-auth data typically lives in legacy UM systems with inconsistent schemas. Mapping it onto FHIR resources like Claim and ExplanationOfBenefit is where Category 2 (Type/Cardinality Change) drift is most likely to appear.

2. Provider Access API (new)

Payers must share patient claims, encounter, and clinical data directly with in-network providers via a FHIR API, governed by member attribution and opt-out rules.

Technical Risk: Bulk FHIR export conformance. Maintaining strictly valid Bundle structures at export scale is where Category 1 (Mandatory Element Removal) drift shows up under load.

3. Payer-to-Payer API (new as an active API)

When a member transitions from one payer to another, the receiving payer can request the member’s historical data through a FHIR API, replacing the notice-based workflow from CMS-9115-F with an active data-exchange obligation.

Technical Risk: Inter-vendor compatibility. If Payer A’s ExplanationOfBenefit implementation diverges from Payer B’s expected profile — a Category 2 or Category 3 drift — the exchange fails and the data gap becomes a compliance event.

4. Prior Authorization API (new — the rule’s namesake)

Payers must accept FHIR-based prior-authorization requests, return decisions, and expose request status through structured responses. This is the capability CMS-0057-F is named after, and it carries the strictest decision-timeline rules (operational since January 2026).

Technical Risk: Workflow-state fidelity. Task.status values, decision encoding, and supporting-documentation attachment structures must match the Da Vinci PAS IG — drift here is typically Category 5 (Endpoint Behavioral Change) because declarations remain correct while behavior diverges.

Enforcement Posture: What CMS Has Signaled

The full enforcement posture for CMS-0057-F is still being shaped, but CMS’s handling of CMS-9115-F offers a useful reference. Three patterns are likely to extend:

1. Operational attestation at the compliance deadline

Payers will be expected to demonstrate that their APIs are operational, conformant to the published Implementation Guides, and meeting the rule’s decision-timeline obligations.

Where Tessara fits: Signed, hash-linked evidence chains provide a byte-verifiable record of conformance state at any historical timestamp — useful for any attestation process that requires retrospective proof.

2. Structural non-conformance findings from technical scans

CMS and ONC have, under predecessor rules, flagged structural non-conformance — missing mustSupport elements, cardinality violations, broken profile references — through technical scans of public endpoints.

Where Tessara fits: Tessara’s Conformance Comparator identifies Category 1 (Mandatory Element Removal) and Category 2 (Type/Cardinality Change) findings continuously, so structural drift is known internally before it shows up in an external scan.

3. Complaint-driven investigations

Under CMS-9115-F, third-party app developer and patient complaints have been the loudest enforcement signal. A breaking schema change that prevents an app from ingesting data tends to generate a CMS-portal complaint quickly.

Where Tessara fits: Detecting Category 2 (Type/Cardinality Change) drift at deployment time gives engineering a chance to revert or patch before the first app breaks.

The Cost of Non-Compliance

The consequences of missing the January 2027 deadline are not purely financial. Published and historically observed enforcement mechanisms include:

Civil Money Penalties (CMPs) per day of continuing non-compliance, under the statutory authorities CMS uses for program integrity.
Corrective Action Plans (CAPs) mandating structured remediation with oversight and reporting obligations.
Public compliance reporting by CMS, which has historically included payer-level status disclosures and can create significant reputational exposure.

Conclusion: Compliance is a Continuous Process

CMS-0057-F is not a “one-and-done” project. It is an operational mandate. As your clinical systems evolve and your FHIR profiles are updated, the risk of silent drift grows.

Payers who succeed in 2027 will be those who move beyond manual audits and implement Continuous Conformance Monitoring.

Is your API ready for 2027? Review our CMS-0057-F Conformance Readiness Checklist.