SGO-3 onderzoek - Slim Bevragen & GBSO

SGO-3 onderzoek - Slim Bevragen & GBSO

SGO-3 onderzoek - Slim Bevragen & GBSO Eindrapport

project 3982 versie

1.2

datum

13 maart 2014

Inhoudsopgave 1.

Inleiding

4

1.1 1.2 1.3 1.4 1.5

Aanleiding Opdrachtformulering Referentiekader Werkwijze Indeling rapport

4 4 5 5 5

2.

Terugblik

6

3.

Schuivende panelen

8

3.1 3.2 3.3 3.4

Discussie over sectorknooppunten Onderzoek Domeinmakelaar SZW Task Force SGO3 – Versnelde invoering basisregistraties Digitaal 2017

8 9 10 12

4.

Wat is Slim Bevragen?

4.1 4.2 4.3 4.3.1 4.3.2 4.3.3 4.3.4

Een korte beschouwing over informatie-uitwisseling Aspecten rondom Slim Bevragen Definitie en modelvorming Slim Bevragen als leidend principe Alles draait om de eenvoud: services De stelselknooppunten en Slim Bevragen Slim Bevragen

5.

Conclusies

5.1 5.2 5.3

Beantwoording vraagstelling Conclusies en aanbevelingen Hoe nu verder?

14 14 14 16 16 17 17 19

20 20 21 22

Bijlage A

Geïnterviewde personen

23

Bijlage B

Bestudeerde documentatie

24

Bijlage C

Afwegingskader

25

1.

Inleiding

1.1

Aanleiding

SGO3, het overleg van secretarissen generaal dat verantwoordelijk is voor de versnelde effectieve inzet van basisregistraties laat enkele onderzoeken uitvoeren naar maatregelen die mogelijk het gebruik van de basisregistraties kunnen stimuleren en uiteindelijk tot een besparing van kosten kunnen leiden. Een van die onderzoeken betreft de onderwerpen Slim Bevragen en gemeenschappelijke bevragings- of serviceorganisatie (GBSO). Omdat in het verleden voor dit laatste de term GOB (Gemeenschappelijke Ontsluiting Basisregistraties) is gehanteerd zal die term in het vervolg van dit rapport gehanteerd worden. De gemeenschappelijke ontsluiting van basisregistraties, in de zin van het gecombineerd en “slim” bevragen is enige jaren geleden niet van de grond gekomen. Het nut bleef steken in abstracties, de vraag was niet in alle opzichten duidelijk genoeg en partijen waren niet bereid middelen beschikbaar te stellen om de kosten te dekken. Daarnaast bleken sommige geïntegreerde vragen te stokken op juridische belemmeringen rond het gebruik van met name de GBA. In algemene zin waren in de werkgroep SGO3 ook signalen dat de informatieproducten vanuit het stelsel niet altijd aansluiten bij de specifieke behoeften van verschillende uitvoeringsorganisaties. De behoefte was er dus al langer maar het realiseren van iets als een gemeenschappelijke bevragings- of serviceorganisatie kwam niet van de grond. Door tal van lopende ontwikkelingen en initiatieven is de vraag opnieuw binnen SGO3 aan de orde gekomen. Hier is een tweetal onderzoeksvoorstellen uit voortgekomen inzake Slim Bevragen enerzijds en GOB anderzijds welke in onderhavig onderzoek gezamenlijk zijn opgepakt.

1.2

Opdrachtformulering

PBLQ heeft de opdracht gekregen om het onderzoek uit te voeren. Daarbij is de volgende opdrachtformulering gebruikt: Welke informatieproducten of dienstverlening van het stelsel van basisregistraties, uitgaande van nu aanwezige gegevens in die registraties, ontbreken in de ogen van uitvoeringsorganisaties in het licht van versnelde en effectievere inzet van het stelsel van basisregistraties in hun werkprocessen? Onderzoek hoe de beantwoording van vraag 1 kan worden meegenomen in de overheidsbrede businesscase die eind 2013 wordt opgesteld voor een stelsel van domein makelaars1. Als ook hoe aangesloten kan worden bij het onderzoek gegevensmakelaar SuwiNet 2.0

1

pagina 4 / 25

Dit onderzoek is eind 2013 opgestart doch heeft nog niet tot de genoemde overheidsbrede businesscase geleid

13 maart 2014

PBLQ - SGO-3 onderzoek - Slim Bevragen & GBSO

Namens de opdrachtgever SGO-3 heeft dhr. N. Hooyman, ministerie I&M, opgetreden als opdrachtgever.

1.3

Referentiekader

Ons referentiekader wordt met name gevormd door de NORA en het iNUP. Daarnaast is gebruik gemaakt van het afwegingskader “Uitbreiding van gegevens in het stelsel van basisregistraties, Den Haag, PBLQ 2013” vanwege het daarin beschreven uitgangspunt om te starten bij de processen waarin geregistreerde gegevens worden gebruikt en vervolgens uit die processen de informatiebehoeften en kwaliteitseisen te leiden. Uiteraard hebben we daarnaast de eerder verschenen GOB-documentatie tot ons genomen en ons verdiept in relevante aanpalende ontwikkelingen, zoals de “domeinmakelaar” en het zogenaamde “rotondemodel”.

1.4

Werkwijze

In de voorbereidingsfase hebben we de documenten bestudeerd zoals opgenomen in bijlage B. Tevens hebben we deelgenomen aan de startbijeenkomst domeinmakelaar, georganiseerd door SZW. In de onderzoeksfase is gesproken met diverse bij het onderwerp betrokken beleidsmakers en uitvoerders, zie bijlage A. Vragen die aan de orde kwamen waren (onder andere): de aanleiding voor het onderzoek en de historische achtergrond het belang van (de organisatie van) de geïnterviewde bij het onderwerp en diens behoeften hieraan hoe die behoefte gerealiseerd kan worden en welke belemmeringen een rol spelen, de relatie met andere projecten, de rol van sectorale knooppunten en de aansluiting op het rotondemodel. De geïnterviewden zijn daarnaast uitgenodigd voor een werkconferentie. In deze werkconferentie zijn we eerst ingegaan op de verschillende beelden die bij de deelnemers leven over het thema Slim Bevragen. Dit omdat uit de interviewronde bleek dat deze beelden zeer divers zijn. Door de thema’s in deelgroepjes uit te werken voor verschillende invalshoeken (juridisch, financieel, bestuurlijk, informatiekundig, etc.), hebben we een belangrijke stap gezet richting een definitie van het begrip Slim Bevragen. De resultaten van de desk research, interviews en werkconferentie hebben we in een interne werksessie geanalyseerd waarna we de hoofdlijnen van het rapport hebben samengesteld. Het concept rapport is besproken in een tweede werkconferentie en met de opdrachtgever, waarna het definitieve rapport is opgesteld.

1.5

Indeling rapport

We beginnen deze rapportage met een terugblik op de historie in hoofdstuk 2 om te constateren dat de behoefte aan bepaalde voorzieningen steeds terugkeert en nog steeds actueel is. In hoofdstuk 3 beschrijven we enkele aanpalende ontwikkelingen die van belang zijn voor het thema Slim Bevragen. Wat Slim Bevragen eigenlijk inhoudt, beschrijven we in hoofdstuk 4. Om in hoofdstuk 5 de onderzoeksvragen te beantwoorden en onze suggesties te doen voor het vervolg.

pagina 5 / 25

13 maart 2014


2.

Terugblik

In oktober 2008 is de Startarchitectuur GOB opgesteld. Onder de Gemeenschappelijke Ontsluiting Basisregistraties (GOB) werd verstaan: een verzameling standaarden en voorwaarden die gaan over het leveren van gegevens uit basisregistraties. Daarbij maakt de GOB gebruik van de Overheid Service Bus (tegenwoordig Digikoppeling) geheten en de daarin voorziene Overheid Service Register (welke webservices zijn er beschikbaar om gegevens uit een basisregistratie te halen). De OSR biedt in feite een overzicht van de door afnemers aan het stelsel te stellen vragen.

Hoe werken GOB services Webservice A1

Webservice A1

Webservice A2

Webservice A2

Afnemer X

