Inleiding

Goed kunnen zoeken in de Basisregistratie Personen (BRP) is essentieel voor veel afnemers en hun bedrijfsprocessen. Het is daarbij belangrijk dat ook met een beperkte hoeveelheid identificerende gegevens, de juiste persoon gevonden kan worden. Een goede zoekstrategie kan veel tijd besparen en helpt bovendien om de privacy van burgers te beschermen. Persoonsgegevens worden immers minder vaak ‘onterecht’ verstrekt en geraadpleegd wanneer afnemers op zoek zijn naar gegevens van een persoon waarvan ze weinig identificerende gegevens hebben. Daarom werkt RvIG voortdurend aan verbeteringen in de zoekmogelijkheden en zich inzet om de bestaande mogelijkheden onder de aandacht te brengen.

Deze handleiding is voor het zoeken en raadplegen van persoonsgegevens via de Ad-hoc- webservice van de BRP Verstrekkingsvoorziening (BRP-V).

Wie staat er wel en niet in de BRP

Gegevens in de BRP zijn ingevoerd vanaf 1-10-1994

Vóór 1 oktober 1994 bestond de bevolkingsadministratie in Nederland uit papieren persoonskaarten. Met de ingang van de Wet Gemeentelijke Basisadministratie persoonsgegevens (GBA), op 1 oktober 1994, is de digitalisering van de persoonsregistratie gestart. Van iedereen die op deze datum in Nederland woonde, zijn de persoonsgegevens van papier geconverteerd naar digitale gegevens in de GBA. Dat waren toen ongeveer 15 miljoen mensen.

Dus vanaf dat moment stond iedereen die op deze datum in Nederland woonde in de GBA, behalve de personen die zijn:

• Geëmigreerd vóór 1-10-’94;
• Overleden vóór 1-10-’94;

Dit is belangrijk om je te realiseren bij het zoeken. Want als je iemand zoekt die vóór deze datum is overleden, dan kun je die persoon niet vinden in de BRP. Het is nog wel mogelijk om de gegevens van de persoonskaart op te vragen bij de gemeente waar de persoon woonde ten tijde van het overlijden. Als de persoon vóór die tijd is geëmigreerd, dan zal je die in de meeste gevallen ook niet vinden. In sommige gevallen kan het zijn dat de persoon wel vindbaar is, bijvoorbeeld bij hervestiging in Nederland op een later moment. Of als de persoon na 2013 is ingeschreven als niet-ingezetene.

Inschrijving in de BRP is voor altijd

Vanaf het moment dat is gestart met de digitalisering van de gegevens in de toenmalige GBA, 1 oktober 1994, geldt dat als iemand eenmaal in de GBA/BRP is opgenomen met een persoonslijst, deze persoonslijst er altijd in blijft staan.

Wanneer iemand verhuist naar een andere gemeente, dan verhuist de persoonslijst mee naar de gemeente waar de persoon naar toe verhuist.

Iemand kan zich uitschrijven als inwoner van Nederland als hij/zij naar het buitenland verhuist; de persoonslijst ‘verhuist’ dan automatisch van de laatste woongemeente naar de Registratie Niet-ingezetenen (RNI). De RNI is onderdeel van de BRP, dus de persoonslijst blijft in de BRP staan, en is via BRP-V te bevragen. Ook wanneer iemand overlijdt, dan blijven de geregistreerde persoonsgegevens in de BRP staan. Ook de persoonsgegevens van een overledene zijn via BRP-V te bevragen. De status van de persoonslijst (niet-ingezetene of overleden) wordt met het antwoord op een ad-hoc-vraag automatisch mee verstrekt, zodat het voor de afnemer duidelijk is dat het niet om een ingezetene gaat.

Iedereen in de BRP heeft een BSN en een A-nummer

Iedereen die in de BRP staat (ingezetene, niet-ingezetene of overledene) heeft een burgerservicenummer en een A-nummer. Iemand die geen BSN heeft, kan niet als persoon in de BRP staan. Het A-nummer en het BSN blijven geldig, ook na emigratie en/of overlijden.

Een BSN wordt nooit hergebruikt, ook niet wanneer iemand overlijdt of emigreert. Dit geldt ook voor het A-nummer. Ook de oude sofinummers – de voorloper van het BSN – worden niet hergebruikt. Als een persoon nog over een oud sofinummer beschikt en wordt ingeschreven in de BRP, krijgt die persoon een nieuw (en dus ander) BSN.

Ook niet-ingezetenen maken deel uit van de BRP

Bij de invoering van de Wet BRP op 6 januari 2014 is tegelijkertijd de Registratie niet-ingezetenen (RNI) geïntroduceerd. In de RNI staan personen die een relatie hebben met de Nederlandse overheid, maar niet of niet meer in Nederland wonen.

Kort na de invoering van de RNI in 2014 zijn de gegevens van drie miljoen niet-ingezetenen in de RNI opgenomen. Anderhalf miljoen persoonslijsten van personen die vanaf 1-10-1994 geëmigreerd zijn en anderhalf miljoen persoonslijsten van personen die een relatie hebben met de Belastingdienst en/of de Sociale Verzekeringsbank en niet in Nederland wonen. Vanaf 2014 is de RNI verder gevuld met emigraties en inschrijvingen van niet-ingezetenen via de RNI-loketten. Ook kunnen niet -ingezetenen inschreven worden door een aantal daartoe aangewezen bestuursorganen (ABO’s).

Bij emigratie wordt de persoonslijst van de laatste woongemeente naar de RNI gestuurd. Er verdwijnen geen gegevens van de persoonslijst, maar niet alle gegevens worden vanaf dat moment nog actief bijgehouden. De gegevens over de gerelateerden –ouders, partners en kinderen– worden ‘bevroren’; de bijhouding daarvan wordt opgeschort.

Als een persoon zichzelf via een RNI-loket inschrijft, of ingeschreven wordt door een ABO worden de gegevens over de gerelateerden niet opgenomen. De rest van de persoonslijst is vrijwel gelijk aan de persoonslijst van een ingezetene, met als belangrijkste verschil dat het woonadres in het buitenland geregistreerd wordt voor niet-ingezetenen.

