The mathematics of fragmentation
A Dutch healthcare organization with 15 source systems technically has up to 105 possible point integrations. That number follows from a simple formula: with n systems, there are n*(n-1)/2 possible direct connections. Add one system and that number grows quadratically — not linearly.
Even if only 10% of those potential connections are actually needed, that still amounts to around 10 separate integrations. Each one has its own version control, its own monitoring, its own security attributes, its own test pipeline, and its own documentation. The cognitive load on the IT team grows in parallel.
And the number of required connections keeps growing. A new HR system that needs to communicate with billing, scheduling, and HR reporting? That alone creates three new integrations — for just one system. Wegiz, EHDS, and ongoing digitalization only increase that number.
“The cost of fragmentation is paid every month — you just never see it on a single invoice.”
Hidden costs that never appear on an invoice
The direct development costs of an integration can seem manageable — a few weeks of work, a few thousand euros per connection. That is often how the topic is framed in a management decision. It is simply not the full picture.
The indirect costs are where the real pain lies. Downtime: when system A fails, the integrations with B, C, and D break as well. Duplicate data entry: when a connection fails, healthcare professionals enter the same data in multiple systems. Compliance evidence per connection: for each individual integration, the DPIA, risk analysis, penetration test, and audit trail must all be maintained.
Every time an endpoint receives a version update, the counterpart must be tested and potentially updated. With 10 connections each receiving two updates per year, that is 20 regression-testing cycles annually that virtually no one performs systematically. The result: brittle integrations that break at the worst possible moment.
Why a FHIR layer breaks the curve
FHIR is not a software product; it is a semantic agreement. HL7 publishes FHIR (Fast Healthcare Interoperability Resources) as an open standard through which healthcare concepts are exchanged in a structured manner via RESTful APIs. The resources are recognizable: Patient, Observation, MedicationRequest, Encounter, and so on.
By normalizing all sources to FHIR — by having each system project its data to the shared FHIR resources — every addition becomes linear rather than exponential. For 15 systems, that means 15 connections instead of 105. More importantly: every additional system requires the same effort as the previous one.
This is not only a technical advantage. It shifts the routing architecture in your organization from a hub-and-spoke tangle of direct connections to a standardized exchange layer. Any new system connecting to it only needs to implement the FHIR mapping — not 14 separate integrations with existing systems.
What this means for the business case
The gain lies not only in less build effort, but in scalability: adding new use cases becomes a matter of weeks rather than quarters. An AI agent that needs to consume intake data from three systems? That is one FHIR query, not three new integrations.
And perhaps more importantly: auditing becomes simpler. One source of truth per data class, one place for access policy, one shared audit log. Compliance becomes something you demonstrate, not something you reconstruct. Wegiz requires standardized electronic exchange — a FHIR layer is exactly that.
Total Cost of Ownership calculated over a five-year horizon typically shows that a shared integration layer reaches break-even somewhere between year two and year three. After that, every new connection becomes cumulatively less expensive, while the point-to-point route starts again at full cost each time.
Common objections — and why they don't hold up
"A central layer is a single point of failure." Not if you build it properly. A FHIR server can be deployed redundantly and in a distributed manner, with failover and separate read/write paths. The single point of failure actually arises with point-to-point connections, where one endpoint becomes critical to twenty systems.
"Our vendors don't support FHIR." That was true until a few years ago. Today, major EHR and EPD vendors publish FHIR endpoints, and FHIR mapping for specific ancillary systems is achievable via gateways and adapters. The Wegiz deadline is accelerating that support faster than many vendors had planned.
"FHIR is too generic for our use case." Rarely true. FHIR extensions and profiles — such as the Dutch Nictiz profiles — provide precisely the space for sector-specific fields without abandoning the shared core. What must remain local, stays local; what must be transferable, remains transferable.
How do you migrate from point-to-point to FHIR?
The most pragmatic approach: do not do it all at once. A big-bang migration of 10 connections simultaneously is a recipe for disruption. Instead, work with a strangler pattern — build the FHIR layer alongside the existing integrations, switch them over one by one, and retire the old connections once the new ones are stable.
Start with the most painful connection. Which integration consumes the most time, breaks most frequently, or is most often blocked by compliance questions? That is where the business case lies. The first FHIR connection is an investment; the second and third already yield measurable time savings.
Finally, dedicate a team that owns the integration platform — not one individual, not a rotation of contractors. A shared FHIR layer requires continuity of expertise; otherwise the old problem reappears in a new form: central infrastructure that no one feels accountable for.
