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.

1 Probleemstelling

1.1 Omschrijving

Het programma Haal Centraal van de VNG (inmiddels ondergebracht onder programma Toekomst BRP van RvIG) zorgt ervoor dat gegevens uit landelijke basisregistraties 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. In fase I werden via de BRP API's (de BRP Bewoning API, de BRP Personen API en de BRP Reisdocumenten API) alleen nog gegevens verstrekt die één op één overgenomen zijn van een PL, maar met de inwerkingtreding van het Experimentbesluit BRP dataminimalisatie mag de Minister die gegevens bewerken tot informatie, en die informatie ook verstrekken aan afnemers. Hiermee wordt mogelijk gemaakt dat afnemers alleen die informatie krijgen die ze echt nodig hebben, en dat de afleiding van die informatie op dezelfde manier plaatsvindt voor alle afnemers.

In eerdere wijzigingen (W162, W171 en W185) is de verstrekking van gegevens door middel van de drie BRP API's in het LO BRP opgenomen. Deze wijziging bevat de beschrijving van de benodigde aanpassingen om verstrekkingen van informatie in het LO BRP op te nemen.

1.2 Herkomst

Wens van de gemeenten en de VNG om BRP-gegevens, alsook daarvan afgeleide informatie, direct bij de bron op te halen.

1.3 Raakvlakken

Tegelijk met deze aanpassing wordt ook de verstrekking van informatie over gezag toegevoegd aan de BRP Personen API. Deze toevoeging is opgenomen in LO-wijziging W189 Uitbreiding BRP API met gezag.

2 Oplossing

2.1 Huidige situatie

In de huidige situatie kunnen afnemers al wel om informatie vragen bij RvIG, maar verstrekt RvIG via de BRP API's alleen de gegevens die nodig zijn om de gevraagde informatie af te leiden. Die afleiding vindt in een "proxy" plaats bij de afnemer. Of afnemers geautoriseerd zijn voor de gevraagde gegevens kan pas worden gecontroleerd na vertaling van de informatievraag naar de benodigde gegevens. Ook protocollering van de verstrekking van de gevraagde gegevens kan pas na de vertaling van de informatievraag worden gedaan.

2.2 Oplossing

De BRP API's van RvIG gaan nu informatievragen rechtstreeks beantwoorden, zodat de proxy bij de afnemers niet langer nodig is. In het LO BRP wordt beschreven welke informatie kan worden verstrekt, hoe voor de verstrekking van informatie kan worden geautoriseerd en dat die verstrekking moet worden geprotocolleerd. Zo wordt het bijvoorbeeld mogelijk om afnemers wel te autoriseren voor de informatie leeftijd, maar niet voor het gegeven geboortedatum, dat nodig is om de leeftijd te berekenen. Om dat te kunnen doen binnen de kaders van de huidige systematiek voor autoriseren en protocolleren, wordt de informatie waarvoor dit nodig is, aangeduid met rubrieken, zoals dat ook met gegevens op de PL gebeurt. Deze nieuwe rubrieken worden in het gegevenswoordenboek in het LO BRP opgenomen, maar blijven wel duidelijk onderscheiden van de rubrieken die de gegevens op een PL bevatten.

Voor informatie wordt daarom een nieuw soort gegevens geïntroduceerd in het gegevenswoordenboek: afgeleide gegevens. Deze gegevens zijn afgeleid van de gegevens op de PL en staan daar zelf niet op. Voor afgeleide gegevens worden nieuwe rubrieken geïntroduceerd, waarbij categorieën en groepen worden aangeduid met letters in plaats van cijfers. Deze informatierubrieken worden alleen toegevoegd voor zover dit nodig is voor autoriseren en protocolleren.

Op basis van het Experimentbesluit BRP dataminimalisatie kunnen de volgende soorten bewerkingen van gegevens tot informatie worden onderscheiden:

