Digitale transitie is een breed begrip en omvat veel. Dat uit zich ook in de recente brief over beleid voor digitalisering van het kabinet. Twintig pagina's beleid, ga er maar aan staan.

Aan dat beleid ga ik vanaf deze maand met heel veel mensen handen en voeten geven. Transparant en open, zoals eerder. Daarom aan jou de vraag: help je me op weg?

Ik ben heel nieuwsgierig naar jouw antwoorden op vragen als "waar moet de focus op liggen?", "wat zouden de internationale speerpunten moeten zijn?", "wie moeten zeker gevraagd worden om mee te denken en mee te doen?", "welke resultaten moeten zeker geboekt worden en hoe dan?", "wat moeten we wel doen, en wat ook niet (meer)?", "hoe en waar zorgen we voor blijvende offline en online ontmoetingen en dialoog?", "welke zinnen moeten zeker worden uitgesproken in het volgende debat over digitalisering in de Tweede Kamer?", etc.

Kortom: beleid en uitvoering voor digitalisering, dat doen we samen. Kom maar op met voorstellen en aanbiedingen om mee te doen. Bij voorkeur in een blog, een reactie, etc. Want dan kunnen anderen weer op jou reageren.

Ik ben nieuwsgierig! Reageren kan bijvoorbeeld op LinkedIn

Dit is een blog in een serie waarin ik vragen beantwoord over het wetsvoorstel “Wet elektronische gegevensuitwisseling in de zorg”. Een wetsvoorstel dat beoogt om stap voor stap de zorg te digitaliseren. Zodat faxen, brieven of DVD’s op de buik van een patiënt steeds minder voorkomen. Het is een wet waaronder gegevensuitwisselingen kunnen worden aangewezen die tenminste digitaal moeten verlopen. Dat kan op twee manieren. Door aan te wijzen dat ze elektronisch moeten verlopen (spoor 1 van de wet) of door ook aan te wijzen hoe, volgens welke norm, dat moet (spoor 2). Het is een wet waarover vragen zijn. In een serie blogs ga ik in op die vragen. Heb je ook een vraag? Laat deze gerust weten; via LinkedIn bijvoorbeeld.

De Wegiz en open API's

Van verschillende kanten wordt in de voorbereiding op de behandeling van de Wegiz gezegd dat het jammer is dat de wet geen eisen stelt aan verplicht gebruik van open API's. API's, of Application Programming Interfaces, zijn gestandaardiseerde manieren om gegevens die in informatiesystemen zijn opgenomen te raadplegen of wijzigen. Zo maken API's op de systemen van de GGD en het RIVM het mogelijk om vanuit de CoronaCheck-app vaccinatiegegevens op te vragen en er een bewijs van te maken. Ook het MedMij-afspraken stelsel, dat ten grondslag ligt aan het kunnen ophalen van de eigen informatie in een Persoonlijke Gezondheidsomgeving, werkt met dergelijke API's. Open API s maken innovatie mogelijk, door ontwikkelaars gestandaardiseerde toegang tot informatie in bronsystemen te geven. Daarom is het goed om afspraken over open API's voor de hele zorg maken (en daar wordt door Nictiz ook aan gewerkt).

Afspraken over API's kunnen ook (via opname in normen) verplicht worden gesteld onder de Wegiz. Dat kan niet in een keer voor de hele zorg, maar per gegevensuitwisseling. De Wegiz stelt namelijk eisen aan specifieke gegevensuitwisselingen, denk aan verpleegkundige overdracht of beelduitwisseling tussen ziekenhuizen. Het is dan wel nodig dat de eisen aan techniek die in normen worden opgenomen de API's bevatten.

Daar is voor gekozen omdat elke gegevensuitwisseling andere gegevens bevat en elke verplichting daardoor gaat over andere informatie die wordt uitgewisseld. Zorgprofessionals bepalen zelf in kwaliteitsstandaarden, bijvoorbeeld voor verpleegkundige overdracht, welke informatie nodig is. Als dat is gebeurd dan kan onder de Wegiz worden aangewezen hoe die gegevensuitwisseling moet plaatsvinden. Niet in de wet zelf (die bevat geen vaste technische eisen waardoor de wet innovatie mogelijk maakt), maar in een Algemene Maatregel van Bestuur (AMvB). In zo'n AMvB kan verplicht worden dat aan normen wordt voldoen. In zo'n norm worden zowel eisen gesteld aan taal als aan techniek. Zo zorg je ervoor dat de informatie over komt en ook begrepen wordt. In de aanwijzingen ten aanzien van de techniek kan (via normen waarin eisen zijn opgenomen) dus wel degelijk ook een open API worden aangewezen (bij voorkeur natuurlijk voor elke gegevensuitwisseling dezelfde).

