The CMS-0057-F Opportunity Most Payers Are Missing

The Provider Access API you’re building for compliance can also end the chart chase

Health plans still get most of their clinical data the slow way: requests by fax and portal, weeks of waiting, and scanned charts that have to be abstracted by hand before risk adjustment or HEDIS teams can use them. The fix most of the industry agrees on is direct connections to provider EHRs. What has held it back is the work of getting connected: attribution, provider identity, secure endpoints, and a reason for practices to participate.

CMS-0057-F is now forcing that work. To meet the January 1, 2027 Provider Access API deadline, plans are building the attribution, identity and FHIR infrastructure direct clinical data exchange depends on, and opening a conversation with every attributed practice.

The API sends data one way, to providers. Add the return path, and the same build delivers continuous, discrete clinical data from provider EHRs, without per-chart fees that rise as the network grows.

Why the workarounds fall short

The industry has spent years working around the chart chase. Retrieval vendors take the labor off internal teams, but per-chart fees scale with volume and records still arrive as images. National query-based networks offer reach, but what comes back is usually document-level and rarely complete enough for HEDIS numerator compliance or risk adjustment documentation. Both are useful supplements. Neither is a long-term answer.

Direct EHR integration is. The technology has been ready for a while; certified EHRs now expose standards-based FHIR APIs. So why hasn’t it taken over?

The obstacle was never the technology

It was the first connection. Four things made it hard, and they compounded each other.

There was nothing to build on. A plan asking a practice for EHR access was asking for something new, with no existing technical or legal framework between them. Every connection started from zero.

Providers had little reason to say yes. Data flowed one way, out of the practice and into the plan. The practice took on the legal review, the IT work and the risk, and got back more requests.

Every party moved at its own pace. Data use agreements waited on the practice’s counsel. App activation waited on the EHR vendor’s review queue. Integration waited on IT priorities that were rarely the plan’s.

The plan’s own foundation was missing. Reliable attribution, provider identity and secure, standards-based endpoints are prerequisites for any exchange. Few plans had all three, and building them for a single use case was hard to justify.

Multiply that across hundreds of practices on dozens of EHR platforms, and it is no surprise that most plans settled for the chart chase.

What CMS-0057-F quietly changes

The Provider Access API requires impacted payers to make claims and encounter data, USCDI clinical data and prior authorization information available to in-network providers who have a treatment relationship with the member. To meet it, plans are now building, on a regulatory deadline and with budget already approved:

• an attribution process that links members to the providers treating them;
• provider identity and authentication, so the plan knows exactly which organization is on the other end;
• FHIR endpoints and the security model around them; and
• provider-facing resources and outreach, because the rule requires plans to explain the API to the providers who will use it.

Look at that list again. It is the foundation every obstacle above was waiting on. The roster that tells a plan which providers should receive a member’s data is the same roster that tells it which members it needs clinical data for. The provider identity work is the same. The security model is the same. And for the first time, the plan has a reason, and a mandate, to be in a technical conversation with every attributed practice.

The Provider Access API is half of a clinical data exchange. It just runs in one direction.

Turn a one-way mandate into a two-way exchange

Add the return path, and the provider conversation changes. Instead of asking a practice to give data away, the plan brings something to the table: its members’ claims history and prior authorizations, plus open care gaps and risk adjustment suspects, delivered inside the clinician’s EHR session, attached to the patient in front of them, without another portal login. In return, discrete clinical data flows back to the plan as encounters close.

Providers answer fewer record requests and can close gaps during the visit instead of after a follow-up call. Plans get the data they have been chasing, in a form they can load. And the provider onboarding the plan is already doing for CMS-0057-F becomes one onboarding, not two.

What it means for risk adjustment and HEDIS

• Risk adjustment. Much of the documentation that supports an accurate risk score sits in specialty encounters, such as cardiology, nephrology, endocrinology and oncology, that PCP-centered retrieval misses. EHR-level connectivity brings every department on that system into scope. Documentation arrives within the submission year, while there is still time to act, and traces back to the source record, which matters more every year as RADV scrutiny increases.
• HEDIS and Stars. Numerator evidence arrives continuously instead of in an end-of-year sweep. Discrete, standardized clinical data reduces reliance on hybrid chart review and positions the plan for NCQA’s shift toward digital (ECDS) reporting.
• Care gaps and payment integrity. Gaps are visible as they open, not months later. Claims can be reviewed against clinical records that are already validated and consistent.

Just as important, it scales differently. Connectivity is established once per EHR platform, so adding a practice on that platform is configuration, not a new integration project. Adding members adds no per-chart fee. The cost curve that defines the chart chase flattens.

How Onyx DataBridge makes it work

Onyx DataBridge is built to sit on the same foundation as your Provider Access API, and to handle the parts of clinical data exchange that CMS-0057-F doesn’t.

Get data. Retrieval starts from your attributed member roster, not a list of offices to call. Connections are made once per EHR platform, cover every specialty and department on that system, and refresh as new encounters close.

Make data usable. Inconsistent C-CDAs, PDFs and local HL7 variations come in; validated, standardized, ready-to-load data goes out. The rework that usually sits between retrieval and use is handled in the pipeline, not by analysts.

Use data. Data lands in your own environment, keyed to your member IDs, where existing HEDIS, risk adjustment and care management teams and tools can use it. Plans that want a managed repository can use [Onyx repository option — confirm name with Product], but it is an option, not a requirement.

Close the loop. Care gaps and suspects flow back into the clinician’s EHR workflow, so providers see value from the exchange, not just requests.

Design it once

The time to do this efficiently is now, while CMS-0057-F scope and provider onboarding plans are still being finalized. A few lessons from the programs we have seen succeed:

• Scope the two together. Plans that treat Provider Access and clinical data exchange as separate projects build the same foundation twice and ask their providers to onboard twice.
• Keep ownership of the roster. The plan holds the attribution data. Programs that hand roster-building to providers tend to stall before they scale.
• Sponsor outreach under the plan’s name. The plan holds the provider relationships, and the CMS-0057-F conversation gives it a reason to call.
• Sequence by EHR platform. Start with the systems that cover the most attributed members. Every additional practice on that platform is easier than the last.

The investment is already being made

Every impacted plan will spend what it takes to meet the Provider Access API deadline. The real question is whether that spend ends at compliance, or becomes the foundation for high-quality clinical data, in a readily ingestible format, available when you need it.

The plans that see the opportunity early will spend the next few years using clinical data. The rest will still be chasing it.

See how Onyx DataBridge works for your network.

Request a Demo