a)    Afleiden: het samenstellen van een nieuw gegeven uit één of meer gegevens op één of meer persoonslijsten, zodanig dat uit dat het nieuwe gegeven de oorspronkelijke gegevens, die voor de afleiding gebruikt zijn, niet terug te herleiden zijn. Bijvoorbeeld: de voorletters worden afgeleid uit de voornamen. Of uit meerdere gegevens wordt één antwoord afgeleid, bijvoorbeeld de aanschrijfnaam: hiervoor zijn gegevens over de eigen naam van de persoon nodig, maar ook eventueel aanwezige gegevens over een huwelijk/geregistreerd partnerschap. Of het BSN van alle personen die gezag hebben over een minderjarige wordt afgeleid uit gegevens over gezag op de persoonslijst van die minderjarige en wettelijke regels over gezag van rechtswege.
b)    Aggregeren: het afleiden van aantallen en gemiddelden uit gegevens op meerdere persoonslijsten in de BRP. Een dergelijk aantal of gemiddelde is niet tot één persoonslijst of gegevens op die persoonslijst te herleiden. Bijvoorbeeld: het aantal in- en uitschrijvingen op een adres binnen een bepaalde periode, of het gemiddelde aantal ingeschrevenen op een adres gedurende een bepaalde periode.
c)    Alterneren: het verstrekken van het ene dan wel het andere gegeven van een persoonslijst, afhankelijk van een conditie. Bijvoorbeeld: als antwoord op de vraag vanaf welke datum een persoon op een bepaald adres verblijft, wordt óf de datum aanvang adres, óf de datum aanvang verblijf buitenland verstrekt.
d)    Splitsen: het opsplitsen van een rubriek naar meerdere velden/rubrieken, zodanig dat uit een afgesplitst deel het oorspronkelijke gegeven niet valt terug te herleiden. Bijvoorbeeld: een geboortedatum splitsen in afzonderlijke delen: geboortedag, geboortemaand of geboortejaar.
e)    Verifiëren: vaststellen of een bepaald gegeven precies overeenkomt met het gegeven op de persoonslijst, zonder het gegeven zelf te verstrekken. Bijvoorbeeld: komt het door de burger opgegeven adres overeen met het in de BRP-geregistreerde adres (antwoord ja/nee). Dit wordt ook wel hit/no hit genoemd.
f)    Verwijzen: het opnemen van een verwijzing (hyperlink) naar een ander object in de registratie in het antwoord op een informatievraag. Bijvoorbeeld naar de persoonslijst van een gerelateerde van de persoon van wie de persoonslijst is bevraagd, of naar het verblijfsobject in de Basisregistratie Adressen en Gebouwen (BAG).

Voor bewerkingen die als resultaat een afgeleid gegeven hebben waaruit de gebruikte brongegevens van de persoonslijst zonder meer terug te herleiden zijn, is geen extra juridische grondslag nodig: deze bewerkingen mag de Minister reeds doen onder de Wet BRP. Voorbeelden van zulke bewerkingen zijn het formatteren van datums (bijvoorbeeld 3 juni 2016 in plaats van 20160603) en het verstrekken van een omschrijving bij een code op basis van publiek toegankelijke (vertaal)tabellen (bijvoorbeeld: de gemeentenaam bij de gemeentecode). Voor dergelijke afgeleide gegevens zijn afnemers impliciet geautoriseerd als zij geautoriseerd zijn voor het brongegeven (de datum of de code zoals die op de PL staat). Bij verstrekking van zulke gegevens wordt geprotocolleerd dat het brongegeven verstrekt is. Daarom is het niet nodig om informatierubrieken te definiëren voor deze vormen van afgeleide gegevens.

Verstrekkingen van afgeleide gegevens die conform regelgeving en beleid mee moeten worden verstrekt (onderzoek, RNI-deelnemer, verificatie) worden niet beperkt door middel van autorisaties. Verstrekking van deze gegevens worden niet geprotocolleerd. Daarom is het niet nodig om informatierubrieken te definiëren voor alle elementen in de objecten "inOnderzoek", ook al worden die wel afgeleid uit element 83.10.

