1 Probleemstelling

1.1 Omschrijving

In het /personen endpoint van de BRP API zijn twee elementen opgenomen die zijn aangemerkt als "deprecated". Dit is een gebruikelijke wijze om in koppelvlakspecificaties aan gebruikers kenbaar te maken dat zij moeten zorgen dat hun systemen niet langer afhankelijk zijn van deze elementen, omdat die op enig moment niet langer verstrekt zullen worden. Op het moment dat de twee elementen uit de BRP Personen API verwijderd zullen worden, moeten ze ook verwijderd worden uit de beschrijving van de BPR API in het Logisch Ontwerp BRP.

1.2 Herkomst

Deze wijziging komt voort uit het inzicht dat met de introductie van sommige informatievragen in de BRP API deze twee elementen niet langer nodig zijn.

1.3 Raakvlakken

Er zijn geen raakvlakken met andere LO-wijzigingen, of met andere wet- en regelgeving.

2  Oplossing

2.1 Huidige situatie

In het endpoint /personen van de BRP API, in de functie RaadpleegMetBurgerservicenummer, kan op dit moment om de elementen indicatieGezagMinderjarige en verblijfplaats.datumIngangGeldigheid worden gevraagd en worden de bijbehorende booleans die aangeven dat deze gegevens in onderzoek zijn (inOnderzoek.indicatieGezagMinderjarige en verblijfplaats.inOnderzoek.datumIngangGeldigheid), meeverstrekt. Maar met de introductie van het object gezag (met daarin alle gezagsrelaties van de bevraagde persoon) en verblijfplaats.datumVan zijn deze twee elementen overbodig geworden.

2.2 Oplossing

De genoemde elementen worden verwijderd uit de response berichten van het endpoint, en kunnen niet meer worden opgevraagd met de fields parameter.

2.3 Gerelateerde wijzigingen in wet- en regelgeving

Er zijn geen relaties met wijzigingen in wet- en regelgeving.

2.4 Openstaande punten

Er zijn na implementatie van deze wijziging geen openstaande punten.

3 Invoering

Deze wijziging is gepland om op te worden genomen in LO 2025.Q1 (1 januari 2025).

4 Gevolgen

4.1 Documentatie

Alleen LO BRP moet worden aangepast conform de beschreven oplossing in par. 2.2.

4.2 Gemeenten

Er is geen impact op de burgerzakensystemen van gemeenten.

4.3 Afnemers

Afnemers die gebruik maken van het /personen endpoint van de BRP API kunnen niet langer vragen om indicatieGezagMinderjarige en om verblijfplaats.datumIngangGeldigheid. Voor de datum inwerkingtreding van deze LO-wijziging moeten zij zorgen dat ze die twee elementen niet meer opvragen vanuit hun taakapplicaties.

4.4 IND

Er is geen impact op de systemen van IND.

4.5 Caribische landen en Caribisch Nederland

Er is geen impact op de systemen in het Caribisch deel van het Koninkrijk

4.6 RvIG-systemen

In de BRP API specificaties op Github waren de twee elementen reeds aangemerkt als deprecated. Per de datum inwerkingtreding van deze LO-wijziging zullen ze ook daadwerkelijk niet meer verstrekt kunnen worden door het /personen endoint van de BRP API. Hiervoor moet een nieuwe versie van de BRP API in gebruik worden genomen.

1 Probleemstelling

1.1 Omschrijving

In de landelijke tabellen zoals RvIG die publiceert op de website, komen kolommen voor die niet in het LO BRP beschreven zijn. Daarnaast heeft een aantal afnemers gevraagd om uitbreiding van de landentabel met internationaal erkende codes op basis van de ISO-3166 (Codes for the representation of names of countries and their subdivisions) standaard. Alle ABO's, maar ook pensioenfondsen, wisselen namelijk internationaal gegevens uit en daarbij is het nuttig om ondubbelzinnig te kunnen verwijzen naar landen via internationaal erkende codes.

1.2 Herkomst

Deze wijziging komt voort uit eigen constateringen van het LO-team en wensen die afnemers te kennen hebben gegeven.

1.3 Raakvlakken

Deze wijziging heeft geen raakvlakken met andere wijzigingen.

2 Oplossing

2.1 Huidige situatie