Verstrekken informatie A1 (BSN 567) Basis registratie Stelsel Catalogus

Afnemer Y

A

Basis

Service Registry

registratie B Verstrekken informatie B2 (BSN 345)

Webservice A1

Webservice B1

Webservice B2

Webservice B2 11

Het GOB regelt het maken van afspraken en het realiseren van voorzieningen, waarmee het eenvoudig wordt gegevens uit basisregistraties te gebruiken door bijvoorbeeld standaarden te definiëren en leveringsvoorwaarden vast te stellen voor de verstrekking van gegevens uit basisregistraties. Hiertoe zou GOB een drietal voorzieningen realiseren: een voorziening die antwoorden op veelgestelde vragen waarbij meerdere basisregistraties betrokken zijn kan ontsluiten; een stelselcatalogus waarin de structuur van het stelsel van basisregistraties is beschreven en definities van soorten objecten, gegevens en berichten staan; een abonnementensysteem voor gebeurtenissen, bijvoorbeeld een verhuizing. De laatste twee voorzieningen, Stelselcatalogus en het abonnementensysteem (via het huidige Digilevering) zijn inmiddels gerealiseerd. Dat geldt echter niet voor de eerste voorziening.

pagina 6 / 25

13 maart 2014


Hierbij werd gedacht aan een loket, die een samengestelde vraag uitsplitst in enkelvoudige vragen en deze achtereenvolgens zou stellen aan de betreffende basisregistraties waarna de enkelvoudige gegevens weer werden gecombineerd tot 1 antwoord op de vraag. Bijvoorbeeld bij de uitvraag van een gehandicaptenparkeerplaats voor BSN-X met gehandicaptenindicatie: beschikt BSN-X of diens partner over een auto. De GOB vraagt dan eerst de partnergegevens op en vervolgens voor beide BSN’s de eventuele voertuiggegevens.

Hoe werken samengestelde GOB services Webservice P

Uitvoeren A1 (BSN 345) Antwoord A1 (BSN 345) Uitvoeren A2 (BSN 567)

Webservice Q

Web Service A1 Web Service A2

Antwoord A2 (BSN 567) STAP 1

Afnemer X

BSN partner = 345 STAP2

Gebruik BSN (345)

Afnemer Y

Persoonsgegevens = abc

Basis Complexe Service Q

Opzoeken persoons gegevens en rijbewijs gegevens partner van BSN(567)

registratie A

Basis registratie

Rijbewijsgegevens = def

Webservice A1 Webservice P

B

Uitvoeren B1 (BSN 345) Antwoord B1 (BSN 345) Uitvoeren B2 (BSN 345) Antwoord B2 (BSN 345)

Web Service B1 Web Service B2 14

Een ander veel gebruikt voorbeeld is bij crisisbestrijding: geef alle bedrijven met hun bestemmingen in een straal van 1 km van de ramplocatie. Hoewel de GOB nog genoemd werd in de Visie op het Stelsel van Basisregistraties uit 2010, is deze gemeenschappelijke voorziening voor samengestelde vragen nooit gerealiseerd. Gezamenlijk moesten de drie voorzieningen de GOB invullen als een marktplaats tussen vragen van afnemers en antwoorden (web services) van registraties. Deze marktplaats is er dus niet gekomen. De redenen waarom dit deel van de GOB niet gerealiseerd is, hebben we slechts oppervlakkig onderzocht resulterend in de volgende indrukken: Het ontwerp van de GOB is technisch en informatiekundig gezien nog altijd toepasbaar. De GOB is echter aanbodgericht ontworpen en als een “one size fits all” voorziening waar alle afnemers met allerlei soorten samengestelde vragen terecht zouden kunnen. Daarmee kwam centraal te staan hoe dit te organiseren in plaats van de informatiebehoefte. Hoewel er destijds enkele voorbeelden van dit type vragen zijn bedacht, was de vraagkant en daarmee de businesscase onvoldoende duidelijk. Het slecht gevuld zijn van het OSR met web services zal ook niet bijgedragen hebben. Meervoudige vragen zijn echter te zien als een manier van slim verstrekken en daarmee de ontzorgende tegenhanger van Slim Bevragen. En dat maakt de GOB voor dit onderzoek nog steeds relevant.

pagina 7 / 25

13 maart 2014


3.

Schuivende panelen

3.1

Discussie over sectorknooppunten

Reeds jaren loopt er een discussie over de mogelijke rol van zogenaamde sectorknooppunten2 als middel voor het ontsluiten (lees: slim bevragen) van gegevens in sectoren. Ook zie je in de praktijk steeds meer organisaties opstaan die zich opwerpen als sectorknooppunt. Ten tijde van RENOIR (2009-2010) hebben twee zogenaamde sectorcoördinatoren (Heemskerk en Aalbers) voor de sectoren onderwijs, welzijn en zorg resp. justitie en veiligheid in kaart gebracht hoe sectorale knooppunten de gegevensuitwisseling kunnen faciliteren tussen en met sectorale organisaties gebruikmakend van generieke e-overheid voorzieningen. Uit een inventarisatie van de op dat moment bestaande en in ontwikkeling zijnde sectorknooppunten bleken er ook al verschillende (vormen van) sectorknooppunten te bestaan. Zo kan een sectorknooppunt dienen als (afhankelijk van het perspectief): koppelpunt voor organisaties binnen een sector, en/of ontkoppelpunt tussen organisaties uit verschillende sectoren en /of als ontkoppelpunt tussen publieke en private ketenpartijen (zoals in de zorg of het onderwijs). Ook in de jaren daarna en in de huidige discussies worden aan een sectorknooppunt verschillende functionaliteiten toegekend. De implementatievisie stelsel (Ducastel, Hoff, Opdam, van Splunter, Zuurmond) beschrijft de beoogde werking van het stelsel vanuit het perspectief van de professional als gebruiker. Dit vereist een paradigma shift voor het stelsel van aanbod van voorzieningen naar het beantwoorden van vragen. Hierbij werden sectorale knooppunten geschetst als middel om gegevens “met 1 druk op de knop” uit sectoren te halen, waarbij de privacy beschermd wordt door deze vragen op een slimme wijze te stellen. Waarbij sectorknooppunten niet alleen een rol spelen in het ontsluiten van sectoren en vice versa het stelsel, maar informatie ook kunnen verrijken met specifieke informatie aansluitend op de vraag, zoals het leveren van jeugdzorg, fraudebestrijding, het innen van vorderingen en andere ketenvraagstukken. Ook het Vergezicht 2020 (2012, Willems, Zuurmond, Ducastel, Crasborn) beschrijft een toekomst van een werkend stelsel met sectorale knooppunten. De hierna beschreven domeinmakelaar (par. 3.2) is in feite een sectorknooppunt. Dit geldt ook voor de zogenaamde minirotondes zoals voorgesteld door de Taskforce SGO-3 (zie par. 3.3). In de smalle definitie is een sectorknooppunt vooral het ontkoppelpunt tussen organisaties binnen de sector en organisaties binnen de rest van de overheid. Breder, in een meer federatief model heeft een sectorknooppunt ook een coördinerende en standaardiserende rol binnen de sector. Het knooppunt kan bijv. de vertaling doen van sectorale begrippen

2

In deze rapportage wordt consequent het woord sectorknooppunt gebruikt. Hiervoor kan ook sectoraal aanspreekpunt of ontkoppelpunt gelezen mogen worden. Verder is het niet de intentie van de auteurs om hiermee te suggereren dat er binnen de Nederlandse overheid een eenduidige en scherpe afbakening in sectoren te maken is. Dat is niet zo. Het woord knooppunt (dus zonder het voorvoegsel sector) is echter een dusdanig algemeen begrip dat hier het begrip sectorknooppunt is gehandhaafd omdat dat begrip volgens de auteurs het dichtst bij de bedoelde koppel- en ontkoppelfunctie komt.

pagina 8 / 25

13 maart 2014


