Data: Waarom een modern dataplatform de basis is voor volwassen AI in de zorg

In de whitepaper “De weg naar volwassen AI in de zorg” interviewden we 11 Nederlandse zorgorganisaties over hun weg naar AI-volwassenheid. Eén van de negen onderzochte domeinen is Data (T1): de beschikbaarheid, kwaliteit, standaardisatie en ontsluiting van data. Van alle domeinen scoort dit het laagst: 7 van de 11 organisaties zitten hier nog in fase 1 “Beginnend: versnipperd en experimenteel”. Geen toeval: zonder een solide datafundament blijft AI hangen in losse pilots, hoe goed het model ook is.

Het probleem is niet nieuw, maar wel hardnekkig

Historisch gegroeide EPD-inrichtingen zoals HiX, afdelingsspecifieke applicaties en jarenlange maatwerkoplossingen hebben in vrijwel elke zorgorganisatie datasilo’s opgeleverd. Er is beperkte standaardisatie, waardoor iedere afdeling het op zijn eigen manier doet. Data is vaak “goed genoeg” voor het primaire zorgproces, maar onvoldoende gedefinieerd, gemonitord en gevalideerd om organisatiebreed te hergebruiken in AI-toepassingen.

Belangrijk daarbij: dit is niet alleen een technisch vraagstuk. Eén van de geïnterviewde ziekenhuizen benoemde het scherp: datakwaliteit is cruciaal, maar het verbeteren ervan ligt niet bij het AI-implementatieteam; daar zijn andere teams verantwoordelijk voor. Een dataplatform bouwen is dus net zo goed een organisatorisch als een technisch traject.

Van fase 1 naar fase 3: wat een modern dataplatform toevoegt

De whitepaper beschrijft drie fasen voor het domein Data. In fase 1 is data versnipperd en wordt de ontsluiting handmatig geregeld. In fase 2 is datamanagement ingericht en zijn kernbronnen gedocumenteerd. In fase 3 is data gestandaardiseerd, gevalideerd en (near-)real-time overal beschikbaar, met soevereiniteit geborgd in de architectuur.

Een lakehouse-platform, of dat nu Databricks of Microsoft Fabric is, is een van de manieren om die beweging concreet te maken. Voor wie er dagelijks mee werkt, zijn dit de vier bouwstenen die het verschil maken:

1) Bronkoppeling

De grootste inspanning zit zelden in het platform zelf, maar in het samenbrengen van uiteenlopende bronsystemen, in de zorg bijvoorbeeld EPD, planning, facturatie en losse afdelingsapplicaties, tot één consistente set datamodellen. Technisch gebeurt die instroom vaak via geautomatiseerde ingestie-tooling, zoals Auto Loader in Databricks, die nieuwe data uit bronsystemen incrementeel oppikt en verwerkt zonder dat daar handmatig werk voor nodig is. Dat vraagt daarom vooral om het expliciteren en documenteren van kernbronnen, vóór er ook maar één AI-model wordt gebouwd. Zodra meerdere systemen hetzelfde soort informatie bevatten, denk aan een patiënt- of cliëntbeeld dat in meerdere applicaties losstaand wordt bijgehouden, ontstaat de behoefte aan één gezaghebbende, herbruikbare versie. Die ene waarheid voorkomt dat elk team zijn eigen interpretatie van “de data” hanteert.

2) Herleidbaarheid

Juist in een gereguleerde omgeving als de zorg moet je kunnen aantonen waar data vandaan komt, wanneer die is gewijzigd en op basis waarvan een AI-toepassing tot een uitkomst komt. Lineage en versiebeheer maken dit aantoonbaar, in plaats van afhankelijk te zijn van losse documentatie. Dit wordt typisch geautomatiseerd vastgelegd in de catalogus van het platform zelf, bijvoorbeeld via Unity Catalog lineage, waardoor herkomst en wijzigingen zichtbaar zijn zonder dat iemand dit apart hoeft bij te houden.

3) Veilig delen zonder kopieën

Data delen tussen teams, afdelingen of samenwerkende zorgorganisaties, zonder dat er kopieën rondzwerven. Dat scheelt risico én beheerlast, ongeacht welk platform dit faciliteert.

