Payer-to-Payer API Requirements: Consent, Cadence, and the Data You Owe at Enrollment

Of CMS-0057-F's four mandated APIs, the Payer-to-Payer API is the one where your counterparty is a competitor, your trigger is an enrollment event, and your data obligation runs both directions. The Patient Access and Provider Access APIs are read paths you control end to end; payer-to-payer is a bilateral protocol between organizations that have never exchanged a byte and have no commercial reason to make it pleasant. That makes the specification details — what data, on whose consent, on what clock — worth reading more literally than usual. Compliance for the API provisions lands January 1, 2027 (with program-specific framing: rating periods for Medicaid managed care, plan years for QHPs), which puts serious build-and-test work in 2026.

The data you owe: three buckets, two exclusions

Per the CMS-0057-F fact sheet and CMS's payer-to-payer workflow document, an impacted payer responding to a request must make available:

• Claims and encounter data — adjudicated claims and encounters, explicitly excluding provider remittances and enrollee cost-sharing information. This is the notable asymmetry with the Patient Access API, which does include cost-sharing: the member is entitled to see what they paid; their next insurer is not.
• USCDI data — all data classes and elements in the adopted version of the United States Core Data for Interoperability (the content standard at 45 CFR 170.213). This is the clinical payload: problems, medications, allergies, results, notes categories.
• Prior authorization information — with two carve-outs verified in the fact sheet and CMS's FAQ: drug PAs are excluded (as they are from the rule's PA provisions generally), and denied prior authorizations are excluded. Only PAs that were approved (in whatever active or historical state) travel to the new payer. CMS's FAQ table makes the contrast explicit: Patient Access and Provider Access APIs include denied PAs; payer-to-payer does not. The same FAQ notes that documentation a provider submitted to support a PA request is in scope for the payer-to-payer exchange.

The denied-PA exclusion is worth pausing on, because engineers keep being surprised by it. The exchange exists for care continuity — the new payer should be able to honor or gracefully transition an active authorization rather than making the member re-run the gauntlet. A denial carries no authorization to continue, and shipping it to the new payer would mostly export prejudice. Your extract logic therefore needs PA status as a filter, which means your canonical auth record needs a status model clean enough to filter on. A PA that was denied, appealed, and overturned is an approval; make sure your data layer agrees.

Lookback is five years. Payers are required to share data with a date of service within five years of the request — a deliberate compromise in the final rule between the entire record and recency. Practically: your archival tier is now part of your API surface. Claims from four and a half years ago that live in a warehouse export with a 48-hour retrieval SLA are a compliance problem wearing a storage-cost disguise.

Consent: opt-in, and the enrollment moment

Unlike the Provider Access API, which runs on an opt-out basis, the payer-to-payer exchange requires the patient to affirmatively opt in. Impacted payers must provide plain-language educational resources explaining what the exchange does and how to grant or manage permission.

That flips the engineering problem from "build the pipe" to "get the consent signal into the pipe's control plane." Design consequences:

• Consent capture belongs in enrollment, not in a portal afterthought. The natural moment to ask is when the member joins and names their previous payer. A consent flow buried three screens deep in a member portal will produce opt-in rates that make the API a well-tested no-op.
• Consent is per-member state that gates outbound requests. The request to the previous payer is only permitted once the member has opted in, so the consent flag, its timestamp, and its provenance (enrollment form, portal, phone) need to live somewhere the integration layer can evaluate — and audit — per request.
• Previous-payer identification is a data-quality problem you own. The workflow assumes the new payer learns who the previous payer was, typically from the member at enrollment. If the member reports multiple previous payers, CMS's workflow document says the payer must request data from all of the patient's previous payers within the five-year window — not just the most recent one.

Cadence: the one-week clock and the quarterly refresh

Two timing rules shape the architecture. First, per the final rule, the new payer must request the member's data from the previous payer no later than one week from the start of coverage (or at the patient's request) — CMS's workflow document frames the trigger as one week from having sufficient identifying information with the opt-in in hand. Either way, this is an event-driven obligation hanging off your enrollment feed: an 834-driven batch process that reconciles monthly will structurally miss it.

Second, concurrent coverage is a subscription, not a one-shot. When the member holds two or more impacted payers at once — dual-eligibles being the canonical case — the payers must exchange the member's data at least quarterly for the duration of the overlap. That means your system needs to know that a concurrency relationship exists, schedule recurring pulls per member-payer pair, and handle the refresh diff (new claims since last exchange, changed PA statuses) rather than re-ingesting five years each quarter. CMS's FAQ lists the FHIR Bulk Data Access IG among the standards for this API, which tells you the expected shape: bulk, asynchronous, batch-oriented — not a chatty per-resource REST conversation.

Ingestion is the half nobody budgets

The rule doesn't stop at making data available: the requesting payer must integrate the data it receives into the member's record. Receiving five years of another organization's claims, USCDI resources, and PA history means reconciling foreign identifiers, foreign code-system habits, and a foreign payer's idea of what a "complete" resource looks like — with the Da Vinci Payer Data Exchange IG recommended but not mandated, so counterparty variance is a given. Triage the effort by use case: the inbound PA data is what your UM team can act on immediately (honoring an active authorization instead of re-adjudicating it), so land that first with member match confidence scoring, and treat full clinical-record merge as the longer program. Scope varies by line of business — check the requirements for your programs against Medicare Advantage and Medicaid managed care specifics, and note the QHP framing differs again.

What to build in 2026

A minimal sequenced plan for an engineering team starting now: get the consent capture and previous-payer fields into enrollment flows first, because backfilling consent is a campaign, not a migration. Stand up the five-year extract (claims minus cost-sharing, USCDI, non-denied non-drug PAs) against your own data and measure how long a full member pull actually takes. Build the enrollment-event listener with the one-week timer and a dead-letter queue you actually monitor — the failure mode is a member whose previous payer never answered, and the rule made you the party responsible for asking. Then find a trading partner to test against; a bilateral protocol tested only against yourself is a hypothesis.

Verify data-scope, consent, and timing details against the CMS-0057-F rule text (89 FR 8758), CMS's Payer-to-Payer API workflow document, and the current CMS interoperability FAQs — program-specific compliance framing differs for Medicaid managed care and QHP issuers.