naar sectoroverstijgende begrippen. Maar ook optreden als sectorale vraag- of juist aanbodorganisatie. Of eisen stellen aan de onderliggende sectorale registraties, bijv. op het terrein van informatieveiligheid, standaardisatie, beschikbaarheid, actualiteit etc. Daarnaast is nog niet zo eenvoudig wat dan eigenlijk een sector is. Vaak wordt hierbij gebruik gemaakt van de indeling in departementen, maar bijv. de zorg is dermate complex dat er meerdere knooppunten te vinden zijn (het landelijke schakelpunt LSP voor de uitwisseling van huisarts- en medicatiegegevens, de CVZ berichtenpostbus BRP voor Wmo berichten tussen overheden en het Vecozo schakelpunt VSP voor de uitwisseling van Awbz berichten tussen overheden en zorgleveranciers). Daarnaast hebben uitvoerders die te maken hebben met meerdere sectoren zoals gemeenten, behoefte aan een eigen sectorknooppunt. Conclusie: de historie leert dat er door de jaren heen een constante roep is om een voorziening voor de uitwisseling van gegevens binnen, met en tussen sectoren, dat hiervoor wisselende benamingen worden gebruikt en dat de betreffende voorzieningen nog slechts ten dele zijn gerealiseerd.

3.2

Onderzoek Domeinmakelaar SZW

Het concept van de domeinmakelaar komt mede voort uit de drie decentralisaties in het sociale domein (zie kader) en de hieruit voortvloeiende noodzaak om gegevens in te kunnen zien die oorspronkelijk afkomstig zijn uit andere (deel)sectoren. Het onderzoek naar de Domeinmakelaar moet antwoord geven op de vragen: hoe ziet de domeinmakelaar er uit en wat levert deze op (businesscase)? Dit onderzoek is ten tijde van schrijven van dit rapport nog aan de gang zodat het begrip Domeinmakelaar nog wel nadere scherpte en duiding vereist. Onderstaande beschrijving is dan ook gebaseerd op een ontwikkeling die nog sterk in beweging is. Het idee achter de Domeinmakelaar en het stelsel van domeinmakelaars is dat ieder (ministerie gerelateerd) domein dat op substantiële schaal gegevens uitwisselt in ketens, een (evt. meerdere) domeinmakelaar(s) ontwikkelt. Zo’n domeinmakelaar distribueert in opdracht van een bronhouder gegevens naar een andere organisatie binnen hetzelfde domein, of van een bronhouder naar een domeinmakelaar van een ander domein, die vervolgens distribueert naar afnemers in dat domein. Drie decentralisaties in het sociale domein Gemeenten krijgen de komende jaren nieuwe taken op het terrein van de Jeugdzorg, Wmo/AWBZ en Werk (Participatiewet). Deze drie decentralisaties in het sociale domein (ook wel 3D genoemd) hebben grote gevolgen voor de informatievoorziening. Voor de zogenaamde Multi-probleem gezinnen wordt een werkwijze voorzien volgens het principe “1 gezin – 1 plan – 1 dossier”. Dit betekent dat de gemeentelijke regisseur informatie heeft over welke professionals bij welke klanten/gezinnen betrokken zijn en dat essentiële gegevens tussen de professionals uit de verschillende domeinen met elkaar gedeeld moeten kunnen worden. Denk hierbij aan gegevens als: indicatiestelling, gezinssituatie en adres. Als mogelijke bronnen hiervoor valt te denken aan de basisregistraties, de verwijsindex risicojongeren en het DKD (digitaal klant dossier). De huidige informatiesystemen van gemeenten en uitvoerende professionals zijn hier echter nog niet op ingericht. Daarnaast voorziet de huidige wetgeving onvoldoende in het faciliteren van deze gegevensuitwisseling, met name in relatie tot de bescherming van persoonsgegevens. In een door VNG geïnitieerd onderzoek Verkenning Informatievoorziening Sociaal Domein (VISD) is zomer 2013

pagina 9 / 25

13 maart 2014


een visie beschreven op de aanpak van de informatiseringondersteuning van de 3D waarbij uitgegaan wordt van een integrale benadering over de inhoudelijke domeinen heen. Daarbij is een aantal generieke informatiefuncties onderkend zoals 1) het kunnen zien van gegeven, 2) het kunnen ontvangen, beoordelen en routeren van signalen en meldingen, 3) het kunnen registreren van 1 plan en 4) het kunnen communiceren met betrokken professionals. Deze functies zijn in de verkenning uitgewerkt incl. de daarvoor benodigde minimale gegevensset. Gemeenten maken deel uit van de Suwi-keten en maken gebruik van Suwinet voor de gegevensuitwisseling in de keten van werk en inkomen. Vandaar dat voor de 3D keteninformatisering o.a. gekeken is naar het gebruik van Suwinet. Deze kent een webapplicatie waarmee geautoriseerde medewerkers inzage krijgen in de Suwi gegevens. Uit het onderzoek Kopie Suwinet blijkt echter dat Suwinet hier niet bestemd en geschikt voor is maar componenten ervan mogelijk wel.

In de discussie over de Domeinmakelaar kan het Inlichtingenbureau gezien worden als de domeinmakelaar die in het sociale domein producten kan uitwisselen (Het Inlichtingenbureau heeft alle gemeenten aangesloten en fungeert de facto als sectorloket voor gemeenten). In het onderzoek Kopie Suwinet is geconstateerd door SZW dat Suwinet hiervoor niet geschikt is. Suwinet 1.0 is immers gebaseerd op inkijk waarbij er voor afnemers acht verschillende rollen zijn gedefinieerd om gegevens in te kunnen kijken. Het blijkt dat veel gemeenten elke gebruiker alle rollen toekennen. Hiermee kunnen onnodig veel mensen bij onnodig veel gegevens. Er wordt wel gelogd op het inkijkgedrag, maar vaak is hier te weinig controle op. De recente studie van de Inspectie SZW wijst uit dat slechts 4% van de onderzochte gemeenten goed omgaan met het gebruik van de Suwiproducten. Daarnaast zijn ook de governance (expliciete verantwoordelijkheid ligt bij SZW) en de techniek belangrijke redenen om hier niet voor te kiezen. Naar aanleiding hiervan hebben najaar 2013 de ministeries van SZW, VWS en V&J besloten de verantwoordelijkheid op zich te nemen om voor het sociaal domein gegevensuitwisseling in de ketens technisch mogelijk te maken (Suwinet 2.0). Voor en namens de gemeenten neemt de VNG het initiatief om vorm en inhoud te geven aan een gemeentelijke domeinmakelaar. Tijdens de startbijeenkomst domeinmakelaar in december 2013 is veel aandacht besteed aan het doel (het waarom van een domeinmakelaar), de functies en wat het oplevert. In het verslag is een plaatje opgenomen dat sterk doet denken aan het rotondemodel, waarbij het midden van de rotonde wordt gezien als marktplaats tussen de domeinmakelaars (waarmee deze oude GOB gedachte opnieuw om de hoek komt kijken). Conclusie: De discussie rond het stelsel van domeinmakelaars is een bevestiging van de behoefte aan een mechanisme voor de ontsluiting van sectoren. De Domeinmakelaar is een mogelijke invulling van de eerder genoemde sectorale knooppunten. De decentralisaties in het sociale domein vormen een mooi en actueel voorbeeld van de behoefte aan samengestelde gegevens uit verschillende domeinen.

3.3

Task Force SGO3 – Versnelde invoering basisregistraties

Afgelopen najaar heeft een Task Force van experts in opdracht van SGO3 een advies uitgebracht ( ‘Alles draait om de eenvoud’) waarin een voorstel wordt gedaan voor vereenvoudiging van het stelsel: het zogenoemde rotondemodel. De stuurgroep SGO3 acht dit rotondemodel een goede basis voor de gewenste vereenvoudiging en heeft opdracht gegeven voor de validatie en een impactanalyse van dat model. Die validatie en impactanalyse wordt 22 maart a.s. opgeleverd. Ook deze ontwikkeling is dus nog volop in

pagina 10 / 25

13 maart 2014


