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.
Reacties
Vanochtend las ik al een artikel over de chaos rond de registratie van de gevaccineerden. Dat betekent volgens mij niet dat het nu gissen is naar het verloop van de pandemie. De cijfers van de ziekenhuizen zijn daarvoor de indicatie, gaan die naar 0 dan gaat het goed.
Je zou denken dat het vaccineren strak geregeld is kwa administratie: alles in de De Grote Database. Naam? Paspoort? Afkomst? Prikken maar. Misschien is het daarom helemaal niet erg dat het een rommeltje is met de administratie. Hoe meer een zootje met die data hoe beter.
dat was-je-handen-stuk is minder abstract dan "basale data-hygiëne".
en coronamelder-app is sexier dan hygiene regels.
wanneer komt artikel over oplossing met blockchain want die kan nooit fouten bevatten zegt men ;-)
"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."
Hoe denken ze dan dat bedrijven zoals ijzergieterijen dat doen met betrekking tot soortelijk sg-metingen, spectraal analyses, temperatuur e.d.? Van applicatie naar applicatie? Natuurlijk niet. Je slaat dingen op in verzamelt csv's/xml's/json's in lokale file-folders of message-queus. Een apart on-create triggered proces biedt ze al of niet succesvol aan en verplaatst ze naar succes- of mislukt-folders/queues. Bij mislukt wacht je tot het probleem is opgelost en sleep je het hele kakkie er weer in de proces-folder of je zet het proces eerst stop. Aan de ontvangstkant precies zo maar dan omgekeerd. Heb je een groot probleem, stapelt het zich hoogstens een beetje op, maar is niets wat een nachtje inhalen niet kan afwikkelen.
Kost geen drol, kan verzamelen en kan uitsplitsen naar diverse verschillende applicaties en zet je in een paar dagen in elkaar. Het is eigenlijk nog een stuk makkelijker dan iets in elkaar zetten dat bij het minste of geringste in elkaar stort en onherstelbaar dataverlies oplevert. Alles met standaard aanwezige voorzieningen en kan met terugwerkende kracht nog jaren weer worden gebruikt voor latere ontwikkelingen.
Hoe toevallig dat (nog meer) medische persoonsinformatie kan helpen bij het oplossen van de crisis want dat het gissen naar het verloop van een pandemie op basis van prikgetallen een obscure vorm van wetenschap is komt vooral door een grote onzekerheid over de effecten van vaccinatie. Never waste a good crisis want wie de bijsluiter van vaccins leest die ziet dat er nog veel onzekerheid is met deze experimentele vaccinaties. Er is nog geen sluitend bewijs dat hiermee (blijvend) de groepsimmuniteit vergroot wordt en de pandemie beteugeld wordt. Op dit moment is het nog één groot fieldlab waar alleen de farmaceutische bedrijven beter van worden als we door angst straks 'verslaafd' zijn aan een jaarlijkse herhaling voor immuniteit met een immorele vendor lock. En ik sluit me dan ook aan bij de reactie van Louis Kossen hoewel naar mijn mening ziekenhuis opnames NIET indicatief zijn voor het verloop van een pandemie als het grootste deel van bevolking door milde klachten thuis uitziekt.
Data-hygiëne is mooi maar nietzeggende data kan ook correct zijn maar toch geen zinnige informatie opleveren want het liegen met statistiek is een politieke kunst.
Meten is weten, maar alleen als je weet wat je meet. Dat laatste kan alleen het geval zijn indien er voldoende wordt gemeten, dus ook welk deel van de meting een inschatting is. Met een juiste definiëring van foutmarges hoef je niet te liegen. Je kan er zo 200.000 vaccinaties naast zitten.
@Rob Koelmans ... ik zou het RIVM even bellen als ik u was. U heeft blijkbaar een perfecte oplossing die in een paar dagen gerealiseerd kan worden. Iedereen blij toch?
@cynikus +1
@Cynicus, zal ik doen. Dankjewel.
Reactie van Rob klinkt alsof beste stuurlui aan wal staan maar in essentie zit er wel een interessant punt in als we kijken naar de foutgevoelige transactionele gegevensuitwisselingen van applicatie naar applicatie versus een ouderwetse batchverwerking via de database. De schaalbaarheid van veel SOA architecturen wordt tenslotte bepaald door de I/O bussen waardoor de verschillende lagen in deze gelaagde architecturen niet altijd op dezelfde snelheid draaien. De eenvoud van het opsturen van een mutatiebestand welke stambestanden wijzigt is daarom in veel processen gebruikelijk, de real-time informatie status is tenslotte veelal niet essentieel.
@Oudlid, wat wij in die gevallen doen is uiteraard altijd wel service oriented. Een webAPI bouw je letterlijk in een twee uurtjes in PowerAutomate/Flow. Werkt niet alleen veilig maar is ook veel makkelijker dan direct op een database socket. We werken dus met een mix van de twee dingen die jij veronderstelt.
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.
@Oudlid, dacht het wel, maar kennelijk niet. Maar dit voert wat mij betreft te ver buiten het bestek van het bovenstaande artikel van René.
Rob,
Het bestek van René gaat om de gegevensuitwisseling welke je op verschillende manieren op kunt zetten door te kijken naar het doel. Rechtmatigheid van opslag en verwerking van persoonsgegevens wordt tenslotte door de doelbinding bepaalt. Gezien tijdelijkheid lijkt het opzetten van een supermarkt model voor beeldschermdokters van RIVM me niet de meest voor de hand liggende architectuur keus door de gebruikelijk 'scope creep' met een onrechtmatig hergebruik van persoonsgegevens. Want problematiek van lokale e-overheid met loketfunctie in de uitvoer en centrale i-overheid met een niet te stillen datahonger voor de beleidsbepaling is al eens benoemd door WRR.
Ondertussen is er een nieuwe (Europese) wet die stelt dat ik het recht op inzage, correctie en soms zelf verwijdering heb. Vanuit dat gezichtspunt zou supermarkt concept ideaal zijn hoewel ik twijfels heb over de organisatorische uitvoerbaarheid als ik honderden supermarkten af moet gaan want zoals je kunt zien zijn er nogal wat ontvangers omdat de burger ongevraagd een onderzoeksobject is:
https://www.rijksoverheid.nl/onderwerpen/privacy-en-persoonsgegevens/vraag-en-antwoord/wie-krijgen-mijn-persoonsgegevens-uit-brp
We hebben alle formaten en standaardisaties al zij het dat de toepassingsgebieden nog heel beperkt zijn. Alles wat je voor een individuele burger nodig hebt, is al ontwikkeld en toegepast in gepubliceerde standaards, organisaties e.d. zoals StUF van Gemma, Vera onder Cora bij woningcorporaties e.d. Dat soort architecturen wordt nu alleen nog onderling gebruikt door instanties maar kun je ook prima gebruiken voor dienstverlening aan burgers of ten dienste van burgerbelangen. Daar is alleen nog geen verdienmodel op.
Het is complexe kost en de grote zoveel kunnen voorlopig nog prima verdienen aan het wegzetten van warm vlees (uitdrukking komt niet van mij maar van Ordina https://www.aanbestedingscafe.nl/na-bouwfraude-vleesfraude-nu-ict-fraude/) bij tot mislukken gedoemde miljoenenprojecten bij de overheid.
Vooral geen nieuwe standaards ontwikkelen. Gaat alleen maar doublerende innovatie opleveren.
Doublerende innovatie door het ontwikkelen van nieuwe standaards ljikt me een contradictio in terminis, een tegenspraak in terminologie. Tenslotte gaat een standaard over erkende specificaties of criteria welke kunnen wijzigen als deze door voortschrijdende technologie achterhaald wordt. Maar natuurlijk kun je er ook voor kiezen een standaard in een andere standaard te verpakken en weer in een andere standaard enzovoort zodat je een Matroesjka poppetje verkrijgt. Vanuit dat gezichtspunt ben ik het trouwens eens met Jack, want soms zijn architecten bezig met het ontwikkelen van een geheel eigen taal voor een beperkt taalgebied.
Lullen we over de puntjes op i dan heb ik al acht keuzen door de diakritische tekens waar veel systemen nog altijd niet mee om kunnen gaan want deze discriminerende systemen hebben vaak moeite met buitenelandse namen, per definitie verdacht. Het is veel makkelijker om iedereen een nummer te geven waabij het gebruik van een BSN ook handig is in het ontmenselijken van het probleem zoals filosofische IT-ers onder ons weten. Want orde in de Nederlandse datachaos gaat om de sleutels die passen op sloten waardoor je relationele verbindingen kunt leggen omdat datasynthese gaat om het menu dat je samenstelt uit de individuele ingrediënten.
Je kunt een standaard voor het ene en een andere standaard voor een ander toepassingsgebied ontwikkelen, toch? Terwijl een goede standaard in beide had voorzien. Ik zie de contradictie niet.
De informatieuitwisseling betreffende de overtreffende trap in DIKW-model gaat om het vertalen van informatie naar kennis wat veelal de som van een informatiesynergie van meerdere (meta)data ingrediënten is. En in overtreffende trap van het DIKW-model geldt 1+1≠2 door de synergie van voortschrijdende kennis betreffende het weten wat je meet aan de hand van een specificatie. Voor wie mij in deze filosofische verwarring niet meer kan volgen, het uitgangspunt is veelal niet 0 omdat er meestal al basis kennis aanwezig is die vastgelegd is in een standaard.
Heb je liever ƒ1, €1 of ₿1?
Aangaande het weten wat je meet zit in de vraagstelling ook nog eens een 'zijn en tijd' perspectief door een dagkoers als het om de waarde van een ruil gaat want gedoemde miljoenenprojecten bij de overheid zijn uiteindelijk een lachertje als je de waarde van de informatie kent. Oja, lood heeft door de synergie meer waarde dan goud als deze verpakt zit in de loop van revolver met daar achter de overtuigende lading van buskruit als het om het nieuwe normaal gaat.
Oudlid, in mijn optiek is datachaos een pleonastische uitdrukking (want data = chaos), en dan schiet een datasynthese dus niet op.
Het geluid uit de koolmonoxidemelder is voor een kind in zijn beperkte belevingswereld een grappig geluidje; voor een volwassene is het informatie op basis van kennis om snel te handelen (en dat is tegelijk een mooie metafoor voor de huidige klimaatcrisis).
Uiteraard levert het doen van boodschappen in de supermarkt geen informatieovervloed en keuzestress op, als je weet wat je wilt! Daarvoor heb ik overigens geen boodschappenlijstje nodig; al sinds jaar en dag hanteer ik namelijk hetzelfde weekmenu. Op maandag haal ik boodschappen voor 3 dagen en kijk voordat ik van huis ga welke benodigde ingrediënten moeten worden aangevuld.
Wat ik in de boodschappenkar leg wordt bepaald door:
1. toekomstige gebeurtenissen, namelijk onder andere de 3 maaltijden, en
2. de levensmiddelen die ik al in huis heb voor deze 3 maaltijden en geen aanvulling behoeven en
3. de levensmiddelen die wel benodigd zijn en soms net uitverkocht zijn in de supermarkt.
Het is duidelijk dat precies punt 3 een keuzemoment oplevert, maar meestal van zeer korte duur, omdat een alternatief product in hetzelfde schap altijd wel voorhanden is. Als de gewenste vleesvervanger is uitverkocht, ga ik uiteraard niet overwegen om opeens weer vlees te eten; ik neem gewoon een andere vleesvervanger, en het is nooit verkeerd om eens wat anders te proberen.
Eerlijk gezegd let ik hierbij niet op de prijs, maar voor ieder is de financiële situatie natuurlijk weer anders. Het is overigens een goed idee om gezonde producten goedkoper en ongezonde producten duurder te maken, wat ook weer flinke besparingen kan opleveren voor de gezondheidszorg.
Je ziet dus dat het gedrag in de supermarkt wordt bepaald door toekomst – wat is benodigd voor de komende dagen – in combinatie met de situatie waarin men verkeert (qua levensmiddelenvoorraad in huis, financiën, gezondheid, etc. ), en dat alles ook weer met alle onderliggende waarden.
De eigenlijke tijd is voor Heidegger geen opeenvolging van nu-momenten, waarbij het verleden bepalend is voor de toekomst, maar een kwestie van herhaling, waarbij de toekomst het belangrijkst is. Over deze ingewikkelde problematiek heeft psychiater en filosoof (en hoogleraar) Gerben Meynen een zeer verhelderend proefschrift geschreven: “Vrijheid en tijd. Het begrip herhaling in Heideggers Sein und Zeit“ (2005).
Als je deze lijn in de geschiedenis van het filosofisch denken even volgt:
https://nl.wikipedia.org/wiki/Nominalisme
wordt het duidelijk dat we met het scheermes van Ockham geen steek verder komen.
Jack,
De context in het systeemdenken van een ordening in chaos gaat om begrip geven aan bepaalde signalen want data is niks, een nietszeggend geluid zonder de context van informatiesythese om de accenten taalkundig even te verleggen. Je kunt dus een kind een dik boek geven over de filosofie maar zolang deze niet (begrijpend) kan lezen is het als je koolmonoxidemelder. Zoals de voedzame maaltijd niet smaakvol hoeft te zijn want het is veelal de toevoeging van kruiden die hiervoor zorgt. Ik heb daarom ook meer kookboeken dan filosofische verhandelingen in mijn boekenkast staan en de Oosterse keuken is favoriet. Want ik heb ook geen scheermes van Ockham maar een santoku met bamboe greep welke ik - net als mijn andere messen - vlijmscherm houdt op een wetsteen, de lege buik kan namelijk niet denken. En is de honger naar kennis eigenlijk niet een honger naar data?