Gezonde Zorg

Organisatie en financiering van een kosteneffectieve,
patiënt- en zorgverlenersvriendelijke en faire zorg
A- A A+

Covid-19: de preventie (v. 0.6)

Deze pagina is in aanbouw, zie het versienummer (0.x). Nog niet alle geplande hoofdstukkken zijn gepubliceerd.

Inleiding

Ook als er snel een vaccin tegen de huidige corona virus disease (covid) ontwikkeld wordt, dient er een preventieprogramma opgesteld te worden. Er kan immers over twee jaar weer een pandemie — of Nederlandse epidemie — ontstaan, door een nieuw virus.

Zo'n programma zou lockdownmaatregelen zoveel mogelijk overbodig moeten maken, zelfs al zullen opeengepakte bijeenkomsten altijd als gevaarlijk beschouwd moeten worden. De volgende maatregelen zijn gericht op dat overbodig maken:

Test & trace-systeem

Bron- en contactonderzoek door de GGD

Eén vorm van test & trace (T&T) is het bron- en contactonderzoek door de GGD. Daarbij vraagt GGD-personeel aan een positief getest iemand met wie men in de afgelopen tijd allemaal contact heeft gehad, om vervolgens die contacten te benaderen.

Dat is een enorm arbeidsintensief systeem. Weliswaar stelt de GGD nu ruim voldoende capaciteit te hebben, maar daarbij gaat men uit van de relatief lage incidentiecijfers van begin mei. Als er een tweede besmettingsgolf komt bestaat de kans dat men het net als begin maart al heel snel niet meer kan bijbenen — de incidentiecijfers toen waren nog veel lager dan begin mei.

Verder moeten vraagtekens gesteld worden bij de gevoeligheid, want weinig mensen weten precies wie men in de afgelopen periode mogelijk heeft besmet.

Een keer onbeschermd niezen in een supermarkt kan al een paar vreemden hebben geïnfecteerd, en in een volgepakt café kunnen dat er makkelijk nog meer zijn. Als hoofdsysteem bij een snelgroeiende epidemie voldoet dat GGD-onderzoek dus niet. (Het is wel bruikbaar voor verpleeghuizen en andere woon-zorginstellingen, zie later.)

Een contactapp

Voor het T&T-hoofdsysteem is een betere optie: een contactapp. In ieder geval zou die als achtervangsysteem ontwikkeld moeten worden. Verderop wordt beschreven hoe die functioneel en privacyrespecterend geconstrueerd kan worden.

Echter, voor het overzicht eerst de verschillende soorten epidemieappfuncties die er zijn. Die kunnen gecombineerd worden, maar voor de duidelijkheid wordt uitgegaan van aparte apps:

De contactapp, zijn werkwijze en het systeem erachter zouden als volgt geconstrueerd moeten worden. Daarbij is gekozen voor de eenvoudigste constructie, omdat des te groter de begrijpelijkheid, des te groter het gebruik zal zijn.

  1. De broncodes van alle hiernavolgende zaken dienen openbaar gemaakt te maken (open source).
  2. De Rijksoverheid maakt een database aan met twee zaken: een lijst van (vele miljoenen) unieke ID-codes en een lege lijst waarop straks de ID-codes komen te staan van de houders die hebben aangegeven besmet te zijn geraakt (zie punt 7).
  3. Bij installatie van de app op de telefoon legt hij contact met de databaseserver en krijgt een ID-code toegewezen. De app hoeft daarvoor geen enkel persoons- of telefoongegeven naar de server te sturen en de server slaat geen enkel gegeven op. De toegewezen code wordt door de server van de lijst van beschikbare codes afgehaald, zodat de code uniek blijft.
  4. De app moet het recht krijgen om automatisch opgestart te worden als de telefoon opgestart wordt, en zo nodig bluetooth in te schakelen. Hij hoeft dan geen interface te tonen, maar zonder die rechten moet hij niet (opnieuw) geopend kunnen worden, want anders kan de gebruiker onterecht denken dat hij het doet.
  5. De app scant middels bluetooth welke andere gebruikers van de app in de buurt komen (duur en afstand nader te bepalen) en slaat — alleen — hun ID-codes op, op de telefoon. Apple en Google synchroniseren hun bluetoothsystemen al om dat ook tussen die twee soorten smartphones mogelijk te maken.
  6. De codes worden drie weken bewaard: de maximale incubatieperiode van twee weken plus een week test- en meldtijd (zie volgende punt). Voor extra privacy zouden ze nog kunnen worden gecodeerd, maar dat brengt een verhoogd risico op disfunctioneren met zich mee. Opslaan in een verborgen map zou een minder storingsgevoelige methode zijn.
  7. Als een appgebruiker van een arts te horen krijgt dat men (waarschijnlijk) drager is van het virus, krijgt men van de arts een TAN-code. Daarmee kan de gebruiker zijn toegewezen ID-code laten opnemen op de databaselijst van codes die besmet zijn geraakt. Daarbij worden door de server geen andere gegevens opgeslagen.
  8. De app haalt uit zichzelf dagelijks de lijst van besmettings-ID-codes op en vergelijkt die met de lijst van ID-codes die hij in de afgelopen drie weken opgeslagen heeft. Als er een (nieuwe) match is, krijgt de gebruiker een waarschuwing dat men zo snel mogelijk contact moet opnemen met de huisarts(enpost), en op basis van hoeveel matches dat is. De huisarts schrijft dan een testverwijzing uit, en tot de testuitslag terug is dient men in quarantaine te gaan.
  9. De apptaal dient omschakelbaar te zijn naar in ieder geval Engels, Marokkaans-Arabisch en Turks.