Vanwege de opzet van de Wegiz kan het verplicht stellen van een open API dus wel, maar alleen in normen per gegevensuitwisseling. Dat hoeft niet erg te zijn, want er zijn andere manieren om zorgbrede eisen te stellen. Zo worden in het "Besluit elektronische gegevensverwerking door zorgaanbieders" eisen gesteld aan informatieveiligheid die gelden voor elk zorginformatiesysteem. Net als in de Wegiz gebeurt dat door te verplichten dat wordt voldaan aan NEN-normen. Denk aan NEN 7510 voor informatiebeveiliging en NEN 7513 voor logging. Een NEN-norm voor open API's in de zorg is er nog niet. Maar zo'n norm is best denkbaar!

Open APIs en landelijke uitwisseling
In veel regio's worden zorgspecifieke infrastructuren gebruikt voor gegevensuitwisseling tussen zorgaanbieders. Open API's hebben in de regel geen aparte infrastructuur nodig, want ze maken meestal gebruik van Internet (met beveiliging, dat natuurlijk wel). Als die open API's er zijn dan is landelijke uitwisseling ook veel makkelijker geworden. Zorgspecifieke infrastructuren kunnen dan worden vervangen door veilige communicatie over Internet met gebruik van open API's. Twee vliegen in een klap dus!

Het is een vraag die in de zorg, maar ook daarbuiten, vaak speelt. Bij het stellen van een diagnose is bijvoorbeeld soms informatie van andere artsen zinvol. Denk aan een oude MRI-scan of een eerdere diagnose. Maar wie maakte die scan ook al weer, hoe lang geleden was dat eigenlijk, is die scan nog beschikbaar? Je kunt natuurlijk een rondje bellen, maar dat is veel werk en niet altijd even doelmatig. Elektronisch de vraag stellen aan alle zorgaanbieders kan ook, maar heeft nog al wat haken en ogen. Wat als een GGZ-instelling die vraag over mij zou stellen aan alle zorgaanbieders, of een verslavingskliniek? Alleen al de vraag stellen geeft meer prijs dan je lief is.

Datzelfde vraagstuk hadden we bij het maken van CoronaCheck. Als ik in de app mijn QR-code aanmaak dan bevraagt de app meerdere bronsystemen op vaccinatie-, test- en herstelgegevens van mij. Op dit moment gaat het om de GGD, het RIVM en ZKVI (het systeem dat gebruikt wordt door ziekenhuizen die bijvoorbeeld huisartsen en ambulancepersoneel uit de eigen regio vaccineren). CoronaCheck doet dat niet door het BSN te versturen, want dat levert het privacyprobleem op dat ook de verslavingskliniek van hiervoor zou hebben. Het pseudoniem van de persoonsgegevens dat wordt verstuurd kan alleen worden gemaakt als de bron ook gegevens over de persoon bevat. Daarmee kunnen de andere bronnen niet herleiden om wie het gaat.

In de DPIA is dat alsvolgt beschreven:

Met name voor de vaccinatiegegevens geldt dat de betrokkenen die de gegevens wil opvragen om een Bewijsmiddel aan te maken niet altijd weet in welke vaccinatieadministratie zijn of haar gegevens zijn opgenomen (omdat de eerste vaccinatie mogelijk in een andere administratie is opgenomen dan de tweede of omdat men niet goed weet onder wiens verantwoordelijkheid de vaccinatie is uitgevoerd). Om toch te kunnen zorgen dat de persoon kan beschikken over een EU DCC en Coronatoegangsbewijs is de volgende oplossing ontwikkeld. Na DigiD verificatie van de persoon wordt door middel van een gepseudonimiseerde bevraging van de relevante administraties, de vaccinatie‐/test‐/herstelgegevens van de gebruiker opgevraagd bij alle (potentieel) relevante partijen.

