1 Probleemstelling

1.1 Omschrijving

Sinds LO BRP 2024.Q2 (22 april 2024) verstrekt de BRP API informatie over alle gezagsrelaties van een persoon: van alle minderjarigen waarover de persoon gezag heeft en alle meerderjarigen onder wiens gezag de persoon staat, wordt het burgerservicenummer verstrekt. Dat is voor sommige afnemers wat summier; zouden graag meer informatie over de betreffende personen meegeleverd krijgen. Daarnaast wordt alleen bij GezagNietTeBepalen een toelichting verstrekt waarom het gezag niet te bepalen is, terwijl die ook nuttig zou zijn bij TijdelijkGeenGezag. Verder is het endpoint /bewoningen op dit moment alleen opengesteld voor gemeentes terwijl het ook relevant is voor andere afnemers, en wordt het endpoint /reisdocumenten uitgefaseerd omdat er inmiddels goede alternatieven zijn op het Basisregister Reisdocumenten. In het endpoint /personen is het mogelijk om te zoeken op postcode en huisnummer, maar sommige afnemers vinden het handig als daar (een deel van) de geslachtsnaam aan kan worden toegevoegd om het zoekresultaat te verkleinen. Tenslotte is er nu nog een informatierubriek voor Geheimhouding persoonsgegevens, terwijl dit eigenlijk een andere representatie betreft van de inhoud van rubriek 07.70.10 Indicatie geheim en er dus geen sprake is van informatie in de zin van het experimentbesluit dataminimalisatie BRP.

Strategische keuze

Door zowel de gemeentelijke leveranciers als de RvIG is de voorkeur uitgesproken voor het bouwen van een centrale voorziening die REST API's aanbiedt aan bijhouders en afnemers, waarmee berichten in JSON-formaat kunnen worden uitgewisseld. Dit lost de huidige knelpunten op en kan worden gezien als een eerste stap richting de nieuwe architectuur, zonder daar al te ver op vooruit te lopen.

Deze nieuw te bouwen centrale voorziening kan ingezet worden voor al het huidige berichtenverkeer, maar dit project is een goede aanleiding om te bezien of er van sommige berichtsoorten en berichtencycli afscheid kan worden genomen.

1.2 Herkomst

Deze wijziging is aangevraagd door afnemers bij de Product Owner van het BRP API team.

1.3 Raakvlakken

Er zijn geen raakvlakken met andere LO-wijzigingen.

2 Oplossing

2.1 Huidige situatie

Op dit moment:

• verstrekt de BRP API in het informatieproduct Gezagsrelaties alleen het burgerservicenummer van personen waarmee de bevraagde persoon een gezagsrelatie heeft;
• verstrekt de BRP API alleen een toelichting bij GezagNietTeBepalen;
• is het endpoint /bewoningen alleen opengesteld voor gemeenten;
• is het endpoint /reisdocumenten open voor nieuwe aansluiters;
• kan er nog niet worden gezocht op geslachtsnaam bij de zoekingang ZoekMetPostcodeEnHuisnummer in het endpoint /personen;
• bestaat er een informatierubriek voor Geheimhouding persoonsgegevens.

2.2 Oplossing

De BRP API wordt zodanig uitgebreid, dat die in het informatieproduct PA.GZ.01 Gezagsrelaties niet alleen de burgerservicenummers levert van de minderjarige over wie iemand gezag heeft of de meerderjarigen onder wiens gezag iemand staat, maar ook de volledige naam en de leeftijd van die minderjarige en de volledige naam van de meerderjarige. Daarnaast gaat de BRP API ook een toelichting leveren bij TijdelijkGeenGezag.
Verder wordt het endpoint /bewoningen opengesteld voor alle afnemers, zodat die ervoor geautoriseerd kunnen worden en wordt het endpoint /reisdocumenten juist uitgefaseerd: er worden geen nieuwe afnemers meer op aangesloten.
In het endpoint /personen wordt de zoekingang ZoekMetPostcodeEnHuisnummer uitgebreid met het optionele element geslachtsnaam.
Tenslotte wordt de informatierubriek PA.IN.01 Geheimhouding persoonsgegevens verwijderd uit het LO omdat het hier geen echt informatieproduct betreft.

