Domein Uitwisselingsfundament Evaluatie StUF 12 februari 2025

Colofon

Projectnaam: Evaluatie StUF

Auteurs: M. Nijland (InnoValor Advies), R. Kosman (InnoValor Advies), L. Olthof (InnoValor Advies)

Opdrachtgever: Forum Standaardisatie 

Dit document verschijnt onder de Creative Commons licentie: CC0 1.0 Universeel (CC0 1.0)

Publiek Domein Verklaring

Managementsamenvatting

StUF (Standaard Uitwisseling Formaat) is een verzameling standaarden die gebruikt worden voor de elektronische uitwisseling van informatie tussen overheidsorganisaties, met name voor de uitwisseling van basisregistraties. De standaard staat sinds 2008 op de 'Pas toe of leg uit'-lijst van Forum Standaardisatie. Deze evaluatie onderzoekt of StUF nog steeds voldoet aan de criteria voor opname op deze lijst, gezien de technologische ontwikkelingen en de opkomst van alternatieven zoals API's.

Uit deze evaluatie komen de volgende conclusies naar voren:

• Het huidige toepassingsgebied van StUF is niet meer passend. Alternatieven zoals API's zijn in veel gevallen meer geschikt voor eenvoudige bevragingen van basisgegevens.
• De toegevoegde waarde van StUF staat ter discussie. Hoewel StUF functionaliteit biedt waarvoor nog geen alternatieven bestaan, zoals complexe bevragingen met historie, geven experts in veel gevallen de voorkeur aan API's voor nieuwe voorzieningen.
• Het draagvlak voor StUF neemt af. Experts verwachten dat het gebruik van StUF in de komende jaren significant zal afnemen door de opkomst van alternatieven.
• Het beheer van StUF is een aandachtspunt. De doorontwikkeling van StUF is stopgezet en experts uiten zorgen over de continuïteit van het beheer.
• De opname van StUF op de 'Pas toe of leg uit'-lijst staat ter discussie: Experts hebben uiteenlopende meningen over de wenselijkheid van het verplicht stellen van StUF.

Vanuit de analyse van de interviews en de bovenstaande conclusies zijn de volgende aanbevelingen opgesteld:

• Aan VNG Realisatie om een strategie en roadmap op te stellen voor de transitie van StUF naar alternatieven, waaronder API’s. Onderdeel hiervan in het creëren van een overzicht van alternatieven en nog te ontwikkelen alternatieven voor de verschillende onderdelen in de StUF familie.
• Aan VNG Realisatie om samen met gemeenten en leveranciers te onderzoeken hoe het functioneel toepassingsgebied het beste herzien kan worden aan de hand van domeinspecifieke gesprekken. Dit kan onderdeel zijn voor de strategie en roadmap voor de transitie van StUF naar alternatieven, waaronder API’s.
• Aan VNG Realisatie om een toetsingsprocedure aan te vragen bij het Forum Standaardisatie, om:
  • Het toepassingsgebied te herformuleren zodat dit reflecteert waar StUF meerwaarde heeft en verplicht toegepast moet worden.
  • Aan de hand van het nieuw geformuleerde toepassingsgebied te bepalen of (delen van) StUF in zijn geheel verplicht moet worden gesteld middels opname op de ‘Pas toe of leg uit’-lijst.
  • Aan de hand van het nieuw geformuleerde toepassingsgebied te bepalen of (delen van) StUF moet worden aanbevolen middels opname op de lijst aanbevolen standaarden.
  • Aan VNG Realisatie en het Forum Standaardisatie om te achterhalen hoe de transitie en het al dan niet gebruik van de bijbehorende standaarden duidelijk gecommuniceerd kan worden aan gebruikers.
  • Uit de evaluatie blijkft de noodzaak van een zorgvuldige transitie naar een nieuwe informatiearchitectuur, waarbij de voordelen van API's worden benut zonder de functionaliteit te verliezen die StUF op dit moment nog biedt.

Inleiding

Achtergrond

Forum Standaardisatie is een onafhankelijke overheidsorganisatie die de overheid adviseert over het gebruik van open ICT standaarden in de digitale overheid. Open standaarden zorgen voor een betere uitwisselbaarheid en toegankelijkheid van gegevens. Forum Standaardisatie zorgt ervoor dat digitale gegevens veiliger en gemakkelijker met elkaar uitgewisseld kunnen worden. Zo helpen zij de samenwerking binnen de publieke sector te verbeteren. In opdracht van het Forum Standaardisatie voert Bureau Forum Standaardisatie (BFS) initiatieven uit om het gebruik van open standaarden bij de overheid te bevorderen.

Een van de manieren van Forum Standaardisatie om de onderlinge samenwerking van overheden te bevorderen is door open standaarden te toetsen en voor te schrijven aan publieke organisaties. Op de ‘Pas toe of leg uit’-lijst (verplichte standaarden) van het Forum Standaardisatie staan standaarden die overheden verplicht moeten toepassen volgens ‘Pas toe of leg uit’-verplichting op het moment dat ze een ICT-dienst of -product aanschaffen dat binnen het desbetreffende toepassingsgebied valt van de standaard.

De ‘Pas toe of leg uit’-lijst wordt onderhouden op basis van een open procedure. De toetsing bij aanmelding is een momentopname. Als een standaard een aantal jaar op de ‘pas toe of leg uit’-lijst staat, kan het zijn dat de relevantie, het draagvlak, het toepassingsgebied of de marktpartijen veranderd zijn. Er kunnen dan vragen ontstaan als: Heeft de standaard nog toegevoegde waarde? Wordt de standaard nog door voldoende marktpartijen ondersteund?

In zulke gevallen kan het Forum Standaardisatie besluiten om standaarden te evalueren. Voor 2024 evalueert het Forum Standaardisatie de Standaard Uitwisseling Formaat (StUF) van de ‘Pas toe of leg uit’-lijst.

De beschrijving van StUF op de website van Forum Standaardisatie luidt als volgt: Standaard Uitwisseling Formaat (StUF) is een set basisafspraken over het uitwisselen van gegevens tussen applicaties in het gemeentelijke veld. StUF beschrijft de generieke toepassing van die berichten, niet de specifieke gegevens erin. Als overheidsorganisaties gegevens in basisregistraties (informatie over personen, adressen of bijvoorbeeld gebouwen) uitwisselen, doen ze dat via standaarden die gebaseerd zijn op StUF.

Aanleiding

Op 12-11-2008 is de StUF standaard opgenomen op de ‘Pas toe of leg uit’-lijst van het Forum Standaardisatie. 

In het Forumadvies d.d. 25 maart 2019 is, in het kader van regulier onderhoud van de ‘Pas toe of leg uit’-lijst van het Forum Standaardisatie, de StUF standaard geëvalueerd in hoeverre de informatie over deze standaard nog actueel was. De belangrijkste bevindingen uit de evaluatie van 2019:

