The algorithmic question underneath every Member Match implementation is whether to match deterministically (exact identifier comparison), probabilistically (weighted similarity scoring), or in a combined model. CMS-0057-F does not prescribe the algorithm; the IG leaves the choice to the implementer. The choice has direct operational consequences for match rate, false positive risk, and the size of the operator-review queue. For FHIR provider data exchange guides, this is the core algorithmic decision.

What Each Approach Actually Does

Deterministic matching requires exact correspondence on specified fields. A typical deterministic rule says: match if first name, last name, date of birth, and SSN all match exactly. Some implementations relax to subsets (any 3 of 4 fields match). The output is binary: match or no match.

Probabilistic matching assigns weights to fields based on their discriminating power. Last name carries higher weight than first name, exact DOB carries higher weight than approximate, SSN carries highest weight when present. The algorithm computes a similarity score across all available fields and returns a numeric confidence. The implementation picks thresholds: above X is a match, below Y is no match, in between is uncertain.

Where Deterministic Wins

Deterministic matching wins on three dimensions. First, simplicity: the logic is auditable, deterministic across runs, and explainable to regulators. Second, false positive avoidance: a true exact match is essentially never wrong. Third, computational cost: deterministic comparison is fast and scales linearly.

For payer-to-payer transfers where data accuracy matters more than coverage breadth, deterministic-first patterns dominate. Plans with clean, complete demographic data on their members particularly benefit.

Where Probabilistic Wins

Probabilistic matching wins on coverage. It catches matches that deterministic misses: misspelled names, transposed digits in identifiers, address changes, name changes from marriage or divorce. For populations where data quality is uneven (Medicaid populations, dual-eligibles, members from heavy-immigration regions), probabilistic adds meaningful coverage.

The trade-off is the operational burden of tuning thresholds and managing the uncertain-confidence cases. Probabilistic implementations need an operator-review process for mid-confidence matches; deterministic does not.

The Real-World Match Rate Numbers

Industry data from FHIR Connectathon Member Match tests shows typical deterministic match rates of 65 to 80 percent against realistic data sets. Adding probabilistic with a 0.85 threshold typically lifts the rate to 85 to 92 percent. Lowering the threshold to 0.75 with operator review can push past 95 percent, at the cost of operator workload.

The numbers vary by population. Stable member populations with clean data perform better. High-churn populations with weak data quality perform worse. Plans should expect to tune the threshold based on their actual data, not on industry averages.

The False Positive Asymmetry

A false positive is much more expensive than a false negative. A false negative means the member's history does not transfer; the receiving payer starts from scratch and the member experience degrades. A false positive means the wrong patient's history transfers, which is a privacy incident with reporting obligations, regulatory exposure, and reputational damage.

Most production implementations tune conservatively for this reason. Accepting some false negatives to ensure essentially zero false positives is the standard pattern, even though it leaves match coverage below what probabilistic alone could achieve.

The Combined Model Most Plans Run

In practice, most production deployments in 2026 run a combined model: deterministic-first for the easy cases (which represent the majority of matches), probabilistic fallback with high confidence threshold for the hard cases, and operator review for the genuinely uncertain. The combination delivers most of the coverage of pure probabilistic with most of the safety of pure deterministic.

The configuration knobs are the deterministic field set (full match required or relaxed), the probabilistic threshold (0.85 to 0.95 typical), and the operator-review range (0.70 to 0.85 typical). Plans tune these against their actual member population rather than against vendor defaults.

For broader strategy patterns that build on top of the algorithmic choice, the Top 5 Member Match strategies for Payer-to-Payer covers the patterns. For the Consent flow that runs alongside Member Match, the Top 5 FHIR Consent patterns for Payer-to-Payer covers the parallel layer.

Sources

• Da Vinci PDex IG (Member Match section)

When a payer needs to notify an EHR of an event (PA decision rendered, member transferred, eligibility changed), two FHIR-native mechanisms apply. CDS Hooks is a workflow-triggered pattern: the EHR calls the payer service at a specific decision point, and the payer responds with information. FHIR Subscriptions is an event-driven pattern: the EHR registers interest in resource changes, and the payer pushes notifications when events happen. Both are conformant; the choice has operational consequences. This comparison lays out the trade-offs for more on payer-side workflow integration on this site.

What Each Pattern Does

CDS Hooks is a request-response pattern. The EHR initiates contact at a defined workflow trigger (order-sign, order-select, appointment-book, medication-prescribe). The payer service receives the call, processes the context, and returns a card with information. The EHR renders the card inline in the workflow. The flow is bounded by the trigger; nothing happens between triggers.

FHIR Subscriptions is a publish-subscribe pattern. The EHR or another consumer registers a Subscription with the payer's FHIR server, specifying which resource changes to be notified about. The payer pushes notifications when matching changes occur. The flow is continuous; events propagate as they happen.