beweging. Op basis van de op dit moment bekende informatie, komt het advies van de Task Force op het volgende neer. Ga terug naar het oorspronkelijke doel Het doel van het stelsel – zoals destijds geformuleerd – is tweeledig, namelijk het aanbrengen van samenhang in de informatievoorziening binnen de totale overheid (1) èn eenmalige registratie, meervoudig gebruik (2). Dit alles vanuit een gedachte waarin de burger (mede) centraal staat. Het huidige stelsel ademt echter te veel een sfeer uit van ‘de overheid weet wel wat goed voor u is’. En dat terwijl de huidige maatschappelijke ontwikkelingen – waarin het hoge tempo van digitalisering en de zelfredzaamheid van de burger hand in hand gaan – meer dan eens benadrukken hoe cruciaal het herstellen van koppeling met het oorspronkelijk geformuleerde doel is. Dit vraagt om een gerichte doorontwikkeling van het Stelsel. Om zo de stap te kunnen zetten naar de volgende fase in de levenscyclus.

Denk vanuit gegevens in plaats vanuit registers en instituties De Task Force is van mening dat het huidige concept van het Stelsel moet worden herijkt. De gedachten gaan daarbij uit naar vereenvoudiging van de werking van het Stelsel door het aanbrengen van focus. Het stelsel zou zich moeten concentreren op een beperkt aantal kerngegevens (het Task Force rapport spreekt van contextneutrale gegevens, maar deze term roept teveel vragen op, daarom wordt nu gesproken van kerngegevens). Die kerngegevens zijn (per definitie) identificerende gegevens én specifieke authentieke gegevens. Omdat deze gegevens een zo algemene betekenis hebben, lenen zij zich bij uitstek voor hergebruik: échte basisgegevens dus. Dit vraagt wél om een mentale shift: denken in termen van gegevens in plaats van in termen van registers en bijbehorende instituties. Om zo stappen te zetten in een samenhangende informatie-infrastructuur voor de gehele overheid. Het ‘rotonde’ concept Om de geschetste doorontwikkeling daadwerkelijk te kunnen maken, stelt de Task Force het ‘rotondeconcept’ voor. Een rotonde kenmerkt zich door het feit dat met slechts één regel (‘cédez le passage’) omvangrijke verkeerstromen worden geregeld. De kerngegevens vormen het hart van het concept. Distributie en uitwisseling ervan met de afzonderlijke, specifieke context- en domeingebonden registraties – zoals die zich bijvoorbeeld bevinden aan de Laan van de Leefomgeving – vinden plaats via ‘de digitale rotonde’. Het denken vanuit dit model heeft in de tussentijd niet stilgestaan. De Programmaraad Stelsel van basisregistraties heeft een document vastgesteld (Visie op het stelsel van overheidsgegevens) en door gestuurd naar SGO3. In het kader van de validatie en impactanalyse van het rotondemodel zal dit worden meegenomen. Zie de volgende pagina voor een visualisatie.

pagina 11 / 25

13 maart 2014


Conclusie: het rotondemodel is een model waarin de eerder genoemde begrippen als sectorale knooppunten en domeinmakelaars eenvoudig in passen als zijnde de mini-rotondes die de toegangspoorten vormen tot de sectorale straten en lanen. Op deze manier beantwoordt het rotondemodel aan de bij herhaling geconstateerde behoefte aan sectorale ontsluiting maar vernieuwt tegelijk het denken hierover door niet uit te gaan van registers maar van gegevens.

3.4

Digitaal 2017

Ook het beleidsvoornemen ‘Digitaal 2017’ is een kader waar rekening mee moet worden gehouden. Het ministerie van BZK schrijft daarover: “De digitale dienstverlening door de overheid moet beter. Dit is afgesproken in het regeerakkoord. Burgers en bedrijven moeten uiterlijk in 2017 zaken die ze met de overheid moeten regelen, digitaal kunnen afhandelen. Voorbeelden zijn het aanvragen van een vergunning of het indienen van een bezwaarschrift. Voor wie dat wil, blijven niet-digitale alternatieven bestaan. Onder de overheid valt het geheel aan bestuursorganen van de Rijksoverheid, gemeenten, provincies en waterschappen. Het beoogde doel is dat burgers de overheid sneller en makkelijker kunnen vinden en dat ze zaken kunnen doen op de plek en het tijdstip die hen het beste uitkomen.” In de visiebrief digitale overheid 2017 beschrijft minister Plasterk van Binnenlandse Zaken en Koninkrijksrelaties hoe de overheid deze doelstelling wil bereiken. Zo beschrijft hij hoe de overheidsdiensten de

pagina 12 / 25

13 maart 2014


informatie op de website overheid.nl willen uitbreiden en verbeteren. Om zaken te kunnen doen - met de overheid - is het namelijk allereerst noodzakelijk dat de overheid alle voor burgers relevante informatie digitaal beschikbaar maakt. Daarnaast moeten burgers alle (aan)vragen aan de overheid digitaal kunnen versturen en alle berichten van de overheid digitaal kunnen ontvangen. Het actief openbaar maken van meer informatie via internet vergroot de openbaarheid van bestuur. Dit sluit aan bij de visie en het actieplan Open Overheid. Uiteraard geldt deze dienstverlening niet alleen voor burgers maar zeker ook voor bedrijven. Nederland heeft zich aangesloten bij het Open Government Partnership (OGP). Het OGP is het wereldwijde initiatief om overheden beter te laten functioneren door openheid. Dat betekent meer transparantie over overheidsactiviteiten, open staan voor initiatieven uit de samenleving, verantwoording afleggen en het inzetten van innovatieve technologieën. Alle deelnemers aan het OGP schrijven een visie en een actieplan. De Nederlandse visie en actieplan Open Overheid zijn opgesteld door het ministerie van Binnenlandse Zaken en Koninkrijksrelaties en gaan over de informatierelatie tussen overheid en samenleving. Bij de ontwikkeling naar een volledig transparante samenleving is het niet alleen van belang om na te denken over welke informatie beschikbaar is, maar ook over de manier waarop men de informatie vindbaar, begrijpelijk en volledig aanbiedt aan de burger. Conclusie: Digitaal 2017 bevestigt enerzijds de behoefte aan efficiency in de dienstverlening maar ook aan transparantie over de gegevens die over burgers en bedrijven bij de overheid bekend zijn en op basis waarvan de overheid beslissingen neemt over deze burgers en bedrijven. Dit stelt eisen aan de uitwerking van Slim Bevragen en de hiervoor te realiseren gemeenschappelijke en/of sectorale voorzieningen.

pagina 13 / 25

13 maart 2014


4.

Wat is Slim Bevragen?

4.1

Een korte beschouwing over informatie-uitwisseling

Voor we op het concept Slim Bevragen ingaan is het verstandig om te bezien hoe op dit moment de uitwisseling van informatie binnen de overheid ingericht is. Het is vaak een mengvorm van bilaterale bulkuitwisselingen (middels bestandsuitwisseling of grote berichten) en inkijkfuncties (bijvoorbeeld SUWI Inkijk). Daarnaast valt op dat binnen een sector vaak een sectorknooppunt wordt gebruikt en voor uitwisselingen met partijen buiten de sector de uitwisselingen vaak één-op-één zijn. Bulk-uitwisseling en inkijk hebben hun grond in het verleden waarin gegevens tussen organisaties uitgewisseld moest worden en er weinig mogelijkheden waren om te bepalen wie wat zou mogen zien. Het gevolg is een infrastructuur van uitwisselingen waarin privacy of informatie op maat niet aan de orde waren. Dit is echter in deze tijd niet meer houdbaar. Met aan de ene kant de uitkomsten van een onderzoek van de Universiteit Twente waarin is aangetoond dat een groot deel van de Nederlandse burgers weinig vertrouwen in de e-overheid heeft en aan de andere kant beleidsdoelstellingen over: ‘de participatiemaatschappij’ (‘doedemocratie’); ‘de iSamenleving’ en ‘de iOverheid’; ‘de Open Overheid’; ‘Digitaal 2017’ alsmede de ontwikkelingen in de EU rondom ‘general data protection regulation’, is duidelijk dat er werk aan de winkel is. Bulk-uitwisselingen komen meer en meer onder vuur te liggen omdat de controleerbaarheid en de transparantie ver te zoeken zijn en ook de inkijk ligt onder vuur nu uit onderzoek van SZW is gebleken dat slechts 4% van de gemeenten de beveiliging rondom SUWInet Inkijk goed heeft geregeld. Wat nodig is zijn lichtere vormen van bevragen en inzien in de informatieuitwisseling tussen overheden. Niet meer ‘alles’ uitwisselen in bulk omdat het kan maar alleen die antwoorden geven die mogen. Dat is ‘privacy by design’. ‘Slim Bevragen’ kan daar een rol in spelen door als standaardmechanisme te worden ingezet als er sprake is van beleidsprocessen waarin alleen nog maar de informatie belangrijk is waarmee het antwoord op de vraag kan worden gegeven.