De opkomst van JSON ten koste van XML en de verschuiving naar nieuwe informatiearchitecturen zoals Common Ground en Haal Centraal werden als belangrijke ontwikkelingen genoemd die invloed hebben op de toepassing van StUF.

De complexiteit van de standaard en de ruimte voor verschillende interpretaties, evenals de incompatibiliteit van sommige implementaties, werden geïdentificeerd als knelpunten.

De versie van StUF op de 'Pas toe of leg uit'-lijst kwam niet overeen met de actuele versie die in de praktijk werden gebruikt.

Het toepassingsgebied van StUF moest worden geherformuleerd volgens de standaardsyntaxis die het Forum Standaardisatie sinds 2017 hanteert.

Op basis van deze bevindingen is er destijds geadviseerd om een volledig expertonderzoek uit te voeren om de standaard StUF te toetsen aan de criteria voor de 'Pas toe of leg uit'-lijst. Dit advies heeft destijds echter geen opvolging gekregen.

Aanleiding voor het Forum Standaardisatie om de opdracht te geven om de StUF-standaard te evalueren, en om de impact van bovengenoemde aanbevelingen en de ontwikkelingen van de afgelopen vijf jaar te evalueren.

Aanpak

Bij de uitvoering van de evaluatie is de volgende aanpak gehanteerd: 

Kick-off bijeenkomst: vaststelling van de scope en aanpak van het onderzoek, en de te interviewen experts (Bureau Forum Standaardisatie en InnoValor Advies)

Bureau-onderzoek: verkenning naar beschikbaar materiaal over gebruik, beheer en toepassing van de standaard. Gericht op zowel een eerste inhoudelijke indicatie, als op verkenning van relevante partijen.

Interviews: met vertegenwoordigers van beheerder, gebruikers, en leveranciers (samen: experts) die in hun werk met de standaard te maken hebben. De evaluatiecriteria (zie paragraaf 1.3.2) zijn hierbij als leidraad gebruikt.

Op basis van het bureau-onderzoek is er contact gezocht met de experts voor semigestructureerde interviews. De resultaten zijn verwerkt in dit rapport. De uitwerking van de evaluatie is in twee rondes gedeeld met dossierhouders en opdrachtgever ter review. Na review is er besloten om aanvullende interviews te houden om extra verdieping te geven daar waar nodig.

Betrokken experts evaluatie

De volgende experts zijn geïnterviewd in het onderzoek:

Voornaam	Achternaam	Organisatie
Theo John  Robert Ilias	Peters van Dijk Melskens Cheqri	VNG Realisatie
Frank	Terpstra	Geonovum
Brenda	de Graaf	Gemeente Den Haag
Cor	Franke	Franke Interim Management
Jacob	Versteeg	Centric
Cathy	Dingemanse	HaalCentraal programma (RvIG)
Martijn	van Rees	Gemeente Rotterdam
Arjen	Brienen	Gemeente Delft & VNG Realisatie
Ruud	Kathmann	Waarderingskamer
Edwin	Wisse	Logius
Janette	Storm	Kadaster

Tabel 1 - Betrokken experts evaluatie

Evaluatiecriteria

De evaluatie van StUF heeft plaatsgevonden op basis van de onderstaande criteria, die daarnaast ook als leidraad zijn gebruikt tijdens de interviews.

Criteria	Subvragen
Functioneel toepassingsgebied	Is het functioneel toepassingsgebied nog juist? Is dit duidelijk en concreet geformuleerd? Weet een potentiële gebruiker wanneer de standaard van toepassing is?
Toegevoegde waarde	Heeft de standaard nog toegevoegde waarde? Welk reëel en als zodanig ervaren probleem heeft de standaard opgelost?
Draagvlak	Is er nog voldoende draagvlak voor de standaard? Hoe staat het met gebruik van de standaard, waar wordt deze toegepast binnen de overheid en wat zijn de toekomstige ontwikkelingen? Zijn er voldoende marktpartijen die de standaard ondersteunen?
Open standaardisatieproces	Voldoet het beheer en doorontwikkeling aan de vereiste criteria? Zijn er zaken veranderd in het beheer van de standaard sinds de plaatsing op de ‘Pas toe of leg uit’-lijst? Voldoet het beheer van de standaard nog aan de criteria voor openheid en is het besluitvormingsproces nog goed en actueel gedocumenteerd? Is de beheerder van de standaard nog actief?
Adoptie	Heeft opname op de ‘Pas toe of leg uit’-lijst de adoptie bevorderd? Ondersteunen de experts de opname van de standaard op de ‘Pas toe of leg uit’-lijst? Wat zijn eventuele redenen om dit niet te ondersteunen? Wat zijn redenen om de standaard wel op de lijst te houden?
Opname-adviezen	Bij verschillende standaarden zijn opname-adviezen meegegeven door het Forum om de adoptie te bevorderen. Zijn deze adviezen opgevolgd en/of zijn er nieuwe adoptie adviezen mee te geven?
Lopende ontwikkelingen	Zijn er relevante lopende ontwikkelingen? Wat zijn de toekomstige ontwikkelingen met betrekking tot de standaard (of gerelateerde standaarden) en het interoperabiliteitsprobleem dat de standaard oplost? Heeft dit impact voor de positie van de standaard op de lijst? Zijn er nieuwe versies nieuwe standaarden op komst, is er een noodzaak tot verplicht gebruik hiervan, en is deze mogelijk geschikt voor opname op de lijst?

Tabel 2 – Evaluatiecriteria en onderzoeksvragen

Toelichting StUF standaard

StUF is een universele berichtenstandaard voor het elektronisch uitwisselen van gegevens tussen applicaties. Het domein van StUF omvat de uitwisseling van administratieve gegevens tussen overheidsorganisaties (basisregistraties en landelijke voorzieningen), en informatieketens van gemeenten. StUF staat sinds 2008 op de ‘Pas toe of leg uit’-lijst. StUF bevat zelf geen berichten maar wel bouwstenen en richtlijnen waarmee berichtstandaarden kunnen worden samengesteld. StUF is beschreven in XML. De StUF standaard beoogt te voorkomen dat steeds opnieuw maatwerk moet worden ontwikkeld, beperkt het overleg voor het realiseren van koppelingen tussen systemen en bevordert de interoperabiliteit. Voor beter zicht op de StUF standaard zal hieronder de StUF familie worden toegelicht.

De StUF familie

StUF is een familie van samenhangende gegevens- en berichtenstandaarden, en de meest actuele versie van de onderlaag is 3.01. StUF is op te delen in een aantal onderdelen van generiek tot specifiek. De StUF standaard opgenomen op de ‘Pas toe of leg uit’-lijst beperkt zich tot de StUF protocolverbindingen, de StUF onderlaag en de StUF horizontale sectormodellen.

Figuur 1 – Schematische weergave van de structuur van de StUF standaard

