Wireframe preview

Best viewed on desktop.

This is a wireframe for review, not the finished site. The responsive (mobile) treatment comes in the design and build phase. Open this page on a screen at least 1200 px wide to see the layout as intended.

Payer-to-Payer Interoperability

CMS-0057-F (the CMS Interoperability and Prior Authorization Final Rule) requires impacted payers to exchange member clinical and administrative data at enrollment, with member opt-in.

Three Problems the API Does Not Solve

Discovery: how does the receiving payer know which prior payer to ask, and how does it reach them? Authentication: how do two payers who have never transacted establish trust? Matching: how do they agree the member is the same person, given different identifiers and imperfect demographics?

None of these is solved by building an endpoint. All three must be solved before an endpoint is useful.

Consent and the Intermediary

Opt-In Is a Workflow

The exchange is conditioned on member opt-in. That means capturing consent, retaining evidence of it, honoring its scope, and handling withdrawal, at enrollment, at scale, across a population that has no idea this is happening. Programs that scope opt-in as a UI element discover the operational shape of it later.

Where an Intermediary Helps

The value an intermediary adds here is discovery, identity, and provenance, more than transport: knowing who to ask, establishing that both parties are who they claim, and producing a durable record of what was exchanged under what consent. PNT supports FHIR-based exchange with provenance recorded at both ends and no PHI retained in transit. Specific payer readiness is maintained per payer.

Frequently Asked Questions

What is CMS-0057-F payer-to-payer exchange?

A requirement that impacted payers exchange a member's clinical and administrative data when the member changes plans, conditioned on member opt-in, via a FHIR API. Compliance dates begin January 1, 2027.

Why is payer-to-payer the hardest CMS-0057-F requirement?

Because it requires two organizations with no commercial relationship to find each other, authenticate each other, and match a member across systems using different identifiers, none of which the API solves. Building the endpoint is the easy part. Discovery, trust, and identity matching depend on parties outside your control.

Is member opt-in just a consent checkbox?

No. It requires capturing consent, retaining evidence of it, honoring its scope, and handling withdrawal, at enrollment and at population scale. Programs that scope it as a UI element find the operational shape of it in production.

Ready to talk through your use case?

Talk to a Post-n-Track specialist about your data challenges. A direct conversation, starting with what you need.