Met het BSN en van BRP‐gegevens (voornaam, geboortenaam en geboortedatum) wordt een cryptografische hash‐waarde berekend met behulp van het SHA‐256 algoritme. Omdat genoemde invoerdata een zekere mate van voorspelbaarheid heeft, is de maximale entropie van dit deel van de hash‐waarde niet de 256 bits die het SHA‐256 algoritme potentieel biedt, maar is deze gereduceerd tot ongeveer 58 bits in de meest conservatieve schatting, maar effectief waarschijnlijk 70 bits (dit heeft te maken met de structuur van het BSN, hoe uniek achternamen zijn en dat de geboortedata in een maximaal interval van 1906 tot 2021 zullen liggen). Om deze nog relatief lage entropie te adresseren wordt bij de berekening van de hash‐waarde een voor de zorgaanbieder unieke salt gebruikt (ook wel shared secret genoemd) die de entropie voor derden verhoogt evenredig aan de lengte van de salt.

Vooralsnog wordt uitgegaan van een totale entropie (voor derden die niet bekend zijn met de salt) van 384 bits of meer. Dit vormt samen de “UNOMI‐token”.

Ik vind dit een mooie oplossing om ook op andere plekken in de zorg te beproeven. Bijvoorbeeld om mijn Persoonlijke Gezondheidsomgeving te kunnen vullen met al mijn historische gegevens. Zo'n beproeving vergt wel een passende grondslag, want het gaat ook bij een pseudoniem nog steeds om een persoonsgegeven.

Meer weten over de technische oplossing? Die is beschreven op Github.

Een tijdje terug schreef ik een blog over waarom je algoritmen niet perse moet willen begrijpen. Die blog maakte veel reacties los. Veel daarvan kwam neer op: je snapt toch wel dat vooringenomenheid moet worden bestreden? Mijn antwoord daarop is: ja zeker wel! De vraag is alleen of je daarbij vooral het proces centraal moet stellen of juist de uitkomsten kritisch moet beschouwen.

Een voorbeeld. Als leidinggevende met een achtergrond waarin een dubbeltje niet snel een kwartje zou worden ben ik gespitst op vooringenomenheid in selectieprocessen. Gelukkig is daar steeds meer aandacht voor. Veel van die aandacht gaat naar het proces van selectie zonder vooroordelen (denk aan het weglaten van identificerende gegevens uit brieven en CV’s om de kans op vooringenomenheid te verkleinen).

Maar of een selectieproces zonder vooringenomenheid was kun je ook anders beoordelen, namelijk door de uitkomsten te beschouwen. De vertegenwoordiging van iedereen in de samenleving is best een goede graadmeter. Kort geleden veranderden veel vrouwen op LinkedIn hun naam tijdelijk in Peter. Ze deden dat om aandacht te vragen voor het feit dat er in 2022 nog steeds veel meer mannelijke dan vrouwelijke bestuurders zijn. Sterker nog, er zijn zelfs meer bestuurders die Peter heten dan dat er vrouwelijke bestuurders zijn. De uitkomsten van selectie zijn niet zonder vooroordelen, zo blijkt.

Ik ben er daarom voorstander van om ook eisen te stellen aan de uitkomsten van selectieprocessen. Bijvoorbeeld met een vrouwenquotum, maar eigenlijk breder nog namelijk door eisen te stellen aan inclusie in het algemeen.

Dat is ook de reden dat ik niet perse vind dat je algoritmen moet willen begrijpen. Het zijn de uitkomsten die tellen. Deze moeten zonder vooringenomenheid zijn. Dat is, wat mij betreft, misschien wel het belangrijkst om te blijven toetsen.

In de recent uitgebrachte Leidraad voor kwalitatieve diagnostische en prognostische toepassingen van AI in de zorg heeft dat een belangrijke plek gekregen. Net als bij andere medische interventies geldt ook bij het gebruik van AI in de zorg: het zijn de uitkomsten die tellen. In de leidraad wordt daarom beschreven hoe je de waarden van algoritmen in de zorg onderzoekt met ook aandacht voor bias in de werking.

Bij de externe validatie van het model dient men verder te kijken dan alleen naar de voorspelkracht en medische waarde. Ook evaluatie van eerlijkheid en bias is van groot belang. Ongelijke behandeling ontstaat meestal door een vorm van algoritmische bias

Verschillende vormen van algoritmische bias worden onderscheiden. Het begrippenkader van Suresh & Guttag en de daarin genoemde vormen van bias wordt daarbij toegepast.

Figuur met bias in AI

