Build, buy, or partner is usually presented as a cost comparison. It is not. All three options can be made to look cheapest depending on which line items you count, which is why the spreadsheet rarely settles the argument.
The variable that actually decides it is roadmap displacement — what your engineers stop building while they build this. That question rarely appears in the comparison, and it is generally the largest number in it.
This is scoped specifically to CMS-0057-F integration work. If you are running a broader interoperability vendor selection, the generic evaluation framework and RFP questions live in how to evaluate healthcare interoperability vendors. This piece is narrower: you have decided to do CMS-0057-F work, and you are deciding who does it.
Before the decision: what are you actually deciding about?
"Do we build or buy CMS-0057-F?" is not answerable, because CMS-0057-F is not one thing. The honest version splits it into layers, and the answer is frequently different for each.
- Transport and auth — per-payer registration, OAuth, token handling. Commoditised. Weak case for building.
- Per-payer capability handling — the variation layer. Buildable, and the thing a platform is genuinely good at absorbing.
- Normalisation into your schema — nobody else has your schema. You are building this whatever you decide.
- DTR and CQL execution — the engine is general-purpose and buyable; the extraction layer under it is not.
- Workflow surface — your product. Always yours.
Teams that reach a clean decision usually got there by splitting the stack first. Teams that stall are trying to answer one question that is really five.
The honest case for each
Build it
Build when payer data is core to what makes your product different, not a feature attached to the side of it. If you already run FHIR in production, the ramp is far shorter than it looks from outside — most of the difficulty in this work is FHIR fluency, and a team that has it is starting from a genuinely different place.
The condition people skip: roadmap headroom. This is two to three quarters of infrastructure work before a customer sees anything. If your next two quarters are already committed, building is not a technical decision you are making; it is a commitment you are quietly breaking.
The upside is real, and it compounds. An integration layer you own is an asset. Payer nine costs you a fraction of payer three, and you are not negotiating renewal terms with anyone.
Buy it
Buy when payer data is a feature rather than the product. If a customer commitment lands in a window shorter than your build, buying is the correct answer, and there is nothing defensive about it.
The trade you are making is control of the seams. Platforms make choices about normalisation, about how variation is abstracted, about what happens when a payer degrades — and those choices become your product's behaviour. When they are wrong for your use case, you are filing a ticket rather than fixing it.
The other trade is per-payer economics. Rented maintenance is a real benefit; it is also a per-payer fee that grows with exactly the thing you hope grows.
Partner
Partner when you want to own the layer but cannot staff it yet, or when the unknowns are concentrated in one place — usually DTR — and the rest is work you could do comfortably.
The version of this that works has three properties: your team is in the build rather than receiving it, handover is written into the engagement from day one, and the deliverable is your codebase rather than access to someone else's. The version that does not work is a build shop that leaves and takes the context with it.
The cost the comparison leaves out
Licence fees and engineering days are easy to count and both sides of the argument count them. The displaced roadmap is harder to quantify and larger in effect.
Two quarters of your senior engineers on payer integration is two quarters of them not on the thing your customers are actually asking for. If that thing was going to close deals, its absence has a number attached, and the number is usually bigger than the licence fee you were arguing about.
Say it out loud in the decision meeting. Name the features that get displaced. If the answer is still "build" after naming them, it is a good decision made with open eyes. If they were never named, a decision did not really happen.
The cost side has no useful public benchmark for the same reason the vendor quotes vary so widely — the drivers differ enormously between teams. The ten that actually move the number are here, and anyone quoting you a figure before asking about them has not scoped the work.
Questions to ask any partner, including us
"Do you support Da Vinci?" is not a question, because the answer is always yes. These six separate the vendors who have done the work from the ones who have read the implementation guide.
The last one is the most useful. Anyone without a real answer to "when should I not hire you?" is selling rather than scoping, and you will find out which later at greater expense.
When you should not hire Nirmitee for this
Applying our own test. Do not bring us in if:
- You already run FHIR in production and have the headroom. You will build a better integration layer than any outside team, because you know your data model and we would have to learn it. Read the DTR guide, run the two-week CQL spike yourself, and keep the money.
- You need one payer, one API, and nothing more. A narrow integration does not justify an engagement. Buy a platform or write it.
- You have not answered the scoping questions yet. Not a reason to avoid us permanently — a reason to do that first, with or without help. Scoping into an engagement is how projects get priced wrong in both directions.
- You are an impacted payer looking for production references on the serving side. Our production work is on the provider-facing consuming side. We would rather say that than imply otherwise.
Where we do fit
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. HIPAA, SOC 2, ISO 27001.
The engagements where we add most are the ones with a concentrated unknown — a DTR extraction gap, a per-payer abstraction that has to hold for a decade, a normalisation layer being designed once. Usually a 15-minute technical conversation is enough for both of us to tell whether that is your situation.
