1 Probleemstelling

1.1 Omschrijving

In LO 2024.Q2 is informatie over gezag toegevoegd aan de BRP Personen API (LO-wijziging W189 Uitbreiding BRP API met gezag). Informatie omtrent gezag van of over een persoon kon worden bevraagd via de functie "raadpleeg met burgerservicenummer". Op verzoek van de Politie wordt er nu een aparte zoekingang toegevoegd "zoek met adresseerbaar object identificatie". Hiermee kan de politie met één enkele bevraging alle gezagsrelaties opvragen van alle personen die als bewoner staan ingeschreven op een adres.

1.2 Herkomst

Programma Toekomst BRP, initiatief BRN-01-02 Uitbreiden informatievragen Haal Centraal (Gezag).

1.3 Raakvlakken

Nee. Het is een toevoeging aan LO-wijziging W189 Uitbreiding BRP API met gezag, die in LO 2024.Q2 is opgenomen.

2 Oplossing

2.1 Huidige situatie

Op dit moment is informatie over gezag van of over een persoon alleen op te vragen via de functie "raadpleeg met burgerservicenummer".

2.2 Oplossing

Informatie over gezag wordt via een nieuwe zoekingang "zoek met adresseerbaar object identificatie" in dezelfde JSON-structuur ontsloten als in "raadpleeg met burgerservicenummer" (zie LO BRP, par. 5.3.12.4). Verder is deze nieuwe zoekingang identiek aan de andere zoekingangen (ZoekMetGeslachtsnaamEnGeboortedatum, ZoekMetNaamEnGemeenteVanInschrijving, etc.).

2.3 Gerelateerde wijzigingen in wet- en regelgeving

Er zijn geen relaties met wet- en regelgeving. De juridische grondslag voor het verwerken van BRP-gegevens tot informatie over gezag is vastgelegd in het experimentbesluit BRP dataminimalisatie, dat op 22 april 2024 in werking is getreden.

2.4 Openstaande punten

Er zijn geen openstaande punten meer na implementatie van deze wijziging in de BRP Personen API.

3 Invoering

Geen bijzonderheden.

4 Gevolgen

4.1 Documentatie

De uitbreiding moet worden beschreven in LO BRP.

4.2 Gemeenten

Er is geen impact op gemeenten in hun rol van bijhouder.

4.3 Afnemers

De nieuwe zoekingang wordt alleen ontsloten voor de Politie, dus er is geen impact op andere afnemers.

4.4 IND

Er is geen impact op de IND in haar rol van bijhouder.

4.5 Caribische landen en Caribisch Nederland

Er is geen impact op het Caribisch deel van het Koninkrijk.

4.6 RvIG-systemen

Bij RvIG wordt alleen een nieuwe versie van de container met daarin de BRP Personen API opgeleverd.

1 Omschrijving

BRP-V geeft afnemers de mogelijkheid “slim” te zoeken naar personen. Zij kunnen zoekwaarden aan het eind verruimen met een wildcard, of zoeken onafhankelijk van hoofdletters of diakrieten. Slim zoeken is echter aan bepaalde regels gebonden, die onvoldoende garantie bieden dat een afnemer een persoon daadwerkelijk vindt.

1.2 Herkomst

Programma toekomst BRP heeft tot doel de kwaliteit en continuïteit van de BRP (stelsel en data) te borgen en te verbeteren. Eén van de initiatieven uit dat programma luidt: ZKF-01-01 Slimmer zoeken in BRP-V. Deze LO-wijziging komt daaruit voort.

1.3 Raakvlakken

Initiatief ZKF-01-02 Uitbreiden zoekfunctie – tranche 1 beoogt een verdere verbetering in het zoeken naar ‘onvindbare’ personen, bijv. door te zoeken met deels onbekende datums, of door met reguliere expressies meer complexe zoekvragen te stellen. Bovendien zal er een initiatief worden ingediend bij tBRP om de verschillende zoekmethoden in het BRP-stelsel voor zover mogelijk te uniformeren, zodat gebruikers op een consistente manier kunnen zoeken, ongeacht of ze de webservice of de BRP API’s gebruiken, of zoeken via BV BSN.

2 Oplossing

2.1Huidige situatie

BRP-V kent onderstaande slimme zoekmogelijkheden bij ad hoc bevragingen (beschreven in het Logisch Ontwerp BRP):

• Zoeken op het eerste deel van de rubriekwaarde, door aan het einde een sterretje “*” (wildcard) toe te voegen;
• Zoeken zonder onderscheid tussen hoofdletters en kleine letters (case insensitive);
• Zoeken onafhankelijk van diakritische tekens.

2.2 Oplossing

De zoekmogelijkheden van Slim zoeken worden uitgebreid met:

• Zoeken op een willekeurig deel van de voornamen en geslachtsnaam: het sterretje mag overal in de voornamen of geslachtsnaam voorkomen; en kan staan voor 0, 1 of meerdere karakters.
  Met zoekterm J*nsen vind je bijvoorbeeld:
  o Jansen
  o Jensen
  o Johansen
  o Jung Hansen 
• Zoeken op voorletters: door gebruik van spaties en sterretjes kun je in het voornamenveld zoeken naar voorletters. Daarbij kun je wel de volgorde bepalen, maar niet de precieze positie. Met zoekterm A*B* vind je bijvoorbeeld:
  o Albert Berend
  o Albert Pieter Berend
  o Albert Berend Karel
  o Albert Pieter Berend Karel
  o Maar niet: Albert Pieter-Bas

2.3 Gerelateerde wijzigingen in wet- en regelgeving

Geen.

2.4 Openstaande punten

Geen.

3 Invoering

Geen bijzonderheden.

4 Gevolgen

4.1 Wijzigingen LO BRP

De beschreven werking van Slim zoeken wordt uitgebreid met de nieuwe zoekmogelijkheden, als genoemd in paragraaf 2.2.

4.2 Wijzigingen in HUP

N.v.t.

4.3 Gemeenten (bijhouders)

N.v.t.

4.4 Afnemers

Afnemers krijgen uitgebreidere zoekmogelijkheden tot hun beschikking in de bestaande zoekvelden, maar de oude methoden blijven ook werken. Zij hoeven in principe hun systemen niet aan te passen, tenzij zij de zoekmogelijkheden in hun user interface anders willen aanbieden. Bijvoorbeeld: bij het zoeken op voorletters verwacht de Ad hoc webservice sterretjes, waar de gebruiker misschien punten denkt te moeten invoeren. Het staat de ontwikkelaar van de user interface natuurlijk vrij een dergelijke vertaalslag in te bouwen.

4.5 IND

N.v.t.

4.6 Caribische landen en Caribisch Nederland

Slimmer zoeken is in principe ook beschikbaar voor PIVA-V, dat immers functioneel gezien een kopie is van BRP-V. Zodra de functionaliteit daar wordt ‘aangezet’ zal ook LO BES worden aangepast.

4.7 RvIG-systemen

De nieuwe zoekfunctionaliteit zal in BRP-V worden ingebouwd.

1 Probleemstelling

1.1 Omschrijving

De gezagsmodule (GM) is een systeem dat op basis van een BSN aangeeft wie er gezag hebben over de persoon met dat BSN, of over wie die persoon gezag heeft. Van die personen wordt het BSN in het antwoord opgenomen. Dit maakt het voor bijv. Politie en KMAR veel eenvoudiger om te bepalen of iemand met een minderjarige mag reizen. Ook wordt deze module gebruikt door de zogenaamde BevoegdheidsVerklaringsDienst, waarmee partijen (bijv. zorgverleners) kunnen nagaan of iemand namens iemand anders mag optreden.

De GM is gebouwd door en in beheer bij Logius. Logius heeft aangegeven dit niet op lange termijn te kunnen blijven doen en de staatssecretaris wil de functionaliteit van de GM nu juist aanbieden aan meer afnemers dan alleen Politie, KMAR en Veilig Thuis. Daarom onderzoekt RvIG wat nodig is om de GM in beheer te nemen bij RvIG. Het eerste dat daarvoor nodig is, is dat de GM wordt opgenomen in de BRP als centrale voorziening. Dat betekent ook dat het koppelvlak waarmee de GM wordt bevraagd, in het Logisch Ontwerp BRP moeten worden beschreven, maar ook dat afnemers voor verstrekking van informatie over gezag moeten worden geautoriseerd en dat die verstrekkingen moeten worden geprotocolleerd.

Omdat de GM feitelijk informatie afleidt uit gegevens op verschillende PL-en, en deze informatie verstrekt is daar een juridische grondslag voor nodig. Die wordt geboden door het Experiment BRP dataminimalisatie. Afnemers die gezagsinformatie willen gebruiken, moeten dan ook deelnemers worden aan het experiment en een convenant ondertekenen: ook de afnemers die nu al gebruik maken van de GM.

Om het voor nieuwe afnemers bovendien eenvoudiger te maken aan te sluiten en te zorgen dat de GM "automatisch" het zelfde niveau van beveiliging, service levels en juridische kaders voldoet, wordt de GM ontsloten door de BRP Personen API. Het informatieproduct "gezag" wordt aan de BRP Personen API toegevoegd. Het koppelvlak tussen de BRP Personen API en de GM wordt een interne koppeling die niet in het LO beschreven hoeft te worden. Huidige afnemers zullen moeten overstappen op de BRP Personen API.

1.2 Herkomst

De wens van BZK/DO om de gezagsmodule al op te nemen in de centrale voorzieningen van de BRP zodra er een juridische basis is voor de Minister (lees: RvIG) om informatie over gezag af te leiden en te verstrekken.

