W146 Melding aan bewoners bij nieuwe inschrijving woonadres (Seintje)

1. Probleemstelling

1.1 Omschrijving

Het basisidee achter het inschrijven van een persoon die zich wenst in te schrijven op een adres is dat de aangifte door die persoon wordt gevolgd. Dit kan als ongewenst bijeffect hebben dat iemand zich kan inschrijven op een adres terwijl de huidige bewoners daar geen weet van hebben en de persoon ook feitelijk niet op dat adres verblijft. Die huidige bewoners kunnen hiervan wel hinder ondervinden in de vorm van post voor deze spookbewoner, deurwaardersbezoek of een afwijzing voor een toeslag omdat het inkomen van deze spookbewoner wordt meegeteld.

Het principe dat iemand zich kan inschrijven waar hij of zij daadwerkelijk woont, moet zeker in stand blijven. Maar informeren van de huidige bewoners kan het herstellen van foutieve inschrijvingen aanzienlijk versnellen. Gemeenten hanteren thans eigen beleid op dit punt, vaak ook bepaald door de (vermoede) omvang van dit issue in hun specifieke gemeente, maar de Tweede Kamer heeft aangedrongen om dit via de Wet BRP te regelen.

1.2 Herkomst

De Tweede Kamer heeft in eerste instantie een amendement ingediend om dit als verplichting voor gemeenten in de Wet BRP te verankeren. Uiteindelijk is ervoor gekozen om in een Experimentbesluit per AMvB te regelen dat er een ‘seintje’ naar de huidige of nieuwe bewoners wordt gestuurd. Door de staatssecretaris is aan de Tweede Kamer toegezegd haast te maken met dit experiment.

1.3 Raakvlakken

In W162 (Haal Centraal API's) is onder meer het gebruik van API's als wijze van gegevensverstrekking in algemene zin beschreven. Omdat W162 reeds in LO 4.2 is opgenomen, worden die algemene aanpassingen in het LO hier niet opnieuw gespecificeerd.

 

2. Oplossing

2.1 Huidige situatie

Artikel 2.20, eerste lid, Wet BRP, bepaalt dat de gegevens omtrent de aangifte van een adreswijziging, worden ontleend aan die aangifte, tenzij aannemelijk is dat de gegevens onjuist zijn. Gemeenten doen hun best om foutieve aangiften te voorkomen, zoals vragen om een verklaring van de ‘hoofdbewoner’, maar daarvoor ontbreekt een goede juridische basis. Er zijn ook thans al gemeenten die de huidige bewoners informeren als er zich iemand op ‘hun’ adres vestigt, maar daartoe bestaat geen verplichting.

2.2 Oplossing

Het experiment "Informeren Ingezetenen over Inschrijvingen op het woonadres" is onderdeel van het Experiment "Bijhouding BRP" en heeft een actieve kant (uit te voeren door de gemeenten) en een passieve kant (burger kan op MijnOverheid zien hoeveel personen er op ‘zijn’ woonadres staan ingeschreven). 
Bij wijze van experiment worden colleges van B&W verplicht om in alle gevallen huidige bewoners actief te informeren over het aantal personen dat zich op ‘hun’ adres inschrijven, dan wel de nieuwe bewoners actief te informeren over het aantal personen dat nog op ‘hun’ adres staan ingeschreven. Voor deze verplichting is een aanpassing in de gemeentelijke systemen wenselijk, maar niet noodzakelijk. Het LO (de systeembeschrijving van de BRP) hoeft hier niet op te worden aangepast.
Het tweede onderdeel van het experiment houdt in aan ingezetenen op verzoek elektronisch worden geïnformeerd over het aantal personen dat op hun adres is ingeschreven. Omwille van de privacy wordt alleen het aantal bewoners verstrekt, en geen persoonsgegevens. Deze functionaliteit wordt door Logius geïmplementeerd in Mijn Overheid, maar MO haalt die informatie via een API op uit de BRP. De beschrijving van die API wordt in het LO opgenomen met het voorliggende wijzigingsvoorstel. 
Het Experiment heeft overigens uitsluitend betrekking op het gebruik van een adres als woonadres. Personen die een adres gebruiken als briefadres of als tijdelijk verblijfadres (niet-ingezetenen), worden buiten beschouwing gelaten.

2.3 Openstaande punten

Er zijn geen openstaande punten.

 

3. Consequenties

3.1 Logisch Ontwerp BRP

Er wordt een nieuwe API toegevoegd in hoofdstuk 5 van LO BRP, waarmee Mijn Overheid op basis van een burgerservicenummer het aantal bewoners kan opvragen van het adres waarop de persoon met dat BSN staat ingeschreven.

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

Voor dit wijzigingsvoorstel is een experimentbesluit nodig. Van dat experiment is de voorhangprocedure inmiddels voltooid; het ligt nu bij de Raad van State. Het ziet er naar uit dat het experiment in werking zal treden per 1 juli 2023.

 

5. Gevolgen

5.1 Externe partijen

5.1.1 Gemeenten

Systeemaanpassing om gemeenten te ondersteunen bij het bepalen of en zo ja, welke personen (huidige bewoners of juist de nieuwe bewoners) moeten worden geïnformeerd over een verhuizing. Ook bepalen voor welke adressen dit niet geldt.

5.1.2 Gemeenten – Burgerlijke Stand modules

Geen gevolgen.

5.1.3 Gemeenten – Reisdocumenten modules

Geen gevolgen.

5.1.4 Afnemers

Van alle afnemers heeft dit wijzigingsvoorstel uitsluitend gevolgen voor Mijn Overheid (Logius). De koppeling met de nieuwe API moet geïmplementeerd worden.

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

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

Een API aanbieden aan MijnOverheid, waarmee MO het aantal bewoners kan opvragen dat actueel is ingeschreven op een adres. Dit adres kan worden gespecificeerd met het BSN van de persoon die over dit aantal moet worden geïnformeerd.

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. Als het experiment wordt omgezet in een vaste werkwijze, zou de procedure waarmee dit wordt geregeld deel uit kunnen maken van de zelfevaluatie.

5.4.6 POM/POWS

Van elk van de personen die zijn meegeteld in het uiteindelijke aantal ingeschrevenen wordt geprotocolleerd dat 08.11.80 Identificatiecode verblijfplaats is verstrekt aan Logius. Dat zal dus ook op de protocolleringsoverzichten worden getoond. Hiervoor is geen aanpassing van de POM of POWS nodig.

5.4.7 Tabellenapplicatie

Geen gevolgen.

5.4.8 Berichtenverkeer en mailboxserver

Geen gevolgen.

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

De nieuwe API wordt ook in de proefomgevingen van BRP-V geïmplementeerd.

5.4.18 Proefomgeving BV BSN

Geen gevolgen.

5.5 Interne RvIG-systemen

5.5.1 BCM

Geen gevolgen.

5.5.2 BaTMan

Geen gevolgen.

5.5.3 Robin

Geen gevolgen.

5.6 Documentatie

5.6.1 Technische Handleiding ABO-Interface

Geen gevolgen.

5.6.2 HUP

De procedure voor het informeren van bewoners over een nieuwe inschrijving op hun adres moet in de HUP worden opgenomen.

5.6.3 WIR

Geen gevolgen.

5.6.4 Website

Communicatie naar burgers over de passieve inzagemogelijkheid.