Zo'n app waarborgt de privacy en de telecomwet ervoor wijzigen hoeft niet. Er moeten echter nog wel vijf vragen beantwoord worden: a) wat te doen met thuiswonende mensen zonder smartphone, b) wat te doen met mensen in woon-zorginstellingen, c) hoe zorgt men ervoor dat voldoende mensen de app gaan installeren, d) kan de app ook grote groepen nabije mensen aan, zoals in een druk café?, en e) hoe de app's gevoeligheid te reguleren?

Mensen zonder smartphone

De thuiswonende mensen die nog geen smartphone hebben zullen bijna altijd ouderen zijn (jonge kinderen worden vooralsnog buiten beschouwing gelaten). Die zullen zich realiseren dat vooral zij behoren tot de risicogroepen. Van hen mag dus gevraagd worden er een aan te schaffen, ook omdat geschikte smartphones er al voor € 70 zijn.

Verder zijn de startschermen ervan zo in te stellen dat ook digibeten ermee om kunnen gaan. Als men met een TV-afstandsbediening kan omgaan, en met een normale telefoon, kan men ook leren met een smartphone om te gaan. Bovendien start de app zichzelf op bij het opstarten van de smartphone.

Mensen in woon-zorginstellingen

Binnen veel woon-zorginstellingen is een contactapp niet uitvoerbaar. Maar daar zou (wel) het bron- en contactonderzoeksysteem door de GGD kunnen worden ingezet. Dat zou daar wel uitvoerbaar zijn, door de veel beperktere groep mensen waarmee een besmet iemand contact heeft kunnen leggen.

En het zou ook nuttig zijn omdat bezoek dat mogelijk besmet is geraakt, of de oorzaak kan zijn van een besmetting, er in ieder geval mee gewaarschuwd kan worden.

Bevorderen/verplichten van de app

Gebruik van de app kan bevorderd worden door oproepen van alle politieke partijen aan hun kiezers, alle geloofsgenootschappen aan hun gelovigen, en alle verenigingen aan hun leden, om hem te gebruiken. Naast uiteraard een mediacampagne door de Rijksoverheid.

Verder zou een voorwaarde voor toegang tot een toegangscontroleerbare bijeenkomst moeten zijn dat men een smartphone met de geopende (= functionerende) app heeft. Dat gaat weliswaar in tegen de opdracht van de European Data Protection Board (EDPB), dat een contactapp altijd vrijwillig moet zijn, maar daarmee gaat de EDPB buiten zijn boekje.

Het orgaan mag eisen stellen aan persoonsdataverwerking, in dit geval dat die niet te herleiden zijn tot een persoon(lijke locatie) of een telefoon. Maar als aan die eis voldaan wordt, moet de EDPB het al dan niet verplicht stellen van zo'n app voor dergelijke bijeenkomsten overlaten aan de (normale) wetgever.

Net zoals die wetgever gaat over het verplicht bij zich hebben van een identiteitsbewijs, om maar een van de zeer vele wettelijke verplichtingen te noemen.

Kan de app zeer grote groepen aan?

Of de app grote groepen nabije mensen, zoals in een druk café, aankan, zal moeten blijken uit testen. Het is wel zo dat de huidige smartphones chips en een werkgeheugen hebben die 15 jaar geleden nog niet eens in een gemiddelde PC zaten.

Maar of ze ook met een grote stroom aan bluetoothdatapakketjes om kunnen gaan, zelfs al zijn dat telkens minuscuul kleine pakketjes (want slechts één ID-code), dat zal moeten blijken. Evenwel kunnen daarbij Apple en Google gevraagd worden om verbeteringen aan te brengen indien nodig.

