Attribution (Provider Access v1): the Payer creates and maintains the member attribution list as a Group. No member match is involved. This workflow is mainly used for value-based care and risk-based contract data flows.
Attestation (Provider Access v2): the Provider submits the members it treats to $provider-member-match, attesting to a treatment relationship for each one, and the Payer creates a Group of the matched members. This is the workflow that supports the CMS-0057-F Provider Access API requirement.

The PDex IG (STU 2.2) states that, for the CMS-0057 Provider Access API obligation, payers SHALL support the v2 (Attestation) workflow, and providers SHOULD use it. The v1 (Attribution) workflow remains for value-based care and risk-based contract data flows, and a provider may use both with the same payer, choosing per data flow. See When to use Provider Access v1 (Attribution) versus Provider Access v2 (Attestation).

Both workflows end with the same $davinci-data-export operation on a Group ID. They differ in how that Group is created and found:

	Attribution (v1)	Attestation (v2)
Who creates the Group	The Payer, ahead of any request. See Create Group Resources.	The `$provider-member-match` operation, when the Provider calls it. It stores a Group of matched members, and returns Groups of non-matched and consent-constrained members.
How the Provider finds the Group ID	Searches for the Groups that carry its identifier. See Discover the Group IDs.	Reads it from the `$provider-member-match` response.
Treatment relationship	Implied by the Payer's attribution.	Attested by the Provider with a `Consent` resource (scope `treatment`) for each member in the request.
Member opt-out	The Payer removes the member from the Group, or configures the Consent Module. See Manage Consent.	Checked during the match: a member with an active PDex Provider Access `Consent` that denies sharing is returned in the consent-constrained Group instead of the matched Group. Exports of the matched Group are not rechecked; use the Consent Module for that.
Additional Payer setup	None.	The System to System Data Exchange module, which provides `$provider-member-match`. Matching and consent validation can be customized with a Custom Matching Script.
Lifetime of the Group	Maintained by the Payer for as long as the attribution applies.	Short-lived. The PDex IG suggests that a matched Group expires after about 30 days, but does not set a fixed limit. New patients, or requests after the Group may have expired, start with a new `$provider-member-match`.

The following steps are the same in both workflows: registering the provider system, creating its Organization resource, enabling the Da Vinci Data Exchange module, authenticating the provider system, and calling and polling $davinci-data-export. See Get Started.

Actors, Roles & Data Flow Data Scope, Use Cases and Timeliness