4.2

Aspecten rondom Slim Bevragen

Uit de interviews en werkconferentie bleek dat men heel verschillende invullingen kan geven aan het begrip Slim Bevragen. Voor een deel komt dit voort uit de beantwoording vanuit verschillende invalshoeken. Wij hebben de volgende invalshoeken benoemd om naar het thema Slim Bevragen te kijken: politiek/bestuurlijk, juridisch, informatiekundig, technisch, financieel, organisatorisch en mens/veranderkundig. Deze zullen hierna achtereenvolgens worden behandeld.

pagina 14 / 25

13 maart 2014


Politiek/bestuurlijk Vanuit de politiek worden soms tegenstrijdige eisen aan het stelsel gesteld: efficiënt handelen, fraudebestrijding, privacybescherming kunnen op gespannen voet met elkaar staan (denk aan zaken als controle achteraf op het recht van uitkering). Daarbij dienen burgers en bedrijven te kunnen vertrouwen op het correcte alsook rechtmatige gebruik door de overheid van diens gegevens. Maatschappelijke vraagstukken worden veelal per domein aangepakt door het opstellen van nieuwe/aanvullende wetten en regelgeving. Dit heeft informatiekundige consequenties (steeds net andere gegevensdefinities) maar ook consequenties op het terrein van de privacybescherming (wat voor het ene doel is vastgelegd, mag niet voor een ander doel gebruikt worden). Juridisch Gestreefd dient te worden naar het voorkomen van onnodig distribueren van gegevens en tegelijk het optimaal voldoen aan de informatiebehoefte zoals benodigd voor efficiënte en effectieve uitvoeringsprocessen. Het begrip “privacy by design” wordt wel gebruikt wanneer systemen en processen van meet af aan zodanig ontworpen worden dat de juiste informatie op het juiste moment op een veilige manier in de uitvoering van wettelijk bepaalde processen aanwezig kan zijn. De roep om privacybescherming wordt nu vaak als belemmerd ervaren voor de inrichting van deze uitvoeringsprocessen. De crux is om de vraag naar een gegeven zodanig te stellen dat deze niet meer en niet minder oplevert dan voor het proces vereist (need to know). Door te vragen naar voor het uitvoeringsproces relevante informatie, in plaats van naar het gegeven zoals dat elders onder een bepaald regime is vastgelegd, kan de doelbindingsvraag verschuiven naar het eind van de keten (van registratie naar gebruik). Informatiekundig / technisch Zoals hierboven gesteld ligt de crux in het niet meer en niet minder opvragen van de informatie zoals nodig voor het eigen (wettelijk bepaalde) uitvoeringsproces. Om slimme (privacy by design) vragen te kunnen stellen, is het nodig te weten welke gegevens zich reeds in het stelsel bevinden, wat deze gegevens precies inhouden alsook waar en hoe deze opgevraagd en vertaald kunnen worden naar voor het eigen proces relevante informatie. Voorbeelden van gegevens die in verschillende domeinen verschillende betekenissen en/of wettelijke consequenties kunnen hebben, zijn het begrip Inkomen, Vermogen, Gezinssamenstelling, etc. Om gegevens van elders op gepaste wijze te kunnen hergebruiken en interpreteren, zijn zogenaamde metadata nodig (gegevens over gegevens). Het stelsel beschikt reeds over voorzieningen hiervoor zoals de stelselcatalogus en het OSR service register. Deze voorzieningen worden echter nog maar matig gebruikt. Bij gegevens die open zijn zou je ook kunnen kiezen voor het implementeren van zoekstructuren á la Google. Om als gebruiker op de kwaliteit van gegevens te kunnen vertrouwen, is echter ook metadata over de kwaliteit van het gegeven belangrijk, zoals de actualiteit van het gegeven. Daarnaast kan het gewenst zijn om de gegevens van elders eerst te vertalen en/of te verrijken met andere gegevens alvorens zij toepasbaar zijn in de eigen processen. Slim Bevragen wordt dan slim leveren. Andere voorzieningen die hiervoor nodig zijn, zijn beveiligingsvoorzieningen, autorisatieregimes etc. Organisatorisch en financieel Voor het stellen van slimme vragen en het ontvangen van slimme antwoorden (gegevenslogistiek) valt te denken aan de inrichting van sectorale loketten. Communiceren via ontkoppelpunten is immers vele malen eenvoudiger en efficiënter dan honderden/duizenden bilaterale (1 op 1) gegevensuitwisselingen via specifieke koppelingen, en vele male veiliger en meer “privacy by design” dan grootschalige uitvraag of inkijk. Hiertoe zal echter wel een en ander geregeld moeten worden op het terrein van organisatie, financiën en governance:

pagina 15 / 25

13 maart 2014


-

-

Organisatorisch: welke sectorale knooppunten onderkennen we, is er een centraal knooppunt voor algemeen identificerende gegevens die in meerdere sectoren gebruikt worden, hoe gaat de communicatie tussen knooppunten, hoe voorkom je drempels tussen de knooppunten, etc. Governance: wie is de eigenaar van een knooppunt, wie is opdrachtnemer en wie zijn de opdrachtgever(s), wie is waarvoor verantwoordelijk bij communicatie tussen knooppunten, etc. Financiering: wat levert het op, wie betaalt wat, is dat wel een relevante vraag (gaat om maatschappelijk belang), hoe regel je voorfinanciering (kost gaat immers voor de baat uit, bijv. via een investeringsfonds).

Mens- en veranderkundig Veranderkundig bezien vergt slim bevragen de paradigmashift van aanbodgericht naar vraaggericht zoals ook benoemd in de implementatievisie stelsel. De informatievoorziening door het stelsel moet aansluiten op de werkprocessen en cultuur van de uitvoerder van deze processen. Het gaat dan niet om het aanbieden van gegevens maar om het beantwoorden van vragen. Dit vergt ook veranderingen in de wijze van werken binnen de organisaties die de gegevens op deze manier slim bevragen dan wel slim beantwoorden. Daarmee verandert ook de relatie tussen organisaties: van de vragende partij vergt dit vertrouwen in het antwoord, opdat deze niet alles zelf gaat uitzoeken en gaat grasduinen in andermans bestanden; van de antwoordende partij vergt dit een paradigmashift in het denken over informatieveiligheid en privacybescherming: in plaats van doelbinding bij het geregistreerde gegeven moet worden uitgegaan van het gegeven vereist voor de uitvoering van een proces zoals wettelijk belegd bij een uitvoerder, zoals hierboven reeds betoogd.

4.3

Definitie en modelvorming

4.3.1

Slim Bevragen als leidend principe

Op basis van het voorgaande is de conclusie te trekken dat het mechanisme van Slim Bevragen een belangrijke plaats krijgt in bestaande en nieuwe uitwisselingen rondom het stelsel van basisregistraties en daarmee in de Gemeenschappelijke Digitale Infrastructuur (GDI, een term uit het rapport van Rob Kuipers van januari 2014). Het zorgt voor privacy by design, hetgeen de toon van de muziek voor de toekomst van het stelsel zal worden. Slim Bevragen lijkt veel efficiënter te zijn dan grote uitwisselingen, maar ook ingewikkelder. Dat blijkt ook wel uit het feit dat op dit moment veel voorbeelden van uitvoeringsprocessen waarin Slim Bevragen een rol zou kunnen spelen opgelost zijn met grootschalige uitwisselingen. Slim Bevragen komt nu nog maar weinig voor, maar het is de verwachting dat in de loop van de tijd alles (of tenminste heel veel) van de vragen van de ene overheidsorganisatie aan de andere Slim zullen worden. Wat hierbij helpt is het inzicht dat is opgedaan in het onderzoek “Uitbreiding van gegevens in het stelsel van basisregistraties” dat PBLQ HEC in opdracht van de PSB in 2013 uitvoerde. Dat afwegingskader is in het kader van SGO3-onderzoek ‘Overheidsbreed stelsel van persoonsgegevens’ uitgebreid en biedt een uitstekende basis om te bepalen op welke wijze een ‘nieuwe’ gegevensvraag middels het stelsel kan worden beantwoord. Een samenvattende beslisboom voor dat uitgebreide afwegingskader is in bijlage C te vinden. Niettemin is Slim Bevragen nog niet eenvoudig te organiseren want dit vereist naast standaarden (waarvan velen al bestaan) en een service georiënteerde architectuur (zie paragraaf 4.3.2). ook een vorm van centrale slimheid (zoals hierna beschreven in paragraaf 4.3.3).

