Direct naar content

Whitepaper Fieldlab Proactieve Dienstverlening

Fieldlab Proactieve Dienstverlening

Proactief zorgtoeslag aanbieden
bij de levensgebeurtenis 18 jaar worden
in een toekomstig Federatief Datastelsel

9, 10 en 11 december te Utrecht

Overzicht

Aliza.tekofsky@ictu.nl
Strategisch adviseur Digilab

Roos.degroot@vng.nl
Product Owner Digilab

Samenvatting en aanbevelingen

De overheid is te complex geworden

Regelingen - en vooral de gecombineerde effecten van regelingen - zijn zo complex geworden, dat burgers en overheid ze niet meer kunnen overzien. Het ophalen van de juiste gegevens en deze combineren met de juiste regels, is een puzzel die voor de gemiddelde burger steeds lastiger te leggen is.

Proactieve dienstverlening is een manier om complexiteitsreductie voor rekening van de overheid te laten komen, en de baten bij de burger te laten landen. Met name voor mensen in een kwetsbare positie, maakt dat verschil. Zij zijn de eersten die de weg kwijtraken in een woud van regelingen en gegevens. Zij zullen bijvoorbeeld toeslagen waar zij wel recht op hebben niet verzilveren, omdat ze de gevolgen niet kunnen overzien en de benodigde gegevens moeilijk kunnen vergaren.

Standaarden kunnen bijdragen om de complexiteit te reduceren

In het Fieldlab hebben we onderzocht hoe we op de fundamenten van een federatief datastelsel, met verantwoorde, gestandaardiseerde uitwisseling van gegevens, proactieve diensten kunnen bouwen. De case daarvoor was een jongere die 18 wordt en proactief zorgtoeslag krijgt aangeboden. Hiervoor is een fictieve keten opgezet met de betrokken organisaties, en alle fictieve organisaties maakten gebruik van dezelfde standaarden:

Federatieve Service Connectiviteit

Standaard die zorgt voor veilige gegevensuitwisseling tussen (overheids)diensten. Zorgt dat koppelingen standaard en flexibel zijn, combineert met Federatieve ToegangsVerlening (FTV) en Logboek DataVerwerkingen (LDV).

Federatieve Toegangsverlening

Zorgt dat toegangsverlening via Policy Based Acces Control (PBAC) onder de juiste voorwaarden gebeurt, werkt samen met FSC en LDV

Logboek Dataverwerkingen

Zorgt dat gegevensverwerkingen eenduidig worden vastgelegd en onderling – ook over organisaties heen, relateerbaar zijn.; doordat iedereen deze standaard gebruikt, zijn logs te combineren en kan het gegevengebruik door de keten verantwoord worden.

Cloud Events standaard

Message queue op basis van Cloud Events-standaard. Zorgt voor realtime berichten bij wijzigingen. Fieldlab implementatie met NATS message queue, organisaties bepalen zelf hun abonnementen

REST API standaard

Een lijst afspraken die ontwikkelaars volgen tijdens het bouwen van een REST-API voor de publieke sector. Door de regels te hanteren wordt de API voorspelbaar.

Overige beproefde standaarden en technieken

Op bovenstaande fictieve keten zijn aanvullend diverse standaarden en technieken beproefd:

Wettelijke regels naar machine-leesbare code omzetten schept mogelijkheden

Tijdens het Fieldlab is tevens geëxperimenteerd met het vertalen van wetten naar machine-uitvoerbare regels. Dit heeft een aantal voordelen:

Juridisch-beleidsmatig track

Het Fieldlab onderzocht de juridische basis voor proactieve dienstverlening met zorgtoeslag voor 18-jarigen als casus. Voor toeslagen bestaat in de Algemene wet inkomensafhankelijke regelingen een juridische basis voor het voor-ingevuld aanbieden van aanvragen. Op basis van bekende gegevens toekennen en uitbetalen kan niet, omdat een toeslag door de betrokkene moet worden aangevraagd.

Daarnaast is gekeken naar de mogelijkheden om te zorgen dat echt alleen gegevens die noodzakelijk zijn voor voorinvullen/toekennen worden afgenomen uit beschikbare bronnen. Het formuleren van juridische policies hiervoor - regels die bij Federatieve Toegang geautomatiseerd gecheckt kunnen worden - was een (te) grote uitdaging, die nog verder opgepakt wordt in de inmiddels ingestelde werkgroep Federatieve toegang. In de loop van het Fieldlab kwamen meer juridische vragen op, maar het track was na de eerste dag onderbezet.

Overall merkten we dat er vooral meer gecombineerd juridisch-technisch denkwerk nodig is. Dus geen aparte track, maar juristen die meelopen bij andere tracks.

Conclusies

  1. Multidisciplinaire samenwerking tussen juristen, beleidsmakers en technici is essentieel en zou structureel moeten zijn.
  2. Toetsing van aannames over en weer is cruciaal (voorbeeld: worden gegevens opgeslagen of zonder opslag gebruikt?)
  3. Voor proactief aanbieden zonder aanvraag is wijziging van sectorwetgeving (die vrijwel altijd uitgaan van een aanvraag) nodig.
  4. Het aanbieden rechtstreeks vanuit de bron bij en aan de burger is een ander patroon dan het verzamelen door een overheidsorganisatie en vervolgens aanbieden van de uitkomst aan de burger. Dit patroon is nog niet beoordeeld en biedt nieuwe mogelijkheden. Zie ‘Van Wet naar Digitale Werking’ hierboven en Vorderingenoverzicht Rijk die volgens dit patroon (rechtstreeks van de bron naar de burger) werken.
  5. Technische uitwerking van scenario’s is een must voor juridisch-beleidsmatige toetsing. Zie het hoofdstuk Uitbreiding Scenario voor een voorbeeld: de implicaties en vragen bij het wetswijzigingsscenario in combinatie met een correctie in de registratie.

