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.