W172 oplegnotitie 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).