pagina 16 / 25

13 maart 2014


4.3.2

Alles draait om de eenvoud: services

Zoals gezegd, voor Slim Bevragen en daarmee slim verstrekken, is een heel fundamenteel puzzelstukje nodig: services. En het mooie is, dat kunstje kennen we al. Weliswaar nog maar mondjesmaat binnen de overheid, maar al wel veel meer in het bedrijfsleven. Daar is de term SOA al lang geen reden meer om de dokter te bezoeken maar geeft het een denkkader waarin de ICT wordt ingezet in modulaire blokken die, op elkaar gestapeld, alle bedrijfsfuncties van een organisaties ondersteunen. Of, mooier gezegd (bron: Wikipedia): Service Oriented Architecture (SOA) is een architectuurmodel, geen technologie op zich. Centraal bestaat een SOA-opgebouwd systeem uit servicecontracten. Hierbij is sprake van afnemers van diensten en leveranciers. Kenmerkend voor de diensten (en contracten) is:  Een service is virtueel: de afnemer heeft geen weet van de implementatie van de dienst. De dienst is onafhankelijk van de afnemer. Scheiding van verantwoordelijkheid is expliciet vastgesteld. Voordeel hiervan is onafhankelijkheid van veranderingen van afnemer en leverancier. Voldoen aan het contract staat immers centraal;  Een service is gestandaardiseerd: er is slechts één implementatie aanwezig van een verantwoordelijkheid. Voordeel is het rationaliseren van de standaard. Standaardiseren=massa, massa=kassa. De dienst wordt 'commodity' en eenvoudig te vervangen door een andere leverancier of goedkoper door een efficiëntieslag;  Een service is modulair (vervangbaar) en compositioneerbaar. Standaard is niet flexibel. Flexibiliteit wordt bereikt door combineren (componeren) van standaards tot een nieuwe standaard;  Een service is abstract: generiek, niet afgestemd voor 1 specifieke afnemer, maar op een doelgroep van afnemers;  Een service is autonoom: afnemer en leverancier zijn maximaal onafhankelijk van implementatie van beide. Er bestaat geen directe link of relatie tussen verschillende services. Services zijn zich ook niet van elkaar bewust. De motor achter Slim Bevragen is dus een service georiënteerde aanpak van informatie-uitwisseling. En die aanpak moet ingebed worden in een concept waarbij hieronder beschreven functies beschikbaar moeten komen als kern van een toekomstige GDI. En ook daar hebben we al vaker met elkaar over gesproken: stelselknooppunten.

4.3.3

De stelselknooppunten en Slim Bevragen

Het sectorknooppunt, of feitelijk: het sector ontkoppelpunt, heeft een sleutelpositie in een service georiënteerde aanpak die Slim Bevragen binnen onze overheid zou moeten maken. Dat is mooi, want sectoren die al zo ver zijn dat ze een goed functionerend sectorknooppunt (in enige vorm) hebben, kunnen snel op het concept aansluiten zonder al te veel frictiekosten. Wat moet een sectorknooppunt dan tenminste qua functies bieden in onze visie? Ten eerste er dus gewoon zijn. Dat klinkt simpel en is het ook. Allerlei bilaterale uitwisselingen leiden er alleen maar toe dat meer uitwisselingen gepaard gaan met exponentiële groei van het aantal verbindingen. Dat moet maximaal lineair zijn (zegt ook de Taskforce SGO3 in zijn concept-eindrapportage). Alleen als een sector wil aansluiten op een service georiënteerde architectuur en daarbij services ter beschikking wil gaan stellen, zal het tenminste de onderstaande zaken moeten regelen. Als de sector alleen maar wil afnemen, hoeft het in principe geen sectorknooppunt te hebben. In principe, want we kunnen nauwelijks een sector voorstellen die

pagina 17 / 25

13 maart 2014


niet ook services zou willen aanbieden. Daarnaast kan een sectorknooppunt ook een rol binnen de sector hebben om gegevensstromen te ontkoppelen, zoals bijvoorbeeld het Landelijk Schakelpunt Zorg. Theoretisch zou het dus zo kunnen zijn dat een sectorknooppunt alleeen op basis van een service georiënteerde aanpak moet werken om aan te kunnen sluiten op de GDI en als ze dat niet willen mogen ze zelf kiezen hoe ze het inrichten (subsidiariteit). Het tweede punt dat nodig is de autorisatie. Hoewel het prettiger zou zijn (in informatiekundige termen) om een soort van Google-zoekmachine te hebben die overheidspartijen aan elkaar koppelt en waarbij informatie op basis van het elkaar vinden gaat stromen, is het, gezien de aard van veel van de informatie die tussen organisaties wordt uitgewisseld, wenselijk om aan de poort van de sector aan autorisatie te doen. Dat kan op een heel basaal niveau door gebruik te maken van PKI-Overheid-certificaten maar ook geavanceerder door op gebruikersniveau te willen authenticeren. In alle gevallen zal de doelbindingsdiscussie moeten opschuiven van de vrager naar de ontvanger, maar dat vergt meer uitwerking dan in het kader van dit onderzoek mogelijk is en zal dus nader uitgezocht moeten worden. Het derde aspect dat een sectorknooppunt moet regelen is een functie om te ontsluiten welke informatie de sector allemaal beschikbaar heeft, iets als een sectorcatalogus. Aan de ingang van iedere sector moet helder worden welke informatiebronnen waar te vinden zijn. Dit is een Wehkamp-gids van alle services die binnen de sector beschikbaar zijn met alle relevante gegevens die daarbij horen (zoals: waar kan ik ze krijgen, welke standaarden zijn gehanteerd, enz.). Voor deze catalogus zal op landelijk niveau een standaard moeten worden ontwikkeld (of overgenomen van een paar best practices zoals het Nationaal Georegister) zodat consolidatie van deze sectorcatalogi op nationaal niveau mogelijk wordt. Maar de sectorknooppunten blijven altijd verantwoordelijk voor hun eigen sectorcatalogus. Een vierde noodzakelijkheid is een functie die aangeeft of er over een bepaald object informatie beschikbaar is binnen de sector, noem het een verwijsindex. Deze geeft voor iedere sector per te identificeren object in het stelsel van basisregistraties (denk hierbij aan natuurlijke personen, rechtspersonen BAG-objecten, voertuigen, enz.) welke organisatie informatie over dat object heeft. Dat is wel zo handig om te voorkomen dat er onnodige vragen worden gesteld. Een mooi voorbeeld daarvan zijn de berichtenuitwisselingen rondom het Digitaal Kind Dossier (DKD). Op zich al een veel slimmer concept dan de bulk-uitwisselingen die er voor benodigd waren in het verleden, wordt hier per dossier een aantal gegevens verzameld bij verschillende overheidsorganisaties, zo ook bij de Dienst Uitvoering Onderwijs (DUO). Maandelijks (!) verwerken zij 800.000 vragen vanuit het DKD. Het blijkt echter dat ruim 400.000 ervan (de helft) leeg teruggaan naar het DKD omdat de betreffende persoon niet bekend is in het onderwijsdomein. Als vijfde en laatste verantwoordelijkheid tenslotte, is het nodig dat het sectorknooppunt namens de sector informatie beschikbaar stelt over de informatie die de sector ter beschikking stelt. Dit is niet hetzelfde als de genoemde informatie in de sectorcatalogus, maar zou wel via die weg beschikbaar gesteld kunnen worden. Het gaat om het verschaffen van inzicht in de kwaliteit van het gegeven, dat zijn dus aspecten als de actualiteit, de volledigheid, de bron, de verzamelmethode, enzovoort. Die metadata moeten de afnemers helpen om de gegevens goed te kunnen gebruiken in hun eigen processen. Met het toenemend gebruik van informatie buiten de sector waar het ingewonnen wordt, is dit een steeds belangrijker wordend onderwerp. Er zal landelijk moeten worden vastgelegd welke metadata minimaal moet worden bijgehouden, maar de sector heeft hier vaak ook zelf al standaarden voor.