A.    In Tabel 34 Landentabel stond in de PDF bij “Gazastrook en Westelijke Jordaanoever” een voetnoot, die we in de CSV niet kwijt kunnen. In de CSV-versie is het niet mogelijk om voetnoten toe te voegen. Een voetnoot in een tabel is überhaupt geen wenselijke oplossing.
B.    In Tabel 34 Landentabel staat een asterisk (*) achter een aantal einddatums. Deze geeft aan dat deze einddatum een fictieve datum is. De werkelijke einddatum is eerder. Indertijd bij de invoering van de GBA is hiervoor gekozen (aanvankelijk geen einddatum in de tabel, daarna een einddatum met indicatie ‘fictief’) om gemeenten die al omvangrijke conversies van PK naar PL hadden uitgevoerd, te behoeden voor grootschalige aanpassingen in de gegevens op de persoonslijsten.
C.    In tabel 34 Landentabel staat in de PDF een kolom "Iso alpha-2". Deze ontbreekt in de CSV van tabel 34 Landentabel en in LO BES en LO BRP. Nu is het al een lang gekoesterde wens van sommige afnemers, waaronder ABO's en pensioenfondsen, dat we codes uit ISO-3166 toevoegen aan de tabel: in het LO BRP, in beide CSV-versies van de tabel, en in beide PDFs van de tabel. (De ISO-norm 3166 geeft codes voor alle landen, grondgebieden of belangrijke geografische gebieden (bijvoorbeeld Antarctica), kortweg "landen" genoemd.)

2.2 Oplossing

De oplossing omvat drie wijzigingen in tabel 34:

A.    In plaats van een voetnoot met de volledige officiële landnaam, zou het beter zijn om te zorgen dat die in 34.94.11 Landnaam past. Daarom wordt de definitie van de rubriek 34.94.11 Landnaam aangepast naar de maximale lengte van 80 karakters en wordt de Landnaam “Gazastrook en Westelijke Jordaanoever” gewijzigd in "Gazastrook en Westelijke Jordaanoever, met inbegrip van Oost-Jeruzalem".

B. Het zou beter zijn de asterisk die aangeeft dat de einddatum van een regel in de landentabel fictief is, in een aparte kolom op te nemen in de tabel. Hiervoor wordt de nieuwe rubriek 34.99.97 "Fictieve einddatum tabelregel” geïntroduceerd. Daarnaast wordt deze rubriek gevuld voor alle tabelregels met de waarde die nu al gepubliceerd wordt.

C. Tenslotte worden tabelrubrieken geïntroduceerd voor de ISO 3166-1 Alpha-2 code, de ISO 3166-1 Alpha-3 code, de ISO 3166-1 Numerieke code, de ISO 3166-2 code en de ISO 3166 Engelse landnaam van landen. Deze velden worden gevuld bij alleen die landen in de tabel die op 1 januari 1994 nog niet beëindigd waren. Voor landen die in de tabel voorkomen, maar niet in ISO 3166 (zoals de Kanaaleilanden en Kosovo) worden deze velden leeg gelaten. Voor gebieden die wel in de tabel voorkomen en niet in ISO 3166-1, maar wel in ISO 3166-2 wordt alleen de ISO 3166-2 code opgenomen.

2.3 Gerelateerde wijzigingen in wet- en regelgeving

Er zijn geen relaties met wijzigingen in wet- en regelgeving.

2.4 Openstaande punten

Er zijn, na implementatie van deze wijzigingen geen openstaande punten.

3 Invoering

Deze wijziging zal pas worden opgenomen in LO 2025.Q3, dat volgens planning in werking zal treden op 1 juli 2025, om alle partijen in de gelegenheid te stellen om de hier voorgestelde wijzigingen in tabel 34 te implementeren. Immers: met inwerkingtreding van LO 2025.Q3 zullen de wijzigingen in de Tabellen Applicatie worden doorgevoerd en worden er direct tabelberichten verzonden.

4 Gevolgen

4.1 Documentatie

De aanpassingen in de structuur van tabel 34 zullen in LO BRP en LO BES leiden tot wijzigingen in de beschrijving van de landelijke tabellen (par. 4.7 respectievelijk par. I.7).

4.2 Gemeenten

Alle partijen die tabelberichten verwerken of tabellen downloaden van de website van RvIG, krijgen te maken met de nieuwe en gewijzigde kolommen in tabel 34. Zij moeten dus allemaal zorgen dat ze tabelberichten met de nieuwe structuur van deze tabel kunnen verwerken met ingang van de datum van inwerkingtreding van LO 2025.Q3.

4.3 Afnemers

Alle partijen die tabelberichten verwerken of tabellen downloaden van de website van RvIG, krijgen te maken met de nieuwe en gewijzigde kolommen in tabel 34. Zij moeten dus allemaal zorgen dat ze tabelberichten met de nieuwe structuur van deze tabel kunnen verwerken met ingang van de datum van inwerkingtreding van LO 2025.Q3.

4.4 IND

Alle partijen die tabelberichten verwerken of tabellen downloaden van de website van RvIG, krijgen te maken met de nieuwe en gewijzigde kolommen in tabel 34. Zij moeten dus allemaal zorgen dat ze tabelberichten met de nieuwe structuur van deze tabel kunnen verwerken met ingang van de datum van inwerkingtreding van LO 2025.Q3.

