CMS-0057-F build vs buy: which parts of the FHIR API program should a payer own?
Health plan IT leaders planning the CMS-0057-F APIs are offered complete platforms by interoperability vendors. Buying all of it rarely removes the hardest work, because some components depend on the payer's own systems and records. The useful question is which components to buy, which to build and how they connect.
Should a payer build or buy its CMS-0057-F FHIR APIs?
Quick answer
Most payers should split their CMS-0057-F program rather than build or buy all of it: buy the FHIR server and conformance work if a vendor already passes the implementation guides, and keep attribution, consent records and the mapping from claims and core systems in house. Agnotic Technologies builds those payer-owned parts and connects them to the vendor.
| Criterion | Build | Buy |
|---|---|---|
| FHIR server and guide conformance (commonly bought) | You run the server, profile validation and every guide upgrade | Vendor runs it; you review conformance evidence and the version roadmap |
| Identity and app registration (either) | Integrate with your member and provider identity systems | Vendor runs authorization; you connect it to your identity provider |
| Consent and opt-out records (always the payer's) | Kept with enrollment and member services | A vendor can enforce flags, but the decision record stays with you |
| Provider attribution (always the payer's) | Built from contracts, claims and member choices | Vendor receives your attribution feed; it cannot create it |
| Claims, encounter and clinical data mapping (always the payer's) | Your team maps core and claims data to the guides | Vendor tools can help, but the source knowledge is yours |
| Previous and concurrent payer identification (always the payer's) | Collected at enrollment and kept current | Vendor runs the exchange once you supply the payer list |
| Prior authorization rules (either) | Rules and documentation templates kept with your UM team | Vendor hosts the API; you load and maintain the rules |
| Metrics and reporting (either) | Built from your own logs and claims data | Vendor reports on API traffic; you add business measures |
What they are
What is Build
The payer's team, or an engineering partner working for it, builds and runs a component on the payer's own infrastructure. The payer controls the code, the data model and the release schedule, and carries the conformance testing and upgrades.
What is Buy
A vendor supplies and runs a component, typically the FHIR server, implementation guide conformance and app registration, and keeps it current as guides change. The payer feeds it data and stays responsible for compliance.
Key differences
Which work stays with the payer whatever it buys?
Attribution, consent and data mapping. For Medicare Advantage, 42 CFR 422.121(a)(3) requires the MA organization to establish and maintain a process to associate enrollees with their in-network providers for the Provider Access API, and 42 CFR 431.61 sets parallel duties for state Medicaid programs. That process runs on contracts, claims and member choices the vendor does not hold, so it stays yours even when the API is bought.
Why are consent records a payer system, not a vendor feature?
Because the rules tie them to enrollment. 42 CFR 422.121(a)(4) requires a process that lets an enrollee opt out of Provider Access data exchange and change that choice at any time, and for Medicaid, 42 CFR 431.61(b)(2) requires the Payer-to-Payer opt-in to be offered to new beneficiaries no later than one week after enrollment. Keep the record of each choice with member data and send the vendor only the resulting flag.
What happens when implementation guide versions change?
45 CFR 170.215 adopts HL7 FHIR Release 4.0.1 as the API base standard and lists US Core versions, noting that adoption of US Core STU 3.1.1 expired on January 1, 2026. The Da Vinci PDex guide, now version 2.2.0, notes that CMS guidance recommends, but does not require, the implementation guides it links to. Versions move, so a contract must say which versions the vendor supports and how upgrades are scheduled.
What does a hybrid layout look like?
A bought FHIR server and authorization service at the edge; payer-built services behind it for attribution, consent, payer identification and data mapping from claims and core systems; and one integration layer that feeds the vendor and receives its logs. Each payer-built service can then serve a second vendor if you switch.
Where does prior authorization fit in the split?
Prior authorization is its own build with its own rules and Da Vinci guides; our AI prior authorization page covers that decision. In the overall program, treat it as an either component: the API can be bought, but the rules and documentation templates stay with your utilization management team.
When to use each
When to use Build (payer-owned components)
- The component depends on payer data no vendor holds, such as attribution or consent decisions.
- Your claims and core systems need custom mapping that a vendor would charge to maintain.
- You already run a FHIR platform for the Patient Access API and can extend it.
- You want the option to change vendors without moving payer records.
When to use Buy (interoperability vendor)
- The component is the same for every payer, such as a conformant FHIR server.
- The vendor can show conformance evidence for the guides and versions you need.
- Your team is small and implementation guide upgrades would stall other work.
- The contract lets you export your data and configuration if you leave.
Which questions belong in a CMS-0057-F vendor contract?
1. Which implementation guide versions do you support today, and how much notice do you give before upgrading?
2. What conformance evidence can you share: test reports, the test tools used and the exact guide versions tested?
3. How do our attribution and consent feeds reach you, how fast are changes applied, and what happens to a request during a delay?
4. Can we export all data, configuration, app registrations and logs in a standard format, at any time and at exit?
5. Which access and audit logs do we receive, and how long are they kept?
6. Who handles a member's or provider's complaint about data shared through the API, and how is it escalated to us?
7. Which parts of the work do subcontractors perform, and are they covered by the BAA?
Which sources does this comparison rely on?
- 42 CFR 422.121: Provider Access and Payer-to-Payer APIs for MA organizations (eCFR)
- 42 CFR 431.61: Provider Access and Payer-to-Payer APIs for state Medicaid programs (eCFR)
- 45 CFR 170.215: application programming interface standards (eCFR)
- Da Vinci Payer Data Exchange (PDex) implementation guide, version 2.2.0 (HL7)