pagina 18 / 25

13 maart 2014


Samengevat komt dit alles schematisch op het volgende neer:

Andere sectoren

Sector catalogus

4.3.4

Sector Knoop Punt

Meta -data

Meta -data

Polisadministratie

Basis Registratie Inkomens

Beheer van Relaties (BD)

SUWI bedrijven register

Meta -data

Meta -data

Verwijs -index

Slim Bevragen

Slim Bevragen is dus het proces van het stellen van informatievragen via een sectorknooppunt waarbij de vraag aan een in die sector beschikbaar gestelde generieke service gesteld wordt en waarbij het antwoord ja of nee is, of het antwoord niet zozeer de geregistreerde gegevens teruggeeft maar niet meer en niet minder dan waarvoor de vragensteller bevoegd is om antwoord te krijgen. Een mooi voorbeeld is “Is BSN-x ouder dan y jaar”, waarvoor de service gemaakt kan worden zonder dat van belang is of deze antwoord geeft op een vraag over het recht op uitkering, het aankopen van alcohol of zelfbeschikking.

pagina 19 / 25

13 maart 2014


5.

Conclusies

5.1

Beantwoording vraagstelling

Welke informatieproducten of dienstverlening van het stelsel van basisregistraties, uitgaande van nu aanwezige gegevens in die registraties, ontbreken in de ogen van uitvoeringsorganisaties in het licht van versnelde en effectievere inzet van het stelsel van basisregistraties in hun werkprocessen? Wat we binnen de Nederlandse overheid missen is het beschikbaar zijn van “slimme antwoorden”. Generieke services die van elders informatie leveren zoals benodigd voor de uitvoering van een specifiek proces. In dit licht ontbreken “standaardvragen” (of eigenlijk standaard antwoorden) per sector; dit betreft zowel enkelvoudige als meervoudige vragen. De behoefte aan deze standaardvragen met antwoorden verschilt echter per afnemer en per sector. Mede hierdoor is niet altijd duidelijk wat Slim Bevragen nu precies oplevert (de businesscase is onhelder, zeker in het geval van meervoudige vragen). Veel enkelvoudige vragen zijn al gerealiseerd in de vorm van koppelingen en/of inkijk-functies (bijv. SUWI). Daarnaast ontbreekt een deel van de voor Slim Bevragen benodigde functies: Niet elke sector heeft een duidelijk sectorknooppunt waar overheden met hun vragen terecht kunnen; Ieder sectorknooppunt zou de doelbindingsvraag door middel van autorisatie-functies aan het begin van de sector moeten kunnen afvangen; Vanuit iedere sector zal middels een sectorcatalogus kenbaar gemaakt moeten worden welke services de sector aanbiedt; Iedere sector zal middels een vorm van verwijsindex zichtbaar moeten maken (onder voorwaarden uiteraard) over welke objecten in het stelsel van basisregistraties zij informatie hebben; Iedere sector moet op een gestandaardiseerde manier omgaan met metadata over de definitie en de kwaliteit van een gegeven (bijv. hoe actueel is het gegeven). Uit de inventarisatie blijkt dat sectorale knooppunten een manier kunnen zijn om op een efficiënte en eenvoudige wijze invulling te geven aan de gegevenslogistiek achter het Slim Bevragen. Er moet echter nog veel geregeld worden om het stelsel van sectorknooppunten (wellicht in de vorm van een rotonde) te realiseren, denk aan zaken als governance en financiering. Hiervoor dient het aanbeveling om aan te sluiten op de ontwikkelingen rond de stelselrotonde c.q. het stelsel van domeinmakelaars (zie ook beantwoording onderzoeksvraag 2). Tot slot zijn ontbrekende stelselfuncties genoemd zoals het als afnemer kunnen wijzigen van adressen en gekwalificeerd terugmelden. Deze vallen echter buiten de scope van Slim Bevragen. Onderzoek hoe de beantwoording van vraag 1 kan worden meegenomen in de overheidsbrede businesscase die eind 2013 wordt opgesteld voor een stelsel van domeinmakelaars. Als ook hoe aangesloten kan worden bij het onderzoek gegevensmakelaar SuwiNet 2.0. Voor de hierboven voorgestelde invulling van het begrip Slim Bevragen middels standaardvragen per sector (oftewel: domein) kan uitstekend aangesloten worden bij het gedachtegoed achter het stelsel van

pagina 20 / 25

13 maart 2014


domeinmakelaars c.q. de gegevensmakelaar Suwinet 2.0 alsook bij het rotondemodel van de taskforce SGO-3. De domeinmakelaar is immers te zien als een sectoraal knooppunt (minirotonde) op de stelselrotonde. De sectorale knooppunten oftewel de domeinmakelaren kunnen als gegevensmakelaar een belangrijke rol spelen bij het Slim Bevragen door te functioneren als: loket waar sectorale organisaties hun vragen kunnen stellen over gegevens elders in het stelsel (of in andere huizen langs de eigen straat) i.e. slim bevragen door sector plek waar gegevens uit verschillende bronnen in het stelsel met elkaar in verband kunnen worden gebracht om specifieke waarde toe te voegen i.e. slim beantwoorden aan sector toegangspoort voor andere sectorale knooppunten en/of organisaties uit andere sectoren die vragen hebben inzake gegevens uit de betreffende straat of laan i.e. slim bevragen aan sector.

5.2

Conclusies en aanbevelingen

Het lijkt zeer de moeite waard om het concept van Slim Bevragen verder vorm te geven, te valideren en mee te experimenteren. Hier liggen immers zeker kansen om kosten te besparen, zij het dat deze niet gerealiseerd zullen worden op de korte termijn waar SGO-3 zich op richt. Maar daarnaast (en misschien wel belangrijker) vormt Slim Bevragen de enabler van een paradigma shift van het leveren van geregistreerde gegevens naar het privacy by design leveren van antwoorden zoals benodigd voor de efficiënte en effectieve uitvoering van processen. Hierdoor schuift het doelbinding principe op van voor in de keten (registratie) naar achterin de keten (verantwoord gebruik). Hoe dit precies vorm gegeven kan worden, vergt nog wel enig nader onderzoek. Bij de realisatie van Slim Bevragen moeten we klein beginnen en de focus leggen op de (organisatie van de) informatiekundige vraag. Ons voorstel is om het concept Slim Bevragen nader te verkennen door eerst een aantal cases uit te werken. Bijv. de casus “eigen bijdrage voor studenten in een inrichting” of “informatieverstrekking bij scheiding. Op basis van deze cases kan dan aangegeven worden wat voor deze cases ontbreekt, welke voorzieningen nodig zijn, wat er dan beter gaat en wat de gevolgen zijn op informatiekundig, juridisch, financieel, organisatorisch etc. gebied. Wij zijn van mening dat de uitwerking van dergelijke cases effectiever is dan het opstellen van een algemene businesscase voor het nog tamelijk conceptuele idee achter Slim Bevragen. De historie in acht nemend, hebben wij ons uiteraard afgevraagd waarom het concept van de GOB eerder niet geleid heeft tot de inrichting van een stelsel van sectorale knooppunten (domeinmakelaars) die gebruik maken van Slim Bevragen voor het ontsluiten van gegevens uit het stelsel. Met andere woorden: waarom gaat het nu wel lukken? Dit heeft ons inziens alles te maken met de wijze waarop de GOB eerder als algemene voorziening is neergezet die in termen van het rotonde-model midden op de rotonde zou komen te staan. Door de GOB op die manier te positioneren ging de discussie vooral over bestuurlijke, organisatorische, financiële, juridische zaken. Door nu eerst, op basis van een concrete sectorale vraag, decentraal GOB-achtige voorzieningen als Slim Bevragen en samengestelde vragen te beleggen bij de zogenaamde sectorknooppunten (domeinmakelaars), kunnen deze voorzieningen stapsgewijs gerealiseerd worden en kan de discussie focussen op vooral de informatiekundige kant: welke (evt. samengestelde) antwoorden wil je via Slim Bevragen uit een sector kunnen krijgen?

