The CMS-0057-F Compliance Countdown: What Payers Need Done by January 1, 2027

CMS-0057-F — the Interoperability and Prior Authorization Final Rule (89 FR 8758, finalized January 2024) — sets a hard production-FHIR-API deadline of January 1, 2027. Operational decision-timeframe and metrics requirements have been live since January 1, 2026, with the first public metrics reporting deadline already passed on March 31, 2026.

That leaves roughly 8 months of useful build-and-test runway before the deadline, less if your fiscal year resets in October or your procurement committee meets quarterly. This post is a working-backwards calendar for the regulated payer classes — Medicare Advantage organizations, Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care entities, and QHP issuers on the Federally-facilitated Exchanges.

The dates below are real because regulators set them. Arithmetic does the rest.

The fixed dates (don’t negotiate with these)

Date	Obligation
2026-01-01	PA decision-timeline rules operational (72hr expedited / 7 calendar-day standard)
2026-03-31	First annual PA performance metrics publication deadline (passed)
2027-01-01	All four FHIR APIs live in production: Patient Access (expanded), Provider Access, Payer-to-Payer, Prior Authorization
2027-10-01	Next IG conformance deadline per the 2026 CMS Proposed Rule

Everything else in this post is a derived deadline — what you have to finish in order to hit those four.

What the rule actually requires

A useful framing: CMS-0057-F and its predecessor CMS-9115-F together require 5 FHIR APIs — four under CMS-0057-F plus CMS-9115-F’s Provider Directory. Most payers already operate the CMS-9115-F APIs (Patient Access, Provider Directory, Drug Formulary). CMS-0057-F adds three net-new APIs and expands the existing Patient Access API to include prior-authorization data.

The full enforcement breakdown is in our CMS-0057-F enforcement analysis. What follows is the payer’s calendar.

May 2026 — Inventory and gap analysis

Eight months out, you should already know the answer to one question: which of the four APIs is the weakest in your stack right now?

If the answer is “we don’t know,” that is the work for May. Concrete activities:

Run Inferno against your current Patient Access build. Capture the raw test report.
Pull your CapabilityStatement from production and diff it against the published Da Vinci PAS, US Core, and CARIN Blue Button profiles you have certified against.
Inventory which prior-authorization data fields live in your UM system and which live in your claims platform. Map each to its FHIR resource (Claim, ExplanationOfBenefit, Task, ServiceRequest).

The first cycle of this work always finds something. The question is whether you find it in May or in November.

June–July 2026 — Profile selection and frozen baselines

Pick the IG versions you intend to ship against and freeze them. Frozen means version-pinned in your build, signed off by the integration architect, and recorded somewhere a CMS auditor can find later.

This is where most payer programs accidentally start drifting. A team certifies against hl7.fhir.us.davinci-pas@2.0.1, then a developer six weeks later updates a generator to 2.1.0 because “it had a fix we needed.” Your CapabilityStatement now references a profile your compliance team has never reviewed. That is Spec Version Mismatch drift — see our drift taxonomy for what auditors do with that finding.

Concrete activities:

Pin every IG package version with explicit hashes in your build manifest.
Document the profile selection rationale (the auditor will ask).
Stand up a baseline conformance check that you can re-run on every deploy.

August 2026 — Provider Access API in staging

The Provider Access API is the most common gap in payer roadmaps because it didn’t exist under CMS-9115-F. You are sharing claims, encounter, and clinical data directly with in-network providers under member-attribution and opt-out rules.

If you are in August 2026 and Provider Access is still on a whiteboard, you are not necessarily late, but your margin is gone. Concrete activities:

Member-attribution logic implemented and tested against test cohorts.
Opt-out preference store deployed in production.
Bulk FHIR export validated for Bundle cardinality at production scale (this is where Mandatory Element Removal drift shows up under load).
SMART Backend Services authorization configured (private_key_jwt).

September 2026 — Payer-to-Payer end-to-end test

Inter-vendor compatibility is where Payer-to-Payer breaks. Your ExplanationOfBenefit profile and the receiving payer’s expected profile will not match exactly. The question is whether the difference is Type/Cardinality Change drift (a deal-breaker) or Structural Extension drift (informational).

Find at least one peer payer willing to run a paired conformance test before September 30. If you cannot find one, fall back to the published reference implementations and test against those. Either way, capture the test results in a way that survives the audit.

October 2026 — Prior Authorization API integrated with UM

This is the rule’s namesake. Workflow-state fidelity is the binding constraint: Task.status transitions, decision encoding, supporting-documentation attachment structures, and the linkage from a PAS request all the way to the final ClaimResponse.

Concrete activities:

All Task.status transitions implemented per the Da Vinci PAS state machine.
Supporting-documentation attachment encoded as DocumentReference with proper MIME types.
Decision-timeline counters wired (your January 2026 operational deadline already required this — confirm it is still working).
End-to-end test from PAS request → adjudication → ClaimResponse round-trip.

November 2026 — Patient Access API expanded

The expanded Patient Access API now must include prior-authorization information. The CMS-9115-F version did not.

This is a smaller scope of work than the three new APIs, but it is the one most likely to break existing third-party app integrations. A schema change that adds new ExplanationOfBenefit extensions can silently break a downstream client that was strict-validating against the old profile.

Concrete activities:

Prior-auth fields added with mustSupport flags reviewed.
Existing third-party app developers notified (CMS-9115-F app developer registry is your starting list).
Deprecation timeline communicated for any field reshaping.
Continuous conformance monitoring against the expanded profile (drift will show up in the first 30 days of production traffic).

December 2026 — Evidence trail and dry runs

The technical work is done. The question CMS will ask is “how do you know it was conformant on January 1?”

If your answer is “we have application logs,” see why application logs aren’t compliance evidence. The short version: logs rotate, get edited, and aren’t signed. Auditors know this.

What auditors accept is structurally different. A signed verdict, hash-linked to the prior verdict for the same API, with a public Ed25519 key they can verify themselves — see how Tessara’s evidence chain works. The mechanics are public; the artifact is reproducible without our tooling.

December activities:

Final dry run of all four APIs against the certification environment.
Continuous conformance evidence chain populated with at least 30 days of pre-production verdicts.
Internal mock audit. Walk through the exact artifacts you will hand to CMS.

January 1, 2027 — Production cutover

If you have done the prior eight months, this is an uneventful day. Production traffic begins, your conformance evidence chain captures every state change, and you have a defensible answer to the audit question that is coming sometime in 2027 or 2028.

If you have not done the prior eight months, this is a different conversation. The January 1, 2027 deadline does not have a grace period built into the rule text. Civil money penalties, corrective action plans, and public compliance reporting are all on the table.

Procurement cycles for payer-IT tooling run 9–12 months. If you are starting that cycle in May 2026, you are on time. If you are starting it in October 2026, you are buying off-the-shelf and hoping.

What we built

Tessara produces continuous, cryptographically verifiable conformance evidence for the FHIR APIs CMS-0057-F mandates. We probe only the public /metadata endpoint and declared profile snapshots — no patient data, no payload inspection, no agents inside your perimeter. The output is an Ed25519-signed verdict chained by SHA-256 Merkle root, replayable by any auditor with our public key.

If you are working backwards from January 1, 2027, the December dry run is the latest defensible point at which to stand up that evidence chain. Earlier is better. See pricing for current design-partner slots, or contact us to talk through your specific roadmap.

Useful primary sources for this calendar: CMS-0057-F Final Rule (89 FR 8758), CMS interoperability landing page, HL7 FHIR R4 specification, Da Vinci PAS Implementation Guide.