Where CDS Hooks Wins

CDS Hooks wins for clinician-facing in-workflow notification. The EHR has the workflow context; the hook fires at the right moment; the response renders inside the workflow the clinician is already using. For PA pre-checks at order entry, this is the right pattern.

CDS Hooks also wins when the notification is action-driven. The clinician is making a decision; the payer's information needs to arrive at the moment of the decision. Notifications that arrive between decisions are less useful in clinician workflows.

Where FHIR Subscriptions Wins

FHIR Subscriptions wins for status-change notifications that happen outside the clinician's current workflow. A PA decision rendered by the payer's UM team three hours after submission is a status change; CDS Hooks cannot push this back because the EHR is not actively asking. Subscriptions can push.

Subscriptions also win for back-office and care-management workflows where the consumer is not the clinician at the moment of decision. A care management team monitoring a population for PA outcomes wants Subscription-style notification rather than relying on clinician-triggered hooks.

The Patterns Combine

In production, most CMS-0057-F EHR-payer integrations use both patterns together. CDS Hooks handles the initial CRD prompt at order-sign. The clinician launches DTR, completes the form, submits PAS. The PA submission creates a Task that the payer's UM system processes. When the UM system renders the decision, a FHIR Subscription fires that notifies the EHR. The EHR consumes the notification and updates the relevant view (the patient's chart, the order status, the clinician's task list).

This combined flow uses CDS Hooks for the synchronous decision support and Subscriptions for the asynchronous status update. Neither pattern alone covers the full lifecycle.

The EHR Support Asymmetry

EHR support for CDS Hooks is broader and more mature than support for FHIR Subscriptions in 2026. Epic, Cerner Oracle Health, and athenahealth all support CDS Hooks well. FHIR Subscriptions support is patchier; Epic and Cerner have working implementations but smaller EHRs may not.

This asymmetry means CDS Hooks works as a baseline integration pattern across more EHRs, while Subscriptions works only where the EHR supports it. For payers whose provider network spans many EHRs, the practical pattern is CDS Hooks for the synchronous layer and Subscriptions where possible plus polling-based fallback where it is not.

The Performance and Reliability Differences

CDS Hooks calls are synchronous, which means latency and error handling matter at the moment of the clinician's workflow. A slow or unreliable hook degrades the workflow experience. Subscriptions are asynchronous, which means latency matters less but reliable delivery matters more. A dropped Subscription notification means the consumer never knows the event happened.

Production implementations handle both: CDS Hooks with strict latency SLAs and retries on transient failures, Subscriptions with delivery guarantees and consumer-side reconciliation.

How to Read Vendor Positioning

For the CDS Hooks side of EHR support specifically, the Top 5 EHRs with strong CDS Hooks support for Da Vinci CRD covers the EHR-side landscape. For the broader Patient Access API integration patterns that may use Subscriptions for status changes, the Top 5 EHR integration patterns for Patient Access API consumers covers the related layer.

Sources

• CDS Hooks v2.0.1

TEFCA (the Trusted Exchange Framework and Common Agreement) was designed to handle clinical data exchange across the US healthcare system through Qualified Health Information Networks (QHINs). For Payer-to-Payer Data Exchange under CMS-0057-F, TEFCA offers a path that reduces the bilateral payer engineering work in exchange for participating in a shared network. Several payer-to-payer solutions in 2026 integrate with TEFCA, with varying depth. Here are the leaders. For broader context, more on payer-side workflow integration covers the surrounding architecture.

What "TEFCA-Integrated" Actually Means

A TEFCA-integrated Payer-to-Payer solution can route transfers through a QHIN rather than requiring direct bilateral connections between every pair of payers. The QHIN handles authentication, network identity, and often Member Match across the network. The receiving payer connects once to the QHIN; the QHIN routes the request to the right prior payer or payers.

The depth of integration varies. Some solutions use TEFCA for network discovery and authentication, then run the actual data transfer point-to-point. Others run the full data flow through the QHIN. The depth has trade-offs for performance, control, and operational simplicity.

1. CommonWell Health Alliance

CommonWell is one of the foundational US clinical data networks and operates as a QHIN under TEFCA. CommonWell's Payer-to-Payer support leverages the existing CommonWell membership for network identity and routes requests to participating payers. For payers already in CommonWell for clinical data exchange, the Payer-to-Payer extension is a natural fit.

2. eHealth Exchange

eHealth Exchange is another large QHIN with deep payer participation. The platform handles authentication, query routing, and member lookup across the network. For payers with existing eHealth Exchange relationships, the Payer-to-Payer pattern uses the same connections.

3. Konza