En zelfs al zou dat nu nog niet werken op oudere smartphones kan de app toch al zeer nuttig zijn, want opeengepakte bijeenkomsten zullen pas als allerlaatste weer toegestaan worden. Immers, de supersnelle verspreiding tijdens het Brabantse carnaval zal veel eerder in de café's hebben plaatsgevonden dan in de buitenlucht.

Hoe de contactgevoeligheid te reguleren?

Alhoewel overgevoeligheid hier te preferen is boven ondergevoeligheid, dient de eerste ook zo veel mogelijk voorkomen te worden. Zoals impliciet al gesteld wordt de contactgevoeligheid bepaald door de twee volgende parameters:

Die twee variabelen houden automatisch al rekening met hoe druk het is, want des te meer mensen op een bepaalde oppervlakte, des te kleiner wordt de afstand en/of des te langer de contactduur. Er zijn echter nog twee belangrijke variabelen: hoe de luchtverversing is en het percentage aanwezigen dat een mondkapje draagt (zelfs een sjaal verkleint de kans dat men anderen besmet via speekselaerosolen).

Dat kan de app natuurlijk niet detecteren, maar de gebruiker wel. Daarom zou er een schuifje ingebouwd moeten worden waarmee de contactgevoeligheid kan worden ingesteld. Komt de gebruiker dan een ruimte binnen met slechte ventilatie waar niemand een mondkapje draagt, dan schuift h/zij het gevoeligheidsniveau naar 5 (zeer hoog risico).

De app zet dan de vereiste contactafstand en -duur om de ID-code van iemand anders op te slaan op maximaal resp. minimaal.

Mogelijk moet de API daarvoor aangepast worden, maar het zou niet moeilijk moeten zijn om Apple en Google van het nut van die optie te overtuigen. Ter verhoging van het gebruiksgemak zou nog ingebouwd moeten worden dat het schuifje na X uur automatisch terugschuift naar niveau 3 (medium risico), X ook in te stellen middels een schuifje.

Responsieve incidentiemonitor

Dagelijkse landelijke steekproef

Veel mensen, ook beleidsmakers, denken dat de invloed van (versoepeling van) de lockdownmaatregelen pas na drie weken zichtbaar wordt, aan het aantal gerelateerde ziekenhuisopnames per dag. Er zijn echter veel snellere manieren. De snelste manier is om dagelijks een landelijke representatieve steekproef te testen op aanwezigheid van het virus.

Dat hoeven niet steeds dezelfde mensen te zijn, maar de steekproef dient wel echt een steekproef te zijn. Dat wil zeggen dat ook mensen getest moeten worden die (nog) geen symptomen hebben of denken dat de symptomen die ze hebben niet komen door covid.

Dan heeft men een zeer accurate en zeer responsieve monitor, maar het vergt een enorm grote testcapaciteit. Uitgaande van maximale accuratesse (1% foutmarge, 99% betrouwbaarheidsinterval) en 17,3 mln mensen, moeten er dan dagelijks 16.500 mensen getest worden.

Er moeten elke dag ook nog andere mensen getest worden. Op zijn minst de volgende, en zij moeten voorrang krijgen:

In totaal zouden er dan elke dag minstens 91.500 mensen getest moeten worden. Nederland heeft mogelijk wel voldoende laboratoria daarvoor, maar voorlopig nog niet de testmaterialen en -afnamemankracht. Die zal op 1 juni maximaal 30.000 zijn.

Een dagelijkse en accurate landelijke steekproef is dus niet op korte termijn realiseerbaar. Evenwel hoeft het nog steeds niet telkens drie weken te duren voordat de incidentieverandering duidelijk wordt, want er zijn meer mogelijkheden.

De GGD-statistieken

Second best zou de incidentiestatistiek van de GGD zijn, verkregen door de virusdetectietesten die men doet. En zo lang iedereen met symptomen getest kan worden, inclusief cliënten in woon-zorginstellingen, is dat inderdaad ook de tweede beste optie.

Echter, de praktijk van begin maart liet zien dat de testcapaciteit al heel snel te klein was. De vraag naar testen was toen nog heel laag, en de cliënten in woon-zorginstellingen werden zelfs überhaupt nog niet getest.

Het risico bestaat dat met de versoepeling van de maatregelen per 1 juni, en vooral het weer toestaan van bijeenkomsten tot 100 man per 1 juli, er een tweede golf komt. Die makkelijk hoger kan zijn dan de eerste, omdat de gevallen in de woon-zorginstellingen nu wel meegeteld (moeten) worden.

Daardoor bestaat er een reëel risico dat GGD's het wederom niet kunnen bijbenen. Er is evenwel een achtervangsysteem mogelijk: het meldsysteem voor de huisartsen en artsen van woon-zorginstellingen (verder te noemen: instellingsartsen).