De RNI is een onderdeel van de BRP. Iemand die als niet-ingezetene in de RNI staat, staat dus altijd in de BRP. Andersom is dit niet zo. 

28 miljoen mensen (op dat hele kleine stukje aarde…)

Begin 2025 staan er ruim 28 miljoen personen in de BRP:

• 18 miljoen inwoners van Nederland;
• Ruim 5 miljoen niet-ingezetenen;
• Bijna 5 miljoen overledenen;

Binnenkort komt hier nog een vierde groep bij: de inwoners van Caribisch Nederland.

De ad-hoc-vraag

Als je persoonsgegevens op wilt vragen uit de BRP, kun je een ad-hoc-vraag sturen aan BRP-V. Een ad-hoc-vraag bestaat uit twee onderdelen:

1. De identificerende gegevens van de persoon die je zoekt;
2. Een opgave van de gegevens die je over deze persoon in het antwoord wilt ontvangen.

LET OP! Zowel de identificerende gegevens als de gevraagde gegevens, moeten vallen binnen je autorisatie anders krijg je een foutmelding. In het eerste geval is dat foutmelding X018, in het tweede geval is dat foutmelding X017. In de foutmelding staat welk gegeven buiten je autorisatie valt.

Voor de identificatie van de persoon die je zoekt, moet je minimaal één van de volgende gegevens gebruiken, zogenoemde identificerende gegevens:

• A-nummer (rubriek 01.01.10);
• BSN (rubriek 01.01.20);
• Geboortedatum (rubriek 01.03.10);
• Geslachtsnaam (rubriek 01.02.40);
• Postcode (rubriek 08.11.60);
• Postcode tijdelijk verblijfadres (rubriek 16.11.60);

Deze identificatie kan worden aangevuld met andere gegevens waarvoor je bent geautoriseerd. Met de optie “Zoeken in historie” zoekt BRP-V ook in de historische gegevens op de persoonslijst. Je hoeft niet expliciet geautoriseerd te zijn voor die historische gegevens bij het zoeken.

Hoe werkt het zoeken met de ad-hoc-vraag

Als je als identificatie een uniek nummer gebruikt (BSN of A-nummer) krijg je altijd precies één set persoonsgegevens als antwoord. Want het unieke nummer is maar aan 1 persoon gekoppeld. Het is niet gewenst om naast het BSN of het A-nummer nog een ander gegeven als identificatie mee te sturen. BRP-V zoekt namelijk met de combinatie van alle opgegeven gegevens. Het toevoegen van een extra zoekgegeven aan een uniek nummer, maakt de kans alleen maar kleiner dat je de persoon vindt.

Zowel het BSN als het A-nummer is een uniek nummer dat maar aan 1 persoon gekoppeld is. Mocht het voorkomen dat je bij een vraag op A-nummer of BSN toch meerdere personen in het antwoord terugkrijgt, meld dat dan onmiddellijk aan RvIG! Deze situatie moet zo snel mogelijk opgelost worden.

Als je (nog) geen BSN of A-nummer hebt van de gezochte persoon, kun je een combinatie van identificerende gegevens invoeren, bijvoorbeeld geslachtsnaam en geboortedatum.

Zo’n combinatie (waar minimaal één van de verplichte identificerende gegevens bij moet zitten) levert in sommige gevallen meerdere gevonden personen op in de BRP. Bijvoorbeeld als gezocht wordt met alleen een geboortedatum of met een geboortedatum en een veelvoorkomende geslachtsnaam als Jansen/Janssen of (de) Vries.

Als het totaal aantal gevonden personen niet groter is dan tien, dan krijg je van alle gevonden personen de gevraagde set persoonsgegevens terug. Je moet op basis van die gegevens zelf bepalen wie de gezochte persoon is en alleen die gegevens gebruiken voor het doel waarvoor je ze opgevraagd hebt.

Als er meer dan tien personen gevonden zijn, krijg je een melding dat er te veel personen gevonden zijn. Je moet er dan zelf voor zorgen dat het zoekresultaat kleiner wordt door het stellen van een specifiekere vraag. Dat kan op twee manieren:

1. door extra identificerende gegevens toe te voegen aan de oorspronkelijke vraag, of 
2. door andere identificerende gegevens te gebruiken.

Het toevoegen van een of meer extra identificerende gegevens maakt het zoekresultaat kleiner, omdat BRP-V zoekt met de combinatie van alle identificerende gegevens. Alleen de personen die alle identificerende gegevens op hun persoonslijst hebben staan, worden gevonden. Als je bij de geslachtsnaam Janssen plus geboortedatum 1 juli 1955 te veel resultaten krijgt, dan kun je bijvoorbeeld de postcode van het woonadres toevoegen. Er wordt dan binnen de groep van personen met geslachtsnaam Janssen en geboortedatum 1 juli 1955 gezocht naar alleen die personen die ook op de opgegeven postcode wonen.

Als je over andere gegevens van de gezochte persoon beschikt, kunnen die ook gebruikt worden om het zoekresultaat te verkleinen. Bijvoorbeeld door in plaats van de geslachtsnaam, de postcode en het huisnummer te gebruiken. De combinatie van een geboortedatum en een postcode en huisnummer verkleint het zoekresultaat.

Het opgeven van meerdere identificerende gegevens kan soms tot gevolg hebben dat er niemand gevonden wordt, terwijl je toch zeker weet dat de gezochte persoon in de BRP moet staan. De reden hiervoor is meestal dat een of meer van de opgegeven identificerende gegevens niet exact overeenkomt met de geregistreerde gegevens op de persoonslijst van de gezochte persoon. Als je weet welk gegeven dat is, kun je dat vervangen door een ander identificerend gegeven. Heb je geen ander identificerend gegeven, dan kan Slim zoeken [link naar paragraaf] uitkomst bieden.

De ad-hoc-adresvraag

