Inleiding

Uit betrouwbare bron in het kort

Binnen de overheid willen we waar mogelijk gebruikmaken van eerder vastgelegde gegevens. Zo hoeven we burgers en bedrijven geen informatie te vragen die we al hebben, en kunnen we processen efficiënter afhandelen. Denk bijvoorbeeld aan het vooraf invullen van gegevens bij een aanvraag, of aan het actief aanbieden van hulp bij veranderende omstandigheden.

In de praktijk gaat dat nog lang niet altijd goed. Gegevens worden vaak opnieuw uitgevraagd en opgeslagen. Dat leidt tot onnodig werk en een grotere kans op fouten. Daarom hanteren we als overheid een belangrijk principe: haal gegevens bij de bron.

Wie gegevens haalt bij de bron, moet kunnen vertrouwen op de kwaliteit ervan. Daarvoor is het essentieel om te weten waar een gegeven vandaan komt en waarom het is opgenomen of aangepast. Is een geboorteplaats bijvoorbeeld gebaseerd op een officiële akte, of op een verklaring van een burger zelf? Door herkomst en reden vast te leggen en mee te leveren, vergroten we het vertrouwen; niet alleen binnen de overheid, maar ook bij burgers en bedrijven.

Vaak gaan we ervan uit dat onze bronnen de waarheid bevatten. In werkelijkheid zijn gegevens soms onvolledig, onzeker of zelfs betwist. Helaas zijn onze bronnen hierop meestal niet goed ingericht. Twijfel is lastig vast te leggen en correcties zijn moeilijk door te voeren - zeker met terugwerkende kracht.

Het feit dat onze bronnen slecht omgaan met deze zogenaamde ‘crappy flow’, maakt dat zelfs een ogenschijnlijk kleine vergissing grote gevolgen kan hebben. Want terwijl een foute registratie zich zonder menselijke tussenkomst als een inktvlek over overheidsregisters verspreidt, lukt het in dat systeem van registers niet op eenduidige wijze twijfels over juistheid of correcties door te voeren. Mensen kunnen hierdoor onterecht diep in de schulden raken en moeten soms jarenlang procederen voor herstel. Helaas gebeurt dit vaker dan we denken.

Met ‘Uit betrouwbare bron’ onderzoeken we hoe je de techniek achter een bron - het register - op basis van begrijpelijke handelingen kunt inrichten. Daarbij hoort het zichtbaar maken van de herkomst en de reden van verwerking van gegevens. Bovendien zorgen we ervoor dat twijfel, onderzoek en correctie goed ondersteund worden – zowel in de bijhouding als in de levering van gegevens.

Door duidelijk te maken wat we wel en niet weten, en précies te laten zien welke gegevens - inclusief twijfel en correcties - we door de tijd heen hebben geleverd, creëren we bronnen waarop burgers, bedrijven en ambtenaren kunnen vertrouwen.

Aanleiding: registers kunnen beter

Beperkingen van bestaande registers

Bestaande registers kennen meestal één een conceptueel model, waarin een compromis is gesloten tussen behoeften van degenen die het register bijhouden en wensen van afnemers. Zo’n model wordt vervolgens vertaald naar een logisch en uiteindelijk een fysiek model voor een database. In dat laatste model komen we vaak constructies tegen voor het bijhouden van de aanleiding voor een registratie en bi-temporele historische inzage. Bij deze werkwijze en het register dat als resultaat daarvan ontstaat, kunnen op vier gebieden tekortkomingen aangewezen worden:

1. Het sluit niet optimaal aan bij de informatie-eenheden die bijhouders herkennen.
2. Het sluit niet optimaal aan bij de informatie-eenheden waarin afnemers geïnteresseerd zijn.
3. Het kan (in tegenstelling tot informatie-atomen) niet ondubbelzinnig historische toestanden verklaren.
4. Het is niet mogelijk om behalve met historie van ‘gewone’ toestanden óók goed om te gaan met complexere gevallen waarin we ook tijdlijnen en herkomst voor twijfel en correcties goed willen verklaren.

De valkuil van de ‘crappy flow’

Samen met collega’s verbonden aan onder andere het Federatief Datastelsel, Digilab en de Kafkabrigade keken we tijdens de ‘Dag van de toekomstige registraties’ en de ‘Dag van de toekomstige ketens’ diepgaand naar beperkingen van overheidsregisters: Aan de hand van tijdens die dagen besproken casussen vallen twee dingen op:

1. Onze registers verstrekken meestal de juiste informatie, maar het gaat ook vaker dan we ons realiseren fout, en
2. Als registers foute informatie verstrekken, is herstel heel moeilijk.

