Payer-to-Payer Data Exchange in Delegated Risk Arrangements [A Technical Guide]

Most healthcare CTOs think payer-to-payer data exchange only matters when members switch insurance plans. However, the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) fundamentally expands this scope. 

‍

Released in January 2024, the rule requires payers to implement FHIR-based APIs for expanded data exchange, including a Payer to Payer API that applies to delegated entities. With patient consent, payers must share up to five years of clinical and claims data even when members are managed by a delegated risk partner rather than switching plans.

‍

CMS-0057-F Redefines Payer-to-Payer Data Exchange

‍

Traditional Member Switching vs. Expanded CMS-0057-F Mandate

‍

CMS-0057-F creates new technical mandates when payers delegate risk to other entities. In delegated risk arrangements, a health plan (Plan A) contracts a separate organization (Entity B) to manage members under a capitated or value-based agreement. Under the new rule, Plan A remains responsible for ensuring seamless data flow and patient access, even though Entity B handles day-to-day care and claims.

‍

Delegated entities must be treated as integrated co-payers for data exchange purposes. The rule's Patient Access API, Provider Access API, and Payer-to-Payer API provisions compel the primary payer to incorporate data from delegates as if it were its own. This means payer CTOs must design architecture connecting Plan A's systems with Entity B's systems in real time.

‍

Real-World Scenario: Medicare Advantage Plans and Delegated Risk Entities

‍

Medicare Advantage plans that delegate to partners like P3 Health Partners, which manages approximately 115,000 to 120,000 Medicare Advantage members under full-risk contracts, illustrate the complexity. Under CMS-0057-F, if Plan A delegates members to P3, Plan A must enable the same interoperable data access for those members' information as it would if it held the data internally. Data historically in silos must be accessible as part of the plan's API ecosystem, effectively blurring the boundary between payers even when members haven't formally changed plans.

‍

Technical Implications of Expanded Interoperability Scope

‍

CMS-0057-F’s expanded mandate compels CTOs to implement cross-organizational FHIR APIs, shared authentication frameworks (OAuth 2.0 and SMART on FHIR), and standardized data transformation pipelines. 

‍

Delegated risk-bearing entities must expose their clinical and administrative data through secure endpoints while adhering to the primary payer’s compliance posture. This new interoperability layer demands real-time monitoring, audit logging, and data provenance tracking to satisfy CMS audit readiness.

‍

The Delegated Risk-Bearing Entity Model: Technical Complexity

‍

Architecture Challenge: Primary Plan to Delegated Entity to CMS

‍

In delegated arrangements, Plan A to Delegated Entity B to CMS forms a three-tier chain of accountability. CMS maintains the ultimate source of truth for Medicare beneficiary enrollment and payment. The Medicare Advantage plan holds the contract with CMS. The delegated entity manages day-to-day operations.

‍

Data must flow bidirectionally at each level. Eligibility flows from CMS to the MA plan to the delegated entity. Claims and encounter data flow upward from the delegated entity to the MA plan to CMS. Each handoff point creates potential for data discrepancies, latency issues, and compliance gaps. Often, the delegate operates its own IT systems, meaning critical patient data resides in Entity B's databases rather than Plan A's core system, yet Plan A cannot relinquish regulatory ownership.

‍

Data Sovereignty in Delegated Arrangements

‍

When risk is delegated, the location of data storage often differs from the location of regulatory accountability. Plan A remains the accountable entity to CMS, yet the data physically resides in Entity B’s systems. This distributed model requires federated identity management, consistent FHIR resource mapping, and shared consent tracking across organizations.

‍

Eligibility as Source of Truth Across Delegated Relationships

‍

Eligibility data determines whether a member is covered, which provider they're attributed to, and what benefits they're entitled to. The primary payer typically maintains the master eligibility file, receiving updates from CMS regularly. However, the delegated entity needs near real-time access to make care management decisions, process claims, and manage provider attribution.

‍

Traditional batch-oriented approaches (monthly roster updates) create problems for real-time interoperability. If a member's status changes mid-cycle, lag before the delegate's list updates can lead to managing patients who are technically disenrolled or missing newly assigned members. Mismatches create cascading problems, including denied claims, misdirected care management, and incorrect quality metric attribution.

‍

Claims Processing Complexity in Capitated and Shared-Risk Models

‍

In full-risk delegation, Entity B processes and pays claims using a capitated budget, then submits encounter data back to the plan. It's common to see 60 to 90-day delays between service date and when the plan receives encounter information, with many state programs requiring encounter data submission within 30 or 45 days of claim adjudication.