Dit zijn de 10 belangrijkste lessen uit dit Fieldlab

  1. Werk samen met “the Whole System in the Room”
    • Breng beleidsmakers, juristen, inhoudsexperts, architecten en ontwikkelaars fysiek samen om samen te bouwen.
    • Deelnemers noemden ‘samenwerking’ unaniem als grootste meerwaarde van het Fieldlab en zouden graag vaker zo werken.
  2. Werk volgens (FDS-)standaarden en ontwikkel mee aan toekomstige standaarden
  1. Werken volgens deze nieuwe standaarden vraagt meer dan een technische omslag
    • Ook mindset, beleidsinhoud en transparantie moeten veranderen, inclusief een nieuwe locus of control.
  2. Ontwerp beleid op basis van PoCs en scenario’s
    • Zonder PoCs blijven implicaties van proactieve diensten onderbelicht.
    • Scenario’s helpen de effecten van keuzes in kaart te brengen en scherper af te wegen.
  3. Denk na over de feedbackloop in het proces
    • Correcties en bezwaren moeten mogelijk zijn: tweerichtingsverkeer is essentieel.
  4. Beheer historie bij de bron
    • Zorg dat wijzigingen kunnen worden doorgevoerd zonder historisch verloop te verliezen.
  5. Digitale proactieve dienstverlening vereist directe gegevens- en regeltoegang
    • Een combinatie van brongegevens en regels-als-code rechtstreeks gebaseerd op de bron (wet) ontbreekt nog.
  6. De huidige werkwijze is ongeschikt voor grootschalige proactieve diensten
    • Te traag & inefficiënt: één-op-één afspraken werken onvoldoende; een federatief afsprakenstelsel is nodig.
    • Te onbetrouwbaar: te veel kopieën en onvoldoende verwerking van wijzigingen.
    • Te weinig waarborgen: gebrekkige transparantie, logging en correctiemogelijkheden.
  7. Wetgeving is nu aanvraag-gebaseerd, maar biedt al mogelijkheden
    • Voor brede invoering van proactief datadelen moet wetgeving veranderen (van aanvragen naar proactieve diensten).
    • Tot die tijd (en ook daarna) verdient het onderzoek om proactieve dienstverlening via de burger zelf te laten verlopen, zonder datadeling tussen overheden.
  8. Ga vooral DOEN:
    • Voer zelf een proef uit (bijvoorbeeld met Digilab).
    • Start met ontsluiting van Data bij de Bron via API’s.
    • Start met implementatie van vastgestelde standaarden.
    • Werk samen aan de standaarden van de toekomst (bijvoorbeeld bij Digilab).
    • Gebruik de mogelijkheden die er nu al zijn, om proactief diensten aan te bieden.

En doe vooral mee met ons volgende Fieldlab, of organiseer er zelf één.

Aanleiding onderwerp

Het initiatief om gebruik te maken van bepaalde dienstverlening ligt nu volledig bij de burger en ondernemer. Zo wees een onderzoek in 2018 uit dat 230.000 seniorenhuishoudens mogelijk hun zorg- of huurtoeslag misliepen.

De Nederlandse overheid streeft naar de verbetering op lopende levensgebeurtenissen, waaronder ’18 jaar worden’.[1] Dit kan o.a. bereikt worden door het moderniseren van de huidige Generieke Digitale Infrastructuur (GDI): van een GDI op basis van overwegend centrale voorzieningen naar een GDI van overwegend standaarden en kleinere, herbruikbare componenten op basis van open source die door alle overheidsorganisaties gebruikt worden. Dit is onderdeel uit van het Meerjarenprogramma Infrastructuur Digitale Overheid (MIDO).

Uitgangspunten van een fieldlab

Er liggen forse ambities als het gaat om verantwoord datagebruik. Realisatie van de interbestuurlijke datastrategie (IBDS) met het Federatief Datastelsel (FDS) vergt interbestuurlijke samenwerking en een zekere urgentie.

Een fieldlab heeft een belangrijk verbindend karakter: de werkvorm brengt kennis, kunde en netwerken bij elkaar. Vanuit Rijk, gemeenten, provincies, waterschappen en uitvoeringsorganisaties. Het bevordert interbestuurlijke samenwerking, enthousiasmeert, inspireert en zet aan tot vernieuwing.

Dit fieldlab fungeerde als technische ‘pressure cooker’, waarbij in een ‘proof of concept’-omgeving vrijuit geëxperimenteerd kan worden met nieuwe technieken die bijdragen aan het gemeenschappelijke doel en de gemeenschappelijke case. Denk hierbij aan:

Voorbehouden:

Technische uitgangspunten voor deze case tijdens het fieldlab

Voor het mogelijk maken van proactieve dienstverlening binnen Het Federatief Datastelsel is technische interoperabiliteit en gegevensdeling één van de randvoorwaarden.

Daarbij is het wenselijk dat:

Tijdens dit fieldlab onderzochten we samen met juristen wat kan en mag, of waar aanpassingen nodig zijn. De juridische bevindingen vormen ook onderdeel van deze beschouwing, in ‘het juridisch- beleidsmatig track’ p.14.