Registers zijn kortom slecht ingericht voor het omgaan met gevallen die niet volgens het boekje verlopen of waarin fouten moeten worden hersteld. We noemen deze tegenhangers voor de goed ondersteunde ‘happy flow’ de ‘crappy flow’. Dit inzicht leidt ertoe dat we bescheiden moeten zijn over wat we als overheid denken te weten. Onze registers moeten die bescheidenheid ondersteunen door ze te ontwerpen met ‘epistemische nederigheid’ in gedachten.

Bouwstenen voor betrouwbare registers

Architectuurbepalende aspecten

Epistemische nederigheid is een idee dat zich niet 1-2-3 naar programmacode laat omzetten. Om dat idee concreet te maken, hebben we een set functionaliteiten gedefinieerd. Die vormt het fundament vormt voor een betrouwbaar register. Omdat met deze set moet vrijwel overal in het ontwerp van een register rekening gehouden worden, noemen deze functies ook wel Architectuurbepalende aspecten (ABA’s) - of in het kort ‘aspecten’. We hebben de volgende aspecten geïdentificeerd:

• Herkomst, onderverdeeld in:
  • Bron: waar komt het gegeven vandaan?
  • Oorzaak: waarom is het gegeven opgenomen in de registratie of heeft dit gegeven geleid tot een wijziging van de administratie?
  • Verwerking: op welke wijze is het gegeven verwerkt (denk aan toegepaste algoritmen)?
• Registratie: op welk moment is het gegeven in het register opgenomen?
• Geldigheid: op welk moment is het gegeven van toepassing geworden en op welk moment was het gegeven niet langer van toepassing?
• Zekerheid: hoe zeker zijn we over dit gegeven?
• Doorhaling: op welk moment kwamen we erachter dat we dit eigenlijk niet hadden moeten of willen registreren?

Aanvullende uitgangspunten voor registerarchitectuur

Om bovengenoemde aspecten zo goed mogelijk tot hun recht te laten komen én om de tekortkomingen van bestaande registers op te lossen hanteren we voor registers een aantal aanvullende architectuuruitgangspunten:

• We scheiden bijhouding en levering.
• Bijhouding doen we op basis van functionele API’s. Deze API’s geven logische opdrachten - commando’s - aan het systeem die aansluiten bij de praktijk.
• Commando’s veroorzaken een verandering in het systeem. Die verandering – het gevolg – slaan we op.

Voorbeeld: onterecht geëmigreerd

De implicaties van een registerontwerp dat is gebaseerd op eerdergenoemde aspecten en architectuuruitgangspunten worden in onderstaand voorbeeld toegelicht.

Het voorbeeld toont bovenaan een zogenaamde bi-temporele tabel (in een variant die binnen de Nederlandse overheid regelmatig voorkomt). Daaronder zien we links een verzameling gebeurtenissen en rechts hoe die in een ‘ideaal’ register zouden worden verwerkt. Bovenstaande afbeelding toont dat ‘persoon p1 verhuisd is naar adres a1’ en dat dit ingegaan is op 5 april 2000.

In de tweede stap wordt geregistreerd dat persoon p1 geëmigreerd is. Omdat het begrip ‘verblijfsplaats’ in deze registratie is beperkt tot Nederlandse adressen, weten we niet langer waar deze persoon woont. Daarom beëindigen we het verblijfsadres. In de tabel lukt dit niet; we hebben hier geen einddatum, en dus voeren we een vrijwel lege rij op die als startdatum de beëindigingsdatum heeft.

Nu krijgen we te maken met een crappy flow. We hebben persoon p1 aan de balie en die geeft aan niet geëmigreerd te zijn. De gevolgen zijn ernstig. Huurtoeslag, zorgtoeslag en pensioenopbouw van p1 zijn plotseling gestopt. Aangezien er sprake is van ‘gerede twijfel’ - de persoon over wie het gaat staat immers aan onze balie - willen onmiddellijk duidelijk maken dat we de beëindiging van het adres gaan onderzoeken. Door dit ook te communiceren aan afnemers - zoals de dienst toeslagen - zou p1 in de ideale situatie weer aanspraak moeten kunnen maken op de toeslagen.

Uit het onderzoek blijkt dat er sprake is van een persoonsverwisseling. De emigratie is per abuis bij de verkeerde persoon geregistreerd. Als gevolg hiervan beëindigen we de twijfel – die is immers opgelost, en laten we de beëindiging op de adresregistratie vervallen.

Om te kunnen achterhalen waarom dingen binnen de overheid gebeurd zijn, willen we heel nauwkeurig zijn over wat op welk moment in het register bekend was. Het register moet dus kunnen vertellen dat we ooit dachten dat persoon p1 geëmigreerd was, we daaraan vervolgens twijfelden, en tenslotte de emigratie vanwege een registratiefout hebben laten vervallen.