‍

For up to two months, Plan A's system could be unaware of claims paid by Entity B. If a patient uses a Patient Access API to view claims, recent services might be missing. Organizations should implement incremental encounter data submissions, sending immediate encounters within a week of processing rather than waiting for monthly batches.

‍

CMS-0057-F Compliance Architecture for Delegated Arrangements

‍

Patient Access API Obligations When Risk Is Delegated

‍

Payers must make patient data available via a secure API, including claims, encounter data, clinical data specified by USCDI v1, and prior authorization information. In delegated arrangements, Plan A's Patient Access API cannot omit data held by Entity B. If the delegate paid claims or gathered clinical data, it must be included.

‍

The plan needs mechanisms to pull or receive data from the delegate's systems. Some plans build a unified data lake where both entities feed all member data. Others implement real-time call-outs where the plan's system dynamically queries the delegate's API. Modern cloud architectures use streaming approaches (FHIR subscriptions) where the delegate publishes claim finalized events that the plan's system subscribes to and uses to update the central FHIR store.

‍

Provider Directory API Compliance in Multi-Entity Scenarios

‍

Under delegated arrangements, network management is divided. The delegate often maintains its own provider network data, but the plan must present an aggregate provider directory. The plan's directory API must include the delegate's providers and locations, requiring data synchronization processes.

‍

If a physician joins or leaves the delegate's network, the delegate should supply that update to Plan A within a tight timeframe so the directory API can be updated within the mandated 30 days. Better strategies include real-time APIs or portals where delegates can directly update provider directory entries rather than periodic bulk uploads that lead to errors and delays.

‍

Prior Authorization API Requirements and Delegated Decision-Making

‍

CMS-0057-F requires payers to implement a Prior Authorization API with decision timeframes of 72 hours for urgent requests and 7 calendar days for standard requests. This API requirement becomes enforceable on November 27, 2026.

‍

In delegated risk arrangements, utilization management is often delegated, with Entity B handling all prior auth reviews. Yet CMS holds Plan A accountable for the PA process and timelines.

‍

Plan A's Prior Authorization API can serve as a front-end where providers submit PA requests, with the system routing requests to the delegate for review. Because timeframes are now enforceable, handoffs between plan and delegate must be extremely efficient, potentially requiring escalation protocols where plans auto-approve if delegates don't respond in time.

‍

Technical Data Flow Patterns in Delegated Payer Exchange

‍

Eligibility synchronization in delegated scenarios (real-time vs. batch)

‍

When Medicare Advantage Plan A delegates risk to Entity B, eligibility becomes a shared responsibility with competing technical requirements. Real-time synchronization ensures both organizations maintain identical member attribution data as changes occur, but introduces architectural complexity around API latency, system availability, and transaction rollback procedures. Consider a scenario where a member switches PCPs mid-month and the primary payer updates attribution in their system. If the delegated entity's API is temporarily unavailable, you create a data inconsistency window where:

‍

• Claims could route to the wrong provider
• Prior authorization requests fail due to attribution mismatches
• Revenue allocation becomes disputed between organizations

‍

Batch processing offers simpler implementation with predictable data transfer windows, typically daily or weekly eligibility file exchanges. However, batch approaches create systematic lag periods where the delegated entity operates on stale attribution data. This becomes problematic when CMS-0057-F requires real-time prior authorization decisions or when claims arrive during the sync gap. The delegated entity might approve a prior auth for a member who's no longer eligible, or reject coverage for a newly enrolled member whose eligibility hasn't been processed yet. Smart implementations often combine both approaches by using:

‍

• Real-time sync for critical eligibility changes (enrollments, terminations, PCP switches)
• Batch reconciliation processes to catch and correct any missed transactions or system errors

‍

Claims Lag Management: 60–90 Day Delays Across Delegated Boundaries

‍

Claims lag is the delay between when a service occurs and when the claim is finalized. It creates blind spots in RAF and STARS reporting. In delegated setups, lags often compound because Entity B batches claims for transmission to Plan A, which then reprocesses them before CMS submission. A typical 60–90 day delay can distort IBNR (incurred but not reported) estimates and risk adjustment projections.

‍

Plans can mitigate lag by adopting streaming ingestion or near real-time claim feeds using cloud messaging protocols (e.g., Kafka or AWS Kinesis). Delegates can publish “claim finalized” events that feed Plan A’s FHIR store immediately. Combined with automated reconciliation windows, where both systems cross-verify totals weekly, this approach minimizes downstream discrepancies and strengthens CMS audit readiness.