In het LO BRP worden beschreven:

• De nieuwe gegevenssoort "afgeleide gegevens";
• De bewerkingen die kunnen worden gedaan om tot die afgeleide gegevens te komen;
• De nieuwe categorieën, groepen en elementen, voor zover nodig om te kunnen autoriseren voor verstrekking van afgeleide gegevens en die verstrekkingen te kunnen protocolleren;
• Bij elke informatierubriek: welke bewerking wordt gedaan bij de totstandkoming van de afgeleide gegevens en welke gegevens van de PL daarvoor worden gebruikt. Voor de bewerking zelf (het algoritme) wordt verwezen naar de specificaties op Github.

De afleidingsregels voor de informatierubrieken worden tevens opgenomen in het algoritmeregister.

2.3 Gerelateerde wijzigingen in wet- en regelgeving

Deze LO-wijziging kan pas in werking treden als het Experimentbesluit BRP dataminimalisatie in werking is getreden.

2.4 Openstaande punten

Er zijn geen openstaande punten.

3 Invoering

Om de migratie naar de nieuwe versie van de drie BRP API's eenvoudig te maken voor afnemers, stelt RvIG een nieuwe versie van de proxy ter beschikking. Voor deze nieuwe proxy maakt het geen verschil of hij antwoord krijgt van de huidige versie van de BRP API's bij RvIG (die BRP-gegevens verstrekken), of van de nieuwe (die informatie verstrekken). Daarom hoeven afnemers na installatie van de nieuwe versie van de proxy niets meer te doen op het moment dat RvIG de nieuwe versie van de drie BRP API's in gebruik neemt.

4 Gevolgen

4.1 Documentatie

De nieuwe versie van de drie BRP API's worden conform de inhoud van hoofdstuk 2 in het LO BRP beschreven.

4.2 Gemeenten

Voor gemeenten in hun rol als bijhouder zijn er geen gevolgen.

4.3 Afnemers

Deze wijziging heeft uitsluitend gevolgen voor deelnemers aan de pilot die al zijn aangesloten op de BRP API's. Aansluiten op de nieuwe versie van de BRP API's vereist van deze afnemers alleen dat ze een nieuwe versie van de proxy installeren. Deze zal zowel de oude versie van de BRP API's bij RvIG ondersteunen als de nieuwe en dus automatisch herkennen of er LO-gegevens of informatie verstrekt zijn/is. Op langere termijn staat het afnemers vrij om de proxy te verwijderen en de BRP API rechtstreeks, via hun API Gateway, te benaderen.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

Geen gevolgen.

4.6 RvIG-systemen

Er wordt op (of rond) de datum van inwerkingtreding van LO BRP waarin deze wijziging is opgenomen een nieuwe versie van de BRP API's in productie genomen (mits het Experimentbesluit BRP dataminimalisatie daadwerkelijk in werking is getreden).

1.1 Omschrijving

Ongeveer 1500 keer per jaar wordt een persoon ingeschreven in de BRP, terwijl hij al een persoonslijst heeft. Dit gebeurt bijvoorbeeld wanneer de gemeente- of RNI-medewerker de presentievraag niet of niet correct stelt, of het antwoord erop niet goed interpreteert. Hij merkt dan niet op dat de persoon die zich komt inschrijven, al ingeschreven is, en schrijft hem nogmaals in, met twee persoonslijsten met verschillende A-nummers voor deze persoon tot gevolg. De BRP-V heeft vanaf dat moment twee persoonslijsten van deze persoon, en kan die beide verstrekken aan afnemers.