In de leidraad voor kwalitatieve diagnostische en prognostische toepassingen van AI in de zorg worden niet alleen de algoritmen maar vooral de effecten en uitkomsten onderwerp van onderzoek. Zoals de gezondheidsuitkomsten op de lange termijn en op de korte termijn, voor zowel het individu als de populatie.

Figuur beoordelen AI op uitkomsten Beoordelen van uitkomsten: dat is zoals in de gezondheidszorg interventies worden beoordeeld. Het voorkomen van ongewenste vooringenomenheid daarin telt daarmee ook. Dat geldt voor handelingen door mensen in de zorg, en ook voor algoritmen.

Daarom ben ik voorstander van het beoordelen van processen (van zowel mensen als algoritmen) op tenminste hun uitkomsten. En dus, om de cirkel rond te maken, van quota gericht op inclusiviteit bij selectieprocessen.

Ik ben slecht in schaken. Zelfs zo slecht dat ik zelden win. Als ik toch een beetje een kans wil hebben dan speel ik bij voorkeur tegen iemand die direct en precies kan uitleggen waarom een zet is gedaan. Want de kans dat zo iemand echt goed kan schaken, is niet zo groot.

Over hoe mensen beslissen is veel literatuur en er wordt nog steeds veel onderzoek naar gedaan. Beroemd onderzoek, ook in Nederland. Zo als dat van Adriaan de Groot. Een psycholoog die in 1946 cum laude promoveerde op “Het denken van den schaker”.

enter image description here

Ook in de zorg wordt veel onderzoek naar beslissen door zorgprofessionals gedaan. In het boek “Practical Decision Making in Health Care Ethics: Cases and Concepts” trof ik ook weer schaken als voorbeeld aan.

One way to grasp the difference between a rational choice strategy and a recognition-primed decision strategy is to think of how a computer plays a game of chess. The computer uses a rational choice strategy. It considers all the possible moves, then the opponent’s possible counter moves to these moves, then its possible moves after these counter moves, and so on. After comparing thousands of alternatives, it picks the best move.

This artificial intelligence is so powerful that good computer programs can now beat the best chess players. The beginning chess player, by the way, also relies on rational choice strategy. He compares the advantages and disadvantages of possible moves to find the best one. Of course his ability to compare moves and counter moves is far less than that of a computer. The expert player, on the other hand, relies chiefly on a recognition-primed decision approach. He perceives key patterns on the board, considers them rather briefly, and then makes his moves. He has neither the time nor the cognitive ability to calculate the huge number of possibilities implied by each move he could make.

Beslissingen nemen is bij mensen veel meer dan een rationeel afwegingsproces. Er zit, onder andere, veel patroonherkenning in. En het gaat, zowel bij experts als bij anderen, met regelmaat fout. Mooie voorbeelden daarvan, en waarom ze ontstaan, tref je aan in het boek “How doctors think”. Menselijke beslissers, zoals artsen, die een bepaald patroon vaak hebben gezien, delen een nieuw probleem dat er op lijkt al snel bij diezelfde groep in. “Availability heuristics” heet dat. Daniel Kahneman won voor die theorie in 2002 een Nobelprijs.

Als er niet alleen een rationeel afwegingsproces is, dan is het veel lastiger achteraf de keuze uit te leggen. Groopman, de schrijver van “How doctors think”, adviseert patiënten daarom vooral vragen te stellen die voorkomen dat fouten in het denken ongemerkt blijven. Vragen als “Kan het nog iets anders zijn?” of “Is er iets dat niet in het plaatje past?”. Vragen die de patroonherkenning uitdagen. Zijpad: omdat huisartsen minder in een specialistische tunnel zitten is Groopman fan van een eerste triage door huisartsen.

In het debat over algoritmen, en zeker over hun toepassing binnen de overheid, wordt – wat mij betreft - onterecht vooral de aandacht gericht op registers van algoritmen en het eisen van inzicht in hun werking. Dat kan bij simpele algoritmen, die eigenlijk rekenregels zijn. Zodra het complexer wordt, zoals in het geval van zelflerende algoritmen en patroonherkenning, wordt dat een stuk lastiger. Net als bij mensen. En het is ook helemaal niet nodig.

