In het RSGB hebben niet ingeschreven personen (ANDER NATUURLIJK PERSOON en ANDER NIET NATUURLIJK PERSOON, voor patch 2 op RSGB 2 was dit daarin ANDER BUITENLANDS NIET NATUURLIJK PERSOON) een door de gemeente uitgegeven nummer. Dit geldt voor RSGB 2 en voor RSGB 3.
In de praktijk zien we echter dat dit nummer niet bestaat. Er is geen bron voor dit gegeven en het wordt (waarschijnlijk vooral ook daarom) niet uitgegeven. Het RSGB en GEMMA schrijven op dit vlak, voor zover ik heb kunnen vinden, ook helemaal niets voor.
Als individuele leverancier is dit probleem niet op te lossen: doordat deze personen vanuit verschillende afdelingen (en dus ook systemen) kunnen worden opgevoerd kan het nummer niet eenduidig worden bepaald zonder afstemming tussen deze mogelijke bronnen in de gemeente.
Het gegeven heeft echter wel kardinaliteit 1 gekregen en is daarmee verplicht geworden in een aantal StUF-berichttypen. Dit komt bijvoorbeeld naar voren in de discussie over het invullen van het nnp.id in het StUF-forum (https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/stuf-bg-310/hoe-nnpid...). Deze discussie is de aanleiding voor de patch op RSGB 2, die naar mijn mening het aangekaarte probleem niet oplost: doordat het nummer niet wordt uitgegeven, zal het ook door de wijziging van de structuur niet voorkomen in de betreffende berichten.
Mijn voorstel is om de betreffende twee nummers te verwijderen uit het RSGB. Het zijn nummers die in de praktijk niet bestaan en waarvan de semantiek dan ook ligt in de techniek en niet in de praktijk/werkelijkheid. Dit zal pijn doen, omdat dergelijke subjecten dan niet meer d.m.v. een eenduidige sleutel kunnen worden geïdentificeerd, maar feitelijk zal er toch gematcht moeten worden op andere gegevens (al is het maar bij het uitgeven van het nummer van een mogelijk nieuw object).
Mocht de conclusie zijn dat een identificatie wel degelijk wenselijk en/of noodzakelijk is, dan zou ik toch graag ook in het RSGB beschreven zien waar, hoe en/of wanneer dit nummer wordt gegenereerd en hoe geborgd kan worden dat (binnen de gemeente) over de verschillende systemen heen deze nummers uniek worden uitgegeven. Alleen dan kan op een nuttige manier van dit nummer gebruik worden gemaakt.
Dit zal zeker pijn doen. Dit doet zelfs zoveel pijn dat je een aantal relaties niet kan waarborgen. (bijvoorbeeld in de LV WOZ kunnen wij op die manier niet waarborgen dat de ontvanger van een WOZ-beschikking teruggevonden kan worden, omdat deze op basis van deze nummers worden gekoppeld.) Het lijkt ons onwenselijk om bij iedere koppeling de betreffende subjecten op een combinatie van een 7 of 8 tal attributen te moeten zoeken. Beter is het om de subjecten eenmalig te identificeren en voorzien van een nummer. Het uitgeven van een uniek nummer voor dit doel, kan niet de grootste uitdaging zijn voor een gemeentelijk midoffice.
De anp en ann.identificatie zijn bijvoorbeeld van belang in het ZS-DMS koppelvlak waar een niet authentieke persoon een zaak kan starten of eventueel daarbij betrokken is.
Daarnaast zijn er al registraties van niet authentieke personen ingerichte bij gemeenten waar deze elementen worden toegepast .
De elementen worden door diverse leveranciers al ondersteund en toegepast
Uit de reacties hierboven maak ik op dat de noodzaak van de betreffende ID's hoog is. Daarbij blijft mijn opmerking staan dat er geen duidelijke afspraken zijn over hoe en waar deze nummers tot stand komen. Als hierover geen implementatie-afspraken worden gemaakt, blijft het dus voor iedere gemeente/configuratie noodzakelijk om maatwerk te leveren die aansluit bij de betreffende situatie.
Voor elke willekeurige applicatie waarin ANP's en ANN's kunnen worden ingevoerd moet dan per situatie worden bepaald of de applicatie zelf het nummer moet bepalen, of dat er een centrale component is die dat doet. En bij het zelf genereren: hoe moet de applicatie dat doen zonder het risico te lopen op dubbel uitgegeven nummers of ANP/ANN's die vanuit verschillende applicaties verschillende ID's krijgen. In beide gevallen loopt de gemeente risico's op het gebied van data-integriteit.
Mijn vraag uit de laatste alinea uit mijn eerste post blijft dus onbeantwoord en wat mij betreft nog steeds zeer relevant.
Klinkt als een (nieuwe) gemeentelijke kernregistratie die oa. services zal moeten bieden voor het genereren en opvragen van unieke id's a.d.v. een aantal gedefinieerde kenmerken. Maken van wat crud-functies hiervoor is niet moeilijk maar het bedenken van de juiste bedrijfslogica (hoe check je op dubbele, op basis waarvan verwijder je id's, wat doe je als personen alsnog een bsn of kvknr krijgen, ...) is nog wel een ding denk ik.
Nieuw is hier een relatief begrip. De identificerende nummers staan al enige jaren in het RSGB. Ze maken al enige jaren deel uit van onze gemeentelijke registratie. We gaan er vanuit dat wat genoemd staat in het RSGB al door verschillende leveranciers geïmplementeerd is. We zijn dan ook benieuwd naar hun ervaringen.
In de Makelaarsuite van Pinkroccade Local Government is een module beschikbaar die centraal 'niet authentieke' personen registreert met de bijbehorende nummers. Deze personen kunnen vervolgens gedistribueerd worden en opgevraagd in het gegevensmagazijn.
De niet natuurlijk personen kunnen zich ook binnen Nederland bevinden. Hierdoor kan een gemeente alle personen die relevant zijn, maar niet in het handelsregister voorkomen, toch opnemen.