Provider Access API and Attribution: Who Gets to See What

Of the four APIs CMS-0057-F requires by January 2027, the Provider Access API is the one where the hard problem is not FHIR. Serving US Core resources over SMART Backend Services is well-trodden ground. The hard problem is an authorization question your payer has probably never had to answer as a real-time system decision before: does this provider, right now, have a treatment relationship with this member? Get that wrong in one direction and you have disclosed protected health information to a provider with no business seeing it. Get it wrong in the other direction and you have built a compliance API no provider can actually use.

This article walks through what the API must serve, the access gate CMS requires, and the attribution engineering — roster freshness, panel matching, decision auditing — that determines whether the thing works.

What the API has to serve

Per the CMS-0057-F fact sheet and FAQs, the Provider Access API must make three categories of data available to in-network (or enrolled, for Medicaid and CHIP FFS) providers with whom the patient has a treatment relationship:

• Individual claims and encounter data — explicitly without provider remittances and enrollee cost-sharing information. That exclusion is the main data-shape difference from the Patient Access API, which does carry cost-sharing data for the member's own eyes.
• All data classes and elements in USCDI — the content standard adopted at 45 CFR 170.213, served over FHIR R4 with the US Core profiles.
• Specified prior authorization information, excluding drugs — and per CMS's FAQ comparison table, that includes denied prior authorizations, with PA information available for one year after the authorization's last status change. Claims and clinical data go back to a January 1, 2016 date of service.

The response-time expectation is concrete: once a provider requests data, the payer must make it available no later than one business day — conditioned on the provider being authenticated, the patient being attributed to that provider, no opt-out on file, and no legal prohibition on disclosure. CMS finalized that turnaround with clinic workflows in mind: the provider is pulling payer data in proximity to a visit, not running a research query.

Compliance dates differ slightly by program: January 1, 2027 for Medicare Advantage organizations and state Medicaid/CHIP FFS programs, the rating period beginning on or after that date for Medicaid and CHIP managed care, and plan years beginning on or after that date for QHP issuers on the FFEs.

The access gate: three checks, in order

The rule's condition list for releasing data is effectively a three-stage policy gate, and it is worth implementing it as exactly that:

Authentication and network status — verify the identity of the requesting provider organization and confirm it is in-network or enrolled. The technical standards (SMART Backend Services with Bulk Data Access for this API) get you identity; network status is a lookup against your own provider data, with all the data-quality baggage that implies.

Attribution — confirm a treatment relationship exists between this provider and this member. More on this below, because it is the whole game.

Consent posture — check that the patient has not opted out. Note the asymmetry CMS built deliberately: Provider Access is opt-out (data flows unless the patient says stop), while the Payer-to-Payer API is opt-in (data flows only with the patient's permission). If your consent service models both as one boolean, you will ship a bug. They are different defaults, captured at different moments, with different revocation semantics.

Wrapped around the gate is an education requirement: payers must provide plain-language resources to patients about the benefits of the exchange and their ability to opt out, and to providers about how to request data and how the payer's attribution process works. That second one is worth taking seriously as an engineering deliverable — your attribution rules have to be explainable enough to document for outsiders.

Attribution: CMS punted on the process, deliberately

CMS requires an attribution process but declines to prescribe one. The final rule and the Provider Access API FAQ sketch acceptable approaches: claims history establishing an ongoing relationship, existing patient rosters for providers or organizations such as ACOs, and — for new patients with no claims yet — evidence of an upcoming appointment, which payers can piggyback on the eligibility-verification query providers already run before a first visit. The rule also points at two useful prior-art references: the Medicare FFS Data at the Point of Care pilot, where providers attest to a treatment relationship as they add each patient to a maintained roster, and the HL7 Da Vinci Member Attribution (ATR) List IG, which standardizes the exchange format for attribution lists without dictating how the list is derived.

That flexibility is a gift and a trap. The gift: you can reuse machinery you already run for value-based contracts and care management. The trap: "use what you have" becomes "trust a roster nobody has reconciled since the contract was signed."

The two failure modes: roster freshness and panel matching

Roster freshness. Claims-based attribution is authoritative but slow — a claim proves a relationship weeks after the encounter, which is exactly backwards for an API meant to serve data before a visit. Roster-based attribution is fast but decays: providers leave groups, panels close, members switch PCPs, and the roster your network team exported last quarter silently diverges from reality. A workable design layers the two: claims history as the durable base, roster and appointment evidence as the fresh edge, each attribution record carrying its evidence type and an expiry appropriate to that evidence. An appointment-based attribution for a new patient should not quietly live forever; a ten-claim history with a PCP should not expire because a roster refresh hiccuped.

Panel matching. The requesting identity is an organization credential; the treatment relationship may exist at the individual-clinician level. You have to decide — and document — at what grain you attribute. Match on individual NPI and you will deny legitimate requests when a covering clinician or a new hire in the same practice requests data. Match on organizational NPI or TIN and a 400-clinician group gets every attributed member's data through one credential. The final rule's comment discussion acknowledges exactly this tension and leaves the choice to payers. A defensible middle: attribute at the practice level for data release, but record the individual clinician context when the request supplies it, and let your audit trail — not your access gate — carry the finer grain.

Designing the access-control layer

Treat the gate as a policy decision point that produces an auditable artifact, not an inline if statement:

• Deny by default, decide with evidence. Every permit decision should record which attribution evidence fired (claims window, roster version, appointment attestation), the opt-out check result, and the network status snapshot. When a member or regulator asks why Dr. X saw this record, you answer from the log, not from archaeology.
• Cache attribution decisions with honest TTLs. One business day of latency budget invites caching; stale-roster incidents argue for short TTLs on roster-derived permits and longer ones on claims-derived permits.
• Opt-out wins immediately. Consent revocation must invalidate cached permits at once — not at the next batch refresh. This is the audit finding that writes itself.
• Scope bulk to the panel. Bulk Data Access is a required standard for this API; a bulk export must be filtered to the requesting organization's currently attributed members, re-evaluated at export time, not at request time.

Every one of these events — permit, deny, opt-out change, roster refresh — belongs in your audit pipeline with the same discipline you apply to any PHI access.

Where to start

Build the attribution service first and the FHIR facade second. The facade is commodity; the attribution service encodes decisions only your plan can make — evidence hierarchy, matching grain, TTLs, exception handling — and it is also the component your provider-facing documentation must describe in plain language. If you can write that document today and your systems already behave the way it says, you are ahead of most of the market. If you cannot, that gap is the project.

Verify requirements against the CMS-0057-F rule text (89 FR 8758), the CMS Provider Access API FAQs on cms.gov, and the current Da Vinci PDex and ATR implementation guides; all continue to evolve.