Als je niet alleen focust op de precieze werking van een algoritme, dan kom je op andere oplossingen. Ik noem er 3.

  1. Consultatie, second-opinion en redundantie
    Is de keuze echt lastig, dan wordt in de zorg vaak een collega geconsulteerd. Of, als de patiënt het initiatief neemt, een second-opinion gevraagd. In machines die het altijd moeten doen, denk aan ruimtevaartuigen, worden beslissingen vaak ook door meerdere systemen of algoritmen genomen. Ik vind het geen gek idee om dat voor gevoelige beslissingen op andere gebieden ook te doen. Dat kan op heel veel manieren. Door meerdere algoritmen tegelijk bijvoorbeeld, met steekproeven en second opinion door mensen of door bij voortduring te monitoren op onregelmatigheden en die te willen gebruiken om van te leren.
  2. Transparant leren en verbeteren op basis van uitkomsten
    In de zorg is het gebruikelijk geworden: de eigen uitkomsten gebruiken om van te leren en te verbeteren. Die uitkomsten geven inzicht in verschillen die relevant kunnen zijn. Tussen ziekenhuizen, of tussen groepen die ze behandelen. Dat kan ook op andere terreinen. Door uitkomsten te monitoren en onderzoek te doen naar gevonden verschillen kun je niet alleen individuele fouten vinden en waar mogelijk herstellen, maar ook structurele fouten repareren.
    Dat, overigens, is niet altijd eenvoudig. Er is bijvoorbeeld, begrijpelijk, veel weerstand tegen het gebruiken van nationaliteit of afkomst bij beslissingen. Ook in de zorg is men er voorzichtig mee. Maar het is in sommige gevallen een heel noodzakelijk gegeven. Uit onderzoek naar etniciteit en kanker, in de Verenigde Staten bijvoorbeeld, blijken er verschillen te bestaan tussen etnische groepen als het gaat om de uitkomsten van diagnose en behandeling van kanker. Verschillen die verklaard kunnen worden door allerlei factoren, zoals sociaal economische en culturele. Maar ook door genetische factoren. Nu steeds meer bekend wordt over genetische factoren van ziekte, en ook behandeling steeds persoonlijker wordt, is het vastleggen van dergelijke gegevens juist een vorm van goede zorg. Zoals bijvoorbeeld ook het aanbod van stamcellen wereldwijd sterk verschilt tussen regio’s, waardoor de kans op een passende behandeling afhangt van je afkomst. Verschillen in uitkomsten onderzoeken vergt daarom een open blik, transparantie en verantwoording.
  3. Ethische begeleiding
    En daarmee kom ik bij mijn derde punt: of het nu om mensen (dokters bijvoorbeeld) of algoritmen gaat, het is de inzet ervan die bepalend is. De bekende dooddoener: met een hamer kun je een spijker inslaan, maar ook een ander pijn doen. Bij de inzet van technologie als CoronaMelder is ethiek daarom voortdurend meegenomen. Dat deden we samen met prof. dr. ir Peter-Paul Verbeek. Met het ECP ontwikkelde hij de aanpak Begeleidingsethiek. Het ministerie van VWS ontwikkelde de daarop gebaseerde “handleiding aanpak begeleidingsethiek voor AI & digitale zorg”. Ethiek beperkt zich natuurlijk niet tot algoritmen. In de zorg is het gebruikelijk om nieuwe onderzoeken, bijvoorbeeld, altijd eerst van een medisch-ethische toetsing te voorzien.


Ik ben, dit alles overwegend, geen fan van een puur instrumentele benadering van AI en algoritmen. Een algoritmeregister en een volledige uitleg van een algoritme (als dat al mogelijk is) voegen niet zoveel toe. Niet in de zorg, niet in het openbaar bestuur. Het gaat om hoe we er mee omgaan. Om de waarborgen, de transparantie en de ethiek van de inzet. Als je je daarop richt kom je tot hele andere oplossingen. Oplossingen die, als je om je heen kijkt in sectoren als de gezondheidszorg, al lang bestaan en hun werking hebben bewezen.

PS
We hebben nog veel te doordenken, zoals terecht door Floor Terra opgemerkt. Denkrichtingen moeten kritisch worden beschouwd. Wat betekent het niet altijd kunnen uitleggen van een algoritme bijvoorbeeld voor het recht op controle van de verwerking en van correctie?

Rationele mensen en niet te vertrouwen algoritmen