Konza is a QHIN with strong payer-side focus and growing Payer-to-Payer specific tooling. The platform is newer than CommonWell or eHealth Exchange but moving faster on CMS-0057-F-specific patterns. For payers without existing QHIN relationships, Konza is often shortlisted alongside the larger networks.

4. Onyx with TEFCA Integration

Onyx Technologies built its Payer-to-Payer solution with TEFCA integration as a first-class option. Onyx handles the FHIR ePA stack and the payer-side platform; the TEFCA layer plugs in for network connectivity. This pattern fits payers that want a single vendor relationship with TEFCA-mediated transport.

5. Particle Health (Bilateral TEFCA Bridge)

Particle Health offers a TEFCA bridge for payers that want to participate without becoming full QHIN participants directly. The pattern routes the payer's requests through Particle's QHIN connectivity rather than the payer joining the QHIN itself. Best fit for smaller payers that want TEFCA benefit without the network membership cost.

What TEFCA Integration Buys and What It Costs

TEFCA integration reduces per-relationship engineering work. Without TEFCA, each payer-to-payer relationship requires bilateral agreements, authentication setup, and operational coordination. With TEFCA, the payer connects once to the QHIN and gains access to all participating payers.

The cost comes in three dimensions. Commercial: QHIN participation has subscription costs and per-transaction or per-member fees. Operational: the QHIN sits in the data path, which adds latency and a dependency. Control: the payer cedes some operational visibility to the QHIN compared with direct bilateral connections.

For most mid-size payers in 2026, the math favors TEFCA participation for the volume of payer-to-payer transfers expected post-2027 enrollment. For very large payers with concentrated transfer volume to a few specific counterparties, direct bilateral may still be cheaper.

How to Evaluate the TEFCA Path

A useful evaluation pattern is to model three years of post-2027 transfer volume under TEFCA and under direct bilateral, including the bilateral overhead of relationships with the top 10 to 20 partner payers. The deltas often favor TEFCA at typical mid-market scale.

For the broader question of TEFCA versus direct API as the architectural choice, the TEFCA vs Direct API comparison lays out the trade-offs. For the Member Match strategies that work both inside and outside TEFCA, the Top 5 Member Match strategies covers the algorithmic layer.

Sources

• TEFCA on FHIR resources

The FHIR Bulk Data Access IG (STU 2.0.0 in the version current for 2026) is what Inferno tests against for CMS-0057-F conformance. The IG looks short, but the practical conformance bar covers more than the spec text suggests. Production implementations need to handle several patterns correctly, not just one. Here are seven best practices for Bulk Data and attribution coverage implementations targeting CMS-0057-F.

1. Use the Correct Prefer Header Pattern

The Bulk Data IG requires the client to send Prefer: respond-async on the export request. The server responds with 202 Accepted only if the request had this header. Implementations that respond with 202 without the Prefer header are technically non-conformant, even if the rest of the flow works.

The same applies to the optional Prefer: handling=strict header for error handling preferences. Implementations should respect both when present.

2. Return Conformant 202 Status With Content-Location

The 202 Accepted response must include a Content-Location header pointing to the status URL. The status URL is what the client polls for completion. Some implementations return 202 without Content-Location, expecting the client to know the status URL by convention, which is not conformant.

The status URL should be stable for the duration of the export. Clients that lose the URL cannot recover the export status; they have to start a new export.

3. Handle the Status Endpoint Correctly Across States

The status endpoint has three states: in-progress (202 with optional X-Progress header), failed (4xx or 5xx with an OperationOutcome), and completed (200 with a manifest). Implementations need to handle all three states cleanly.

Common gaps include not implementing the X-Progress header (which is optional but useful), returning generic 5xx errors instead of OperationOutcome for failures, and inconsistent handling of the completed state across different export sizes.

4. Produce Conformant Manifest at Completion

The completion response is a JSON manifest with specific required fields: transactionTime (when the export was initiated), request (the original request URL), requiresAccessToken (true if downloading the NDJSON files needs auth), output (the list of files), and error (the list of error files if any).

Implementations sometimes skip the error array, return non-ISO-8601 timestamps for transactionTime, or use non-standard structures for the output entries. These are conformance bugs that Inferno catches.

5. Output NDJSON, Not Batched JSON

The output files must be NDJSON: one FHIR resource per line, no array brackets, no commas between resources. Implementations that produce arrays of resources (batched JSON) are non-conformant even if consumers can sometimes handle the output.

For deeper coverage of this format-level requirement, the NDJSON Streaming vs Batched JSON for FHIR Bulk Exports comparison covers why the spec specifies NDJSON.

6. Handle the DELETE Operation on the Status URL

The client can DELETE the status URL to cancel an in-progress export. Implementations must support this and clean up any partial output. Implementations that ignore DELETE leak storage and continue exports that the client no longer wants.