Tegelijkertijd moet het register kunnen vertellen wat het gedurende die periode op basis van de werkelijke situatie had moeten vertellen, namelijk dat persoon p1 nooit geëmigreerd is en ‘gewoon’ op adres a1 woonde.

Innovatie: toepassing en onderzoek

‘Uit betrouwbare bron’ wordt uitgevoerd door een klein team met veel ervaring in ontwerp en de bouw van registers, en het uitwisselen van gegevens. Teamleden hebben in het verleden onder andere gewerkt aan de BRP, BAG, BRK, WOZ en de Polisadministratie van het UWV.

Uit betrouwbare bron bestaat uit twee sporen:

1. Bestaande patronen voor gegevensopslag toepassen en indien nodig aanpassen en uitbreiden om ze geschikt te maken voor toepassing in betrouwbare registers.
2. Nieuwe patronen ontwerpen en beproeven voor gegevensopslag in betrouwbare registers.

In spoor 1 kijken we naar bekende patronen zoals functionele API’s, event thinking, event sourcing en CQRS.

In spoor 2 doen we onderzoek naar nieuwe patronen. We kijken daarbij naar atomaire claims en annotaties (ACA) vanwege het sterke vermoeden dat deze belangrijk zijn voor het toekomstig ontwerp van betrouwbare registers.

Spoor 1: toepassing van event sourcing

Binnen spoor 1 hebben we het patroon van event sourcing als vertrekpunt genomen. Hiervoor hebben we gekozen omdat de manier van bijhouden goed aansluit bij de behoefte aan functionele API’s, terwijl het ‘append only’(niets verwijderen)-karakter de gevraagde betrouwbaarheid ondersteund. Heel in het kort verloopt dit patroon als volgt:

• Bijhouden start met een commando aan het register.
• Het commando wordt vertaald naar een of meer gevolgen (events).
• Deze gevolgen (events) vormen de basis voor leveringen.

Spoor 1 moet resulteren in een handreiking voor het ontwerpen van betrouwbare registers. Daarin hopen we vragen te beantwoorden zoals:

• In hoeverre zijn de commando’s en bijbehorende gevolgen (events) om ergens aan twijfelen, een onderzoek starten, iets corrigeren etc., te standaardiseren?
• Hoe kunnen we het afleiden van leveringsinformatie uit deze events (projecties) zo eenvoudig mogelijk maken?
• Wat is de beste manier om leveringen herhaalbaar te maken? Binnen event sourcing gebruikt met hiervoor de replay, maar die is waarschijnlijk in een betrouwbaar register niet betrouwbaar genoeg.

Het laatste punt verdient enige toelichting. De replay van events in een event sourcing omgeving gebeurt aan de hand van domeinspecifieke algoritmen. Maar het schrijven van dat soort algoritmen is – zeker als die (ook) crappy flows moeten ondersteunen – niet eenvoudig en dus foutgevoelig.

Hierboven bevat ons leveringsalgoritme (view generator) een bug. Als we zo’n bug repareren dan kunnen we niet meer reconstrueren wat we ooit geleverd hebben, tenzij we alle versies van alle algoritmen in de lucht houden en gebruiken bij reconstructie.

Spoor 2: onderzoek naar atomaire claims en annotaties (ACA)

Het hierboven beschreven replay-probleem zou kunnen worden opgelost door op een andere manier vast te leggen. De mogelijkheden hiervoor verkennen we in spoor 2, waar we de combinatie van events met atomaire claims en annotaties (ACA) beproeven.

Deze concepten hebben we in het emigratievoorbeeld hierboven al geïllustreerd, maar nog niet benoemd:

ACA is op dit moment het enige ons bekende patroon waarmee de semantiek van de crappy flow op een voorspelbare, gestructureerde en niet-redundante manier weer te geven, zonder de technische beperkingen die bijvoorbeeld een bi-temporele tabel met zich meebrengt.

Ook ACA bouwt voort op bestaande ideeën:

• Het atomaire gedachtengoed van de fact based modelingmethoden (die ook binnen DEMO en Wendbaar wetgeven toegepast worden).
• De zesde normaalvorm die in 2003 geïntroduceerd werd door o.a. Chris Date (mede grondlegger van de relationele theorie/database).
• De annotaties zoals die in RDF Star in 2014 geïntroduceerd werden (en helaas niet zijn overgenomen in RDF 1.2 basic).

Vanuit fact based modeling is het gebruikelijk om gegroepeerde structuren zoals tabellen, ster-schema’s en hiërarchische schema’s voor berichten met een algoritme samen te stellen uit de atomen. Je zou dit soort structuren kunnen zien als uit atomen opgebouwde moleculen.

Als dit ook lukt met de registerdata hebben we een algoritme dat zonder kennis van een domein projecties kan maken. We hoeven dit algoritme maar één keer te schrijven en heel goed te testen om het vervolgens toe te kunnen passen in allerlei domeinen.