Naast de reguliere ad-hoc-vraag is er ook de ad-hoc-adresvraag. Hierbij zoek je naar alle bewoners van een bepaald adres. Voor het gebruik van de ad-hoc-adresvraag is een aparte autorisatie vereist naast de autorisatie voor de ad-hoc-vraag. Je gebruikt de ad-hoc-adresvraag bijvoorbeeld als je van een persoon moet weten wie diens huisgenoten zijn. Je kunt de ad-hoc-adresvraag ook gebruiken om op te vragen welke niet-ingezetenen het adres in Nederland gebruiken als tijdelijk verblijfsadres. Je kunt de ad-hoc-adresvraag niet gebruiken voor het woonadres in het buitenland van niet-ingezetenen.

De ad-hoc-adresvraag heeft twee zoekingangen:

Optie 1

Je kunt een ad-hoc-adresvraag stellen door een persoon te zoeken. In het antwoord staan dan alle personen die ingeschreven zijn op hetzelfde adres waarop de gezochte persoon ingeschreven staat. Als de persoon ingeschreven staat als niet-ingezetene op dit adres, dan ontvang je in het antwoord alle andere personen die als niet-ingezetene staan ingeschreven op dit adres. Voor de identificatie van de persoon gelden dezelfde minimale eisen als bij de ad-hoc-vraag.

Als je bijvoorbeeld een ad-hoc-adresvraag stelt met als identificatie het BSN 123456789, dan krijg je de gevraagde persoonsgegevens van alle personen die op hetzelfde adres staan ingeschreven als de persoon met BSN 123456789.

Optie 2

Je kunt een ad-hoc-adresvraag stellen door een adres te zoeken. In het antwoord staan dan alle personen die ingeschreven staan op dat adres. Voor de identificatie van het adres moet je bij deze zoekingang minimaal een van de volgende gegevens gebruiken.

• Gemeentecode (rubriek 08.09.10);
• Straatnaam (rubriek 08.11.10);
• Naam openbare ruimte (rubriek 08.11.15);
• Postcode (rubriek 08.11.60);
• Identificatiecode verblijfplaats (rubriek 08.11.80);
• Identificatiecode nummeraanduiding (rubriek 08.11.90);
• Gemeentecode tijdelijk verblijfadres (rubriek 16.09.10);
• Straatnaam tijdelijk verblijfadres (rubriek 16.11.10);
• Naam openbare ruimte tijdelijk verblijfadres (rubriek 16.11.15);
• Postcode tijdelijk verblijfadres (rubriek 16.11.60);
• Identificatiecode verblijfplaats tijdelijk verblijfadres (rubriek 16.11.80);
• Identificatiecode nummeraanduiding tijdelijk verblijfadres (rubriek 16.11.90).

Deze identificatie kun je aanvullen met

• Functie adres (rubriek 08.10.10);
• Gemeentedeel (rubriek 08.10.20) en 
• De overige elementen uit groep 11 Adres. 

De rubrieken uit categorie 08 kun je niet combineren met rubrieken uit categorie 16. Als je categorie 08 gebruikt, ontvang je alle personen die als ingezetene staan ingeschreven op dit adres. Als je categorie 16 gebruikt, ontvang je alle personen die ingeschreven staan als niet-ingezetene op dit adres.

Als bij de identificatie binnen een ad-hoc-adresvraag alle gebruikte rubrieken binnen de definitie van de adresidentificatie vallen, dan interpreteert BRP-V dit als adresidentificatie. Dus zoeken op alleen postcode (08.11.60) geldt als adresidentificatie en niet als persoonsidentificatie.

In het zoekresultaat worden overledenen die ingeschreven staan op dit adres automatisch uitgefilterd. De overledenen staan dus niet in het zoekresultaat dat je terugkrijgt.

Slim zoeken

Als de ingevoerde zoekgegevens niet exact overeenkomen met de gegevens in BRP-V, dan is er nog de mogelijkheid van “slim zoeken”. Slim zoeken betekent dat er breder gezocht wordt dan de letterlijk ingevoerde gegevens. Dat verhoogt de kans dat de gezochte persoon of het gezochte adres in het zoekresultaat verschijnt. Er zijn drie manieren van slim zoeken:

Zoeken zonder onderscheid te maken tussen hoofletters en kleine letters

Je past dit heel gemakkelijk toe door zelf geen hoofdletters te gebruiken bij het invoeren van de zoekgegevens. Stel, je bent op zoek naar iemand met de –vermoedelijke– achternaam VanDenConckelaer, en je vindt niemand. Als je vermoedt dat de hoofdletters niet correct zijn, dan kun je ook vandenconckelaer proberen. Als je bij de invoer geen hoofdletters gebruikt, dan kijkt BRP-V bij het zoeken in de database niet naar het onderscheid in hoofdletters en kleine letters. Als de werkelijke naam vandenConckelaer is, dan wordt die gevonden met deze optie om het hoofdlettergebruik te negeren.

Zoeken zonder diakritische tekens

Diakritische tekens zijn accenttekens die boven, onder of door de letter staan ter aanduiding van de uitspraak, zoals de tilde of de cedille. Zie paragraaf 5.1.2.4 van het Logisch Ontwerp BRP voor een overzicht van alle combinaties van letters en diakritische tekens die in BRP-V kunnen voorkomen.

Zoeken zonder diakritische tekens pas je toe door zelf geen diakritische tekens te gebruiken bij het invoeren van de zoekgegevens. Stel dat je op zoek bent naar iemand met de naam António Eugénio Nuñes da Silva. Als je twijfelt of je alle diakritische tekens goed hebt ingevoerd, dan kun je ook zoeken met ‘Antonio Eugenio Nunes da Silva’. Als je alle diakritische tekens weglaat, negeert BRP-V de diakritische tekens volledig en kijkt alleen naar de gewone letters in de naam.

Let op: soms krijg je juist te veel resultaten door –onbedoeld– slim te zoeken. Stel dat je op zoek bent naar een persoon met achternaam Muller, dan kan het zijn dat BRP-V te veel resultaten vindt, om er ook gezocht wordt naar Müller. In zo’n geval kun je het slim zoeken van BRP-V uitschakelen door een slash “/” voor de naam te zetten. Je voert /Muller als zoekwaarde in; dat is voor BRP-V het signaal dat er letterlijk naar “Muller” gezocht moet worden. Namen zoals Müller of Mułłer worden dan overgeslagen.