Als een dubbelinschrijving van dit type wordt ontdekt, wordt één van de persoonslijsten afgevoerd met opschortreden ‘F’. Daarvan krijgen de afnemers die een afnemersindicatie bij die PL hebben geplaatst een bericht. Maar die hebben soms niet door dat er een correcte PL is overgebleven waarbij zij een nieuwe afnemersindicatie kunnen zetten. Ze blijven dan werken met de verkeerde persoonsgegevens, of hebben helemaal geen gegevens meer over deze persoon. En vragen zij de persoonslijst op met een niet langer bestaand A-nummer, dan stuurt de BRP-V een melding dat hij de persoon niet heeft kunnen vinden. Dit leidt in de praktijk tot vragen aan de Frontoffice van RvIG.

Volledigheidshalve:

• Er is ook een andere vorm van dubbelopneming, de zgn. ‘blinde’ dubbelinschrijving, die meestal het gevolg is van een niet goed afgeronde verhuiscyclus. Hierbij is een persoon meerdere keren in een gemeentelijke BRP of RNI ingeschreven, onder hetzelfde A-nummer. In de eerste helft van 2022 ging het om 85 gevallen. Om deze situatie recht te trekken, dient de gemeente de overtollige PL niet af te voeren, maar te verwijderen en te vervangen door een verwijzing naar de gemeente waar de overgebleven PL zich bevindt. Afnemers merken hier niets van; er was in de BRP-V maar één PL met dit A-nummer en dat blijft zo na deze herstelactie.
• Een PL kan ook worden afgevoerd zonder dat sprake is van een dubbelinschrijving. Het gaat dan om een onterechte inschrijving bijv. van een niet bestaand persoon.

1.2 Buiten scope

De volgende situaties vallen buiten de scope van deze wijziging:

• Meerdere personen met hetzelfde A-nummer. Alle personen krijgen een nieuw A-nummer; er wordt geen PL afgevoerd.
• Een persoon meerdere keren ingeschreven in gemeentelijke BRP’s met hetzelfde A-nummer; in dat geval wordt de overtollige PL verwijderd, niet afgevoerd (situatie 2 hierboven).
• Afnemers zonder afnemersindicatie krijgen überhaupt geen bericht en blijven dus voorlopig mogelijk werken met verkeerde persoonsgegevens. Wel gaat het hier vaak om afnemers die zelf geen persoonsadministratie bijhouden.
• Afnemers die selecties ontvangen. Die ontvangen altijd de actuele stand van zaken op het moment dat de selectie wordt gedraaid. Voor hen is dit wijzigingsvoorstel dus niet relevant.
• Persoonslijsten worden wel eens onterecht afgevoerd, wat vanzelfsprekend grote gevolgen kan hebben voor de betreffende burger. Gegevenslevering over correctie hiervan aan afnemers kan ook beter.

De laatste twee punten vallen weliswaar buiten de scope van deze wijziging, maar zullen later wel aan bod komen (zie § 1.3).

1.3 Herkomst

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 het programma luidt: ZKF-02-02 Gegevenslevering bij afgevoerde persoonslijsten verbeteren. Dit initiatief is opgesplitst in drie onderdelen. Het eerste daarvan, ZKF-02-02a, beoogt de spontane verstrekkingen te verbeteren over afgevoerde persoonslijsten (aan afnemers met een afnemersindicatie). Deze wijziging komt daaruit voort.

1.4 Raakvlakken

De overige twee onderdelen van bovengenoemd initiatief zijn:

• ZKF-02-02b: Verbeteren ad hoc gegevenslevering bij afgevoerde persoonslijsten.
• ZKF-02-02c: Verbeteren gegevenslevering bij correcties van onterecht/foutief afgevoerde persoonslijsten.

2 Oplossing

2.1 Huidige situatie

