← Back to use cases

Build vs Buy: A Decision Framework for the FHIR Backend Layer

A vendor-neutral framework for deciding whether to build, assemble, or buy the FHIR backend a digital health product depends on, with a five-year cost model, a risk model, and a set of decision criteria that survive contact with regulated reality.

Executive Summary

The decision to build, assemble, or buy a FHIR backend is one of the most consequential early architectural choices in a digital health product. The choice cascades into engineering velocity, compliance burden, integration cost, and the size and shape of the team for the entire life of the product.

The decision is also unusually hard to evaluate well, because the costs that matter most show up years after the choice is made. A custom build looks cheap in year one because it ships only the features the team can think of. A managed FHIR backend looks expensive in year one because the licence price is visible up front. By year three, the cost ordering is often inverted, and by year five, the difference is rarely close.

This paper walks through a decision framework that captures the costs that matter most, including the ones that are not obvious in year one. It covers a five-year total-cost-of-ownership model, a risk model focused on the failure modes a digital health product is most exposed to, and a set of criteria for choosing between three positions: build, assemble (open-source plus integration), and buy (managed FHIR backend).

The framework is vendor-neutral. It does not point to a specific product. The conclusion in any specific case depends on the team’s existing competencies, the regulatory context, the integration footprint, and the time-to-market pressure. The framework’s value is in making the trade-offs visible enough to discuss across product, engineering, compliance, and finance.

1. The Three Positions

The three positions are best framed by what the team owns and what they consume.

Build. The team writes a FHIR-shaped data layer themselves. They own the storage model, the validation, the search, the versioning, the audit, the access control, the integrations, and the operational tooling. The result is a custom backend that does exactly what the team has built and nothing else.

Assemble. The team adopts an open-source FHIR server (Hapi FHIR, IBM LinuxForHealth FHIR, Medplum’s open-source core, or a similar component) and integrates it into their stack. They own the deployment, the integration code, and the customisations. The vendor (the open-source community) owns the core.

Buy. The team adopts a managed FHIR backend with a defined SLA, a vendor responsible for the platform, and a deployment model that fits the regulatory requirements. The team owns the integrations they choose to write and the data they put in. The vendor owns the platform.

Hybrid positions exist (for example a managed core with custom extension layers) but tend to settle into one of the three positions over time as the costs of the in-between space become clear.

2. What the Five-Year Cost Model Captures

The cost model that matters runs five years out, not one. The relevant cost categories are the ones that compound rather than the ones that are visible at signing.

2.1 Direct cost categories

  • Engineering build cost. The cost of writing the backend itself, in person-months and salary.
  • Engineering maintenance cost. The cost of keeping the backend running, secure, and current with the relevant standards.
  • Licence or subscription cost. The visible cost paid to a vendor.
  • Hosting cost. The cost of the infrastructure the backend runs on.
  • Compliance cost. The cost of producing the dossier required by the relevant regulations (FDA, BfArM, MDR notified body, ISO 27001 auditor, HIPAA risk assessment).

2.2 Indirect cost categories

  • Integration cost. The cost of integrating the backend with each new partner system the product needs to talk to.
  • Migration cost. The cost of restructuring data when a standard evolves (R4 to R5, ISiK module additions, US Core revisions) or when an integration partner changes.
  • Hiring cost. The cost of recruiting and retaining engineers with the specialised skills a backend layer requires.
  • Opportunity cost. The cost of not shipping the features that engineers building the backend would otherwise have built.
  • Risk cost. The expected cost of incidents the architecture is exposed to.

2.3 The shape of the curve

The cost curve for a custom build is back-loaded. Year one is cheap because the team ships only the slice they need. Year three is expensive because the slice has grown into a backend with full operational obligations and the team has accumulated technical debt around the parts they did not build. Year five often dwarfs the licence cost of a managed alternative.

The cost curve for an assembled stack is medium. The open-source core is free at the licence level, but the integration code, the deployment, the security hardening, and the version-tracking are not. The total cost depends heavily on how far the customisations go and how disciplined the team is about not forking the core.

The cost curve for a managed buy is front-loaded. Year one shows the licence cost. Year three shows the licence cost plus the integration cost the team chooses to take on. Year five is largely flat unless the product crosses into a new regulatory geography or a new integration class.

3. A Worked Example

Consider a digital health team building a remote-patient-monitoring product over five years, growing from 2,000 to 50,000 patients, with a marketing-driven growth pattern that pushes load up after each clinical-evidence milestone.

