Dat we een door een pandemie veroorzaakte gezondheidscrisis meemaken, weet iedereen. Dat die crisis aantoont dat ze overheid slecht omgaat met ict weten velen. Maar dat het meest schrijnende ict-falen as we speak zich afspeelt op het gebied van data is vrijwel onbekend.
Op 9 april jongstleden meldde het RIVM dat ze waren opgehouden met het bijhouden van de vaccinatiecijfers van kwetsbare groepen. De reden? De gegevenslogistiek tussen de GGD’s en het RIVM loopt niet goed. Nou was dat al bekend. De GGD’s werken met een nieuw systeem genaamd CoronIT. Dat systeem functioneert, maar de test- en vaccinatiedata worden record-voor-record via een niet goed werkend GGD-systeem genaamd HPZone doorgestuurd naar het RIVM. Door voortdurende uitval en het kennelijk ontbreken van feedback loops durft het RIVM voorlopig geen uitsplitsing van vaccinatiedata meer te geven.
Dat in een gezondheidscrisis die tienduizenden mensenlevens en tientallen miljarden kost basale stuurinformatie onbetrouwbaar of niet beschikbaar is, is ernstig. Veel ontbrekende informatie zit immers gewoon in het systeem CoronIT bij de GGD. Maar het RIVM geeft nóg een reden om de handdoek in de ring te gooien: Cijfers van ziekenhuizen, verpleeginstellingen en huisartsen ontbreken deels nog.
Niet kwijt kunnen
En inderdaad. Zowel testen als vaccineren gebeurt niet (meer) alleen door de GGD’s. Het vaccinatiebeleid is bovendien gebaseerd op een indeling in risicogroepen die deels is gebaseerd op leeftijd maar deels ook op medische informatie, zoals het bezit van extra kilo’s (morbide obesitas) of een extra chromosoom (downsyndroom). Los daarvan zijn er aanhangers van mensen als Willem Engel (‘viruswappies’) en Thierry Baudet (‘corona is griepje’) die geen vaccinatie wensen. En tenslotte heeft een kwart van de Nederlanders al een corona-infectie doorgemaakt. Zo mag ondergetekende binnenkort een vaccinatie-oproep verwachten, maar met mijn hoeveelheid antilichamen wil ik als solidaire burger achteraan in de rij. Ik kan die informatie alleen niet kwijt bij de autoriteiten.
Zo ongeveer het enige waar onze overheid zicht op heeft zijn de aantallen en leeftijden van de burgers. De ontbrekende informatie is echter elders aanwezig, in de hoofden van burgers en in systemen buiten het overheidsdomein. Maar terwijl de pandemie voortwoekert gebeurt er maand na maand en Kamerdebat na Kamerdebat nagenoeg niets aan deze informatiepositie. Hooguit kunnen we zeggen dat het RIVM en de GGD elk voor zich bezig zijn om specifieke corona-informatiesystemen te bouwen (RIVM) of te verbouwen (GGD). Maar dat is software en hier gaat het over data.
Passiviteit
Natuurlijk hebben GGD en RIVM een aansluiting op de bevolkingsadministratie (de BRP), dus dat zit hopelijk goed. Wat je zou verwachten van een overheid die aanstuurt op groepsimmuniteit door zowel vaccinatie als immuniteit-na-besmetting, is dat burgers de mogelijkheid krijgen om aan te geven dat ze (aantoonbaar) een besmetting hebben doorgemaakt of dat ze geen vaccinatie wensen. Een verbouwde kopie van het donorregister had er vorig jaar al kunnen zijn, maar het valt buiten de opdracht van de GGD en het RIVM en het ministerie van VWS is zoals altijd passief.
Maar echt boeiend is de situatie met betrekking tot risico verhogende aandoeningen. Die informatie is er ook. De bron zijn de registraties door de huisartsen. Onze overheid, die strak wil regelen dat iedereen netjes op volgorde wordt geprikt, had met deze informatie probleemloos iedereen vooraf in een risicogroep kunnen indelen, uiteraard in overleg met de huisartsen en met aandacht voor privacy. En uiteindelijk hoeft de GGD alleen iemands risicogroep te weten en niet wat hij/zij mankeert. Overigens is deze informatie ook uit de systemen van de ziektekostenverzekeraars te halen, maar daarvan zouden veel mensen nerveus worden.
Falen
Met de medische input van huisartsen speelt nóg een probleem. Huisartsen vaccineren zelf ook – gelukkig maar. Natuurlijk zijn er huisartsen die friends and family (fout) of een te dikke patiënt van 59 met astma voor laten gaan (goed). Maar daarna moet deze informatie alsnog bij de GGD’s en het RIVM terechtkomen. Ik vroeg een bevriende huisarts of dat gebeurt. Zijn antwoord: ‘lang niet altijd’. Zelf geeft hij alleen gegevens door als de patiënt uitdrukkelijk staat geregistreerd als akkoord met gegevensuitwisseling. Ook hier ontstaat dus weer een gat in de registratie, maar ook hier belandt de vaccinatie-informatie weer netjes in de huisarts-informatiesystemen, beschikbaar doch buiten bereik van VWS, GGD’s en RIVM.
Natuurlijk is het wel of niet gebruik maken van medische persoonsinformatie een politieke keuze. Maar onze overheid heeft bewust gekozen voor een vaccinatie-aanpak gebaseerd op een strakke volgorde en daaruit volgen minimumeisen aan je informatiehuishouding. In 2020 had dat allemaal op orde kunnen zijn gebracht, maar een hightech coronamelder-app bleek belangrijker dan basale data-hygiëne. Zoals steeds falen ook hier minister De Jonge en zijn ambtenaren. Maar als het RIVM meldt dat ze het zicht kwijt zijn op de bescherming van de bevolking en er wordt niemand boos, dan is er iets fundamenteler mis. We falen allemaal, als zelfverklaard kennisland.
Dit artikel staat ook in Computable-magazine #02/2021.
Nagekomen bericht: Bij gebrek aan vaccinatiedata is het gissen naar het verdere verloop van de pandemie.
als je denkt in webapis, powerautomate, databasesocket, i/o bus, mutatiebestand, ben je een it-wappie die een juridisch/organisatorisch/politiek probleem denkt op te lossen.
Wat voor wappie ben je dan als je denkt dat iemand dat denkt?
Een exportfunctie bouwen is (technisch) niet het probleem, eenvoud waarmee je gegevensverzamelingen koppelt met oplossingen zoals PowerAutomate/Flow is één van de punten van zorg. Een reden om de architectuur van GGD-systeem te herzien ging om export-functies zonder logging. Nu heeft het toevoegen van zo’n audit weinig nut als een ieder die door de GGD gevaccineerd actief moet instemmen met doorgifte van gegevens aan RIVM terwijl het op dit moment meer een wie niet weet die stemt toe van een passief consent is. Ik kan me niet herinneren dat mijn moeder iets gevraagd is of dat haar iets uitgelegd is en ik ben er beide keren bij geweest.
Het voorkomen van een datalek doe je door de informatie af te lakken aan de bron voordat je deze verstuurd. Data classificatie naar actief consent aan de bron zal je vast met PowerAutomate/Flow kunnen bouwen want RPA gaat om een automatisering van de informatieprocessen alleen vrees ik dat een record-voor-record opvraging via een webAPI zo traag als dikke stront door een dunne trechter is. Dikke stront in SOA is de protocol overhead van TCP/IP terwijl dunne trechter de I/O bus is welke veelal gedeeld wordt waardoor uitschalen tot een hogere RTT leidt met uiteindelijk meer time-outs.
Oudlid, de dikke stront in SOA heeft een naam: Data.
Word jij in de supermarkt ook niet altijd gek van de informatieovervloed en keuzestress ?
Jack,
Vooraf bepalen wat je wilt eten en vanuit die keus een boodschappenlijst maken voordat je naar de supermarkt gaat scheelt een heleboel keuzestress in de winkel want je hoeft dan alleen nog op de pijs te letten. En uiteraard haal je niet telkens één artikel maar alles in één keer omdat je hebt nagedacht over je behoefte en met kennis van de winkelindeling kun je vrij snel je karretje vullen. Ik wordt dan ook niet gek van de informatieovervloed in de supermarkt omdat ik altijd met een boodschappenlijstje op pad gestuurd wordt. Vervelend is het afrekenen als er maar één kassa open is en er een wachtrij van 5 klanten ontstaat want je vergeet nog de dunne trechter. Wachttijd blijkt betreffende een round-trip time (RTT) in ketens nog altijd een grote impact te hebben op de som der delen van SOA.
Ik ga uit van het marktconcept van SOA wat niet om data als één ingrediënt gaat maar om informatie als complete maaltijd wat een datasynthese vanuit meerdere gegevensverzamelingen is. Het verhaal van Rob sluit namelijk aan op het idee van een Enterpris Service Bus waarbij zijn PowerAutomate/Flow als de zoveelste laag over de status quo van een ‘winkelindeling’ gelegd wordt als het om winkelen in de gegevensverzamelingen van verschillende organisatie gaat. Ga ik vissen, jagen of oogsten is vanuit het DIKW-model dat RIVM hanteert een interessante vraag want honger naar data is namelijk nogal groot omdat het recept niet duidelijk is. Doe me dus maar eens een link naar een mooie 5GL vertaling van een wiskundige vergelijking van een kansberekening met enkel onzekere factoren.
Welk probleem moest nou ook alweer opgelost worden ?
IT-ers DIKW is die van het busje komt zo.
@Oudlid, als zoveelste laag? Denkfoutje.
Rob,
Wel of geen toevoeging gaat om de vraag wat je vervang want WebAPI’s zitten boven in het OSI model met daardoor een enorme protocol overhead als we kijken naar de effectieve pay-load per transactie van SOAP/XML. De toevoeging van het e-loket met SOA(P) gaat vooral om een extra presentatielaag op het al gelaagde model van data-, integratie- en applicatielagen in de architectuur. Tenslotte worden eerdere winAPI’s in dit soort stacks veelal niet vervangen waardoor het gebruikelijke ‘kralen rijgen’ in de presentatielaag onveranderlijk door gaat.
@OudLid, waarom zit dat dan allemaal ook nog een keer in SQL-Server?
Rob,
Heb je wel opgelet over prijsvergelijking in de supermarkt? Keuzestress van Jack heb ik niet door een boodschappenlijstje op basis van de FUNCTIONELE eisen. SQL is een taal voor het beheer van gegevens in een relationeel databasebeheersysteem en niet een merk met een licentiemodel op basis van functionaliteit.