Wanneer een dubbelopneming wordt geconstateerd, dan wordt één van de twee persoonslijsten afgevoerd met opschortreden ‘F’ (ten onrechte opgenomen), nadat eventueel gegevens van de overtollige PL zijn overgenomen op de PL die overblijft. Op de overblijvende PL wordt het Vorig A-nummer opgenomen; op de af te voeren PL het Volgend A-nummer. De groep A-nummerverwijzingen betreft echter administratieve gegevens, die niet spontaan verstrekt worden. Afnemers ontvangen dus geen Gv01-bericht als het Volgend A-nummer wordt toegevoegd op een af te voeren persoonslijst.

Zodra een PL wordt afgevoerd, stuurt BRP-V een Ng01-bericht (Afvoeren PL) aan alle afnemers die een afnemersindicatie hebben staan bij de afgevoerde PL. Dat Ng01-bericht bevat alleen gegevens over de afgevoerde PL zelf, niet over de PL die overblijft. Het is afnemers dan niet altijd duidelijk dat er nog een actuele persoonslijst is van de betreffende persoon waarbij zij een nieuwe afnemersindicatie zouden moeten plaatsen. Daardoor blijven zij mogelijk verkeerde persoonsgegevens gebruiken. Of hebben zij, als ze het afvoerbericht correct hebben verwerkt, helemaal geen gegevens meer over die persoon.

2.2 Oplossing

Als een PL wordt afgevoerd wegens een dubbelinschrijving , stuurt BRP-V naast het A-nummer van de afgevoerde PL ook het A-nummer van de overgebleven PL mee in het Ng01-bericht, mits de bijhouder dat heeft ingevuld toen hij de PL afvoerde. Dat maakt de link tussen beide persoonslijsten duidelijk; afnemers weten dan welke persoon zij eventueel in hun systemen moeten bijwerken en of zij bij de overgebleven PL een nieuwe afnemersindicatie moeten plaatsen .

2.3 Gerelateerde wijzigingen in wet- en regelgeving

Geen.

2.4 Openstaande punten

Geen.

2.5 Overwogen alternatieven

Als een PL wordt afgevoerd vanwege een dubbelopneming, wordt in groep 20 een volgend A-nummer opgenomen. Dit zou je kunnen beschouwen als een A-nummerwijziging, de persoon gaat immers door met een ander A-nummer. In het geval van een A-nummerwijziging stuurt BRP-V een Wa11-bericht naar de afnemer. Het resultaat zou dan zijn, dat de afnemer zowel een Ng01- als een Wa11-bericht ontvangt.
Het volgende A-nummer maakt, net als het huidige, al deel uit van het Wa11-bericht, en hoeft dan dus niet toegevoegd te worden aan het Ng01-bericht. Dit zou voor de afnemer tot voordeel hebben dat de berichtstructuur niet wijzigt. Wel moet hij zijn processen aanpassen omdat hij een combinatie van Wa11 en Ng01 over hetzelfde A-nummer anders moet verwerken dan één van de losse berichten afzonderlijk.
Ook in BRP-V moeten in dit geval processen worden aangepast; nu beschouwt BRP-V alleen een ander A-nummer in element 01.01.10 als een A-nummerwijziging, en niet als een A-nummer in groep 20 (Vorig/volgend A-nummer) wordt gezet. Al met al een ingrijpendere wijziging aan beide kanten, zodat de keuze op de uitbreiding van het Ng01-bericht is gevallen.

3 Invoering

Vanaf de dag dat BRP-V de eerste Ng01 met Volgend A-nummer stuurt, moet de ontvangende organisatie daar op voorbereid zijn. Dit wijzigingsvoorstel vereist dus invoering op één moment bij alle afnemers die geautoriseerd zijn voor spontane mutaties en dus Ng01-berichten (kunnen) ontvangen.

4 Gevolgen

4.1 Documentatie

4.1.1 LO BRP

Aan bericht Ng01 (Afvoeren PL), dat momenteel de volgende rubrieken bevat:

• 01.01.10    A nummer
• 07.67.10    Datum opschorting bijhouding
• 07.67.20    Omschrijving reden opschorting bijhouding.

voegen we rubriek 01.20.20 Volgend A-nummer toe als optionele parameter.