Zoeken op een gedeelte van een zoekwaarde (‘wildcard’)

Als je slechts een deel van een zoekwaarde zeker weet, bijvoorbeeld alleen het geboortejaar of een deel van de postcode, dan kun je een zogenaamde ‘wildcard’ gebruiken. In de BRP gebruiken we het sterretje “*” als wildcard.

Voor alle zoekgegevens geldt dat het sterretje aan het einde van de zoekwaarde mag staan. In het zoekproces wordt dan alleen op de tekens vóór het sterretje gezocht. Het sterretje staat voor 0 of meer tekens. Bijvoorbeeld: als je zoekt met voorvoegsel Von* dan worden de voorvoegsels Von, Von ‘t, Von dem, Von den, Von der en Von t gevonden. Als je zoekt met voorvoegsel von* dan worden daarnaast ook nog alle varianten gevonden die met een kleine letter v beginnen vanwege de 1e manier van slim zoeken.

Voor datums geldt dat met de wildcard gezocht kan worden als alleen het jaar bekend is of als alleen het jaar en de maand bekend is. Als alleen het jaar bekend is, voer je de vier cijfers van het jaar in, met daarachter het sterretje; bijvoorbeeld: 1955*. Als het jaar en de maand bekend zijn voer je de vier cijfers van het jaar en de twee cijfers van de maand in, met daarachter het sterretje; bijvoorbeeld: 194405*.

Extra wildcards voor de actuele voornamen en de actuele geslachtsnaam

Speciaal voor het zoeken met de actuele voornamen en actuele geslachtsnaam zijn er ruimere mogelijkheden voor het gebruik van de wildcard. Het sterretje mag op elke positie in de zoekwaarde staan, dus niet alleen op het einde. En er mogen meerdere wildcards in één zoekwaarde staan. Deze uitgebreidere zoekmogelijkheden zijn vooral bedoeld voor het zoeken op voorletters of een deel van de voornamen of samengestelde achternamen.

Hieronder vind je een uitgebreid voorbeeld om dit toe te lichten:

Stel, je hebt in je eigen database: JH Janssen geboren op 27-03-1943 in Amsterdam.
De geboortedatum is niet helemaal zeker.
Je wilt de volledige NAW-gegevens opvragen om een brief te sturen.

• Je zoekt met achternaam Janssen en geboortedatum 02-03-1943. 
  Je krijgt als antwoord: niemand gevonden. Dan weet je zeker dat de geboortedatum niet klopt, want de achternaam Jansen komt zeker voor in de BRP.
   
• Je kunt de geboortedatum dus niet gebruiken en zoekt daarom met achternaam Janssen en geboorteplaats Amsterdam.
  Je krijgt als antwoord: te veel resultaten gevonden. In het antwoord mogen maximaal 10 zoekresultaten getoond worden, en er wonen meer dan 10 personen met de achternaam Jansen in Amsterdam.
   
• Daarom besluit je de zoekgegevens aan te vullen met de voorletters JH.
  Je krijgt als antwoord: niemand gevonden. In de BRP staan geen voorletters maar voornamen. Daarom wordt er niemand gevonden, want BRP-V zoekt letterlijk naar de ingevoerde zoekgegevens.
   
• Je besluit de wildcard te gebruiken: je zoekt met voornamen J*, achternaam Janssen en geboorteplaats Amsterdam.
  Je krijgt als antwoord: te veel resultaten gevonden. Blijkbaar wonen er meer dan 10 personen in Amsterdam met de achternaam Jansen en een voornaam/voornamen die beginnen met een J.
   
• Je besluit de nieuwe optie voor slimmer zoeken te gebruiken: het gebruik van meerdere wildcards in een zoekveld. Je zoekt met voornamen J* H*, achternaam Janssen en geboorteplaats Amsterdam. “J*” staat voor: de eerste letter van de (eerste) voornaam is een J. “H*“ staat voor: daarna moet nog een hoofdletter H komen. Je hebt opzettelijk een spatie gezet tussen J* en * zodat er gezocht wordt naar afzonderlijke voornamen. 
  Je krijgt als antwoord vier personen, met als voornamen: Jurjen Hans, Jan Hein, Johannes Hendrikus Gerardus, Josha Allard Harald. De twee laatste personen kunnen niet de gezochte persoon zijn, want zij hebben drie voornamen. Zij zijn gevonden omdat de wildcard alle tekens accepteert tot aan de volgende opgegeven letter of het einde van de tekenreeks.

Dan blijven er twee personen over, waarbij je op basis van de opgevraagde gegevens moet bepalen wie de gezochte persoon is. Bijvoorbeeld de geboortedatum: als de eerste persoon 03-02-1943 heeft en de tweede persoon 15-11-2023, dan is het vrijwel zeker de eerste persoon (dag en maand omgedraaid).

Een ander voorbeeld, maar dan met een dubbele geslachtsnaam.

Stel, je zoekt een persoon met de achternaam van Thoor Gilsing, maar je krijgt telkens “niet gevonden” als antwoord. Je hebt al geprobeerd te zoeken met T*, maar dat leverde te veel resultaten op. Als de schrijfwijze van het eerste deel “Thoor” onzeker is, kun je voortaan ook zoeken op alleen het laatste deel met: “*Gilsing”. Je vindt dan alleen achternamen die eindigen op Gilsing. Tip: als je een spatie invoegt tussen de * en Gilsing, dan geef je aan dat je de enkele geslachtsnaam Gilsing niet zoekt. Nog een tip: als je niet zeker weet of het eerste deel van de achternaam afgesplitst moet worden als voorvoegsel, kun je ook een * voor de achternaam zetten. Bijvoorbeeld: je moet de achternaam Del las Vidales opzoeken; dan kun je ook *Vidales invoeren, zonder spatie tussen * en Vidales. Als Del las een voorvoegsel uit de Voorvoegseltabel is, dan wordt de achternaam Vidales toch gevonden, want de * staat voor: 0, 1 of meerdere tekens. In dit geval dus 0 tekens.