Uitgangspunten van het Federatief Datastelsel

Door data, waar we als overheid toch al over beschikken, effectief meervoudig in te zetten, wordt het publieke belang beter bediend.

Het Federatief Datastelsel wordt een Nederlands vertrouwensraamwerk voor cross-sectorale datadeling tussen organisaties met wettelijke taken. Je kunt het zien als het data-ecosysteem van de Nederlandse overheid. Het raamwerk bestaat uit afspraken, standaarden, stelselfuncties en voorzieningen.

Technische interoperabiliteit is een randvoorwaarde voor het Federatief Datastelsel. Het Federatief Datastelsel wil deze interoperabiliteit bevorderen door het gebruik van standaarden. Deze standaarden worden ontwikkeld en beproefd in samenwerking met Digilab.

Digilab is het technische innovatielab voor de IBDS en FDS. Binnen Digilab werkt met het techteam en met andere overheidsprojecten aan de ontbrekende technische puzzels die er nodig zijn voor technische interoperabiliteit, datadeling en datagebruik met de uitgangspunten van Common ground.

Digilab en de projecten op Digilab ontwikkelen proof of concepts om te toetsen of de beoogde standaarden kunnen werken en hoe die in samenhang geïmplementeerd zouden kunnen. Het is de plek waar tijdens ontwikkeling van beleid, technisch gevalideerd wordt of dat beleid in de praktijk goed kan werken.

Het project Federatief Datastelsel is onderdeel van het programma Interbestuurlijke samenwerking (IBDS). IBDS streeft naar verantwoorde inzet van data voor maatschappelijke opgave0n en draagt daarmee bij aan de doelen van het programma Werk aan Uitvoering (WaU) en de werkagenda Waardengedreven Digitaliseren.

Het programma Realisatie IBDS kent 4 pijlers met verschillende (complementaire) projecten. Gericht op Wat Mag, Wat Kan, Wat Helpt en Wat Inspireert bij datadeling en -gebruik. IBDS is er om binnen de overheid verantwoord met data te werken. Het gebruikt daarvoor use cases met maatschappelijke waarde. Dat vergt samenwerking, slim hergebruiken en doorontwikkelen van dat wat er al is. Het programma Interbestuurlijke Datastrategie was opdrachtgever voor dit fieldlab.

Startscenario: Jael wordt 18 jaar

Uitbreiding scenario

Het is mei 2024.
Jael is inmiddels 20 jaar en na haar 18e gaan studeren.
Ze ontvangt een thuiswonende studiebeurs van Fictieve DUO.
De studiebeurs telde toen Jael ging studeren nog niet mee als inkomen om zorgtoeslag te berekenen (in overeenstemming met de huidige, echte wetgeving).

Wetswijziging: studiebeurs wordt gift

Op het Fieldlab is op dag twee een wetswijziging doorgevoerd, met ingangsdatum 1 januari 2024. Waar de studiebeurs in de eerdere wetgeving niet meetelde als inkomen voor de zorgtoeslag, is dit op de tweede dag van in het Fieldlab veranderd. De studiebeurs werd per 1 januari 2024 een gift en als zodanig opgeteld bij het inkomen dat meetelt voor de zorgtoeslag.

Wetswijziging studiebeurs

Jael blijkt toch uitwonend

Er is meer nieuws. Eind mei 2024 blijkt dat Jael toch al 10 maanden uit huis is. Jael kreeg toen al 10 maanden lang studiebeurs (2023)/-gift (2024) voor thuiswonende studenten (dus ook tijdens de oude wetgeving vóór 1 januari 2024).

De volgende correcties vinden automatisch plaats:

Uitbreiding scenario: beleidskeuzes, correcties, betalingsregeling

Hoe zorgen we dat de invoering van de wet goed gaat?

Voorwaarden

  1. de juiste geldende rekenregels voor de juiste maand worden gebruikt in de herberekening en
  2. dat het Fictief Duo register met de studiegift zowel formele als materiële historische feiten kan ophoesten. Met andere woorden: hoe stond het geregistreerd destijds, en wat weten we nu over die periode?

Gebruikte technieken
Technieken die deze uitbreiding mogelijk maakten:

Doordat de algoritmes gebaseerd zijn op een bepaalde wet, die op een bepaald moment is ingegaan èn in het register van DUO wordt aangegeven per wanneer de student uit- of thuiswonend was, kan automatisch met terugwerkende kracht berekend worden hoeveel de studiegift had moeten zijn.

De VO-Rijk casus toont voordelen van een interoperabel en adaptief stelsel

Vervolgvragen

Juridisch-beleidsmatig track

Tijdens het Fieldlab is op dag 1 en - in kleinere bezetting - ook op dag 3 een juridisch track samengekomen. De juristen hebben zich de eerste dag vooral gebogen over de vraag: welke juridische basis is er in deze casus voor gegevensuitwisseling? Specifiek voor de zorgtoeslag leek het aanbieden van een voor-ingevulde aanvraag mogelijk een grondslag te zijn (artikel 15, lid 7 Awir). Dit is echter specifiek voor deze casus en niet uit te breiden naar iedere vorm van proactieve diensten.

Juridisch Kader: Proactief Aanbieden van Zorgtoeslag

Waarom een juridisch kader?

De overheid voert alleen die taken uit die voorafgaand en expliciet in de wet zijn vastgelegd. En alleen voor die taken mogen (persoons)gegevens verwerkt worden (grondslag): Daarom zijn vooraf expliciet vastgelegde wettelijke taken, bevoegdheden en grondslagen essentieel.