The Inferno tests check this pattern. Implementations that pass Inferno on the happy path sometimes fail on the cancellation case.

7. Support the _outputFormat Parameter (Where Relevant)

The export request can specify _outputFormat, with the value typically being NDJSON. Implementations should accept the parameter and return appropriate Content-Type headers on the output files. Skipping the parameter handling is conformant in narrow cases but breaks for clients that rely on it.

How to Test Conformance Beyond Inferno

Inferno is the conformance suite of record for CMS-0057-F, but it does not test everything. Production-grade testing should include realistic-volume exports (100,000+ members, not just the test profiles), realistic data variety (multiple resource types, edge cases in resource content), and operational scenarios (concurrent exports, cancellation mid-export, status URL access after long delays).

For the operational monitoring that catches issues conformance testing misses, the Top 5 tools for monitoring FHIR Bulk Data export health covers the observability side. For the async export patterns that the conformance rules wrap, the Top 5 Async export patterns for FHIR Bulk Data implementations covers the operational layer.

Sources

• FHIR Bulk Data Access IG v2.0.0

Epic is the largest US EHR by patient volume and the most consequential single integration target for CMS-0057-F provider-side workflows. Payers that want Da Vinci CRD prompts to fire reliably, DTR SMART apps to launch cleanly, and PAS submissions to flow correctly have to do the Epic-specific work well. Five best practices have emerged from the production deployments running by mid-2026. For FHIR provider data exchange guides on this site, these are the field-tested patterns.

1. Start App Orchard Certification Early

Epic App Orchard certification for payer-built SMART apps and CDS services typically runs three to six months from submission to production approval. The process includes security review, FHIR conformance validation, and operational testing across Epic customer environments.

Payers that start certification in mid-2026 for a CMS-0057-F January 2027 production deadline are on a tight timeline. Payers that delay until late 2026 risk having apps that work in test but are not yet approved for Epic customer production deployment by the deadline.

The practical pattern is to submit the certification path as early as possible, even if the implementation is still maturing in parallel. Certification can run alongside development; it cannot be compressed by waiting until the implementation is finished.

2. Use the Standard Epic FHIR Scopes Rather Than Custom Extensions

Epic's FHIR implementation supports standard SMART scopes (patient.read, user.read, system.read, with resource-level variants). Payer-built apps that use the standard scopes integrate cleanly across all Epic customer environments. Apps that require custom scope extensions or vendor-specific OAuth flows often need per-customer configuration work that slows rollout.

The pattern that works is to design the payer's SMART app for standard scopes from the start. When advanced functionality requires more than standard scopes can provide, the gap should be addressed through richer FHIR resources rather than Epic-specific scope extensions.

3. Test Across Multiple Epic Customer Environments

Epic implementations vary across customer health systems. Workflow configurations, FHIR scope availability, and CDS Hook customizations differ in ways that surface during production deployment. Apps that pass the Epic sandbox can still encounter friction at specific customer environments.

The pattern that catches these issues is to test against at least three Epic customer environments before broad production rollout. Major payer customers can usually arrange testing access at their largest Epic-using provider organizations.

4. Handle Epic's CDS Hooks Card Rendering Quirks

Epic supports the standard CDS Hooks specification, but card rendering has Epic-specific characteristics. Cards appear in the BPA (Best Practice Advisory) framework. Long card text gets truncated. Inline images need explicit hosting. Action buttons trigger specific Epic workflow events.

Payer CDS services that produce cards designed generically (without Epic-specific awareness) sometimes render with truncation, missing visual elements, or actions that do not trigger the expected EHR behavior. Cards designed with Epic's rendering in mind perform better.

5. Coordinate the DTR SMART Launch Path With Epic's Workflow Triggers

DTR SMART apps launching from Epic require specific workflow triggers and context handoff. The standard pattern is for the DTR app to launch from a CDS Hooks card action, with Epic providing Patient, Encounter, and the relevant draft order as context. The DTR app uses this context for pre-population.

Payers that design DTR apps without Epic-specific launch context fall back to manual lookup, which degrades the clinician experience. Payers that design with the Epic-specific context handoff in mind produce cleaner workflows.

What Epic Customers Actually Need From Payers

A useful framing is that Epic customers (the provider organizations using Epic) want Da Vinci patterns that just work inside their existing Epic workflows. They do not want to retrain clinicians on payer-specific workflows; they want the payer integration to fit their EHR investment. Payers that design their CMS-0057-F integration to respect this preference get higher provider adoption than payers that ask Epic customers to adapt to their patterns.

For the parallel work on the Cerner Oracle Health side, the Top 5 patterns for Cerner CODE integration with Da Vinci PAS covers the Cerner-specific layer. For the broader EHR landscape comparison, the Top 5 EHRs with strong CDS Hooks support covers where each major EHR sits.

