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

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:

• Atomic claims: 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.
• Homomorfe encryptie: maakt berekeningen mogelijk op versleutelde gegevens zonder onderliggende waardente onthullen. Maakt de berekeningen echter ook complexer en zwaarder, dus trager. Pas als andere beveiligingsmaatregels goed op orde zijn, heeft een PET als homomorphe encryptie nut. Anders is het vooral ‘premature optimization’, die dingen onnodig ingewikkeld maakt.
• Bloom filter: toegepast bij Logboek Dataverwerkingen: voor privacybescherming bij het delen van verwerkingslogs, helpt om BSN’s versleuteld (gehasht) op te slaan.
• IMX is beproefd voor het combineren van gegevens en maken van berekeningen, waarbij de herkomst van gegevens traceerbaar blijft.
• VO-Rijk is aangesloten op de case door een schuld bij Fictieve DUO te registreren en heeft in zijn applicatie bepaald of een gebruiker in aanmerking komt voor gezamenlijke betalingsregeling (Rijk). Vervolgonderzoek met LDV richt zich op de vraag of het protocol van VO-Rijk voor ontsluiting rechtstreeks aan de burger, ook voor inzicht in verwerkingenlogs te gebruiken is.
• HAVEN+ (voorheen bekend als Infra-as-code) heeft een generieke open source infra as code-laag ontwikkeld, 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 van FSC.
• DCAT-AP-NL 3.0 en een CKAN Federatieve Catalogus: 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. Dit bleek niet eenvoudig en ook niet aan alle vereisten te voldoen. Logius heeft ook een Proof of Concept voor een federatieve catalogus ontwikkeld met metadata. Vervolgonderzoeken naar de catalogus en het vereenvoudigen van aanleveren van DCAT3 files lopen nu door.
• Het team van developer.overheid.nl heeft samen met het team van NL Design System een nieuwe kennisbank opgetuigd op basis van Docusaurus.

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:

• Maakt het veel eenvoudiger om wetswijzigingen door te voeren, omdat de systemen gebruik maken van dezelfde wettelijke logica, en dus alleen die logica gewijzigd hoeft te worden (in plaats van afzonderlijke systemen waarin die regels op steeds andere wijze zijn vertaald).
• Het helpt de logica van op elkaar ingrijpende regels en definities transparant en de gevolgen inzichtelijk maken, zowel op het niveau van regels (wat gebeurt er als een regel wijzigt) als veranderende gegevens (wat gebeurt er als ik bijvoorbeeld meer ga verdienen). De vertaling van wet naar code is transparant. Dat is nu niet zo, iedere organisatie implementeert de wet op haar eigen manier. Deze doorvertaling is niet per definitie ook inzichtelijk, laat staan beschikbaar, voor de burger (voor eigen berekeningen).
• Overall is het omzetten van regels naar machine-leesbare code essentieel voor de complexiteitsreductie die nodig is voor goede, en zeker ook voor proactieve, overheidsdienstverlening.
• Dit concept, met de werktitel ‘van wet tot digitale werking’, heeft een spin-off gekregen. Het is op 7 april 2025 toegelaten als separaat project op Digilab. Tevens is op 31 maart 2025 een aanvraag op basis van dit concept ingediend voor het innovatiebudget van het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties.

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

• Standaardisatie en component-gebaseerd werken maken systemen flexibeler en beter aanpasbaar bij veranderende eisen.

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:

• Het identificeren, realiseren en toetsen van gemeenschappelijke componenten en technische standaarden voor het FDS
• Het in samenhang beproeven van knelpunten op het gebied van gegevensdeling in een proof of concept omgeving
• Ondervinden wat kan, wat mag, wat helpt en wat inspireert?
• Uitzoeken wat er al is en wat kunnen we hergebruiken?
• Hoe kunnen we wat er al is, verder brengen?

Voorbehouden:

• Het gaat om een toekomstig, nog niet bestaand of niet-operationeel stelsel
• Het is een ‘proeftuin’, geen weerspiegeling van de huidige werkelijkheid
• Componenten zijn Proof of Concepts (POC’s), de software is niet productiewaardig
• Juridische belemmeringen zijn beperkt meegenomen
• In dit fieldlab lag de focus niet op de user experience van de burger, maar op de technische onderlaag die verbeterde dienstverlening mogelijk maakt.

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:

• Gebruik gemaakt wordt van standaarden of standaarden- to-be
• Data real-time beschikbaar is
• Het ‘Data bij de bron- principe’ wordt toegepast
• Dataminimalisatie wordt toegepast
• Er zo veel mogelijk transparantie is: burgers inzicht krijgen in de gegevens, regels en algoritmen die gebruikt zijn
• Software open source en herbruikbaar is
• De deelnemende organisaties voldoen aan de voorwaarden om deelnemer of afnemer te zijn van een Federatief Datastelsel.

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.

• Het FDS maakt afspraken over voorwaarden aan aangeboden datasets en aan welke afspraken organisaties zich moeten houden. Leden van het FDS committeren zich hieraan.
• Het FDS creëert een stelsel van (soms nieuwe) standaarden en afspraken waarbinnen leden aan benodigde vereisten voldoen, waardoor interoperabiliteit mogelijk en veilig is.
• Het FDS streeft naar het gebruik van ‘Data bij de bron’. Dit leidt tot hogere datakwaliteit, meer veiligheid en betere bescherming van privacy;
  • Geen fouten door onnodige kopieerslagen;
• Data op één plek is beter te beveiligen en biedt betere bescherming van privacy;
• Makkelijker data kunnen corrigeren, omdat het maar één keer hoeft te gebeuren;
• De overheid kan makkelijker inzicht geven in het gebruik van data;
• Als we dat op dezelfde manier doen, vallen de barrières weg
• De totale hoeveelheid data binnen de overheid vermindert (dataminimalisatie).

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