2.3 Openstaande punten

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

2.4 Openstaande punten

In deze LO-wijziging wordt alleen nog de BRP Berichten API toegevoegd aan het Logisch Ontwerp BRP, als derde mogelijke manier voor het uitwisselen van berichten, naast de MBS en de webservice StuurGBAbericht. In een latere LO-wijziging zal de MBS worden uitgefaseerd (en de beschrijving ervan dus ook worden verwijderd uit het LO). Nog weer later zal ook de webservice StuurGBAbericht worden uitgefaseerd en wordt ook de beschrijving dáárvan uit het LO verwijderd.

3 Invoering

Deze wijziging zal op of rond 1 april worden opgenomen in de productieomgeving van de BRP API en wordt daarom gepland voor LO 2025.Q2.

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 PBK), ook niet voor de HUP en de WIR.

4.2 Gemeenten

Geen gevolgen.

4.3 Afnemers

Voor afnemers die al gebruik maken van het informatieproduct Gezagsrelaties in de BRP API verandert het koppelvlak omdat er nieuwe gegevens worden meeverstrekt in dat informatieproduct. Het betreft echter een toevoeging van nieuwe elementen in het JSON-object en daar hoeft programmatuur niet op te worden aangepast als afnemers die nieuwe elementen niet nodig hebben. Verder kunnen afnemers anders dan gemeenten voortaan geautoriseerd worden voor /bewoningen, en kunnen er geen nieuwe afnemers worden geautoriseerd voor /reisdocumenten. Het schrappen van PA.IN.01 Geheimhouding persoonsgegevens heeft geen gevolgen, omdat de BRP API al controleerde of afnemers geautoriseerd waren voor de onderliggende rubriek 07.70.10, en ook protocolleerde dat die rubriek was verstrekt. Daar verandert dus niets aan.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

Geen gevolgen.

4.6 RvIG-systemen

De BRP API moet conform bovenstaande worden aangepast.

1 Probleemstelling

1.1 Omschrijving

Sinds 1992 wisselen gemeenten en afnemers persoonsgegevens uit via de mailboxserver (als onderdeel van de BRP Berichtendienst) waarbij de verstrekkingen aan afnemers vanaf 2012 via de landelijke BRP-Verstrekkingsvoorziening plaatsvinden. Jaarlijks worden ca. 185 miljoen berichten via de Berichtendienst getransporteerd. Het contract met de huidige leverancier OpenText voor het beheer en onderhoud van de mailboxserver loopt in maart 2025 af.

De nieuwe stelseldoelarchitectuur BRP van RvIG zal dan echter nog geen andere voorziening leveren, waardoor een oplossing nodig is om het bestaande, noodzakelijke berichtenverkeer te continueren.

Het huidige contract kan niet rechtmatig verlengd worden. Bovendien maakt de huidige mailboxserver gebruik van zeer verouderde techniek, treden er steeds vaker problemen op (zoals het niet automatisch kunnen verwerken van persoonslijsten met meer van 19.000 tekens) in de berichtencycli en voldoet de mailboxserver niet aan de beveiligingseisen die de RvIG stelt ten aanzien van het wachtwoord.

Strategische keuze

Door zowel de gemeentelijke leveranciers als de RvIG is de voorkeur uitgesproken voor het bouwen van een centrale voorziening die REST API's aanbiedt aan bijhouders en afnemers, waarmee berichten in JSON-formaat kunnen worden uitgewisseld. Dit lost de huidige knelpunten op en kan worden gezien als een eerste stap richting de nieuwe architectuur, zonder daar al te ver op vooruit te lopen.

Deze nieuw te bouwen centrale voorziening kan ingezet worden voor al het huidige berichtenverkeer, maar dit project is een goede aanleiding om te bezien of er van sommige berichtsoorten en berichtencycli afscheid kan worden genomen.

1.2 Herkomst

Deze wijziging komt voort uit initiatief ARC-01-01 van programma Toekomst BRP.

1.3 Raakvlakken

