Blog

Een Corona App: mijn aanzet tot een specificatie

De overheid wil met technologie het opsporen van met Coronavirus besmette personen faciliteren en verbeteren. In de volksmond heet die technologie “de Corona App”. Hier wordt uiteengezet wat de bedoeling is. De specificatie die ik kan vinden is

  • Slimme digitale oplossingen die kunnen voorzien in bron- en contactopsporing, in aanvulling op reguliere bron- en contactopsporing door GGD’en
  • Slimme digitale oplossingen die ondersteunen in de zelfmonitoring en begeleiding op afstand

Hierbij:

  • Het huidige proces van bron- en contactopsporing is uitgangspunt ter ondersteuning (REFF)

Deze specifidaties zijn erg abstract. Als een leverancier een oplossing voorstelt verwacht ik dat de leverancier alvorens code te gaan opleveren een specificatie oplevert die in iets meer detail zegt welk probleem er is en hoe dat probleem door hun systeem gaat worden opgelost. Ik verwacht ook suggesties aangaande wat er in de specificaties van het ministerie mist en hoe de leverancier missende specificaties invult. Ik heb weinig van dit alles gevonden in de zeven aanbiedingen die er afgelopen weekend zijn gedaan.

Vandaar dat ik hieronder een aanzet wil geven tot een specificatie voor een systeem (technologie, “app”) dat één van de problemen die het ministerie signaleert oplost en een mogelijke technische invulling van die oplossing.

Het probleem

Het corona virus verspreidt zich deels ongemerkt doordat het virus na besmetting de eerste dagen geen symptomen geeft maar de besmette persoon intussen wel anderen kan besmetten. Als je in staat bent besmettingen vroegtijdig op te sporen kun je maatregelen treffen (isoleren, medicijnen toedienen, etc) om de besmetting niet verder te laten gaan. Startpunt is een geconstateerde besmetting. Het probleem is “hoe spoor ik in zo kort mogelijke tijd iedereen op die door deze besmette persoon is besmet”. Los je dit probleem op dan kun je daarna besmette personen isoleren en/of behandelen. Je kunt dan ook de door deze nieuw besmette personen besmette andere personen opsporen. En verder.

Specificatie

Dit is wat ik zie als de specificatie, qua vorm en inhoud:

De overheid doet een aanbesteding voor een systeem dat

  • in staat is om op basis van één besmet persoon alle door deze persoon besmette andere personen op te sporen
  • hiertoe moeten alle mogelijke besmette personen geïdentificeerd worden waarna door tests daadwerkelijke besmetting kan worden vastgesteld
  • alle in het systeem voorkomende gegevens mogen niet te herleiden zijn tot personen, anders dan op de telefoon (of ander device) van de betrokken persoon
  • detectie van besmette personen na de besmetting genoemd in de eerste bullet dient binnen x uur plaats te vinden (x is b.v. 24 uur)
  • omdat het plannen en uitvoeren van een test al x uur duurt, dient detectie van mogelijke besmettingen binnen een uur plaats te vinden
  • omdat het plannen en uitvoeren van een test x uur duurt, dienen niet alleen de directe besmettingen vanuit de eerste persoon gedetecteerd te worden, maar dient onmiddellijk ook detectie van de tweede lijn van besmettingen in gang te worden gezet, zodat ook die binnen x tijd getest kunnen worden
  • parameters in het systeem als duur van een ontmoeting die gedetecteerd word, afstand van de ontmoeting en dergelijke, dienen centraal te kunnen worden ingesteld
  • er dient een analyse gemaakt te kunnen worden van de effectiviteit van ingestelde parameters en de succes-rate van de tests. Op basis van die analyse dient te kunnen worden vastgesteld wat de optimale waarden zijn voor parameters zodat geen besmettingen gemist worden en het aantal negatieve uitkomsten van tests wordt geminimaliseerd
  • het plannen en uitvoeren van tests is geen onderdeel van het aangeboden systeem

Ik heb hier een aantal punten opgesomd om een idee te geven op welk niveau van detail ik graag de specificatie zou zien. Uiteraard kan de inhoud heel anders zijn als het ministerie andere ideeën heeft.

Een mogelijke oplossing

