FHIR Consent is the resource that captures the member's permission for Payer-to-Payer Data Exchange. The user-facing opt-in flow generates a Consent resource that lives in the payer's FHIR store and gets referenced during the transfer. Patterns for structuring and using Consent vary across implementations, with consequences for audit defensibility, revocability, and operational complexity. Here are the five patterns worth knowing for the CMS-0057-F provider toolkit on this site.
1. Granular Consent With Scoped Categories
The most defensible pattern. The Consent resource specifies what data categories the member has authorized: claims, clinical data, prescription history, prior auth history, or a subset. The transfer flow respects the scope, retrieving only the categories the member opted into.
This pattern handles edge cases cleanly. Members who want their clinical history shared but not their prescription history have a clear path. Audit defenses are strong because the Consent resource carries the explicit scope.
The trade-off is implementation complexity. The opt-in flow has to present meaningful scope choices, the transfer logic has to filter by scope, and the audit log has to track scope alongside the data flow.
2. Time-Bounded Consent With Expiration
A pattern where Consent has a defined period (typically 90 days, 1 year, or the duration of enrollment). After expiration, the consent expires and additional transfers require renewed opt-in.
This pattern fits plans whose policies treat consent as a finite authorization rather than a permanent one. The trade-off is operational: tracking expirations, handling renewal flows, and managing edge cases when consent expires mid-transfer.
For most CMS-0057-F implementations, the consent is tied to enrollment duration. Time-bounded consent narrower than enrollment is rare but appears in some Medicaid managed care contexts.
3. Revocable Consent With Member Portal Withdrawal
A pattern where the member can revoke consent at any time through the member portal, and the revocation triggers a downstream cleanup. The Consent resource transitions from active to inactive status, and the payer's transfer logic stops processing for that member going forward.
The pattern handles member preference changes cleanly. The implementation complexity is in the downstream cleanup: data already transferred may still exist at the receiving payer (the revocation does not retroactively retract), and the audit trail has to show both the original consent and the revocation.
4. Bidirectional Consent With Co-Authorization
A pattern designed for the concurrent coverage case. When a member has two active plans, the Consent resource authorizes bidirectional data flow: prior plan to new plan and ongoing quarterly sharing between concurrent plans. The Consent reflects the full data movement, not just the one-time transfer.
This pattern fits plans with substantial concurrent coverage populations (Medicare Advantage with retiree supplements, dual-eligibles). The implementation complexity is in the Consent resource structure: it has to capture multiple data flows in one cohesive authorization.
5. Provenance-Linked Consent With Audit Chain
A pattern that links each transfer event to the originating Consent through FHIR Provenance resources. Every Bundle delivered carries a Provenance reference to the Consent that authorized the transfer. The audit chain is queryable: starting from any transferred resource, the audit can trace back to the originating Consent.
This pattern has the strongest audit defense and the most operational overhead. Most plans implement a lighter version (Consent reference in the transfer logs) rather than the full Provenance chain. The Provenance pattern appears in deployments where audit demands are highest.
How to Pick the Consent Pattern
The pattern choice depends on the plan's regulatory environment, audit posture, and member experience priorities. Plans in heavy-audit environments (Medicare Advantage, certain Medicaid programs) tend toward the granular and Provenance-linked patterns. Plans optimizing for simpler member experience use coarser scope with strong revocation support.
The patterns are not mutually exclusive. A production deployment can use granular scope + revocation + audit chain together; the constraints come from implementation complexity and member-facing simplicity, not from the data model.
For the user-facing opt-in flow that produces the Consent resource, the Top 5 Member opt-in flows for CMS-0057-F Payer-to-Payer covers the UX side. For the educational content that supports informed consent, the 5 Educational material patterns for Payer-to-Payer member opt-in covers the content design.