Deze wijziging is de eerste van een aantal LO-wijzigingen die nodig zijn in het kader van het uitfaseren van de mailboxserver. Daarnaast zijn sommige andere voorgestelde wijzigingen in het LO een uitvloeisel van deze wijziging, zoals W190 Uitfaseren Hq01 en Xq01 berichtencycli en W208 BRP Afnemersindicaties API.

2 Oplossing

2.1 Huidige situatie

Via de huidige mailboxserver (MBS) worden berichten uitgewisseld tussen (bijna) alle deelnemers van het stelsel. De MBS is een combinatie van een Message Transfer Agent (MTA) en een Message Store (MS) in een X.400 berichtuitwisselingssysteem. Berichten kunnen door een Message Client (MC) worden geplaatst in de mailbox van de ontvanger, of worden opgehaald uit de eigen mailbox. Die berichten hebben een zogenaamd TLV (Tag Length Value) structuur, worden uitgewisseld volgens het sPd of het turbo-sPd protocol en maken gebruik van de Teletex codering. Ze worden uitgewisseld door bepaalde commando's aan te roepen op de mailboxserver. Zowel het protocol als de berichtenstructuur als de Teletex codering zijn flink verouderd en er zijn allerlei knelpunten, zoals een maximale lengte van berichten en van wachtwoorden.

2.2 Oplossing

Omdat het niet wenselijk is om van alle partijen te eisen dat zij zelf een API aanbieden waarmee direct (en synchroon) berichten naar hen kunnen worden verzonden, is het nodig dat er een nieuwe centrale voorziening komt voor berichtuitwisseling waarin elke deelnemer een postvak heeft. Deze voorziening zal worden ontsloten via een API die het verzenden en ophalen van berichten ondersteunt. Berichten krijgen een nieuwe JSON structuur en de tekencodering wordt UTF-8. Verder blijven alle berichtencycli zoals ze zijn, houden de berichten hun huidige naam, blijft de structuur van de berichten in JSON dicht bij de indeling die ze in het TLV-formaat ook hadden en blijft de tekenset beperkt tot tekens die ook in Teletex worden ondersteund.

Voor afnemers is er al een alternatief voor de MBS: de webservice StuurGBAbericht. Via deze webservice kunnen berichten worden verzonden en opgehaald uit BRP-V, waarbij BRP-V het verzenden naar en ophalen uit de MBS verzorgt. De uit te wisselen berichten hebben nog de TLV-structuur en worden integraal in de XML-berichten van de webservice opgenomen. Op termijn zal ook deze webservice verdwijnen en moeten alle afnemers gebruik gaan maken van de nieuwe voorziening.

De nieuwe voorziening zal alle bestaande berichtencycli ondersteunen. Er wordt nog onderzocht of het mogelijk is om afscheid te nemen van sommige berichtencycli, omdat het efficiënter is om ze te vervangen door afzonderlijke API's (denk aan de Ap01-cyclus t.b.v. plaatsen afnemersindicaties, de Av01-cyclus t.b.v. verwijderen afnemersindicaties, de Lg01-cyclus t.b.v. synchronisatie met BRP-V). Ook wordt onderzocht of het mogelijk is om afscheid te nemen van de verwijsberichten en de vrije berichten. Maar dat is voor de beschrijving van de nieuwe voorziening allemaal niet relevant. In deze LO-wijziging wordt er vanuit gegaan dat alle berichtencycli blijven gehandhaafd, maar worden uitgewisseld via de nieuwe voorziening en voorzien van een nieuwe berichtenstructuur.

Tenslotte wordt de TLV-structuur van berichtendienstberichten ook gebruikt in de webservices VraagAI, VraagPL en de functie ControleerPL van de webservice StuurGBAbericht. Ook die (functies van) webservices zullen worden vervangen door aparte API's.

Omdat niet alle aangesloten partijen op het zelfde moment zullen kunnen overstappen op de BRP Berichten API, wordt er ook een tijdelijke voorziening gerealiseerd die berichten kan vertalen en doorsturen van afzenders die al wel zijn overgestapt naar ontvangers die dat nog niet zijn, en andersom. Deze ‘brug’ is een tijdelijke voorziening die daarom niet in het Logisch Ontwerp BRP zal worden beschreven: de koppelvlakken ervan zijn immers RvIG-intern.