Voor de onderhavige casus betekent dit dat voor alle handelingen die door de overheid worden verricht, een wettelijke basis aanwezig moet zijn.

Wettelijke basis

Analyse: Welke gegevens zijn nodig?

In Fieldlab ingericht proces: Alleen berekening tonen.
Toekomstig proces: Ook aanvraagknop beschikbaar maken met vooraf ingevuld formulier.

Vragen & aandachtspunten

  1. Gegevens automatisch naar Toeslagen laten gaan?
    1. Nu gebeurt dit alleen desgevraagd (artikel 38a, lid 1).
    2. Is artikel 15, lid 7 Awir voldoende? Beleid moet ‘vermoedelijk recht’ definiëren.
  2. Hoe controleert een afnemer de grondslag voor gegevensverzoeken?
    1. Policy moet vastleggen hoe gegevens rechtmatig opgevraagd worden.
    2. Voorbeeld: Toeslagen vraagt geslacht op, maar dit is niet nodig voor zorgtoeslag. Hoe te voorkomen? Antwoord: dit ligt besloten in de zorgtoeslagberekening, deze maakt geen gebruik van irrelevante gegevens (er is geen sluis voor om het even welke gegevens ingericht).
    3. Logging & auditsystemen nodig om achteraf te controleren.
  3. Wat als de aanvraag later wordt ingediend?
    1. Moet opnieuw getoetst worden aan actuele gegevens?
    2. Alternatief: werken met plateaus (attenderen → aanvraag → uitbetaling).
    3. Zijn actuele gegevens altijd beschikbaar? Of is een jaarlijkse toetsing praktischer?
  4. Worden gegevens opgeslagen?
    1. Nee, ze worden opgehaald en gebruikt, maar niet bewaard.
    2. In de toekomst: gegevens niet opslaan, maar opvragen bij de bron op moment ‘t’.

Idealiter zou iedere organisatie een gegevensboekhouding hebben en die zo inrichten dat alle gegevens die gebruikt worden c.q. nodig zijn voor de wettelijke taken (en de doelen die daaronder hangen), traceerbaar naar hun juridische bron vastliggen. Dat kan dat de basis zijn voor een gegevensvraag aan een stelselbron, en dat moet dan op een of andere manier ook in een policy vastliggen. Hier kan de proef met omzetting van wetten naar machineleesbare regels vervolgens gebruik van maken. Digilab is in gesprek met het project gegevensboekhouding van het Ministerie van Justitie en Veiligheid om een mogelijke samenwerking te verkennen.

Overall conclusies

Vervolgonderzoek

Beproefde standaarden & technieken

Voor het fieldlab is er door Digilab een fieldlabomgeving neergezet met een aantal registers met een set aan minimale testdata waarmee de zorgtoeslag berekend kon worden. De deelnemers aan het fieldlab konden proeven doen met deze technieken, waardoor we het gebruik in samenhang konden toetsen.

Moderne cloud infrastructuur as code & Haven Standaard

De fieldlabomgeving draait in Azure op Kubernetes. De omgeving maakt gebruik van GitOps d.m.v. Flux, Helmcharts, Docker images, manifests e.d., registers met PostgreSQL database, en is Haven compliant. Door deze opzet is het mogelijk om software van andere partijen te draaien in deze fieldlab-omgeving, indien deze containerized zijn. Onafhankelijk van de code base. Daarbij is het met infra as code eenvoudiger om over te stappen naar een andere cloud(leverancier), waardoor de cloudsoevereiniteit dichterbij is.

Haven schrijft een specifieke configuratie van Kubernetes voor die dient te worden geïmplementeerd op bestaande technische infrastructuur. De voorgeschreven configuratie zorgt ervoor dat iedere Haven omgeving functioneel gelijk is ongeacht de onderliggende technische infrastructuur. Dit brengt diverse voordelen met zich mee: uniformiteit in technische infrastructuur, uitwisselbaarheid van toepassingen, leveranciersonafhankelijkheid, platformonafhankelijkheid en kostenreductie. Op deze manier draagt dit bij aan het versterken van de Nederlandse digitale autonomie bij cloudtoepassingen.
Haven Website
Infra as Code Gitlab

Bevindingen

Niet voor elke partij is het werken met Kubernetes, (Docker)containers, Helmcharts, Flux al zo vertrouwd. Dan kan het deployen van een service of software lastiger gaan. Terwijl bij ervaren gebruikers dit juist heel efficient gaat.

Gebruik van Rest API’s o.b.v. Open API Specifications

Elke fictieve organisatie had een eigen register.
De gegevens per register zijn beschikbaar gemaakt d.m.v. Open API specificaties.
Doordat de API op een standaard wijze beschreven wordt, kan een API makkelijk bevraagd en geïmplementeerd worden door andere applicaties.
Documentatie Rest API Design Rules

Federatieve Service Connectivity- standaard (FSC)