In de gesprekken naar aanleiding van deze blog viel mij op dat vaak wordt gedacht dat mensen rationeel zijn en hun handelen kunnen uitleggen en algoritmen niet. Algoritmen zouden daarom met minder vertrouwen moeten worden bekeken. Dat onderscheid maak ik zelf niet. Beide vormen van handelen moeten, wat mij betreft, op dezelfde manier worden beschouwd. Of een diagnose nu door een dokter of een algoritme wordt gesteld: de eisen zijn hetzelfde. Ook omdat mensen niet zo rationeel en bewust handelen als soms wordt gedacht en algoritmen de kans op discriminatie daarom juist ook kunnen verkleinen.

Deze week heeft de Tweede Kamer, onder meer gesteund door Volt Nederland, Fractie Den Haan, PvdA, ChristenUnie, VVD en Pieter Omtzigt een motie aangenomen waarin staat dat de QR-code van positief geteste mensen moet worden geblokkeerd. Die QR-code kan een papieren bewijs zijn, maar ook een bewijs in de app.

Motie blokkeren QR codes na positieve test

Deze blog is geschreven naar aanleiding van deze aangenomen motie. Achter de op zich logische vraag schuilt namelijk een wereld aan dilemma's.

Op LinkedIn plaatste ik twee berichten en vroeg om mee te denken over oplossingen die rekening houden met onder meer privacy en informatieveiligheid. Een bericht over het blokkeren van papieren QR-codes na een positieve test en over het blokkeren van codes in de app zelf. In deze blog zijn beide onderwerpen samengevoegd. Reageren kan op LinkedIn.

Blokkeren van papieren codes

Bij het blokkeren van QR-codes denken veel mensen vooral aan CoronaCheck, de app. Maar meer dan 600.000 mensen hebben al per post hun bewijzen aangevraagd en veel andere mensen hebben een bewijs op papier van bijvoorbeeld hun huisarts gekregen. Daaronder zijn veel ouderen, mensen die minder digivaardig zijn en geholpen zijn door artsen en bibliotheken en mensen zonder burgerservicenummer. Los van alle andere aspecten van het blokkeren na positieve test (ook in de app) levert het blokkeren van papieren codes extra vraagstukken op.

Omdat een coronatoegangsbewijs bewust niet een-op-een aan een persoon is te koppelen, kan zo'n bewijs alleen worden geblokkeerd door ze nu eerst allemaal ongeldig te maken. Mensen moeten dan een nieuw bewijs aanvragen. Nieuwe bewijzen op papier zouden een persoonlijke code moeten hebben om ze bij het scannen aan de deur vanwege een recente positieve test te kunnen blokkeren (met alle risico's vandien).

Om na een positieve test te kunnen blokkeren bij het scannen zou er een publiek toegankelijke zwarte lijst van (codes van) positief geteste mensen moeten komen. Een lijst die voor iedereen beschikbaar is. Door het bestaan van zo'n zwarte lijst kan moedwillig de data van positieve testen verzameld worden en altijd bekend blijven dat iemand positief getest is geweest. Een dergelijke lijst kan ook gelekt worden. Zoals de lijst waar de Belgische Gegevensbeschermingsautoriteit nu onderzoek naar doet.

Maar wellicht overzie ik iets en heeft iemand een goede oplossing die wel meer privacy biedt en die het niet nodig maakt om alle uitgegeven papieren bewijzen te blokkeren?

Blokkeren van codes in de app

In de CoronaCheck-app worden QR-codes elke paar minuten gewijzigd. Daardoor ben je bijvoorbeeld niet te volgen voor scanners. Ook bevatten de binnenlandse coronatoegangsbewijzen niets dat tot jou herleidbaar is. Deze privacybeschermende maatregelen zijn ook wettelijk geborgd.