BRP-V zal zelfstandig (onafhankelijk van de brug) kunnen bepalen via welk kanaal (Berichtendienst, StuurGBAbericht of BRP Berichten API) een afnemer gegevens verstrekt moet krijgen. De brug en BRP-V doen dit op basis van element 97.12 Aangesloten op de berichtendienst in tabel 59 BRP-deelnemerstabel. Dit element krijgt daarom een iets andere naam: Aansluiting voor berichtuitwisseling. De mogelijke waardes zijn nu nog 0 (Niet aangesloten) en 1 (Wel aangesloten), maar die wijzigen iets:

0 = StuurGBAbericht
1 = BRP Berichtendienst
2 = BRP Berichten API

Let wel: de huidige betekenis van de waarde 0 (Niet aangesloten op de Berichtendienst) ís al dat een deelnemers is aangesloten op StuurGBAbericht.

2.3 Gerelateerde wijzigingen in wet- en regelgeving

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

2.4 Openstaande punten

In deze LO-wijziging wordt alleen nog de BRP Berichten API toegevoegd aan het Logisch Ontwerp BRP, als derde mogelijke manier voor het uitwisselen van berichten, naast de MBS en de webservice StuurGBAbericht. In een latere LO-wijziging zal de MBS worden uitgefaseerd (en de beschrijving ervan dus ook worden verwijderd uit het LO). Nog weer later zal ook de webservice StuurGBAbericht worden uitgefaseerd en wordt ook de beschrijving dáárvan uit het LO verwijderd.

3 Invoering

In deze LO-wijziging wordt enkel nog maar de BRP Berichten API geïntroduceerd als derde oplossing voor het uitwisselen van berichten. Deze wijziging verplicht nog niet tot het gebruik ervan. Vanaf de datum waarop deze wijziging in werking treedt (de planning hiervoor is 1 juli 2025) zal de BRP Berichten API in productie beschikbaar zijn. Dat geldt ook voor de brug en voor BRP-V. Daardoor is het vanaf dat moment in principe voor elke op de MBS aangesloten partij mogelijk om over te stappen op de BRP Berichten API. Om het aantal overstappers een beetje te spreiden stelt RvIG een migratieplan op.

Op 1 juli 2026 mag geen enkele partij meer gebruik maken van de mailboxserver, waardoor deze kan worden uitgezet en afgevoerd. Dat betekent dat alle partijen moeten zijn overgestapt op ofwel StuurGBAbericht, ofwel de BRP Berichten API. Afnemers die dan nog gebruik maken van StuurGBAbericht moeten voor 1 januari 2027 zijn overgestapt op de BRP Berichten API.

4 Gevolgen

4.1 Documentatie

De werking van de BRP Berichten API en de structuur van berichten die via deze API worden uitgewisseld moeten worden beschreven in het Logisch Ontwerp BRP, maar ook in LO BES.

4.2 Gemeenten

Alle gemeenten zijn voor hun bijhoudingstaak aangesloten op de BRP Berichtendienst. Deze LO-wijziging verplicht nog niet tot het overstappen naar de BRP Berichten API, en heeft dus strikt genomen geen directe gevolgen. In overleg met leveranciers werkt RvIG aan een migratieplan waarin de overstap van alle partijen wordt afgestemd en gepland.

4.3 Afnemers

Deze LO-wijziging verplicht nog niet tot het overstappen naar de BRP Berichten API, en heeft dus strikt genomen geen directe gevolgen voor afnemers die gebruik maken van de BRP Berichtendienst. Zij hebben bovendien de keuze om eerst over te stappen op de webservice StuurGBAbericht. In overleg met leveranciers én zelfbouwers werkt RvIG aan een migratieplan waarin de overstap van alle partijen wordt afgestemd en gepland.

4.4 IND

De IND is zowel voor haar taak als bijhouder als voor haar rol als afnemer aangesloten op de BRP Berichtendienst. Deze LO-wijziging verplicht de IND nog niet tot het overstappen naar de BRP Berichten API, en heeft dus strikt genomen geen directe gevolgen. In overleg met leveranciers werkt RvIG aan een migratieplan waarin de overstap van alle partijen wordt afgestemd en gepland.