Voor de uitwisseling van gegevens is gebruik gemaakt van Federatieve Service Connectivity- standaard (FSC). FSC is opgenomen in het Digikoppeling REST profiel, naast andere profielen zoals WUS en Ebms. De FSC-standaard uniformeert de wijze waarop koppelingen worden gerealiseerd, waardoor deze beheersbaar, veilig en betrouwbaar zijn. De koppeling kunnen relatief eenvoudig en snel worden gerealiseerd, gewijzigd, gecontroleerd of opgeheven. Daarnaast worden aanvullende waarborgen gerealiseerd voor de veiligheid en betrouwbaarheid van data. Door gebruik te maken van FSC is er één manier van koppelen, in plaats van allerlei verschillende manieren waarop beveiligd toegang tot het koppelvlak wordt verleend. De FSC-standaard vervult hiermee een cruciale rol in het realiseren van de standaardisering van gegevensuitwisseling in de komende jaren. Federatieve Toegangsverlening en Logboek Dataverwerking sluiten naadloos aan op de FSC-standaard door gebruik te maken van onderdelen (o.a. de inway en outway) van FSC. Als nieuwkomer op het fieldlab heeft de Rijksvoorziening Identiteit Gegevens (RVIG), zelfstandig een eigen service met FSC gedeployed, wat de relatieve eenvoudigheid illustreert.
https://fsc-standaard.nl/oplossing

Logboek Dataverwerkingen (LDV)

De overheid moet haar acties en besluiten altijd kunnen uitleggen en verantwoorden. Aan burgers, maar ook aan bedrijven en andere overheidsorganisaties. De standaard Logboek Dataverwerkingen helpt hierbij. Het is een standaard manier om vast te leggen wat er met gegevens gebeurt. En waarom dat gebeurt.
LDV werkt goed samen met de FSC standaard. Logboek dataverwerkingen maakt in de fieldlabketen gebruik van de transactielogs en de inway en outway uit FSC.
Elke organisatie heeft zijn eigen LDV, elke datavraag krijg een trace-id. Mocht er een onregelmatigheid blijken uit monitoring of logging, dan kan aan de hand van de trace-id, over de organisaties heen, opgezocht worden welke gegevens er verwerkt zijn door welke organisatie. Deze trace-id’s zouden dan bijvoorbeeld via FSC-transactie-id’s aan elkaar te relateren moeten zijn. Elke organisatie moet ook een koppeling hebben met hun eigen Register voor verwerkingsactiviteiten, omdat hiermee achteraf de doelbinding getoetst en gerechtvaardigd kan worden.
De standaard voor het Logboek dataverwerkingen is eenvoudig te combineren met andere applicaties of extensies, zoals bijvoorbeeld voor het loggen van Algoritmes. Waarover later meer.
Documentatie Logboek Dataverwerking Standaard

Federatieve Toegangsverlening

Federatieve Toegangsverlening is een standaardmethodiek om toegang tot gegevens en functies te regelen in een modern federatief stelsel. Denk aan het automatiseren van controles op basis van beleids- en toegangsregels, gebaseerd op transparantie zodat ook achteraf helder is op basis van welke regels en afspraken bepaalde gegevens gedeeld of geraadpleegd mochten worden.
Tijdens het fieldlab is gebruik gemaakt van Federatieve Toegangsverlening, gebaseerd op Policy Based Acces Control. Federatieve Toegangsverlening werkt goed samen met de FSC standaard. FTV kan als extensie gekoppeld worden op FSC waarbij gebruik gemaakt wordt van de FSC inway en outway. In de inway en outway kunnen policies meegegeven en gevalideerd worden. De beoogde standaard voor FTV zal op basis van AuthZen worden gevormd. Komende periode zal hiermee geëxperimenteerd worden binnen Digilab.
Website Federatieve toegangsverlening

Bevindingen

Verder onderzoeken

Transparante algoritmes en proefberekeningen

De fictieve Dienst Toeslagen initieert voor een bepaalde burger een nieuwe berekening zorgtoeslag. Hieruit volgen meerdere records in het logboek. De trace id’s die gebruikt worden in het logboek, die gegenereerd worden in de outway en inway van FSC, zorgen voor een mogelijke koppeling.
De Fictieve Dienst Toeslagen vraagt op een moment ook de daadwerkelijk berekening aan en dit wordt ook vastgelegd als een logboek regel. Deze logboek regel maakt gebruik van de namespace / extensie dpl.algoritmes.id en hiermee weten we hier een “algoritme” operatie, ofwel een berekening heeft plaatsgevonden.

In de metadata is vervolgens ook vastgelegd welke informatie bij de berekening is gebruikt. Naast BSN, gaat het in dit voorbeeld ook om o.a. leeftijd en toetsingsinkomen (zie afbeelding). Voor het opvragen van deze informatie zijn er losse logboek regels, maar de metainformatie die voor de berekening, is in dit voorbeeld ook opgeslagen in de logboekregel van het algoritme. Nu kan de “brief” (het besluit) gekoppeld worden aan de logboek operatie en weten we dat er een berekening bij deze operatie heeft plaatsgevonden. Dit maakt het mogelijk om in de interface van Fictieve Mijn Overheid de burger te voorzien van de volgende informatie:

Daarnaast krijgt de burger de mogelijkheid om een controle berekening uit te voeren. Doordat we het ID van het algoritme weten, kunnen we het algoritme ook lokaal in de browser beschikbaar maken. Hiervoor halen we het algoritme m.b.v. het ID op uit een fictief algoritmeregister. Alle benodigde informatie is nu lokaal in de browser beschikbaar, en de burger kan zonder dat de overheid meekijkt, controleberekeningen maken. Als de burger hierop een nieuwe aanvraag wil starten, dan kan de burger deze proefberekening eventueel wel gebruiken.

Attributen voor Logboek Dataverwerkingen

Bevindingen