4.5 Caribische landen en Caribisch Nederland

Alle partijen die tabelberichten verwerken of tabellen downloaden van de website van RvIG, krijgen te maken met de nieuwe en gewijzigde kolommen in tabel 34. Zij moeten dus allemaal zorgen dat ze tabelberichten met de nieuwe structuur van deze tabel kunnen verwerken met ingang van de datum van inwerkingtreding van LO 2025.Q3.

4.6 RvIG-systemen

Bij RvIG verwerken de BV BSN, BRP-V en RNI tabelberichten. En de Tabellen Applicatie (TApp) moet ze kunnen verzenden. Dus deze vier systemen moeten worden aangepast.

1 Probleemstelling

1.1 Omschrijving

Een tweetal beveiligingseisen in het Logisch Ontwerp BRP en één uit het Logisch Ontwerp BES voldoen niet aan de richtlijnen voor informatiebeveiliging van RvIG.

1.2 Herkomst

De CISO van RvIG, Björn Dijkstra, heeft aangegeven dat alle LO's moeten voldoen aan de IB-richtlijnen..

1.3 Raakvlakken

Er zijn geen raakvlakken met andere LO-wijzigingen.

2 Oplossing

2.1 Huidige situatie

In LO BRP par. 6.4.4.1 én in LO BES, par. B.5.1 staat dat een afnemer of bijhouder bij het maken van een verbinding met BRP-V het zelfde certificaat mag gebruiken in de testomgeving en in de productieomgeving. In par. A.6.2.3 staan de wachtwoordeisen die BRP-V stelt aan wachtwoorden van afnemers en bijhouders. Die zijn verouderd en sluiten nog te veel combinaties van tekens uit.

2.2 Oplossing

De zin in par. 6.4.4.1 van LO BRP en in par. B.5.1. van LO BES die zegt dat certificaten gebruikt worden in zowel de testomgeving als de productieomgeving, wordt geschrapt. De wachtwoordeisen worden bijgewerkt op basis van input van de CISO.

2.3 Gerelateerde wijzigingen in wet- en regelgeving

Er zijn geen relaties met wet- en regelgeving anders dan de IB-richtlijnen van RvIG zelf.

2.4 Openstaande punten

Er zijn geen openstaande punten na implementatie van deze wijziging.

3 Invoering

Vanwege de impact op partijen buiten RvIG wordt deze wijziging pas opgenomen in LO BRP 2025.Q1 en LO BES 2025.Q1. De wijziging wordt al aangekondigd in de werkgroep Implementatie en het Gebruikersoverleg van mei 2024. Zolang huidige certificaten nog geldig zijn, mogen die blijven worden gebruikt in zowel de testomgeving als de productieomgeving. Zodra een certificaat verloopt en moet worden verlengd, moet worden voldaan aan de nieuwe richtlijnen.

4 Gevolgen

4.1 Documentatie

LO BES en LO BRP moeten worden aangepast conform IB-richtlijnen ten aanzien van het gebruik van certificaten en wachtwoordeisen.

4.2 Gemeenten

Gemeenten en afnemers moeten vóór de inwerkingtreding van LO BRP 2025.Q1 zorgen dat hun wachtwoorden voldoen aan de nieuwe richtlijnen. Certificaten die na die datum worden geïnstalleerd mogen uitsluitend in de testomgeving of in de productieomgeving worden gebruikt.

4.3 Afnemers

Gemeenten en afnemers moeten vóór de inwerkingtreding van LO BRP 2025.Q1 zorgen dat hun wachtwoorden voldoen aan de nieuwe richtlijnen. Certificaten die na die datum worden geïnstalleerd mogen uitsluitend in de testomgeving of in de productieomgeving worden gebruikt.

4.4 IND

Ook de IND moet vóór de inwerkingtreding van LO BRP 2025.Q1 zorgen dat hun wachtwoorden voldoen aan de nieuwe richtlijnen. Certificaten die na die datum worden geïnstalleerd mogen uitsluitend in de testomgeving of in de productieomgeving worden gebruikt.

4.5 Caribische landen en Caribisch Nederland

Certificaten die na die datum worden geïnstalleerd door afnemers van PIVA-V mogen uitsluitend in de testomgeving of in de productieomgeving worden gebruikt.

4.6 RvIG-systemen

De RNI moet vóór de inwerkingtreding van LO BRP 2025.Q1 zorgen dat hun wachtwoorden voldoen aan de nieuwe richtlijnen. Certificaten die na die datum worden geïnstalleerd mogen uitsluitend in de testomgeving of in de productieomgeving worden gebruikt.

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.