A technical guide to the Provider Access API under CMS-0057-F 

For payers working through CMS-0057-F, the Provider Access API is the one that tends to get scoped wrong. On paper it’s straightforward: share clinical and claims data with in-network providers who have a treatment relationship with your members. That phrase, “treatment relationship”, turns out to cover a lot of ground.

Before any data can flow, you need to know which providers are treating which members, keep that list current, and give patients a way to opt out. None of that exists yet for most payers, and none of it is purely a technical problem.

This post covers what CMS-0057-F (the CMS Interoperability and Prior Authorization Final Rule) requires, the main implementation problems you need to solve, and a few areas that catch teams out.

What makes this different from Patient Access

If you’ve implemented the Patient Access API under CMS-9115, you’ll recognize some of this, but the Provider Access API is not an extension of that work. It’s a separate API with a different architecture, a different authentication model, and different operational requirements.

The Patient Access API is patient-facing, using SMART App Launch, which allows the patient to authenticate and retrieve their own data. The Provider Access API is a provider-facing bulk API using SMART Backend Services, where a provider organization authenticates as a system client and pulls data for a group of attributed members. No patient login involved.

The data flows differently, the auth layer is different, and the operational responsibilities on the payer side are different. I’d recommend treating them as two separate builds rather than assuming the first one carries over.

What data you’re required to share

Under CMS-0057-F, the Provider Access API must make the following available to in-network providers:

• Claims and encounter data (excluding provider remittances and enrollee cost-sharing information)
• All data classes and elements in the applicable USCDI content standard
• Prior authorization information, excluding those for drugs

CMS (Centers for Medicare & Medicaid Services) strongly recommends using the Da Vinci Payer Data Exchange (PDex) Implementation Guide and the Da Vinci Prior Authorization Support (PAS) IG to profile the FHIR resources you expose. I’d recommend following PDex as the best path for conformance testing and for EHR integration to work in the real world.

One thing worth checking early: the data scope here is not a narrow summary view. Providers need enough claims and clinical history to prepare for a patient visit. If your Patient Access pipeline has gaps in source mapping or coverage limitations, those will show up here too.

Attribution

Before any data can flow, you need to know which providers can access which members. CMS requires payers to maintain an attribution process that associates members with in-network providers who have a treatment relationship with them.

CMS didn’t prescribe which attribution process to use. That flexibility sounds helpful until you realize it means you’re designing and building the whole thing yourself.

One big challenge: there’s no single system that has a complete, current picture of provider-member relationships. I see this a lot. Eligibility systems know who’s covered. Claims systems know who’s been seen. Network systems know who’s contracted. But none of them, on their own, are a reliable source of truth for treatment relationships.

A few things to think through before you start building:

• How will you handle new patients? CMS has indicated that payers could accept proof of an upcoming appointment as verification of a treatment relationship. That works, but you need a mechanism to receive and process that proof.
• How quickly does your attribution list need to update? CMS requires data to be available within one business day of a provider request or attribution status change. Overnight batches may not cut it.
• What happens when a provider-member relationship ends? A patient switches PCPs, or a provider leaves your network. Attribution needs to reflect that, and data access should close accordingly.
• Out-of-network providers aren’t required, but CMS encourages it where you can verify a treatment relationship. Worth deciding your position before implementation.

Existing eligibility and coverage verification processes between payers and providers can serve as a starting point for attribution queries, so you’re not necessarily starting from nothing. But you need to make a deliberate decision about which system owns each piece of attribution data before you start, because more than one of them will have a claim to it.

Patient opt-out

CMS requires payers to maintain a process for patients to opt out of having their data shared with providers under the Provider Access API. It’s mandatory. You also must give patients plain-language information about what’s being shared and how to opt out.

This catches a lot of teams off guard. CMS requires payers to give patients a way to opt out of having their data shared with providers, and to give them plain-language information about what’s being shared and how to opt out. Both are mandatory.

A few things the opt-out mechanism needs to handle:

