A question that comes up in nearly every CMS-0057 conversation: who certifies us?
Nobody does. There is no certification program for payers under CMS-0057-F. CMS has said so explicitly in its own FAQ material, and it changes how you should plan the work — because the absence of a certifying body does not reduce the obligation, it moves the burden of proof onto you.
What the rule actually requires
Two obligations, and only the first is widely understood.
Implement the APIs. Four of them by 1 January 2027: Patient Access expanded to include prior authorization data, Provider Access, Payer-to-Payer, and the Prior Authorization API. The decision-timeline and denial-reason requirements have been in force since the start of 2026 and are already producing reportable metrics.
Routinely test and monitor. This is the part that matters when nobody certifies you. The duty is continuous, not a one-time gate, and it is what an auditor will actually examine.
Why the absence of certification is harder, not easier
With a certification program, compliance has a finish line. Someone hands you a pass and you file it. Without one, three things become true at once.
First, you decide when you are done — and you own that judgement if it turns out to be wrong. Second, enforcement runs through existing machinery rather than a dedicated process: Medicare Advantage program audits and annual surveys, state Medicaid administrative arrangements, state contracts with managed care organisations, and annual qualified health plan certification on the federal exchange. These mechanisms already exist, already have auditors, and now have another thing to look at. Third, "we built it" is not evidence. An endpoint that returns a 200 proves almost nothing about conformance.
The practical consequence: what you need is not a certificate. It is a defensible, dated evidence trail.
The evidence chain that actually holds up
1. A gap assessment against the rule, written down
Not a slide. A document that states, requirement by requirement, where you are and what the plan is. Its value is partly planning and partly that it demonstrates you understood the obligation and acted deliberately — which is the difference between a gap and a finding.
2. Build to the Implementation Guides
The Da Vinci guides — CRD, DTR, PAS, PDex, Plan-Net, plus CARIN Blue Button — are described as strongly encouraged in the final rule rather than mandated. Treat that wording carefully. Building to something else is technically permissible and practically a poor decision, for two reasons: your trading partners are building to the guides, so divergence creates integration work on both sides; and a separate proposed rule would make them mandatory, at which point non-conforming work becomes rework.
3. Run the conformance suites, and keep the output
This is the closest thing to certification that exists, and it is available today. Inferno publishes payer test kits covering the prior authorization and PDex flows; Touchstone provides broader FHIR conformance testing. Neither issues a certificate. Both produce dated, reproducible results against published expectations — which is exactly what "routinely test and monitor" looks like when someone asks you to show it.
Connectathons add something the suites cannot: evidence that your implementation works against other people's, not just against a test harness.
4. Assemble the pack, and keep it current
Dated test results, the IG versions you built against, your gap assessment and its closure, your monitoring approach, and a record of remediation when tests failed. The last item is worth emphasising — a trail showing you found and fixed problems is stronger evidence of a working process than an unbroken record of passes.
The trap in the middle
The predictable failure mode is treating CMS-0057 as a build-and-forget project. The APIs go live in December, everyone moves on, and eighteen months later an audit asks what testing has been done since. "We tested at launch" is a weak answer to a requirement written in the present continuous.
Put the conformance suites in your regular release process. It costs little once wired in, and it converts an annual scramble into a report you can produce on request.
What to do if you are behind
Industry survey work through 2026 suggested a substantial share of payers were still at an early stage on the Patient Access work, and providers less advanced still. If that is you, the sequence that recovers the most ground is unchanged: assess honestly, build to the guides rather than to your own interpretation, test with the published suites, and keep the output.
If you have already scoped the work, our companion piece on what to scope before writing any code covers the planning side in more depth.
Nirmitee builds and tests FHIR APIs for payers and health-tech platforms. Our healthcare interoperability team runs readiness assessments, Implementation Guide builds and conformance-testing engagements; for the platform side see our healthcare software product engineering practice. Talk to our team.