4) Gelaagde datakwaliteit

Ruwe data uit EPD’s, plannings- en financiële systemen landen eerst ongewijzigd, worden daarna opgeschoond en gestandaardiseerd, en worden tot slot gemodelleerd voor specifiek gebruik zoals rapportage of AI-modellen. Databricks noemt dit bronze/silver/gold; Microsoft Fabric werkt met een vergelijkbaar concept binnen OneLake. Die opschoning en standaardisatie tussen de lagen worden in de praktijk vaak afgedwongen door pipeline-tooling, zoals Lakeflow Declarative Pipelines bij Databricks, die datakwaliteitsregels tussen de lagen bewaakt vóórdat data doorstroomt. Zo is "gevalideerd" geen handmatige nacontrole achteraf, maar een ingebouwde stap in het transformatieproces zelf. Voor de meeste lezers telt vooral dat ruwe data zo stap voor stap betrouwbaar wordt, in plaats van los te hangen in silo’s.

Van schone data naar begrepen data: de rol van een kennislaag

Een gestandaardiseerd platform lost het bronprobleem op, maar niet het betekenisprobleem. Een AI-model dat toegang heeft tot goed gestructureerde data, weet daarmee nog niet wat een “opname” is, wanneer een “diagnose” definitief is, of hoe een cliëntbeeld in het ene systeem zich verhoudt tot een patiëntbeeld in het andere. Daarvoor is een kennislaag nodig: een ontologie die begrippen, definities en onderlinge relaties expliciet vastlegt, los van de onderliggende systemen.

Zo’n kennislaag is wat het verschil maakt tussen data die er ligt en data die een AI-toepassing daadwerkelijk kan interpreteren. Het is ook waarom bronkoppeling en een kennislaag elkaar aanvullen: bronkoppeling brengt de data samen; de ontologie zorgt dat die data een gedeelde, eenduidige betekenis krijgt. Zonder die laag blijft elke AI-toepassing gebonden aan de aannames van de dataset waarop hij toevallig is gebouwd.

Welke ervaring is hier relevant voor de zorg?

Dit soort dataplatforms en kennislagen bouwen we bij IG&H inmiddels ook binnen de zorg zelf, naast de ervaring die we breder in andere datagedreven sectoren hebben opgebouwd. Wat steeds terugkomt: de grootste uitdaging zit niet in de techniek, maar in het samenbrengen van bronsystemen tot iets waar de organisatie op kan bouwen, het aantoonbaar maken van herkomst en gebruik van data, en het vastleggen van een gedeelde betekenislaag daarbovenop.

Geen doel op zich, en geen keuze voor één leverancier

Een dataplatform optuigen, in welke technologie dan ook, is geen garantie voor AI-succes — dat blijkt ook uit de whitepaper: impact is het resultaat van samenhang tussen proces, mens en techniek. Welk platform het beste past, hangt af van de bestaande Microsoft/Azure- of AWS-voetafdruk, het datavolume en de bestaande teamkennis. Maar zonder een schaalbaar dataplatform met degelijke governance, aangevuld met een kennislaag die betekenis toevoegt, blijft elke AI-toepassing afhankelijk van een handmatige, kwetsbare dataverzameling per project. Dat is precies waarom organisaties die willen doorgroeien naar fase 3, hier vaak als eerste in investeren: het is de bouwsteen waar andere domeinen — AI-oplossingen, adoptie, cliëntbeleving — op voortbouwen.

Praktisch startpunt

Begin niet met “alle data” te willen ontsluiten. Kies één kritieke databron waar een AI-toepassing daadwerkelijk op leunt, bijvoorbeeld het patiënt- of cliëntbeeld, en breng in kaart welke systemen daar nu een eigen versie van bijhouden. Leg vast wat de bron van waarheid is, wie daarover gaat, en welke definitie leidend is. Van daaruit breid je uit naar de volgende kritieke bron, in behapbare stappen, niet in één big bang, en los van welk platform je uiteindelijk kiest.

Benieuwd hoe dit voor jouw organisatie eruitziet?

Lees de volledige whitepaper “De weg naar volwassen AI in de zorg” of neem gerust contact op:

Michael Zuur

Director Data & AI

michael.zuur@igh.com