• Vanuit het Fictieve BRP-register wordt een cloud event op de message queue gezet ‘burger 111222333’ heeft 18 jaar bereikt’.
• Fictieve Dienst Toeslagen is geabonneerd op dit event en start het eigen proces op.
• Fictieve Dienst Toeslagen haalt gegevens op. Fictieve Dienst Toeslagen heeft via FSC- contracten met het Fictieve Zorgverzekeringsregister, Fictief BRP, Fictief-UWV, Fictieve Belastingdienst.
• Fictieve Dienst Toeslagen heeft de federatieve toegang correct ingericht volgens Policy Based Acces Control en mag bij de gegevens van de registers die benodigd zijn. Volgens de principes van Federatieve Toegang worden de policies van aanbieder, afnemer en het stelsel gecheckt alvorens Fictieve Dienst Toeslagen de data vraag kan stellen. De data-aanbieders checken de eigen policies.
• De data-aanbieders checken aan hun kant of ze een FSC-contract hebben met de data-vrager. Vervolgens wordt gecheckt in een apart mini-register (FDS-ledenlijst) of de datavrager lid is van het FDS en aan de gestelde voorwaarden voldoet. Als dat zo is, is de datavraag valide in deze fieldlabketen.
• Van elke data-vraag en antwoord wordt de verwerking gelogd in Logboek DataVerwerkingen (LDV). Zo is later altijd terug te vinden welke partij welke gegevens heeft opgevraagd, met een referentie naar de doelbinding via het Register van Verwerkingsactiviteiten (RvvA)
• Ten behoeve van dataminimalisatie checkt Fictieve Dienst Toeslagen eerst of er een zorgverzekering is. Zo niet, dan stopt het proces. Zo ook voor de overige benodigde informatie. Er wordt dus alleen gevraagd wat nodig is.
• Als het vermogen boven de grens voor zorgtoeslag ligt, dan wordt alleen dat feit (vermogen is > dan X) gecontroleerd. Meer is niet nodig.
• Wanneer alle gegevens zijn opgehaald, rekent de rekenengine aan de hand van de rekenregel (ook wel het algoritme) de hoeveelheid zorgtoeslag uit. Dit wordt via een RestAPI doorgegeven aan de ‘Fictieve Mijn Overheid’ en geplaatst in de fictieve Berichtenbox van de burger.
• Jael kan op ieder moment zien op hoeveel zorgtoeslag ze, op dat moment op basis van de de meest recente gegevens, recht heeft.
• Indien haar inkomen of vermogen wijzigt in desbetreffende registers (in deze keten respectievelijk fictief UWV en Fictieve Belastingdienst), worden deze wijzigingen weer met cloud events op de message queue gezet, wordt dit direct opnieuw berekend door de Fictieve Toeslagen Reken engine en aan haar aangeboden in de Fictieve Mijn Overheid.
• De berichten in de Berichtenbox komen uit de database van de MijnOverheid / Daar zijn ze opgeslagen als tekst (Markdown-formaat). De berichten worden aangemaakt door Fictieve Dienst Toeslagen via de berichtenbox-api. De Fictieve Berichtenbox heeft een API waarmee andere partijen (Fictieve Toeslagen) berichten kunnen aanmaken en versturen.
• Toeslagen is geabonneerd op events van de Belastingdienst, UWV, etc. en maakt een nieuw berichtenbox-bericht als er iets verandert in de zorgtoeslag.
• In deze omgeving wordt niets opgeslagen, maar alles real-time berekend. (Uitgezonderd de berichten in de Fictieve berichtenbox).
• De gegevens worden alleen voor deze berekening gebruikt en niet opgeslagen. Als later een aanvraag volgt, zullen, voor de onderbouwing van het besluit, deze gegevens uiteraard wel opgeslagen moeten worden. Voor een proactief aanbod is dit echter nog niet nodig. De engine is daarom in deze uitganssituatie ‘stateless’.
• In de “Fictieve Mijn Overheid’ kan Jael in het Logboek Dataverwerkingen real-time zien welke organisaties welke dataverwerkingen heeft gedaan.
• In Fictieve Mijn Overheid’ kan Jael zien welke algoritmes zijn gebruikt om haar besluiten te berekenen. In dit fieldlab is gekozen voor een ‘fictieve Mijn Overheid’. In praktijk kan de overheid deze data ontsluiten via verschillende front-ends die daartoe gerechtigd zijn.

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.

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:

• Er wordt met terugwerkende kracht gecorrigeerd bij de bron Fictieve DUO: toch uitwonend. Jael heeft met terugwerkende kracht recht op 10 maanden uitwonende studiebeurs.
• Vanaf 1 januari 2024 telt deze hogere uitwonende studietoelage als gift mee in het inkomen voor de zorgtoeslag.
• Dit betekent dat haar inkomen hoger was van 1 januari tot en met mei 2024 en er in deze periode te veel zorgtoeslag is uitgekeerd.
• De correctie van de toestand uitwonend/thuiswonend leidt tot herberekening met terugwerkende kracht en een schuld bij fictieve Dienst Toeslagen, omdat Jael in de periode januari tot en met mei 2024 te veel zorgtoeslag heeft ontvangen.

Uitbreiding scenario: beleidskeuzes, correcties, betalingsregeling

• De beleids-/juridische vragen die zich aandienen gaan over de gevolgen die de correctie, gecombineerd met de veranderde regelgeving, voor Jael moet hebben:
  • Is het juridisch juist, en is het politiek en beleidsmatig gewenst om de fout met alle gevolgen aan Jael toe te rekenen? Met als mogelijk gevolg dat het vertrouwen in proactieve diensten daalt of mensen deze zelfs gaan weigeren?
  • Willen we mensen een keuze bieden bij dit soort situaties om de gevolgen van de wijzigingen te accepteren, of kiest de overheid?
  • Kiezen we als overheid dan de regel ‘alleen baten vallen bij de burger’? In dat geval zou de berekening voor Jael per saldo (extra studiefinanciering vs minder zorgtoeslag) gunstig uit moeten vallen, om door te werken.
  • Dan zou het zelfs een overweging kunnen zijn om deze bedragen te verrekenen tussen instanties, en dus niet de (ver-)rekening en de bijbehorende complexiteit bij Jael te laten.