Sources

• SMART App Launch v2.2.0

The five-year history transfer is the data-heaviest part of Payer-to-Payer Data Exchange. The CMS-0057-F requirement assumes the prior payer can produce five years of clinical and claims data for a single member, package it as a clean FHIR Bundle, and deliver it within one business day of the formal request. Plans that have not invested in data integration ahead of time often discover they cannot meet this bar without significant effort. Here are best practices for the inter-payer transfer reference on this site.

1. Inventory Five Years of Data Before You Need It

The first practice is the simplest and most often skipped. Build an inventory of where five years of data actually lives for a randomly selected member. Claims data is usually in the claims platform but may have been archived. Clinical data may live in claims-attached documents, in HIE feeds, in care management systems, or in CDA documents that have not been parsed into FHIR.

Plans that do this inventory before the first transfer request discover the gaps in time to address them. Plans that wait discover gaps under deadline pressure.

2. Build the FHIR Conversion Layer as Part of CMS-9115-F Work

For payers running CMS-9115-F since 2021, the Patient Access API already required some claims-to-FHIR conversion. Plans that extended this conversion to cover the broader CARIN BB profiles, PDex profiles, and the Bulk Data export pattern have a head start on Payer-to-Payer.

Plans that built the CMS-9115-F Patient Access conversion narrowly (just enough for the API) typically need additional work to support the five-year history scope.

3. Exclude Denied PAs and Cost-Sharing Detail Explicitly

The IG specifically excludes denied PAs and cost-sharing detail from the transfer. Implementations that pull broadly and filter at the end risk leaking excluded data. Implementations that scope the query to include only the required data at retrieval time produce cleaner output and audit cleanly.

The exclusion logic is straightforward in the IG but requires deliberate implementation. Plans that treat it as a post-processing filter sometimes find edge cases where excluded data leaks.

4. Handle the One-Business-Day Window With Async Processing

The one-business-day window from request to data delivery is realistic when the export pattern is async. Implementations that try to deliver synchronously often miss the window when the history is large or the data layer is slow.

The standard pattern uses FHIR Bulk Data async export: the receiving payer requests the export, gets a job identifier, and polls or subscribes for completion. The data is delivered as NDJSON file URLs once the export completes. Most plans target completion in 4 to 12 hours, which leaves margin against the one-business-day window.

5. Sequence the Bundle by Resource Type for Consumer Efficiency

The five-year history is delivered as multiple FHIR Bundles, typically chunked by resource type or by date range. Consumer-side ingestion is much smoother when the Bundles arrive in an order that lets the receiving payer process foundational resources first (Patient, Coverage, Practitioner) before consuming the larger clinical resources (Observation, Condition, Procedure).

Implementations that sequence Bundles thoughtfully reduce consumer-side complications. Implementations that emit Bundles in arbitrary order force the consumer to handle deferred resolution and re-processing.

6. Test Against Realistic Member Profiles

A useful pre-production test is to run the full five-year history export for a synthetic member with realistic data volume (200,000 to 500,000 resources is typical for a member with chronic conditions and active care). The export time, output integrity, and consumer-side ingestion all surface issues at this scale that small test profiles miss.

How This Fits the Broader Payer-to-Payer Architecture

The five-year history transfer is the data-heaviest step in a flow that also includes Member Match, Consent, and concurrent coverage handling. The pieces have to work together cleanly; a fast history export paired with a slow Consent flow does not actually deliver the data on time.

For the concurrent coverage handling that often complicates the transfer, the Top 6 ways to handle concurrent coverage in Payer-to-Payer exchange covers the patterns. For the member-facing opt-in flow that triggers the transfer, the 5 educational material patterns for Payer-to-Payer member opt-in covers the consent side.

Sources

• Da Vinci PDex IG v2.1.0

The Documentation Templates and Rules (DTR) component of Da Vinci ePA renders the payer-specific questionnaire inside the provider EHR as a SMART app. The provider does not leave their workflow; the DTR app launches in context, runs the CQL rules to determine which questions actually need answers, collects documentation, and returns a completed Bundle ready for PAS submission. Five patterns have emerged as the production-grade approaches in 2026. For the CMS-0057-F provider toolkit on this site, these are the field-tested designs.

1. EHR-Launch With Pre-Population From Context

The most effective production pattern. The DTR app launches via SMART EHR Launch, receives Patient and Encounter context, and pre-populates the questionnaire from EHR data. The clinician sees a partly-completed form rather than a blank slate, and only completes the fields the CQL rules cannot derive automatically.

Pre-population reduces clinician time substantially. A typical PA form that would take 10 to 15 minutes to fill manually completes in 2 to 3 minutes when pre-population catches 60 to 80 percent of the data from EHR resources.

