The gate on the Payer-to-Payer API
When a member leaves one plan for another, the Payer-to-Payer API is how their history follows them. The new plan asks the old one for up to five years of claims, clinical data and prior authorizations. Nothing moves until the member says yes. That permission is the entire gate, and no API collects it for you. This article is about that gate, and it is written for Medicare Advantage; for the rest of the rule, start with our CMS-0057-F overview.
Right now the calendar matters more than the engineering. Medicare Annual Enrollment for 2027 runs October 15 through December 7, 2026, a window fixed in regulation. Coverage for everyone who signs up begins January 1, 2027, the day the Payer-to-Payer duty takes effect under 42 CFR 422.121. By then every existing member is owed the chance to opt in, and everyone who joined during Annual Enrollment is owed the same offer within a week of coverage starting.
Both offers are discharged by talking to the member. The conversation has to come back with a specific set of elements, among them who the previous insurer was, under whose name that coverage sat, and the permission itself. Collecting it is what this article calls capture. A plan that reaches January without a way to do it has converted the work into a backfill campaign across the whole membership. That campaign runs in the same weeks as the API go-live.
What the rule requires
For Medicare Advantage the duties sit in the Payer-to-Payer half of 42 CFR 422.121. Medicaid, CHIP and the QHP issuers on the federally facilitated exchanges each get their own version of the same section. Medicaid and CHIP differ in three ways worth knowing. There the State collects the opt-in rather than the plan. An exchange between a State and its own contracted plans needs no opt-in at all. And managed care plans pick the duty up through their State contract rather than directly from CMS.
For a Medicare Advantage plan the duty runs like this. Offer the opt-in and a way to change it, and start identifying the member's previous and concurrent payers, both no later than a week after coverage starts. Make reasonable efforts when the member does not respond. Then, once you hold the permission and enough identifying information, send the data request within a week, attesting that the member is enrolled and has opted in. Repeat it to concurrent payers quarterly while the member is in both plans. Explain all of it in plain language when you ask, once a year after, and in an accessible place on your public website. What you request is the Patient Access data set from the last five years, minus provider remittances, member cost sharing and denied prior authorizations, plus the unstructured documentation attached to prior authorizations.
Three points are easy to read the wrong way.
The first week runs on asking, not on getting an answer. The deadline is to put the question to the member, not to have their answer in hand. CMS proposed "at enrollment" and finalized "start of coverage" because, as it put it, payers might not have contact with patients before enrollment. The preamble to the final rule adds that collection "may take longer than the enrollment process". So measure the share of new members you asked inside seven days, not the share who answered. The first is your process, the second is member behavior. A dashboard built on the second reads red every month while telling you nothing.
The second week is the one that can fail quietly. It does not start until you hold both the opt-in and enough information to identify the other payer, and from there the request has a week to go out. That is latency inside your own queue, the only deadline here your systems can miss with no person involved, and it deserves a monitor.
The rule does not tell you where to ask. CMS declined to prescribe a process and pointed instead at "an already established point of contact with the patient". So the opt-in does not have to sit on the enrollment application. For Medicare Advantage the deadline does not assume it will, since the clock runs from the start of coverage rather than from enrollment. The welcome call, the ID card mailing, the first portal login and a service script are all available to you. Pick the touchpoint you own and can instrument.
Where FHIR starts, and where it does not
CMS did not write a technical standard for this. The rule requires FHIR R4, US Core and the FHIR Bulk Data specification, by pointing at the API standards ONC has adopted. It recommends the Da Vinci PDex implementation guide without requiring it. So PDex conformance is a trading-partner agreement rather than something CMS checks. What PDex adds is the shape of the exchange, and that shape is what tells you which elements you have to collect.
The requesting payer starts with $bulk-member-match and submits, per member, patient demographics, the prior coverage and the permission, on the HRex Patient Demographics, Coverage and Consent profiles. The responder evaluates each member on its own and returns three groups: matched, not matched, and consent-constrained, that last one being members it found but whose consent it cannot honor. The matched group feeds $davinci-data-export (PDex bulk exchange).
FHIR is the format of the request, not the format of the capture. Nothing in the rule or the guides requires a FHIR Questionnaire to ask the questions or a FHIR server to hold the answers. PDex makes storing the Consent record optional even for the receiver. It checks only four things to validate a request: that the member matched, that the responder can honor the scope the member chose, that the consent period is valid, and that the payer asking is the payer named in the consent. On the requesting side there is no storage requirement at all. What you owe is a conformant HRex Patient, Coverage and Consent at the moment the request goes out, and everything on the near side of that transformation is yours to design.
Connectivity is not a prerequisite either. The member reads a payer's name off a card, but the exchange needs an organization with an identifier and a live endpoint. There is no national payer identifier and no national directory to get from one to the other. CMS says payers would likely have to contact the previous payer directly to find out whether it supports the API at all. A proposed rule from April 2026 would start closing that gap, requiring payers to report their Payer-to-Payer and other API endpoints to CMS within 60 days of a final rule. The mechanism is still to be determined, so treat it as a direction of travel rather than something to plan against. Either way it is an argument for collecting elections now, because they turn into requests as endpoints appear.
Should you capture in FHIR anyway?
Not required is not the same as not worth it. FHIR-native capture can take either of two shapes. If the page the member sees is yours, it can write the Consent itself when they submit, and no form engine is involved. If you want the form to be data as well, the member-facing form is a FHIR Questionnaire, the answers land as a QuestionnaireResponse, and the Consent is derived from that. Two arguments carry both.
You need a FHIR-readable consent store on the serving side regardless. Provider Access lets you answer a provider only if the member has not opted out, and on the Payer-to-Payer responding side you validate the consent that arrives with each request. Your APIs already read a consent store on every call. Capture somewhere else and you own a synchronization job. There is also the evidence problem. HRex Consent wants source pointing at a DocumentReference, the record of what the member agreed to rather than a yes-or-no flag. A QuestionnaireResponse is already that record, timestamped and tied to the question set and its version.
A Questionnaire does not need the vendor's release slot. The case against FHIR-native is convenience: members are already in the enrollment vendor's flow, so adding two questions there must be faster. That holds only if the vendor can ship it, and adding a scope choice, a representative path and a signature to a member-facing flow is not a small change request. Ownership is what decides this. A portal you control can write the Consent on submit. A form you host can be pointed at from the welcome email, the portal, an SMS, or a link a representative reads out. A portal you do not control will do neither without the same change request. The touchpoint stays where it was either way; what changes is who can fix the wording in November.
The real argument against is migration. If you already run a consent table the business treats as the system of record, going FHIR-native means moving it. Worth separating out, because the capture channel, the form and the system of record are three decisions rather than one.
Four decisions to make before enrollment season
1. Where capture happens, and what holds the answer afterwards. The channel is where the question reaches the member: the enrollment vendor, the portal, the service desktop, or paper. The system of record is whatever your APIs read once the member has answered, and it does not have to be the same system. If permissions already sit in a table you run, that table is a system of record you inherited rather than a channel, and the channel is whatever fills it. Neither decision has to wait for the API build. Whatever you pick, add a route for members who are not on a portal. CMS "strongly recommend[s] that there be a way for patients to record their permission telephonically or otherwise". The language and disability access duties in 45 CFR part 92 apply to the form and the script.
2. What the consent period is. CMS says the election is "valid indefinitely with that payer" until the member withdraws it, but HRex Consent makes both a start date and an end date mandatory. So the end date is your policy rather than a member answer, and it has to appear on the form the member signs.
3. Which scope value the consent carries, and whether the member picks it. HRex recognizes two policy values whose names run opposite to the intuition: #sensitive grants everything including what law treats as sensitive, #regular grants everything except that. You do not have to put the choice in front of the member, because the rule asks for a yes or a no and scope is not among the things you must explain.
What you cannot skip is the decision, because the value still travels in the outgoing Consent. A form that does not ask fixes it by policy, and that is a legal question rather than a design one. Sending #sensitive asserts the member authorized disclosure of records protected under 42 CFR part 2 and state law. The rule permits the exchange only where the disclosure is not prohibited by other law. How much data actually reaches you pulls the other way. A responder without security labels cannot separate the sensitive subset, so PDex has it exclude the member rather than filter. The member who asked for less receives nothing, while the member who said everything gets a full history.
4. Which PDex version your stored records are shaped for. A single enrollment contact can collect the Payer-to-Payer opt-in and the Provider Access opt-out together, so this decision covers both records. PDex 2.2.0 adds a category coding that identifies which API each consent record belongs to, mandatory on the Provider Access consent profile, widens the signer to personal representatives and adds three search parameters. Payer-to-Payer records are unaffected by that, because they use HRex Consent and that profile is identical in both releases. For Provider Access, shape what you store to 2.2.0 rather than to 2.1: 2.2.0 is the current release, and records written to the 2.1 shape this autumn buy a migration. CMS's own recommendation still names PDex 2.0.0, so this is a bet on the guide rather than on the rule. Worth checking separately: both consent profiles reference a US Core 7.0.0 Patient, while the rule itself points at US Core 3.1.1. The version your consent records assume may not be the version the rest of your build targets.
What to ask the member
"Required" means the profile is invalid without it. "Must support" means the receiving system has to be able to process the element if you send it, which is not the same as an obligation to ask the member for it. "Recommended" marks an element CMS names in the preamble that the profile does not constrain at all.
| What to capture | Why | Where it lands |
|---|---|---|
| Legal name | required, for member matching | Patient.name.family, .given |
| Date of birth | required, for member matching | Patient.birthDate |
| Sex, and birth sex where you hold it | must support, for member matching | Patient.gender, us-core-birthsex |
| Address | must support, for member matching | Patient.address |
| Phone | recommended: CMS names it among the elements appropriate to identify a patient | Patient.telecom |
| Previous insurer, as printed on the card | required, identifies who to ask | Coverage.payor to Organization |
| Member ID from that card | must support: CMS names this as the identifier to collect | Coverage.identifier (member number), Coverage.subscriberId |
| Whether that plan was in the member's own name or a spouse's or parent's | required: the ID on a card is often the subscriber's, not the patient's | Coverage.relationship, dependent, policyHolder |
| Any other plan, current or within five years | required by the rule: you have to find every previous and concurrent payer, and re-ask concurrent ones quarterly | one Coverage per payer |
| The permission itself | required, the gate on the whole API | Consent.provision.type = permit |
| Scope: everything, or everything except what law treats as sensitive | required, the only sensitivity control the profile has | Consent.policy.uri, bound to the two HRex values |
| Who answered, and a representative's relationship and basis of authority | required: HIPAA makes you treat a representative as the member and verify their authority | Consent.performer |
| The retained record of what was signed or read out | required: the profile wants evidence, not a flag | Consent.source to DocumentReference |
| The consent period | required, but you supply it: decision 2 above | Consent.provision.period |
| Which organization discloses and which receives | required, but you supply it: your identity plus the previous payer's | Consent.provision.actor |
That is the whole of it. Every element HRex Consent requires either appears above or is fixed by the profile itself. The profile sets the status, the scope, the disclosure category, the permit, the disclose action and the two actor roles for you. The consent period, the two organization actors and the retained record come from your own configuration rather than from the member, and the signed artifact can stay wherever your documents live today. Only one non-obvious question here can be answered by nobody but the member: whether the previous coverage was in their own name.
What not to ask
Three of the four below come from the preamble. The fourth is a design choice that follows from it.
- Coverage start and end dates. CMS allows that they "may be useful in some instances", then discourages them: "patients are unlikely to know or remember those exact dates, nor are they likely easy to find." A required date field buys little matching accuracy and costs completion.
- Recent services and their dates. Discouraged as burdensome, since the member would have to get them from the payer you are about to ask.
- Social Security numbers. To be used to identify patients "only when necessary (and permissible by law)".
- The specific plan name. Commenters urged CMS not to require it: plan names are long, unintuitive, and members switch plans while staying with the same payer. CMS did not rule either way, so dropping it is a design choice. What routing needs is the payer, not the product.
What CMS does endorse is short: the patient's name, member ID, date of birth, physical address and phone number, plus the previous payer's name and a patient ID number or similar identifier.
When the member does not answer, or changes their mind
Withdrawal only works forward. It stops future requests, the quarterly exchange with concurrent payers included, but nothing asks you to delete what you already received. Left alone the election stands indefinitely with that payer and does not travel: the next plan collects its own. Nor does revocation travel on the wire, so if a member calls the previous payer directly, both sides need an operator path for a permission change learned by phone.
Reasonable efforts have a floor: CMS recommends following up once before concluding the member is choosing not to opt in, and encourages giving them a way to decline so the follow-up stops. Record the attempts and the declines, or you cannot defend either.
One conversation, two records
The Provider Access opt-out notice carries the same trigger, a week after coverage starts, which is what lets one contact carry both and turns two outreach programs into one.
The records stay separate and are shaped differently: the PDex provider consent profile leaves the end date and the source document optional, while HRex Consent requires both, plus two organization actors. The category coding in PDex 2.2.0 keeps them separable in one store. Neither flag may ever gate a Patient Access response, where the member's own app authorization is the permission event.
How Health Samurai helps
Payerbox is Health Samurai's CMS-0057-F platform for health plans, and it is live with payers today. The design principle is integrate, do not replace, and the consent capture module we are building now follows it. You keep asking members where you already reach them, and the consent table you already run stays the system of record.
See the full solution on the Payerbox page for CMS-0057-F. To work through your own capture path before enrollment season closes, book a call. We will look at where your opt-in lives today, what your form has to collect, and what it takes to turn that into a conformant request against whatever your trading partners stand up.