4.5 Caribische landen en Caribisch Nederland

In Caribische delen van het Koninkrijk wordt geen gebruik gemaakt van de mailboxserver, maar worden berichten uitgewisseld via een FTPS-server. Die berichten hebben echter wel het TLV-formaat dat in het LO BRP en LO BES beschreven is, dus ook de PIVANOBO-systemen zullen moeten worden aangepast. Hiertoe ontstaat echter pas een verplichting als het oude formaat niet meer wordt ondersteund, en dat is in deze LO-wijziging nog niet het geval. In overleg met leveranciers werkt RvIG aan een migratieplan waarin de overstap van alle partijen wordt afgestemd en gepland.

4.6 RvIG-systemen

Bij de RvIG is er een heel aantal systemen dat berichten uitwisselt via de huidige berichtendienst en dat dus op enig moment zal moeten worden aangepast. Hiertoe bestaat echter met de inwerkingtreding van deze LO-wijziging nog géén verplichting. Het betreft de onderstaande systemen:

• RNI (Register Niet-Ingezetenen)
• BRP-V (BRP-Verstrekkingsvoorziening)
• PIVA-V (PIVA-Verstrekkingsvoorziening)
• Daft (Data Analysis & Fingerprint Tool)
• TAPP (Tabellen Applicatie)
• PBK (PIVA-BRP-Koppeling)
• BV BSN (BeheerVoorziening BSN)
• BR (Basisregister Reisdocumenten)
• RPS (Register PaspoortSignaleringen)

Wanneer elk van deze systemen over kan stappen op de BRP Berichten API, moet duidelijk worden uit het migratieplan van RvIG.

1 Probleemstelling

1.1 Omschrijving

In de Werkgroep Implementatie hebben verschillende leveranciers en afnemers te kennen gegeven dat ze de landelijke tabellen graag zouden willen kunnen raadplegen via een API. Met deze LO-wijziging komt RvIG aan die wens tegemoet en wordt de BRP Tabellen API geïntroduceerd.

1.2 Herkomst

Deze wijziging komt voort uit wensen van leveranciers en afnemers.

1.3 Raakvlakken

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

2 Oplossing

2.1 Huidige situatie

De landelijke tabellen worden nu in CSV- en in PDF-formaat gepubliceerd op de website van RvIG. Daarnaast worden wijzigingen in de tabellen (met uitzondering van Tabel 35 Autorisatietabel) via tabelberichten (Dt01/Dw01) verspreid naar afnemers die zijn aangesloten op de berichtendienst of op de webservice StuurGBABericht.

2.2 Oplossing

De BRP Tabellen API maakt het mogelijk om de landelijke tabellen te bevragen. Een tabel kan met één request integraal worden opgehaald, maar er zijn ook allerlei mogelijkheden om bepaalde tabelregels op te vragen.

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 is gepland om op te worden genomen in LO 2025.Q3 (1 juli 2025).

4 Gevolgen

4.1 Documentatie

Alleen LO BRP moet worden aangepast: de BRP Tabellen API moet worden toegevoegd.

4.2 Gemeenten

Er is geen directe impact op de burgerzakensystemen van gemeenten. Het staat leveranciers echter vrij hun systemen aan te passen zodat ze de BRP Tabellen API aanroepen in plaats van alleen tabelberichten te verwerken.

4.3 Afnemers

Afnemers die gebruik willen maken van de BRP Tabellen API moeten hun taakapplicaties hierop aanpassen. Maar dit is niet verplicht en ze blijven de tabelberichten ontvangen via de Berichtendienst.

4.4 IND

Er is geen impact op de systemen van IND in haar rol van bijhouder (aanleveren verblijfstitels)..

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

De BRP Tabellen API wordt gerealiseerd in de Tabellen Applicatie (TAPP). Die moet worden aangepast. Gemeenten en afnemers moeten toegang tot de API kunnen krijgen; dit heeft mogelijk nog impact op netwerkverbindingen en infrastructuur.