What it does
When a member enrolls in a new plan, the Payer-to-Payer API lets that new plan request up to five years of the member's claims and clinical history from every payer they were previously enrolled with, when the member asks for it.
This is the requirement most often confused with the Provider Access API. The difference is who's asking. Here it's the receiving payer, not a treating provider, and the data moves payer-to-payer, not payer-to-EHR.
Who calls it
The member's new payer, initiating a request to former payers on the member's behalf once the member opts in during enrollment.
The endpoint-discovery problem underneath P2P
CMS-0057-F requires obligated payers to respond to Payer-to-Payer requests. It stops there: the rule says nothing about how a payer's system is supposed to locate another payer's FHIR endpoint, confirm that endpoint genuinely belongs to the payer it claims to be, or establish trust before a request goes out.
A payer directory is what closes that gap: a registry mapping payer organizations to their live FHIR base URLs and the public keys needed to authenticate a request, so a P2P call can be routed and verified instead of guessed at or wired up by hand with every partner.
Because CMS didn't mandate a specific directory or designate anyone to run one, every obligated payer is solving this independently, by building a private registry, negotiating bilateral trust with each partner payer one at a time, or joining a shared registry that already lists other participants. Which path you take is a real architectural decision with its own cost and timeline tradeoffs against the compliance deadline, not a footnote.
Technical standards
| Standard | Version | Notes |
|---|---|---|
| HL7 FHIR | 4.0.1 | Base data format. |
| Da Vinci PDex | STU 2 | Same clinical/claims payload structure as Patient and Provider Access. |
| $member-match operation | Da Vinci PDex | The FHIR operation used to confirm both payers are talking about the same member before any data moves. |
| Da Vinci PDex Plan-Net | STU 1.1 | The FHIR implementation guide most payer directories are built on, even though it was originally scoped for provider directories. See the Provider Directory page for that original use case. |
| JWK (RFC 7517) | n/a | Public key format typically published alongside directory entries for endpoint authentication. |
Bulk data, not a chat API
P2P exchanges are typically implemented as FHIR Bulk Data ($export) jobs, not real-time request/response calls. The data volume and multi-payer coordination don't fit a synchronous pattern.
Don't build the directory from scratch on day one
Standing up a private registry before you have a single P2P partner to route to is usually slower, and harder to defend to leadership, than joining a shared directory that already has other obligated payers in it.
Previous API
Provider Directory
A public, query-only FHIR API exposing a payer's provider network, required since 2020, that the new Provider Access API now leans on to decide who's actually in-network.
Read it →Next API
Prior Authorization API
Automating prior auth end to end, from a provider checking if it's needed to getting a decision back, on the Da Vinci CRD, DTR, and PAS standards.
Read it →Ready to see where you stand?
Every requirement on this page is one line item in our free CMS-0057-F readiness survey.