Actors and Roles

• Payer System – Hosts the FHIR server (e.g. Smile Digital Health) containing claims, clinical, and prior authorization (PA) data. Validates provider access and enforces patient opt-out preferences.
• Provider System (EHR) – Authenticated client system that requests patient data for treatment. Registers with the payer as a SMART on FHIR client system.
• Member (Patient) – The individual whose data is being accessed. May opt out to restrict data sharing.

Data Flow Overview

Administrative Setup (Pre-requisites)

1. Client Registration: The Provider EHR registers as a SMART on FHIR client.
2. Identity Mapping: A FHIR Organization resource is created/linked to the EHR client, containing the Provider’s unique Business Identifier (e.g., NPI or Internal ID).

The Da Vinci PDex IG defines two ways for a provider to obtain the FHIR Group that it exports from:

• Attribution: the Payer creates and maintains the member attribution list. No member match is involved. This workflow is mainly used for value-based care and risk-based contract data flows.
• Attestation: the Provider submits the members it treats to $provider-member-match, and the Payer returns a matched Group. This is the workflow that supports the CMS-0057-F Provider Access API requirement.

Both workflows then use the same $davinci-data-export operation against a Group ID.

Creation of Member Attribution (Access) List by the Payer (Attribution workflow)

1. Attribution List Creation: The Payer generates FHIR Group resources to define the member-to-provider relationship.
2. Linking: Each Group includes the Provider’s Business Identifier in the Group.managingEntity or via a specific characteristic to ensure the data is only accessible by that specific Provider.

Payer and Provider Session

1. Authorization Request: The Provider System authenticates via OAuth 2.0.
2. Token Introspection & Scoping: Upon successful authentication, the Payer System: -Identifies the Provider’s Business Identifier from the Organization resource containing the Provider's OIDC Client ID. -Locates the FHIR Group(s) (Attribution Lists) associated with that Identifier. -Issues an Access Token scoped specifically to the members within those groups.OnAuthenticationSuccess
3. The provider queries the payer’s FHIR server using approved scopes (for example, patient/*.read or user/*.read) set by the Payer.
4. Group identification:

• Attribution workflow: The Provider can query FHIR group IDs (member attribution list) associated with them
• Attestation workflow: The Provider submits a $provider-member-match request listing its patients, with a Consent resource attesting to a treatment relationship for each one. The Payer matches each patient to a member, checks for a provider access opt-out, and returns Groups of matched, non-matched and consent-constrained members. The Provider uses the ID of the matched members Group in the next step.

5. Data Request: The Provider initiate exports on the Payer’s FHIR server based on FHIR group ID ( $davinci-data-export)
6. The payer validates the access.
7. The payer returns relevant FHIR patient level resources of the FHIR Group (based on its membership)

In the Attestation workflow, the matched Group is short-lived. The Provider can run several exports against it while it remains valid, for example _since delta exports or exports for a subset of members. The PDex IG suggests that a matched Group expires after about 30 days but does not set a fixed limit. Requests for new patients, or requests after the Group may have expired, start with a new $provider-member-match, which also re-checks opt-outs and treatment relationships.