< Index

Bronnen

7 maart 2025

Vandaag zoom ik in op een project dat deze week is gestart.

“Uniforme bronontsluiting”

Een voorbeeld waarom het loont om beleid en engineering heel dicht bij elkaar te hebben wanneer je beleid voor engineers maakt.

Overheden hebben data in databases. Jargon: bronnen. Als een andere partij die data nodig heeft moet geregeld worden hoe die bij de data kan komen, zowel beleid als techniek. Dit wordt bronontsluiting genoemd.

Welke partijen willen data? Dat kunnen we categoriseren. Wordt op de beleidsafdeling de informatiestromen genoemd.

Deze suboptimale onderverdeling is niet zo ontworpen maar komt voort uit de verschillende wetten die er op van toepassing zijn.

Gegevensuitwisseling tussen overheden onderling is geregeld met allerlei Nederlandse kaders, afspraken, standaarden en voorzieningen. Denk aan Digikoppeling en het Federatief Datastelsel.

De Europese Single Digital Gateway met het Once-Only Technical System is verplicht als manier om data vanuit Nederlandse overheidsorganisaties naar organisaties in Europa te krijgen. Voorbeeld use case: Als je in Spanje gaat studeren en men wil je diploma zien, kan via SDG-OOTS het bewijs van diploma worden opgehaald bij DUO.

Ook heeft men voor de hele EU de EU Digitital Identity Wallets bedacht. Daarbij gaat de data eerst vanuit de (overheids)bron naar de Wallet, een app, en kan de burger deze data zelf gebruiken waar nodig. Voorbeeld use case: Als je in Spanje gaat studeren en men wil je diploma zien, kan via je via DUO het bewijs van diploma in je wallet zetten en deze inleveren in Spanje.

Klopt, het is meer mensen opgevallen dat deze twee verplichtingen uit de EU overlappend zijn.

Private organisaties willen ook graag gevalideerde overheidsdata. tegenwoordig liever niet meer een bewijs op papier, maar rechtstreeks uit een database van de overheid. Denk aan een hypotheekverstrekker die graag wil weten hoeveel inkomen je hebt, waar je woont, etc. etc. Dit doet men tegenwoordig via gespecialiseerde partijen zoals Datakeeper, Ockto, etc. die de data ophalen uit de overheidsbron en doorsturen naar de private dienstverlener. Dit mag overigens alleen met toestemming. We noemen deze gespecialiseerde partijen de datadelers.

Je kunt je voorstellen dat voor elk van deze bovengenoemde informatiestromen een eigen beleidsdossier wordt gestart. Het betreft complete wetten uit de EU waar we ons in Nederland toe moeten verhouden, of een zorgelijke ontwikkeling waar de Autoriteit Persoonsgegevens een strenge brief over schrijft omdat de Datadelers de data niet uit de bron halen, maar via een webbrowser scrapen nadat de betrokken burger met DigiD is ingelogd op bijvoorbeeld MijnOverheid. En adviseert dat de overheid daar rap API’s voor moet gaan aanbieden.

Beleidstechnisch allemaal verschillende uitdagingen, waar voortvarend beleid op wordt gemaakt, zoals kaders over hoe we zorgen dat de bronontsluiting verantwoord en veilig werkt.

Nu de link naar de techniek

Het risico is dat de oplossingen die binnen deze vier beleidsdossiers worden worden bedacht los van elkaar staan en leiden tot andere technische kaders. En dan is het ineens zo dat elke overheidsbron vier verschillende bronontsluitingen moet regelen, elk met een eigen techniek, compliancy, audits, implementatiekosten, onderhoud etc. Waarom? Omdat er dan geen technische oplossing is die binnen alle kaders past, dus moeten er meerdere oplossingen komen. Het lijkt vreemd als je het zo leest, maar deze dossiers ontstaan niet allemaal op hetzelfde moment, hebben een andere aanleiding, ander tempo, zitten bij andere afdelingen of zelfs andere departementen…

Mijn taak is o.a. om dit soort dingen te detecteren en te zorgen dat het niet op die manier uit elkaar loopt. Door bijvoorbeeld voor te stellen dat in ieder geval aan de leverende kant één kader wordt gehanteerd voor de bronontsluiting, en idealiter te zorgen dat er technisch gezien steeds dezelfde standaarden worden gebruikt. Er zijn echter wat verschillen die in de aard van de informatiestroom zijn besloten. Zo is de EDI Wallet gebaseerd op het ‘valideren’ van een gegeven dat men al heeft in de bron, heeft SDG-OOTS een manier van toestemming regelen die anders werkt dan die van de datadelers etc.

Daarom kijken we, direct bij het ontwikkelen van beleid, ook gelijk in Digilab wat de technische mogelijkheden zijn. Is wat we beleidsmatig willen wel technisch mogelijk? En moeten we dan precies voorschrijven? Door de experimenten realistisch uit te voeren kom je daar achter voordat je zaken voorschrijft waar iedereen last van heeft.

Deze week is de intake geweest voor een nieuw project bij Digilab: een concrete test voor uniforme bronontsluiting, samen met stichting RINIS, gemeente Utrecht, gemeente Rijswijk en leveranciers. Men zag de bui al hangen, 342 gemeenten die allerlei bronnen zouden moeten ontsluiten op vier manieren, dat leek geen geweldig plan. De technische deep-dive deze week was veelbelovend, alle betrokken partijen zijn enthousiast over de aanpak.

Als je denkt, mijn organisatie wil wel meedoen met die proef want wij zien een soortgelijk probleem, neem vooral contact op met Digilab.

Kleine innovatie van de week

In Digilab is terloops een klein tooltje gemaakt die kijkt naar welke services je als organisatie aanbiedt, van elke service de OpenAPI specificaties ophaalt en deze gebruikt om automatisch een DCAT Turtle file aan te maken. Op die manier duikt de Dataservice self description vanzelf op in je Catalogus als je de Federated Service Connectivity standaard gebruikt. Als het een FDS Dataservice betreft sta je dan ook automatisch in de landelijke catalogus als je dat wilt, zowel de technische info (hoe connect ik) als de semantische kant (wat biedt de service). Want waarom zou je het handmatig op allerlei plekken invullen als het ook automatisch kan? Een inzicht daarbij is dat wanneer je de OpenAPI specificatie goed uitgewerkt, veel metadata in andere formaten daar uit afgeleid kan worden.