Het AI-validatieteam wilde gebruik maken van regels.overheid.nl, maar kregen dat ‘niet aan de praat’. Zij hebben daarom een alternatief bedacht, waarbij ze de wet vertalen naar een machine uitvoerbare wet met rekenregels, die wordt geschreven in yaml. Deze machine uitvoerbare wet is de basis voor de algoritme engine. Deze engine is tijdens het fieldlab in Python gebouwd.
Vervolgens is daar met behulp van WebAssembly een pakket van gemaakt, zodat de burger de schaduwberekening ook in de browser kan uitvoeren. Dit pakket kan ook op bijv. de machine van de Fictieve Dienst Toeslagen worden gebruikt, en daarmee kun je garanderen dat het machine-uitvoerbare wet en de engine in beide gevallen hetzelfde zijn.

Verder onderzoeken

Database met historie: Database met ‘Atomic Claims’

Het project ‘Uit betrouwbare bron’ ontwerpt een capabel overheidsregister dat invulling geeft aan publieke waarden zoals controleerbaarheid en betrouwbaarheid. Hiervoor is het nodig om meer context bij vastgelegde gegevens bij houden. Denk daarbij aan informatie die iets zegt over de aanleiding voor vastlegging (al dan niet in de vorm van events), kwaliteits- of zekerheidsindicaties en historische gegevens. We beproeven daarbij registratie van gegevens in de vorm van atomaire claims. Deze zijn de kleinst mogelijke informatiefragmenten die zonder betekenisverlies kunnen worden vastgelegd en stellen ons in staat precies vast te stellen welke gegevens als gevolg van een bepaalde aanleiding werden gewijzigd of aan de juistheid van welke gegevens wordt getwijfeld.

Bevindingen

Tijdens het fieldlab bleek een capabel register geen voorwaarde voor goede proactieve dienstverlening in de happy flow. Zodra er correcties gedaan moeten worden, ligt dat anders. De verkeerd geregistreerde woonsituatie van Jael was dankzij gedetailleerd bijgehouden historie wel eenvoudig te herstellen, waarna we onterecht te weinig betaalde studiefinanciering alsnog konden uitbetalen. Bovendien was het register in staat de gevolgen van een wetswijziging met terugwerkende kracht te verwerken.

Verder onderzoeken

De fieldlabresultaten onderschreven het belang van bijhouding van historische gegevens en bewezen de werking van een register dat informatie bijhoudt in de vorm van atomaire claims. Hoewel dit laatste helpt ambiguïteit bij interpretatie van registergegevens te voorkomen, moet verder experimenteren duidelijk maken of dit ook op de schaal van een ’echt’ register blijft functioneren.
Daarnaast wordt verder onderzocht hoe de inrichting en het gebruik van de vaak complexe functionaliteit die capabele registers nodig hebben, kunnen vergemakkelijken. Een laatste vervolgtrack betreft het capabeler maken van registers op basis van de techniek van vandaag.

Hiervoor is aandacht tijdens de ‘Dag van de Toekomstige Ketens’ op 3 april 2025.
Een ander punt voor vervolgonderzoek is hoe de context binnen een federatief datastelsel meegenomen kan worden tussen verschillende registers.
Website Uit betrouwbare bron
Gitlab Betrouwbare Bron

Cloud Events

Organisaties werden real-time op de hoogte gesteld door middel van Cloud event- standaard. In deze keten is dit geïmplementeerd met een NATS message queue. NATS is licht en verbruikt weinig resources. Organisaties bepalen zelf op welke Cloud events zij zich willen abonneren, ze kunnen filteren en limiteren welke berichten zij willen ontvangen. In plaats van dat organisaties onderling met elkaar 1-op-1 berichten versturen of één bericht met heel veel informatie naar een meerder ketenpartners te sturen, abonneren organisaties zich op een event dat voor hen relevant is.

Naar aanleiding van een event kunnen zij hun eigen processen opstarten en registers raadplegen. Het voordeel van events is dat Het voordeel van events is dat de events een seintje geven dat er iets veranderd is, wat mogelijk relevant is voor de organisaties die geabonneerd zijn op het event. De organisatie bepaalt zelf welk proces en wat de inhoud daarvan is. Ook bij het versturen en ontvangen van de cloud events wordt gebruik gemaakt van de FSC inway en outway, zodat niet iedereen zich ongeautoriseerd op cloud events kan abonneren. De headers met de FTV policies worden alleen gecheckt bij het aanmaken van de initiële connectie, daarna wordt voor elk volgend event dezelfde verbinding gebruikt. Dit zorgt er dus voor dat het niet nogmaals gecontroleerd kan worden.
Cloud event Github

Bevindingen

Het team van de Belastingdienst en Dienst Toeslagen hebben kennis gemaakt met een volledig nieuwe manier van werken, met nieuwe technieken en andere programmeertalen. Het is hun gelukt om eigen app aan te sluiten op de event message queue (events). De nieuw aangesloten app, startte daarna een eigen proces op waarmee toeslag berekend werd.

Verder onderzoeken

IMX

IMX maakt het mogelijk om gegevens uit verschillende bronnen te combineren en als nieuw informatieproduct beschikbaar te stellen. Op basis van de bestaande informatiemodellen van de bronnen en een specificatie waarin de vertaalregels staan beschreven, kan IMX alle benodigde gegevens realtime en zo efficiënt mogelijk bij de bron raadplegen en assembleren tot een eindproduct. Daarbij wordt zoveel als mogelijk data minimalisatie toegepast. Tijdens dit orkestratie-proces wordt de herkomst van alle gegevenselementen bijgehouden, zodat transparant blijft welke brongegevens zijn gebruikt. IMX is ook heel bruikbaar om data uit systemen die geen API op maat aanbieden, op te halen en in het juiste formaat aan te bieden. Zo kan het goed ingezet worden bij transities. Door het gebruik van IMX hoeft niet alles op hetzelfde moment op een andere manier te gaan werken.
Website IMX