• You need to capture opt-out preferences through a channel patients can use (member portal, phone, paper form).
• That preference must propagate to the attribution system before any data export runs and should be checked each time. The PDEX Provider Access Implementation guide recommends using the PDEX Provider Access Consent Profile to handle consent.
• You need to handle members who opt out and then opt back in.
• Opt-out status needs to be logged with timestamps for audit purposes.
• Opt-out applies across the board. CMS has confirmed that a patient opts out of sharing with all providers, not specific ones, which simplifies the consent model you need to build.

The plain-language communication requirement is also worth taking seriously. A notice buried in the member handbook doesn’t meet the intent. Share this with members through a channel they use, not just one that checks a legal box.

The bulk data mechanics

The Provider Access API uses FHIR Bulk Data, specifically the $davinci-data-export operation defined in the Da Vinci Member Attribution (ATR) IG. This is a system-level, asynchronous API, not a real-time query interface.

The basic flow: a provider system authenticates using SMART Backend Services, requests a bulk export for their attributed member group, and polls for the result. The payer system generates the export asynchronously and makes the files available for download.

The basic flow:  

1. The provider system authenticates using SMART Backend Services 
2. The provider system requests a bulk export for their attributed member group 
3. The payer system generates the export asynchronously 
4. The provider system polls for the results 
5. The payer system makes the files available for download
6. The provider system downloads results 

A few things worth having in your backlog:

v1 vs v2 workflow

The PDex IG describes both an attribution-based (v1) and an attestation-based (v2) workflow for Provider Access. The current recommendation for CMS-0057-F conformance is v2 (attestation), where the provider attests to a treatment relationship rather than relying entirely on a payer-maintained list. v1 remains relevant for value-based care data flows, so this isn’t a case of one replacing the other. If you started implementation work based on earlier IG versions, check which workflow you’re building against.

Authentication

SMART Backend Services is different from the SMART App Launch your Patient Access API uses. It requires system-level credentials and a different token exchange flow. If your auth infrastructure was built for patient-facing access, you’re adding a new auth pathway, not reusing the existing one.

The one-business-day requirement

CMS requires data to be available within one business day of a provider request or an attribution status change. For bulk exports, your pipeline needs to be fast enough that a request received at any point in the day can be fulfilled within that window. Overnight batch jobs are unlikely to be sufficient.

Financial data

The base CMS requirement excludes provider remittances and cost-sharing information. The PDex IG does allow payers to include financial data for value-based care contracts where the provider is at financial risk. Worth knowing which data scope applies to your provider relationships.

Prior auth data in the Provider Access API 

If you’ve worked through the Patient Access Prior Auth requirements, some of this will be familiar. The data requirements overlap, but the use case is different. A provider pulling this data is preparing for a patient visit, and the level of detail needs to reflect that.

For Prior Auth data, the PDex IG uses a combination of the ExplanationOfBenefit resource (for finalized PA decisions) and PAS profiles (for more detailed authorization information).

A few things to check before assuming your Patient Access pipeline covers this:

• Your prior auth pipeline needs to include pending and active decisions, not just finalized ones. Providers need the current status before a patient walks in the door.
• The data needs to surface at a level of detail a provider can use: clinical codes and decision details, not just an approval or denial flag.
• Confirm the drugs exclusion is scoped correctly. The same Part D vs medical benefit mapping issue from Patient Access applies here.

A note on reuse and what comes next

The infrastructure you build for the Provider Access API, particularly the attribution system and the SMART Backend Services auth layer, carries forward into the Payer-to-Payer API. It’s worth designing them as reusable components from the start rather than point solutions.

The attribution data and claims history this API exposes also lay the groundwork for quality measure reporting, care gap closure, and value-based care program management, but that’s a bigger topic for another time.

If you’re mapping where your CMS-0057-F implementation currently stands, the CMS-0057-F Readiness Checklist is a useful starting point.

If you’re building on Firely Server, it supports the bulk data operations, PDex-conformant resource profiles, and SMART Backend Services auth required for Provider Access. Get in touch if you want to talk through your specific situation.