Fifty-fifty

23 maart 2025

Deze week ongeveer 50% overleg en 50% schrijfwerk. Een volle week, er gebeurt veel tegelijk. Ben half tevreden. Niet alles gaat snel genoeg en andere dingen gaan juist iets te snel, waardoor ik last heb van FOMO.

Proof of Concept

Opnieuw heel wat tijd gestoken in de Proof of Concept Law as Code. De essentie: een uitvoerbare specificatie van de wet publiceren, in plaats van deze specificaties in software van uitvoeringsorganisaties “verstopt” te houden. Een paar keer hebben we het hele concept uiteengezet om feedback te krijgen en te kijken of we delen kunnen falsificeren. Dat lukt vooralsnog niet echt. Mijn indruk is dat iedereen die ons verhaal aanhoort aan de hand van de PoC software, de eerste uren vooral bezig is met het overzien van alle consequenties. Er komen nog weinig kritische geluiden los, terwijl we dat wel hard nodig hebben. Het risico bestaat dat we enthousiast overschakelen naar een volgende fase, terwijl er toch wat fatale fouten in het concept zitten. Zelf ben ik dan ook druk bezig om meer de diepte in te gaan op zoek naar manieren waarop het fout gaat. Een interessant onderwerp daarbij is het verschil tussen twee constructen die vaak voorkomen in wetgeving: verwijzingen naar definities in andere wetten vs verwijzingen naar besluiten uit andere wetten. Dat maakt een groot verschil voor wat betreft de gegevens die uitgewisseld moeten worden: gaat het om het uitvoerbaar gespecificeerde stukje van die andere wet, samen met de input feiten die nodig zijn om dat stukje wet uit te voeren, of gaat het om de met een besluit tot stand gekomen nieuwe feiten die je opvraagt?

Op korte termijn moeten we ook iets met de naam, want ‘de PoC’ is als aanduiding alleen voldoende voor het team. ‘Machine Law’, zoals de software nu heet, geeft een verkeerd beeld en doet geen recht aan wat we doen. Hetzelfde geldt voor ‘Law as Code’, dat werkt alleen voor andere nerds. Speel nu met wat variaties op Reproducible Law Instantiation and Execution Framework (RLIEF).

Volgende week is de three pager af waar Kees nu aan werkt. Als je een idee niet kunt vangen in drie pagina’s is het geen goed plan. Het is hard nodig om het in een paar pagina’s over te kunnen brengen, maar niet eenvoudig. Wellicht zijn het vooral alle consequenties die het een lang verhaal maken. Zelf werk ik aan een Research Agenda waarin we alle grote vragen formuleren waar meer onderzoek naar nodig is. De teller staat op 56 onderwerpen verdeeld over 11 categorieën. Ben bang dat het nog gaat verdubbelen. Er is heel wat onderzoek nodig.

Programmeringstafel Gegevensuitwisseling

De vergadering van de Programmeringstafel Gegevensuitwisseling behandelde ditmaal o.a. de uitdagingen rond Uniforme Bronontsluiting. Er was bijval voor de aanpak en zelfs wat aanmeldingen van organisaties die wel mee willen doen om samen uit te vinden hoe we gaan zorgen dat de veelvoud aan nieuwe wensen en wetten die data uit overheidsbronnen vereisen niet gaan leiden tot een even groot aantal nieuwe manieren om te koppelen met die bronnen.

Logboek Dataverwerkingen

Rond de standaard Logboek Dataverwerkingen gebeurt ook van alles. De Core is nu aardig stabiel, daaromheen wordt nu gewerkt aan een paar extensies die de standaard uitbreiden ten behoeve van specifieke wensen. Een grote extensie die beschrijft hoe je nauwkeurig kunt vastleggen welke data precies is verwerkt, een eerste verkenning naar hoe de NEN 7513 kan worden ingevuld met de standaard, en denkwerk rond de exacte invulling van het veld data-subject. Voor dat laatste moet eerst de vraag beantwoord worden of we in dat veld ook niet-natuurlijke personen wilden vangen. Dat vraagt om wat juridische overwegingen rond de definitie van ‘betrokkene’. Nemen we die over van de AVG (en definieren we daarnaast nog een ander soort betrokkene voor niet-natuurlijke personen) of breiden we de definitie wat uit?

Daarnaast verwachten we een dezer dagen een advies van de Autoriteit Persoonsgegevens over de concept standaard, en zijn we bezig om het geheel naar een versie te brengen die kan worden voorgelegd ter consultatie. Ook wordt de Programmeringstafel Gegevensuitwisseling een volgende keer bijgepraat over doelen en voortgang van deze standaard.

eDelivery

Het lijkt mij goed om, nu FSC een vastgesteld deel van de Digikoppeling-standaard is, we gaan kijken of we er iets mee kunnen binnen Digital Europe. Dat is een enorme pot geld (7 miljard) waaruit allerlei initiatieven worden gefinancierd die van de EU een Digital Powerhosue moeten maken. Specifiek gaat het dan om de prioriteit Standards & Compliance.

Een paar jaar geleden heb ik dat al eens voorgesteld, naar aanleiding van een hackathon in Brussel waar we voor uitgenodigd waren. Maar er was (bij ons) geen tijd om er echt iets mee te doen, focus was nodig om het in Nederland te regelen. Geen van de andere landen was toen al bezig met de uitdaging rond API’s.

Wat mij betreft is het nu wél het juiste moment om te onderzoeken of we FSC naar Europa kunnen brengen: ofwel binnen eDelivery (zoals FSC binnen Digikoppeling) ofwel als een losse standaard voor API-connectiviteit er naast.

Alleen FSC is overigens niet voldoende om de functionaliteit die eDelivery biedt te evenaren voor API’s, maar met wat aanvullende services kom je een heel eind. Conceptueel lijkt het goed te passen. Wellicht moet het voor API’s ook wat anders werken dan voor eBMS / AS4, omdat de aard van de uitwisseling nu eenmaal anders is.

In Nederland wordt eDelivery vrij intensief gebruik, al is het verstopt als laag onder bijv. Peppol, SBR, Digipoort. Er is nog geen standaard om hetzelfde te regelen met API’s. Strategisch is het voor NL ook goed om FSC naar EU te brengen nu we met onze oplossing voorop lopen, omdat als op een dag een andere oplossing vanuit de EU wordt gepromoot, de NL standaard in de verdrukking kan komen.