Nog een voorbeeld uit de praktijk. Je bent op zoek naar een persoon met de achternaam Thomassen à Thuessink van der Hoop van Slochteren. Bij zo’n samengestelde naam kun je gemakkelijk fouten maken, want alleen al het naamdeel Thomassen heeft als varianten: Thomashen, Thomason, Thomasse, Thomassen, Thomasson, Thomasze, Tomase, Tomasse, Tomassen. Als je zeker weet dat het eerste deel klinkt als Tomasse, en dat het laatste deel Slochteren is, dan kun je zoeken met: T*oma* Slochteren.

In het antwoord staan aanvullende gegevens

Opschortingsgegevens

In de BRP staan niet alleen inwoners van Nederland (ingezetenen) maar ook niet-ingezetenen en overleden personen; zie Wie staat er wel en niet in de BRP [link naar paragraaf]. Als je een vraag stelt aan BRP-V worden deze personen automatisch meegenomen in de zoekactie. Daarom sturen we in het zoekresultaat aanvullende gegevens mee waaraan je kunt zien of een gevonden persoon een niet-ingezetene is of een overledene; dit zijn de zogenaamde opschortingsgegevens. In het antwoord kan een van deze vier opschortingsredenen staan:

• O: de persoon is overleden;
• E: de persoon is geëmigreerd;
• R: de persoon is een niet-ingezetene die nooit in Nederland gewoond heeft;
• M: de persoon is een niet-ingezetene die vanwege een ministerieel besluit is uitgeschreven.

Naast de opschortingsreden wordt ook de datum van opschorting meegestuurd.

Wanneer er bij een persoon geen opschortingsgegevens zijn meegestuurd, betekent dit dat de persoon een ingezetene is.

Als je op een zoekvraag meerdere personen in het antwoord krijgt, is een check op de opschortingsgegevens direct een goede eerste controle van het zoekresultaat. Wanneer je zeker weet dat de gezochte persoon in Nederland woont en nog in leven is, vallen de resultaten van niet-ingezetenen en overleden personen dus af.

Onderzoeksgegevens

In het antwoord kunnen ook aanvullende gegevens meegestuurd worden als een gegeven in onderzoek staat. Dit gebeurt in gevallen wanneer er twijfel is over de juistheid van de gegevens en de gemeente daarom een onderzoek uitvoert. Afhankelijk van het proces waarvoor je de gegevens opgevraagd hebt, kan het nodig zijn om contact op te nemen met de desbetreffende gemeente om naar het onderzoek te vragen. Bijvoorbeeld wanneer blijkt dat een adres in onderzoek staat en het doel was om een brief naar deze persoon te sturen.

De aanvullende gegevens worden altijd meegestuurd als ze aanwezig zijn, dit is niet afhankelijk van de inhoud van de autorisatie van je organisatie. Je kunt er bij het stellen van een ad-hoc-vraag ook niet expliciet om vragen.

Gegevens over niet-ingezetenen

Als in het antwoord een niet-ingezetene voorkomt (de opschortingsreden is dan E, R of M) kun je aanvullende gegevens aantreffen over de organisatie (“RNI-deelnemer”) die de gegevens heeft aangeleverd en de datum waarop de gegevens zijn opgenomen. Ook kun je aanvullende gegevens aantreffen over de verificatie die de RNI-deelnemer heeft uitgevoerd op de betreffende gegevens. Deze aanvullende gegevens geven je extra informatie over de actualiteit en betrouwbaarheid van de gevraagde gegevens.

Let op: Het is voor RvIG niet inzichtelijk hoe de meegestuurde gegevens getoond worden op het scherm van de afnemer. Dit is afhankelijk van hoe de leverancier van jouw applicatie dit heeft ingebouwd. Idealiter staan de aanvullende gegevens duidelijk op het scherm weergegeven want het is belangrijke informatie bij het beoordelen van de zoekresultaten. RvIG is verantwoordelijk voor de gegevensverstrekking, de ontvangende applicatie is verantwoordelijk om de gegevens begrijpelijk in beeld te brengen.

Aandachtspunten bij het zoeken

Standaard combinaties voor zoekgegevens

Vaak gebruikte combinaties van zoekgegevens zijn:

• Geslachtsnaam en geboortedatum;
• Geslachtsnaam en postcode;
• Postcode en huisnummer;
• Geslachtsnaam en geboortedatum en gemeente van inschrijving.

Deze combinaties kun je aanvullen met extra gegevens als er te veel zoekresultaten gevonden worden. 
Aandachtspunt: Als je verwacht dat je meer dan 1 persoon gaat vinden, is het aan te bevelen om slechts een beperkte set gegevens in het antwoord op te vragen. Dit voorkomt dat je ongewild een grote set persoonsgegevens te zien krijgt van personen die je niet zocht. De inhoud van de gevraagde set persoonsgegevens moet genoeg zijn om te kunnen bepalen wie de gezochte persoon is. Bijvoorbeeld: voornamen, voorvoegsel, geslachtsnaam, geboortedatum, geboorteplaats. Als je de gezochte persoon gevonden hebt in het zoekresultaat, kun je met het BSN van de bedoelde persoon de hele set gegevens opvragen die je voor je proces nodig hebt.

Zoeken in historische gegevens

Wanneer je een persoon niet kunt vinden en je vermoedt dat dit komt omdat je verouderde gegevens gebruikt, kun je ook zoeken in de historische gegevens in de BRP. In je zoekvraag zet je dan de indicator IndicatieZoekenInHistorie aan (als je die niet op je scherm ziet, vraag dan aan je applicatiebeheerder hoe dat moet). Je hoeft hiervoor niets aan te passen aan de identificerende gegevens, en je hoeft ook niet geautoriseerd te zijn voor deze historische gegevens om ermee te kunnen zoeken. Als je ook historische gegevens in het antwoord wilt ontvangen, moet je daar wel voor geautoriseerd zijn.

Let op: Zoeken in de historische gegevens werkt alleen voor de ad-hoc-vraag, niet voor de ad-hoc-adresvraag.