Natuurlijk kun je het vraagstuk van blokkeren op dezelfde manier oplossen als bij papieren bewijzen (met alle dilemma's van dien, zoals beschreven in de vorige post). Dan zou je alle huidige codes moeten intrekken, opnieuw moeten laten aanmaken en dan wel statisch maken. Maar dan geef je wel veel privacymaatregelen op. Stel je voor dat je het slimmer wilt doen, kan dat? Kun je CoronaCheck als het ware maken tot iets dat voorkomt dat je uit isolatie de kroeg in gaat en blijven voldoen aan eisen van toegankelijkheid, veiligheid en privacy? En moet je dat wel willen? Ik doe hierbij een beroep op jullie denkkracht.

Metafoor

In de passage hiervoor stond eerst "Kun je CoronaCheck als het ware maken tot iets dat een 'slimme enkelband' is" maar veel mensen namen aanstoot aan die metafoor die minder letterlijk moest worden genomen dan mensen deden.

Als u op deze blog bent gekomen omdat u bent verwezen door mensen die geen vertrouwen hebben in ambtenaren in het algemeen en die mij in het bijzonder niet veel goeds toewensen: er is geen complot. Voor een respectvol gesprek over de inhoud van deze blog sta ik altijd open.

De app is zo ontworpen dat er geen stiekem contact is met een database. De app weet ook niet wie jij bent. Je haalt zelf je vaccinatiegegevens of GGD-testgegevens op. Dat doe je met DigiD (alle communicatie is dus gebaseerd op pull, niet op push). Voor mensen zonder DigiD of burgerservicenummer zijn er papieren bewijzen, die kunnen worden ingeladen in de app.

Het toevoegen van een positieve test aan de app kan dus ook alleen uit eigen beweging. De app kan zo worden aangepast dat gebruikers, zeg een of twee keer per dag, verplicht worden om in te loggen met DigiD bij de GGD om te beoordelen of er een recente positieve test is. Als die gevonden wordt, dan kan de QR-code worden geblokkeerd.

Er zijn wel wat nadelen. Stel dat 10 miljoen mensen dat 2 keer per dag doen en iedereen ook 8 uur slaapt, dan zijn er tenminste 300 inlogpogingen per seconde. Dat is meer dan alle systemen aankunnen, dus er zijn mensen die hun code verliezen omdat ze geen contact krijgen. Maximaal 2,6 miljoen mensen per dag kunnen 1 keer inloggen. Daarmee verliezen de overige miljoenen mensen hun QR-code. De wel geslaagde inlogpogingen kosten alleen al aan DigiD-tikken meer dan 150.000 euro per dag. Je zou natuurlijk QR-codes kunnen laten vervallen en mensen vragen ze weer te activeren als ze op pad gaan. Maar dat levert veel pogingen op hetzelfde moment op (de avonden in het weekend bijvoorbeeld), leidt niet tot een prettige gebruikerservaring en waarschijnlijk tot meer gedoe bij de controle (als mensen de code niet hebben geactiveerd door nogmaals in te loggen met DigiD bij de GGD).

Een ander nadeel is dat alle mensen zonder DigiD of zonder burgerservicenummer na een dag hun QR-code in de app kwijt zijn. De oplossing is immers alleen geschikt voor mensen met DigiD dus zij kunnen geen bewijs ophalen van het niet hebben van een positieve test. Je sluit dus veel mensen uit.

Best wel wat consequenties dus. Maar misschien zie ik veel logischere oplossingen over het hoofd?

Tot slot

De Tweede Kamer heeft recent een Commissie Digitale Zaken ingesteld. Deze commissie omschrijft de aanleiding als volgt:

Digitalisering verandert onze samenleving radicaal. Nieuwe technologieën als kunstmatige intelligentie, algoritmen, Big Data, robotica, quantumcomputers, Internet of Things en de cloud hebben grote gevolgen, zeker in samenhang met elkaar. Deze ontwikkelingen gaan snel en hebben invloed op onder meer de werkgelegenheid, onze veiligheid, de democratie, onze privacy, de verhouding tussen burgers onderling, en tussen burgers en de overheid.

Het begrijpelijke verzoek dat een QR-code moet kunnen worden kunnen ingetrokken na een positieve test lijkt vooralsnog niet makkelijk realiseerbaar zonder concessies te doen aan waarden als privacy en laat zien hoe actueel de analyse van de commissie Digitale Zaken van de Tweede Kamer is.

Dit is een blog in een serie waarin ik vragen beantwoord over het wetsvoorstel “Wet elektronische gegevensuitwisseling in de zorg”. Een wetsvoorstel dat beoogt om stap voor stap de zorg te digitaliseren. Zodat faxen, brieven of DVD’s op de buik van een patiënt steeds minder voorkomen. Het is een wet waaronder gegevensuitwisselingen kunnen worden aangewezen die tenminste digitaal moeten verlopen. Dat kan op twee manieren. Door aan te wijzen dat ze elektronisch moeten verlopen (spoor 1 van de wet) of door ook aan te wijzen hoe, volgens welke norm, dat moet (spoor 2). Het is een wet waarover vragen zijn. In een serie blogs ga ik in op die vragen. Heb je ook een vraag? Laat deze gerust weten; via LinkedIn bijvoorbeeld.

Hoe verhoudt de Wegiz zicht tot de Wabpvz?

Na mijn eerdere blog over de Wegiz en toestemming kreeg ik veel vragen over de verhouding van het wetsvoorstel tot de Wet aanvullende bepaling verwerking persoonsgegevens in de zorg (Wabvpz). Deze wet regelt onder meer het recht op digitaal afschrift van de eigen medische gegevens en de verplichting om aan normen ten aanzien van informatiebeveiliging te voldoen.

Er is echter nog iets dat de Wabvpz regelt, en dat geldt voor uitwisselingssystemen. Als daarvan gebruik wordt gemaakt dan is vanwege de bepalingen in de Wabvpz toestemming nodig voor het ongericht raadpleegbaar maken van medische informatie. Nu doet het woord “uitwisselingssystemen” denken dat het hierbij gaat om alle gegevensuitwisseling in de zorg. Maar dat is dus niet zo. Het gaat om een specifieke technische inrichting, waarbij informatie ongericht raadpleegbaar wordt gemaakt voor andere zorgverleners. Als de uitwisseling technisch zo werkt, dan is de extra toestemming nodig. Die moet ook specifiek zijn. Iets als “ik geef aan mijn huisarts toestemming om mijn samengevatte gegevens opvraagbaar te maken door de huisartsenpost voor waarneming”.

De Wegiz bepaalt dat normen voor gegevensuitwisseling er voor moeten zorgen dat niet alleen via uitwisselingssystemen kan worden uitgewisseld. Want anders is voor mensen die geen toestemming geven voor beschikbaarstelling van hun informatie geen gegevensuitwisseling mogelijk, ook als er volgens de WGBO geen uitdrukkelijke toestemming nodig is.

Een recent voorbeeld illustreert waarom dat belangrijk is.

Naast de GGD en allerlei zorginstellingen vaccineren ook huisartsen mensen tegen COVID-19. Volgens de Europese verordening die het Digitaal Corona Certificaat (DCC) regelt, mogen ze die gegevens verwerken voor zo'n DCC. Daar is geen aparte toestemming meer voor nodig.

Maar er is op dit moment geen manier om die gegevens vanuit de CoronaCheck-app op te halen uit de gebruikte huisartsinformatiesystemen, anders dan via een uitwisselingssysteem. En dat mag niet, omdat de toestemming die gegeven is door mensen voor het raadpleegbaar maken van hun gegevens niet is gegeven voor dit doel. Daarnaast zou langs deze route ook niet voor iedereen informatie beschikbaar zijn.

Precies dit is de reden waarom (aldus de Wegiz) ook op een andere manier dan via uitwisselingssystemen (zoals bedoeld in de Wabvpz) moet kunnen worden uitgewisseld.

In een brief aan de Tweede Kamer is dat als volgt opgeschreven:

Eerder heb ik uw Kamer gemeld dat mogelijk ook vaccinatieregistraties bij huisartsen direct via CoronaCheck opvraagbaar zullen worden. De technologie van de meeste huisartsinformatiesystemen maakt directe aansluiting echter niet mogelijk. Hiervoor is een tijdelijke route via het Landelijk Schakelpunt (LSP) onderzocht die niet haalbaar is gebleken. In dit geval is namelijk sprake van een uitwisselingssysteem dat gegevens ongericht raadpleegbaar maakt. De toestemming die mensen hebben gegeven voor die beschikbaarstelling ziet op huisartswaarneming en niet op CoronaCheck, waardoor de gegevens niet voor dit doel mogen worden gebruikt. Hoewel er een juridische grondslag is voor het leveren van vaccinatiegegevens door huisartsen aan CoronaCheck, staat hier de technische wijze waarop die uitwisseling via het LSP zou worden vormgegeven de koppeling in de weg. Mochten bepaalde huisartsinformatiesystemen wel direct benaderbaar zijn voor CoronaCheck zal getracht worden met deze systemen alsnog een koppeling te realiseren.

Tot slot: het technische alternatief is er al. De systemen van de GGD en het RIVM worden bijvoorbeeld direct (via Internet) vanuit CoronaCheck bevraagd. Vandaar de laatste zin: zodra het kan zullen ook huisartsinformatiesystemen worden aangesloten.