pagina 21 / 25

13 maart 2014


5.3

Hoe nu verder?

Voor de verdere totstandbrenging van Slim Bevragen komen wij tot de volgende mogelijke aanpak op basis van principes als “keep it simple” en “op zoek naar quick wins”: Realiseer standaardvragen Identificeer per sector in eerste instantie vijf gegevens bij wijze van startpunt die het meest gevraagd worden door partijen van buiten de sector en definieer hier slimme standaardvragen voor. Begin hierbij met de vragen die het eenvoudigst te realiseren zijn en/of de vragen die het meeste gesteld worden. Het idee achter SGO-3 is immers op korte termijn effectiever en efficiënter gebruik van de basisregistraties te bevorderen en niet het schetsen van vergezichten van baten op de lange termijn. Kijk per standaardvraag wie hiervoor bereid is te betalen. Laat de vraag van de afnemer leidend zijn en niet de mogelijkheid die de registratie biedt. Hanteer het principe privacy by design D.w.z. definieer de standaardvragen zodanig dat deze alleen antwoord geven op dat nodig is voor de uitvoering van gebruikende processen. Zo kan het opvragen van iemands geboortedatum privacygevoelig zijn en mogelijk niet passen binnen de doelbinding waarvoor het gegeven is vastgelegd. Maar voor veel vragen kan het voldoende zijn om te weten of iemand volwassen is, m.a.w. “is BSN-x ouder dan 18 jaar”. Andere voorbeelden zijn: “ligt het inkomen van BSN-x boveneen bepaald bedrag” (in plaats van: hoe hoog is het inkomen), “is bedrijf Y gevestigd op dit adres” (in plaats van wie woont/zit er op dit adres), “zit student X in detentie” (in plaats van “waarvoor zit X”), heeft BSN-x het gezag over BSN-Y (in plaats van “is de ouder van het kind uit het gezag gezet) etc. In het algemeen betreft het hier ja/nee vragen in plaats van inhoudelijke vragen. Hierdoor wordt breder gebruik van gegevens mogelijk, zonder meteen toegang te krijgen tot allerlei onderliggende persoonlijke informatie. En gelet op de wettelijke basis onder het uitvoeringsproces, heeft de betreffende afnemers ook inderdaad recht op het beschikken over dit gegeven. Begin met enkelvoudige vragen Afnemers kunnen ook zelf meervoudige vragen maken, door meerdere enkelvoudige vragen na elkaar te stellen. Meervoudige “off the shelf” standaardvragen vereisen een afweging in het kader van het onderzoek dat nu afgerond wordt in opdracht van DUO. Sluit met de ontwikkeling van Slim Bevragen aan op het rotondemodel Zie hierbij de rotonde als de stip op de horizon waar naar toe moet worden gewerkt. Begin met het definiëren en stimuleren van de sectorale knooppunten. Focus hierbij op de wel kunners en willers (de bulk). Vanwege grote getallen zit hier de winst (doelstelling SGO3). Werk daarnaast aan maatregelen voor niet-kunners resp. niet-willers. Waarbij niet-kunners met name zit in menselijke ondersteuning en niet-willers met name in fraudebestrijding. Bevorder het gebruik van de rotonde door de minirotondes (sectorknooppunten) in te richten als informatiepalen (waar je gegevens en services / apps kan krijgen) in plaats van als verkeersdrempels (tolpoortjes) door te focussen op het beantwoorden van vragen uit andere sectoren en niet op de privacyissues. Op deze wijze wordt parallel gewerkt aan de realisatie van quick wins op korte termijn (enkelvoudige standaardvragen) en de beoogde innovatie op lange termijn (rotondemodel met sectorknooppunten voor de uitwisseling van sectorale gegevens).

pagina 22 / 25

13 maart 2014


Bijlage A

Geïnterviewde personen

Onderstaande tabel geeft weer de geïnterviewde personen alsmede hun aanwezigheid tijdens de eerste resp. tweede werkconferentie. Datum

Naam

Organisatie

WC1

WC2

07-11-13

Noud Hooijman

Min. I&M

X

X

09-12-13

Edward Roscam Abbing

Min. Financien / BD

X

X

11-12-13

Arjan Levinga

RWS

X

X

11-12-13

Marcel Pellicaan

CAK

X

12-12-13

Annemarieke van Splunter

Min. SZW

X

16-12-13

Ron Roozendaal

Min. VWS

19-12-13

Wilma Willems

Min. BZK / prog. maatsch.baten

03-02-14

Harry Blankena

DUO

Geen

Remco Siegerist

UVW

X

X

X

X

Daarnaast was op de eerste werkconferentie aanwezig Dirk Schravendeel (PBLQ, onderzoeker SGO-3 fiches 8, 9 en 11), op de tweede werkconferentie Erik Dolle (PBLQ, onderzoeker SGO-3 fiches 10 en 12) en op beide bijeenkomsten het team voor dit fiche bestaande uit Dirk Jan van der Linden, Patty Heemskerk en Udo Pijpker.

pagina 23 / 25

13 maart 2014


Bijlage B

Bestudeerde documentatie

#

Documentnaam

Auteur / organisatie

Datum

1

Startarchitectuur GOB

ICTU/ODP

02-10-2008

2

Visie op stelsel basisregistraties

BZK

28-05-2010

3

Slotrapportage sectorcoördinatoren

HEC in opdracht van ICTU/Renoir

09-11-2010

4

Implementatievisie stelsel basisregistraties

HEC et alt in opdracht van PSB

25-06-2012

5

Vergezicht 2020

Willems, Zuurmond, Ducastel en Crasborn

23-04-2013

6

Architectuurschets van het stelsel voor gegevensuitwisseling V1.0

ICTU

17-06-2013

7

Uitbreiding van gegevens in het stelsel van basisregistraties

PBLQ HEC in opdracht van PSB

18-06-2013

8

Eindadvies verkenning informatievoorziening sociaal domein (VISD)

KING

29-07-2013

9

De burger bediend in 2013

Inspectie SZW

18-10-2013

10

Verslag sessie Domeinmakelaars 17-12-13

SZW

17-12-2013

11

Advies Governance Generieke Digitale Infrastructuur

Rob Kuipers in opdracht van BZK

14-01-2014

pagina 24 / 25

13 maart 2014


Bijlage C Afwegingskader

Gegevensbehoefte in processen

Nee

Is de gegevensbehoefte duidelijk?

Ja

· · · ·

Wordt de gegevensbehoefte gedeeld door meer dan één proces? Gaat het om dezelfde typen objecten? Is er voldoende Gaat het om vergelijkbare overlap in de objectverzamelingen? gegevensbehoeften van Is er genoeg overlap in de meerdere processen? kwaliteitseisen? Zijn de objecten eenduidig identificeerbaar?

Nee

Gesloten procesregister(s)

Nee

Procesoverstijgende registratie binnen enkele organisatie

Buiten scope

·

5x Ja

Worden deze processen uitgevoerd door meer dan één organisatie?

Ja

Gezamenlijke gegevensbehoefte vastgesteld

Is de gegevensbehoefte af te leiden uit reeds beschikbare gegevens?

(Doorloop voor dit gegeven eerst het afwegingskader om de passende registratiewijze te bepalen.)

Nee

Ja

Nee

Kan de afleiding in de processen eenduidig en tegen beperkte inspanning plaatsvinden?

Ja Registreer het resultaat van de afleiding (in een bestaande of nieuwe registratie)

pagina 25 / 25

13 maart 2014

Bevraag Slim

Registreer het gegeven (in een bestaande of nieuwe registratie)


SGO-3 onderzoek - Slim Bevragen & GBSO

Recommend Documents