• We zijn er in dit scenario van uit gegaan dat er een schuld ontstaat voor Jael.
• De dienst Vorderingenoverzicht Rijk toont deze schuld en geeft een handelingsperspectief: Jael krijgt een centrale betalingsregeling aangeboden om de zorgtoeslag terug te betalen.

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:

• 2 algoritmes voor berekenen hoogte zorgtoeslag:

  • 1 zonder DUO - studiegift als variabele voor de hoogte van het inkomen
  • 1 mèt de DUO - Studiegift als variabele voor de hoogte van het inkomen

• Database/register met materiële en formele historie van Fictieve DUO:

  • Student meldt toch uitwonend te wonen
  • DUO onderzoekt melding en concludeert dat die juist is
  • DUO verwerkt correctie met terugwerkende kracht
  • Cloud event met deze inhoud wordt aangeboden, Fictieve DUO doet een correctie in hun register
  • Toeslagen reageert op het cloud event met een herberekening

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

• Doordat de software van dezelfde uitgangspunten en standaarden gebruik maakt, is er sprake van technische interoperabiliteit.
• Het is bijvoorbeeld makkelijk om te koppelen met de app van Vorderingenoverizcht Rijk en gebruik te maken van Data bij de Bron. Het Vorderingenoverzicht Rijk heeft een koppeling gemaakt met Fictieve Dienst Toeslagen en Fictieve Duo (en andere registers waarbij een burger schulden kan hebben).
• Zodra een burger via de VO-rijk app inlogt, worden de meest recente schuldendata direct bij de bron opgehaald en getoond.
• Op basis van deze informatie kan een betalingsregeling worden aangeboden op basis van de regels die VO-rijk hiervoor gebruikt.

Vervolgvragen

• Moeten wijzigingen in registraties wettelijk altijd herberekend worden?
• Is het mogelijk om in te bouwen dat correcties alleen ten goede komen van de betrokkene? Dus dat de toeslag geen voorschot is, maar het daadwerkelijke recht, en als dat gecorrigeerd moet, dat dat alleen naar boven toe gebeurt?
• Mag je dan naar de gehele correctie kijken, en constateren dat het netto-resultaat positief is, of mag je alleen het positieve deel effectueren?
• Betrek je bij de berekening van het saldo alleen de toeslag, of ook de studiefinanciering/-gift? Dus mag de te veel ontvangen zorgtoeslag verrekend worden met de nog te ontvangen studiefinanciering? En kan dit automatisch? Hoe werkt dit tussen verschillende overheidsinstanties?
• Kunnen wetten door middel van een taalmodel omgezet worden naar een algoritme? Tijdens het ontwikkelen van de rekenengine werd gebruik gemaakt van het handmatig omzetten van wetten naar een leesbare rekenmodel met ALEF. Dit zou voor juristen heel veel werk betekenen. Door samenwerking met het AI Validatie-team is gekeken of een LLM (Large Language Model) kan ondersteunen in het omzetten van wetten naar machineleesbare rekenregels. Dit wordt momenteel verder onderzocht.

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

• Artikel 2 & 2a Wet zorgtoeslag
  Zorgtoeslagvoorwaarden:
  • 18 jaar
  • Zorgverzekering afgesloten
  • Vermogen onder drempelwaarde
  • Normpremie lager dan standaardpremie
• Artikel 7 Wet zorgtoeslag
  Toeslagen worden toegekend op aanvraag.
• Artikel 15, lid 7 Awir
  Toeslagen mag een formulier toesturen en relevante gegevens vooraf invullen bij vermoedelijk recht op toeslag.