Een app op een smartphone lijkt de aangewezen weg om het probleem aan te pakken. Gegeven de privacy-eisen lijkt het handig om gegevens locaal op een telefoon te bewaren. De app op de telefoon heeft middelen om de nabijheid van andere telefoons (personen dus) te detecteren en slaat de informatie over de ontmoeting op. Als de eigenaar van de telefoon wordt getest en besmet blijkt, moet de relevante data, dat wil zeggen alle ontmoetingen die potentieel tot nieuwe besmettingen hebben geleid, gedeeld worden met de betrokken mogelijk besmette personen. In verband met privacy zijn deze personen niet geïdentificeerd met een BSN of naam, maar met een anoniem nummer of ID. Er zijn diverse manieren om de informatie over de ontmoeting en mogelijke besmetting op de telefoon van de andere persoon te krijgen.

De mogelijk besmette persoon dient zelf actie te ondernemen om getest te worden, dit volgt uit de privacy eis dat er geen centrale instantie mag zijn die een ID kan koppelen aan een telefoon. Laat je deze eis vallen dan kan bij geconstateerde mogelijke besmetting de plaatselijke GGD worden ingelicht dat persoon X getest moet worden.

Aandachtspunt is de periode van mogelijke besmetting, van x dagen/uren voor de positieve test tot y dagen/uren voor/na de positieve test. Aandachtspunt is ook, als  persoon A besmet is en x dagen eerder heeft A persoon B ontmoet, wie heeft dan wie besmet? Dat kan voor de tijdlijnen verschil maken.

Een oplossing in meer detail

Als we de oplossing zoeken in een app (Android en iOS) dan moet die app het volgende doen:

  1. Vastleggen welke personen ik ontmoet onder besmet-omstandigheden (dat wil zeggen, omstandigheden waaronder die persoon mij kan besmetten of andersom)
  2. Detecteren dat ik ben besmet (bijvoorbeeld omdat ik dat de app vertel)
  3. De relevante contacten die ik heb ontmoet op de hoogte brengen dat ze mogelijk zijn besmet

1. Ontmoetingen

De app moet vaststellen dat ik persoon B heb ontmoet onder besmet-omstandigheden. Dat wil zeggen, gedurende X seconden in elkaars nabijheid op maximaal Y meter. Met een tijdstip. De app legt vast “persoonsID B, X seconden, Y meter afstand, tijdstip Z”. Die informatie blijft lokaal in de app.

2. Besmetting

Wordt ik bij de GGD getest, en de test is positief, dan voer ik dat in in de app. De app weet welke ontmoetingen nu relevant zijn: alle ontmoetingen in de laatste T tijd (met X seconden en Y meter). De app upload de lijst met ontmoetingen (ID B, tijdstip T) naar een server. De server slaat het op in een database.

3. Contacten inlichten

Om te weten of ik mogelijk besmet ben, moet mijn app weten wat er over mij in de database op de server is gemeld. Vanwege de privacy eisen kan de server mij dat niet laten weten want de server weet niet wie er bij mijn ID hoort. Dus moet mijn app iedere zoveel minuten/uren een ping naar de server doen met de vraag “ben ik mogelijk besmet?” waarbij alleen mijn ID wordt meegegeven. Dit moet gezien de specificaties minimaal eens per uur gebeuren.

Technisch

De app moet vaststellen wie ik wanneer ontmoet. Men lijkt ervan uit te gaan dat dit met bluetooth moet. In dat geval moet een telefoon permanent de omgeving scannen voor andere devices en aanwezige devices pollen voor een ID. Ik ga ervan uit dat dit kan zonder actief te pairen. Als er gepaird moet worden zie ik wel complicaties. Je kunt uit een bluetooth contact afleiden wat de afstand is, en je kunt met herhaalde pings de tijdsduur detecteren. Ik weet niet hoe nauwkeurig de afstandsbepaling is.

Je kunt detectie ook met wifi doen. Als je telefoon niet in een wifi netwerk hangt (je wandelt op straat bijvoorbeeld) kun je een wifi access point activeren zodat andere telefoons je kunnen detecteren, verbinding maken en ID’s uitwisselen. Als je telefoon wel in een wifi netwerk hangt, dan zit je hoogstwaarschijnlijk ergens binnen en zijn de andere mensen in het wifi netwerk te besmetten of besmettelijk.

Je kunt detectie met GPS doen maar bij direct contact via wifi of bluetooth is dat niet nodig en gaat het via een server dan doemen privacy issues op.

Bluetooth lijkt de handigste manier.