3.1 Build

  • Year 1: 4 engineers building the backend (data layer, validation, search, audit, basic access control). Cost: ~€800k.
  • Year 2: 3 engineers maintaining and extending. Adding bulk export, more granular access control, an analytics surface. Cost: ~€600k.
  • Year 3: 4 engineers maintaining and extending. Adding integrations with two payer systems and a hospital. Cost: ~€800k.
  • Year 4: 4 engineers maintaining and extending. Migrating to a new internal storage engine because the original schema does not scale. Cost: ~€800k.
  • Year 5: 5 engineers maintaining and extending. Adding ISiK conformance for German market entry. Cost: ~€1.0M.

Total direct cost over 5 years: €4.0M, plus hosting (€500k), plus compliance overhead (~€300k). Grand total: ~€4.8M.

3.2 Assemble

  • Year 1: 2 engineers integrating Hapi FHIR, building the access layer, customising the search behaviour. Cost: ~€400k.
  • Year 2: 2 engineers extending the access layer, building bulk export, integrating analytics. Cost: ~€400k.
  • Year 3: 3 engineers integrating with two payer systems and a hospital, fighting Hapi version upgrades that broke the customisations. Cost: ~€600k.
  • Year 4: 3 engineers maintaining and extending; the customisations are now a fork in everything but name. Cost: ~€600k.
  • Year 5: 3 engineers maintaining and extending; ISiK conformance requires a profile-validation overhaul. Cost: ~€600k.

Total direct cost over 5 years: €2.6M, plus hosting (€600k, includes more aggressive caching), plus compliance overhead (~€300k). Grand total: ~€3.5M.

3.3 Buy

  • Year 1: licence ~€100k, 1 engineer integrating ~€200k, hosting bundled. Cost: ~€300k.
  • Year 2: licence ~€150k, 1 engineer maintaining and extending integrations. Cost: ~€350k.
  • Year 3: licence ~€200k (more patients), 2 engineers integrating payer systems and a hospital using the platform’s integration tooling. Cost: ~€600k.
  • Year 4: licence ~€250k, 2 engineers extending integrations. Cost: ~€650k.
  • Year 5: licence ~€300k (German market), 2 engineers extending integrations including ISiK conformance through platform configuration. Cost: ~€700k.

Total direct cost over 5 years: €2.6M, plus compliance overhead (€100k thanks to vendor-supplied dossier material). Grand total: ~€2.7M.

3.4 What the example shows

The build is the most expensive path by a wide margin in this example. The assemble path is competitive on direct cost but loses ground on compliance overhead and on the recurring upgrade cost the customisations carry. The buy path is the cheapest direct cost and the smallest compliance overhead, but the team has the smallest control surface.

The numbers are illustrative rather than authoritative. The shape of the curve, however, is consistent across the examples we have seen across multiple digital health teams. The build path looks attractive in year one and looks expensive by year five. The buy path is the inverse.

4. The Risk Model

The cost model is one half of the picture. The risk model is the other half. Three risk categories matter most for a digital health product.

4.1 Compliance risk

A backend that does not produce the evidence the regulator expects is not deployable into the market the regulator covers. The compliance risk is the probability of producing such a backend, weighted by the cost of recovery.

The build position carries the highest compliance risk because the entire backend record has to be produced from scratch and the team often discovers gaps under deadline pressure. The buy position carries the lowest compliance risk because the vendor publishes the backend-layer release record (versioned releases, change history, security advisories, product documentation) on an ongoing cadence; the manufacturer’s QMS plugs those artifacts into the manufacturer’s own dossier rather than reconstructing them.

4.2 Integration risk

A digital health product accumulates integrations over time: identity providers, payer systems, EHRs, hospital systems, patient-facing apps, analytics, study data exports. Each integration that the backend cannot easily support is either a custom integration project or a missed deal.

The build position carries the highest integration risk because each new integration is a project. The assemble position carries medium integration risk; the open-source core often supports the standard integration shapes but the customisations may not. The buy position carries the lowest integration risk because the vendor invests in integration patterns across customers.

4.3 Operational risk

A backend in production has to keep running predictably. The operational risk is the probability of an outage, a data integrity incident, a security incident, or a performance incident, weighted by the cost.

The build position carries the highest operational risk because the team’s first encounter with each failure mode is in production. The buy position carries the lowest operational risk because the vendor’s deployment has met the failure modes already.

5. When to Build

Build fits a small number of cases. The clearest is when the data model is genuinely not FHIR-shaped and a translation layer would be lossy. The second is when the team has a strong existing competency in distributed data systems and the FHIR backend is the team’s primary product, not a supporting layer of something else. The third is when the product’s competitive advantage is the backend itself.