• Artikel 38 Awir
  Andere organisaties (publiek en privaat) moeten desgevraagd relevante gegevens leveren voor wetstoepassing.
• Artikel 38a Awir
  Gegevensverstrekking voor dienstverlening.
• Artikel 39 Awir
  Uitwisseling van gegevens tussen Dienst Toeslagen en Belastingdienst.

Analyse: Welke gegevens zijn nodig?

• Trigger: 18 jaar worden (BRP-gegevens)
  • BRP geeft leeftijd/geboortedatum door.
  • Keuze: direct ja/nee ontvangen of zelf berekening maken?
  • Antwoord: in dit geval triviaal. In andere casus wellicht wél relevante vraag.
• Vermogen (Belastingdienst)
  • Kan worden opgevraagd via artikel 39 Awir.
  • Vraag: is er een geschikt en actueel bestand beschikbaar?
• Inkomen (UWV, polis)
  • Lonen en uitkeringen beschikbaar via artikel 38 Awir.
  • Echter: zelfstandigeninkomen ontbreekt.
• Zorgverzekering (Vecozo)
  • Begin- en einddatum beschikbaar via artikel 38 Awir.
• Bewaartermijnen
  • Volgen de selectielijst van Toeslagen.

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

• Zet juristen in dezelfde ruimte als techneuten (en in het algemeen: zet iedereen in dezelfde ruimte voor het meeste spontane contact).
• Organiseer gesprekken, waar deze niet spontaan plaatsvinden, op relevante vragen.
• Toets aannames over en weer. Tijdens het Fieldlab kwam bijvoorbeeld de vraag op waar de gegevens voor de Toeslagenberekening werden opgeslagen. Het antwoord: nergens (de engine is stateless), was bij de juridische track niet opgekomen en maakt uit voor de juridische beoordeling van de gegevensdeling.
• Voor gegevensverwerking en deling door en tussen overheden is een grondslag nodig. De overheid werkt nu vooral aanvraag-gebaseerd. Zonder aanvraag is er niet altijd een grondslag voor proactief aanbieden.

Vervolgonderzoek

• Welke policies zijn vanuit juridisch oogpunt nodig voor FTV, zijn er eventuele residual policies nodig?
  • Moeten deze policies per casus worden ingericht?
  • Welke policies zijn algemeen geldend?
  • Is er een link met gegevensboekhouding te leggen?
• Hoe richten we een systeem van waarborgen in in een Federatief Datastelsel, waarin verantwoordelijkheid voor rechtmatigheidscontrole bij aanvraag, meer bij de vrager van gegevens wordt gelegd?
• Hoe komen we tot de machineleesbare regels voor toegang?
• Is hiervoor een link met (een vorm van) gegevensboekhouding nodig of wenselijk?

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

• De techniek lijkt niet het moeilijkst om op te lossen, maar de policies en voorwaarden om gegevens te kunnen delen zijn nog niet helder genoeg en lijken nog te ontbreken. Hierdoor is het lastig om een reële POC te implementeren en demonstreren.
• Ook de gedachte dat de verantwoordelijkheid voor het afnemen van data grotendeels bij de afnemer ligt is een grote wijziging. De data-aanbieder weet niet of de data-afnemer doelbinding heeft en kan dit vooraf niet controleren. De afnemende partij moet dit op verschillende plekken in applicatie, infrastructuur en organisatie vooraf controleren en middels policies of er bijv. doelbinding is om gegevens bij een aanbieder te vragen. Er kan pas achteraf geaudit worden of de data-afnemer rechtmatig gegevens heeft opgevraagd. Dit ‘openzetten’ van gegevensuitwisseling voelt contra-intuïtief. In praktijk gebeurt dit in het dagelijks leven ook, maar dan zonder inzicht en transparantie. Juridisch lijkt de ‘nieuwe methode’ lastig vast te leggen of te verantwoorden, terwijl het feitelijk wel op deze manier in de wet staat.

Verder onderzoeken