2. CQL-Driven Conditional Question Rendering

A pattern where the DTR app does not render all questions at once but instead uses CQL rules to determine which questions apply given the current answers. A "patient takes medication X" answer triggers a follow-up question; a "patient does not take medication X" answer skips the follow-up.

This pattern reduces the visible form to what actually matters for the specific PA case. The implementation complexity is in the CQL authoring; payer clinical teams need to author the conditional logic, often with FHIR-specific tooling.

3. Staged Save With Resume

A pattern where the DTR app saves partial progress and lets the clinician resume later. PA forms sometimes need data the clinician cannot answer in the moment (lab result pending, imaging review needed). The staged-save pattern lets the clinician complete what they can, hand off the rest to clinical staff, and resume later without re-entering data.

The implementation requires the DTR app to maintain state across sessions and the EHR to support relaunch with the saved context. Both are achievable but require deliberate design.

4. Inline Attachment Capture From EHR

A pattern where the DTR app needs supporting documentation (imaging report, lab values, clinical note) and can pull it directly from the EHR via the FHIR API rather than requiring the clinician to manually attach files. The clinician approves the attachment but does not have to find and upload it.

This pattern works well for PA cases where the documentation requirements are predictable. The implementation depends on the EHR exposing the supporting resources through the FHIR API; not all EHR configurations support this cleanly.

5. Two-Way Validation Before Submission

A pattern where the DTR app validates the completed Bundle against the payer's rule set before submitting to PAS. The clinician sees inline indication that the submission will pass clinical-necessity criteria before they actually submit. If the rules indicate a likely denial, the clinician can adjust documentation or escalate before formal submission.

This pattern significantly improves first-pass approval rates and reduces denial-then-appeal cycles. The trade-off is that the validation logic has to run client-side in the SMART app, which adds complexity.

How Production Teams Combine These Patterns

The teams that ship production DTR SMART apps in 2026 typically combine all five patterns. EHR Launch with pre-population is the foundation. CQL-driven conditional rendering keeps the form concise. Staged save handles real-world workflow interruptions. Inline attachment capture reduces clinician burden. Two-way validation improves approval rates.

The patterns build on each other. Implementations that skip the foundational pre-population produce DTR apps that fail clinical adoption regardless of the other features.

What to Avoid

The most common anti-patterns in DTR SMART app design are: standalone launch when EHR launch is possible (forces the clinician to leave their workflow), blank forms when pre-population is possible (wastes clinician time), all-questions-at-once when CQL conditional rendering is possible (overwhelms the clinician), and synchronous-only operation when staged save is needed (loses partial progress).

For the broader question of Standalone SMART versus EHR Launch as the architectural choice, the Standalone SMART vs EHR Launch for Da Vinci DTR comparison covers the trade-offs. For the broader catalog of EHR workflow patterns that derail Da Vinci PA adoption, the 5 EHR workflow anti-patterns that break Da Vinci PA adoption covers the failure modes.

Sources

• Da Vinci DTR IG v2.0.1

The attribution-of-record is the answer to a deceptively complex question: which provider does this member belong to for the purpose of Provider Access data sharing. CMS-0057-F leaves the attribution methodology to the payer, but the payer has to articulate the methodology and apply it consistently. The IG expects attribution exposed through the Group resource. Five attribution-of-record patterns have emerged as defensible in 2026 deployments. For broader context, Bulk Data and attribution coverage covers the surrounding architecture.

1. Member-Selected PCP Attribution

The simplest pattern. The member identified a primary care provider at enrollment (or updated their selection later), and that PCP is the attribution-of-record. The Group resource for each PCP contains the members who selected them.

This pattern works cleanly when the plan structure assumes PCP selection (most HMO plans, many Medicare Advantage plans). It does not work for plans without member-selected PCPs (most PPO plans, traditional Medicare).

2. Claims-Based Attribution With Look-Back Window

The most common pattern when PCP selection is absent. The payer analyzes member claims over a defined look-back window (typically 12 to 24 months) and identifies the provider the member sees most often or most recently for primary care. That provider becomes the attribution-of-record.

The pattern handles plans without explicit PCP selection. The trade-off is that attribution can shift over time as claims patterns change, and providers may dispute attribution when they see a member infrequently or only for specialty care.

3. Geographic Attribution as Fallback

A pattern that attributes members to providers based on geographic proximity when neither member selection nor recent claims provide a clear answer. The member's address is mapped to nearby in-network providers, and one is selected as the attribution-of-record (typically the nearest PCP).

The pattern is a last-resort fallback. Geographic attribution often produces friction because the geographically nearest provider may not be where the member actually receives care.

4. Specialty Carve-Out Attribution