1.3 Raakvlakken

Tegelijk met deze wijziging zal ook W172 in werking treden. In die LO-wijziging wordt geregeld dat de BRP API's niet langer uitsluitend BRP-gegevens verstrekken, maar (ook) informatie. De bewerking van gegevens tot informatie vindt dan niet langer bij gebruikers van de BRP API's plaats, maar bij RvIG. De juridische grondslag hiervoor wordt geboden door het Experimentbesluit BRP dataminimalisatie. Deze wijziging zal dan ook niet in het LO BRP worden opgenomen voordat dit experimentbesluit in werking treedt.

2 Oplossing

2.1 Huidige situatie

Op dit moment is Logius geautoriseerd voor ad hoc bevraging van BRP-V. Die autorisatie wordt gebruikt door de GM, die de ad hoc bevraging doet op het moment dat de GM wordt bevraagd (via een speciale API van de GM). De GM bewerkt de ad hoc verstrekte gegevens uit de BRP tot een antwoord op de vraag aan de GM. In de BRP API's worden op dit moment nog geen informatie verstrekt, laat staan informatie over gezag.

2.2 Oplossing

De BRP Personen API wordt als een "schil" om de GM geplaatst. Afnemers van informatie over gezag bevragen de BRP Personen API, die vervolgens de GM bevraagt. De GM wordt niet langer rechtstreeks benaderd. In dit wijzigingsdocument wordt beschreven hoe informatie over gezag wordt opgenomen in de BRP Personen API, op welke wijze voor die informatie kan worden geautoriseerd en op welke wijze de verstrekking van die informatie wordt geprotocolleerd.

In de BRP Personen API wordt een object toegevoegd met daarin alle gezagsrelaties van de bevraagde persoon, inclusief eventuele andere gezaghouders. Dus als gegevens worden opgevraagd van een minderjarige, worden daarbij de BSN's van alle gezaghouders verstrekt, en een aanduiding van de aard van de gezagsrelatie (eenhoofdig gezag, tweehoofdig gezag, voogdij, etc.). Als gegevens worden opgevraagd van een meerderjarige, dan worden alle BSN's verstrekt van personen over wie die meerderjarige gezag heeft, én de BSN's van eventuele personen met wie die meerderjarige samen tweehoofdig ouderlijk gezag, gezamenlijk gezag, of voogdij uitoefent.

Daarnaast wordt een zoekingang toegevoegd waarmee partijen als de Politie kunnen zoeken op een verblijfsobject (via de identificatiecode verblijfplaats / adresseerbaar object identificatie), om zo alle personen te vinden die zijn ingeschreven op dat verblijfsobject, mét al hun gezagsrelaties.

2.3 Openstaande punten

Het in beheer nemen van de GM door RvIG heeft veel meer aspecten dan alleen dit juridische traject. Die hebben echter geen gevolgen voor het Logisch Ontwerp BRP.

3 Invoering

De huidige gebruikers van de GM zullen moeten worden geautoriseerd voor verstrekking van informatie over gezag. Bovendien moeten zij overstappen van rechtstreekse bevraging van de GM naar bevraging van de BRP Personen API. Om dat te mogen doen, moeten ze het convenant ondertekenen voor deelname aan het Experiment BRP dataminimalisatie.

Nieuwe afnemers die informatie over gezag willen gebruiken, zullen ook het convenant moeten ondertekenen en geautoriseerd worden voor informatie over gezag alvorens aan te mogen sluiten op de BRP Personen API.

4 Gevolgen

4.1 Documentatie

Deze wijziging in het LO BRP heeft geen gevolgen voor andere logisch ontwerpen (LO BSN, LO BRPk, LO BES en LO PGK), ook niet voor de HUP en de WIR.

4.2 Gemeenten

Voor gemeenten (als bijhouder) verandert er niets.

4.3 Afnemers

Bestaande gebruikers van de GM zullen moeten worden geautoriseerd voor ad hoc verstrekking van informatie over gezag. Daarnaast zullen ze het convenant moeten ondertekenen voor deelname aan het Experiment BRP dataminimalisatie. Vervolgens moeten ze overstappen van rechtstreekse bevraging van de GM naar bevraging van de BRP Personen API. Voor afnemers die geen gebruik maken van informatie over gezag verandert er niets.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

Geen gevolgen.

4.6 RvIG-systemen

Er zal een nieuwe versie van de BRP Personen API in de daarvoor reeds bestaande container moet worden geïnstalleerd. De Tabellen Applicatie zal geschikt moeten worden gemaakt voor het autoriseren voor informatievragen. BRP-V en POM zullen geschikt moeten worden gemaakt voor het protocolleren van verstrekking van informatie. Maar dit wordt allemaal al geregeld in LO-wijziging W172 Haal Centraal API's Fase II.