In every other case the build path’s costs accumulate faster than the team initially expects, and the dossier work is harder than the team initially expects.

6. When to Assemble

Assemble fits when the team has the engineering depth to operate an open-source FHIR core in production, when the customisations are limited and disciplined, and when the cost model penalises licence fees more than engineering cost.

The risk that turns assemble into the worst of both worlds is fork drift. Customisations that started as small extensions accumulate over time and end up as a fork in everything but name. The fork blocks upstream upgrades, multiplies the security review burden, and re-creates the dossier problem the open-source core was supposed to avoid.

Teams that succeed with assemble tend to enforce a strict discipline: customisations are layered above the core through documented extension points, and the core itself is upgraded on a predictable schedule.

7. When to Buy

Buy fits most digital health products that are not themselves FHIR backends. The vendor’s published backend-layer evidence, integration coverage, and operational maturity are difficult to match with engineering investment alone, and the time-to-market gap is hard to recover later.

Buy also fits when the regulatory geography is broad. A FHIR backend whose architecture and release artifacts already line up with HIPAA, GDPR, MDR, and DiGA expectations removes a class of backend-layer work the manufacturer would otherwise carry on every market expansion. The manufacturer still authors the dossier itself; the vendor’s record feeds into it.

The risk that turns buy into the wrong answer is vendor lock-in. The mitigation is to choose a vendor whose data model is standards-based (FHIR R4, exportable through Bulk Data) and whose deployment model is portable (the manufacturer can move the deployment if the relationship ends). With a standards-based data model and an exportable deployment, buy is reversible at a defined cost rather than at an open-ended cost.

8. The Decision Criteria

Six criteria capture most of what teams should weigh.

  1. Time-to-market pressure. If the product has to be in front of users within a year, buy. If three years is fine, the other positions become viable.
  2. Engineering depth. If the team has the depth to operate a backend in production, build or assemble. If they do not, buy.
  3. Regulatory footprint. If the product is going into multiple regulated geographies, buy. If it is one geography for the foreseeable future, the others are viable.
  4. Integration breadth. If the product has to talk to many partners, buy or assemble with discipline. If integrations are limited and stable, build is viable.
  5. Cost sensitivity over five years. Build is the most expensive over five years in most cases. Assemble is competitive when discipline holds. Buy is the most predictable.
  6. Strategic importance of the backend. If the backend is the product’s competitive advantage, build. If it is a supporting layer, buy.

9. The Half-Way Houses

Two patterns sit between the three positions and are worth naming.

9.1 Buy the core, build the periphery

Many teams find the right shape is to buy a managed FHIR core and to build the workflow, UI, and product-specific logic above it. This pattern keeps the engineering investment focused on the part of the product that differentiates and pushes the commodity backend work to the vendor. Most successful digital health products converge on this shape over time.

9.2 Assemble the core, buy the operational layer

Less common but viable for teams with strong open-source competency: assemble the FHIR core from open-source components and buy a managed operational layer (monitoring, audit storage, identity provider). This pattern fits teams that have a religious commitment to open source and the engineering discipline to operate it.

10. Common Mistakes

Across the build/assemble/buy decisions we have seen, three mistakes account for most of the regret.

10.1 Underestimating the dossier cost

Teams routinely budget for the engineering cost of the backend and not for the dossier cost. The dossier work for a custom backend is at least as expensive as the engineering, often more. The buy path’s dossier savings are a real and consistent cost reduction.

10.2 Underestimating the operational cost

A backend in production has to be monitored, patched, recovered, and supported on call. The team that built the backend usually ends up doing the operational work too, which compounds the opportunity cost.

10.3 Overestimating the lock-in risk of buy

When the data model is FHIR R4 and the platform supports Bulk Data export, the lock-in risk is bounded. Teams that overweight the lock-in risk against a standards-based platform are often paying the build or assemble cost to avoid a risk that does not materialise.

11. Closing

The build/assemble/buy decision rewards taking a five-year view. The costs that matter most are the ones that show up after the architecture has set, and the risks that matter most are the ones that the architecture’s failure modes are exposed to. A team that runs the cost model honestly, weighs the risk model against their tolerance, and chooses against the criteria above will arrive at the position that fits their context.

Most digital health teams who are not themselves FHIR backend vendors arrive at buy, often after spending one or two years on build or assemble first. The cost of converging on a position via the wrong starting point is non-trivial, and the framework above is meant to surface enough of the trade-offs to make the call earlier.

References