Management en analyse

Een besmet-ontmoeting vindt plaats op minder dan X meter gedurende minimaal Y seconden. X en Y worden bepaald door medische deskundigen, maar staan ter discussie. Ik stel voor om X en Y centraal instelbaar te maken, bij een ping die de app toch al doet kunnen X en Y in de app worden geupdate.

Ik zou overwegen om de gebruikers in te delen in groepen, waarbij je de in te stellen parameters kunt variëren per groep. Bijvoorbeeld, als de groepen A, B en C verschillende waarden van X hebben, en de groepen D, E en F verschillende waarden van Y, dan kun je een analyse maken van de succes rate. Dat wil zeggen, je kunt zien dat potentiële besmettingen in groep A 50% positief testen en in groep B 10%. Dat geeft je inzicht wat een juiste waarde is van X. Dit staat je toe een beleid te voeren: ik wil alleen mensen testen als we bijna zeker weten dat ze zijn besmet, of ik wil iedereen testen die in de verste verte mogelijk besmet is.

Koppeling van ID en telefoonnummer

Als de eis is dat “het systeem” mogelijk besmette personen inlicht, dan is het volgende mogelijk.

Je richt een server in met een API die onder beheer staat van een notaris. Deze server staat los van alle andere systemen in ons project. De API kan twee dingen:

  • registreer dat dit ID bij dit telefoonnummer hoort
  • meldt dat dit ID mogelijk is besmet

Het registreren gebeurt door de gebruiker bij installatie van de app, en kan optioneel zijn. Het melden gebeurt door de server die van mijn app na besmetting mijn lijst met mogelijk besmette ID’s ontvangt. Deze server kan via de API de notaris-server berichten sturen “dit ID is mogelijk besmet”. De notaris-server stuurt dan een pushbericht of SMS naar de betrokken persoon.

Kettingreactie

Krijgt een persoon te horen dat hij/zij mogelijk besmet is, dan wordt een afspraak gemaakt bij de GGD voor een corona-test. Dat duurt X tijd. Om sneller iedereen te bereiken, kun je willen dat deze persoon als mogelijke besmetting alvast zijn/haar contacten ook inlicht, op bovenbeschreven manier. Je kunt er ook voor kiezen dit alleen te doen voor contacten die lang in nabijheid zijn geweest op korte afstand.

Conclusie

De oplossing, c.q. het systeem, moet eerst in functionele zin worden beschreven. Daarnaast kan een indicatie worden gegeven hoe de technische invulling kan plaatsvinden. En daarbij dient proof of concept te worden gegeven voor deze technische invulling: bijvoorbeeld, je moet laten zien dat contact-detectie met bluetooth echt werkt.

Pas daarna dient sprake te zijn van het bouwen van een totale oplossing. Het is prima als die totale oplossing wordt gebouwd gelijk met de functionele beschrijving, maar dan moet de documentatie van de gebouwde oplossing voorzien in een goede functionele beschrijving alsmede van argumenten waarom de functionele en technische keuzen zijn gemaakt zoals ze zijn gemaakt.

Blog

Online lesgeven

Ik heb een site online gezet met Moodle, een online leer-omgeving, en daarmee BigBlueButton geïntegreerd. BigBlueButton is een videoconference omgeving net als Zoom of Jitsi, maar dan van goede kwaliteit, en niet open voor iedereen.

Later deze week zet ik instructies online hoe je een account kunt aanvragen om ermee te experimenteren. Als je deze omgeving voor je school dan wilt gebruiken, kunnen we zien of je daarvoor een eigen server nodig hebt (dan heb je alles voor je school alleen en geen pottekijkers) of dat we servers willen delen tussen scholen (dan kun je handig lesmaterialen uitwisselen).

Blog

Quantum rules in Rubik’s Cube

IMG_20200414_124653.jpg.resized

Rubik’s Cube was first sold in 1980. I was in college (University of Amsterdam, Astronomical Institute) about to graduate, when someone pointed all of us to a Martin Gardner article in Scientific American about the Rubik Cube. I bought the cube the next day and spent a weekend figuring it out. I never read the Gardner article beyond the introduction and the description of the cube, I wanted to figure this thing out myself. I found a number of algorithms that allowed me to change a minimum number of cubicles (the parts of the cube) at a time. This way, I thought I could solve the cube by adjusting the cubicles one by one. I found I couldn’t.

