W171 oplegnotitie Haal Centraal API's Fase I-2
Wat kun je vinden op deze pagina?
- 1 Probleemstelling
- 1.1 Omschrijving
- 1.2 Herkomst
- 1.3 Raakvlakken
- 2 Oplossing
- 2.1 Huidige situatie
- 2.2 Oplossing
- 2.3 Openstaande punten
- 3 Consequenties
- 3.1 Logisch Ontwerp BRP
- 3.2 Logisch Ontwerp BSN
- 3.3 Logisch Ontwerp BRPk
- 3.4 Logisch Ontwerp BES
- 3.5 Logisch Ontwerp PGK
- 3.6 Beschrijving Interface Reisdocumenten
- 4 Invoering
- 5 Gevolgen
- 5.1 Externe partijen
- 5.2 Wet- en regelgeving BRP
- 5.3 Financiën
- 5.4 RvIG-systemen met externe zichtbaarheid
W171 oplegnotitie Haal Centraal API's Fase I-2
1 Probleemstelling
1.1 Omschrijving
Het programma Haal Centraal van de VNG zorgt ervoor dat basisgegevens uit landelijke registraties 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. Door aan te sluiten op deze API's hoeven gemeenten geen gemeentelijke gegevensmagazijnen meer bij te houden waarin zij feitelijk een kopie van de eigen basisregistratie personen bewaren ten behoeve van binnengemeentelijke bevragingen. De instandhouding van die gegevensmagazijnen is duur doordat gegevensuitwisseling ermee via complexe en verouderde StUF-BG koppelvlakken gebeurt. Daarnaast ontstaan er verschillen tussen de gegevens in de BRP en in die gegevensmagazijnen, en geldt voor afnemers dat die nogal eens op verschillende wijze omgaan met de gegevens uit de BRP, en bijvoorbeeld de aanschrijfnaam op verschillende wijzen samenstellen uit de naamgegevens uit de BRP. De doelstellingen van Haal Centraal zijn dan ook: kostenreductie, een efficiëntere en effectievere wijze van het gebruik van gegevens uit de BRP, betere kwaliteit, meer consistentie bij het gebruik van die gegevens en dataminimalisatie.
Om te onderzoeken of aansluiting op de BRP API's van het programma Haal Centraal het inderdaad mogelijk maakt om afscheid te nemen van die gemeentelijke gegevensmagazijnen wil RvIG samen met de VNG een pilot starten waarin een aantal gemeenten én afnemers de BRP gaat bevragen via de API's van Haal Centraal. In eerste instantie zullen deze API's alleen gegevens verstrekken waarin de wet reeds voorziet (fase I). In fase II zullen ze ook informatie verstrekken die van de BRP-gegevens kan worden afgeleid (zoals leeftijd op basis van de geboortedatum, en aanschrijfnaam op basis van naamgegevens en aanduiding naamgebruik). Om die informatie te mogen verstrekken, is echter een experimentbesluit nodig, omdat dit een andere manier van gegevensverstrekking is dan die waarin de wet BRP nu voorziet.
De API's van Haal Centraal vormen een nieuwe wijze van ad hoc gegevensverstrekking uit BRP-V en dienen als zodanig ook in het LO te worden beschreven, en geschouwd en getoetst te worden.
In een eerder wijzigingsvoorstel (W162) is de verstrekking van gegevens door middel van de BRP Personen API in het LO opgenomen. Dit wijzigingsvoorstel bevat de beschrijving van de benodigde aanpassingen in het LO om verstrekkingen van gegevens (fase I) door middel van de BRP Reisdocumenten API van Haal Centraal in het LO op te nemen. De BRP Bewoning API en de BRP Historie API volgen in een latere versie van LO BRP. Voor fase II zal ook een separate LO-wijziging worden voorbereid.
1.2 Herkomst
Wens van de gemeenten en de VNG om BRP-gegevens direct bij de bron op te halen.
1.3 Raakvlakken
Er zijn geen raakvlakken met andere LO-wijzigingen.
2 Oplossing
2.1 Huidige situatie
In de huidige situatie houden gemeenten een schaduwregistratie bij van hun eigen inwoners, en bevragen ze BRP-V via de adhoc webservice wanneer gegevens van niet-inwoners nodig zijn (in dat geval functioneert de gemeente dus als buitengemeentelijke afnemer - GABA). Ook afnemers bevragen de BRP-V via de adhoc webservice. Dit is een SOAP webservice. Toegang tot deze webservice, autorisatie voor adhoc verstrekking van de gevraagde gegevens en protocollering van die verstrekkingen zijn in het LO beschreven. Met de invoering van de BRP Personen API is de behoefte aan een eigen gegevensmagazijn wel verminderd, maar nog niet verdwenen.
2.2 Oplossing
Het onderhavige LO-wijzigingsvoorstel bevat het logisch ontwerp van de BRP Reisdocumenten API. Het technisch ontwerp staat op de Github pagina's van de RvIG. De API's worden ontsloten via een API Gateway, een in de markt gebruikelijke wijze voor het regelen van toegang, authenticatie en autorisatie tot API's.
Gemeenten hebben voor het raadplegen van de gegevens van eigen inwoners geen aanvullende autorisaties nodig; dit geldt niet als gegevensverstrekking door de Minister. Voor het raadplegen van de gegevens van niet-eigen inwoners, en voor alle verstrekkingen aan afnemers, voldoen de bestaande autorisaties voor ad hoc gegevensverstrekking.
Alle bevragingen via API's worden gelogd én geprotocolleerd. Logging wordt gedaan door de API Gateway; protocollering wordt gedaan door de API applicatie door alle gegevens met betrekking tot een verstrekking aan te bieden aan een protocolleringsinterface van BRP-V. De BRP-V leest deze gegevens in, in de eigen protocolleringstabellen, zodat deze terechtkomen in de bestaande protocolleringsoverzichten wanneer een gemeente daarom vraagt.
Alleen deelnemers aan de pilot van Haal Centraal kunnen gebruik maken van de BRP API's. Deelname aan de pilot is echter niet beperkt tot deze gemeenten en afnemers: wanneer een andere gemeente of afnemer deel wil nemen aan de pilot, kan deze eveneens het convenant ondertekenen en aansluiten op de API’s.
2.3 Openstaande punten
Voor fase I (verstrekking van gegevens, nog geen afgeleide informatie) zijn er geen openstaande punten. Voor fase II (verstrekking van informatie; W172) moet het Experimentbesluit dataminimalisatie BRP worden genomen, zodat de Minister gegevens mag verwerken tot informatie, en die informatie mag verstrekken. Omdat die verstrekkingen in een afzonderlijke LO-wijziging worden beschreven is dat voor nu geen openstaand punt.
3 Consequenties
3.1 Logisch Ontwerp BRP
De nieuwe API wordt conform de inhoud van hoofdstuk 2 in het LO beschreven.
3.2 Logisch Ontwerp BSN
Geen wijzigingen.
3.3 Logisch Ontwerp BRPk
Geen wijzigingen.
3.4 Logisch Ontwerp BES
Geen wijzigingen.
3.5 Logisch Ontwerp PGK
Geen wijzigingen.
3.6 Beschrijving Interface Reisdocumenten
Geen wijzigingen.
4 Invoering
Toegang tot de API's wordt uitsluitend verstrekt aan deelnemers van de pilot van Haal Centraal. Voor alle overige gemeenten en afnemers heeft deze wijziging geen consequenties.
5 Gevolgen
5.1 Externe partijen
5.1.1 Gemeenten
Voor gemeenten die niet deelnemen aan de pilot van Haal Centraal verandert er niets. Voor gemeenten die wel deelnemen, wordt het mogelijk om BRP-V te bevragen via de nieuwe API's van Haal Centraal. De API's verstrekken vooralsnog uitsluitend gegevens zoals het LO die al beschrijft, en nog geen "informatie".
5.1.2 Gemeenten – Burgerlijke Stand modules
Geen gevolgen.
5.1.3 Gemeenten – Reisdocumenten modules
Geen gevolgen.
5.1.4 Afnemers
Uitsluitend deelnemers aan de pilot ondervinden gevolgen. Die kunnen de BRP bevragen via API's zodra ze hun systemen daar geschikt voor hebben gemaakt en toegang tot de API Gateway hebben gekregen.
5.1.5 IND
Geen gevolgen.
5.1.6 Caribisch Nederland
Geen gevolgen.
5.1.7 Caribische Landen
Geen gevolgen.
5.2 Wet- en regelgeving BRP
5.2.1 Wet- en regelgeving BRP
Voor dit punt is een Experimentbesluit opgesteld.
5.2.2 Autorisaties
Geen gevolgen.
5.2.3 Wet- en regelgeving Caribisch Nederland
Geen gevolgen.
5.2.4 Wet- en regelgeving BSN
Geen gevolgen.
5.2.5 Wet -en regelgeving Reisdocumenten
Geen gevolgen.
5.3 Financiën
5.3.1 Financiën
Geen gevolgen.
5.4 RvIG-systemen met externe zichtbaarheid
5.4.1 BRP-V en/of Daft
Geen gevolgen.
5.4.2 RNI
Geen gevolgen.
5.4.3 A-nummer aanvraag programma (AAP)
Geen gevolgen.
5.4.4 TMV
Geen gevolgen.
5.4.5 Evaluatie-Instrument
Geen gevolgen.
5.4.6 POM/POWS
Geen gevolgen.
5.4.7 Tabellenapplicatie
Geen gevolgen.
5.4.8 Berichtenverkeer en mailboxserver
Er zijn geen gevolgen voor het bestaande berichtenverkeer via de berichtendienst en de webservices. De API’s vormen echter wel een nieuwe wijze van gegevensverstrekking en alle berichten die ondersteund worden om gegevens op te vragen via API’s, worden dan ook in dit wijzigingsvoorstel toegevoegd aan het LO.
5.4.9 PGK-module
Geen gevolgen.
5.4.10 PIVA-V
Geen gevolgen.
5.4.11 Tabellenapplicatie PIVA
Geen gevolgen.
5.4.12 BV BSN
Geen gevolgen.
5.4.13 RAAS
Geen gevolgen.
5.4.14 Basisregister/Verificatieregister
Geen gevolgen.
5.4.15 Signaleringsregister
Geen gevolgen.
5.4.16 Centraal meldpunt Identiteitsfraude
Geen gevolgen.
5.4.17 Proefomgevingen BRP-V
Geen gevolgen.
5.4.18 Proefomgeving BV BSN
Geen gevolgen.
W082 oplegnotitie Volledige registratie EU-kiesrechtgegevens
Wat kun je vinden op deze pagina?
W082 oplegnotitie Volledige registratie EU-kiesrechtgegevens
1 Probleemstelling
1.1 Omschrijving
Voorafgaand aan elke verkiezing van het Europees Parlement wisselen EU-lidstaten op grond van de Europese Richtlijn 93/109/EG, bilateraal gegevens uit over kiesgerechtigde burgers met als doel zoveel mogelijk te voorkomen dat deze burgers twee oproepkaarten ontvangen voor de verkiezingen (in de lidstaat van verblijf en in de lidstaat van herkomst).
Momenteel is het voor de lidstaat Nederland niet mogelijk om volledig te voldoen aan de gestelde eisen in de EU-richtlijn en Kieswet over gegevensuitwisseling met andere EU-lidstaten. Van de EU-burger die ervoor kiest om in de lidstaat van verblijf te stemmen, moet worden verstrekt: het adres en woonplaats waar de burger het laatst als kiezer geregistreerd stond in de lidstaat waarvan de burger de nationaliteit bezit. Anders dan de andere uit te wisselen gegevens kan Nederland dit gegeven echter niet (eenvoudig) verstrekken omdat dit niet in de BRP wordt geregistreerd.
Gemeenten beschikken daarentegen wel over dit gegeven. EU-onderdanen met een nationaliteit van een andere EU-lidstaat die in Nederland wonen en er voor kiezen om in Nederland te stemmen voor het Europese Parlement (art. Y 32, lid 2, Kieswet), maken dit kenbaar via een Y32 formulier bij de gemeente van inschrijving. Op het huidige Y32 formulier wordt gevraagd naar ‘laatste adres en plaats in de lidstaat van herkomst’, dit is het adres en woonplaats waar de burger het laatst als kiezer geregistreerd stond in lidstaat waarvan de burger de nationaliteit bezit. In de praktijk is niet altijd duidelijk welk adres wordt bedoeld. Het formulier zal op korte termijn (per 1 april 2023) worden aangepast om dit te verduidelijken.
1.2 Herkomst
BZK-DGOBDR/DenB/Democratie/Team Verkiezingen.
1.3 Raakvlakken
Er zijn geen raakvlakken met andere LO-wijzigingen.
2 Oplossing
2.1 Huidige situatie
Ondanks het feit dat Nederland verplicht is het laatste adres en woonplaats uit de EU-lidstaat van herkomst uit te wisselen met de andere EU-lidstaten is dat tot op heden niet mogelijk. Er is nu geen voorziening om deze gegevens te registreren in de BRP.
2.2 Oplossing
Om volledige gegevensuitwisseling met de EU-lidstaten mogelijk te maken, is een wijziging van het Logisch Ontwerp BRP noodzakelijk. Voor registratie van de laatste adres en woonplaats uit de lidstaat van herkomst wordt groep 13.31 uitgebreid met drie velden:
31.40 Adres EU-lidstaat van herkomst
31.50 Plaats EU-lidstaat van herkomst
31.60 Land EU-lidstaat van herkomst
3 Consequenties
3.1 Logisch Ontwerp BRP
Het Logisch Ontwerp wordt conform paragraaf 2.2 aangepast.
3.2 Logisch Ontwerp BSN
Geen wijzigingen
3.3 Logisch Ontwerp BRPk
Geen wijzigingen
3.4 Logisch Ontwerp BES
Geen wijzigingen
3.5 Logisch Ontwerp PGK
Geen wijzigingen
3.6 Beschrijving Interface Reisdocumenten
Geen wijzigingen
4 Invoering
Omdat EU-richtlijn 93/109/EC verplicht dat de adresgegevens uit de lidstaat waar de EU-onderdaan het laatst als kiezer stond ingeschreven uitgewisseld worden, moeten gemeenten deze gegevens vanaf het in werking treden van het aangepaste LO BRP 4.4 op basis van het brondocument, modelformulier Y32, op de persoonslijst plaatsen.
Het met terugwerkende kracht invoeren van deze gegevens van in het verleden ingevulde Y32 formulieren wordt niet verplicht gesteld. Het is echter wel van belang dat in aanloop naar de aanstaande Europees Parlementsverkiezing (voorjaar 2024) deze gegevens zoveel als mogelijk in de BRP worden geregistreerd, om ‘dubbel stemmen’ zo goed mogelijk te voorkomen.
Kiest de gemeente er voor de nieuwe elementen 31.40, 31.50 en 31.60 in categorie 13 met terugwerkende kracht in te voeren dan kan een gemeente, na het in werking treden van het aangepaste LO BRP 4.4, een selectie maken uit de lokale BRP van alle persoonslijsten waar de aanduiding Europees kiesrecht op voorkomt. Als de betrokken EU-onderdaan nog woonachtig is in de gemeente waar het verzoek tot registratie om in Nederland deel te nemen aan de Europees Parlementsverkiezingen is gedaan, is het brondocument (Y32 formulier) bij die gemeente aanwezig. Als betrokken EU-onderdaan na het verzoek tot registratie voor deelname in Nederland aan de EP-verkiezingen naar een andere gemeente is verhuisd, dan kan het brondocument worden opgevraagd in de gemeente waar deze registratie heeft plaatsgevonden. Op grond van de datum van het verzoek (31.20) kan worden bepaald bij welke gemeente het Y32-formulier moet worden opgevraagd.
5 Gevolgen
5.1 Wet- en regelgeving BRP
Besluit BRP.
5.2 Gemeenten
Aanpassing van de burgerzakenapplicatie op de nieuwe gegevenselementen in categorie 13. Optioneel: het opzoeken van brondocumenten (model Y32) en het registreren van de gegevens.
5.3 Burgerlijke Stand modules
Geen gevolgen.
5.4 Reisdocumenten modules
Geen gevolgen.
5.5 GBA-V en/of Daft
Aanpassing in de gegevensset met impact op de gegevensverstrekking en synchronisatie.
5.6 TMV
Aanpassen BRP catalogus.
5.7 Evaluatie-Instrument
Geen gevolgen.
5.8 BCM en Robin
BCM uitbreiden met controle op de nieuwe gegevenselementen in categorie 13.
5.9 POM/POWS
Zichtbaar maken dat de nieuwe gegevens zijn verstrekt.
5.10 RNI
Aanpassen van de applicatie op ontvangen en tonen van de nieuwe rubrieken. Merk op dat deze rubrieken in de RNI niet worden bijgehouden.
5.11 Technische Handleiding ABO-Interface
Geen gevolgen.
5.12 Tabellenapplicatie
Aanpassing van de autorisatietabelregel op de nieuwe gegevenselementen in categorie 13.
5.13 A-nummer aanvraag programma (AAP)
Geen gevolgen.
5.14 Autorisaties
Bij nieuwe of te wijzigen autorisaties rekening houden met de nieuwe mogelijkheden. Het autorisatieaanvraagformulier (AAF) aanpassen zodat om de nieuwe gegevens kan worden verzocht.
5.15 Berichtenverkeer
Wijzigingen in Lg01, La01 en gegevensverstrekkingen.
5.16 Afnemers
Na autorisatie voor de nieuwe gegevenselementen in categorie 13. Dit betreft vooralsnog uitsluitend team Verkiezingen (formeel de Minister van BZK).
5.17 HUP
HUP moet aangepast worden door het opnemen van de nieuwe gegevenselementen en de beschrijving daarvan.
5.18 WIR
Geen gevolgen.
5.19 Q-brochure/website
Geen gevolgen.
5.20 Voorlichting/roadshows
Gemeenten moeten geïnformeerd worden over het invoeren van de nieuwe gegevenselementen bij de geregistreerde Kiesrechtgegevens.
5.21 Financiën
Geen gevolgen.
5.22 Wet- en regelgeving BES
Geen gevolgen.
5.23 Caribisch Nederland BES
Geen gevolgen.
5.24 PGK-module
Geen gevolgen.
5.25 PIVA-V
Geen gevolgen.
5.26 Caribische landen ACM
Geen gevolgen.
5.27 Tabellenapplicatie PIVA
Geen gevolgen.
5.28 Wet- en regelgeving BSN
Geen gevolgen.
5.29 BV BSN
Geen gevolgen.
5.30 Wet- en regelgeving Reisdocumenten
Geen gevolgen.
5.31 RAAS
Geen gevolgen.
5.32 Signaleringsregister
Geen gevolgen.
5.33 Basisregister/Verificatieregister
Geen gevolgen.
5.34 Centraal meldpunt Identiteitsfraude
Geen gevolgen.
Gebruikershandleiding foutenmeldpunt BSN
Wat kun je vinden op deze pagina?
- Doel website
- Proces
- Werking foutenmeldpunt
- Hardware, certificaat, adres website
- Gebruikerstoegang
- Inloggen, uitloggen
- Hoofdmenu
- Wijzigen wachtwoord
- Blokkeren wachtwoord
- Opvoeren melding
- Afhandelen activiteiten
- Herinnering openstaande meldingen
- Wijzigen contactgegevens
- Functies gegevensbeheer
- Afhandeltermijnen
- Mailmatrix en mailtemplates
- Bijlage 1 menustructuur
Gebruikershandleiding foutenmeldpunt BSN
Doel website
Met het in beheer nemen van de BV-BSN heeft de Rijksdienst voor Identiteitsgegevens zich gecommitteerd aan het inrichten van een foutenmeldpunt voor het melden van BSN-nummerfouten. Dit foutenmeldpunt (FMP) moet zorg dragen voor de registratie en coördinatie van de oplossing van nummerfouten. Het oplossen van de fouten is voorbehouden aan de registerhouders. Om dit proces te faciliteren heeft RvIG besloten een webportal in te richten waar de melding in geregistreerd kan worden.
Proces
Een gebruiker van het burgerservicenummer kan bij een controle constateren dat er mogelijk meerdere ’burgerservicenummers bestaan bij dezelfde persoon.
De gebruiker moet deze zogenaamde foutvermoedens kunnen melden zodat deze beoordeeld en waar nodig hersteld kunnen worden. Melding kan geschieden door Registerhouders en BSN-gebruikers. Hierop is één uitzondering. BSN-gebruikers die aangesloten zijn bij de Sectorale Beheervoorziening voor de Zorgsector (SBV-Z) melden hun foutvermoeden bij de SBV-Z die vervolgens de fout via de applicatie kan melden. Burgers die een foutvermoeden hebben dienen zich te wenden tot de organisatie waar het foutvermoeden is ontstaan of bij de eigen gemeente.
Na melding van de fout wordt er direct een bevestiging van de melding per mail gestuurd met een uniek identificatienummer en komt de melding terecht in een centrale database bij het foutenmeldpunt BSN van Rijksdienst voor Identiteitsgegevens. Hier wordt de fout beoordeeld. Na beoordeling kan het foutvermoeden doorgestuurd worden naar de registerhouder (=gemeente) die de fout moet oplossen of kan het foutenmeldpunt BSN de fout zelf oplossen. Ook kan de fout gekwalificeerd worden als niet terecht waarna het dossier direct gesloten kan worden en de indiener van de fout automatisch op de hoogte gesteld wordt.
Indien de fout wordt doorgestuurd aan een registerhouder wordt er een mail verstuurd naar de contactpersoon van de gemeente met daarin een link naar het foutenmeldpunt BSN. Door op de link te klikken wordt de betreffende medewerker direct naar de foutmelding geleid die hij/zij vervolgens na ingelogd te hebben kan bekijken. De gemeente dient binnen redelijke termijn de fout in behandeling te nemen en, nadat de fout hersteld is dit af te melden via de applicatie. Hetzelfde geldt voor gevallen dat de foutmelding na onderzoek niet terecht blijkt te zijn.
Het foutenmeldpunt BSN ontvangt de terugmelding en sluit het dossier. Na sluiting van het dossier wordt de indiener van het foutvermoeden via mail op de hoogte gesteld van de wijze van afhandeling.
Werking foutenmeldpunt
Het foutenmeldpunt BSN werkt zoals een reguliere MS Windowsaplicatie. Een bericht wordt in het groen getoond. Dit gebeurt boven in het scherm.
Een foutmelding wordt in het rood getoond. Dit gebeurt boven in het scherm door eerst de term ‘FOUTMELDINGEN’ te tonen en vervolgens de betreffende foutmelding(en).
Hardware, certificaat, adres website
Er wordt een PKIO-servercertificaat geïnstalleerd op de server waardoor gebruikersnaam en wachtwoord beveiligd zijn. Ook weet de gebruiker zeker dat men de juiste website bezoekt. De url van de website is https://www.fmpbsn.nl
Gebruikerstoegang
In de applicatie zijn alle gebruikersgegevens opgenomen. Voor de gebruikers vanuit gemeenten en BRP-afnemers is gebruik gemaakt van de gegevens van de BRP-contactpersonen zoals bekend bij RvIG. Voor het verzenden van de email- berichten vanuit het Foutenmeldpunt BSN wordt gebruik gemaakt van het emailadres dat bij de BRP-contactpersoon hoort. Het is ook mogelijk om een ander emailadres op te geven: Het gewenste e-mailadres moet dan voldoen aan het formaat FMP@<instantienaam>.nl of fmp@<instantienaam>.nl. De instantie moet dit via de Frontoffice van RvIG aanvragen.
Inloggen, uitloggen
Na het kiezen van de juiste url verschijnt het volgende scherm:
Als je je gebruikersnaam en/of wachtwoord bent vergeten, kun je contact opnemen met de Frontoffice van RvIG. Als je drie keer een foutief wachtwoord invoert, moet je ook contact opnemen met de Frontoffice van RvIG. De eerste keer dat je inlogt moet je het wachtwoord wijzigen (zie Wijzigen Wachtwoord).
Hoofdmenu
Afhankelijk van de rol die gekoppeld is aan de gebruikersnaam, wordt bepaald welke functionaliteiten voor de gebruiker zichtbaar zijn. In dit scherm kun je ook het wachtwoord wijzigen en uitloggen waardoor je weer in het aanlogscherm terecht komt. Zie voor de menustructuur van de applicatie bijlage 1
Wijzigen wachtwoord
In dit scherm voert de gebruiker het huidige wachtwoord en het nieuwe wachtwoord in. Het nieuwe wachtwoord moet voldoen aan de volgende voorwaarden:
- Wachtwoord moet minimaal 12 posities zijn;
- Wachtwoord moet hoofdletters, kleine letters, cijfers en minimaal 1 leesteken bevatten;
- Als leesteken kun je een van de volgende tekens gebruiken: ! @ # $ % & _ + = .
- 1 x per 3 maanden (90 dagen) dient het wachtwoord verplicht te worden gewijzigd in een nog niet eerder gebruikt wachtwoord;
Gebruiker voert ter bevestiging nogmaals het nieuwe wachtwoord in.
Als de gebruiker klikt op knop [Opslaan], worden wijzigingen opgeslagen en wordt terug genavigeerd naar het menuscherm.
Als de gebruiker klikt op de knop [Annuleren] wordt alleen terug genavigeerd naar het menuscherm.
Blokkeren wachtwoord
Een gebruiker kan maximaal drie keer foutief inloggen. Na drie keer foutief inloggen wordt het gebruikersaccount geblokkeerd en kun je niet meer inloggen. De functioneel beheerder van RvIG kan de blokkade van het account opheffen, neem contact op met de Frontoffice van RvIG.
Opvoeren melding
Met deze functie kan een gebruiker een nieuw foutvermoeden indienen
Procesbeschrijving
Je kunt dit scherm bereiken door na het inloggen in het hoofdmenu op de knop ‘Melding opvoeren’ te klikken.
- Gebruiker klikt op de knop ‘Melding Opvoeren’ in het hoofdmenu.
- Gebruiker voert de melding gegevens in.
- Gebruiker bevestigt de invoer met de knop ‘opslaan’ of ‘opslaan en volgende’.
- Het systeem controleert of de gegeven valide zijn:
a. Indien de gegevens valide zijn maakt het systeem een nieuw dossier aan en slaat hierin de melding gegevens op.
b. Indien de gegevens niet valide zijn, krijgt de gebruiker hiervan een melding in het scherm. - De contactpersoon van de gebruikersorganisatie ontvangt van het systeem een bevestigingsmail met daarin het (unieke) dossiernummer. Indien het veld ‘emailadres’ van de aanmelder is ingevuld stuurt het systeem een ook een zelfde bevestigingsmail naar de aanmelder.
- De knop ‘Annuleren’ navigeert terug naar het hoofdmenu.
Nadat de melding is ingevoerd kan men de melding terug vinden in het overzicht onder het hoofdmenu.
In het scherm kan meerdere nummers invoeren, bijv. een BSN en een A-nummer. Hiervoor moet je in het scherm op ‘Nummer toevoegen’ klikken.
Schermvelden
Veld | Maximale lengte | Verplicht | Bijzonderheden |
Indiener | |||
Organisatie | 40 | X | Dit veld wordt automatisch gevuld in relatie met inlogaccount. |
Aanmelder | |||
Kenmerk | 100 | Hier kan een eigen kenmerk van de instantie die de melding doet worden ingevuld, bijv een briefnummer. | |
Naam bron | 100 | Invoeren: degene die bij u het foutvermoeden heeft gemeld. | |
Functie | 100 | Invoeren: functie van degene die bij u het foutvermoeden heeft gemeld. | |
100 | Indien u hier iets invult, dan worden meldingen ten aanzien van de afhandeling van dit dossier – naast naar uzelf – automatisch naar het ingevulde emailadres verstuurd. | ||
Telefoon | 10 | Invoeren: functie van degene die bij u het foutvermoeden heeft gemeld | |
Melding | |||
Type Melding | 2 | Hier moet een van de mogelijke foutsoorten geselecteerd worden (alleen voor gebruikers met rol gegevensbeheerder) | |
Korte Omschrijving | 200 | Hier vult men een korte omschrijving van de fout in die op het overzicht meldingen zichtbaar wordt. | |
Omschrijving | ∞ | Hier kan men de fout uitvoerig omschrijven. | |
Meldingregels | |||
Nummer | 9 | X | Hier moet per type een nummer ingevuld worden, bijv een Burgerservicenummer of een A-nummer |
Type | 1 | Kies uit de verschillende soorten nummers | |
Naam | 100 | Naam van degene aan wie het nummer is toegekend | |
Geboortedatum | 10 | Vereist formaat : dd-mm-jjjj | |
Straat | 40 | ||
Huisnummer | 10 | ||
Postcode | 6 | Vereist formaat : 1111AA | |
Woonplaats | 40 |
Nadat de melding is opgeslagen ontvangt de indiener automatisch een emailbericht met daarin het dossiernummer en eventueel het ingevoerde kenmerk van de gedane melding. Alle automatisch gegenereerde emails hebben als afzender “Foutenmeldpunt BSN”:
Indien er een emailadres van de aanmelder is ingevuld dan ontvangt deze ook dit emailbericht. Dit dossiernummer wordt ook in blauw getoond op het invoerscherm.
Als de melding wordt afgewezen dan ontvangt de indiener automatisch een emailbericht met daarin het dossiernummer, eventueel het ingevoerde kenmerk van de gedane melding en de reden afwijzing. Indien er een emailadres van de aanmelder is ingevuld dan ontvangt deze ook dit emailbericht.
Als de melding in behandeling is genomen door de gegevensbeheerder dan ontvangt de indiener automatisch een emailbericht met daarin het dossiernummer en eventueel het ingevoerde kenmerk van de gedane melding. Indien er een emailadres van de aanmelder is ingevuld dan ontvangt deze ook dit emailbericht.
Als de melding is afgesloten door de gegevensbeheerder dan ontvangt de indiener automatisch een emailbericht met daarin het dossiernummer en eventueel het ingevoerde kenmerk van de gedane melding. Indien er een emailadres van de aanmelder is ingevuld dan ontvangt deze ook dit emailbericht.
Meldingen organisatie
Je kunt dit scherm bereiken door na het inloggen in het hoofdmenu op de knop ‘Meldingen organisatie’ te klikken.
Gebruiker krijgt de meldingen te zien die door zijn of haar organisatie zijn ingediend.
Ook is het hier mogelijk om de selectie aan te passen door het aanklikken van een of meer checkboxen in het scherm en daarna op de knop [zoeken] of [toon alles] te klikken. In het laatste geval worden alle ooit ingediende meldingen getoond binnen de geselecteerde periode. Het is ook mogelijk te zoeken op meldingnaam (naam van de drager van het betreffende nummer), meldingnummer, omschrijving, A-nummer of BSN-nummer. Hierbij kan gebruik gemaakt worden van wildcards, behalve als er gezocht wordt op A-nummer of BSN. De wildcards die gebruikt kunnen worden zijn *_*. Door te klikken op een regel krijgt de gebruiker een detailscherm van de melding te zien.
Met de knop [Terug] kan men terug naar het overzichtscherm.
Afhandelen activiteiten
Deze functie kan men op de volgende manieren bereiken:
- Via de ontvangen email ‘Melding activiteit toegekend’ door in het mailbericht op de URL onderaan het bericht te klikken.
- Kies in het hoofdmenu de knop ‘Mijn activiteiten’. Het scherm “Activiteiten Overzicht” wordt getoond.
Als je deze functie niet kunt bereiken dan ben je niet geautoriseerd hiervoor. Neem in dat geval contact op met de Frontoffice van RvIG.
klik daarna op de activiteit die afgehandeld moet worden.
Hierdoor kom je in het volgende scherm terecht:
Let op de geplande uitvoerdatum! Als deze overschreden wordt dan ontvang je automatisch een emailbericht ‘herinnering open activiteit’. De details van de melding worden zichtbaar door in het scherm rechtsboven de knop ‘Melding details’ te activeren. Alle activiteiten die behoren bij de melding worden getoond als je rechtsboven de knop “Activiteiten” activeert, ook de activiteiten die niet door jou als gebruiker hoeven te worden afgerond!
Nadat de door jou af te handelen activiteit is afgerond dien je dit aan te geven door in dit scherm de knop ‘Afronden activiteit’ te activeren en het volgende scherm in te vullen:
Er moet hierin duidelijk worden vermeld welke activiteiten men heeft uitgevoerd.
Zorg er wel voor dat je alle activiteiten van een dossier sluit die aan jou zijn toegekend als je klaar bent met een dossier. Het dossier kan pas worden gesloten als alle openstaande acties zijn afgerond en gesloten.
Herinnering openstaande meldingen
Als de uitvoerdatum van de aan jou toegekende activiteit overschreden wordt, dan ontvang je automatisch een emailbericht ‘herinnering open activiteit’. Je moet de activiteit dan zo snel mogelijk afronden.
Wijzigen contactgegevens
Wijzigingen in de gegevens van de BRP-contactpersoon moeten worden doorgegeven aan de Frontoffice van RvIG. Deze wijziging zal daarna automatisch worden bijgewerkt voor het Foutenmeldpunt BSN. Het is mogelijk om een ander emailadres op te geven dan het e-mailadres van de contactpersoon. Het gewenste e-mailadres moet dan voldoen aan het formaat FMP@<instantienaam>.nl of fmp@<instantienaam>.nl. De instantie kan dit via de Frontoffice van RvIG aanvragen.
Functies gegevensbeheer
De gegevensbeheerder ontvangt van het systeem een kopie van de bevestigingsmail met daarin het dossiernummer als er een melding is ingediend.
Als er door een oplosser een activiteit wordt afgerond dan ontvangt de systeembeheerder een mail hierover.
Na het inloggen verschijnt voor de gegevensbeheerder het volgende scherm:
De gegevensbeheerder klikt op de knop [meldingen overzicht] in het hoofdmenu;
Het systeem toont daarna een lijst van alle dossiers met status ‘Aangemeld’ of ‘Open’ .
De meldingen met status ‘Aangemeld’ moeten nog in behandeling genomen worden.Wanneer de gegevensbeheerder klikt op een dossier (= rij) in deze lijst, dan wordt het dossier geopend.
Er worden twee tabbladen getoond: Het tabblad Melding en het tabblad Activiteiten. Bij het openen van het scherm is het tabblad Melding details actief; Op het tabblad Melding worden een of meer knoppen getoond, afhankelijk van de status van de melding. Na het selecteren van een aangemeld dossier krijgt de beheerder de keuze om het dossier te wijzigen, af te wijzen of in behandeling te nemen:
Indien de knop ‘Wijzigen’ geselecteerd is dan verschijnt het volgende scherm:
Hierbij kan de gegevensbeheerder alle ingevoerde gegevens van de aanmelder wijzigen of aanvullen. Na het klikken op de button ‘Wijzigingen opslaan’ worden de wijzigingen opgeslagen. Indien de knop ‘In behandeling nemen’ geselecteerd is dan verschijnt het volgende scherm:
Hierbij moet de gegevensbeheerder de juiste keuze invoeren. Het kiezen van de juiste type melding is van belang voor de meldingenrapportage. De status van de melding wijzigt naar ‘In Behandeling’ en er kunnen er activiteiten aan de melding worden toegevoegd. via de knop activiteit toevoegen:
Indien de knop ‘Melding afwijzen’ geselecteerd is dan verschijnt het volgende scherm:
Hier moet de gebruiker de reden van afwijzen moet opgeven en bevestigen met een druk op de knop [Opslaan]; Via het tabblad Activiteiten kan de gebruiker activiteiten bekijken en toevoegen aan het dossier (zie Aanmaken activiteit).
NB Als er open meldingen aanwezig zijn moet er regelmatig, in ieder geval elke werkdag, worden gekeken of er activiteiten afgerond zijn! In dat geval moet het volgende deelproces worden geïnitieerd door gegevensbeheer.
Zoeken in het dossieroverzicht
In het dossieroverzicht bestaat de mogelijkheid te zoeken op
- Meldingnaam
- Meldingnummer
- Omschrijving
Hierbij kunnen wildcards worden gebruikt. De wildcards zijn: *_*. Verder kan er ook gezocht worden op:
- A-nummer
- BSN
Er zit geen controle op het juist invoeren van een A-nummer of een BSN, dus controleer de invoer als er wel een resultaat wordt verwacht maar niet getoond wordt.
Activiteit toevoegen
Nadat er een melding in behandeling is genomen kunnen er activiteiten worden toegevoegd aan de melding.
Voor elke standaardactiviteit waaruit gekozen kan worden kan een prioriteit worden meegegeven. Hierdoor wordt dan ook de oplostermijn ingevuld. De oplostermijn kan eventueel gewijzigd worden.
Afhandeltermijnen
De afhandeltermijnen van de gemelde fouten is als volgt gedefinieerd in volgorde van prioriteit:
- Hoog: zoals gedefinieerd in de activiteit
- Gemiddeld: zoals gedefinieerd in de activiteit
- Laag: zoals gedefinieerd in de activiteit
Mailmatrix en mailtemplates
In de volgende matrix wordt getoond welke emailberichten automatisch naar welke soort gebruiker gestuurd worden:
Functie/rol | Aanmelder | Oplosser |
Melding opvoeren | X | |
Meldingen overzicht | X | |
Mijn activiteiten | X | |
Beheer | ||
Meldingen organisatie | X | X |
Wachtwoord wijzigen | X | X |
Uitloggen | X | X |
NB de aanmelder krijgt alleen emailberichten als het emailadres is ingevuld bij het opvoeren van de melding! De ‘oplosser’ is degene die een activiteit krijgt toegekend.
Hieronder worden de verschillende soorten emailberichten getoond:
Dossiernummer (UC1)
Afgewezen melding
In behandeling genomen (UC4)
Toegekende activiteit (UC5)
Afhandeling dossier (UC8)
Herinnering niet afgehandelde activiteit (UC9)
Herinnering open dossier (UC9)
Bijlage 1 menustructuur
De inhoud van het hoofdmenu is afhankelijk van de rol die de gebruiker heeft.
In onderstaand overzicht is aangegeven welke functies (knoppen) de gebruiker in het hoofdmenu ter beschikking heeft:
Beschrijving per functie:
Melding opvoeren:
Scherm : Dossieroverzicht
Beschikbare knoppen:
Opslaan en volgende: volgende melding kan worden ingevoerd Opslaan: melding wordt opgeslagen; terug naar hoofdmenu Annuleren: melding wordt niet opgeslagen ; terug naar hoofdmenu
Meldingenoverzicht:
Scherm: Dossieroverzicht
Beschikbare knoppen:
Mijn activiteiten: hier worden de activiteiten getoond die aan u als oplosser zijn toegewezen
Home: terug naar hoofdmenu
Uitloggen: men verlaat de applicatie en komt in het inlogscherm Rapportage: er wordt een overzicht gegeven van alle meldingen die men heeft gedaan.
Mijn activiteiten
Scherm: Activiteitenoverzicht
Hier worden de activiteiten getoond die aan jou als oplosser zijn toegewezen Functie: door het aanklikken van een activiteit verschijnt de activiteit die aan jou is toegewezen.
Beschikbare knoppen:
Meldingen: terug naar Dossieroverzicht (Meldingenoverzicht) Home: terug naar hoofdmenu
Uitloggen: men verlaat de applicatie en komt in het inlogscherm
Meldingen Organisatie:
Scherm: Dossieroverzicht met als subkop: tonen meldingen mijn organisatie
Beschikbare knoppen:
Mijn activiteiten: Hier worden de activiteiten getoond die aan u als oplosser zijn toegewezen.
Rapportage: hier wordt een bestand aangemaakt waarin alle meldingen worden opgenomen.
Activiteit:
Scherm: de te behandelen activiteit
Functie: behandelen activiteit die aan de oplosser is toegewezen. Beschikbare knoppen:
Afronden activiteit: in dit scherm geeft u aan welke handelingen er uitgevoerd zijn en dat de activiteit is afgerond.
Terug: er wordt teruggegaan naar vorige scherm in de menustructuur (activiteitenoverzicht van de melding)
Home: terug naar hoofdmenu
Uitloggen: men verlaat de applicatie en komt in het inlogscherm
Wachtwoord wijzigen:
Scherm: wachtwoord wijzigen
Beschikbare knoppen:
Home: terug naar hoofdmenu
Opslaan: het nieuwe wachtwoord wordt opgeslagen; terug naar hoofdmenu
Annuleren: het nieuwe wachtwoord wordt niet opgeslagen; terug naar hoofdmenu
Uitloggen:
Functie: men verlaat de applicatie en komt in het inlogscherm
Functionele specificaties Beheervoorziening BSN
Wat kun je vinden op deze pagina?
Functionele specificaties Beheervoorziening BSN
1. Inleiding
Dit document is een aanvulling op het functioneel ontwerp van de BV BSN en geeft invulling op een aantal punten, waar gekozen is voor een flexibele opzet van de use cases. Dit document kan naar aanleiding van voortschrijdend inzicht of bevindingen bij testuitvoering aangepast worden.
Definities
Zie de BSN glossary.
2. Intelligent zoeken
2.1 inleiding
Alleen velden die niet verplicht zijn. De velden, die altijd onderdeel uitmaken van het verplicht zoekpad, worden niet gebruikt in het aankleed regime en derhalve niet in de BV BSN toegepast.
Het gaat hierbij voor UC12 om de velden:
- Geslachtsnaam
- Geboortedatum
- Geslachtsaanduiding
En voor UC23 (en ook 35 en 37) om de velden:
- Geboortedatum
- Geslachtsaanduiding
2.2 Algemeen
Per veld kan een keuze gemaakt worden welke zoekmethode geboden wordt. Hierbij moet een goede afweging gemaakt worden tussen de kans op een juiste match en het risico van een onjuiste match.
Er kunnen verschillende zoekmethoden onderscheiden worden:
- Exacte match: Het opgegeven veld komt exact overeen met het gevonden veld. Deze zoekmethode zal voor alle opgegeven velden gebruikt worden.
- Diakrietentransformatie: Het opgegeven veld komt, na diakrietentransformatie, exact overeen met het gevonden veld (dat volgens dezelfde methode is ontdaan van zijn diakrieten). In onderstaande tabel staat aangegeven voor welke velden diakrietentransformatie wordt toegepast. In de notitie “Diakrieten” is reeds beschreven hoe moet worden omgegaan met de transformatie van diakrieten.
- Overige zoekmethoden: Er zijn verschillende zoekmethoden per veld onderscheiden. Deze staan in de tweede tabel. Bij het selecteren van de zoekmethoden, zijn de volgende uitgangspunten gehanteerd:
- Er wordt uitgegaan van een goed identificeerbare persoon (liefst met identiteitsdocument), die aan het loket geïdentificeerd wordt.
- Tikfouten worden niet opgelost met de voorgestelde zoekmethoden.
In onderstaand overzicht staat per veld aangegeven of diakrietentransformatie van toepassing is.
Veld |
Diakrietentrans- formatie |
Voornamen |
X |
Voorvoegsels geslachtsnaam |
X |
Geslachtsnaam |
X |
Geboortedatum |
|
Geboorteplaats |
X |
Geboorteland |
X |
Geslachtsaanduiding |
|
Nationaliteit |
|
Gemeente van inschrijving |
X |
Straatnaam |
X |
Huisnummer |
|
Huisletter |
|
Huisnummertoevoeging |
|
Aanduiding bij huisnummer |
|
Postcode |
(1) |
Locatiebeschrijving |
X |
Land vanwaar ingeschreven |
X |
Datum vertrek uit Nederland |
|
(1) Voor de postcode geldt: Alleen exacte match, case insensitive
2.2.1 Diakrietentransformatie
De diakrietentransformatie wordt als volgt uitgevoerd:
- Alle diakritische tekens worden verwijderd en een aantal bijzondere lettertekens (bv. Ǽ) wordt omgezet naar een corresponderend teken of tekens in de range ‘a’ tot en met ‘z’. Dit gebeurt volgens een vertaaltabel (zie conversietabellen).
- Alle (normale) hoofdletters A tot en met Z worden omgezet naar de overeenkomstige kleine letters.
- Alle resterende karakters, niet zijnde de cijfers ‘0’ tot en met ‘9’ en de letters ‘a’ tot en met ‘z’, worden omgezet naar spaties waarna alle spaties worden verwijderd.
2.3 Zoekmethoden per veld voor UC 12
2.3.1 Voornamen
- Alleen op de opgegeven voornamen zoeken
Het is mogelijk om alleen op die voornaam/voornamen te zoeken, die in de vraag zijn opgegeven. Dit betekent dat als slechts één voornaam is opgegeven, deze wordt vergeleken met de eerste voornaam in het veld voornamen en als er twee voornamen zijn opgegeven, deze worden vergeleken met de eerste twee voornamen in het veld voornamen, etc. De opgegeven volgorde en de in de registratie vastgelegde volgorde moeten exact aan elkaar gelijk zijn. - Op eerste voorletter zoeken
Er wordt alleen op eerste voorletter gezocht als slechts 1 positie in het veld voornamen is opgegeven. Het opgegeven karakter wordt vergeleken met de eerste positie van het veld in de registratie (na diakrietentransformatie).
Bij het zoeken in BVR’ het zoekresultaat alleen verkleind door het zoeken op voornaam of de opgegeven voornaam, indien het veld voornamen gevuld is (en ongelijk is aan het veld voorletters). Het zoeken op eerste voorletter wordt altijd uitgevoerd (ongeacht of in het veld voornamen de voornamen of de voorletters zijn opgenomen).
2.3.2 Voorvoegsels geslachtsnaam
Geen overige zoekmethoden
2.3.3 Geslachtsnaam
N.B. Dit veld is onderdeel van het verplichte zoekpad en de zoekstap is daarmee functioneel onderdeel van de beheercomponenten. Voor de compleetheid wordt hier ook beschreven, hoe met het zoeken van de geslachtsnaam wordt omgegaan.
1. Bekende schrijfwijzen van onderdelen van een naam
Op basis van een conversietabel wordt de opgegeven naam vergeleken met het veld Geslachtsnaam in de registraties. Uitgangspunten hierbij zijn:
- Gericht op het oplossen van verschillen in buitenlandse geslachtsnamen, omdat de verwachting is dat Nederlandse geslachtsnamen goed gedocumenteerd (paspoort, rijbewijs) zijn
- De omzetting is met name gericht op transliteratie en transscriptie. Hiermee worden gedeeltelijk verschillen in het omzetten van niet Romaanse schriften opgelost. (In Russische paspoorten is bijvoorbeeld vaak het cyrillisch omgezet volgens een Franse transliteratie. Deze verschilt van de Nederlandse of Engelse transliteratie).
- Er is met name aandacht besteed aan de omzetting van cyrillisch (en afgeleide schriften), Chinees, Koreaans en Arabisch.
- De voorgestelde omzetting wordt toegepast op de geslachtnaam, zoals deze na diakrietentransformatie (in brede zin) is ontstaan.
De omzetting zal als volgt plaatsvinden
a. In geslachtsnaam gevonden letter of lettercombinatie wordt vervangen door een code volgens onderstaande tabel. Hierbij wordt de langste combinatie eerst vervangen. De overige letters in de naam blijven staan.
Code |
Letters of lettercombinaties |
1 |
v,w |
2 |
ae, a |
3 |
zj, zh, sh, sch, tsj, ch, tsch, tch, sj, jh, x, kh, s |
4 |
sjtsj, schch, schtsch, chtch, sc |
5 |
j, i, y |
6 |
u, oe, ou, yu, o, ue |
b. Letters en codes, die opeenvolgend meermalen voorkomen, worden teruggebracht tot 1 (dus eee wordt e en 33 wordt 3)
c. de “h”, die niet in een combinatie in de tabel voorkomt, wordt verwijderd. (Hiermee wordt dh=d, th=t, etc)
2 Opgegeven geslachtsnaam en opgegeven voorvoegsels combineren
De opgegeven voorvoegsels en geslachtsnaam worden van diakrieten ontdaan en samen gevoegd om deze te vergelijken met de velden voorvoegsels en geslachtsnaam uit de registratie, die een zelfde bewerking hebben ondergaan.
2.3.4 Geslachtsaanduiding
N.B. Dit veld is onderdeel van het verplichte zoekpad en de zoekstap is daarmee functioneel onderdeel van de beheercomponenten. Voor de compleetheid wordt hier ook beschreven, hoe met het zoeken van de geslachtsaanduiding wordt omgegaan.
- Als in de zoekvraag ‘Man’ wordt opgegeven, wordt gezocht naar ‘Man’ én ‘Onbekend’.
- Als in de zoekvraag ‘Vrouw’ wordt opgegeven, wordt gezocht naar ‘Vrouw’ én ‘Onbekend’.
2.3.5 Geboortedatum
N.B. Dit veld is onderdeel van het verplichte zoekpad en de zoekstap is daarmee functioneel onderdeel van de beheercomponenten. Voor de compleetheid wordt hier ook beschreven, hoe met het zoeken van de geboortedatum wordt omgegaan.
- als in de zoekvraag staat jjjjmmdd, wordt gezocht op jjjjmmdd (Exacte match)
- als in de zoekvraag staat jjjjmm00, wordt gezocht op jjjjmm00 en jjjjmm01
- als in de zoekvraag staat jjjj0000, wordt gezocht op jjjj0000, jjjj0101 en jjjj0701
- als in de zoekvraag staat 00000000, wordt gezocht op 00000000
2.3.6 Geboorteplaats
1. Gemeentenaam voor herindeling
Bij het opgeven van een geboorteplaats wordt rekening gehouden met het door de gebruiker opgeven van een gemeentenaam van voor herindeling. Daarnaast wordt er rekening mee gehouden dat er gemeentes met gelijke namen zijn. In dat geval moet naar alle bijbehorende gemeentes worden gezocht
2. Bekende schrijfwijzen Nederlandse plaatsnamen (incl. woonplaatsen) Op basis van een conversietabel wordt de ingevoerde plaatsnaam ten behoeve van de vergelijking omgezet naar de officiële plaatsnaam. Hierbij wordt er rekening mee gehouden dat een woonplaats onder meerdere gemeenten kan vallen en dat er woonplaatsen met gelijke namen bestaan.
2.3.7 Geboorteland
Geen overige zoekmethoden
2.3.8 Nationaliteit
Geen overige zoekmethoden
2.3.9 Gemeente van inschrijving
Geen overige zoekmethoden
2.3.10 Datum vertrek uit Nederland
Geen overige zoekmethoden
2.4 Zoekmethoden per veld voor UC 23
Deze zoekmethoden gelden ook voor BV BSN UC35 en BV BSN UC37.
1. Alleen op de opgegeven voornamen zoeken
Het is mogelijk om alleen op die voornaam/voornamen te zoeken, die in de vraag is/zijn opgegeven. Dit betekent dat als slechts één voornaam is opgegeven, deze wordt vergeleken met de eerste voornaam in het veld voornamen en als er twee voornamen zijn opgegeven, deze worden vergeleken met de eerste twee voornamen in het veld voornamen, etc. De opgegeven volgorde en de in de registratie vastgelegde volgorde moeten exact aan elkaar gelijk zijn.
2. Op eerste voorletter zoeken
Er wordt alleen op eerste voorletter gezocht als slechts 1 positie in het veld voornamen is opgegeven. Het opgegeven karakter wordt vergeleken met de eerste positie van het veld in de registratie (na diakrietentransformatie).
2.4.2 Voorvoegsels geslachtsnaam
Geen overige zoekmethoden
2.4.3 Geslachtsnaam
1. Bekende schrijfwijzen van onderdelen van een naam
Op basis van een conversietabel wordt de opgegeven naam vergeleken met het veld Geslachtsnaam in de registraties. Uitgangspunten hierbij zijn:
- Gericht op het oplossen van verschillen in buitenlandse geslachtsnamen, omdat de verwachting is dat Nederlandse geslachtsnamen goed gedocumenteerd (paspoort, rijbewijs) zijn
- De omzetting is met name gericht op transliteratie en transcriptie. Hiermee worden gedeeltelijk verschillen in het omzetten van niet Romaanse schriften opgelost. (In Russische paspoorten is bijvoorbeeld vaak het cyrillisch omgezet volgens een Franse transliteratie. Deze verschilt van de Nederlandse of Engelse transliteratie).
- Er is met name aandacht besteed aan de omzetting van cyrillisch (en afgeleide schriften), Chinees, Koreaans en Arabisch.
- De voorgestelde omzetting wordt toegepast op de geslachtnaam, zoals deze na diakrietentransformatie (in brede zin) is ontstaan.
De omzetting zal als volgt plaatsvinden
d. In geslachtsnaam gevonden letter of lettercombinatie wordt vervangen door een code volgens onderstaande tabel. Hierbij wordt de langste combinatie eerst vervangen. De overige letters in de naam blijven staan.
Code |
Letters of lettercombinaties |
1 |
v,w |
2 |
ae, a |
3 |
zj, zh, sh, sch, tsj, ch, tsch, tch, sj, jh, x, kh, s |
4 |
sjtsj, schch, schtsch, chtch, sc |
5 |
j, i, y |
6 |
u, oe, ou, yu, o, ue |
e. Letters en codes, die opeenvolgend meermalen voorkomen, worden teruggebracht tot 1 (dus aa wordt a, eee wordt e en 33 wordt 3)
f. de “h”, die niet in een combinatie in de tabel voorkomt, wordt verwijderd. (Hiermee wordt dh=d, th=t, etc)
2. Opgegeven geslachtsnaam en opgegeven voorvoegsels combineren De opgegeven voorvoegsels en geslachtsnaam worden van diakrieten ontdaan en samen gevoegd om deze te vergelijken met de velden voorvoegsels en geslachtsnaam uit de registratie, die eenzelfde bewerking hebben ondergaan.
2.4.4 Geslachtsaanduiding
N.B. Dit veld is onderdeel van het verplichte zoekpad en de zoekstap is daarmee functioneel onderdeel van de beheercomponenten. Voor de compleetheid wordt hier ook beschreven, hoe met het zoeken van de geslachtsaanduiding wordt omgegaan.
o Als in de zoekvraag ‘Man’ wordt opgegeven, wordt gezocht naar ‘Man’ én ‘Onbekend’.
o Als in de zoekvraag ‘Vrouw’ wordt opgegeven, wordt gezocht naar ‘Vrouw’ én ‘Onbekend’.
2.4.5 Geboortedatum
N.B. Dit veld is onderdeel van het verplichte zoekpad en de zoekstap is daarmee functioneel onderdeel van de beheercomponenten. Voor de compleetheid wordt hier ook beschreven, hoe met het zoeken van de geslachtsnaam wordt omgegaan.
- Als in de zoekvraag staat jjjjmmdd, wordt gezocht op jjjjmmdd (Exacte match)
- Als in de zoekvraag staat jjjjmm00, wordt gezocht op jjjjmm00 en jjjjmm01
- Als in de zoekvraag staat jjjj0000, wordt gezocht op jjjj0000, jjjj0101 en jjjj0701
- Als in de zoekvraag staat 00000000, wordt gezocht op 00000000
2.4.6 Geboorteplaats
1. Gemeentenaam voor herindeling
Bij het opgeven van een geboorteplaats wordt rekening gehouden met het door de gebruiker opgeven van een gemeentenaam van voor herindeling. Daarnaast wordt ermee rekening gehouden dat er gemeentes met gelijke namen zijn. In dat geval moet naar alle bijbehorende gemeentes worden gezocht
2. Bekende schrijfwijzen Nederlandse plaatsnamen (incl. woonplaatsen) Op basis van een conversietabel wordt de ingevoerde plaatsnaam ten behoeve van de vergelijking omgezet naar de officiële plaatsnaam. Hierbij wordt er rekening mee gehouden dat een woonplaats onder meerdere gemeenten kan vallen en dat er woonplaatsen met gelijke namen bestaan.
2.4.7 Geboorteland
Geen overige zoekmethoden
2.4.8 Gemeente van inschrijving
1. Gemeentenaam voor herindeling
Bij het opgeven van een geboorteplaats wordt rekening gehouden met het door de gebruiker opgeven van een gemeentenaam van voor herindeling. Daarnaast wordt gehouden met dat er gemeentes met gelijke namen zijn. In dat geval moet naar alle bijbehorende gemeentes worden gezocht
2. Bekende schrijfwijzen Nederlandse plaatsnamen (incl. woonplaatsen) Op basis van een conversietabel wordt de ingevoerde plaatsnaam ten behoeve van de vergelijking omgezet naar de officiële plaatsnaam. Hierbij wordt er rekening mee gehouden dat een woonplaats onder meerdere gemeenten kan vallen en dat er woonplaatsen met gelijke namen bestaan.
2.4.9 Straatnaam
BOCO-vertaling (24 tekens) Als de straatnaam langer is dan 24 posities dan wordt de straatnaam ingekort volgens de specificaties van de BOCO- norm (zie bijlage 1 van de HUP GBA).
2.4.10 Huisnummer
Alleen het eerste numerieke deel wordt meegenomen in de vergelijking.Het huisnummer kan alleen numeriek zijn, alle tekens na de eerste set numerieke tekens worden verwijderd
2.4.11 Huisletter
Terug tot 1 positie. Het eerste niet-numerieke teken in het opgegeven veld als huisletter gezien.
2.4.12 Huisnummertoevoeging
Alleen exacte match
2.4.13 Aanduiding bij huisnummer
Alle andere invoer dan “to” of “by” wordt genegeerd en heeft dan geen gevolgen voor de gevonden resultaten.
2.4.14 Postcode
Geen overige zoekmethoden
2.4.15 Locatiebeschrijving
Geen overige zoekmethoden
2.4.16 Land vanwaar ingeschreven
1. Bekende schrijfwijzen buitenlandse landen
Op basis van een conversietabel wordt de landnaam omgezet. In de conversietabel zullen van een land de lokale schrijfwijze en de Nederlandse schrijfwijze worden opgenomen.
2. Historische landnamen
Op basis van de landentabel wordt de opgegeven naam geconverteerd en vergeleken met de vulling van het veld in de registratie.
2.5 Instellingen intelligent zoeken
2.5.1 Wegingsfactor
De wegingsfactor van een veld bepaalt de volgorde van het toepassen van het aankleedregime. Daarnaast wordt de wegingsfactor gebruikt om (ten behoeve van UC 12) de score te berekenen. De hier opgegeven wegingsfactoren vormen de initiële instelling van het intelligent zoeken. Deze kunnen naar aanleiding van het afstellen van het intelligent zoeken gewijzigd worden.
Veld |
Wegingsfactor |
Voornamen |
0,70 |
Voorvoegsels geslachtsnaam |
0,65 |
Geslachtsnaam |
0,85 |
Geboortedatum |
0,90 |
Geboorteplaats |
0,67 |
Geboorteland |
0,60 |
Geslachtsaanduiding |
0,90 |
Nationaliteit |
0,30 |
Gemeente van inschrijving |
0,50 |
Straatnaam |
0,45 |
Huisnummer |
0,75 |
Huisletter |
0,40 |
Huisnummertoevoeging |
0,25 |
Aanduiding bij huisnummer |
0,20 |
Postcode |
0,80 |
Locatiebeschrijving |
0,10 |
Land vanwaar ingeschreven |
0,32 |
Datum vertrek uit Nederland |
0,35 |
2.5.2 Matchwaarde zoekmethode per veld
De hier opgegeven matchwaarden vormen de initiële instelling van het intelligent zoeken. Deze kunnen naar aanleiding van het afstellen van het intelligent zoeken gewijzigd worden.
Veld |
Zoekmethode |
Matchwaarde |
Voornamen |
Exact |
1 |
Diakrietentransformatie |
0,95 |
|
Alleen op opgegeven voornamen zoeken |
0,80 |
|
Op eerste voorletter zoeken |
Nvt |
|
Voorvoegsels geslachtsnaam |
Exact |
1 |
Diakrietentransformatie |
0,95 |
|
Geslachtsnaam |
Exact |
1 |
Diakrietentransformatie |
0,95 |
|
Bekende schrijfwijzen van onderdelen van een naam |
(lengte van de langste string – Levenshtein distance)/ lengte van de langste string |
|
Opgegeven geslachtsnaam en voorvoegsels combineren |
0,8 |
|
Geboortedatum |
Exact |
1 |
Diverse notaties met nullen |
0,8 |
|
Geboorteplaats |
Exact |
1 |
Diakrietentransformatie |
0,95 |
|
Gemeentenaam voor herindeling |
0,9 |
|
Geboorteland |
Exact |
1 |
Diakrietentransformatie |
0,95 |
|
Geslachtsaanduiding |
Exact |
1 |
Ook met geslacht is “O” zoeken |
0,85 |
|
Nationaliteit |
Exact |
1 |
Gemeente van inschrijving |
Exact |
1 |
Diakrietentransformatie |
0,95 |
|
Gemeentenaam voor herindeling |
0,9 |
|
Bekende schrijfwijzen Nederlandse plaatsnamen (woonplaatsen) |
0,85 |
|
Straatnaam |
Exact |
1 |
Diakrietentransformatie |
0,95 |
|
BOCO-vertaling |
0,85 |
|
Huisnummer |
Exact |
1 |
Alleen het eerste numerieke deel |
0,8 |
|
Huisletter |
Exact |
1 |
Terug naar 1 positie |
0,80 |
|
Huisnummertoevoeging |
Exact |
1 |
Aanduiding bij huisnummer |
Exact |
1 |
Negeren andere invoer dan to of by |
0,9 |
|
Postcode |
Exact (case insensitive) |
1 |
Locatiebeschrijving |
Exact |
1 |
Diakrietentransformatie |
0,95 |
|
Land vanwaar ingeschreven |
Exact |
1 |
Diakrietentransformatie |
0,95 |
|
Datum vertrek uit Nederland |
Exact |
1 |
2.6 Conversietabellen
2.6.1 Woonplaatsen
Ten behoeve van het zoeken op woonplaats zal een conversietabel waarin de woonplaats volgens PTT en NEN en de gemeentenaam zijn gekoppeld worden toegepast. Onderstaand een uittreksel als voorbeeld. De volledige tabel komt in Excel beschikbaar
Plaats PTT |
Plaats NEN |
Gemeentecode |
Gemeentenaam |
LEIDSCHENDAM |
LEIDSCHENDAM |
1916 |
Leidschendam-Voorburg |
VOORBURG |
VOORBURG |
1916 |
Leidschendam-Voorburg |
RYSWYK ZH |
RIJSWIJK ZH |
603 |
Rijswijk |
WATERINGEN |
WATERINGEN |
1783 |
Westland |
LEIDEN |
LEIDEN |
546 |
Leiden |
2.6.2 Vertaaltabel diakrieten
Ten behoeve van de diakrietentransformatie wordt een conversietabel gehanteerd, waarin de letter (met diakriet) en de bijbehorende vertaling zijn opgenomen. Onderstaand een uittreksel als voorbeeld. De volledige tabel is in Excel beschikbaar.
Vertaling |
letter |
Y |
Ý |
Y |
Ŷ |
Y |
Ÿ |
R |
Ŕ |
R |
Ŗ |
R |
Ř |
S |
Ś |
S |
Ŝ |
S |
Ş |
S |
Š |
W |
Ŵ |
T |
Ţ |
T |
Ť |
U |
Ù |
U |
Ú |
U |
Û |
3. Dienstsoorten
Binnen de BV BSN worden de volgende dienstsoorten onderkend:
Dienstnummer |
Dienstsoorten |
02 |
Controleer BSN en identificerende gegevens |
03 |
Haal op set identificerende gegevens |
04 |
Distribueer nummer |
05 |
Registreer nummertoekenning |
06 |
Hang registratie om bij BSN |
07 |
Ophalen berichten uit berichtenlogboek |
08 |
Vraag auditgegevens op |
11 |
Nummer uit verkeer halen |
12 |
Match identificerende gegevens |
16 |
Toets of het nummer een BSN is |
21 |
Registreer opgewaardeerd sofinummer |
22 |
Registreren instantiewijziging |
23 |
Opvragen BSN op basis van identificerende gegevens |
24 |
Verificatie van identiteitsdocumenten |
28 |
Ophalen nummergegevens |
29 |
Ophalen nummerfouten uit het nummerfoutenlogboek |
30 |
Ophalen protocolgegevens |
31 |
Vastleggen autorisatiegegevens |
32 |
Melden foutvermoeden |
33 |
Stellen bulkvraag |
34 |
Ophalen antwoord bulkvraag |
35 |
Opvragen BSN tbv schoning en initiële vulling |
39 |
Doorvoeren correctie nummerregister.doc |
4. Autorisatie: rollen en diensten
4.1 Implementatie vastleggen autorisatiegegevens
Het vastleggen van de autorisatiegegevens zal vooralsnog worden geïmplementeerd op basis van Microsoft Active Directory en de bijbehorende hulpmiddelen. De beschrijving van het proces in de use case zal daarom op verschillende punten afwijken van de realisatie:
- Er is geen sprake van verwerking op basis van berichten.
- De datum vanaf en datum t/m worden niet zoals beschreven geïmplementeerd.
- Logging zal plaatsvinden op basis van de standaardfunctionaliteit.
4.2 Rollen en diensten
Ten behoeve van het autorisatiemechanisme worden de volgende rollen onderkend:
- Beheercomponent
- Beheerorganisatie BV BSN
- Foutenmeldpunt
- Gebruiker van alle verificatievragen
- Gebruiker van twee verificatievragen
Hierbij dient opgemerkt te worden dat de rol beheercomponent betrekking heeft op de BC GBA en de BC RNI. De BC BVR zal niet geautoriseerd worden voor de diensten van de BV BSN.
De rollen zijn gekoppeld aan de diensten, die een rol tot zijn beschikking heeft:
Nr | Dienst | Beheer- component | Beheer- organisatie BV BSN | Fouten- meldpunt | Alle vragen | Twee vragen |
2 | Controleer BSN en identificerende gegevens | X | X | X | X | |
3 | Haal op set identificerende gegevens | X | X | X | X | |
4 | Distribueer nummer | X | X | |||
5 | Registreer nummertoekenning | X | ||||
6 | Hang registratie om bij BSN | X | ||||
7 | Ophalen berichten uit berichtenlogboek | X | X | |||
8 | Vraag auditgegevens op | X | ||||
11 | Nummer uit verkeer halen | X | ||||
12 | Match identificerende gegevens | X | X | X | ||
16 | Toets of het nummer een BSN is | X | X | X | X | X |
21 | Registreer opgewaardeerd sofinummer | X | ||||
22 | Registreren instantiewijziging | X | X | |||
23 | Opvragen BSN op basis van identificerende gegevens | X | X | X | X | |
24 | Verificatie van identiteitsdocumenten | X | X | X | X | |
28 | Ophalen nummergegevens | X | X | |||
29 | Ophalen nummerfouten uit het nummerfoutenlogboek | X | ||||
30 | Ophalen protocolgegevens | X | ||||
31 | Vastleggen autorisatiegegevens | X | ||||
32 | Melden foutvermoeden | X | X | X | ||
33 | Stellen bulkvraag | X | X | X | ||
34 | Ophalen antwoord bulkvraag | X | X | X | ||
35 | Opvragen BSN tbv schoning en initiële vulling | X | X | X | ||
39 | Doorvoeren correctie nummerregister | X |
5. Schoningstermijnen
Ten behoeve van het schoningsproces worden schoningstermijnen gehanteerd. In onderstaande tabel; wordt een overzicht gegeven van de schoningstermijnen:
logboek/register | Schoningstermijn |
Berichtenlogboek | 6 weken |
Nummerfoutenlogboek | 1,5 jaar |
Protocollogboek | 1,5 jaar |
Auditlogboek | 1,5 jaar |
Bulkvragenregister | 2 weken |
6. Auditlogboek
Indien er sprake is van een proces dat het nummerregister muteert, dan is vereist dat ook de tussenstappen van het proces fysiek in het auditlogboek worden vastgelegd.
Aansluiting testen en toetsen BSN
Wat kun je vinden op deze pagina?
Aansluiting testen en toetsen BSN
Inleiding
Als een organisatie volgens de Wet algemene bepalingen BSN gebruiker is, kan de organisatie gebruik gaan maken van de Beheervoorziening BSN (BV BSN) om verificatievragen te stellen. Met deze verificatievragen kan de identiteit en het Burgerservicenummer van een burger, bijvoorbeeld bij een loket, op basis van identificerende persoonsgegevens worden geverifieerd. Het verdient daarbij de voorkeur om deze persoonsgegevens over te nemen uit een identiteitsdocument. Hierna kan het Burgerservicenummer op een betrouwbare wijze in de administratie van de gebruiker worden gebruikt. Om daadwerkelijk van de BV BSN gebruik te kunnen maken moet de aansluitprocedure worden doorlopen. Deze procedure, en de daarin te nemen stappen is te vinden op de website van RvIG
Naast het doorlopen van dit proces moetendoor de gebruiker een aantal technische voorzieningen worden gerealiseerd. Voordat van deze voorzieningen betrouwbaar gebruik kan worden gemaakt moeten ze getest (stap 6 uit de aansluitprocedure) en getoetst worden (stap 7). Testen en toetsen is onderdeel van de aansluitprocedure van de BV BSN. Ook andere partijen (zoals softwareleveranciers) mogen hun technische voorziening testen. Tijdens het test- en toetsproces hebben technisch contactpersonen van de “tester” en beheerorganisatie regelmatig overleg over technische details als ip-adressen en digitale certificaten. In deze notitie wordt ingegaan op de (functionele) inhoud van de testset en de aansluittoets. Hiermee wordt beoogd dat de gebruiker zich goed kan voorbereiden op de aansluittoets en het daarop volgend gebruik van de BV BSN.
Doelstelling aansluittoets
De aansluittoets biedt de waarborg voor de aansluitende gebruikers en voor de BV BSN dat bij aanvang van het BV BSN gebruik door de gebruiker de geteste functionaliteit werkt. Daarnaast wordt door de aansluittoets voorkomen dat de organisatie en systemen van de BV BSN in de productiesituatie onnodig worden belast door het aansluiten van slecht functionerende voorzieningen.
Achtergrond
In het najaar van 2007 is het Burgerservicenummer (BSN) ingevoerd. Het BSN is een uniek nummer, dat voor de meeste burgers gelijk is aan hun sofi-nummer. Het speelt binnen de gegevenshuishouding van de overheid een spilfunctie: persoonsgebonden gegevens kunnen doelmatig en – mits wettelijk toegestaan – betrouwbaar worden uitgewisseld tussen overheid en burger en tussen (semi-) overheidsorganisaties onderling. Om dit technisch mogelijk te maken is een systeem, de Beheervoorziening Burgerservicenummer (BV BSN), ingericht.
De BV BSN is het geheel van voorzieningen dat het genereren, distribueren, beheren en raadplegen van het BSN verzorgt. Daarnaast wordt met behulp van de beheervoorziening ook (geautoriseerd en op basis van een beperkt aantal vragen) toegang verkregen tot identificerende persoonsgegevens en kan worden gecontroleerd of identiteitsdocumenten die aan het loket worden gebruikt nog in omloop mogen zijn. Op deze wijze kan, aan het loket van een gebruiker van het BSN, de identiteit en BSN van een burger aan het loket betrouwbaar worden vastgesteld.
De BV BSN functioneert daarbij als een berichtenmakelaar; de informatie die vanuit diverse bronnen wordt betrokken wordt aan gebruikersystemen (wederom servers) doorgeven; er is dus geen rechtstreekse gebruikersinterface. Het systeem is ingericht op 24 uur gebruik per dag en 7 dagen per week. De Beheervoorziening spreekt XML/SOAP met haar gebruikers. In onderstaande figuur wordt de architectuur van de BV BSN weergegeven.
Gebruikers worden hierin per sector of organisatie aangesloten. Omdat de beheervoorziening uitsluitend in (synchrone) XML berichten spreekt is de gebruiker zelf verantwoordelijk voor opname in de gebruikersprocessen en het realiseren van een gebruikersinterface. Veelal zal hierbij een systeem dat de huidige processen ondersteund worden uitgebreid.
Een organisatie die een systeem gaat gebruiken dat de aansluiting op de BV BSN omvat zal deze willen testen en toetsen. Zo kan door de gebruiker worden vastgesteld of de aansluiting correct functioneert. Daarnaast toetst de beheerorganisatie van de BV BSN of de (nieuwe) aansluiting past op de interface en de integriteit van het systeem niet in gevaar brengt. Voor beide activiteiten stelt de beheerorganisatie van de BV BSN faciliteiten beschikbaar. In dit document worden de testset en de inhoud van de toets gedefinieerd.
De diensten van de BV BSN
Voor gebruikers biedt de BV BSN vijf diensten: vier rond BSN en de identificerende gegevens van een persoon en één over de geldigheid van een identiteitsdocument (van waaruit de identificerende gegevens bij voorkeur zijn overgenomen). Op hoofdlijnen (voor de details wordt verwezen naar het Logisch Ontwerp [1]) zien de diensten er als volgt uit:
- Toets BSN
De beheervoorziening BSN toetst of het opgegeven nummer voldoet aan de eisen voor het nummer én of het nummer daadwerkelijk “in verkeer” is.
- Haal identificerende gegevens op
De beheervoorziening BSN haalt op basis van het opgegeven BSN de identificerende gegevens van een persoon op.
- Opvragen BSN
Op basis van opgegeven identificerende persoonsgegevens haalt de BV BSN het BSN op. Dit lukt alleen maar als de opgegeven identificerende persoonsgegevens zodanig (onderscheidend) zijn dat één (en slechts één) persoon bij de gegevens wordt gevonden.
- Controleer nummer en identificerende gegevens
De BV BSN toetst of het opgegeven nummer een BSN is én of de bijbehorende persoonsgegevens overeenkomen (“matchen”) met de opgegeven identificerende gegevens.
- Toets identiteitsdocument
Op basis van een opgegeven documentnummer en documenttype achterhaalt de BV BSN of het document gebruikt kan worden als identiteitsdocument conform artikel 1 van de WID.
Beschrijving testset (voor stap 6 aansluitprocedure)
Om een goede test uit te kunnen voeren is het belangrijk om, vanuit een gegeven invoer, de uitkomst te voorspellen. Feitelijk is dat reeds voor enkele eenvoudige gevallen in de aansluittoets gedaan. Er is daarnaast voor gekozen om een beschrijving van de testset op te nemen. Hiermee kan, naar wens van de gebruiker, een groot aantal testscenario’s worden gemaakt. Het feit dat het hiervoor noodzakelijk is de werking van BV BSN enigszins te bestuderen wordt als pré beschouwd!
De gegevens uit deze testset zijn volledig gefingeerd. Ze vertonen derhalve geen enkele gelijkenis met personen die echt bestaan. In alle test- en toetsomgevingen van de BV BSN is gegarandeerd deze testset aanwezig. De inhoud van de testdatabase kun je opvragen via info@rvig.nl.
Beschrijving aansluittoets (stap 7 aansluitprocedure)
Met de aansluittoets wordt zeker gesteld dat de voorziening van de nieuwe BV BSN gebruiker aan een aantal minimale eisen voldoet. Gedacht wordt daarbij onder meer aan de vulling van verplichte velden. Doordat de gebruiker zelf verklaart dat de door zijn voorziening getoonde resultaten voldoen aan de uitvoervoorspelling wordt ervoor gezorgd dat een minimaal testproces plaatsvindt. De verwachting (en het advies) is dat veel organisaties er voor zullen kiezen hun voorzieningen veel uitgebreider te testen.
De testgevallen van de aansluittoets zijn beschreven in bijlage 1. Deze testgevallen kunnen ook als inspiratiebron dienen voor aanvullende testbeschrijvingen. Al voor de daadwerkelijke aansluittoets kunnen deze testen ook al worden uitgevoerd.
Bij de aansluittoets voert de aansluitende partij zelf de testen uit; vanuit de gegevens die in de logboeken worden opgeslagen kan de technisch contactpersoon van de BV BSN verklaren of aan de minimale eisen wordt voldaan. Zoals in de aansluitprocedure staat vermeld, moet je vooraf contact opnemen met de technisch contactpersoon van de beheerorganisatie beheervoorziening BSN om af te stemmen wanneer de aansluittoets zal gaan plaatsvinden. In die gevallen dat een gebruiker (gedurende de aansluitprocedure) heeft aangegeven niet alle 5 de diensten te gaan gebruiken kan worden volstaan met het toetsen van de wel te gebruiken diensten. Wordt in een later geval besloten om een dienst aan de gebruikersvoorziening toe te voegen dan dient voor deze dienst de aansluittoets alsnog te worden doorlopen.
Aanvullende informatie
Bijlage 1 Aansluittoets
In deze bijlage staan de testen die onderdeel uitmaken van de aansluittoets.
A. Toets BSN
Test A1 Veld | Invoer | Verwachte uitvoer |
BSN | 123456789 | |
Omschrijving resultaat | Nummer is geen BSN |
Test A2 Veld | Invoer | Verwachte uitvoer |
BSN | 999990068 | |
Omschrijving resultaat | Nummer is een BSN |
B. Haal identificerende gegevens op
Test B.1 Veld |
Invoer |
Verwachte Uitvoer |
BSN |
999990068 |
999990068 |
Voornamen |
|
Rozen |
Voorvoegsel geslachtsnaam |
|
|
Geslachtsnaam |
|
Groeman |
Geboortedatum |
|
19470909 |
Geboorteplaats |
|
's-Gravenhage |
Geboorteland |
|
Nederland |
Geslacht |
|
M |
Gemeente van inschrijving |
|
's-Gravenhage |
Straatnaam |
|
Zuiderparklaan |
Huisnummer |
|
12 |
Huisletter |
|
|
Huisnummer toevoeging |
|
|
Aanduiding bij huisnummer |
|
|
Postcode |
|
2574HA |
Locatiebeschrijving |
|
|
Land vanwaar ingeschreven |
|
|
Test B.2 Veld |
Invoer |
Verwachte Uitvoer |
BSN |
999990160 |
999990160 |
Voornamen |
|
Hendrik Jan |
Voorvoegsel geslachtsnaam |
|
de |
Geslachtsnaam |
|
Brink |
Geboortedatum |
|
19711213 |
Geboorteplaats |
|
Utrecht |
Geboorteland |
|
Nederland |
Geslacht |
|
M |
Gemeente van inschrijving |
|
Utrecht |
Straatnaam |
|
St. Jacobsstraat |
Huisnummer |
|
400 |
Huisletter |
|
L |
Huisnummer toevoeging |
|
Toe |
Aanduiding bij huisnummer |
|
|
Postcode |
|
3511BT |
Locatiebeschrijving |
|
|
Land vanwaar ingeschreven |
|
Zwitserland |
C. Opvragen BSN
Test C.1 Veld |
Invoer |
Verwachte Uitvoer |
BSN |
|
999990160 |
Voornamen |
|
Hendrik Jan |
Voorvoegsel geslachtsnaam |
|
de |
Geslachtsnaam |
Brink |
Brink |
Geboortedatum |
19711213 |
19711213 |
Geboorteplaats |
|
Utrecht |
Geboorteland |
|
Nederland |
Geslacht |
M |
M |
Gemeente van inschrijving |
|
Utrecht |
Straatnaam |
|
St. Jacobsstraat |
Huisnummer |
|
400 |
Huisletter |
|
L |
Huisnummer toevoeging |
|
Toe |
Aanduiding bij huisnummer |
|
|
Postcode |
|
3511BT |
Locatiebeschrijving |
|
|
Land vanwaar ingeschreven |
|
Zwitserland |
Test C.2 Veld |
Invoer |
Verwachte Uitvoer |
BSN |
|
999990160 |
Voornamen |
|
Hendrik Jan |
Voorvoegsel geslachtsnaam |
|
de |
Geslachtsnaam |
|
Brink |
Geboortedatum |
19711213 |
19711213 |
Geboorteplaats |
|
Utrecht |
Geboorteland |
|
Nederland |
Geslacht |
M |
M |
Gemeente van inschrijving |
|
Utrecht |
Straatnaam |
|
St. Jacobsstraat |
Huisnummer |
400 |
400 |
Huisletter |
|
L |
Huisnummer toevoeging |
|
Toe |
Aanduiding bij huisnummer |
|
|
Postcode |
3511BT |
3511BT |
Locatiebeschrijving |
|
|
Land vanwaar ingeschreven |
|
Zwitserland |
Test C.3 Veld |
Invoer |
Verwachte Uitvoer |
BSN |
|
999994931 |
Voornamen |
|
Jan |
Voorvoegsel geslachtsnaam |
|
de |
Geslachtsnaam |
Jager |
Jager |
Geboortedatum |
19701201 |
19701201 |
Geboorteplaats |
|
Hellevoetsluis |
Geboorteland |
|
Nederland |
Geslacht |
V |
V |
Gemeente van inschrijving |
|
Amsterdam |
Straatnaam |
|
Acacia |
Huisnummer |
|
55 |
Huisletter |
|
|
Huisnummer toevoeging |
|
|
Aanduiding bij huisnummer |
|
|
Postcode |
|
3224EA |
Locatiebeschrijving |
|
|
Land vanwaar ingeschreven |
|
|
Indicatie geheim |
|
Ja |
Test C.4 Veld |
Invoer |
Verwachte Uitvoer |
BSN |
|
|
Voornamen |
|
|
Voorvoegsel geslachtsnaam |
|
|
Geslachtsnaam |
Kooyman |
|
Geboortedatum |
20030303 |
|
Geboorteplaats |
|
|
Geboorteland |
|
|
Geslacht |
V |
|
Gemeente van inschrijving |
|
|
Straatnaam |
|
|
Huisnummer |
|
|
Huisletter |
|
|
Huisnummer toevoeging |
|
|
Aanduiding bij huisnummer |
|
|
Postcode |
|
|
Locatiebeschrijving |
|
|
Land vanwaar ingeschreven |
|
|
Melding |
|
Meerdere resultaten gevonden |
Resultaatcode |
|
23003 |
D. Controleer nummer en identificerende gegevens
Test D.1 Veld |
Invoer |
Verwachte Uitvoer |
BSN |
999994396 |
999994396 |
Voornamen |
|
Eisa |
Voorvoegsel geslachtsnaam |
|
von |
Geslachtsnaam |
Thursen |
Thursen |
Geboortedatum |
20000505 |
20000505 |
Geboorteplaats |
|
Hellevoetsluis |
Geboorteland |
|
Nederland |
Geslacht |
V |
V |
Gemeente van inschrijving |
|
Hellevoetsluis |
Straatnaam |
|
Cronus |
Huisnummer |
|
555 |
Huisletter |
|
|
Huisnummer toevoeging |
|
|
Aanduiding bij huisnummer |
|
|
Postcode |
|
3225TD |
Locatiebeschrijving |
|
|
Land vanwaar ingeschreven |
|
|
Test D.2 Veld |
Invoer |
Verwachte Uitvoer |
BSN |
999994396 |
999994396 |
Voornamen |
|
Eisa |
Voorvoegsel geslachtsnaam |
|
von |
Geslachtsnaam |
|
Thursen |
Geboortedatum |
20000505 |
20000505 |
Geboorteplaats |
|
Hellevoetsluis |
Geboorteland |
|
Nederland |
Geslacht |
V |
V |
Gemeente van inschrijving |
|
Hellevoetsluis |
Straatnaam |
|
Cronus |
Huisnummer |
555 |
555 |
Huisletter |
|
|
Huisnummer toevoeging |
|
|
Aanduiding bij huisnummer |
|
|
Postcode |
3225TD |
3225TD |
Locatiebeschrijving |
|
|
Land vanwaar ingeschreven |
|
|
Test D.3 Veld |
Invoer |
Verwachte Uitvoer |
BSN |
999990019 |
999990019 |
Voornamen |
|
Erebos |
Voorvoegsel geslachtsnaam |
|
|
Geslachtsnaam |
Bultenaar |
Bultenaar |
Geboortedatum |
20000401 |
20000401 |
Geboorteplaats |
|
Hellevoetsluis |
Geboorteland |
|
Nederland |
Geslacht |
M |
M |
Gemeente van inschrijving |
|
Hellevoetsluis |
Straatnaam |
|
Eik |
Huisnummer |
|
555 |
Huisletter |
|
|
Huisnummer toevoeging |
|
|
Aanduiding bij huisnummer |
|
|
Postcode |
|
3224TB |
Locatiebeschrijving |
|
|
Land vanwaar ingeschreven |
|
|
Gegevens in onderzoek |
|
Geboortedatum is in onderzoek (010310) |