• StUF protocolbindingen 3.02: beschrijft de afspraken voor het gebruik van StUF.
• StUF onderlaag 3.01: maakt gebruik van voorzieningen die de protocolbindingen biedt.
• StUF horizontale sectormodellen: generieke sectormodellen die wel specifiek toepasbare berichten kunnen vormen. De sectormodellen zijn gebaseerd op een drietal informatiemodellen (RSGB, RGBZ, IMZTC) en een StUF onderlaag en protocolbindingen.
  • StUF-BG 3.10 (Basisgegevens),
  • StUF-ZKN 3.10 (Zaken),
  • StUF-ZTC 3.10 (Zaaktypen(-catalogus).
• StUF verticale sectormodellen: meerdere sectormodellen zijn ontwikkeld door externe partijen en door hen beheerd.
  • StUF-EF 3.15 (e-Formulieren) – in beheer VNG Realisatie,
  • StUF-WOZ 3.13 (Wet Onroerende Zaken) – in beheer Waarderingskamer,
  • StUF-HR 3.00 (Handelsregister) – in beheer Handelsregister,
  • StUF Geo IMGeo 1.3 (Topografie) – in beheer Geonovum,
  • StUF-RIHa 3.01 (Referentie Informatiemodel Handhaving) – in beheer ILT,
  • StUF LVO 3.12 (Landelijke Voorziening Omgevingsloket) – in beheer Ministerie van IenM,
  • StUF Wkpd 0102 (Wet Kenbaarheid Publiekrechtelijke Beperkingen) – in beheer Kadaster,
  • StUF-LVBAG 3.10 (Landelijke Voorziening voor de Basisregistratie Adressen en Gebouwen) – in beheer Kadaster.
• StUF koppelvlakken: specificeert hoe gegevensuitwisseling tussen applicaties en voorzieningen eruit moet zien. Daar waar sprake is van een duidelijk knooppunt of eindpunt is StUF verplicht voor de aansluiting, en is er sprake van een koppelvlak. StUF-CORV 1.0 is een voorbeeld van een StUF-koppelvlak voor Jeugdzorg voor de uitwisseling van gegevens tussen gemeenten en de overige partijen in de Jeugdzorg. 

Gebruik StUF

Uit de Monitor Open Standaarden 2023 komt naar voren dat alleen al het GGK (Gemeentelijk Gegevens Knooppunt) 10 miljoen berichten per jaar verwerkt met een StUF envelop. Maar ook mutaties op BAG, Kadaster, BRP en vele andere registraties worden via StUF berichten uitgewisseld. Dit gaat dus over vele miljoenen berichten per jaar.

Beheerder VNG Realisatie ziet een toename in de softwarecatalogus in het aantal leveranciers dat StUF aanbiedt. Wel zijn er minder softwareproducten waarin StUF een rol speelt. De Monitor Open Standaarden 2023 laat hetzelfde beeld zien. Onderstaande tabel geeft een beeld van de adoptie van de twee StUF onderdelen (StUF-BG en StUF-ZKN) door de ICT-markt.

	Totaal		StUF-BG		Stuf-ZKN
Aantal leveranciers	299	(276)	72	(67)	58	(55)
Aantal softwareproducten (incl. versies)	2961	(3632)	1201	(1420)	738	(501)
wv. beschikbaar/in gebruik	1447	(1590)	368	(460)	226	(187)
wv. gepland/in ontwikkeling	91	(109)	50	(60)	26	(16)

Tabel 3 Peildatum april 2023 (tussen haakjes de cijfers van de vorige monitor)
(bron VNG-Realisatie)

Uit het overzicht is af te lezen dat het aantal leveranciers is gestegen (overall een stijging van 8%). Dit komt onder andere doordat het gebruik van de softwarecatalogus niet meer van een convenant afhankelijk is. Ondanks meer leveranciers is het aantal softwarepakketten gedaald met 18%. Er is sprake van enkele toetreders en er is ook sprake van een beweging van samenvoeging door samenwerking tussen partijen en overname van pakketten door een leveranciersgroep.

VNG Realisatie zet in het kader van Common Ground in op het gebruik van API-standaarden. In verband daarmee worden er API standaarden ontwikkeld als alternatief voor de StUF standaarden. Ook wordt gestuurd op het vervangen van de StUF standaarden in het gemeentelijke IT landschap. Deze transitie is een doorlopend proces en de verwachting is dat de StUF standaarden voorlopig nog wel in gebruik zullen blijven.

Evaluatie StUF

De evaluatie van StUF heeft als doel om informatie te verschaffen over de huidige relevantie van de standaard en het toepassingsgebied, en de stand van zaken rond de adoptie van de standaard. In dit hoofdstuk wordt de StUF standaard geëvalueerd tegen de evaluatiecriteria, zoals beschreven in paragraaf 1.3.2.

Toepassingsgebied

StUF kent het volgende functioneel toepassingsgebied. StUF moet worden toegepast bij het uitwisselen van gegevens tussen applicaties van overheidsorganisaties (basisregistraties en landelijke voorzieningen) en gemeentebrede informatieketens en -functionaliteit, met als doel:

Uitwisseling en bevraging van basisgegevens die behoren tot een aantal wettelijk vastgestelde basisregistraties, zoals Personen (GBA), Adressen (BRA), Gebouwen (BGA), Kadaster (BRK), Nieuw Handelsregister (NHR) en Waarde Onroerende Zaken (WOZ);

Uitwisseling en bevraging van zaakgegevens die behoren tot de producten- en dienstenportfolio van gemeenten; 

Uitwisseling van domein- of sectorspecifieke gegevens waarin ook basis- en/of zaakgegevens voorkomen en waarvoor geen andere (inter)nationale (XML-gebaseerde) berichtenstandaard is vastgesteld.

Experts geven aan dat StUF nog intensief gebruikt wordt in verschillende domeinen, maar de rol en toepassing van StUF verandert door de beschikbaarheid van alternatieven waaronder API’s. Via een API kan een applicatie automatisch toegang krijgen tot bepaalde informatie en/of functionaliteiten. Dit heeft invloed op de toepasbaarheid van het functioneel toepassingsgebied. Vrijwel alle experts zijn erover eens dat het huidige geformuleerde toepassingsgebied niet passend meer is voor StUF. Dit speelt met name bijeenvoudige bevragingen van basisgegevens die behoren tot een aantal wettelijk vastgestelde basisregistraties en de uitwisseling en bevraging van zaakgegevens. In die situaties bieden alternatieven, zoals API’s voor basisregistraties of de zaakgericht API’s, afhankelijk van de context, een meer eenvoudige manier van bevragen of uitwisselen dan StUF. Volgens enkele experts zal het blijven verplichten van StUF in deze situaties het gebruik van deze API’s in de weg staan. Andere experts beargumenteren dat organisaties ondanks de verplichting alsnog kunnen kiezen voor API’s ondanks de verplichting, door het gebruik van de ‘Leg uit’-optie.

Onder de experts is consensus dat het toepassingsgebied herzien moet worden en dat StUF alleen daar moet worden gebruikt waar StUF meerwaarde heeft (zie paragraaf 3.1.2). Dit zou organisaties ertoe bewegen om zoveel mogelijk middels alternatieven basis- en zaakgegevens uit te wisselen en te bevragen. VNG Realisatie benoemt dat het verduidelijkt moet worden dat de toepassing van StUF betrekking heeft op SOAP XML gebaseerde bevragingen en uitwisseling van gegevens. Voor andere uitwisselingspatronen dienen gebruikers de desbetreffende relevante standaarden en ontwerpprincipes te gebruiken, denk aan REST-API Design Rules voor het aanbieden van REST-API’s ten behoeve van het ontsluiten van overheidsinformatie en/of functionaliteit.

Toegevoegde waarde 

Toegevoegde waarde (van delen) van StUF staat ter discussie

StUF is een familie van standaarden en kent onderdelen die nog veel in gebruik zijn bij organisaties. StUF is breed inzetbaar en nog niet voor alle functionaliteiten van StUF zijn alternatieven beschikbaar. Daar waar wel alternatieven zijn, bijvoorbeeld in de vorm van API’s, geeft het merendeel van de experts de voorkeur aan het inzetten van dat alternatief boven het gebruik van StUF bij een nieuwe of te ontwikkelen voorziening (denk aan applicaties of systemen). Deze alternatieven dragen bij aan het realiseren van ‘data bij de bron’-gedachtegoed van het Federatief Datastelsel en Common Ground programma’s, waarbij toegewerkt wordt naar een andere informatiearchitectuur. Het minimaliseren van data-uitwisseling wordt hiermee gerealiseerd. 

Alle experts geven aan dat de StUF standaard een complexe standaard is. STUF is ontworpen om gegevensuitwisseling mogelijk te maken tussen verschillende systemen binnen de Nederlandse overheidssector. Dit betekent dat het een breed scala aan gegevens en processen moet ondersteunen, wat de structuur complex maakt. Meerdere experts van zowel uitvoerende overheden als gemeenten geven aan dat deze complexiteit van de standaard inherent is aan de complexiteit en veelzijdigheid van het domein. Het uitwisselen en synchroon houden van basisgegevens wordt gezien als ingewikkeld. Dit geldt voor zowel materiële als formele historie. StUF is daardoor moeilijk te doorgronden voor een ontwikkelaar, wat kan leiden tot verschillen in implementaties. Verschillen in implementaties is tevens iets wat duidelijk naar voren komt in het rapport van de Software Improvement Group (SIG) uit 2015 waarin er een analyse wordt gemaakt van de StUF BG standaard. In dit rapport is onderzocht of StUF BG bijdraagt aan interoperabiliteit, kostenverlaging, marktwerking en innovatie. SIG concludeert dat het verplicht gebruik van StUF-BG slechts een beperkte garantie geeft voor een verbetering van de interoperabiliteit. Bij iedere implementatie ontstaat er een sub-standaard waardoor er geen sprake is van kostenverlaging en marktwerking. Diverse experts geven aan dat StUF zo complex is dat maanden inleertijd nodig is om het te gebruiken waardoor kosten voor een koppeling oplopen. Daarbij wordt het steeds moeilijker om specialisten te vinden die met StUF kunnen werken.

Om een zo compleet mogelijk beeld van de voor- en nadelen van het gebruik van StUF te schetsen, worden hieronder de situaties beschreven waar het gebruik van StUF meerwaarde heeft en de situaties waarin het gebruik van alternatieven, waaronder API’s, de voorkeur genieten boven StUF.

Situaties waar StUF (nog) geen alternatieven kent

Meerdere experts geven aan dat er meerwaarde zit in de volwassenheid van StUF. Het is een volledig uitontwikkelde standaard die, ondanks een aantal belemmeringen, in het algemeen goed werkt voor de meeste organisaties. 

StUF voorziet in de behoefte rond complexe data en bedient complexe datamodellen. Experts geven aan dat in die complexiteit meerwaarde zit. StUF kent een breed scala aan functionaliteiten en wordt ingezet voor complexe bevragingen en uitwisseling van gegevens. Maar niet voor iedere functionaliteit die mogelijk gemaakt wordt door StUF, is een gestandaardiseerd alternatief. Hierbij wordt echter opgemerkt dat dit ook niet nodig is. Voornamelijk moet gekeken worden wat afnemers nodig hebben. API’s bieden een alternatief voor een deel van die functionaliteit. Afnemers kunnen de transistie inzetten naar de API’s. 

Hieronder worden een aantal situaties geschetst waar volgens de meeste experts StUF nog geen gestandaardiseerde alternatieven kent.

Notificaties/kennisgevingen

Met name voor processen met persoonsgegevens zijn proactieve notificaties gewenst, zoals bij wijzigingen in de basisregistraties. Een aantal processen bij gemeenten is op deze manier al ingericht. Denk aan processen die actuele gegevens nodig hebben bijvoorbeeld in het sociaal domein, zorg, leerplicht of belastingzaken. Aan de hand van een wijziging moet een proces in gang worden gezet. Hiervoor wordt nu nog StUF toegepast. Een volwaardig proactief notificatie alternatief is binnen Common Ground of Haal Centraal nog niet in de breedte toe te passen. In de BRP Update API specificatie wordt er een mogelijkheid gegeven om kennisgevingen te implementeren, waar gemeenten zelf voor moeten zorgen. Deze BRP Update API stuurt direct notificaties naar afnemers als er wijzigingen zijn. De werking is anders dan StUF-kennisgevingen waarin er actief een notificatie wordt gestuurd als er een wijziging is. Op termijn zal Rijksdienst voor Identiteitsgegevens hiervoor met een product komen, deze is er nog niet. Tot die tijd is er geen gestandaardiseerd alternatief voor StUF.

Massaliteit van bevragen

In bepaalde situaties is het wenselijk om in bulk bevragingen uit te voeren. StUF kan goed omgaan met het verwerken en uitwisselen van grote hoeveelheden aan informatie. Op dit moment is er voor massaliteit geen gestandaardiseerd alternatief voor StUF. API’s zijn bijvoorbeeld op dit moment hierop nog niet ingericht.

Informatiemodellen van StUF

Er is geen ander informatiemodel naast het Referentiemodel Stelsel van Gemeentelijke Basisgegevens (RSGB) dat de verbinding tussen basisregistraties beschrijft. Het Referentiemodel Gemeentelijke Basisgegevens Zaken (RGBZ) is het informatiemodel voor zaakgericht werken, ook hiervoor is geen alternatief. Basisregistraties hebben eigen informatiemodellen.

In de pilot met VNG Realisatie in 2018 is echter vastgesteld dat het RSGB niet nodig is voor het bevragen van basisregistraties in samenhang. Dit wordt in de huidige praktijk al gerealiseerd zonder afhankelijkheid van het RSGB.

Deze modellen missen echter de verbinding met andere databronnen. De StUF-informatiemodellen (RSGB) en (RGBZ) zijn verouderd en sluiten niet meer exact aan op de basisregistraties. In het Gemeentelijk GegevensModel (GGM) worden de informatiemodellen RSGB en RGBZ gebruikt. Er zijn op dit moment geen alternatieven voor deze informatiemodellen. VNG Realisatie geeft aan dat er echter wel ingezet moet worden op een gestandaardiseerd, en up-to-date, informatiemodel voor het verbinden van databronnen, waaronder basisregistraties, die gebaseerd is op het ‘data bij de bron’-gedachtegoed. Dit vraagt om een transitie van informatiemodellen.

Situaties waar alternatieven (API’s) boven StUF gewenst zijn

Andere experts geven aan dat sommige situaties interoperabiliteit ook met andere standaarden en oplossingen, waaronder API’s, gerealiseerd kan worden. Enkele voorbeelden hiervan worden hieronder geschetst.

Eenvoudige bevragingen basisregistraties

Voor eenvoudige bevragingen van basisgegevens die behoren tot een aantal wettelijk vastgestelde basisregistraties zijn alternatieven beschikbaar middels API’s, namelijk Basisregistratie Personen (BRP) API, Basisregistratie Kadaster (BRK) API, Waardering Onroerende Zaken (WOZ) API en de Basisregistratie Adressen en Gebouwen (BAG) API. 

VNG Realisatie heeft oktober 2022 de Haal Centraal API-specificaties, waar de bovenstaande API’s toe behoren, tot standaard verklaard. Daarmee adviseert VNG Realisatie gemeenten om deze Haal Centraal API-specificaties uit te vragen als er een nieuwe voorziening wordt aangeschaft. Iedere organisatie kan bij het herzien van de informatiehuishouding of bij het aanschaffen van nieuwe voorzieningen ervoor kiezen om API’s uit te vragen in plaats van StUF. Meerdere experts geven aan de voorkeur te hebben dat, bij nieuwe voorzieningen, geen gebruik meer gemaakt wordt van StUF, maar overgegaan wordt op deze API’s. Daarmee geven deze experts aan de toekomst te zien in deze API’s.

Bevragingen over informatieproducten verlopen steeds vaker middels API’s. Daarmee ontvangt een afnemer niet alle data van zijn informatieverzoek en moet daarmee zelf aan de slag om het tot een geheel te vormen maar ontvangt het een vastgesteld informatieproduct waarmee de afnemer gelijk aan de slag kan. RvIG noemt dat middels de BRP API bijvoorbeeld voor een brief drie informatieproducten aangeboden worden: aanschrijfwijze, aanhef en adressering. Precies dat wat nodig is voor een juiste adressering. De traditionele voorzieningen leveren hiervoor 23 losse persoonsgegevens inclusief partnergegevens. 

Uitwisseling en bevraging zaakgegevens

Voor de uitwisseling en bevraging van zaakgegevens die behoren tot de producten- en dienstenportfolio van gemeenten zien meerdere experts ook toegevoegde waarde in het gebruik van de API’s voor Zaakgericht Werken boven het gebruik van StUF voor zaakgegevens. StUF wordt nog veelvuldig gebruikt in deze context, maar op het gebied van zaakgegevens wordt er al veel gewerkt met API’s en is er een beweging gaande naar andere manieren van gegevensuitwisseling die niet gebaseerd is op de StUF standaarden.

Voorbeeld: bepalen van gezag over een kind

Alleen in de BRP staat vastgelegd als er een gerechtelijke uitspraak is geweest. Voor het overgrote deel van de kinderen is dit niet het geval en moet een gezagsrelatie afgeleid worden uit gegevens uit de BRP. Gegevens over ouders, het huwelijk, nationaliteit, achtergrond enzovoort is nodig om te bepalen wie gezag heeft. Al die gegevens werden verstrekt aan een afnemer. Met een informatieproduct wordt er bepaald voor een kind wie het gezag heeft (als dat kan). Alleen dat deel van de informatie wordt vervolgens verstrekt aan de afnemer. Dit is gebruikt en getest door verschillende partijen waaronder Politie, Marechaussee, en Veilig Thuis organisaties.

Generatiewissel gegevensuitwisseling - transitie van StUF naar alternatieven

Alle experts zien meerwaarde in alternatieven voor StUF. Experts benoemen echter twee voorwaarden voor de transitie van StUF naar die alternatieven. Enerzijds wordt de beschikbaarheid van alternatieven voor de functionaliteit van StUF genoemd. Daarbij zou het helpen als er een compleet overzicht (mapping) gemaakt wordt van welke alternatieven (waaronder API’s) de verschillende onderdelen van StUF zouden kunnen vervangen. 

Anderzijds wordt de impact van de transitie op de organisaties genoemd. Meerdere experts geven aan dat in welke mate organisaties meerwaarde zien in de transitie van StUF naar alternatieven afhangt van de huidige informatievoorziening en -architectuur van gemeenten en of die in hoge mate gebaseerd is op het repliceren van (deel)kopieën van basisregistraties en zaakgegevens. De meeste gemeenten hebben een gegevensmagazijn en zij maken hiervan kopieën, hiervoor wordt StUF gebruikt.

Hoewel veel bestaande systemen en voorzieningen zijn aangesloten via StUF en draaien op StUF-gebaseerde koppelvlakken, kan een transitie naar alternatieven zorgvuldig moeten worden gepland. Een veelvoorkomende houding “Het werkt, dus waarom veranderen”, wordt door experts als een belemmerende factor gezien. De omvang van de verandering, bijvoorbeeld het aanpassen van 20 tot 30 systemen, vraagt om een gestructureerde aanpak. Dit betekent niet dat systemen volledig opnieuw moeten worden ingericht, maar dat er plannen, roadmaps en tussenoplossingen nodig zijn om de overgang soepel te laten verlopen. Dit vereist mandaat, tijd en financiële middelen. Bovendien is het niet altijd wenselijk als voorzieningen, ook al is het incidenteel, gebruik maken van complexere bevragingen waarvoor er geen alternatieve oplossingen voor StUF zijn. In die situatie wordt StUF gebruikt, geven enkele experts aan. 

Tegelijkertijd beamen experts dat als afnemers bezig zijn met het opnieuw inrichten van voorzieningen het de voorkeur geniet om gestandaardiseerde alternatieven (waaronder API’s), daar waar mogelijk, te gebruiken in plaats van StUF. Bovendien, in de situatie waarin een organisatie in haar informatiehuishouding nauwelijks of geen gebruik maakt van StUF, is het onwenselijk om nieuwe systemen en voorzieningen via de StUF standaarden in te richten. Met name als er geen sprake is van complexere bevragingen zijn er eenvoudigere oplossingen dan StUF die dezelfde mogelijkheden bieden, zoals API’s. 

Draagvlak

Draagvlak voor StUF staat ter discussie.

Alle bevraagde experts beamen dat het gebruik van StUF groot is. Ook ziet beheerder VNG Realisatie nog steeds een toename in de softwarecatalogus van het aantal leveranciers dat StUF aanbiedt. Wel zijn er minder softwareproducten waarin StUF een rol speelt (zie ook paragraaf 2.2).

Het hoge gebruik staat echter niet gelijk aan het draagvlak. Experts zouden in veel gevallen over willen gaan naar alternatieven (waaronder API’s) voor bevragingen en uitwisseling. Echter zijn er nog niet op alle vlakken gestandaardiseerde alternatieven voor StUF.

Experts verwachten dat het gebruik van StUF uiteindelijk zal afnemen dankzij de beweging naar alternatieven (waaronder API’s) voor bevragingen en uitwisseling. Experts geven aan dat dit niet een snelle beweging zal zijn maar een doorlopend proces en dat er in de komende 5 tot 10 jaar wel een significante afname zal zijn van het gebruik van StUF. Enerzijds moeten gemeenten hun architectuur aanpassen en anderzijds moeten de alternatieven voor de functionaliteit van StUF beschikbaar zijn. Een enkele expert geeft aan te verwachten dat StUF zeker nog vele jaren gebruikt zal worden, simpelweg omdat de informatiehuishoudingen van gemeenten niet zo snel veranderen.

Transitie van StUF naar alternatieven, waaronder API’s

Grote gemeenten zijn bezig met transitieplannen voor StUF. Gemeente Den Haag en gemeente Rotterdam hebben een duidelijke visie op Common Ground en de inzet van API’s. Leveranciers, zoals Centric, verwachten dat dit de koplopers zijn en dat kleinere gemeenten zullen volgen. Wat duidelijk wordt in de evaluatie is dat de impact van de transitie bepaald wordt door informatiehuishouding en -architectuur van gemeenten en in hoeverre deze gebruik maakt van StUF.

De meeste leveranciers in het domein hebben StUF geïmplementeerd in hun softwareproducten. Sommige leveranciers hebben dat niet gedaan. Voor hen is StUF complexer te implementeren dan API’s. Ontwikkelaars vinden API’s vaak eenvoudiger te implementeren dan StUF. Steeds meer leveranciers willen over op het gebruik van API’s, ook grote leveranciers als Centric en PinkRoccade zien hier een toekomst in. Centric is ondertekenaar van het Groeipact waarbij leveranciers, klanten en ketenpartners samenwerken aan het realiseren van de Common Ground visie.

Enkele experts geven aan dat sommige leveranciers primair inzetten op de API’s. Zij bieden implementaties waar volledig met API’s worden gewerkt, zoals bij de Gemeente Den Haag.

Beheer

Beheer van StUF staat ter discussie.

De StUF standaard opgenomen op de ‘Pas toe of leg uit’-lijst beperkt zich tot de StUF protocolverbindingen, de StUF onderlaag en de StUF horizontale sectormodellen. Bij opname van de StUF standaard op de ‘Pas toe of leg uit’-lijst in 2008 bestond er geen overkoepelend versienummer. Hierdoor is op de ‘Pas toe of leg uit’-lijst geen versienummer vermeld voor StUF. De actuele versie 3.01 van StUF is nooit getoetst op de criteria voor de ‘Pas toe of leg uit’-lijst. Bovendien is het versienummer niet zichtbaar op de ‘Pas toe of leg uit’-lijst. Het versiebeheer van StUF is daarom een aandachtspunt voor VNG Realisatie en het Forum Standaardisatie.

VNG Realisatie geeft aan alle StUF standaarden in eigen beheer te ondersteunen en onderhouden. De ontwikkeling van een nieuwe major versie van StUF (ook wel StUF 4.0) is stopgezet. Op de website van de VNG Realisatie en op Gemma Online wordt benoemd dat verschillende ontwikkelingen maken het vernieuwen van standaarden noodzakelijk om invulling te (blijven) geven aan de behoefte en wensen van gemeenten. De doorontwikkeling van de StUF standaard, de StUF sectormodellen en de StUF koppelvlakken is daarom stopgezet. 

Het feit dat er niet geïnvesteerd wordt in de doorontwikkeling kan doen voorkomen dat de standaard niet in actief beheer is. VNG Realisatie pakt echter wel bugs en benodigde aanpassingen op, en voert verbeteringen door waar nodig. De laatste versies van de StUF specificaties zijn op Gemma Online te vinden. 

Experts benoemen een aantal aandachtspunten ten aanzien van het beheer. De StUF regiegroep komt niet meer bij elkaar, afspraken en beslissingen worden nu via Github online gedeeld. Er zijn zeer weinig mensen bij VNG Realisatie nog betrokken bij StUF. Dit wordt door experts als een risico benoemd voor de continuïteit.

Doorontwikkeling blijft achter

Door een groot aantal experts wordt benoemd dat VNG Realisatie niet actief stuurt op de transitie van StUF naar alternatieven waaronder de API’s. De doorontwikkeling is weliswaar formeel gestopt, er is echter geen roadmap door VNG Realisatie bekend gemaakt over wat de stappen zijn rondom het ontwikkelen van andere standaarden of het overgaan op andere standaarden. Experts geven aan dat VNG Realisatie gemeenten niet of nauwelijks begeleidt in de transitie. Met de volgende zaken zou VNG Realisatie de transitie beter kunnen begeleiden:

een overzicht van alternatieven voor de verschillende StUF onderdelen;

een overzicht met API’s of oplossingen waaraan gewerkt wordt ter vervanging van StUF onderdelen;

een strategie voor de transitie bij gemeenten;

een roadmap of plan voor de aankomende jaren.

VNG Realisatie geeft aan dat de transitie van StUF naar API’s op de kaart is gezet. In oktober 2024 is er een mail gestuurd naar de bij VNG Realisatie bekende gebruikers en leveranciers van StUF-koppelvlakken, om inzicht op te halen over de implementatie van de StUF-koppelvlakken binnen bestaande oplossingen. Op basis van de ontvangen gegevens, wordt samen met gemeenten en marktpartijen een vervangingsstrategie opgesteld rondom de StUF-standaarden.

Opname op de lijst

Opname op de lijst van StUF staat ter discussie.

Op de vraag of er meerwaarde zit aan een ‘Pas toe of leg uit’-status voor StUF wordt wisselend door de experts gereageerd. De meeste experts twijfelen eraan of StUF aan de criteria voor de ‘Pas toe of leg uit’-lijst voldoet. Een diversiteit aan suggesties is gemaakt door experts:

Het overgaan op de API’s behelst een transitie naar een andere manier van informatiehuishouding en -architectuur. Een soortgelijke route als voor de Geostandaarden wordt aanbevolen voor de transitie van StUF naar alternatieven (waaronder API’s). Dit betekent dat StUF wordt verplaatst naar de lijst aanbevolen standaarden om het belang van de standaard te erkennen en om tegelijk ruimte te bieden voor nieuwe standaarden en oplossingen.

StUF kan op de ‘Pas toe of leg uit’-lijst blijven staan mits het functioneel toepassingsgebied verandert zodoende dat het de toepassing van gestandaardiseerde alternatieven (waaronder API’s), daar waar ze beschikbaar zijn, niet in de weg staat.

Onderdelen van de StUF standaard zouden verplaats kunnen worden naar de lijst aanbevolen standaarden. Enkele experts benoemen dat (onderdelen van) de StUF standaard ook geen plek heeft op de lijst aanbevolen standaarden doordat er geen sprake is van actief beheer op de standaard en het daardoor niet voldoet aan het criteria van ‘Open standaardisatieproces’.

De StUF standaard nog langer op de ‘Pas toe of leg uit’-lijst houden wordt als schadelijk gezien. Het advies is met nadruk om de standaard van de lijst af te halen. Als gemeenten een nieuw voorziening willen inkopen waarbij er API’s gebruikt zouden kunnen worden en StUF niet noodzakelijk is dan worden die gemeenten met de huidige ‘Pas toe of leg uit’-verplichting voor StUF geforceerd om hoge kosten te maken. 

Het belang en de noodzaak van een gemeentebrede standaard mag niet onderschat worden. Het advies is om eerst de transitie van StUF naar alternatieven (waaronder API’s) vast te stellen zodat er bij het al dan niet wijzigen van de ‘Pas toe of leg uit’-status van StUF het duidelijk is voor gemeenten welke standaard ze moeten uitvragen. 

Status adoptie adviezen

Er waren geen openstaande adoptiepunten voor de StUF standaard.

Lopende ontwikkelingen

Er is een beweging gaande naar een nieuwe informatiearchitectuur. Programma’s zoals het Federatief Datastelsel, Common Ground en Haal Centraal dragen hieraan bij. Deze nieuwe beweging streeft ernaar om aan te sluiten op een landelijk gegevenslandschap. ‘Houd data bij de bron’ is hierbij de leidraad. Via een API (Application Programming Interface) wordt informatie makkelijker herbruikbaar gemaakt. Via een API kan een applicatie automatisch toegang krijgen tot bepaalde informatie en/of functionaliteiten. Het is dan niet meer nodig om databases met elkaar te synchroniseren zoals nu vaak nog gebeurt. Gemeentelijke deelkopieën van gegevensmagazijnen zijn veelal niet meer nodig. Bovendien hoeven er geen leveranciersafhankelijke gegevens meer worden bijgehouden. Deze beweging ontstijgt de keuze van individuele technologieën boven andere (bijvoorbeeld REST/JSON vs. SOAP/XML). Het gaat over een compleet nieuwe informatiearchitectuur die de kosten significant moet reduceren.

De volgende ontwikkelingen zijn besproken met de experts in het kader van mogelijke alternatieven voor StUF.

Haal Centraal API’s

Haal Centraal richt zich op het centraal stellen van landelijke voorzieningen doormiddel van API’s.

Het programma Haal Centraal begon als een pilot in 2018, in samenwerking met het Kadaster, VNG Realisatie, en de G4-gemeenten. Er werd na een succesvolle pilot een investeringsvoorstel ingediend bij BZK voor de ontwikkeling van Haal Centraal API’s. Dit voorstel werd gehonoreerd in 2019. De eerste stuurgroep vond plaats in de zomer van 2019, met VNG Realisatie, BZK, Kadaster, RvIG, de gemeente Den Haag en de KVK ten behoeve van de realisatie van de Haal Centraal API’s. In 2022 is een pilot gestart waarbij de RvIG via de BRP API gegevens verstrekt aan afnemers. De API-specificaties zijn gespecificeerd in het programma Haal Centraal en door VNG Realisatie gestandaardiseerd in 2022. Dat betekent concreet dat gemeenten bij het toepassen van API's om gegevens op te halen (waar mogelijk) de gestandaardiseerde Haal Centraal API-specificaties moeten gebruiken.

Inmiddels worden de volgende basisregistraties ontsloten middels API’s:

Basisregistratie Personen (BRP). Voor de BRP API is een experimentbesluit aangenomen. De BRP API is daarmee in gebruik genomen en maakt geen gebruik van StUF. Middels de BRP API wordt basisinformatie uitgewisseld zoals een aanhef voor correspondentie, maar wordt niet een volledige set met persoonlijke data wat vaak wel het geval is met StUF. De BRP API draagt bij aan data minimalisatie. De BRP API heeft een gouden API ontvangen van het kennisplatform API’s. Een kanttekening bij het experitmentbesluit is dat het besluit een einddatum heeft. Dit betekent echter niet dat de BRP API daarna niet meer beschikbaar zal zijn. 

Basisregistratie Adressen en Gebouwen (BAG). De BAG API is in 2019 geïntroduceerd en is niet gebaseerd op StUF. Deze API neemt toe in populariteit en wordt volgens het Kadaster steeds vaker toegepast. De BAG gegevens zijn openbaar en minder privacygevoelig waardoor een experimentbesluit niet nodig was en deze API gemakkelijker te realiseren was. 

Basisregistratie Kadaster (BRK).

Landelijke voorziening Waardering Onroerende Zaken (LV WOZ). 

De API's vervangen delen van de StUF-standaard. Haal Centraal API's worden al steeds meer gebruikt door gemeenten, met als doel om gegevens rechtstreeks uit bronsystemen te halen en daarmee de kwaliteit en snelheid van de gegevensuitwisseling te verhogen. Desondanks dat het programma Haal Centraal is beëindigd wordt het gedachte goed voorgezet. Een voorbeeld van een ambassadeur is gemeente Den Haag.

Common Ground API’s

Common Ground richt zich op de uitwisseling tussen en binnen gemeenten. Common Ground is een ontwikkeling waarbij gemeenten de informatievoorziening eenvoudiger, flexibeler en slimmer willen inrichten door gebruik te maken van technologieën en data-uitwisseling direct vanuit bronsystemen. Dit stelt gemeenten in staat om hun dienstverlening en bedrijfsvoering te verbeteren en sneller in te spelen op maatschappelijke uitdagingen. De nieuwe aanpak moet de huidige, vaak trage en kostbare manier van gegevensuitwisseling gebaseerd op StUF vervangen, zodat gemeenten efficiënter kunnen omgaan met thema's zoals duurzaamheid, zorguitgaven, participatie en openbare orde.

Een van de producten is de API’s voor Zaakgericht Werken. Dit is een serie gestandaardiseerde koppelingen waarmee applicaties (zaak)gegevens in gestandaardiseerde bronnen kunnen ophalen en vastleggen. Door te werken met de API-ZGW zijn gemeenten in staat om regie te houden op hun gegevens, eenvoudiger verschillende applicaties rond zaakgericht werken te koppelen en te voldoen aan privacywetgeving. Data worden niet langer gekopieerd en op meerdere plekken en in verschillende vormen opgeslagen, waardoor gemeenten altijd met de juiste en actuele gegevens werken. VNG Realisatie heeft deze API’s voor Zaakgericht Werken als standaard verklaart middels ‘Pas toe of leg uit’. Dit betekent dat gemeenten bij het aanschaffen van een nieuwe voorziening deze API’s zullen implementeren. Deze API’s voor Zaakgericht Werken worden steeds vaker ingezet beamen experts.

Overige alternatieven

NL Gov for CloudEvents is een Nederlandse specificatie van de internationale CloudEvents-standaard, bedoeld voor het maken van afspraken over event-gebaseerde communicatie tussen verschillende diensten. Het doel is om de interoperabiliteit tussen systemen te verbeteren en losse koppelingen mogelijk te maken, zodat overheidsdiensten efficiënter en flexibeler kunnen samenwerken. Deze Nederlandse variant voegt specifieke eisen toe die relevant zijn voor de Nederlandse situatie, terwijl het blijft aansluiten op de internationale context.

De basisregistratie WOZ werkt met “gebeurtenissen” binnen StUF. Dit komt overeen met een systeem van “informatierijk notificeren over CloudEvents”. Zo krijg je een signaal als er iets wijzigt en dan kunnen de gegevens worden opgehaald. NL GOV profile for CloudEvents draagt ook bij aan dataminimalisatie. 

Conclusies en aanbevelingen evaluatie StUF op de ‘Ptolu’-lijst

Conclusies StUF

Experts zijn het erover eens dat StUF complexe standaard is. Tegelijkertijd wordt dit door een aantal experts gezien als meerwaarde aangezien StUF in complexe situaties een oplossing biedt voor het bevragen en uitwisselen van gegevens. De experts zijn er tevens over eens dat het toepassingsgebied van de standaard niet meer passend is voor StUF. Het aanpassen van het toepassingsgebied biedt ruimte voor het gebruik van alternatieven, waaronder API’s, en het bekrachtigen van de relevantie van StUF in die situaties waar er geen alternatief is. 

Toepassingsgebied

Het functioneel toepassingsgebied van StUF is achterhaald met de huidige kennis en ontwikkelingen. Er zijn situaties waarin alternatieven toegepast kunnen worden die eenvoudiger zijn dan StUF en waarbij het verplicht stellen van StUF als niet passend wordt gezien.

Alternatieven

De toegevoegde waarde van StUF staat ter discussie. StUF kent functionaliteiten waar er nog geen alternatieven voor zijn. In die situaties, die vaak complexer van aard zijn, heeft StUF meerwaarde. In de andere situaties geven de experts de voorkeur aan het gebruik van alternatieven, waaronder API’s, bij het vernieuwen of aanschaffen van voorzieningen. 

Draagvlak

Het gebruik van StUF is groot. Dit staat echter niet gelijk aan draagvlak. Voor een aantal functionaliteiten zijn er nog geen goed alternatieven beschikbaar. Daar waar wel alternatieven zijn, bijvoorbeeld in de vorm van API’s, geeft het merendeel van de experts de voorkeur aan het inzetten van dat alternatief boven het gebruik van StUF bij een nieuwe of te ontwikkelen voorziening (denk aan applicaties of systemen). Signalen dat het gebruik zal gaan afnemen bij het omarmen van onder andere de Haal Centraal API’s worden wel gegeven door de experts. Dit is een kwestie van een lange adem. 

Beheer

De doorontwikkeling van de StUF standaard, de StUF sectormodellen en de StUF koppelvlakken is stopgezet door het VNG Realisatie. Dit in het kader van andere ontwikkelingen, waaronder het inzetten op API’s. VNG Realisatie pakt wel bugs en benodigde aanpassingen op, en voert verbeteringen door waar nodig. Er zijn zorgen van experts over het beheer van de StUF standaard. Er is ook kritiek op hoe VNG Realisatie de transitie van StUF naar alternatieven (API’s) begeleidt.

Opname op de ‘Pas toe of leg uit’-lijst

Bevraagde experts zijn het er niet over eens of StUF (deels) verplicht moet blijven middels opname op de ‘Pas toe of leg uit’-lijst. Er zijn suggesties voor het (deels) verplaatsen naar de lijst aanbevolen standaarden, voor het verwijderen in zijn geheel en voor het laten staan op de ‘Pas toe of leg uit’-lijst. 

Lopende ontwikkelingen

Er is een beweging gaande naar een nieuwe informatiearchitectuur. Programma’s zoals het Federatief Datastelsel, Common Ground en Haal Centraal dragen hieraan bij. Deze nieuwe beweging streeft ernaar om aan te sluiten op een landelijk gegevenslandschap. ‘Houd data bij de bron’ is hierbij de leidraad. De API’s en standaarden die ontwikkeld worden sluiten aan bij dit nieuwe gedachtegoed. Al deze ontwikkelingen hebben impact op de meerwaarde van StUF.

Aanbevelingen StUF

Vanuit de analyse van de interviews en de bovenstaande conclusies zijn de volgende aanbevelingen opgesteld:

Aan VNG Realisatie om een strategie en roadmap op te stellen voor de transitie van StUF naar alternatieven, waaronder API’s. Onderdeel hiervan in het creëren van een overzicht van alternatieven en nog te ontwikkelen alternatieven voor de verschillende onderdelen in de StUF familie. 

Aan VNG Realisatie om samen met gemeenten en leveranciers te onderzoeken hoe het functioneel toepassingsgebied het beste herzien kan worden aan de hand van domeinspecifieke gesprekken. Dit kan onderdeel zijn voor de strategie en roadmap voor de transitie van StUF naar alternatieven, waaronder API’s. 

Aan VNG Realisatie om een toetsingsprocedure aan te vragen bij het Forum Standaardisatie, om:

Het toepassingsgebied te herformuleren zodat dit reflecteert waar StUF meerwaarde heeft en verplicht toegepast moet worden.

Aan de hand van het nieuw geformuleerde toepassingsgebied te bepalen of (delen van) StUF in zijn geheel verplicht moet worden gesteld middels opname op de ‘Pas toe of leg uit’-lijst. 

Aan de hand van het nieuw geformuleerde toepassingsgebied te bepalen of (delen van) StUF moet worden aanbevolen middels opname op de lijst aanbevolen standaarden. 

Aan VNG Realisatie en het Forum Standaardisatie om te achterhalen hoe de transitie en het al dan niet gebruik van de bijbehorende standaarden duidelijk gecommuniceerd kan worden aan gebruikers.