Bevinding

Tijdens dit fieldlab is de Toeslagen rekenregelspecificatie gemodelleerd met IMX om zo een nieuw infomatieproduct beschikbaar stellen. De mapping-taal en referentie-implementatie zijn uitgebreid met configuratie en functionaliteit voor het kunnen toepassen van beslislogica. Het bleek dat er verschillende oplossingen zijn gerealiseerd waarmee de rekenengine van input werd voorzien.

Verder onderzoeken

Onderzocht moet worden wat binnen een keten met regelspecificaties en verschillende APIcalls, de beste plek is voor orkestratie.

DCAT 3 NL profiel en een CKAN Federatieve Catalogus

Voor het beschrijven van databronnen en services. De services die gebruikt werden tijdens het fieldlab zijn beschreven in DCAT 3 formaat en aangeboden ten behoeve van een POC Federatieve Catalogus, gebaseerd op CKAN.

Bevindingen

CKAN-instantie: CKAN bleek lastig aan te passen aan de wensen van het FDS: De uitsplitsing in datasets, dataservices en metadatering werkte nog niet goed in CKAN.
Het opstellen van correcte DCAT3 NL files blijkt niet eenvoudig: Het is niet gelukt de informatie uit de DCAT 3 files de eerste keer correct in te lezen. Deze metadata kan in een vervolg beproefd kan worden in de huidige opstelling in 2025. Het FDS en Digilab onderzoeken welke catalogus wel aan de requirements voldoet.
Documentatie DCAT 3 standaard

Verder onderzoeken

Project en applicatie Vorderingenoverzicht Rijk (VO-Rijk)

Het maken van een overzicht van actuele betalingsverplichtingen is voor burgers die in schuldhulpverlening terecht komen een grote drempel. Het project Vorderingenoverzicht Rijk levert een bijdrage aan het verlagen van die drempel, zodat problemen met betalingen en schulden sneller kunnen worden opgelost of worden voorkomen. Omdat het opvragen van informatie over financiële verplichtingen door een burger bij overheidsorganisaties een tijdrovende en complexe activiteit is, wil VO Rijk het proces van opvragen en ontsluiten van gegevens van de verschillende overheidsorganisaties naar de burger standaardiseren. Daarnaast automatiseren we dit proces voor de burger, zodat de burger dit niet handmatig hoeft uit te voeren, maar eenvoudig en snel kan regelen.
Documentatie Vorderingenoverzicht Rijk

Bevindingen

Doordat Vorderingenoverzicht Rijk van dezelfde standaarden en architectuur gebruik maakt, is het eenvoudig om de applicatie aan te sluiten op de bronnen van het fieldlab. Tijdens het fieldlab heeft VO Rijk in de applicatie bepaald of een gebruiker in aanmerking komt voor gezamenlijke betalingsregeling (Rijk). De organisatie fictieve Dienst Toeslagen werd aangesloten bij de app van VO Rijk. Via het Schulden endpoint van fictieve Dienst Toeslagen kon VO Rijk het verschuldigde zorgtoeslagbedrag tonen in de applicatie en aan de hand daarvan proactief een betalingsregeling aanbieden.

Verder onderzoeken

Op welke wijze kan de standaard die wordt gebruikt, om gegevens rechtsreeks van de bron te ontsluiten naar een burger, worden gebruikt voor een burgerinzicht-app voor Logboek Dataverwerking?

Screenshot van de VO Rijk-app

FDS als toezichthouder

Eén van de rollen van het Federatief Datastelsel is om toezicht te houden. Tijdens het fieldlab is gebouwd aan een dashboard om dataverkeer inzichtelijk te maken. Het aantal calls is een verzameling van alle services.
Hiervoor is gebruik gemaakt van de logs van FSC.
https://fds-logaggregator.padv.apps.digilab.network/assets/

Developer Overheid Nederland (DON) & NL Design System

Tijdens het fieldlab heeft het team van developer.overheid.nl samen met het team van NL Design System een nieuwe kennisbank opgetuigd op basis van Docusaurus. Docusaurus is een Open Source pakket dat Markdown bestanden omzet in statische HTML-documentatie. Met NL Design System compatible componenten heeft de kennisbank bovendien een Rijkshuisstijl-jasje gekregen, en voldoet de nieuwe kennisbank aan de toegankelijkheidseisen. Los van het technische aspect hebben de twee teams veel kennis verzameld en proberen te structureren binnen de kennisbank. Samen met de wens om deelnemers zélf kennis aan te laten leveren bleek dit een behoorlijke uitdaging.

Verder onderzoeken

Team DON moet dan ook verder onderzoeken hoe zij de informatie beter kunnen structureren (bijvoorbeeld via een zoekmachine) en hoe het toevoegen van nieuwe content laagdrempeliger gemaakt kan worden voor potentiële contributors.
https://don.apps.digilab.network/

Project Infra as Code / Haven+