• Welke policies gelden er voor het Federatieve Datastelsel?
• Moeten alle policies bij elke api call gecheckt worden? Zo nee, welke wel en niet?
• Is het een optie om bij de policy-check “is lid van FDS” voorwaarden te stellen voor het auditen en vormgeven van waarborgen, die tonen dat organisaties gegevens alleen gebruiken conform doelbinding en met een wettelijke grondslag?
• Onderdeel van die waarborgen zou kunnen zijn: de logs moeten bestaan conform standaard (Logboek Dataverwerkingen) en daarin moet herleidbaar zijn voor welk doel en met welke grondslag de gegevens zijn opgevraagd aan de hand van het register van verwerkingsactiviteiten.
• Zijn die waarborgen te automatiseren? Zijn er zogenaamde residual policies nodig en zo ja, waar bestaan die uit?
• De voorwaarden en policies hangen af van de definitie van verschillende deelnemers of afnemers van het Federatief datastelsel.
• Komt er een Federatieve toegangsverlening NL gov profiel en een FDS- profiel?
• Juridisch- en privacytechnisch: is er voldoende verantwoording van de doelbinding als je meegeeft in de policies dat je van LDV gebruikt maakt èn een RVVA hebt? De verwerkingsactiviteit mag om AVG redenen niet worden meegegeven.
• In de juridische track ontstond de behoefte om nader uit te werken hoe je in een federatief stelsel op meerdere niveaus waarborgen inbouwt voor de juiste autorisatie – indien die waarborgen niet in de toegangsbeslissing per keer zitten.
• Wat zijn eisen aan datasets? Zijn er verschillende eisen of policies per verschillende ‘categorie’ dataset?
• Voor FTV moeten er een soort policy registers gevormd worden per organisaties en in combinatie met LDV een policy logboek waarin getracet kan worden op basis van welke policy, welk gegeven opgevraagd kon worden.

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:

• De opgevraagde informatie
• De gebruikte berekening
• De uitkomst

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.

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

• Voor het tonen van de waarden die zijn gebruikt voor het algoritme, werden de waarden ook in de logs opgeslagen. Hier openbaart zich een spanningsveld tussen het beginsel van dataminimalisatie en de vereisten van transparantie en verantwoording. Dit is dus een beleidsmatige en juridische afweging die gemaakt zal moeten worden.
• Voor de specifieke use case van het fieldlab werkte de python engine voor de machine uitvoerbare wetten. Het was een ruwe diamant. Uit dit fieldlab is vervolgens het idee van ‘Wet naar Digitale Werking’ ontstaan en daarmee wordt dit nu verder verkend en beter uitgewerkt.

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

• Hoe weten organisaties in een federatief stelsel welke events er zijn?
• Hoe abonneert een organisatie zich daarop’?
• Is het nodig om BSN te pseudonimiseren in een cloud event? Moet er überhaupt een BSN gestuurd worden?
• Hoe voldoe je aan dataminimalisatie en doelbinding?
• Hoe wordt in een federatief datastelsel een wildgroei aan cloud events voorkomen?
• Is het wenselijk om de authorisatie wèl bij elk event te checken?

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

• Logius was aanwezig en heeft ook Proof of Concept voor een federatieve catalogus ontwikkeld met metadata. https://metadata.simulatie.datastelsel.nl/
  Hoe kan bovengenoemde catalogus bijdragen aan een federatieve catalogus waarin datasets en dataservices vindbaar zijn en worden aangeboden?
• In de aangeleverde DCAT werden meerdere services beschreven. Is het handig om meerdere services in één DCAT bestand te beschrijven en aan te bieden?
• Digilab onderzoekt of er een manier is om eenvoudig DCAT3 files te creëren naar aanleiding van OpenAPI specificaties in de FSC directory.

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?

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

• Maakt de berekening trager (is in dit geval een erg simpele berekening, dus verschil is verwaarloosbaar, maar bij complexe berekeningen wel relevant)
• Maakt de code ingewikkelder

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.