Wat kun je vinden op deze pagina?
- 1 Probleemstelling
- 1.1 Omschrijving
- 1.2 Herkomst
- 1.3 Raakvlakken
- 2 Oplossing
- 2.1 Huidige situatie
- 2.2 Oplossing
- 2.3 Openstaande punten
- 3 Consequenties
- 3.1 Logisch Ontwerp BRP
- 3.2 Logisch Ontwerp BSN
- 3.3 Logisch Ontwerp BRPk
- 3.4 Logisch Ontwerp BES
- 3.5 Logisch Ontwerp PGK
- 3.6 Beschrijving Interface Reisdocumenten
- 4 Invoering
- 5 Gevolgen
- 5.1 Externe partijen
- 5.2 Wet- en regelgeving BRP
- 5.3 Financiën
- 5.4 RvIG-systemen met externe zichtbaarheid
W171 oplegnotitie Haal Centraal API's Fase I-2
1 Probleemstelling
1.1 Omschrijving
Het programma Haal Centraal van de VNG zorgt ervoor dat basisgegevens uit landelijke registraties eenvoudig direct bij de bron kunnen worden opgehaald door gemeentelijke taakapplicaties en systemen van andere afnemers met behulp van Application Programming Interfaces (API's). De BRP is één van die landelijke basisregistraties. Door aan te sluiten op deze API's hoeven gemeenten geen gemeentelijke gegevensmagazijnen meer bij te houden waarin zij feitelijk een kopie van de eigen basisregistratie personen bewaren ten behoeve van binnengemeentelijke bevragingen. De instandhouding van die gegevensmagazijnen is duur doordat gegevensuitwisseling ermee via complexe en verouderde StUF-BG koppelvlakken gebeurt. Daarnaast ontstaan er verschillen tussen de gegevens in de BRP en in die gegevensmagazijnen, en geldt voor afnemers dat die nogal eens op verschillende wijze omgaan met de gegevens uit de BRP, en bijvoorbeeld de aanschrijfnaam op verschillende wijzen samenstellen uit de naamgegevens uit de BRP. De doelstellingen van Haal Centraal zijn dan ook: kostenreductie, een efficiëntere en effectievere wijze van het gebruik van gegevens uit de BRP, betere kwaliteit, meer consistentie bij het gebruik van die gegevens en dataminimalisatie.
Om te onderzoeken of aansluiting op de BRP API's van het programma Haal Centraal het inderdaad mogelijk maakt om afscheid te nemen van die gemeentelijke gegevensmagazijnen wil RvIG samen met de VNG een pilot starten waarin een aantal gemeenten én afnemers de BRP gaat bevragen via de API's van Haal Centraal. In eerste instantie zullen deze API's alleen gegevens verstrekken waarin de wet reeds voorziet (fase I). In fase II zullen ze ook informatie verstrekken die van de BRP-gegevens kan worden afgeleid (zoals leeftijd op basis van de geboortedatum, en aanschrijfnaam op basis van naamgegevens en aanduiding naamgebruik). Om die informatie te mogen verstrekken, is echter een experimentbesluit nodig, omdat dit een andere manier van gegevensverstrekking is dan die waarin de wet BRP nu voorziet.
De API's van Haal Centraal vormen een nieuwe wijze van ad hoc gegevensverstrekking uit BRP-V en dienen als zodanig ook in het LO te worden beschreven, en geschouwd en getoetst te worden.
In een eerder wijzigingsvoorstel (W162) is de verstrekking van gegevens door middel van de BRP Personen API in het LO opgenomen. Dit wijzigingsvoorstel bevat de beschrijving van de benodigde aanpassingen in het LO om verstrekkingen van gegevens (fase I) door middel van de BRP Reisdocumenten API van Haal Centraal in het LO op te nemen. De BRP Bewoning API en de BRP Historie API volgen in een latere versie van LO BRP. Voor fase II zal ook een separate LO-wijziging worden voorbereid.
1.2 Herkomst
Wens van de gemeenten en de VNG om BRP-gegevens direct bij de bron op te halen.
1.3 Raakvlakken
Er zijn geen raakvlakken met andere LO-wijzigingen.
2 Oplossing
2.1 Huidige situatie
In de huidige situatie houden gemeenten een schaduwregistratie bij van hun eigen inwoners, en bevragen ze BRP-V via de adhoc webservice wanneer gegevens van niet-inwoners nodig zijn (in dat geval functioneert de gemeente dus als buitengemeentelijke afnemer - GABA). Ook afnemers bevragen de BRP-V via de adhoc webservice. Dit is een SOAP webservice. Toegang tot deze webservice, autorisatie voor adhoc verstrekking van de gevraagde gegevens en protocollering van die verstrekkingen zijn in het LO beschreven. Met de invoering van de BRP Personen API is de behoefte aan een eigen gegevensmagazijn wel verminderd, maar nog niet verdwenen.
2.2 Oplossing
Het onderhavige LO-wijzigingsvoorstel bevat het logisch ontwerp van de BRP Reisdocumenten API. Het technisch ontwerp staat op de Github pagina's van de RvIG. De API's worden ontsloten via een API Gateway, een in de markt gebruikelijke wijze voor het regelen van toegang, authenticatie en autorisatie tot API's.
Gemeenten hebben voor het raadplegen van de gegevens van eigen inwoners geen aanvullende autorisaties nodig; dit geldt niet als gegevensverstrekking door de Minister. Voor het raadplegen van de gegevens van niet-eigen inwoners, en voor alle verstrekkingen aan afnemers, voldoen de bestaande autorisaties voor ad hoc gegevensverstrekking.
Alle bevragingen via API's worden gelogd én geprotocolleerd. Logging wordt gedaan door de API Gateway; protocollering wordt gedaan door de API applicatie door alle gegevens met betrekking tot een verstrekking aan te bieden aan een protocolleringsinterface van BRP-V. De BRP-V leest deze gegevens in, in de eigen protocolleringstabellen, zodat deze terechtkomen in de bestaande protocolleringsoverzichten wanneer een gemeente daarom vraagt.
Alleen deelnemers aan de pilot van Haal Centraal kunnen gebruik maken van de BRP API's. Deelname aan de pilot is echter niet beperkt tot deze gemeenten en afnemers: wanneer een andere gemeente of afnemer deel wil nemen aan de pilot, kan deze eveneens het convenant ondertekenen en aansluiten op de API’s.
2.3 Openstaande punten
Voor fase I (verstrekking van gegevens, nog geen afgeleide informatie) zijn er geen openstaande punten. Voor fase II (verstrekking van informatie; W172) moet het Experimentbesluit dataminimalisatie BRP worden genomen, zodat de Minister gegevens mag verwerken tot informatie, en die informatie mag verstrekken. Omdat die verstrekkingen in een afzonderlijke LO-wijziging worden beschreven is dat voor nu geen openstaand punt.
3 Consequenties
3.1 Logisch Ontwerp BRP
De nieuwe API wordt conform de inhoud van hoofdstuk 2 in het LO beschreven.
3.2 Logisch Ontwerp BSN
Geen wijzigingen.
3.3 Logisch Ontwerp BRPk
Geen wijzigingen.
3.4 Logisch Ontwerp BES
Geen wijzigingen.
3.5 Logisch Ontwerp PGK
Geen wijzigingen.
3.6 Beschrijving Interface Reisdocumenten
Geen wijzigingen.
4 Invoering
Toegang tot de API's wordt uitsluitend verstrekt aan deelnemers van de pilot van Haal Centraal. Voor alle overige gemeenten en afnemers heeft deze wijziging geen consequenties.
5 Gevolgen
5.1 Externe partijen
5.1.1 Gemeenten
Voor gemeenten die niet deelnemen aan de pilot van Haal Centraal verandert er niets. Voor gemeenten die wel deelnemen, wordt het mogelijk om BRP-V te bevragen via de nieuwe API's van Haal Centraal. De API's verstrekken vooralsnog uitsluitend gegevens zoals het LO die al beschrijft, en nog geen "informatie".
5.1.2 Gemeenten – Burgerlijke Stand modules
Geen gevolgen.
5.1.3 Gemeenten – Reisdocumenten modules
Geen gevolgen.
5.1.4 Afnemers
Uitsluitend deelnemers aan de pilot ondervinden gevolgen. Die kunnen de BRP bevragen via API's zodra ze hun systemen daar geschikt voor hebben gemaakt en toegang tot de API Gateway hebben gekregen.
5.1.5 IND
Geen gevolgen.
5.1.6 Caribisch Nederland
Geen gevolgen.
5.1.7 Caribische Landen
Geen gevolgen.
5.2 Wet- en regelgeving BRP
5.2.1 Wet- en regelgeving BRP
Voor dit punt is een Experimentbesluit opgesteld.
5.2.2 Autorisaties
Geen gevolgen.
5.2.3 Wet- en regelgeving Caribisch Nederland
Geen gevolgen.
5.2.4 Wet- en regelgeving BSN
Geen gevolgen.
5.2.5 Wet -en regelgeving Reisdocumenten
Geen gevolgen.
5.3 Financiën
5.3.1 Financiën
Geen gevolgen.
5.4 RvIG-systemen met externe zichtbaarheid
5.4.1 BRP-V en/of Daft
Geen gevolgen.
5.4.2 RNI
Geen gevolgen.
5.4.3 A-nummer aanvraag programma (AAP)
Geen gevolgen.
5.4.4 TMV
Geen gevolgen.
5.4.5 Evaluatie-Instrument
Geen gevolgen.
5.4.6 POM/POWS
Geen gevolgen.
5.4.7 Tabellenapplicatie
Geen gevolgen.
5.4.8 Berichtenverkeer en mailboxserver
Er zijn geen gevolgen voor het bestaande berichtenverkeer via de berichtendienst en de webservices. De API’s vormen echter wel een nieuwe wijze van gegevensverstrekking en alle berichten die ondersteund worden om gegevens op te vragen via API’s, worden dan ook in dit wijzigingsvoorstel toegevoegd aan het LO.
5.4.9 PGK-module
Geen gevolgen.
5.4.10 PIVA-V
Geen gevolgen.
5.4.11 Tabellenapplicatie PIVA
Geen gevolgen.
5.4.12 BV BSN
Geen gevolgen.
5.4.13 RAAS
Geen gevolgen.
5.4.14 Basisregister/Verificatieregister
Geen gevolgen.
5.4.15 Signaleringsregister
Geen gevolgen.
5.4.16 Centraal meldpunt Identiteitsfraude
Geen gevolgen.
5.4.17 Proefomgevingen BRP-V
Geen gevolgen.
5.4.18 Proefomgeving BV BSN
Geen gevolgen.