Voorbeeld: je zoekt een persoon met geslachtsnaam Janssen en geboortedatum 12-08-1995. Je vindt niemand, maar weet zeker zij zich15 jaar geleden ingeschreven heeft. Je stuurt de vraag nogmaals met de indicator IndicatieZoekenInHistorie aan. Dit keer ontvang je mevrouw Müller met geboortedatum 12-08-1995. In de gegevens zie je dat mevrouw Janssen in Duitsland getrouwd is met mijnheer Müller en de huwelijksnaam van haar man aangenomen heeft als haar geslachtsnaam.

Zelfs met één zoekresultaat kan het de verkeerde persoon zijn

Wanneer je een persoon zoekt en je krijgt precies één resultaat, dan is het niet altijd zeker dat dit ook de persoon is die je zocht. Dat kan gebeuren als je bijvoorbeeld per ongeluk een verkeerde geboortedatum hebt ingevoerd. Het is belangrijk om de ontvangen gegevens altijd goed te controleren om zeker te weten dat het zoekresultaat daadwerkelijk de gezochte persoon is. Kijk bijvoorbeeld of de voornamen overeenkomen met die van de gezochte persoon.

Wanneer je het A-nummer of BSN gebruikt als identificerend gegeven, krijg je altijd de juiste persoon. Gebruik daarom bij voorkeur een van deze twee nummers bij het opvragen van persoonsgegevens uit de BRP. 

Foutmeldingen

Hieronder staan de meest voorkomende foutmeldingen met een korte uitleg en, indien mogelijk, tips hoe verder te werk te gaan.

Let op: Het kan zijn dat de foutmelding in de applicatie die je gebruikt anders is genummerd en/of verwoord. RvIG levert deze foutmeldingen aan de leveranciers maar is niet bekend met hoe de leverancier deze in jouw applicatie opneemt.

Foutcode en -omschrijving	Toelichting
G033 Geen gegevens gevonden	Dit betekent dat er geen personen zijn gevonden die voldoen aan de identificatie. Vervang een of meer identificerende gegevens uit de zoekvraag door andere gegevens.
P032 Te veel zoekresultaten	De zoekvraag levert meer dan 10 resultaten op. Vul de zoekopdracht aan met een of meer identificerende gegevens zoals een postcode of geboortedatum.
P036 Resultaat te groot, te veel personen op 1 adres	Er staan meer dan 30 personen ingeschreven op het gevraagde adres of de gevraagde adressen. Meestal krijg je deze melding omdat je geen unieke identificatie gebruikt hebt voor de persoon of het adres.  Gebruik als identificatie het A-nummer, het BSN of de identificatiecode van de verblijfplaats, de nummeraanduiding of het tijdelijk verblijfsadres (zie de BAG Viewer).
R034 Geen van de gevonden persoonslijsten voldoet aan de voorwaardenregel	Er zijn een of meerdere personen gevonden, maar geen daarvan voldoet aan de voorwaarden die gesteld zijn in de autorisatie.
T031 Zoekproces afgebroken	De zoekactie in BRP-V is afgebroken. Probeer een andere combinatie van identificerende gegevens. Als dat niet mogelijk is, neem dan contact op met info@rvig.nl.
X001 Technische fout	De zoekactie in BRP-V is afgebroken. Probeer het later nog een keer of neem contact op met info@rvig.nl.
X010 Ongeldige combinatie gebruikersnaam/wachtwoord	De combinatie van de gebruikersnaam en het wachtwoord waarmee geprobeerd is in te loggen, is ongeldig. Neem contact op met je applicatiebeheerder.
X011 Service is niet geactiveerd voor dit account	Controleer in je autorisatiebesluit of je geautoriseerd bent voor het stellen van ad-hoc-vragen (“verstrekking van gegevens op verzoek”). Als dat zo is, neem dan contact op met info@rvig.nl.
X012 Wachtwoord verlopen	Het gebruikte wachtwoord is verlopen. Wijzig het wachtwoord en probeer het opnieuw.
X013 Geen actuele autorisatietabelregel	Vraag bij de applicatiebeheerder of je de juiste BRP-autorisatie gebruikt. Als dat zo is, neem dan contact op met info@rvig.nl.
X014 Niet geautoriseerd voor ad-hoc-vragen	Je bent niet geautoriseerd voor het stellen van ad-hoc-vragen. Controleer je autorisatie en dien zo nodig een verzoek in voor aanpassing ervan.
X015 Niet adresvraagbevoegd	Je bent niet geautoriseerd voor het stellen van ad-hoc-adresvragen. Vul de zoekopdracht aan met een of meer persoons-identificerende gegevens, zoals een geboortedatum, of achternaam.
X017 Geen autorisatie voor rubriek: <rubrieknummer>	Je vraagt om een of meer gegevens die buiten je autorisatie liggen. Verwijder deze gegevens uit de ad-hoc-vraag en probeer het opnieuw. Als de gevraagde gegevens noodzakelijk zijn voor jouw organisatie, neem dan contact op met info@rvig.nl.
X018 Niet toegestaan zoekcriterium gebruikt: <rubrieknummer>	Je gebruikt als identificatie een of meer gegevens die buiten je autorisatie liggen. Verwijder deze gegevens uit de ad-hoc-vraag en probeer het opnieuw. Als de gebruikte identificatie noodzakelijk is voor jouw organisatie, neem dan contact op met info@rvig.nl.
X019 Geen correcte persoonsidentificatie	Voor een correcte persoonsidentificatie moet minimaal een van de volgende rubrieken ingevuld zijn: A-nummer, BSN, geboortedatum, geslachtsnaam of postcode.
X020 Geen correcte persoons- of adresidentificatie	Voor een correcte adresidentificatie moet minimaal een van de volgende rubrieken ingevuld zijn: gemeentecode, straatnaam, naam openbare ruimte, postcode, identificatiecode verblijfplaats of identificatiecode nummeraanduiding.
X021 Ongeldige waarde voor parameter <xml-tag-naam>	Je hebt een ongeldige waarde ingevoerd voor de genoemde rubriek. Controleer in het Logisch Ontwerp BRP wat de voorwaarden zijn voor deze rubriek.
X022 Numeriek zoekcriterium <rubrieknummer> bevat geen numerieke waarde	Je mag alleen cijfers invullen bij de genoemde rubriek.
X023 Zoekcriterium <rubrieknummer> bevat ongeldig teken op positie <x>	Je hebt een ongeldig teken ingevoerd voor de genoemde rubriek op de genoemde positie. Vanwege de dubbelde codering van diakritische tekens is het mogelijk dat de genoemde positie verschilt van de invoer.
X024 Dubbel rubrieknummer in zoekcriteria niet toegestaan: <rubrieknummer>	Bij de identificerende gegevens is twee keer dezelfde waarde opgegeven. Verwijder een van de twee en stel de vraag opnieuw.
X025 Dubbel rubrieknummer in masker niet toegestaan: <rubrieknummer>	Bij de gevraagde gegevens is twee keer dezelfde waarde opgegeven. Verwijder een van de twee en stel de vraag opnieuw.
X026 Onjuiste lengte voor rubriek: <rubrieknummer>=<waarde>	De genoemde rubriek heeft een lengte die niet is toegestaan. Controleer in het Logisch Ontwerp BRP wat de correct lengte (minimaal of maximaal) is voor deze rubriek.
Z037 Geen persoonslijsten die aan de verstrekkingscondities voldoen	Er zijn wel persoonslijsten gevonden die aan de identificatie voldoen, maar na filtering op de voorwaarden in de autorisatie zijn er geen persoonslijsten overgebleven.