A pattern that handles attribution differently for specialty care than primary care. Behavioral health, oncology, specialty pharmacy, and others may have distinct attribution: the specialty provider is attribution-of-record for the specialty-specific Provider Access requests, while the PCP is attribution-of-record for general Provider Access.

The pattern matters more for plans with carved-out specialty benefits. Implementations that hard-code single-attribution per member break when specialty carve-out arrangements exist.

5. Hierarchical Attribution With Multiple Records

A pattern that supports multiple attribution-of-record assignments per member, each scoped to a clinical context. Primary care attribution to the PCP. Behavioral health attribution to the BH provider. Specialty attribution to the relevant specialist. Provider Access requests are matched to the relevant attribution scope.

This pattern is the most operationally complete and the most implementationally complex. Plans with substantial specialty carve-outs or integrated primary plus behavioral health benefit from this pattern; plans with simpler structures may not need the complexity.

How Attribution Affects the Group Resource

Each attribution-of-record assignment maps to membership in a FHIR Group. A provider's Group resource lists the members attributed to them. Provider Access $export operations against a Group return data for those members.

The Group resource has to stay in sync with the underlying attribution data. Implementations that build Group resources statically and let them drift produce incorrect Provider Access output. Implementations that rebuild Group resources on a regular cadence (or expose attribution as a live query rather than a static resource) stay current.

For the Group resource patterns specifically, the Top 6 FHIR Group Resource patterns for provider panel management covers the implementation patterns.

The Audit Trail That Matters During Disputes

Attribution disputes happen. Providers query "why is this member in my panel" or "why is this member not in my panel." Payers need to answer with the attribution methodology, the data sources, and the timing. A defensible attribution implementation captures the audit trail at the time of each attribution decision: which methodology was applied, which data points drove the decision, and when the assignment was made.

For the comparative question of geographic versus claims-based attribution as the foundational methodology, the Geographic vs Claims-Based Attribution comparison covers the choice in depth.

Sources

• CMS-0057-F Final Rule (Provider Access attribution)

CMS-0057-F Provider Access does not require per-request member consent, but it does require member opt-out support. A member can decline to have their data shared via Provider Access at any time, and the payer must honor the opt-out for both ongoing exports and any future requests. The implementation of opt-out tracking has direct consequences for Bulk Data exports: which members appear in Group resources, what data flows in NDJSON, and what audit trail proves compliance. Five patterns have emerged for handling this in 2026. For more on health plan data movement coverage, these are the practical patterns.

1. Persistent Opt-Out Flag on Member Record

The simplest pattern. The member record includes a boolean field (or a structured Consent resource) indicating opt-out status. The flag is set when the member declines and unset if the member later opts back in. Bulk Data exports filter members based on this flag before assembling the Group membership list.

The pattern is operationally simple but coarse-grained. Opt-out applies to all Provider Access uses for the member; there is no scope or time-boundedness. For plans whose members want a simple all-or-nothing choice, this pattern works cleanly.

2. Scoped Opt-Out by Data Category

A pattern where the member can opt out of specific data categories rather than all-or-nothing. Behavioral health data opt-out separately from medical claims. Substance abuse treatment data (governed by 42 CFR Part 2) opt-out separately from general clinical data.

The pattern handles regulatory nuance more cleanly. Some data categories have stronger consent requirements than others; treating them differently in the opt-out model reflects the actual regulatory landscape rather than collapsing to one decision.

3. Provider-Scoped Opt-Out

A pattern where the member can opt out of sharing with specific providers rather than all in-network providers. The member's data continues to flow to most providers; specific providers are excluded.

The pattern fits situations where the member has a fraught relationship with a specific provider (a former provider they no longer want to interact with) but is comfortable with the broader Provider Access framework. Implementation complexity is in tracking provider-scoped opt-outs and applying them during Group assembly.

4. Time-Bounded Opt-Out With Expiration

A pattern where the opt-out has an expiration date, after which the member is auto-included again unless they renew the opt-out. The duration is typically set by plan policy (one year is common) or by regulatory rules.

The pattern fits plans whose policies treat opt-out as a renewable rather than permanent decision. The trade-off is operational: tracking expiration dates, notifying members ahead of expiration, and handling the transition cleanly.

5. Opt-Out With Audit Trail of Decisions

A pattern that wraps any of the above with a comprehensive audit trail. Each opt-out decision is recorded with timestamp, source (member portal, call center, mobile app), and the specific scope. Each export logs which members were excluded based on opt-out status.

The pattern is essential for audit defensibility. Plans that capture opt-out decisions without audit trails struggle when regulators or auditors ask "show me when this member opted out and how you applied that decision in subsequent exports."

How the Opt-Out Pattern Affects Bulk Data Performance

