Payer self-assessment: is your CMS-0057-F solution actually ready?

With less than nine months to January 2027, the question for most payers is no longer whether to act. It’s whether what you’re building will actually hold up.

A vendor contracted, a project underway, endpoints in test. Those are activity metrics, not readiness signals. As we outlined in our overview of where payers should be in 2026, the gap between “endpoints exist” and “this works in production” is where most programs run into trouble, and most don’t find out until Q4.

To help, we’ve pulled together a diagnostic framework for you to test your current setup. It won’t tell you whether you’ll make the deadline. But it will tell you where your risks are, and which ones need attention now.

How to use this

Work through each section with your implementation lead and your vendor. For any question where the honest answer is “I think so” or “I’m not sure,” treat that as a flag. Vague confidence at this stage is how programs end up in crisis in Q4.

Some items reflect CMS mandates. Others reflect what actually determines whether your solution holds up in production. Both are important.

A downloadable checklist and interactive self-assessment tool are available at the end of this post.

Section 1: API coverage

The January 2027 requirement is five APIs in production, which includes an expanded Patient Access API and an updated Provider Directory API that a number of payers may not have fully accounted for.

Patient Access API

• Is prior authorization data (excluding drugs) included in what members can access, not just claims and clinical data?
• Is data being made available within one business day of receipt or update, and have you tested that timeliness requirement against realistic data volumes?

Provider Access API

• Is your provider-patient attribution methodology documented, validated, and operational? If it’s just designed on paper, you may need to consider
• Do members have a working opt-out mechanism, not just a policy that says they can opt out?
• Have you piloted data sharing with at least one real in-network provider, not just in a sandbox environment?

Payer-to-Payer API

• Have you tested your previous and concurrent payer identification workflow against a real enrollment scenario?
• Can you collect previous payer information within one week of enrollment and exchange data within one business day of a valid request?
• Have you confirmed your system can both send data to and receive data from other payers’ endpoints?

Provider Directory API

• Have you migrated from US Core 3.1.1 / Plan-Net 1.1.0 to US Core 6.1.0 / Plan-Net 1.2.0? This was required by January 1, 2026.
• Is your 30-day update process operational, or just documented? Who owns it day-to-day?

Prior Authorization API

• Does your solution support all three components: CRD, DTR, and PAS? While they are not explicitly mandated, all three are recommended for a functioning end-to-end prior auth workflow that providers will actually use.
• Does your solution work across your provider network’s range of EHR systems, or has it only been tested with one or two? This is one of the most common points of failure in PA implementations.
• Are decision timeframes (72 hours for expedited requests, 7 days for standard) enforced in your workflow, not just documented as a policy?
• Are specific denial reasons being provided for all PA decisions? (Required from January 1, 2026)
• Are denial reasons structured and machine-readable via your Prior Authorization API automatically ingested by providers’ EHR systems without manual entry? (Required from January 1, 2027)
• Can you produce the required PA metrics, including volumes, approval and denial rates, average turnaround times, without manual data pulls?

Section 2: The infrastructure underneath the APIs

This is where programs that look fine on the surface start to show cracks. The APIs are the visible layer. What determines whether they function reliably at scale is everything underneath them.

Data quality

• Have you tested your solution against real production data, not test data? Test data masks the inconsistencies and gaps that cause FHIR transformation failures in production.
• Do you have a process for identifying and resolving data quality issues before they reach the FHIR layer, or are you relying on the FHIR layer to catch them?
• Is your member data clean enough to support the identity matching required for Provider Access and Payer-to-Payer exchange?

Delegated vendors

• Have you mapped all of your delegated vendors? This typically includes vision, dental, behavioral health, long-term care, and pharmacy benefit management.
• Do you know which of your delegated vendors can support FHIR-based prior authorization, and which will require separate integration work or workarounds?
• Have you started integration conversations with each one? Each delegated vendor is a separate Prior Authorization integration, and some will require significant lead time.

This is one of the most underestimated risks in CMS-0057-F programs. Payers with 10 or 15 delegated vendors who haven’t started this mapping yet are carrying significant schedule risk into Q3.

Terminology and IG governance

• Do you have a process for managing IG updates, or will every update require a new project?
• Who owns terminology governance, and is that person actively engaged in the implementation?
• Have you validated your FHIR profiles against the required implementation guides, not just the base FHIR standard?

Security and identity

• Is SMART on FHIR and OAuth 2.0 implemented and tested across all five APIs?
• Is consent management handled as a system function, not just a policy document?
• Are audit logs in place and aligned with CMS reporting requirements?

Section 3: The operational layer

Technical and data readiness matter, but they only take you so far. The operational layer is what determines whether your APIs get used, not just built.

Reporting

• Can you produce the annual CMS report without manual intervention? The March 31 deadline repeats every year. If your reporting process requires someone to manually pull and format data each time, that’s a process risk that gets harder to manage as volumes grow.
• Who owns the reporting process, and are they actively involved in implementation now?

Member and provider education

• CMS requires plain-language education materials before data sharing begins. Are yours drafted, reviewed, and ready to publish?
• For Provider Access specifically, members need to understand what data is being shared and how to opt out. Is that communication ready?
• Do providers know how to use the new workflows? Endpoint availability and provider adoption are two different things. If your provider onboarding plan is ‘publish the endpoints and send an email,’ it may need more work.

Cross-functional governance

• Is there a steering group that includes IT, operations, compliance, and clinical representation meeting regularly?
• Are implementation decisions being made at the right level, or are critical choices getting stuck waiting for sign-off?

What your results mean

If you worked through this and found one or two flags, those are manageable. Identify who owns each gap, set a target date to address it, and track it.

If you found gaps across multiple sections, the honest question to ask is whether you’re dealing with execution problems or architectural ones. A misconfigured endpoint or a missing data field is an execution problem.

A solution that was never designed to support all five APIs, a data pipeline that breaks on real production data, or a vendor without the capacity to support your delegated vendor integrations, those are architectural problems. The fix is a different conversation, and the sooner you have it the better.

Nine months is enough time to close execution gaps. It’s tight for architectural ones.

If you’re not sure which category your gaps fall into, that’s worth a conversation. We work with payers at every stage of this process and can usually help you get clarity quickly on what’s fixable in the time you have.

Download the full checklist

The questions above are a summary. The full checklist and an interactive self-assessment tool are available to work through with your team, and your vendor if you have one.

Access the interactive checklist → 

Download the PDF checklist → 

If you’d like to talk through your results, reach out and we’ll be happy to help.