Most health plans are no longer deciding whether to start on CMS-0057-F. They are deciding what to sign. And the statement of work is where a program's architecture gets fixed — the system of record, the integration pattern, the identity model, the interface owners — usually before anyone has drawn the architecture that the scope implies.
CMS-0057-F is the federal rule that requires Medicare Advantage, Medicaid, CHIP, and some exchange plans to offer FHIR APIs for patient access, provider access, payer-to-payer exchange, and prior authorization by January 1, 2027.
ContextStarted is not the same as progressing
In February 2026, WEDI surveyed 86 organizations — 52% payers, 31% vendors, 12% clearinghouses, 5% providers — on progress toward the rule. It was the third in a series, and it was published in March 2026. Two of its findings sit oddly together:
Nearly everyone has started. A large minority are barely underway. And the cost projections are moving in one direction: 28% of payer respondents put implementation between $1–5 million, and the group expecting to spend more than $5 million grew by two-thirds between surveys.
That combination — broad engagement, thin progress, rising spend, a fixed deadline — is the condition under which statements of work get signed quickly and scoped loosely. The barriers payers named in the same survey are worth reading as a checklist of what those SOWs tend to leave undefined: delegated third parties facing connection challenges, digitizing authorization policies, and insufficient funding.
This survey was fielded in February 2026 and published on 11 March 2026. WEDI runs these periodically, so check for a more recent wave before quoting these numbers as current. The figures here are WEDI's, not ours — we cite them as industry context and claim no affiliation with or endorsement by WEDI.
The ten questions
- Which of the four APIs are in scope — and which are explicitly out?
- Where does the authorization decision actually execute?
- What does “supports Da Vinci” mean, concretely?
- Who digitizes the authorization policies, and into what?
- How does this reach the core — API, database, or transaction?
- Who owns each interface when two vendors both say “not mine”?
- Whose identity system is trusted, for whom?
- What does the test evidence consist of, and against what?
- What is explicitly excluded, and what triggers a change request?
- Who is paged at 2 a.m. after go-live?
01Which of the four APIs are in scope — and which are explicitly out?
The rule names four surfaces: Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization. They are not equally hard, and a SOW priced against “CMS-0057-F” as a single noun is priced against whichever subset the vendor had in mind.
Payer-to-Payer in particular carries obligations most scopes underestimate: member matching against another plan you have no shared identifier with, consent capture and honoring, and a five-year historical window. Prior Authorization carries the decision workflow and the metrics reporting.
Names each of the four surfaces individually, states in or out for each, and says which ones are phase one versus later. Out-of-scope items are listed, not implied by omission.
“Full CMS-0057-F compliance.” Compliance is a determination about your organization, not a deliverable a vendor can hand you.
02Where does the authorization decision actually execute?
This is the single question that most changes cost, and it is frequently unanswered. When a provider submits a prior authorization through the new FHIR surface, which system decides it? Your core? A rules layer the vendor is standing up? A utilization-management vendor you already contract with?
Each answer implies a different system of record, a different reconciliation problem, and a different failure mode. If the decision executes outside the core, something must write it back — and that write-back path is where scope tends to be silently assumed.
Draws the request path end to end and names the authoritative store for authorization status. States explicitly whether the core remains system of record, and if not, how and when the core is updated.
“It integrates with your core.” Integration is a direction, not a design.
03What does “supports Da Vinci” mean, concretely?
CRD, DTR, and PAS are three different implementation guides that hand each other input, and a vendor can legitimately claim to “support Da Vinci” while implementing one of them. Ask which guides, at which versions, against which profiles — and which parts are implemented versus stubbed.
DTR is where this usually breaks down. It requires your medical policy expressed as a questionnaire the provider's system can render and, often, CQL that executes against the patient record to pre-populate answers. That is not an API integration; it is policy authoring work.
Names the guides and versions, distinguishes what is implemented from what is planned, and identifies which profiles are validated against a reference implementation.
“Da Vinci compliant.” Ask what would fail if you ran the guide's own test suite against it tomorrow.
04Who digitizes the authorization policies, and into what?
WEDI's payer respondents named this among their top barriers, and it is the line item most often missing from a SOW entirely. Someone has to turn prose medical policy into machine-readable rules — questionnaires, decision logic, code sets, the documentation requirements per service.
That work is slow, requires clinical review, and is rarely something a technology vendor can do without your medical policy team. If the SOW does not say who does it and how many policies are covered, the answer is you, at a volume nobody has counted.
States how many policies are in scope, who authors them, who reviews them clinically, what format they land in, and what happens to policy number 51 when the SOW covered 50.
Silence, or “payer to provide policy content.” That sentence can hide a year of work.
05How does this reach the core — API, database, or transaction?
There are only a few ways into a core administration platform, and they have very different consequences. A supported API is the most durable and usually the most limited. Direct database access is the fastest to build and the most fragile — it is also the pattern most likely to break on your next core upgrade, and the one your core vendor is least likely to support. A transaction interface (X12 278, for example) is well-defined but constrains what you can express.
Ask which one, per interface, and ask what happens at the next core version upgrade. A plan running QNXT, Facets, or HealthEdge should treat “we read directly from the database” as a decision with a maintenance cost attached, not a shortcut.
Specifies the pattern per interface, names the supported surface where one exists, and states the upgrade-compatibility expectation.
“We'll work with whatever access you can give us.” That defers the most expensive decision in the program to implementation.
06Who owns each interface when two vendors both say “not mine”?
This is the failure WEDI's payers described as “delegated third parties facing connection challenges,” and it is structural rather than technical. A CMS-0057-F program typically involves the core vendor, a clearinghouse, a utilization-management system, a provider portal, an identity provider, and an implementation partner. Every one of them owns a piece. None of them owns the seams.
The artifact that prevents this is unglamorous: a responsibility matrix, per interface, naming the party accountable for building it, the party accountable for operating it, and the escalation path when it fails. If no SOW in the program contains one, the seams belong to you by default.
A named owner per interface for build, run, and escalation — including the interfaces that touch parties who are not signatories to this SOW.
A RACI covering only the vendor's own deliverables. The gaps between vendors are exactly what is unmanaged.
07Whose identity system is trusted, for whom?
Three different populations authenticate against these APIs, and they are not the same problem. A member using a third-party app is a SMART on FHIR and OAuth 2.0 authorization question with app registration and consent attached. A provider organization requesting Provider Access is an attribution and organizational-identity question. Another payer requesting Payer-to-Payer is a trust question about an identity provider you do not operate.
Ask which of these the SOW covers, whose identity provider is authoritative in each case, and who performs app registration and vetting — an ongoing operational duty, not a one-time setup task.
Separates the three populations, names the IdP and the trust basis for each, and assigns ongoing app registration and review to a specific team.
“Standard OAuth.” The standard part is the easy part.
08What does the test evidence consist of, and against what?
Ask what you will be shown at the end, and what it was run against. There is a real difference between a demo, a suite of tests against synthetic data, exchanges performed against a published reference implementation, and a formal conformance result. All four are legitimate; only one of them is evidence that answers a regulator's question on its own.
Also ask what the tests do not cover. A test suite that only asserts the happy path tells you the surface exists, not that it behaves under the conditions that will actually occur.
Names the data (synthetic or real), the target (reference implementation, sandbox, your environment), the pinned version, and the scenarios explicitly not covered.
“Certified.” Ask by whom, against what, and to see the certificate — there is no CMS certification for CMS-0057-F implementations.
09What is explicitly excluded, and what triggers a change request?
The exclusions section is the most informative page of any SOW and the least read. Read it before the deliverables. Then ask the harder version of the question: what specific event turns work into a change request?
Common triggers worth pricing in advance: a policy count above the stated number, a core version upgrade during the engagement, a new trading partner, a data-quality problem in a source system, a security review finding, or a change in the plan's own requirements. Ask for the rate and the approval path now, while you have leverage.
Exclusions are specific and enumerated; change-request triggers are named with a rate and an approval path attached.
A short exclusions list and a broad “assumptions” section. Assumptions are exclusions that have not been priced yet.
10Who is paged at 2 a.m. after go-live?
January 2, 2027 is an operational date, not a project date. These APIs are externally visible: providers, members, and other payers will call them, and they will notice when they fail.
Ask where implementation support ends and operational support begins, who monitors what, whose telemetry it is, and what the boundary is between an application failure and an infrastructure failure. Ask what the plan's own team must be able to do on day one, and whether knowledge transfer is a deliverable with a date or a hope.
A stated end of implementation support, a named operational owner, monitoring the plan can see, and knowledge transfer as a dated deliverable.
“Hypercare for 30 days.” Ask what happens on day 31.
PatternWhat the good answers have in common
Every strong answer above does the same thing: it converts a category into a specific, and it names a party. “Integrates with your core” becomes “reads eligibility through the supported API, writes authorization status through X12 278, owned by us, escalating to your core vendor.” That sentence can be estimated, tested, and enforced. The category cannot.
A SOW review is not an adversarial exercise. Ambiguity is a shared liability: the vendor absorbs it as unpriced work and the plan absorbs it as change requests. Both sides do better when the scope says what it means.
DisclosureWhere we sit in this
Cloud Health Office is a payer interoperability software company, and Aurelianware offers an independent technical review of exactly the documents this article describes. So read this with that in mind.
Two things follow from it that are worth stating plainly. First, every question above is one you can ask yourself, or hand to your own architect — that is why they are written as questions rather than as findings. Second, a review that always concluded “you need our software” would be worth nothing; the useful outcome is frequently that an incumbent vendor's proposal is sound, or that the gap is in the plan's own assumptions rather than the vendor's.
We do not claim certification by, affiliation with, or an implementation partnership with any core administration vendor, and nothing here should be read as a criticism of any of them. We also make no claim of savings — the value of asking these questions early is a scope both parties can hold each other to, which is not the same thing as a smaller invoice.