De wiskunde van fragmentatie
Een Nederlandse zorgorganisatie met 15 bronsystemen heeft technisch gezien tot 105 mogelijke point-integraties. Dat aantal volgt uit een eenvoudige formule: bij n systemen zijn er n*(n-1)/2 mogelijke directe koppelingen. Voeg een systeem toe en dat aantal groeit kwadratisch — niet lineair.
Zelfs als maar 10% van die mogelijke koppelingen daadwerkelijk nodig is, zijn dat al gauw 10 aparte integraties. Elk daarvan heeft eigen versiebeheer, eigen monitoring, eigen security-attributen, eigen testpijplijn en eigen documentatie. De cognitive load voor het IT-team groeit mee.
En het aantal benodigde koppelingen blijft groeien. Een nieuw HR-systeem dat moet praten met facturatie, planning en HR-rapportage? Dat zijn al drie nieuwe integraties — terwijl het maar één systeem is. Wegiz, EHDS en de doorgaande digitalisering maken dat aantal niet kleiner; integendeel.
“De rekening van fragmentatie wordt elke maand betaald — alleen zie je hem niet op één factuur staan.”
Hidden costs die niet op de factuur staan
De directe ontwikkelkosten van een integratie lijken beheersbaar — een paar weken werk, een paar duizend euro per koppeling. Op die manier wordt het onderwerp vaak gepresenteerd in een management-decision. Het is alleen niet het hele plaatje.
De indirecte kosten zijn waar het echt pijn doet. Downtime: als systeem A faalt, breekt de integratie met B, C en D ook. Dubbele registratie: als een koppeling het laat afweten, voeren zorgprofessionals dezelfde data in meerdere systemen in. Compliance-bewijs per koppeling: voor elke afzonderlijke integratie moet de DPIA, de risico-analyse, de penetratietest en de audit-trail worden onderhouden.
Bij elke versie-update van een endpoint moet de tegenhanger getest, en mogelijk aangepast worden. Bij 10 koppelingen die elk twee keer per jaar een update krijgen, is dat 20 cycli per jaar van regression-testen die simpelweg niemand structureel doet. Het resultaat: brittle integrations die op het slechtst denkbare moment kapotgaan.
Waarom een FHIR-laag de curve breekt
FHIR is geen softwareproduct; het is een semantische afspraak. HL7 publiceert FHIR (Fast Healthcare Interoperability Resources) als open standaard waarmee zorgconcepten gestructureerd worden uitgewisseld via RESTful API's. De resources zijn herkenbaar: Patient, Observation, MedicationRequest, Encounter, en zo verder.
Door alle bronnen naar FHIR te normaliseren — door elk systeem zijn data naar de gedeelde FHIR-resources te laten projecteren — wordt elke toevoeging lineair in plaats van exponentieel. Voor 15 systemen betekent dat 15 koppelingen in plaats van 105. Nog belangrijker: elk extra systeem kost dezelfde moeite als het vorige.
Dit is niet alleen een technisch voordeel. Het verschuift het verkeerssysteem in je organisatie van een hub-and-spoke met een wirwar van directe verbindingen, naar een gestandaardiseerde uitwisselingsruimte. Wie nieuw aansluit, hoeft alleen de FHIR-mapping te maken — niet 14 aparte integraties met bestaande systemen.
Wat dit betekent voor de business case
De winst zit niet alleen in minder bouwwerk, maar in schaalbaarheid: nieuwe use-cases toevoegen wordt een keuze van weken in plaats van kwartalen. Een AI-agent die intake-data uit drie systemen wil gebruiken? Dat is één FHIR-query, geen drie nieuwe integraties.
En misschien belangrijker nog: de audit wordt simpeler. Eén bron van waarheid per dataklasse, één plek voor toegangsbeleid, één gemeenschappelijke audit-log. Compliance wordt iets wat je aantoont, niet iets wat je reconstrueert. Wegiz vereist gestandaardiseerde elektronische uitwisseling — een FHIR-laag is precies dat.
Total Cost of Ownership berekend over een termijn van vijf jaar laat doorgaans zien dat een gedeelde integratielaag ergens tussen jaar twee en drie break-even draait. Daarna wordt elke nieuwe koppeling cumulatief goedkoper, terwijl de point-to-point-route iedere keer opnieuw begint vanaf vol tarief.
Veelgehoorde bezwaren — en waarom ze niet kloppen
"Een centrale laag is een single point of failure." Klopt niet als je hem goed bouwt. Een FHIR-server kan redundant en gedistribueerd worden, met failover en gescheiden read/write-paden. De single point of failure ontstaat juist bij point-to-point-koppelingen waar één endpoint kritiek wordt voor twintig systemen.
"Onze leveranciers ondersteunen geen FHIR." Dat klopte tot een paar jaar geleden. Inmiddels publiceren grote ECD- en EPD-leveranciers FHIR-endpoints, en is FHIR-mapping voor specifieke ondersteunings-systemen mogelijk via gateways en adapters. De Wegiz-deadline forceert die ondersteuning sneller dan veel leveranciers gepland hadden.
"FHIR is te generiek voor onze use case." Zelden waar. FHIR-extensions en profielen — zoals de Nederlandse Nictiz-profielen — laten exact ruimte voor sector-specifieke velden, zonder de gemeenschappelijke kern op te geven. Wat lokaal moet, kan lokaal; wat overdraagbaar moet, blijft overdraagbaar.
Hoe migreer je van point-to-point naar FHIR?
De meest pragmatische aanpak: doe het niet in één keer. Een big-bang-migratie van 10 koppelingen tegelijk is een recept voor onderbrekingen. Werk in plaats daarvan met een strangler pattern — bouw de FHIR-laag op naast de bestaande integraties, schakel ze één voor één over en trek de oude koppelingen terug zodra de nieuwe stabiel zijn.
Begin met de meest pijnlijke koppeling. Welke integratie kost de meeste tijd, breekt het vaakst, of wordt het meest geblokkeerd door compliance-vragen? Daar zit de business case. De eerste FHIR-koppeling is investering; de tweede en derde leveren al meetbaar tijdwinst op.
Reserveer ten slotte een team dat eigenaar is van het integratie-platform — niet één persoon, niet een rotatie van detacheerders. Een gedeelde FHIR-laag verlangt continuïteit van expertise, anders ontstaat het oude probleem in nieuwe vorm: een centrale infrastructuur waar niemand zich verantwoordelijk voor voelt.