Het project ‘Infra as code’ ontwikkelt een generieke open source infra as code-laag, waarop gemeenten het Dienstenplatform kunnen ‘uitrollen’. Tijdens het fieldlab is er met succes gewerkt aan de referentie-implementaties inclusief logging en monitoring stack en aan het uitrollen Keycloak (OIDC agnostisch), het uitrollen van de applicatie ‘Signalen’ en het uitrollen FSC. Dit is gelukt en heeft bewezen dat het live zetten van een applicatie binnen een korte periode kan, wanneer er gebruik gemaakt wordt van een generieke infrastructuur.
Documentatie Infra as code project

Homomorfe encryptie: een veilige methode voor gegevensverwerking

Homomorfe encryptie maakt het mogelijk om berekeningen uit te voeren op versleutelde gegevens, zonder dat de onderliggende waarden bekend hoeven te zijn. De invoerdata wordt versleuteld, waardoor deze niet kan worden ingezien door derden, zelfs niet wanneer zij toegang hebben tot de versleutelde data. Dit biedt gebruikers extra privacy en bescherming van hun persoonlijke gegevens.

Toepassing in de berekening van zorgtoeslag

Bij Digilab is het principe van homomorfe encryptie toegepast op het berekenen van zorgtoeslag. Voor deze berekening zijn verschillende gegevens nodig, zoals leeftijd, inkomen, vermogen, het hebben van een toeslagpartner en detentiestatus.

Procesbeschrijving

Inkomen en toeslagpartner (Partij A)
Partij A berekent de zorgtoeslag op basis van het toetsingsinkomen en of de burger een toeslagpartner heeft. Dit resulteert in een versleuteld bedrag aan zorgtoeslag per maand.

Vermogensgrens (Partij B)
Partij B bepaalt of het vermogen van de burger onder de grens ligt om in aanmerking te komen voor zorgtoeslag. Het resultaat is een versleuteld binaire waarde: 0 (geen recht op zorgtoeslag) of 1 (mogelijk recht op zorgtoeslag).

Leeftijdscontrole (Partij C)
Partij C controleert of de burger voldoet aan de minimumleeftijd van 18 jaar. Ook dit levert een versleutelde waarde op: 0 (geen recht op zorgtoeslag) of 1 (mogelijk recht op zorgtoeslag).

Detentiestatus (Partij D)
Partij D beoordeelt of de burger gedetineerd is. Een gedetineerde komt niet in aanmerking voor zorgtoeslag, wat resulteert in een versleutelde waarde van 0. In andere gevallen wordt een 1 aangeleverd.

Combineren van resultaten
Een andere partij vermenigvuldigt de versleutelde waarden van partijen A, B, C en D. Het resultaat is een versleuteld getal dat, na ontsleuteling, het maandelijkse zorgtoeslagbedrag van de burger weergeeft.

Voordelen van homomorfe encryptie

Omdat de gegevens gedurende het hele proces versleuteld blijven en pas na de berekening worden ontsleuteld, wordt de kans op het uitlekken van gevoelige invoergegevens aanzienlijk verkleind. Dit verhoogt de privacy en veiligheid van gebruikers, terwijl het systeem toch in staat is om nauwkeurige berekeningen uit te voeren.

Nadelen

Conclusie wel of niet toepassen

Het probleem qua veiligheid zit vaak op een andere plek. Bijvoorbeeld de bronhouder die zijn beveiliging niet op orde heeft, of gebruikers die te simpele wachtwoorden gebruiken.

Pas als die dingen goed op orde zijn, heeft een PET als homomorphe encryptie nut. Anders is het vooral ‘premature optimization’, die dingen onnodig ingewikkeld maakt.

Bloom filter - LDV Filter Component

Tijdens het fieldlab is er in het logboek dataverwerking een Bloom filter toegepast.
Het LDV filter gebruikt een Bloom filter, een efficiënte probabilistische datastructuur die snel kan bepalen of een element tot een verzameling behoort, zonder daadwerkelijke persoonsgegevens op te slaan.

De belangrijkste voordelen van een Bloom filter zijn de lage opslagvereisten, snelle zoekprestaties, gegarandeerde afwezigheid van vals-negatieven en sterke privacybescherming door het gebruik van hashfuncties. In het fieldlab hebben we het geïmplementeerd als het LDV filter component, waarbij elke organisatie een eigen Bloom filter bijhoudt waarin de betrokkenheid van burgers wordt vastgelegd door BSN’s te hashen. Deze individuele filters worden periodiek gesynchroniseerd met een centraal LDV filter, dat een geconsolideerd overzicht biedt van alle betrokkenheidsrelaties tussen burgers en organisaties.
Documentatie over het Bloom filter

Bevindingen

Het Bloom filter zorgt voor een verlaging in het verkeer tussen burgers en overheidsinstanties, aangezien burgers vooraf kunnen bepalen of een instantie verwerkingslogs over hen heeft. Hoewel het centrale LDV filter een single point of failure creëert en fungeert als centrale locatie waar alle data doorheen stroomt, vormt dit geen significant probleem omdat alle persoonsgegevens gehasht zijn.

Verder onderzoeken

Verdere onderzoeksgebieden omvatten het bepalen van optimale hashfuncties, configuratie-instellingen voor de balans tussen nauwkeurigheid en opslag, kwantificeren en beperken van vals-positieven, prestaties testen met grootschalige datasets, en evalueren van synchronisatievereisten tussen organisatiefilters en het centrale LDV filter.

  1. https://open.overheid.nl/documenten/ronl-0de79e5c4c0c9b203c0a1c263efca7eca410958b/pdf, p11.