4.1.2 HUP

Geen. De huidige werkwijze, zoals beschreven in de HUP, voorziet al in de bijhouding van het volgende A-nummer op een afgevoerde PL. De HUP hoeft op dit punt dus NIET aangepast te worden.

4.1.3 LO BES

Idem aan §4.1.1.

Wijzigingen aan berichten van BRP-V worden automatisch ook doorgevoerd in PIVA-V, omdat BRP-V en PIVA-V dezelfde software gebruiken.

4.2 Gemeenten

Geen. De huidige werkwijze, zoals beschreven in de HUP, voorziet al in de bijhouding van het volgende A-nummer op een afgevoerde PL.

4.3 Afnemers

Geautoriseerde afnemers van BRP-V ontvangen een extra veld in het Ng01-bericht over een afgevoerde PL waarbij zij een afnemerindicatie hebben staan: het A-nummer van de overblijvende PL. Zij moeten er op zijn minst voor zorgen dat hun systemen niet vastlopen op dit extra veld als zij een Ng01-bericht binnenkrijgen.
In principe geldt dit ook voor afnemers van de PIVA-V, maar in het Caribisch gebied maakt nog niemand gebruik van spontane verstrekkingen en dus zullen afnemers daar niets merken van deze wijziging.

De bestaande autorisaties hoeven niet te worden aangepast. Als het LO zegt dat een bepaald gegeven automatisch wordt meeverstrekt, dan staat niet meer ter discussie of de afnemer dat gegeven wel of niet verstrekt mag krijgen. Dat antwoord is al in het LO gegeven.
Wel moet de toelichting bij de autorisatiebesluiten worden aangepast, maar dat kan later. (De toelichting zou duidelijker moeten beschrijven welke A-nummers een afnemer krijgt na afvoeren van een PL met opschortreden ‘F’.)

4.4 IND

Geen.

4.5 Caribische landen en Caribisch Nederland

Deze wijziging heeft geen gevolgen voor de PBK-module. Voor PIVA-V, zie §4.6. Voor gevolgen voor afnemers zie §4.3.

4.6 RvIG-systemen

BRP-V: Uitbreiding van bericht Ng01 met optioneel 01.20.20 Volgend A-nummer.
PIVA-V: Idem.

1 Probleemstelling

1.1 Omschrijving

Op 1 januari 2024 is LO BRP versie 2024.Q1 in werking getreden. Hierin wordt een vaste koppeling afgedwongen tussen het te registreren actuele woon- of briefadres in de BRP en een geldig hoofdadres van een adresseerbaar object in de BAG. Op deze aanpassing zijn diverse signalen van gemeenten binnengekomen: het is gebleken dat het niet kunnen opvoeren van een nevenadres als briefadres, wanneer een gemeente of organisatie als briefadresgever voor een burger optreedt, ongewenste situaties kan opleveren. Deze wijziging voor het LO BRP zal ervoor zorgen dat het opvoeren van een nevenadres voor de hierboven beschreven situatie mogelijk wordt.

1.2 Herkomst

Dit initiatief, BRN-07-01 Oplossen verschillen BAG-BRP, valt onder BRP Doorontwikkeling en hoort bij het ontwikkelpunt: BRN Bevragen bij de bron.

1.3 Raakvlakken

Dit wijzigingsvoorstel is een aanvulling op W180 Oplossen verschillen BAG-BRP.

2 Oplossing

2.1 Huidige situatie

Vanaf 1 januari 2024 moeten alle actuele woon- of briefadressen in de BRP een vaste koppeling hebben met een geldig hoofdadres van een adresseerbaar object in de BAG. Dit betekent dat een actueel adres in de BRP altijd moet verwijzen naar een hoofdadres van een adresseerbaar object uit de BAG. Dit geldt zowel voor een woonadres als voor een briefadres; ook als de briefadresgever een gemeente of een organisatie is.

