Burgerservicenummer ontbreekt bij Kadaster natuurlijk persoon

[melsk-r]

Originally created by KayodeBakker (kadaster/BRK-bevragen#810):

Kijkende naar Kadaster niet natuurlijk persoon, is er voor gekozen om rsin als apart veld toe te voegen desondanks dat het identificatie veld gevuld kan zijn met de waarde hiervan. Bij Kadaster natuurlijk persoon niet daarentegen en zal waarschijnlijk met de AVG te maken hebben. Vanuitgaande dat het hiermee te maken heeft, is het alsnog niet logisch aangezien het enige wat weg wordt gelaten het labeltje "burgerservicenummer" is. De waarde blijft immers in identificatie.

Graag hoor ik hier meer over aangezien we toch merken bij het koppelen hierop dat het fijn is om een duidelijk verschil te hebben tussen identificatie van het kadaster en burgerservicenummer/rsin aangezien identificatie nu veels te ambigu is en daarmee lastig te voorspellen wat het zal worden.

[melsk-r]

This comment originally might have been created by someone else.

De achtergrond hiervan is dat de rsin en het kvk-nummer niet volledig en betrouwbaar genoeg zijn gevuld in de BRK om de werking van de API hierop te baseren. Deze worden wel geleverd, maar worden niet gebruikt als primaire sleutel om de persoon te raadplegen. Dus krijg je bij het raadplegen van een zakelijk gerechtigde niet-natuurlijk persoon waarbij een rsin bekend is wel de rsin als identificatie (dat is immers de echte identificatie van de persoon), maar in _links.persoon is een link opgenomen naar de kadasternietnatuurlijk persoon. We kunnen immers niet voldoende vertrouwen op de rsin om direct een link naar de HR API te geven. Dus ook wanneer er wel een rsin is, verwijzen we primair naar de kadasternietnatuurlijkpersoon resource in de BRK API.

Burgerservicenummers in het BRK zijn wel voldoende betrouwbaar gevuld. Daarom wordt hier als identificatie (in zakelijkgerechtigde.persoon) het burgerservicenummer getoond, maar ook in _links.persoon een link opgenomen naar de BRP API. Dus voor ingeschreven natuurlijk personen is het niet de bedoeling dat de natuurlijkpersonen resource van de BRK wordt gebruikt. De meest betrouwbare en actuele gegevens van de persoon vind je immers in de BRP API, niet in de BRK API.
Om die reden is ook burgerservicenummer niet opgenomen in de kadasternatuurlijkpersonen. Het is immers niet de bedoeling ingeschreven natuurlijk personen te raadplegen in de BRK API met kadasternatuurlijkpersonen.

[melsk-r]

This comment originally might have been created by someone else.

Bij het modelleren van persoon in de zakelijk gerechtigde hebben we ook over dit onderwerp de opties besproken en afgewogen vanuit twee opties:

1. specifieke velden gebruiken per soort persoon, dus statutaireNaam en rsin of naam en burgerservicenummer
2. zelfde velden gebruiken ongeacht de soort persoon

Hierbij kwamen we tot de conclusie dat het voor de gebruiker het makkelijkst is wanneer de identificatie en weergavenaam altijd op dezelfde plek uit dezelfde properties gehaald kunnen worden, ongeacht het type persoon.
Bijvoorbeeld als je in een applicatie een lijst met alle zakelijk gerechtigden wilt tonen, kan je die eenvoudig opbouwen met type, persoon.identificatie en persoon.omschrijving. Bij het maken van dat lijst hoef je dus niet voor elke rij te toetsen welk type persoon het is en welk property dus moet worden getoond.

[melsk-r]

This comment originally might have been created by someone else.

Er zit hier nu wel een inconsequentie in de implementatie. Namelijk dat in zakelijkgerechtigden.persoon.identificatie een andere waarde staat dan in kadasternietnatuurlijkpersonen.identificatie bij dezelfde persoon.

Naar mijn idee zouden die hetzelfde moeten zijn.

@kad-hebbim @JohanBoer @MelvLee hoe denken jullie hierover?

[melsk-r]

This comment originally might have been created by someone else.

Volgens mij is zakelijkgerechtigde.persoon.identificatie gelijk aan persoonbasis.identificatie. Dus niet alleen van kadasternietnatuurlijkpersoon

[melsk-r]

This comment originally might have been created by someone else.

Volgens mij is zakelijkgerechtigde.persoon.identificatie gelijk aan persoonbasis.identificatie. Dus niet alleen van kadasternietnatuurlijkpersoon

Je bedoelt dat bijvoorbeeld bij een ingeschreven natuurlijk persoon (waar we een burgerservicenummer hebben) identificatie gevuld is met de kadasterpersoonidentificatie? Hoe moet de gebruiker dan de persoon ophalen in de BRP?

Of andersom dat bij het ophalen van /kadasternietnatuurlijkpersonen/{kadasternietnatuurlijkpersoonidentificatie} property "identificatie" in het antwoord gevuld moet zijn met de RSIN (als die er is)? Dus dat persoon.identificatie ≠ {kadasternietnatuurlijkpersoonidentificatie}?

Dit laatste zou wel de consequentie oplossen. Alleen dan is het ook opnemen van "rsin" nogal dubbelop

[melsk-r]

This comment originally might have been created by someone else.

Volgens mij is zakelijkgerechtigde.persoon.identificatie gelijk aan persoonbasis.identificatie. Dus niet alleen van kadasternietnatuurlijkpersoon

Je bedoelt dat bijvoorbeeld bij een ingeschreven natuurlijk persoon (waar we een burgerservicenummer hebben) identificatie gevuld is met de kadasterpersoonidentificatie? Hoe moet de gebruiker dan de persoon ophalen in de BRP?

Of andersom dat bij het ophalen van /kadasternietnatuurlijkpersonen/{kadasternietnatuurlijkpersoonidentificatie} property "identificatie" in het antwoord gevuld moet zijn met de RSIN (als die er is)? Dus dat persoon.identificatie ≠ {kadasternietnatuurlijkpersoonidentificatie}?

Dit laatste zou wel de consequentie oplossen. Alleen dan is het ook opnemen van "rsin" nogal dubbelop

Laatstgenoemde manier klinkt mij niet logisch in de oren. Je vraagt dan een kadasternietnatuurlijkpersoon op met id=A en in je antwoordbericht krijg je dan als id=B terug bijvoorbeeld...

Met de opzet die we nu gekozen hebben, kun je wel alle kanten op:

• de klant krijgt zowel de rsin terug als de link naar de kadasternietnatuurlijkpersoon en zou dan al kunnen kiezen welke kant hij op wilt gaan; gegevens raadplegen via NHR API (met identificatie) of de BRK API (via de link).
• als de NHR API in de toekomst live gaat, kunnen we de link ook daarnaar laten verwijzen als we zeker weten dat de informatie betrouwbaar is.

Een andere oplossing zou zijn om voor nu geen gebruik te gaan maken van het type 'ingeschreven niet natuurlijk persoon' (omdat rsin niet altijd bekend of betrouwbaar is vanuit BRK) en dus altijd een 'kadaster niet natuurlijk persoon' te leveren. Bij zo een persoon kan dan het veld rsin gevuld zijn, waarmee de klant dan weer bijv. de NHR API kan raadplegen. Dit kost de klant dan wel weer een extra call.

Denk dat we ook moeten kijken naar wat de klantbehoefte hier nu precies is.

[melsk-r]

This comment originally might have been created by someone else.

Als je vanuit REST redeneert, dan is de identificatie van de Kadaster Personen (alle afgeleiden van PersoonBasis) iets van het BRK domein. rsin, kvknummer, bsn, etc zijn allemaal identificaties van een ander domein. Dat mag je niet als identificatie gebruiken in het BRK domein. Anders krijgt je een tight coupling tussen domeinen waardoor wijzigingen in het ene domein leiden tot wijzigingen in het afhankelijk domein

[melsk-r]

This comment originally might have been created by someone else.

Een ander issue dat ook kan ontstaan als je rsin, kvknummer, bsn etc als identificatie gebruikt voor Kadaster Personen, is dat hetzelfde nummer voorkomt als zowel bsn en rsin of een ander identificatie nummer in een andere basisregistratie. Op dat moment is het identificatie nummer niet meer uniek voor een Kadaster Persoon en dan heb je een extra kenmerk nodig om het uniek te kunnen identificeren.