Most CMS-0057-F estimates are wrong in the same direction, for the same reason: the team scoped the FHIR calls and not the five things that actually determine the size of the work.
This is the scoping conversation, in the order it should happen. It takes a couple of hours with the right people in the room and it replaces a guess with a number you can defend.
Question 0: Are you even in scope?
Ask it first because it changes everything downstream. If you build provider-facing software, CMS-0057-F imposes no obligation on you at all — you are choosing to consume, on your own timeline.
Question 1: serving or consuming?
These are two different projects that share almost no code, and an enormous amount of scoping confusion traces back to this question never being asked out loud.
Serving means you are an impacted payer, or you build the core administrative platform for one. You author questionnaires and CQL rules, run a conformant CRD service, receive and adjudicate PAS submissions, and publish four documented endpoints. January 1, 2027 is a hard date, and your obligation is contractual.
Consuming means you build provider-facing software. You fire the CDS Hook, render someone else's questionnaire, execute someone else's rules against your own record, normalise payer data into your schema, and decide where it surfaces. No deadline, no penalty, and you pick the sequence.
If your answer is "both", scope them as two programmes. They will not share a team well.
Question 2: which of the four APIs, and in what order?
Do not scope all four by default. For most provider-facing products, the answer is one, then maybe a second.
- Provider Access API — the usual starting point, and the one with the clearest product value. Claims, encounter, USCDI clinical and prior auth data for attributed patients.
- Prior Authorization API — high value, and the deepest engineering, because it drags the Da Vinci stack in with it.
- Patient Access API — relevant if you build patient-facing surfaces. Already live since 2021, so the CMS-0057-F change here is incremental.
- Payer-to-Payer API — almost entirely a payer concern. Rarely belongs on a provider-facing roadmap.
The order matters more than the count. Provider Access first gives you the normalisation layer that the Prior Authorization work will reuse. Starting with prior auth gives you a deep vertical slice and no reusable foundation.
Question 3: how deep into Da Vinci?
There are three honest answers, and the increments between them are not even.
- CRD only. A CDS Hooks consumer plus card rendering. The smallest of the three by a wide margin.
- CRD plus PAS. Adds Claim bundle assembly, the
$submitoperation and ClaimResponse handling. Roughly doubles the work.
- The full chain including DTR. Adds a CQL execution environment, a bespoke data extraction mapping, a renderer for arbitrary payer-authored questionnaires and a rule versioning strategy. This is not a small increment on the previous option; it is usually the largest single line in the estimate.
The differences between the three guides are worth understanding properly before you commit, because "we'll support Da Vinci" is not a scope statement.
Question 4: how many payers, and how diverse?
Payer count is the multiplier that turns a project into a programme. Three payers within one line of business is not one third of the work of nine across three lines.
Rank the list by share of your customers' panels rather than by size of the plan nationally. A regional Medicaid MCO that covers 40% of one customer's patients matters more to that customer than a national carrier that covers 3%.
Then ask how different they are. Same line of business, similar geography, and a shared platform vendor means the second and third integrations are cheap. Spread across Medicare Advantage, Medicaid managed care, and FFE issuers means per-payer variation is your primary architectural problem and needs designing for on day one.
Question 5: how far is your schema from FHIR?
This is the question with the widest spread of answers and the largest effect on the number.
A product already storing data in FHIR resources has a short mapping. A product with a bespoke relational schema built over ten years around its own clinical concepts has a long one, and the length is not proportional to the schema's quality — a well-designed non-FHIR model can be further from US Core than a messy one that happened to borrow FHIR's vocabulary.
The reliable way to find out is not to estimate it. Take one real CARIN ExplanationOfBenefit bundle and one real US Core clinical bundle and map them by hand, resource by resource, into your schema. Two days of work, and it will move your estimate more than any other single activity. The normalisation problem in full is here.
Three things people forget to scope
- Client registration lead time. Every payer runs its own onboarding. It is not engineering work, so it does not appear on the engineering plan, and then it blocks it. Start registrations before you start building.
- Opt-out handling as a data model concern. If you persist payer data, member opt-out means a deletion path, not a display filter. That is schema work, and it is rarely in the first estimate.
- Testing before endpoints exist. Payer endpoints appear on payer schedules. You will need sandboxes and reference implementations to validate against in the meantime, and that environment is a build of its own.
What a finished scope looks like
If you can produce these six artefacts, you are scoped. If you cannot, the gap is the next piece of work — not the estimate.
Where Nirmitee.io fits
Healthcare-only, FHIR R4 native, with production EHR integrations delivered for 30+ healthtech companies and an open-source Headless EHR covering 28 clinical domains and 70+ FHIR R4 resources. The two-day mapping exercise in Question 5 is the one we would run first on any CMS-0057-F engagement, including one we ended up not taking — it is the fastest way to find out whether this is a six-week problem or a six-month one.