Meldsysteem van de huis- en instellingsartsen

Voor bepaalde ziekten, waaronder epidemieën, bestaat voor de huisartsen een meldplicht. Voor de ziektegevallen in woon-zorginstellingen bestaat eenzelfde plicht voor de instellingsartsen. In alle gevallen volstaat een numerieke melding, zonder de privacyproblematiek ook hier niet speelt. Zo nodig kan de herleidbaarheid tot praktijk of instelling worden omgevormd naar herleidbaarheid tot regio.

Misschien zou een van de systemen daarvoor opengesteld moeten worden voor de andere artsengroep. Of wellicht dient er zelfs een nieuw, gezamenlijk meldsysteem gecreëerd te worden. Maar dat zou door een team van IT-specialisten op korte termijn gerealiseerd moeten kunnen worden, want het gaat om vrij eenvoudige databasetechnieken.

Wel kan dit systeem een monitorvertraging van een week opleveren, want de gemiddelde incubatietijd van covid-19 is 5½ dag. Daarbij moet de patiënt nog gezien worden door een arts. Maar het kan toch flinke tijdwinst opleveren.

Mediacampagne door de Rijksoverheid

Voor zowel het systeem van de GGD-statiek als het meldsysteem van het huis- en instellingsartsen is het waarschijnlijk nodig dat de Rijksoverheid een mediacampagne opzet die mensen oproept om met relevante symptomen meteen contact op te nemen met de (huis)arts(enpost) of de GGD. Het is goed mogelijk dat veel mensen dat pas doen op het moment dat de symptomen ernstig worden, waar makkelijk nog een week overheen kan gaan.

Incidentieapps niet betrouwbaar

Er zijn ook apps die de (mogelijke) incidentie meten, zoals de COVID Radar-app van het Leids Universitair Medisch Centrum (LUMC). Die vraagt om de dag aan de gebruiker of men covidsymptomen heeft en zo ja, meldt dat aan een eigen databaseserver. Daarmee heeft het LUMC een eigen incidentiemonitor gecreëerd.

In zijn totaliteit is dat echter een onbetrouwbaar en ongewenst systeem:

  1. Na verloop van tijd zullen gebruikers moe worden van het elke twee dagen moeten beantwoorden van de vra(a)g(en).
  2. De server krijgt waarschijnlijk veel vals-positieve meldingen, want de gebruiker hoeft alleen maar door te geven of men symptomen heeft. Die hoeven niet veroorzaakt te worden door het coronavirus. Daar kan men op zich voor corrigeren, maar er zijn mogelijk forse verschillen in symptomenattributie tussen nauwelijks en zwaar getroffen gebieden.
  3. De incidentiecijfers van veel woon-zorginstellingen ontbreken omdat de bewoners ervan niet (goed) kunnen omgaan met een smartphone. Dat is een fatal flaw, want juist in die instellingen vallen veel slachtoffers.
  4. Er is een privacyprobleem: de locatie van de telefoon wordt doorgegeven op het moment dat iemand aangeeft symptomen te hebben. Dat lijkt een hard afwijzingscriterium voor de Autoriteit Persoonsgegevens te zijn, en zal op zijn best leiden tot statistisch te laag gebruik ervan in nauwelijks getroffen gebieden.

Verder heeft ook deze monitor een vertraging, van minimaal 5½ dag. Hij levert dus nauwelijks tijdwinstvoordeel op t.o.v. het artsenmeldsysteem.

Conclusie t.a.v. de apps

Een incidentiemonitorapp is niet zinvol, zelfs ongewenst want onbetrouwbaar. (Dus ook daarom geldt dat het wijzigen van de telecomwet niet nodig is.)

Maar een contactapp is wel zinvol, zelfs noodzakelijk, en een adviserende app is waarschijnlijk ook zinvol. Die kunnen gecombineerd worden in één, maar daarbij dient de bediening zeer eenvoudig te blijven. Anders zouden wellicht twee verschillende apps beter zijn.

Hygiëne- c.q. beschermingsmaatregelen

Dit hoofdstuk is nog niet gepubliceerd.

Boodschappendienst voor alle risicogroepen

Dit hoofdstuk is nog niet gepubliceerd.

Koortsscreening

Dit hoofdstuk is nog niet gepubliceerd.

Versiehistorie

Datum laatst bijgewerkt: 20-5-2020. Om server-technische redenen is de vroegste datum 10-6-2018. Voor meer informatie over de versienummering, zie Introductie. De woordafbreking op deze site is geautomatiseerd, wat fouten kan opleveren. Voor contactinformatie zie Colofon/contact/CV. Deze site is gecreëerd door Frank Conijn.