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.