read more on Medium

 

Blog

Advies over Corona app

Android-Logo

Ik heb besloten twee adviezen te geven aan de Rijksoverheid aangaande de te bouwen Corona app. Zie hieronder. Ik ga niet zelf meedingen naar het project om apps te bouwen, ik heb de ervaring dat je daar als kleiner bedrijf toch niet voor in aanmerking komt.

Ten eerste.
De meeste ideeën die rondzoemen over Corona apps gaan over bluetooth. Daarmee detecteer je dat twee mensen binnen een afstand van x meter van elkaar zijn geweest op tijdstip y. Een corona besmetting treedt niet zo gauw op als je elkaar in de buitenlucht passeert op enige afstand, 5 meter of zo. Een besmetting treedt wel op als je een kwartier dichtbij elkaar in de tram zit. Een bluetooth detectie moet dus verder gaan dan alleen contact vaststellen, die moet ook bepalen hoe groot de afstand is geweest en hoe lang de nabijheid van beide personen heeft geduurd. Gebeurt dat niet dan kan het gevolg zijn dat er een enorme hoeveelheid “contacten” onderzocht moeten worden op besmetting terwijl je had kunnen weten dat 80% daarvan (buitenlucht, enige afstand) zeer waarschijnlijk niet is besmet.
Met een gps oplossing die centraal anoniem registreert is gemakkelijker vast te stellen hoe het contact is geweest en hoe groot de waarschijnlijkheid van besmetting is.
Ten tweede.
Een decentrale bluetooth-oplossing gaat er van uit dat iemand die positief is getest op Corona zelf in de app het initiatief neemt anderen in te lichten. Maar:

  • als iemand zojuist heeft gehoord besmet te zijn met Corona, gaat zo iemand dan onmiddellijk met de app anderen op de hoogte brengen? Of belt zo iemand eerst familie en vrienden en gaat er kostbare tijd verloren?- Als via de app contacten op de hoogte worden gebracht, kan dat niet via bluetooth omdat al die anderen niet steeds dichtbij zijn. Dat moet dus wel via een centrale server.
  • Mensen die in contact zijn geweest met een besmet persoon krijgen dan een bericht daarover. Een deel van de mensen heeft de telefoon niet aan, een deel ziet het bericht maar reageert niet, en een deel laat zich testen.
  • Een persoon die zich laat testen doet dat onmiddellijk, of na een paar dagen. De test duurt een dag. Dus na een paar dagen is een nieuwe besmetting bekend, waarna het circus via de app zich opnieuw afspeelt.
  • Voor iedere “kring” van mogelijk besmette personen gaan er dagen overheen. Het kan weken duren voor dat alle eerste/tweede/derdelijns/etc besmettingen zijn opgespoord. “Alle” in de zin van “alle mensen die zelf reageren op het besmettingsbericht”.

Een oplossing waarbij “contactpunten” (dwz, “persoon 2348958 heeft op tijdstip x persoon 9485442 ontmoet gedurende y seconden”) centraal anoniem worden opgeslagen, werkt veel sneller. Immers, zodra persoon y besmet blijkt, gaat een programma op de server alle contacten na in de eerste/tweede/derde/etc lijn en stuurt berichten naar al deze personen met het verzoek zich te laten testen. Dan duurt het geen weken voordat alle besmettingen vanuit één startpunt bekend zijn, maar hooguit twee of drie dagen.

Als alleen “contactpunten” worden geupload vanuit de app, is er geen privacy issue. Wel moet de app een pushbericht enablen zodat de server op basis van het anonieme ID (het nummer) een pushbericht kan sturen “u bent mogelijk besmet, neem onmiddelijk contact op”.

Blog

Online lesomgeving

Ik ben aan het experimenteren met sofware en servers voor online lesgeven. Het lijkt er nu op dat BigBlueButton het handigst is voor de conferencing, en Moodle voor de lessen zelf. BBB doet videoconferencing, maar ook scherm delen, blackboard, video delen e.d. Met Moodle kun je lessen maken in diverse formaten. Dus met die twee samen kun je met Moodle een les volgen, allemaal samen of individueel, en tegelijk eroverheen met BBB samen of met de docent communiceren.

Als je wilt uitproberen, stuur me dan even een mailtje, ik heb een Moodle server en een BBB server in de cloud geïnstalleerd.