The opt-out filtering happens during Group assembly or during export. Two implementation strategies exist. Filter at Group assembly time, so the Group resource only contains members who have not opted out (the export sees a clean Group and runs without further filtering). Or filter at export time, so the Group contains all attributed members and the export logic excludes opted-out members.

The Group-time filtering is generally cleaner and produces faster exports. The export-time filtering is more flexible (changes to opt-out status take effect immediately rather than waiting for Group rebuild) but adds complexity to the export path.

How Opt-Out Connects to the Audit Story

Opt-out handling is one of the audit-prone areas of CMS-0057-F. Auditors and regulators may ask specifically about how opt-outs are captured, applied, and tracked over time. Plans with weak opt-out implementation surface as audit issues even if the rest of the Provider Access stack is solid.

For the attribution-of-record patterns that determine the broader Group membership opt-out applies to, the Best attribution-of-record patterns for CMS-0057-F Provider Access covers the underlying methodology. For the monitoring layer that catches opt-out enforcement issues in production, the Top 5 tools for monitoring FHIR Bulk Data export health covers the observability side.

Sources

• CMS-0057-F Final Rule (opt-out requirements)

Da Vinci PA adoption inside provider organizations depends on workflow fit. Technical conformance with CMS-0057-F is necessary but not sufficient; provider organizations that find the workflow awkward fall back to legacy PA channels (phone, fax, web portal) regardless of how technically capable the FHIR ePA stack is. Five anti-patterns consistently break adoption in 2026 deployments. For more on TEFCA and CMS interop coverage, these are the failure modes worth knowing.

1. Forcing Standalone SMART Launch When EHR Launch Is Available

The most common anti-pattern. The payer's DTR SMART app is built to launch standalone (from a payer portal link), even when the target EHR supports SMART EHR Launch cleanly. The clinician has to switch context to a separate window, authenticate, find the patient, and complete the form outside the clinical workflow.

Provider adoption of standalone DTR is consistently low. Clinicians who can submit through legacy channels in two minutes prefer those over a standalone DTR that takes five minutes plus context switching. The fix is to support EHR Launch wherever the target EHR allows.

2. Requiring Manual Data Entry for Fields Available in EHR Context

A pattern where the DTR app launches inside the EHR but does not pre-populate available fields. The clinician sees a blank questionnaire and manually re-enters patient demographics, current medications, recent diagnoses, and other data the EHR already has.

This anti-pattern wastes clinician time and undermines the entire premise of EHR-embedded PA. The fix is to wire up FHIR pre-population from the EHR context (Patient, Encounter, MedicationStatement, Condition) so the clinician sees a partially-completed form.

3. Showing All Questions Regardless of Relevance

A pattern where the DTR app displays the full questionnaire (which can be 30 or more questions) without using CQL conditional logic to hide irrelevant questions. The clinician scrolls through dozens of inapplicable questions to find the few that actually apply to the case.

This anti-pattern is especially bad on mobile-EHR clients where scrolling is more friction. The fix is to author CQL rules that drive conditional question rendering based on prior answers, the patient's current state, and the specific PA case.

4. Synchronous-Only Submission With No Save State

A pattern where the DTR app requires the clinician to complete the questionnaire in one session, with no save-and-resume capability. PA forms sometimes need supporting data (a pending lab result, an imaging review not yet completed) that the clinician cannot answer at the moment.

When the form has no save state, the clinician either has to abandon the workflow and restart later (losing all progress) or wait until everything is available and complete in one sitting (which disrupts the clinical flow). The fix is to support partial save, hand-off between clinical staff, and resume across sessions.

5. Burying the PA Decision in a Notification That Does Not Surface in Clinical Workflow

A pattern where the PA decision comes back from the payer (after the UM team reviews it) but the notification is sent to a payer-controlled portal or an email address rather than into the provider's EHR workflow. The clinician does not learn the decision until the next encounter with the patient or until staff manually check the portal.

The CMS-0057-F intent is that PA decisions integrate with the provider workflow. The fix is to use FHIR Subscriptions to notify the EHR of decision changes, with the EHR rendering the notification in a place the clinician naturally encounters (the patient chart, the order status, a task list).

How These Anti-Patterns Compound

The anti-patterns are not independent. A DTR app that uses standalone launch (Anti-Pattern 1) typically also lacks EHR context for pre-population (Anti-Pattern 2). A form without conditional logic (Anti-Pattern 3) combined with no save state (Anti-Pattern 4) produces a workflow that almost no clinician completes. Production deployments need to address the anti-patterns together rather than fixing one at a time.

For positive patterns to use instead, the Best DTR SMART app patterns for provider workflows covers the production-grade designs. For the architectural choice between standalone and EHR launch specifically, the Standalone SMART vs EHR Launch for Da Vinci DTR workflows comparison covers the trade-off.

Sources

• Da Vinci DTR IG v2.0.1