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.