‍

HCC Risk Adjustment Flows from Primary Payer to CMS Submission

‍

Risk adjustment data flows are critical for Medicare Advantage revenue. The delegated entity captures diagnosis codes through provider visits and chart reviews. Those codes must flow to the primary payer, which aggregates them and submits to CMS for RAF calculation.

‍

The technical flow starts with claims or encounter data, including ICD-10 diagnosis codes. The delegated entity's systems map codes to HCC categories. The primary payer receives this data and performs its own HCC mapping and validation. When CMS returns MAO004 files indicating which diagnosis codes were accepted, this information must flow back to the delegated entity, allowing care management teams to focus on recapturing rejected or missing codes.

‍

Quality Measure (STARS) Data Aggregation in Delegated Arrangements

‍

STARS ratings directly impact Medicare Advantage plan revenue and market competitiveness. In delegated arrangements, quality measure data must be aggregated across both organizations. The delegated entity typically has the most granular view of quality metrics (which members received preventive screenings, medication adherence, post-discharge follow-ups). This data must be reported to the primary payer for inclusion in STARS submissions. Both organizations must reconcile their data to ensure accurate measure calculation and avoid gaps.

‍

API Implementation Strategy for CMS-0057-F Compliance

‍

FHIR R4 is the mandated standard for CMS-0057-F APIs. Patient Access, Provider Directory, and Prior Authorization APIs must support FHIR R4 resources and interactions. 

‍

Key resources include:

• Patient (member demographics)
• Coverage (eligibility and benefits)
• Explanation of Benefit (claims and encounters)
• Practitioner and PractitionerRole (provider directory) 
• Claim (prior authorization requests)

‍

In delegated scenarios, FHIR resource extensions may be needed to capture information specific to risk-bearing arrangements. Aggregation is simpler to implement and more performant than federation. Many CTOs build a centralized data repository for all enrollee data, fed by delegates and the plan's systems. Modern cloud architectures use streaming approaches where delegates publish events that the plan's system subscribes to and uses to update the central FHIR store, enabling near real-time data synchronization.

‍

Critical Integration Challenges in Delegated Models

‍

Enterprise Master Patient Index 

‍

An Enterprise Master Patient Index (EMPI) becomes exponentially more complex in delegated scenarios:

• Requiring a unified patient identity across the primary payer, 
• Delegated entity,
• HIE systems, and
• Multiple provider EHRs.

‍

According to industry studies, up to 8% to 14% of health records have patient identity errors. Without diligence, delegated models propagate those errors. If the same member is treated as two different people, their clinical data fragments and risk adjustment submissions become incomplete.

‍

NPI-TIN matching is equally critical. Every provider has a National Provider Identifier (individual clinicians have NPI-1 numbers, organizations have NPI-2 numbers). These NPIs must be matched to Tax Identification Numbers to establish organizational affiliations. 

‍

In delegated arrangements, providers may have relationships with multiple organizations, each with different TINs. The technical challenge is maintaining current mappings as provider affiliations change. When a provider leaves one organization and joins another, the NPI-TIN relationship must be updated across all systems.

‍

Data Reconciliation and Attribution Management

‍

Mismatched identifiers often create data reconciliation gaps between primary payer and delegate systems, causing missing or duplicate encounters. These errors disrupt financial accuracy and delay CMS submissions. 

‍

Equally critical is accurate member-provider attribution: when members are assigned to the wrong provider, delegated entities report incomplete or misaligned risk data. This misattribution directly affects RAF scoring and can expose both the payer and delegate to audit findings.

Security and Compliance in Multi-Entity Data Exchange

‍

Under HIPAA, Plan A shares Protected Health Information with Entity B for treatment, payment, and operations purposes. Since Entity B performs functions on behalf of the plan, it's typically a Business Associate requiring a Business Associate Agreement. The BAA should also define how audit logs are maintained and accessed across entities to meet CMS-0057-F traceability requirements. HIPAA's Breach Notification Rule requires notification without unreasonable delay and no later than 60 days from discovery.

‍

When two separate organizations share data, they adopt a zero-trust approach, assuming no implicit trust. Every interaction is authenticated, authorized, and encrypted. If the delegate's system calls Plan A's FHIR API, that API should require strong authentication (mutual TLS or signed JWT tokens).

‍

Data in transit must use end-to-end encryption, and all access events should be captured in immutable audit logs for compliance review. Plans should implement continuous monitoring and anomaly detection to flag irregular API calls or access behavior across both infrastructures.