1 Probleemstelling

1.1 Omschrijving

Gegevens over wie het gezag uitoefent over een minderjarige worden, als dit gezag niet van rechtswege berust bij één of beide ouders, in de BRP vastgelegd in categorie 11 Gezagsverhouding. Deze gegevens worden ontleend aan Centraal Gezagsregister (CGR) van de Raad voor de rechtspraak (RvdR). Zodra de rechter een beslissing neemt over het gezag over een minderjarige, dan wordt die beslissing toegezonden aan de gemeente van inschrijving (of de RNI) van de minderjarige, zodat de medewerkers van de gemeente dit op de persoonslijst (PL) van de minderjarige kunnen registreren.

Tot op heden werden zulke beschikkingen van de rechtbank per briefpost naar gemeenten of de RNI gestuurd en handmatig door burgerzakenmedewerkers “vertaald” naar de registratie van het gezag in categorie 11 Gezagsverhouding zoals die in het Logisch Ontwerp BRP is beschreven. Als een PL al voor de beslissingsdatum is opgeschort wegens emigratie of ministerieel besluit, dan wordt een documentindicatie opgenomen. De uitwisseling van uitspraken van de rechtbank via briefpost is tijdrovend en foutgevoelig en daarom wordt dit nu mogelijk gemaakt via een elektronisch bericht van de RvdR naar de gemeente of de RNI. In het begin zal de vertaling naar de registratie van gezag op persoonslijsten nog handmatig plaatsvinden, maar op termijn moet het mogelijk worden om die te automatiseren.

