Concurrent coverage is the part of CMS-0057-F Payer-to-Payer Data Exchange that breaks the simple mental model of "old payer transfers to new payer once." Many members carry two plans at the same time: Medicare with a supplement, employer plus spouse coverage, Medicare with Medicaid, or commercial plus a specialty carve-out. CMS-0057-F requires quarterly data sharing across concurrent coverage, not just once at enrollment. Six patterns have emerged for handling this complexity in 2026. For broader context, more on health plan data movement covers the surrounding architecture.

1. Quarterly Scheduled Pull Between Plans

The simplest pattern. Each plan runs a scheduled Member Match against the other plan's data each quarter, pulls any new data for shared members, and ingests it. The schedule alignment is straightforward (calendar quarters work for most plans), and the operation is predictable.

The trade-off is that data changes between quarterly pulls are not visible until the next pull. For high-volume changes (active treatment, frequent visits), the quarterly latency can be operationally meaningful.

2. Event-Driven Pull on Significant Coverage Change

A more sophisticated pattern that triggers a pull when the receiving payer notices a significant coverage event (new claim from the other plan's network, change in coverage period, change in benefit structure). The pull is targeted rather than full-history.

The pattern reduces unnecessary data movement but requires event detection logic in the receiving payer's claims system. Plans without modern event-driven claims platforms find this harder to implement.

3. Subscription-Based Notification With Pull

The pattern that emerges as TEFCA matures. Each plan subscribes to a notification channel for the other plan's significant member events. When an event occurs, the notification triggers a targeted pull. The Subscription model handles the notification layer, and the Bulk Data export handles the actual transfer.

This pattern is well-suited to FHIR Subscriptions and TEFCA-conformant networks. It is rare in mid-2026 but expected to become common as the network infrastructure matures.

4. Coordinated Plan Designation

For members with formal Coordination of Benefits arrangements (Medicare Secondary Payer rules, for example), the plans agree on primary versus secondary status and the data flow follows the agreed designation. The primary plan exports its data to the secondary on a documented cadence (usually monthly), and the secondary handles the inverse if applicable.

This pattern works well when both plans run COB processes that are already in place. For Medicare Advantage with retiree supplements, this is the default approach for many plans.

5. Member-Initiated Refresh

The pattern that puts control in the member's hands. The member can request an updated transfer at any time through the member portal, and the receiving payer fetches updated data from the prior or concurrent plan. The opt-in extends to ongoing refresh requests, not just the initial transfer.

This pattern handles edge cases that quarterly scheduling misses but adds operational load when members trigger refreshes during peak times.

6. Hybrid Concurrent and Sequential Logic

The pattern most large payers actually implement. Quarterly scheduled pulls cover the baseline. Event-driven pulls cover significant changes between scheduled cycles. Member-initiated refreshes cover individual cases. The receiving payer's ingestion layer deduplicates across the three channels.

This hybrid is the most operationally complex but the most robust for concurrent coverage cases. Plans with significant dual-eligible (Medicare-Medicaid) populations or specialty carve-out arrangements default to this hybrid because the simpler patterns leave too many edge cases.

How Concurrent Coverage Interacts With Member Match

Concurrent coverage complicates Member Match. A member with two plans has data at both, and the Match engine has to confirm identity at each plan. Plans that maintain consistent member identifiers across coverage transitions have an easier time; plans that re-issue identifiers at each coverage period create matching friction.

For the broader five-year history transfer that runs alongside concurrent coverage handling, the Best practices for 5-year history transfer covers the surrounding patterns. For the question of whether to handle these flows via TEFCA or direct API, the TEFCA vs Direct API comparison covers the transport-layer trade-offs.

Sources

• Da Vinci PDex IG v2.1.0

The FHIR Group resource is how provider panels get expressed in Provider Access. Each in-network provider has one or more Group resources listing the members attributed to them, and the group-level Bulk Data export operates against these Groups. The Group resource is conceptually simple but the patterns for managing it vary substantially across implementations. Six patterns have emerged in 2026 production deployments. For more on FHIR attribution patterns on this site, these are the practical patterns.

1. Materialized Group With Scheduled Rebuild

The most common pattern. The Group resource is materialized in the FHIR store, with member references explicitly listed. A scheduled job rebuilds the Group at a defined cadence (typically nightly or weekly) from the underlying attribution data.

The pattern is operationally simple. The Group is a static resource the rest of the system can query like any other FHIR resource. The trade-off is the rebuild cadence: changes to attribution between rebuilds are not reflected, which can produce slightly stale panels for Provider Access requests.

2. Virtual Group With On-Demand Resolution

A pattern where the Group is virtual: the FHIR API exposes Group resources but resolves the membership list at query time from the attribution database. The Group does not exist as stored data; it is computed on demand.

The pattern produces always-fresh attribution. The trade-off is the query-time cost: each Group access triggers an attribution lookup, which can be slow for large panels.

3. Hierarchical Group With Sub-Groups

A pattern for handling provider organization hierarchies. A health system has Groups at the organization level, the specialty level, and the individual provider level. Sub-groups roll up to parent groups. Provider Access requests can query at any level of the hierarchy.

The pattern fits provider organizations with multi-level structure (an academic medical center with departments, divisions, and individual physicians). The implementation complexity is in maintaining the hierarchy consistently as the organization changes.

4. Multi-Attribution Group With Scope Tagging

A pattern that handles members with multiple attributions (PCP plus specialist). The Group resource includes the member with a scope tag (extension) indicating which attribution applies. Provider Access requests can filter by scope tag to get attribution-specific Group membership.

The pattern handles specialty carve-outs cleanly. The implementation requires the FHIR Group resource to support the scope tagging, which means using extensions consistently.

5. Time-Bounded Group With Effective Dates

A pattern where Group membership has effective start and end dates. A member who joined a PCP's panel in March is recorded with that start date; a member who left in August is recorded with that end date. The Group reflects the current effective membership at query time.

The pattern handles attribution changes over time defensibly. Historical Provider Access requests can reconstruct who was attributed when. The implementation complexity is in maintaining the effective dates and pruning expired records.

6. Hybrid Materialized Plus Live Lookup

A pattern that combines materialized Group resources for performance with live lookup for currency. Most queries hit the materialized Group (fast). Specific high-importance queries (PA decisions, recent attribution changes) trigger a live lookup against the attribution database.

The pattern fits production deployments at scale. The materialized layer handles the typical query load; the live lookup handles the cases where freshness matters more than performance.

How the Group Resource Patterns Interact With Bulk Data Export

The pattern choice affects how group-level Bulk Data export performs. Materialized Groups produce fast exports because the member list is already resolved. Virtual Groups produce slower exports because the member list has to be resolved before the export can start. Time-bounded Groups need export-time filtering for the relevant effective date.

For typical CMS-0057-F production deployments, the materialized pattern with scheduled rebuild is the default starting point. Plans with high attribution churn or specialty carve-outs extend toward the hierarchical, multi-attribution, or hybrid patterns.

What the FHIR Group Spec Allows and What It Implies

The FHIR R4 Group resource is flexible: it allows actual or descriptive membership, characteristic-based filtering, and various member identifier patterns. Production implementations need to pick a specific pattern and apply it consistently. The spec does not enforce a single pattern, which means cross-implementation interoperability depends on documented conventions.

For the broader question of which attribution methodology drives the Group contents, the Best attribution-of-record patterns for CMS-0057-F Provider Access covers the methodological choices. For the export-side performance that Group resource design affects, the Top 5 Async Export patterns for FHIR Bulk Data implementations covers the export layer.

Sources

• FHIR R4 Group resource

Da Vinci publishes a portfolio of FHIR Implementation Guides covering provider-payer interactions. CMS-0057-F anchors on a few of them (CRD, DTR, PAS) but several others matter for the broader provider-side workflow. EHR integration teams need to understand which IGs are required for compliance, which are emerging standards, and which are experimental but worth watching. For payer-provider FHIR integration reading on this site, here are six worth knowing in 2026.

1. Da Vinci CRD IG STU 2.0.1

Coverage Requirements Discovery (CRD) is the order-time decision support IG. The CRD service responds to CDS Hooks calls from the EHR with information about whether PA is required, what documentation is needed, and what comes next. CMS-0057-F requires CRD as part of the Prior Authorization API.

For EHR integration teams, CRD is the entry point. A clinician's order triggers the CRD call; everything downstream depends on whether CRD fires reliably and returns useful information.

2. Da Vinci DTR IG STU 2.0.1

Documentation Templates and Rules (DTR) is the questionnaire-rendering IG. The DTR SMART app launches inside the EHR (typically from a CRD card), renders the payer-specific Questionnaire, runs CQL rules to drive conditional logic, and collects the supporting documentation needed for the PA decision.

DTR is where the provider workflow lives. If DTR is awkward to use, providers abandon the workflow and submit PAs through legacy channels regardless of what the rest of the stack does.

3. Da Vinci PAS IG STU 2.0.1

Prior Authorization Support (PAS) is the submission and response IG. The completed Bundle from DTR is sent to PAS, the payer renders a decision, and the response flows back. PAS often round-trips through X12 278 / 275 inside the payer back office.

PAS is the layer most often confused with the entire ePA workflow. In practice, PAS is the submission endpoint that closes the loop the CRD-DTR sequence opened. All three IGs operate together; isolating any one of them produces an incomplete picture.

4. Da Vinci PDex IG STU 2.1.0

Payer Data Exchange (PDex) is the IG that governs clinical data exchange between payers and providers, including the broader Patient Access API scope. PDex is referenced by CMS-0057-F for Provider Access and Payer-to-Payer flows, and it carries the clinical resource profiles (Condition, Procedure, Observation) that PDex Plan Net and CARIN BB do not cover.

For EHR integration teams, PDex Patient Access is the IG that defines what clinical data the EHR can expect when consuming the Patient Access API.

5. Da Vinci HRex IG

Health Record Exchange (HRex) is a foundation IG that PDex and the other Da Vinci IGs reference for shared profiles and patterns. Most implementations do not directly target HRex but pull profiles from it through the IGs that use it.

For deep implementation work, HRex is worth understanding because changes there ripple through PDex, PAS, and others.

6. Da Vinci Risk-Based Contract IG (Emerging)

The Risk-Based Contract IG is newer Da Vinci work that addresses value-based care contract data exchange between payers and providers. It is not part of CMS-0057-F but signals where the Da Vinci portfolio is heading.

For payers and EHRs that participate in risk-based contracts (which is most large US payers and many health systems), the Risk-Based Contract IG is worth tracking. Production deployments are limited in 2026 but expected to grow.

How to Read Da Vinci IG Maturity

Da Vinci IGs use the standard HL7 maturity ladder: Draft, Trial Use (STU), and Normative. STU 2.0.1 or later for CRD, DTR, and PAS represents maturity adequate for CMS-0057-F production work. Earlier versions exist but should not be the integration target for new work in 2026.

A useful pattern during integration planning is to verify which IG versions the target EHR and the payer's platform actually support, because mismatches surface as conformance failures during testing.

For the CDS Hooks layer that powers CRD specifically, the Top 5 EHRs with strong CDS Hooks support for Da Vinci CRD covers the EHR-side picture. For the SMART App patterns that power DTR, the Best DTR SMART app patterns for provider workflows covers the implementation side.

Sources

• Da Vinci CRD IG v2.0.1

Bulk Data exports are the part of the CMS-0057-F stack that hides operational issues most easily. A failed export looks like a successful 202, then a status URL that returns in-progress for too long, then eventually a timeout. A partial export looks complete but has missing files. Monitoring tools that catch these issues are the difference between operational stability and audit problems. Five tools have emerged as the practical monitoring stack for FHIR Bulk Data in 2026. For the inter-payer transfer reference on this site, these are the field-tested tools.

1. Datadog APM With FHIR Tracing

Datadog APM captures end-to-end traces of Bulk Data export operations: the initial export request, the async processing inside the server, the NDJSON file generation, the consumer-side download. Traces let operations teams pinpoint where exports slow down or fail.

For payers running Bulk Data in cloud environments (AWS, GCP, Azure), Datadog integrates with the infrastructure metrics layer. The combination of FHIR-level tracing and infrastructure-level metrics catches issues that either layer alone would miss.

2. Grafana + Prometheus for FHIR Server Metrics

Grafana paired with Prometheus is the open-source pattern for FHIR server monitoring. Most production FHIR servers (Smile CDR, HAPI FHIR, 1upHealth, InterSystems IRIS, others) expose Prometheus metrics endpoints. Grafana dashboards surface export volume, latency, error rate, and resource utilization.

The setup requires more configuration than the cloud-native APM tools but produces highly customizable monitoring. For payers with strong in-house DevOps capability, this is often the preferred stack.

3. Inferno for Conformance Drift Detection

Inferno tests can run in scheduled mode rather than just on-demand. Running the Bulk Data Inferno suite against the production environment on a nightly cadence catches conformance drift before it produces customer-facing issues.

The pattern is to run a subset of Inferno tests against production (full Inferno is too heavy for nightly), with the subset focused on the cases most likely to drift (manifest format, NDJSON output, status endpoint behavior).

4. Custom Health-Check Endpoints for Consumer-Side Validation

A pattern where the Bulk Data implementation exposes health-check endpoints that consumers can call to validate behavior without running full export tests. The health-check endpoint runs a small synthetic export against test data and returns the resulting manifest plus a small sample of the NDJSON output.

This pattern lets consumer-side teams validate the export behavior continuously without burdening the production environment with large exports. Most production Bulk Data implementations expose some version of this; the spec does not require it but the operational value is high.

5. Distributed Tracing With Cross-Service Context

For Bulk Data implementations that span multiple services (FHIR server, async job queue, NDJSON file generator, storage layer), distributed tracing captures the full lifecycle of an export across service boundaries. Tools like Jaeger, Zipkin, or the cloud-native equivalents (AWS X-Ray, Google Cloud Trace) handle this layer.

The pattern matters more for complex implementations than for monolithic ones. A simple FHIR server with built-in async export does not benefit much from distributed tracing. A complex implementation with a separate job queue and storage tier benefits substantially.

The Metrics That Matter for Production-Grade Operations

A useful baseline set of metrics to track: export request rate (per minute, per hour), export latency (P50, P95, P99 by request size), error rate (by error class), output file size distribution, consumer-side download latency, and Inferno conformance pass rate over time.

Plans that track these consistently catch operational drift early. Plans that rely on user reports to surface issues discover problems after they affect compliance reporting or provider satisfaction.

How the Monitoring Stack Fits the Broader Picture

The monitoring stack is one piece of CMS-0057-F operational maturity. It pairs with the async export patterns (which determine what metrics matter) and with the opt-out handling (which adds operational complexity to Bulk Data).

For the async export patterns that the monitoring is built around, the Top 5 Async export patterns for FHIR Bulk Data implementations covers the operational layer. For the member opt-out patterns that complicate Bulk Data operations, the 5 Patterns for member opt-out in FHIR Bulk Data exports covers the privacy layer.

Sources

• FHIR Bulk Data Access IG v2.0.0

Cerner Oracle Health (the renamed Cerner under Oracle ownership) is the second-largest US EHR by patient volume. The Cerner Open Developer Experience (CODE) platform is the integration framework for third-party apps and CDS services. For payer-built Da Vinci PAS integrations targeting Cerner customer provider organizations, five patterns have emerged as production-grade in 2026. For broader context, more on payer-to-payer transfers covers an adjacent CMS-0057-F topic.

1. Register the CDS Service in CODE and Map to Cerner's Hook Triggers

The first practice is the foundational one. The payer's CDS service for Da Vinci CRD registers through CODE, declares which hooks it implements (order-sign, order-select, medication-prescribe), and provides the discovery URL. Cerner customer environments can then enable the service in their workflow configuration.

The CODE registration process is more lightweight than Epic App Orchard certification but still requires conformance validation. Plans submitting CDS services to CODE for the first time should budget six to ten weeks for the full registration and customer-environment enablement cycle.

2. Use Cerner's Standard SMART App Launch Patterns for DTR

Cerner supports SMART App Launch broadly. Payer-built DTR SMART apps launch through the standard SMART flow with Cerner-specific context handoff. The app receives Patient, Encounter, and the relevant clinical context for pre-population.

The pattern that works is to design the DTR app for the standard SMART App Launch sequence rather than building Cerner-specific deviation. Cerner's implementation handles the standard flow cleanly; deviations sometimes work but become per-environment configuration burdens.

3. Test the Sandbox-to-Production Transition Carefully

Cerner's sandbox environment behaves slightly differently from production customer environments. Apps that work cleanly in the sandbox sometimes encounter friction in specific customer environments because of configuration differences. The pattern is to test broadly across customer environments before declaring production-readiness, similar to the Epic recommendation but with more variance because Cerner customer customization is broader.

The practical approach is to coordinate with Cerner customer testing programs (some larger Cerner-using health systems have established programs for testing payer-built apps). Direct testing arrangements catch issues earlier.

4. Handle Cerner's PAS-Specific Submission Patterns

PAS submission from Cerner has some platform-specific behaviors. Cerner customer organizations sometimes route PAS submissions through specific Cerner middleware before they reach the payer's PAS endpoint. The middleware may modify the FHIR Bundle slightly (adding routing context, normalizing identifier formats).

Payer PAS endpoints that handle Cerner-specific Bundle variants without rejecting them avoid friction. Endpoints that strictly enforce baseline Bundle format sometimes produce unexpected rejections for Cerner-submitted Bundles.

5. Coordinate With Cerner's Behavioral Health and Specialty Workflows

Cerner has stronger market presence in certain healthcare verticals: behavioral health, specialty care, and large hospital systems. Da Vinci PAS integrations from payers serving these verticals encounter Cerner-specific workflow patterns that are less common at Epic-using customers.

Payers building broad CMS-0057-F integration should know which of their target provider populations are predominantly on Cerner and tune the integration for those workflow patterns. The integration that works perfectly for Epic-using primary care may need adjustments for Cerner-using behavioral health.

What Cerner Customers Actually Care About

Cerner customer organizations evaluating payer-built apps tend to weight three factors. First, ease of enablement: how much customer-side configuration work is needed to turn the integration on. Second, workflow fit: does the integration respect existing Cerner workflow patterns. Third, support quality: when the integration breaks, who fixes it and how quickly.

Payers that document these dimensions clearly during onboarding get faster customer adoption than payers that ship technically conformant integrations without operational documentation.

How This Fits the Broader EHR Integration Picture

Cerner integration follows similar high-level principles to Epic integration (certify early, use standard patterns, test broadly) with platform-specific variations. The patterns are not interchangeable; the work is parallel rather than identical.

For the parallel Epic-side work, the Best practices for Epic integration with payer FHIR APIs covers the Epic-specific guidance. For the broader landscape of EHR CDS Hooks support beyond Cerner and Epic, the Top 5 EHRs with strong CDS Hooks support covers the field.

Sources

• Da Vinci PAS IG v2.0.1

Member opt-in for Payer-to-Payer Data Exchange is the user-facing layer where the technical infrastructure meets actual members. CMS-0057-F requires the receiving payer to capture explicit opt-in for the transfer, along with educational materials explaining what data will move. The design of this flow determines opt-in rates, audit defensibility, and member satisfaction. Five patterns have emerged across 2026 deployments, each with different operational characteristics. For broader context, more on TEFCA and CMS interop covers the surrounding regulatory layer.

1. Enrollment-Time Opt-In Inside Member Application

The most common pattern. During the member's plan enrollment application, a section explains Payer-to-Payer transfer and offers opt-in. The member checks a box, signs electronically, and the consent is captured in the application record.

This pattern catches the highest opt-in rate because the member is already engaged in onboarding. The educational content is short, the friction is low, and the consent record is part of the formal enrollment package. The trade-off is that members who skip the optional section default to no transfer, which means clean documentation but lost transfer opportunity.

2. Welcome Sequence Opt-In Through Member Portal

A pattern where opt-in arrives during the post-enrollment welcome sequence. The new member receives a welcome message that includes a link to the Payer-to-Payer opt-in flow, and the flow lives in the member portal with longer educational content and richer interaction.

This pattern catches members who skipped the enrollment-time opt-in and provides more educational depth. The opt-in rate is typically lower than enrollment-time but higher than later-stage prompts. The trade-off is the timing window; members who delay engagement may not opt in before clinical needs arise.

3. Triggered Opt-In on First Clinical Event

A pattern where the system detects when the member has a clinical event (first appointment, first claim, first prescription) and triggers an opt-in request with the context "we noticed you have a new appointment, would you like us to retrieve your history from your prior plan."

The pattern catches members at moments of clinical relevance, when the transfer's value is most concrete. Opt-in rates at this stage are higher than passive welcome flows because the member sees the immediate benefit. The trade-off is the implementation complexity; the trigger logic has to work across claims, scheduling, and pharmacy systems.

4. Mobile App In-Context Opt-In

A pattern that lives in the payer's mobile app, with the opt-in presented as a one-tap card alongside other onboarding tasks. The mobile context allows for biometric authentication, which produces a stronger consent record than browser-based checkboxes.

This pattern works best for plans with strong mobile app adoption. For plans whose members primarily engage via web or call center, the mobile flow misses substantial population.

5. Call-Center-Mediated Opt-In

A pattern where the call center handles opt-in during member service calls. The agent explains the option verbally, captures opt-in through the agent's interface, and the consent is recorded in the system.

This pattern is the lowest-tech but highest-engagement for populations that prefer phone interaction over digital. Senior populations and members with limited digital access benefit. The operational cost is real: agents need training, the consent capture has to be documented for audit, and call handle times extend slightly.

How to Pick the Flow Mix

Most production deployments run a combination. Enrollment-time is the baseline because it catches the easy cases. Welcome-sequence picks up the second-chance population. Triggered opt-in handles the engagement gap. Mobile in-context is layered on top for plans with strong mobile adoption. Call-center mediation handles edge cases.

The numbers vary by population. Plans with younger, digitally engaged members get most opt-ins from enrollment-time and mobile. Plans with older or less digital populations rely more on welcome-sequence and call-center patterns.

For the educational content that supports each flow, the 5 Educational material patterns for Payer-to-Payer member opt-in covers the content design. For the technical FHIR Consent capture underneath the user-facing flow, the Top 5 FHIR Consent patterns for Payer-to-Payer covers the data layer.

Sources

• Da Vinci PDex IG (opt-in flow)

Member Match accuracy determines whether Payer-to-Payer Data Exchange works at all. A false negative loses the member's history, a false positive triggers a privacy incident. Five strategies have emerged as the practical patterns in 2026, each with different operational characteristics and trade-offs. Most production deployments combine two or three of them. Here are the five worth knowing for more on payer-to-payer transfers decisions.

1. Deterministic-First with Probabilistic Fallback

The most common pattern in 2026 deployments. The Member Match engine first attempts a deterministic match (exact identifier, name, DOB, SSN where allowed). If no deterministic match, it falls back to probabilistic with a high confidence threshold (typically 0.9 or above). Below the threshold, the request returns no match and the receiving payer cannot consume data.

This pattern minimizes false positives at the cost of accepting some false negatives. The trade-off works for plans that consider data loss less risky than wrong-patient data.

2. Probabilistic with Operator Review for Mid-Confidence

A more aggressive pattern that adds an operator-review queue for mid-confidence matches (typically 0.7 to 0.9). The match returns provisional, and a human reviewer at the prior payer confirms or rejects before the data transfer completes.

The pattern catches more matches than deterministic-first but requires operational capacity. Plans with high member-switching volume need to staff the review queue carefully or face transfer backlogs.

3. Referential MPI with Universal Identity Source

Pattern where the Member Match engine consults a third-party referential identity database (Verato's Universal Identity is the canonical example) to fill demographic gaps. The receiving payer's request gets enriched with referential data, which improves match quality against the prior payer's records.

The pattern increases match accuracy on incomplete data substantially. The trade-off is the commercial relationship with the referential provider and the data flow through their infrastructure during matching.

4. Coverage-Anchored Match

Some implementations leverage the Coverage resource in the Member Match Bundle for additional matching signal. The receiving payer's Coverage information often includes prior plan ID, group number, or subscriber details that the prior payer can use to confirm match in cases where demographic data alone is ambiguous.

The pattern is particularly effective when members move between plans within the same parent insurer (Medicare Advantage to Medicare Advantage at the same carrier) or between affiliated plans. Member ID transitions become a strong match signal.

5. Network-Mediated Match via TEFCA

For payers participating in TEFCA, Member Match can route through the network's identity infrastructure rather than running point-to-point. The QHIN handles the match across multiple data partners, and the result is delivered to the requesting payer. The pattern shifts the match operation out of the payer's direct control but reduces the per-relationship engineering work.

For payers without TEFCA participation, this pattern is not available. Most 2026 deployments are not yet using TEFCA for Member Match at production scale, but the path is starting to materialize.

How to Pick the Strategy for Your Plan

The strategy choice usually combines two or three patterns rather than picking one. A typical mid-market payer uses deterministic-first with probabilistic fallback as the baseline (covers the easy cases cleanly), adds coverage-anchored matching for cases where demographic data is ambiguous (catches plan-switching cases), and may add operator review for high-stakes cases (specialty drug PA history, ongoing chronic care).

Plans with substantial member acquisition volume from sources with weak data quality benefit from referential MPI. Plans with stable member populations that switch primarily within established carrier relationships rely more on coverage-anchored matching.

For the underlying deterministic versus probabilistic trade-off, the Deterministic vs Probabilistic Member Match comparison lays out the algorithmic side. For the Consent flow that runs alongside Member Match in the Payer-to-Payer transfer, the Top 5 FHIR Consent patterns for Payer-to-Payer covers the parallel layer.

Sources

• Da Vinci PDex IG v2.1.0 (Member Match operations)

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.

Sources

• FHIR R4 Consent resource

CDS Hooks is the integration pattern that lets Da Vinci CRD fire at the right point in the provider workflow. Without strong EHR support for CDS Hooks, the CRD message never reaches the clinician, and the workflow value of Coverage Requirements Discovery collapses. Five EHRs have strong CDS Hooks support in 2026, with the others ranging from partial to none. For related provider-side ePA guides, this is the practical landscape.

What "Strong CDS Hooks Support" Actually Means

A strong CDS Hooks implementation does four things. It fires hooks at the right workflow triggers (order-sign, order-select, appointment-book, medication-prescribe) consistently. It passes complete context to the CDS service (Patient, Encounter, draft order, relevant clinical data). It renders returned cards prominently in the clinician's view, not buried in a separate panel. It logs hook invocations and clinician actions for audit.

Implementations that fire hooks but pass incomplete context produce CDS responses based on guesses. Implementations that fire hooks but bury the response cards produce low clinician engagement. Both fail to deliver the intended value even though they pass technical conformance.

1. Epic

Epic has the most mature CDS Hooks implementation in the US market in 2026. The supported hooks cover the full set relevant to CRD (order-sign, order-select, medication-prescribe). Context passing is complete. Cards render in the order-entry workflow where the clinician naturally encounters them. Epic App Orchard certifies third-party CDS services for production deployment.

The certification process takes time (three to six months typically), which means payers need to start the Epic certification path well ahead of the production deadline.

2. Cerner Oracle Health

Cerner Oracle Health has strong CDS Hooks support through the Cerner Open Developer Experience (CODE) platform. The hooks fire at expected workflow triggers, context is well-formed, and the card-rendering UX is competent. CODE handles the certification for third-party CDS services through a structured but somewhat lighter process than Epic.

The implementations vary slightly across Cerner customer sites because of configuration differences. Payers building Cerner integrations test across multiple customer environments rather than relying on the sandbox alone.

3. athenahealth

athenahealth supports CDS Hooks across its athenaOne platform with growing maturity through 2025 and 2026. The implementation handles the main relevant hooks well. The third-party CDS service registration is less formalized than at Epic or Cerner, which has trade-offs: faster onboarding for payers but somewhat more variance in production behavior.

athenahealth's smaller-practice customer base makes provider engagement easier to coordinate but the total covered population per payer relationship is smaller.

4. Allscripts (Veradigm)

Allscripts (now Veradigm) supports CDS Hooks across the major Veradigm platforms. The implementation handles standard hook patterns; some advanced patterns and newer hooks are more recent additions. For payers with substantial Allscripts/Veradigm provider coverage, the platform is functional for Da Vinci CRD; for payers without significant existing Veradigm relationships, this is rarely a primary integration target.

5. eClinicalWorks

eClinicalWorks supports CDS Hooks with somewhat narrower scope than the leaders. The platform handles core hooks (order-sign in particular) but the broader hook set is less complete. eClinicalWorks has substantial market presence in independent and small-group provider settings, which makes it relevant for payers serving those provider networks even if the technical maturity lags Epic and Cerner.

The EHRs Below the Top 5

NextGen, MEDITECH, MEDHOST, Greenway Health, and others have varying CDS Hooks support that ranges from emerging to limited. For payers with provider networks heavily concentrated in these EHRs, the integration path is more uneven. Some plans build directly into specific NextGen or MEDITECH workflows rather than relying on generic CDS Hooks.

How to Plan Around Variable EHR Support

A useful planning pattern is to map the payer's provider network against EHR market share at the provider organizations and prioritize the EHR integrations by covered patient volume. A plan with 60 percent of its provider visits happening through Epic and Cerner can address most of the workflow value by certifying CDS services in those two platforms.

For Epic-specific integration patterns that go beyond the generic CDS Hooks layer, the Best practices for Epic integration with payer FHIR APIs covers the platform specifics. For Cerner-specific PAS integration patterns, the Top 5 patterns for Cerner CODE integration with Da Vinci PAS covers the related layer.

Sources

• CDS Hooks v2.0.1

When a payer's Patient Access API exposes member data, the consumers fall into three categories. Members using third-party apps (the original CMS-9115-F use case). Other payers receiving data under Payer-to-Payer Data Exchange. Providers' EHRs consuming the member's shared history. The EHR-side consumption is the integration most often underestimated, because Patient Access is usually discussed as a member-facing feature. Five integration patterns have emerged for EHRs consuming Patient Access in 2026. For the EHR-payer integration hub on this site, these are the practical paths.

1. Member-Initiated Pull Through SMART App Launch

The pattern that fits CMS-0057-F naturally. The member shares their Patient Access credentials or authorizes a SMART app inside the provider's EHR to pull their prior payer history. The EHR launches the SMART app, the app calls the prior payer's Patient Access API, and the data flows into the EHR's clinical view.

The pattern preserves member consent (the member initiates the share) and works with existing SMART App Launch infrastructure most major EHRs already support. The trade-off is the member friction; some members skip the share, leaving the EHR without the prior history.

2. Standing Authorization for Network Plans

A pattern that emerges in narrow-network plans where the EHR has standing authorization to query the payer's Patient Access API for any member of the plan. The pattern works when the member's enrollment in the plan implicitly authorizes the EHR-payer data exchange for clinical purposes.

The legal and consent framework for this is delicate; not all plans support it, and member-rights considerations vary by state. Where it works, the friction reduction for providers is significant.

3. EHR-Mediated Member Verification With Pull

A pattern that splits the share into two steps. The provider's EHR collects member verification (insurance card, member ID, demographic data) at intake. The EHR uses this verification to call the prior payer's Patient Access API, with member acknowledgment captured at the intake desk rather than through a separate SMART app launch.

The pattern works for providers with structured intake processes. It pushes some of the authentication complexity to the EHR's intake workflow rather than asking the member to launch a separate app.

4. Care-Coordination Pull Through Provider Access API

A pattern that uses the Provider Access API (rather than Patient Access) for the EHR-side pull. When the EHR is consuming data for a provider who is in-network with the payer, the Provider Access API is the appropriate channel and does not require per-request member consent.

The pattern fits provider organizations whose EHRs handle in-network member care. The complexity shifts to attribution: the Provider Access API requires the payer to know which members the requesting provider is attributed to.

5. Hybrid Pattern Combining Multiple Access Methods

A pattern that combines all of the above into one cohesive EHR workflow. Member-initiated share covers easy cases. Standing authorization covers narrow-network in-plan situations. Provider Access covers attribution-aware in-network cases. The EHR's data layer normalizes data from all sources into the clinical view.

This hybrid is operationally complex but provides the most complete data picture. Larger EHR deployments and integrated health systems with substantial payer-provider relationships tend toward this pattern.

How to Pick the Pattern for Your Provider Network

The pattern choice depends on the provider's relationship with the payer, the EHR's technical capability, and the member-experience priorities. Provider organizations with narrow-network relationships and integrated payer infrastructure use Patterns 2 and 4. Provider organizations with diverse payer relationships use Pattern 1 (Member-Initiated). Highly integrated health systems use the hybrid.

The patterns are not mutually exclusive. A typical health system uses Pattern 1 for out-of-network member care, Pattern 4 for in-network attributed members, and falls back to Pattern 3 for ambiguous cases.

For the synchronous notification side of EHR-payer interaction that complements these pull patterns, the CDS Hooks vs FHIR Subscriptions comparison covers the notification layer. For Epic-specific integration patterns within these flows, the Best practices for Epic integration with payer FHIR APIs covers the platform-specific guidance.

Sources

• SMART App Launch v2.2.0