Most CMS-0057-F "readiness checklists" floating around the payer ecosystem right now are vendor brochures dressed up as guidance. They will tell you that you need a FHIR server. They will tell you that the rule is real. They will not tell you what an actual surveillance request looks like, or what your engineering team should have on disk when CMS asks.
The clock: CMS-0057-F (Interoperability and Prior Authorization Final Rule) requires impacted payers (MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) to begin prior-authorization metrics reporting starting January 1, 2026, with API implementation phased through 2027. The metrics reporting clock has already started.
What is actually being audited
Four APIs and a metrics requirement. The APIs:
- Patient Access API (expanded from CMS-9115-F to include prior authorization information)
- Provider Access API (new, for in-network providers)
- Payer-to-Payer API (new, for member-initiated data transfer between payers)
- Prior Authorization API (new, the headline requirement)
Plus the prior authorization metrics that began reporting January 1, 2026.
The readiness pack, what your engineering team should have on disk today
1. A passing capability discovery
Hit your FHIR base URL with a no-auth GET to /metadata. The CapabilityStatement must resolve, declare FHIR R4, and list the resources you are required to serve. If your capability discovery does not return cleanly in under 30 seconds with the right resource list, you have failed the first thing a surveillance script checks.
2. Authoritative source mappings, not just code mappings
CMS expects your prior auth decisions to be traceable back to the source policy. Not "this code maps to that code." More like: which medical policy, which version, which effective date, which clinical reviewer signed off, which guideline the decision drew from. The metadata is the audit trail. Most payer engineering teams I have seen are missing the metadata layer entirely.
3. Da Vinci Implementation Guide conformance, specifically
CMS named Da Vinci as the IG for Prior Authorization. Your engineering team should be running conformance tests against the Da Vinci PAS (Prior Authorization Support) profiles, not generic US Core. The difference matters: Da Vinci PAS adds specific extensions for the prior-auth lifecycle that ONC Inferno does not catch by default.
4. Information blocking exception documentation
If you deny a Patient Access or Provider Access API request, you need to document which exception under 45 CFR Part 171 you are claiming. ONC's information-blocking framework lists eight exceptions and each requires specific written conditions. "We did not feel comfortable releasing that" is not an exception. Preventing Harm, Privacy, Security, Infeasibility, and the others each have a definition.
5. Metrics dashboard that matches the reporting template
The prior authorization metrics CMS expects include volume of requests, denial rates, average decision turnaround, and reasons. You are not building this from raw claims data on December 28. Build it now, run it monthly, and have a year of synthetic baseline data before the public report drops.
6. A working SMART on FHIR authorization flow
The single most common reason payer FHIR endpoints fail surveillance is the SMART on FHIR authorization configuration. Wrong scopes advertised. Wrong endpoints in .well-known/smart-configuration. Authorization server returning the wrong claims. None of this is hard to fix; it is just commonly skipped.
7. Latency and rate-limit posture
Information-blocking timing requirements assume the consumer can get the data. If your endpoint times out at 30 seconds for a routine bundle pull, you have an information-blocking exposure even when you intended to comply. Test under realistic concurrency.
The patterns that fail CMS-0057 surveillance are almost never "we did not implement the API." They are "we implemented the API and the implementation has gaps that show up under real load or real edge cases."
Where to actually start
- Run capability discovery against your own FHIR endpoint this week. If you cannot, that is your starting point.
- Map your prior auth medical policies to a queryable metadata layer. If your auth decisions are not traceable, fix that before you tune the API.
- Run your endpoints against the Da Vinci PAS profile validator, not just US Core.
- Document your information-blocking exceptions, by exception number, with the conditions met.
- Stand up the metrics pipeline now, not in November.
What the public record actually shows
CMS publishes information-blocking disincentive determinations. ONC maintains the surveillance activity log. HHS OCR posts every HIPAA breach affecting 500+ individuals to the breach portal. The patterns that appear on these lists are public, and they repeat.
See Cost of non-compliance for the cost ranges by failure category, sourced to the regulator's own notices.