Om te voorkomen dat de RvdR “achter het net vist” als een minderjarige toevallig net is verhuisd en om de RvdR niet te confronteren met mogelijke dubbelinschrijvingen, of verschillen in de registratie in de BRP-V en bij de gemeente of de RNI, wordt er een zogenaamde “routeringsvoorziening” in het leven geroepen die bij een bericht over een minderjarige achterhaalt waar het bericht naar toegestuurd moet worden (de gemeente van inschrijving of de RNI.

1.2 Herkomst

Deze wijziging komt voort uit initiatief GEZ-02-01 Uitwisselen gezagsinformatie CGR – gemeenten, van programma Toekomst BRP.

1.3 Raakvlakken

Er zijn vooralsnog geen raakvlakken met andere LO-wijzigingen.

2 Oplossing

2.1 Huidige situatie

Op dit moment worden gegevens omtrent het gezag over een minderjarige per briefpost naar gemeenten of de RNI gestuurd. De medewerkers van de gemeente of van de afdeling G&R van RvIG verwerken de gegevens dan in categorie 11 op de persoonslijst van de minderjarige. Als een PL al voor de beslissingsdatum is opgeschort wegens emigratie of ministerieel besluit, dan wordt een documentindicatie opgenomen. Dit is tijdrovend en foutgevoelig.

2.2 Oplossing

Er wordt een nieuwe berichtencyclus geïntroduceerd: de Og21-berichtencyclus. In het Og21-bericht wordt de minderjarige geïdentificeerd aan de hand van diens burgerservicenummer, en worden de gegevens omtrent het gezag over die minderjarige opgenomen. Als een PL al voor de beslissingsdatum is opgeschort wegens emigratie of ministerieel besluit, dan wordt een documentindicatie opgenomen.

Daarnaast zorgt een nieuwe voorziening bij RvIG voor de adressering van het nieuwe bericht aan de juiste gemeente of de RNI. Dit zorgt ervoor dat RvIG de meeste foutscenario’s kan ondervangen en oplossen, bijvoorbeeld door het Og21-bericht door te sturen naar een gemeente waarnaar de minderjarige nét verhuisd is. Hierdoor krijgt de Raad voor de rechtspraak nog maar met een beperkt aantal foutscenario’s te maken.

De routeringsvoorziening is een generieke voorziening, waarmee in de toekomst ook andere berichten kunnen worden “afgegeven” bij RvIG, zodat RvIG zorg kan dragen voor de bezorging bij de juiste gemeente of bij de RNI. Denk aan het Og11-bericht waarin de Immigratie- en Naturalisatiedienst verblijfstitels stuurt naar gemeenten en RNI.

2.3 Openstaande punten

Deze wijziging zorgt voor het elektronisch uitwisselen van gegevens omtrent het gezag over een minderjarige. Die gegevens moeten nog wel handmatig op de PL worden verwerkt; in een latere wijziging kan worden besloten om die verwerking geautomatiseerd te laten verlopen.

Daarnaast zijn die gegevens nu nog beperkt tot die gegevens die nodig zijn om de huidige registratie van gezag in de BRP te ondersteunen. In de toekomst is het denkbaar dat niet alleen van ouders, maar ook van derden of van gecertificeerde instellingen identificerende gegevens worden meegestuurd en vastgelegd op de persoonslijst, zodat afnemers van de BRP niet meer bij het CGR hoeven op te vragen wie gezag heeft over een minderjarige als dat gezag deels berust bij een derde.

3 Invoering

Voor de realisatie van deze wijziging is inzet nodig van

1. De Raad voor de Rechtspraak voor het implementeren van een berichtenafhandelingssysteem, functionaliteit voor het aanmaken van het Og21-bericht en de verwerking van de Of21-foutberichten, en van de koppeling met de BRP Berichten API;
2. RvIG voor de ondersteuning van de nieuwe berichtencyclus in de BRP Berichten API en de implementatie van de routeringsvoorziening;
3. De burgerzakenleveranciers Centric, PinkRoccade en Shift2 voor de verwerking van het Og21-bericht en het aanmaken van de Of21-berichten.

Die laatste partijen zijn ook druk met de implementatie van de ondersteuning voor de BRP Berichten API en hebben aangegeven dat ze pas nadat ze over zijn gestapt op de BRP Berichten API kunnen gaan werken aan de ondersteuning van de nieuwe berichtencyclus. Naar verwachting kan die dan ook niet eerder dan 1 juli 2026 in gebruik worden genomen.

4 Gevolgen

4.1 Documentatie

Deze wijziging in 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

Gemeenten moeten de nieuwe berichtencyclus ondersteunen in hun burgerzakensystemen. Dit houdt in dat zij de leveranciers daarvan opdracht moeten geven om die ondersteuning te leveren.

4.3 Afnemers

Geen gevolgen.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

Geen gevolgen.

4.6 RvIG-systemen

De RvIG moet zorgen dat de nieuwe berichtencyclus wordt ondersteund door de BRP Berichten API, en dat er een routeringsvoorziening komt die zorg draagt voor het adresseren van Og21-berichten aan de juiste gemeente van inschrijving, dan wel aan de RNI, afhankelijk van waar een minderjarige volgens de BRP-V actueel is ingeschreven. Ook moeten de Of21-berichten op de juiste manier worden afgehandeld.

1 Probleemstelling

1.1 Omschrijving

Een burger heeft recht op inzage van de gegevens die over hem op zijn persoonslijst zijn vastgelegd in de BRP. Burgers krijgen inzage in deze gegevens via Mijn Overheid (en de Mijn Gegevens app, maar die zal hier niet telkens apart genoemd worden), of door een uitdraai op te vragen van hun persoonslijst bij de gemeente van inschrijving. Tot die gegevens behoren ook enkele gegevens (BSN, naam, geboortegegevens en geslacht) van gerelateerden, te weten beide ouders (indien bekend) en eventuele partner(s) en kind(eren).

Als iemand van naam of van geslacht verandert, moet dat ook worden gewijzigd op de persoonslijsten van die gerelateerden, die vervolgens weer recht hebben op inzage in die gewijzigde gegevens. Met enige regelmaat komen er klachten binnen van burgers die hun eigen persoonsgegevens proberen af te schermen voor familieleden. De reden voor het afschermen is bijvoorbeeld stalking en/of eerwraak. De impact op de getroffen burger is enorm, vaak levensbedreigend. Iedere dag dat hier niets aan gebeurt, zorgt mogelijk voor een slachtoffer.

De staatssecretaris heeft toestemming gegeven voor het tijdelijk afschermen van de volgende gegevens op Mijn Overheid:

• De gegevens van ex-partners die nog in leven zijn;
• Het BSN van kinderen van 18 jaar of ouder;
• De BSN’s van ouder(s) van personen van 18 jaar of ouder.

In de oplossing hoeft geen rekening gehouden te worden met meerderjarigheidsverklaringen, niet-wilsbekwame burgers, levenloos geboren/overleden kinderen of andere uitzonderingen.

Logius wil dat Mijn Overheid geen bedrijfslogica hoeft toe te passen op de gegevens die zij opvragen uit de BRP.

1.2 Herkomst

Deze wijziging komt voort uit initiatief IWD-03-03 Afschermen gegevens gerelateerden van programma Toekomst BRP.

1.3 Raakvlakken

Er zijn vooralsnog geen raakvlakken met andere LO-wijzigingen.

2 Oplossing

2.1 Huidige situatie

Om de gegevens te kunnen tonen, bevraagt Mijn Overheid de Ad hoc webservice van de BRP-Verstrekkingsvoorziening (BRP-V). Die gegevens worden rechtstreeks getoond op Mijn Overheid, zonder dat daar bedrijfslogica op wordt losgelaten. Dat laatste moet ook zo blijven.

2.2 Oplossing

De Ad hoc webservice wordt zodanig aangepast, dat alleen als Mijn Overheid haar bevraagt, de af te schermen gegevens als volgt worden getoond: de BSN’s van volwassen kinderen en van ouders van volwassen personen worden vervangen door negen asterisken (*********). Gegevens van ex-partners die nog inleven zijn worden geheel weggelaten uit het responsebericht.

2.3 Openstaande punten

Deze wijziging is een eerste stap in het geven van regie aan de burger over de gegevens die hij wil delen met gerelateerden. Het is de bedoeling dat de burger uiteindelijk zelf kan aangeven welke gegevens over hem op de persoonslijst van gerelateerden moeten worden afgeschermd.

3 Invoering

Omdat de impact van deze wijziging voor Logius zeer beperkt is hangt de invoering van deze wijziging vooral af van de aanpassingen in de Ad hoc webservice. Die zijn naar verwachting per 1 juli geïmplementeerd.

4 Gevolgen

4.1 Documentatie

Deze wijziging in 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

Geen gevolgen

4.3 Afnemers

Geen gevolgen. Alleen voor Mijn Overheid is het gevolg dat gegevens van ex-partners die nog in leven zijn, niet meer worden verstrekt, en dat in de plaats van de BSN’s van volwassen kinderen en van ouders van volwassenen een reeks asterisken wordt verstrekt.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

Geen gevolgen.

4.6 RvIG-systemen

De Ad hoc webservice moet conform bovenstaande worden aangepast.