‍

Technology Architecture for Delegated Payer Exchange

‍

Cloud platform strategies for multi-entity data sharing

‍

Delegated payer arrangements require cloud architectures that balance data sovereignty with operational efficiency across organizational boundaries. The primary challenge lies in maintaining secure, compliant data sharing while preserving each entity's ability to control access, audit trails, and data residency requirements. Multi-tenant cloud platforms often fall short because they can't accommodate the complex permission structures needed when competing organizations must share member data.

‍

Successful delegated architectures typically implement federated cloud models where each organization maintains its own cloud environment while establishing secure data bridges through:

‍

• API gateways with mutual TLS authentication and role-based access controls
• Data lakes with cross-organizational read permissions for specific datasets

‍

EDI integration (834/835/837) alongside FHIR APIs in delegated models

Traditional EDI transactions remain the backbone of payer operations, but delegated arrangements complicate the standard flow where a single organization processes 834 enrollment files, 835 remittance advice, and 837 claims submissions. When risk is delegated, these EDI streams must be split, routed, and synchronized across multiple systems while maintaining compliance with X12 standards.

‍

The integration challenge becomes more complex when CMS-0057-F FHIR API requirements layer on top of existing EDI infrastructure. Delegated entities need hybrid architectures that can:

‍

• Process traditional EDI files for claims and enrollment while exposing FHIR R4 endpoints for patient access
• Translate between EDI data formats and FHIR resources without losing transaction integrity
• Maintain separate 837 claims routing for fully capitated versus shared-risk arrangements
• Synchronize 834 enrollment changes across both EDI and FHIR patient access APIs

‍

Real-time eligibility verification across organizational boundaries

‍

Cross-organizational eligibility verification introduces latency and reliability challenges that don't exist in single-entity scenarios. When a delegated entity needs to verify member eligibility in real-time, they're dependent on the primary payer's system availability and response times. Standard 270/271 eligibility transactions become bottlenecks when they must traverse organizational firewalls, authentication layers, and potentially different cloud environments.

‍

Effective real-time verification architectures implement multiple redundancy layers including:

‍

• Cached eligibility data with configurable refresh intervals to reduce API dependency
• Circuit breaker patterns that fail gracefully when cross-organizational APIs are unavailable
• Asynchronous verification queues for non-critical eligibility checks
• Local eligibility databases that sync periodically but can operate independently during outages

‍

Performance optimization for delegated decision-making

‍

Delegated arrangements create decision-making workflows that span multiple organizations, each with different system response times and availability requirements. Prior authorization decisions that might take milliseconds within a single organization can stretch to seconds or minutes when they require cross-organizational data verification, creating unacceptable delays for provider workflows.

‍

Performance optimization in delegated scenarios requires rethinking traditional synchronous decision patterns. High-performing delegated architectures typically implement:

‍

• Pre-computed decision trees based on common authorization scenarios to minimize real-time lookups
• Distributed caching strategies that replicate frequently accessed data across organizational boundaries
• Asynchronous decision workflows with callback mechanisms for complex cases requiring multi-entity input
• SLA monitoring and automatic failover procedures when cross-organizational response times exceed acceptable thresholds

‍

Implementation Roadmap for CMS-0057-F Delegated Compliance

‍

Achieving compliance in delegated arrangements requires a clear, phased rollout that addresses foundational data integrity before deploying mandated APIs.

‍

Phase 1: Data Readiness & Directory Stabilization

‍

Goal - Synchronize core data and stabilize the Provider Directory, which is an established compliance requirement.

‍

Key Activities:

• Data Readiness: Synchronize eligibility files and stabilize claims and encounter data exchanges between Plan A and all delegated entities.
• Provider Directory API: Validate NPI-TIN mappings and maintain near real-time provider updates across the plan and delegate networks. This addresses the existing CMS-0057-F mandate for public directory access.

‍

Phase 2: Patient Access & Payer Exchange

‍

Goal - Implement the FHIR APIs required to give patients (members) and other payers access to required health information.

‍

Key Activities:

• Patient Access API: Aggregate patient data from multiple systems into a unified FHIR repository that supports seamless, secure access for all members (Patient-to-Payer access).
• Payer-to-Payer Data Exchange: Implement data exchange mechanisms to facilitate the compliant transfer of member data between the current plan and other payers.

‍

Phase 3: Prior Authorization & Provider Access

Goal - Integrate the new mandates for automated prior authorization and provider data access (Provider-to-Payer).

‍

Key Activities:

• Prior Authorization API: Integrate with utilization management systems, enforce CMS-defined decision timelines, and automate the electronic routing of PA requests and decisions between providers and the delegated entities.
• Provider Access API: Implement the FHIR-based API that grants providers access to the required claims and encounter data for their attributed patients.

‍

Continuous Compliance: Across all phases, apply continuous testing, FHIR conformance validation, and real-time monitoring to detect issues early. This integrated approach ensures audit readiness, consistent data quality, and full interoperability under CMS-0057-F and CMS-0057-P.

‍

Future-Proofing Delegated Payer Data Exchange Strategy

‍

CMS-0057-F is part of a broader push towards data interoperability that will continue. Expect additional CMS rules around value-based care reporting, health equity, and patient engagement. Another area to watch is the Trusted Exchange Framework and Common Agreement (TEFCA), a nationwide network for health information exchange. Forward-thinking payer architectures should be TEFCA-ready, with data standards and exchange protocols (FHIR, open APIs) that align with national networks.

‍

As data exchange becomes richer, there's a huge opportunity to apply artificial intelligence and machine learning. Many health insurers are embracing AI, with 84% using AI/ML in some capacity, including for utilization management and prior auth. AI could auto-approve certain prior auth requests by analyzing historical approvals, with one large insurer reporting an AI tool made PA 1,400 times faster. Ensure your architecture supports running analytics across combined datasets through data lakes, where claims and clinical data can be de-identified for model training.

‍

Final Takeaways

‍

Payer-to-payer data exchange in delegated risk arrangements represents one of the most complex technical challenges in healthcare IT. CMS-0057-F has fundamentally expanded interoperability requirements beyond simple member transitions to encompass ongoing data flows between organizations that share financial risk but maintain separate operational systems.

‍

Success requires recognizing that delegated arrangements create three-tier architectures spanning CMS, primary payers, and delegated entities. Data must flow seamlessly to support eligibility management, claims processing, risk adjustment, and quality reporting. Technical implementation requires careful attention to FHIR API standards, data synchronization patterns, security controls, and compliance monitoring.

‍

Organizations that approach delegated payer data exchange strategically will gain competitive advantages. They'll form partnerships more easily, scale operations more efficiently, and adapt to future regulatory changes more quickly.

‍

Frequently Asked Questions

‍

What is the difference between traditional payer-to-payer data exchange and delegated risk arrangements under CMS-0057-F?

‍

Traditional payer-to-payer data exchange occurs when a member switches insurance plans, requiring a one-time transfer of medical records. Delegated risk arrangements involve ongoing data synchronization between a Medicare Advantage plan and a risk-bearing entity managing care for a defined member population. 

‍

Under CMS-0057-F, both organizations must maintain continuous data flows, implement FHIR APIs, and ensure compliance even though members aren't switching plans. The primary payer remains accountable to CMS for data completeness and API availability, even for data generated by the delegated entity.

‍

Who is responsible for implementing Patient Access APIs when risk is delegated to another entity?

‍

The primary payer (Medicare Advantage plan) holds ultimate responsibility for Patient Access API compliance under CMS-0057-F, even when risk is delegated. However, the delegated entity must provide its data to the primary payer for inclusion in the API. 

‍

How does the 30 to 60-day claims lag affect data synchronization in delegated payer arrangements?

‍

The typical claims lag creates significant synchronization challenges because services delivered in one month may not result in processed claims until two months later. This means both organizations temporarily have different views of member utilization, complicating financial projections, risk adjustment submissions, and API data completeness. 

‍

What are the biggest security challenges when exchanging PHI between primary payers and delegated entities?

‍

The primary security challenges include maintaining a zero-trust architecture across organizational boundaries, managing HIPAA Business Associate Agreement obligations, implementing comprehensive audit trails, and coordinating incident response when breaches occur. Every API request must be authenticated and authorized regardless of the source organization, and PHI must be encrypted in transit and at rest. Audit logs must capture all data access across both organizations to detect anomalies. When breaches occur, both entities must coordinate containment, assessment, and notification activities to meet HIPAA requirements within 60 days.

‍

How can healthcare organizations future-proof their delegated payer data exchange implementations?

‍

Future-proofing requires building flexible architectures that can adapt to evolving CMS requirements beyond CMS-0057-F, implementing multi-tenancy patterns to scale across multiple delegated relationships, and incorporating AI/ML capabilities for patient matching, anomaly detection, and predictive analytics. Organizations should monitor emerging standards like TEFCA and design systems that can integrate with multiple interoperability frameworks. 

‍

‍