2.2 Oplossing

Het LO BRP gaat voor de vaste koppeling tussen het geregistreerde briefadres in de BRP en het adresseerbaar object in de BAG ook een nevenadres toestaan, mits de briefadresgever een gemeente of een organisatie is. Bij een briefadres van een natuurlijk persoon én bij een woonadres is een koppeling met een nevenadres van het adresseerbaar object in de BAG nooit toegestaan. Of op een adres in de BAG een natuurlijk persoon woont of dat er een gemeente of organisatie is gehuisvest, wordt afgeleid uit het gebruiksdoel van het betreffende object, dat geregistreerd is in de BAG: als het gebruiksdoel ‘Woonfunctie’ bevat behoort woont er een natuurlijk persoon, en anders is er een gemeente of organisatie gehuisvest.

Voor alle duidelijkheid, deze vaste koppeling:

• geldt voor het actuele woon- of briefadres in groep 11 Adres van alle ingezetenen, dus van alle personen die met status Actueel (= niet-opgeschort) in de BRP zijn ingeschreven;
• geldt NIET voor historische adressen, waarbij het chronologisch opvolgende adres een datum aanvang adreshouding vóór of op 1 januari 2024 heeft;
• geldt NIET voor categorie 16 Tijdelijk verblijfadres.

2.3 Gerelateerde wijzigingen in wet- en regelgeving

Geen.

2.4 Openstaande punten

Geen.

3 Invoering

Op 01-01-2024 is het LO BRP versie 2024.Q1 met de vaste koppeling naar een hoofdadres van een geldig adresseerbaar object in de BAG in werking getreden. Omdat op dat moment al bekend is dat nevenadressen als briefadres van een gemeente of organisatie met een volgende LO BRP versie mogelijk gemaakt gaat worden, wordt vanaf januari 2024 een nevenadres behorende bij een gemeente of organisatie als briefadres niet als bevinding geconstateerd en komt deze niet in de Kwaliteitsmonitor.
RvIG heeft met de 3 softwareleveranciers van gemeenten (Centric, PinkRoccade en Procura) afgesproken, dat wijziging W191 in het LO BRP versie 2024.Q2 zal worden verwerkt.

4 Gevolgen

4.1 Documentatie

Er zijn alleen wijzigingen vereist aan het LO BRP en de HUP. Nu staat expliciet in het LO BRP dat een persoon altijd in de BRP moet worden ingeschreven op het hoofdadres van een geldig adresseerbaar object in de BAG, ongeacht of het een woonadres of briefadres betreft. Met deze LO wijziging wordt dit aangepast, zodat in categorie 08 Verblijfplaats groep 11 Adres het gebruik van een nevenadres van het object in de BAG mogelijk wordt, maar alleen als groep 10 Adreshouding het element 10.10 Functie adres waarde “B” heeft en het gebruiksdoel van het betreffende adresseerbare object in de BAG niet de waarde “Woonfunctie” bevat. In alle andere situaties moet altijd het hoofdadres van het object in de BAG worden gebruikt. Deze wijziging heeft geen gevolgen voor het berichtenverkeer.

In de HUP zal een beschrijving worden toegevoegd over het toegestane gebruik van een nevenadres in bovenstaande specifieke situatie. Ook zal daarin benadrukt worden dat het op het betreffende nevenadres wel mogelijk moet zijn post te bezorgen.

4.2 Gemeenten

Gemeenten mogen een nevenadres als briefadres opvoeren, maar alleen in de situatie dat een gemeente of organisatie als briefadresgever optreedt. Wanneer een organisatie als briefadresgever optreedt dan is dit een rechtspersoon die zijn zetel in Nederland heeft en die door het college van burgemeester en wethouders is aangewezen om als briefadresgever in zijn gemeente op te treden.

4.3 Afnemers

Geen gevolgen.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

Geen gevolgen.

4.6 RvIG-systemen

Geen gevolgen.