Werkinstructie voorraadbeheer reisdocumenten en meldplicht bij vermissing

Voor leidinggevende medewerkers Burgerzaken

1. Telling van vooraad

Om fouten en fraude te voorkomen controleer je regelmatig op wisselende kantoordagen en tijdstippen de voorraad van paspoorten en identiteitskaarten in de kluis.

Doe de telling van de voorraad het liefst door meer dan één persoon.

Vergelijk de telling van aanwezige paspoorten en identiteitskaarten in de kluis met een actueel
overzicht aanwezige reisdocumenten uit het RAAS (Reisdocumenten Aanvraag- en Archiefstation).
 
Ga veilig om met een pincode, toegangspas of sleutel om de kluis te openen en registreer wie toegang heeft. Leg dit vast in een kluisbeleid: wie heeft wanneer toegang tot de kluis.

• Geef een geautisoriseerde medewerker een persoonlijke pincode of toegangspas.
• Bewaar een sleutel in een sleutelkluis.
• Neem geen sleutel of toegangspas mee naar huis.

2. Ontbreekt er een document in de kluis?

Doe altijd melding van vermissing bij de Rijksdienst voor Identiteitsgegevens en verzamel bewijsstukken.*

Vul het C7-formulier volledig in.
Dit formulier is te downloaden op rvig.nl.

Zijn er sporen van inbraak?
Doe aangifte bij de politie en vraag om een proces-verbaal.

Zijn er geen sporen van inbraak?

Maak een eigen een rapport op.

Mail het C7-formulier met een proces-verbaal of rapport naar de Rijksdienst voor Identiteitsgegevens (RvIG), via info@rvig.nl.

Het gemelde documentnummer wordt nationaal en internationaal gesignaleerd. Dit beperkt de risico’s van misbruik met het document.
Breng de houder van het vermiste document op de hoogte.

* Dit is een wettelijke verplichting (PUN, artikel 85 en 86 en Paspoortwet, artikel 4a lid 4)

Inleiding

De use case “Registreer nummertoekenning” beschrijft de stappen voor het registreren van een toekenning van een BSN. Het nummer is door de toekennende instantie toegekend aan een gerechtigde en is daarna niet meer beschikbaar als toe te kennen nummer.

In onderstaand model is de use case “Registreer nummertoekenning” weergegeven.

1. Hoofdscenario

1.1. Initiatie

1.1.1. Ontvang bericht “toekenning nummer”

De use case start met de ontvangst van het bericht “toekenning nummer”. In dit bericht staan de volgende gegevens:

Vraagbericht

Identificatie afzender

Berichtnummer afzender

Instantie

BSN

Datum-tijd van toekennen

1.1.2. Leg bericht “toekenning nummer” vast

Het BV BSN-berichtnummer wordt toegekend en het vraagbericht wordt vastgelegd in het berichtenlogboek. Zie use case “Leg bericht vast”.

1.1.3. Autoriseer verzoek

De autorisatie wordt aangevraagd en verleend. Zie “Autoriseer verzoek” (Zie alternatieve scenario´s 1).

1.2. Verwerking

1.2.1. Controleer bericht

Hier wordt gecontroleerd of de velden uit het vraagbericht goed gevuld zijn. De inhoud van het bericht moet voldoen aan de volgende eisen:

• De afzender moet gevuld zijn (zie ook Alternatieve scenario´s 2)
• Het berichtnummer van de afzender moet gevuld zijn (zie ook Alternatieve scenario´s 3)
• De instantie moet gevuld zijn (zie ook Alternatieve scenario´s 4)
• Het BSN moet gevuld zijn (zie ook Alternatieve scenario´s 5)
• Het BSN moet voldoen aan de 11-proef (zie ook Alternatieve scenario´s 6)

Daarnaast is het wenselijk dat de datum-tijd van toekennen juist is. (zie ook Alternatieve scenario’s 7)

1.2.2. Controleer validiteit toekenning

Het systeem controleert in het nummerregister of de toekenning valide is. De toekenning is valide als:

• het nummer in het nummerregister is geregistreerd en de status “gedistribueerd” heeft en
• de instantie die toegekend heeft (uit het vraagbericht) overeenkomt met het veld “instantie” uit het nummerregister (i.e., de toekennende instantie waaraan de batch met dit nummer is gedistribueerd).

De volgende alternatieve situaties worden onderkend:

• Het nummer is niet gevonden (zie Alternatieve scenario’s 8)
• De instantie van toekenning is niet valide (zie Alternatieve scenario’s 9)
• Het nummer heeft de status “aangemaakt (zie Alternatieve scenario’s 10)
• Het nummer heeft de status “in verkeer” (zie Alternatieve scenario’s 11)
• Het nummer heeft de status “uit verkeer” (zie Alternatieve scenario’s 12)

1.2.3. Registreer nummertoekenning

Voordat de wijziging in het nummerregister wordt doorgevoerd, wordt de oude situatie in de nummerhistorie vastgelegd.
Het systeem voert de mutatie in het nummerregister uit (Zie ook Alternatieve scenario´s 13):

• De status van het nummer wordt op “in verkeer” gezet;
• De datum/tijd van toekennen, zoals door de instantie in het vraagbericht meegegeven, wordt geregistreerd; (indien de tijd niet is aangeleverd wordt 00:00:00 vastgelegd)
• De registratie waarin de gegevens van dit nummer zijn opgenomen wordt geregistreerd. Deze wordt bepaald aan de hand van de identificatie van de afzender.
• Datum/tijd van wijziging.

1.3. Afronding

1.3.1. Stel antwoordbericht “toekenning nummer” samen

Het systeem stelt een antwoordbericht samen. In dit bericht staan de volgende gegevens:

Antwoordbericht

Berichtnummer afzender

BV BSN Berichtnummer

BSN

Berichtresultaatcode (5000)

Omschrijving berichtresultaat (“Nummertoekenning geregistreerd”)

1.3.2. Leg antwoordbericht “toekenning nummer” vast

Het antwoordbericht wordt vastgelegd in het berichtenlogboek. Zie use case “Leg bericht vast”.

1.3.3. Bied antwoordbericht “toekenning nummer” aan

Het antwoordbericht wordt aangeboden aan de actor.

1.3.4. Vul het auditlog

Het systeem registreert in het auditlog het resultaat van alle bovenstaande stappen. De volgende gegevens worden hierbij vastgelegd (Zie Alternatieve scenario´s 14):

Gegevens auditlog	Toelichting
Huidige datum en tijd	Systeemdatum-tijd
Identificatie afzender	DN uit het certificaat
BV BSN-berichtnummer	Het toegekende BV BSN berichtnummer
Berichtnummer afzender	Overnemen uit vraagbericht
Indicatie eindgebruiker/instantie	Overnemen uit vraagbericht
Uitgevoerde actie	de stap die uitgevoerd is
Resultaat van de uitgevoerde actie	Resultaat van de uitgevoerde stap
Resultaatcode	Berichtresultaatcode uit het antwoordbericht

2. Alternatieve Scenario’s

2.1. Alternatief 1: Autorisatie mislukt

Indien de autorisatie wordt geweigerd, wordt het volgende antwoordbericht verstuurd naar de afzender “Afzender niet geautoriseerd” (berichtresultaatcode 4). Daarnaast wordt een melding in het systeemfoutenlogboek opgenomen. Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.2. Alternatief 2: Identificatie afzender in vraagbericht is niet gevuld

Indien het veld Identificatie afzender van het vraagbericht niet gevuld is, wordt de volgende foutmelding naar de afzender verstuurd ”De afzender van het bericht moet gevuld zijn” (berichtresultaatcode 8). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.3. Alternatief 3: Berichtnummer afzender in vraagbericht is niet gevuld

Indien het veld berichtnummer afzender van het vraagbericht niet gevuld is, wordt de volgende foutmelding naar de afzender verstuurd ”Het berichtnummer van de afzender moet gevuld zijn” (berichtresultaatcode 9). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.4. Alternatief 4: Instantie in vraagbericht is niet gevuld

Indien het veld instantie van het vraagbericht niet gevuld is, wordt de volgende foutmelding naar de afzender verstuurd ”De instantie moet gevuld zijn” (berichtresultaatcode 5004). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.5. Alternatief 5: BSN is niet gevuld

Indien het veld BSN van het vraagbericht niet gevuld is, wordt de volgende foutmelding naar de afzender verstuurd “Het BSN moet gevuld zijn” (berichtresultaatcode 5002). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.6. Alternatief 6: BSN voldoet niet aan de 11-proef

Indien het opgegeven nummer niet aan de 11-proef voldoet, wordt de volgende melding naar de afzender verstuurd: “Nummer voldoet niet aan de 11-proef” (berichtresultaatcode 5007).
Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.7. Alternatief 7: Datum-tijd van toekenning is niet juist

Indien het veld datum-tijd van toekenning van het vraagbericht niet gevuld is of een onjuiste datum (bijvoorbeeld onjuist datumformaat of een datum in de toekomst) bevat, wordt een melding aan het nummerfoutenlogboek toegevoegd 

In het nummerfoutenlogboek worden de volgende gegevens opgenomen:

Gegevens nummerfoutenlogboek	Toelichting
Foutnummer	Uniek volgnummer
BV BSN-Berichtnummer	Nummer van het bericht waarbij de fout optrad
BSN	BSN waar de fout betrekking op heeft
Indicatie van de fout	“Datum-tijd van toekenning is niet juist”
Datum/tijd	Datum tijd van constatering van de fout
Status van de verwerking van de fout	Open

Indien het nummerfoutenlogboek niet gevuld kan worden, wordt een melding  in het systeemfoutenlogboek opgenomen. Dit heeft verder geen invloed op de verwerking van het bericht.

Hierna wordt verdergegaan met de verwerking. Als het nummerregister wordt gemuteerd ten behoeve van de toekenning, wordt de datum niet gevuld.

2.8. Alternatief 8: Het nummer is niet gevonden

Het nummer in het aangeleverde bericht is niet aanwezig in BV BSN en kan dus niet toegekend worden. De volgende melding wordt verstuurd naar de afzender “Het opgegeven nummer bestaat niet” (berichtresultaatcode 5003).
Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.9. Alternatief 9: Instantie van toekenning niet valide

Indien de instantie van toekenning ongelijk is aan de instantie waaraan het nummer is gedistribueerd, wordt volgende melding wordt verstuurd naar de afzender “De instantie van toekennen moet gelijk zijn aan de instantie waaraan het nummer is gedistribueerd” (berichtresultaatcode 5005).
Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.10. Alternatief 10: Nummer heeft status aangemaakt

Indien het nummer de status ‘aangemaakt’ heeft, wordt de melding “Het opgegeven nummer kan niet in verkeer worden genomen” (berichtresultaatcode 5006) in het antwoordbericht opgenomen.
Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.11. Alternatief 11: Nummer heeft status in verkeer

Indien het nummer de status ‘in verkeer’ heeft, wordt de melding “Het opgegeven nummer is reeds in verkeer” (berichtresultaatcode 5001) in het antwoordbericht opgenomen.
Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.12. Alternatief 12: Nummer heeft status uit verkeer

Indien het nummer de status ‘uit verkeer’ heeft, wordt de melding “Het opgegeven nummer kan niet in verkeer worden genomen” (berichtresultaatcode 5006) in het antwoordbericht opgenomen.
Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.13. Alternatief 13: Fout bij registreren van nummertoekenning

Indien er een fout optreedt bij het registreren van de nummertoekenning, wordt de melding ”Er is een fout opgetreden” (berichtresultaatcode 2) verstuurd naar de afzender. Het nummerregister wordt teruggebracht in de toestand, zoals die was voor de start van de verwerking van het bericht  Daarnaast wordt  een melding  aan het systeemfoutenlogboek toegevoegd.
Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.14. Alternatief 14: Fout bij vullen auditlog 

Indien het auditlog niet gevuld kan worden, wordt een melding  in het systeemfoutenlogboek opgenomen. Aan de afzender van het bericht wordt de melding "Er is een fout opgetreden" (berichtresultaatcode 2) verstuurd. De verwerking van het bericht zal stoppen.
Indien het tussenstappen betreft wordt direct verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen. 
Indien het de laatste stap betreft, zal wel de beheerorganisatie, maar niet de afzender hierover geïnformeerd worden.

3. Subprocessen

Niet van toepassing.

4. Belangrijke scenario’s

Niet van toepassing.

5. Precondities

• De actor die het bericht verstuurt, is geauthenticeerd (zie use case: authenticeren).

6. Postcondities

• Alle ondernomen acties zijn vastgelegd in het auditlog;
• Er is een antwoordbericht verstuurd naar de actor.

7. Extensies

Niet van toepassing.

8. Speciale eisen

Niet van toepassing.

9. Aanvullende Informatie

9.1. Activiteitendiagram

Download PDF

Inleiding

De use case “Haal op set identificerende gegevens” beschrijft de stappen voor het ophalen van een unieke set identificerende gegevens uit de registratie GBA of RNI, behorende bij een BSN.
In onderstaand model is de use case “Haal op set identificerende gegevens” weergegeven.

1. Hoofdscenario

1.1. Initiatie

1.1.1. Ontvang bericht “Haal op set identificerende gegevens”

De use case start met de ontvangst van het bericht “Haal op set identificerende gegevens”. In dit bericht staan de volgende gegevens:

Vraagbericht

Algemeen deel

Identificatie afzender

Berichtnummer afzender

Indicatie eindgebruiker

1 of meerdere vragen

Vraagnummer

BSN

1.1.2. Leg bericht “Haal op set identificerende gegevens” vast

Het BV BSN-berichtnummer wordt toegekend en het vraagbericht wordt vastgelegd in het berichtenlogboek. Zie use case “Leg bericht vast”.

1.1.3. Autoriseer verzoek

De autorisatie wordt aangevraagd en verleend. Zie use case “Autoriseer verzoek” (zie ook Alternatieve scenario´s 1).

1.2. Verwerking

1.2.1. Controleer bericht

Het bericht moet voldoen aan de volgende eisen:

• Het vraagnummer moet bij 1 beginnen (zie Alternatieve scenario’s 2)
• De vraagnummers moeten oplopend zijn (zie Alternatieve scenario’s 3)
• Het bericht moet minimaal één vraag bevatten (zie Alternatieve scenario’s 4)
• Het bericht mag niet meer vragen bevatten dan het toegestane maximum, waarbij dit maximum een instelbare waarde heeft en initieel wordt ingesteld op 1 (zie Alternatieve scenario’s 5)
• De afzender moet gevuld zijn (zie Alternatieve scenario’s 6)
• Het berichtnummer van de afzender moet gevuld zijn (zie Alternatieve scenario’s 7)
• De indicatie eindgebruiker moet gevuld zijn (zie Alternatieve scenario’s 8)
• De vraagnummers moeten gevuld zijn (zie Alternatieve scenario’s 9)

De volgende stappen (zie activiteitendiagram) worden voor iedere vraag in het bericht herhaald.

1.2.2. Controleer nummer

Het opgegeven BSN wordt gecontroleerd en moet voldoen aan de volgende eisen:

• Het BSN moet gevuld zijn (zie Alternatieve scenario’s 10)
• Het BSN moet voldoen aan de 11-proef (zie Alternatieve scenario’s 11)
• Het BSN moet in verkeer zijn bij GBA of RNI (zie Alternatieve scenario’s 11)

1.2.3. Bepaal registratie

Aan de hand van het opgegeven BSN wordt in het nummerregister bepaald bij welke registratie (GBA of RNI) de identificerende gegevens moeten worden opgehaald.

1.2.4. Haal op set identificerende gegevens

Het systeem raadpleegt de registratie die in de vorige stap is bepaald. (zie ook Alternatieve scenario´s 12).

De volgende gegevens worden uit de registratie opgehaald:

Gegevens uit registratie

BSN

Voornamen

Adellijke titel/predikaat

Voorvoegsels geslachtsnaam

Geslachtsnaam

Geboortedatum

Geboorteplaats

Geboorteland

Geslachtsaanduiding

Aanduiding gegevens in onderzoek persoon

Datum ingang onderzoek persoon

Datum einde onderzoek persoon

Datum overlijden

Aanduiding gegevens in onderzoek overlijden

Datum ingang onderzoek overlijden

Datum einde onderzoek adres

Omschrijving reden opschorting

Indicatie geheim

Gemeente van inschrijving

Functie adres

Gemeentedeel

Straatnaam

Huisnummer

Huisletter

Huisnummertoevoeging

Aanduiding bij huisnummer

Postcode

Woonplaatsnaam

Locatiebeschrijving

LandAdresBuitenland

DatumAanvangAdresBuitenland

Regel1AdresBuitenland

Regel2AdresBuitenland

Regel3AdresBuitenland

Land vanwaar ingeschreven

Aanduiding gegevens in onderzoek adres

Datum ingang onderzoek adres

Datum einde onderzoek adres

1.2.5. Controleer zoekresultaat

Hierna worden de volgende situaties onderscheiden:

• Als er één resultaat gevonden is, worden de gevonden identificerende gegevens teruggemeld.
• Als er meerdere resultaten gevonden zijn, wordt dit gemeld aan de afzender en wordt er een fout naar het nummerfoutenlogboek gestuurd (zie ook Alternatieve scenario’s 13)
• Als er geen resultaat gevonden is, wordt dit teruggemeld aan de afzender (Zie ook Alternatieve scenario´s 13).

1.3. Afronding

1.3.1. Stel antwoordbericht “Haal op set identificerende gegevens” samen

In onderstaande tabel wordt beschreven welke gegevens in het antwoordbericht zijn opgenomen.

Antwoordbericht

Algemeen deel

Berichtnummer afzender

BV BSN Berichtnummer

Berichtresultaatcode (3000)

Omschrijving berichtresultaat (“Verwerking bericht succesvol”)

1 of meerdere antwoorden

Vraagnummer

Resultaatcode (3002)

Omschrijving resultaat (“Resultaat gevonden”)

BSN

Voornamen

Adellijke titel/predikaat

Voorvoegsels geslachtsnaam

Geslachtsnaam

Geboortedatum

Geboorteplaats

Geboorteland

Geslachtsaanduiding

Aanduiding gegevens in onderzoek persoon

Datum ingang onderzoek persoon

Datum overlijden

Aanduiding gegevens in onderzoek overlijden

Datum ingang onderzoek overlijden

Omschrijving reden opschorting

Indicatie geheim

Gemeente van inschrijving1

FunctieAdres1

Gemeentedeel1

Straatnaam1

Huisnummer1

Huisletter1

Huisnummertoevoeging1

Aanduiding bij huisnummer1

Postcode1

Woonplaatsnaam1

Locatiebeschrijving1

LandAdresBuitenland2

DatumAanvangAdresBuitenland2

Regel1AdresBuitenland2

Regel2AdresBuitenland2

Regel3AdresBuitenland2

Land vanwaar ingeschreven1

Aanduiding gegevens in onderzoek adres1

Antwoordbericht

Datum ingang onderzoek adres1

In de volgende gevallen zal geen volledige set van identificerende gegevens in het antwoordbericht worden opgenomen:

• Als in de registratie de omschrijving reden opschorting gelijk is aan “E” (emigratie) of “M” (ministerieel besluit) of gemeente van inschrijving = “Registratie Niet Ingezetenen (RNI) “, worden de binnenlandse verblijfplaatsgegevens (aangeduid met “1”) niet in het antwoordbericht opgenomen.
• Als in de registratie de gemeente van inschrijving is ongelijk aan “Registratie Niet Ingezetenen (RNI) “, worden de buitenlandse verblijfplaatsgegevens (aangeduid met “2”) niet in het antwoordbericht opgenomen.
• Als in de registratie de indicatie geheim ongelijk is aan “0”, worden de verblijfplaatsgegevens (aangeduid met “1” en “2” ) niet in het antwoordbericht opgenomen.

Als in de registratie de datum ingang onderzoek is gevuld en de datum einde onderzoek niet is gevuld, dan betekent dit dat de betreffende gegevens in onderzoek zijn. De aanduiding gegevens in onderzoek is dan gevuld. In alle andere gevallen betekent het dat de betreffende gegevens niet in onderzoek zijn. De datum ingang onderzoek en de aanduiding gegevens in onderzoek worden dan niet in het antwoordbericht opgenomen.

Het veld indicatie geheim wordt in het antwoordbericht als volgt opgenomen:

• Indien indicatie geheim = 0, dan wordt “Nee” opgenomen in het antwoordbericht.
• Indien indicatie geheim <> 0, dan wordt “Ja” opgenomen in het antwoordbericht.

1.3.2. Leg antwoordbericht “Haal op set identificerende gegevens” vast

Het antwoordbericht wordt vastgelegd in het berichtenlogboek. Zie use case “Leg bericht vast”.

1.3.3. Bied antwoordbericht “Haal op set identificerende gegevens” aan

Het bericht wordt aangeboden aan de afzender.

1.3.4. Vul het auditlog

Het systeem registreert in het auditlog het resultaat van alle bovenstaande stappen. De volgende gegevens worden hierbij vastgelegd (Zie ook Alternatieve scenario´s 14):

Gegevens auditlog	Toelichting
Huidige datum en tijd	Systeemdatum-tijd
Identificatie afzender	DN uit het certificaat
BV BSN-berichtnummer	Het toegekende BV BSN berichtnummer
Berichtnummer afzender	Overnemen uit vraagbericht
Indicatie eindgebruiker/instantie	Overnemen uit vraagbericht
Uitgevoerde actie	de stap die uitgevoerd is

Gegevens auditlog

Toelichting

Resultaat van de uitgevoerde actie	Resultaat van de uitgevoerde stap
Resultaatcode	Berichtresultaatcode uit het antwoordbericht

Wanneer alle stappen met succes zijn doorlopen, worden de voorkomens van de betreffende stappen in het auditlog verwijderd. Van het verwerkte bericht wordt één nieuw voorkomen aangemaakt met de volgende gegevens:

Gegevens auditlog	Toelichting
Huidige datum en tijd	Datum-tijd van de eerste stap van het auditlog van betreffende bericht
Identificatie afzender	DN uit het certificaat
BV BSN-berichtnummer	Het toegekende BV BSN berichtnummer
Berichtnummer afzender	Overnemen uit vraagbericht
Indicatie eindgebruiker/instantie	Overnemen uit vraagbericht
Uitgevoerde actie	“Bericht verwerkt”
Resultaat van de uitgevoerde actie	“Succesvol
Resultaatcode	Berichtresultaatcode uit het antwoordbericht

2. Alternatieve scenario’s

2.1. Alternatief 1: Autorisatie mislukt

Indien de autorisatie wordt geweigerd, wordt het volgende antwoordbericht verstuurd naar de afzender “Afzender niet geautoriseerd” (berichtresultaatcode 4). Daarnaast wordt een melding in het systeemfoutenlogboek opgenomen. Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.2. Alternatief 2: Vraagnummer begint niet bij nummer 1

Indien de vraagnummer niet bij nummer 1 begint, wordt het volgende antwoordbericht verstuurd naar de afzender “Vraagnummer begint niet bij 1” (berichtresultaatcode 13). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.3. Alternatief 3: Vraagnummers zijn niet oplopend

Indien de nummering van vraagnummers niet oplopend +1 zijn, wordt het volgende antwoordbericht verstuurd naar de afzender “Vraagnummers zijn niet oplopend” (berichtresultaatcode 14). Hierna wordt verder gegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.4. Alternatief 4: Bericht bevat geen vragen

Indien het inkomende bericht geen vragen bevat, wordt de volgende foutmelding naar de afzender verstuurd ”Het bericht moet minimaal één vraag bevatten” (berichtresultaatcode 7). Hierna wordt verder gegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.5. Alternatief 5: Bericht bevat teveel vragen

Indien het inkomende bericht meer dan n vragen bevat, wordt de volgende foutmelding naar de afzender verstuurd “Het bericht bevat meer vragen dan het toegestane maximum” (berichtresultaatcode 6). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.6. Alternatief 6: Identificatie afzender in vraagbericht is niet gevuld

Indien het veld Identificatie afzender van het vraagbericht niet gevuld is, wordt de volgende foutmelding naar de afzender verstuurd ”De afzender van het bericht moet gevuld zijn” (berichtresultaatcode 8). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.7. Alternatief 7: Berichtnummer afzender in vraagbericht is niet gevuld

Indien het veld berichtnummer afzender van het vraagbericht niet gevuld is, wordt de volgende melding naar de afzender verstuurd ”Het berichtnummer van de afzender moet gevuld zijn” (berichtresultaatcode 9). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.8. Alternatief 8: Indicatie eindgebruiker in vraagbericht is niet gevuld

Indien het veld indicatie eindgebruiker van het vraagbericht niet gevuld is, wordt de volgende melding naar de afzender verstuurd ”De indicatie eindgebruiker van het bericht moet gevuld zijn” (berichtresultaatcode 10). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.9. Alternatief 9: Een of meer vraagnummers niet ingevuld

Indien een of meer vraagnummers niet ingevuld zijn, wordt de volgende melding naar de afzender verstuurd “De vraagnummers moeten gevuld zijn” (berichtresultaatcode 11). Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.10. Alternatief 10: BSN is niet gevuld

Indien het veld BSN van het vraagbericht niet gevuld is, wordt de volgende melding naar de afzender verstuurd ”BSN moet gevuld zijn” (resultaatcode 3004). Hierna wordt verdergegaan met de volgende vraag, indien deze aanwezig is.

2.11. Alternatief 11: Fout bij controleren van het nummer

Indien er een fout is opgetreden bij het controleren van het nummer, wordt de volgende melding naar de afzender verstuurd “Nummer is geen BSN” (resultaatcode 3003). Hierna wordt verdergegaan met de volgende vraag, indien deze aanwezig is.

2.12. Alternatief 12: Fout bij ophalen gegevens

Indien er een fout optreedt bij het ophalen van de gegevens uit de registratie, wordt de melding ”Er is een fout opgetreden” (berichtresultaatcode 2) in het antwoordbericht verstuurd naar de afzender.
Daarnaast wordt een melding in het systeemfoutenlogboek opgenomen  Hierna wordt verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.

2.13. Alternatief 13: Geen of meerdere resultaten gevonden

Als er geen of meerdere resultaten gevonden zijn, wordt de melding “Vraag heeft niet tot één persoon geleid” in het antwoordbericht opgenomen (resultaatcode 3001).
Indien er sprake is van de volgende situaties, wordt een fout aan het nummerfoutenlogboek toegevoegd:

• het BSN komt voor in het nummerregister en is “in verkeer” en
• het BSN is meerdere keren aangetroffen in de registratie die vermeld staat in het nummerregister

De volgende gegevens met betrekking tot het foutvermoeden worden opgenomen in het nummerfoutenlogboek:

Gegevens nummerfoutenlogboek	Toelichting
Foutnummer	Uniek volgnummer
BV BSN-Berichtnummer	Nummer van het bericht waarbij de fout optrad
BSN	BSN waar de fout betrekking op heeft
Indicatie van de fout	“BSN komt meerdere malen voor in registratie”
Datum/tijd	Datum tijd van constatering van de fout
Status van de verwerking van de fout	Open

Indien het nummerfoutenlogboek niet gevuld kan worden, wordt een melding in het systeemfoutenlogboek opgenomen. Dit heeft verder geen invloed op de verwerking van het bericht.

Hierna wordt verdergegaan met de volgende vraag, indien deze aanwezig is.

2.14. Alternatief 14: Fout bij vullen auditlog

Indien het auditlog niet gevuld kan worden, wordt een melding  in het systeemfoutenlogboek opgenomen en moet de verwerking van het bericht stoppen. Aan de afzender van het bericht wordt de melding "Er is een fout opgetreden" (berichtresultaatcode 2) verstuurd.
Indien het tussenstappen betreft wordt direct verdergegaan met de afronding, waarbij in het antwoordbericht de genoemde berichtresultaatcode en omschrijving worden opgenomen.
Indien het de laatste stap betreft, zal wel de beheerorganisatie, maar niet de afzender hierover geïnformeerd worden.

3. Subprocessen

Niet van toepassing.

4. Belangrijke scenario’s

Niet van toepassing.

5. Precondities

• De afzender die het bericht verstuurt is geauthenticeerd (zie use case: authenticeren).

6. Postcondities

• Alle ondernomen acties zijn vastgelegd in het auditlog;
• Er is een antwoordbericht verstuurd naar de afzender.

7. Extensies

Niet van toepassing.

8. Speciale eisen

Niet van toepassing.

9. Aanvullende informatie

9.1. Activiteitendiagram

Download PDF

1. Inleiding

Dit document geeft een overzicht van de gewenste functionaliteit van de BV BSN en een korte omschrijving daarvan. De gewenste functionaliteit is uitwerkt in use-casebeschrijvingen. In hoofdstuk 2 is op globaal niveau de functionaliteit uitgewerkt in een use-casemodel. Van deze use cases is op globaal niveau in onderliggende paragrafen een beschrijving gemaakt.
Een nadere uitwerking van de use case in een basis flow en een alternatieve flow is te vinden in de use-casespecificaties.

1.1. Definities

Zie de BSN glossary.

1.2. Referenties

De BV BSN kent de volgende use-casespecificaties:

• UC02 Controleer BSN en identificerende gegevens
• UC03 Haal op set identificerende gegevens
• UC04 Distribueer nummer
• UC05 Registreer nummertoekenning
• UC06 Hang registratie om bij BSN
• UC07 Ophalen berichten uit berichtenlogboek
• UC08 Vraag auditgegevens op
• UC11 Nummer uit verkeer halen
• UC12 Match identificerende gegevens
• UC13 Opschonen loggegevens
• UC16 Toets of het nummer een BSN is (voorheen Zoek nummer)
• UC17 Authenticeren
• UC18 Autoriseer verzoek
• UC19 Leg bericht vast
• UC21 Registreren opgewaardeerd Sofi-nummer
• UC22 Registreren instantiewijziging
• UC23 Opvragen BSN op basis van identificerende gegevens
• UC24 Verificatie van identiteitsdocumenten
• UC25 Periodieke controle nummers (in bewerking)
• UC26 Vastleggen protocolgegevens
• UC27 Genereren nummers
• UC28 Ophalen nummergegevens
• UC29 Ophalen nummerfouten uit het nummerfoutenlogboek
• UC30 Ophalen protocolgegevens
• UC31 Vastleggen autorisatiegegevens
• UC32 Vastleggen foutvermoeden
• UC33 Stellen bulkvraag
• UC34 Ophalen antwoord bulkvraag
• UC35 Opvragen BSN t.b.v. schoning en initiële vulling
• UC37 Verwerken bulkvraag
• UC38 Detecteren misbruik
• UC39 Doorvoeren correctie nummerregister

2. Functionaliteit BV BSN

2.1. Globale use case beschrijving

In onderstaande paragrafen is de benoemde functionaliteit in het use case model uitgewerkt. Een gedetailleerde uitwerking van de scenario’s is te vinden in de use case specificatie van betreffende use case. Een use case specificatie bevat altijd een hoofdscenario waarin alles goed gaat om het doel te bereiken. Daarnaast kunnen er alternatieve scenario’s zijn die afwijkingen van het hoofdscenario beschrijven, bijvoorbeeld als er iets mis gaat, en aangeven hoe een actor het doel op alternatieve wijzen kan realiseren. In onderstaande paragrafen is een globale beschrijving van de use cases opgenomen.

2.1.1. UC02 Controleer BSN en identificerende gegevens

De use case “Controleer BSN en identificerende gegevens” beschrijft de stappen voor het controleren of de set van identificerende gegevens uit de registratie GBA of RNI, behorende bij het opgegeven BSN, overeenkomt met de opgegeven set identificerende gegevens uit het bericht.

2.1.2. UC03 Haal op set identificerende gegevens

De use case “Haal op set identificerende gegevens” beschrijft de stappen voor het ophalen van een unieke set identificerende gegevens uit de registratie GBA of RNI, behorende bij een BSN.

2.1.3. UC04 Distribueer nummer

De use case “Distribueer nummer” beschrijft de stappen van het genereren en distribueren van nummers in batches aan de actoren BC GBA, en BC RNI.

2.1.4. UC05 Registreer nummertoekenning

De use case “Registreer nummertoekenning” beschrijft de stappen voor het registreren van een toekenning van een BSN. Het nummer is door de toekennende instantie toegekend aan een gerechtigde en is daarna niet meer beschikbaar als toe te kennen nummer.

2.1.5. UC06 Hang registratie om bij BSN

De use case “Hang registratie om bij BSN” beschrijft de stappen voor het omhangen van een registratie bij een BSN. Bij het omhangen van een BSN, wordt in het nummerregister de registratie waarin de gegevens van een persoon zijn opgenomen, gewijzigd (bijvoorbeeld een wijziging van RNI naar GBA).

2.1.6. UC07 Ophalen berichten uit berichtenlogboek

De use case “Ophalen berichten uit berichtenlogboek” beschrijft de stappen voor het opvragen van de gegevens uit het berichtenlogboek die in de BV BSN zijn vastgelegd.
De beheerorganisatie BV BSN en het Foutenmeldpunt kunnen gegevens uit het berichtenlogboek opvragen.

2.1.7. UC08 Vraag auditgegevens op

De use case “Vraag auditgegevens op” beschrijft de stappen voor het opvragen van auditgegevens die in het auditloboek van de BV BSN zijn vastgelegd. In alle use cases is beschreven dat elke stap die door de BV BSN wordt verricht in een auditlog wordt vastgelegd. Hierdoor is het mogelijk te bepalen welke stappen een bericht heeft doorlopen en wat het resultaat van de verwerking is geweest.
De beheerorganisatie van de BV BSN kan de auditgegevens van de berichten opvragen.

2.1.8. UC11 Nummer uit verkeer halen

De use case “Nummer uit verkeer halen” beschrijft de stappen voor het uit verkeer halen van een BSN.

2.1.9. UC12 Match identificerende gegevens

De use case “Match identificerende gegevens” beschrijft de stappen voor het zoeken naar het bestaan van een BSN of SoFi-nummer op basis van een set identificerende gegevens. Aan de hand van de opgegeven identificerende gegevens wordt aan verschillende registraties gevraagd of er personen staan geregistreerd die “matchen” met die gegevens.

2.1.10. UC13 Opschonen gegevens

De use case “Opschonen gegevens” beschrijft de stappen voor het opschonen van berichten/gegevens uit de volgende logboeken:

• Schonen berichtenlogboek
• Schonen nummerfoutenlogboek
• Schonen protocollogboek
• Schonen auditlogboek

2.1.11. UC16 Toets of nummer een BSN is

De use case “Toets of nummer een BSN is” beschrijft de stappen voor het zoeken van een nummer in de BV BSN. Aan de hand van het opgegeven nummer wordt gezocht of een toegekend nummer overeenkomt met het opgegeven nummer. Het zoeken vindt dus niet plaats in de registraties, maar in het BV BSN register zelf.

2.1.12. UC17 Authenticeren

De use case “Authenticeren” beschrijft de stappen voor het authenticeren van een gebruiker van de BV BSN.

2.1.13. UC18 Autoriseer verzoek

De use case “Autoriseer verzoek” beschrijft de stappen voor het bepalen van de autorisatie van een verzoek in de BV BSN.
Autoriseren is het al of niet toekennen van bepaalde rechten aan een gebruiker of een systeem waarvan de identiteit is vastgesteld. Het vaststellen van de identiteit van een gebruiker of een systeem wordt het ‘authenticeren’ (zie UC 17) genoemd.

2.1.14. UC19 Leg bericht vast

De use case “Leg bericht vast” beschrijft de stappen voor het vastleggen van een bericht in het berichtenlogboek. Het kan hierbij gaan om een vraag- of een antwoordbericht. Dit wordt bepaald door de stap van de use case, waarin deze use case leg bericht vast wordt aangeroepen.

2.1.15. UC21 Registreren opgewaardeerd sofi-nummer

De use case “Registreren opgewaardeerd sofi-nummer” beschrijft de stappen voor het registreren van een tot BSN opgewaardeerd sofi- nummer. In onderstaand model is de use case “Registreren opgewaardeerd Sofi-nummer” weergegeven.

2.1.16. UC22 Registreren instantiewijziging

De use case “Registreren instantiewijziging” beschrijft de stappen voor wijzigen van de instantie, waaraan een BSN is toegekend, naar een andere instantie (bijvoorbeeld bij een herindeling of splitsing van een gemeente.)

2.1.17. UC23 Opvragen BSN op basis van identificerende gegevens

De use case “Opvragen BSN op basis van identificerende gegevens” stelt gebruikers in staat om op basis van een minimale set van identificerende gegevens een BSN op te vragen.

2.1.18. UC24 Verificatie van identiteitsdocumenten

De use case “Verificatie van identiteitsdocumenten” beschrijft de stappen voor het valideren van de geldigheid van een documentnummer.

2.1.19. UC25 Periodieke controle nummers

De use case “Periodieke controleren nummerregister” beschrijft de stappen voor het periodiek controleren van burgerservicenummers en Sofi-nummers.

2.1.20. UC26 Vastleggen protocolgegevens

De use case “Vastleggen protocolgegevens” beschrijft de stappen voor het bijhouden van protocolgegevens. Hierbij worden alle gegevensverstrekkende acties voor ieder BSN geregistreerd en vastgelegd.

2.1.21. UC27 Genereren nummers

De use case “Genereren nummers” beschrijft het proces waarbij nieuwe nummers die kunnen worden toegekend als Burgerservicenummer worden gegenereerd en in het register worden opgenomen.

2.1.22. UC28 Ophalen nummergegevens

De use case “Ophalen nummergegevens” beschrijft de stappen voor het ophalen van de gevraagde nummergegevens die in de BV BSN zijn vastgelegd. De beheerorganisatie BV BSN en het Foutenmeldpunt kunnen gegevens uit het nummerregister opvragen.

2.1.23. UC29 Ophalen nummerfouten uit het nummerfoutenlogboek

De use case “Ophalen nummerfouten uit het nummerfoutenlogboek” beschrijft de stappen van het doorgeven van nummerfouten aan het Foutenmeldpunt. De nummerfouten worden opgehaald uit het nummerfoutenlogboek. De bevraging vanuit het foutenmeldpunt wordt periodiek uitgevoerd. Gezien de BV BSN niet op de hoogte is van deze periode wordt deze meegegeven in het vraagbericht (begin- en einddatum), zodoende worden alleen gegevens van een bepaalde periode opgehaald waarbij de status van de foutmelding “Open” is. Voor de meldingen die worden doorgegeven wijzigt de status naar “Doorgegeven aan Foutenmeldpunt”.

2.1.24. UC30 Ophalen protocolgegevens

De use case “Ophalen protocolgegevens” beschrijft de stappen voor het opvragen van protocolgegevens die in het protocollogboek van de BV BSN zijn vastgelegd. De beheerorganisatie van de BV BSN kan het protocollog opvragen.

2.1.25. UC31 Vastleggen autorisatiegegevens

De use case “Vastleggen autorisatiegegevens” beschrijft de stappen voor het vastleggen van autorisatiegegevens in de BV BSN.
De gegevens worden door de beheerorganisatie van de BV BSN opgegeven.

2.1.26. UC32 Vastleggen foutvermoeden

De use case “Vastleggen foutvermoeden” beschrijft de stappen voor het melden van een foutvermoeden door een beheercomponent. Deze worden vastgelegd in het nummerfoutenlogboek

2.1.27. UC33 Stellen bulkvraag

De use case “Stellen bulkvraag” stelt gebruikers in staat om meerdere vragen met betrekking tot het opvragen van het BSN op basis van identificerende gegevens. De gebruiker krijgt een behandelnummer terug en kan later op basis van dit behandelnummer het antwoord op de bulkvraag ophalen. Het betreft hier een tijdelijke dienst van de BV BSN.

2.1.28. UC34 Ophalen antwoord bulkvraag

De use case “Ophalen antwoord bulkvraag” stelt gebruikers in staat om antwoord te krijgen op de eerder gestuurde bulkvraag om bij de opgegeven identificerende gegevens het BSN te zoeken (zie UC33) middels het behandelnummer.
Het betreft hier een tijdelijke dienst van de BV BSN.

2.1.29. UC35 Opvragen BSN t.b.v. schoning en initiële vulling

De use case “Opvragen BSN t.b.v. schoning en initiële vulling” stelt gebruikers in staat om op basis van een minimale set van identificerende gegevens een BSN op te vragen. Het betreft hier een tijdelijke dienst van de BV BSN.

2.1.30. UC37 Verwerken bulkvraag

De use case “Verwerken bulkvraag” verwerkt de gestelde bulkvraag (zie BV BSN UC34) op een door het systeem bepaald moment. Hierna wordt het antwoord op de bulkvraag klaargezet, zodat dit kan worden opgehaald (zie BV BSN UC35).
Het betreft hier een tijdelijke dienst van de BV BSN.

2.1.31. UC38 Detecteren misbruik

De use case “Detecteren misbruik” bewaakt het berichtenverkeer en signaleert uitzonderingssituaties aan de beheerorganisatie BV BSN.

2.1.32. UC39 Doorvoeren correctie nummerregister

De use case “Doorvoeren correctie nummerregister” beschrijft de stappen voor het corrigeren van een record in het nummerregister. De beheerorganisatie BV BSN kan een correctie doorvoeren.

Download PDF

1 Probleemstelling

1.1 Omschrijving

In de loop van de jaren zijn er verschillen ontstaan in de kolomnamen van de landelijke tabellen, tussen de benaming van de rubrieken in het LO, de kolomkoppen in de CSV-versie van de tabellen en die in de PDF-versie ervan. Vanwege de beperkte ruimte in PDF-bestanden is het logisch dat kolomnamen daarin worden afgekort, maar dat gebeurt niet overal op een consistente wijze. In een enkel geval is ook de rubrieknaam in het LO niet logisch.

1.2 Herkomst

Dit probleem is geconstateerd door het LO-team.

1.3 Raakvlakken

Er zijn geen raakvlakken met andere LO-wijzigingen.

2 Oplossing

2.1 Huidige situatie

Er zijn een aantal problemen met de kolomnamen in de landelijke tabellen:

• De gekozen naam voor de rubriek is niet heel logisch of bevat nutteloze toevoegingen. Voorbeeld: 05.12 Officiële omschrijving nationaliteit. "Officiële" voegt hier niets toe.
• De kolomnaam in de CSV-versie van een tabel komt niet overeen met de rubrieknaam in het LO. Voorbeeld: 33.92.11 "Omschrijving" in de CSV van tabel 33 Gemeententabel is niet gelijk aan 33.92.11 "Officiële gemeentenaam" in het LO.
• De kolomnaam in de PDF-versie van een tabel komt niet overeen met de rubrieknaam in het LO. Voorbeeld: "Omschrijving" in de PDF-versie van tabel 36 Voorvoegseltabel is niet gelijk aan 36.02.31 "Voorvoegsel" in het LO.
• Bij kolomnamen in de PDF-versie van tabellen zijn tweede en volgende woorden vaak (niet altijd) met een hoofdletter geschreven, terwijl dat in de CSV-versie en in het LO niet zo is. Voorbeeld: "Datum Ingang" in de PDF-versie van tabel 32 Nationaliteitentabel is geen logische afkorting van 32.99.98 "Datum ingang tabelregel" in het LO.

2.2 Oplossing

In LO BRP krijgen sommige rubrieken een andere naam als die logischer of consistenter is met vergelijkbare rubrieknamen in andere tabellen. In de CSV- en de PDF-versies van tabellen worden de kolomnamen aangepast volgens de aanwijzingen in de bijlage "W164 Bijlage - Verschillen kolomnamen landelijke tabellen LO-CSV-PDF.xlsx".

2.3 Gerelateerde wijzigingen in wet- en regelgeving

Er is geen afhankelijkheid van wet- en regelgeving.

2.4 Openstaande punten

Er zijn geen openstaande punten.

3 Invoering

Geen bijzonderheden.

4 Gevolgen

4.1 Documentatie

In LO BRP worden de volgende rubrieknamen aangepast:

Rubriek	Naam was	Naam wordt
32.05.12	Officiële omschrijving nationaliteit	Omschrijving nationaliteit
33.92.11	Officiële gemeentenaam	Gemeentenaam
34.94.11	Officiële landnaam	Landnaam
37.96.10	Reden opnemen/beëindigen nationaliteit	Code opnemen/beëindigen nationaliteit
37.96.20	Omschrijving	Omschrijving opnemen/beëindigen nationaliteit
38.02.21	Adellijke titel/predicaat	Code adellijke titel/predicaat
39.81.22	Omschrijving soort akte	Omschrijving akte
41.07.41	Reden ontbinding/nietigverklaring huwelijk/geregistreerd partnerschap	Code ontbinding/nietigverklaring
41.07.42	Omschrijving	Omschrijving ontbinding/nietigverklaring
48.35.11	Nederlands reisdocument	Code Nederlands reisdocument
48.35.12	Omschrijving	Omschrijving Nederlands reisdocument
49.35.41	Autoriteit van afgifte	Code autoriteit van afgifte
49.35.42	Omschrijving	Omschrijving autoriteit van afgifte
56.39.11	Verblijfstitel	Code verblijfstitel
56.39.12	Omschrijving	Omschrijving verblijfstitel
59.97.12	Aanduiding aangesloten op de berichtendienst	Aangesloten op de berichtendienst
61.32.11	Gezagsverhouding	Code gezagsverhouding
61.32.12	Omschrijving	Omschrijving gezagsverhouding

 4.2 Gemeenten

Gemeenten en afnemers krijgen te maken met iets andere kolomnamen in de tabellen zoals die gepubliceerd worden op de website van RvIG. Omdat de tabelberichten blijven zoals ze zijn, is er alleen directe impact op gemeenten die de tabellen van de website downloaden en inlezen. Indirecte impact is er als gemeenten in het datamodel ook de nieuwe rubrieknamen willen hanteren, of als rubrieknamen ook op schermen (bijvoorbeeld bij een inzagefunctie voor tabellen) worden getoond. In dat geval zullen ze mogelijk hun software hierop moeten aanpassen.

4.3 Afnemers

Gemeenten en afnemers krijgen te maken met iets andere kolomkoppen in de tabellen zoals die gepubliceerd worden op de website van RvIG. Zij zullen mogelijk hun software hierop moeten aanpassen. Van sommige afnemers is bekend dat zij de tabellen in CSV-formaat downloaden van de website en via een automatische import inlezen in hun applicatie. Die import functie moet mogelijk worden aangepast. Afnemers die tabelgegevens aangeleverd krijgen via de tabelberichten, hoeven niets te doen, tenzij ze in het datamodel, of in schermen van hun applicaties de namen van de rubrieken mee willen wijzigen. In dat geval zullen ze mogelijk hun software moeten aanpassen.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

Geen gevolgen.

4.6 RvIG-systemen

De tabellenapplicatie zal de nieuwe rubrieknamen moeten ondersteunen in haar datamodel en in de schermen voor tabelbeheer, en in staat moeten zijn om de tabellen te generen in CSV- en PDF-formaat met de nieuwe kolomnamen. Daarnaast staan tabelgegevens ook in BRP-V opgeslagen. Ook daar moeten kolomnamen worden aangepast, maar dat is vooral om intern naamgebruik consistent te houden met namen van kolommen in het LO.

 

1 Probleemstelling

1.1 Omschrijving

In eerdere LO-wijzigingen zijn de verstrekking van gegevens door middel van de BRP Personen API (W162), de BRP Reisdocumenten API (W171) en de BRP Bewoning API (W185) in het LO opgenomen. Met wijziging W172 worden via deze API's niet langer alleen BRP-gegevens verstrekt, maar ook informatieproducten, zoals leeftijd een aanschrijfnaam. Dit LO-wijzigingsvoorstel beschrijft de verstrekking van gegevens en informatie over de verblijfplaatshistorie door middel van de BRP Historie API.

1.2 Herkomst

De wens van de gemeenten en de VNG om BRP-gegevens direct bij de bron op te halen. Hieraan wordt voldaan door initiatief BRN-01-01 Haal Centraal BRP API.

1.3 Raakvlakken

Er zijn geen raakvlakken met andere LO-wijzigingen anders dan de hierboven genoemde.

2 Oplossing

2.1 Huidige situatie

Voor historische gegevens over iemands verblijfplaats zijn gemeenten en afnemers nu nog aangewezen op het gebruik van de ad hoc vraag via de berichtendienst of de ad hoc webservice. In die historie kan niet heel gericht worden gezocht, omdat er alleen identificerende kenmerken van een persoon of adres kunnen worden gebruikt als zoekparameters. Er kan bijvoorbeeld niet worden gezocht op een peildatum of een periode.

2.2 Oplossing

Het onderhavige LO-wijzigingsvoorstel bevat het logisch ontwerp van de BRP Historie API. Het technisch ontwerp staat op de Github pagina's van RvIG. In het ontwerp van de Historie API is wél rekening gehouden met de mogelijkheid om op een bepaalde peildatum of in een bepaalde periode te zoeken. Een persoon moet echter altijd met een burgerservicenummer worden geïdentificeerd. Alleen deelnemers aan het experiment dataminimalisatie BRP kunnen gebruik maken van de BRP API. Zij dienen een convenant te ondertekenen en mee te werken aan de evaluatie van het experiment. Het endpoint /verblijfplaatshistorie is alleen beschikbaar voor bevragingen door gemeenten over hun eigen inwoners.

2.3 Openstaande punten

Er zijn na implementatie van deze API geen openstaande punten.

3 Invoering

Toegang tot de API wordt uitsluitend verstrekt aan geautoriseerde deelnemers aan het experiment dataminimalisatie BRP. Voor alle overige gemeenten en afnemers heeft deze wijziging geen consequenties.

4 Gevolgen

4.1 Documentatie

Deze wijziging in LO BRP heeft geen gevolgen voor andere logisch ontwerpen (LO BSN, LO BRPk, LO BES en LO PGK), ook niet voor de HUP en de WIR.

4.2 Gemeenten

Voor gemeenten die niet deelnemen aan het experiment dataminimalisatie BRP verandert er niets. Voor gemeenten die wel deelnemen, wordt het mogelijk om BRP-V te bevragen via het nieuwe endpoint /verblijfplaatshistorie in de BRP API.

4.3 Afnemers

Geen gevolgen.

4.4 IND

Geen gevolgen.

4.5 Caribische landen en Caribisch Nederland

Geen gevolgen.

4.6 RvIG-systemen

De Historie API wordt in een separate container opgeleverd aan DICTU, en moet worden ontsloten via de API Gateway van RvIG. Verder is er geen impact op systemen bij RvIG.

 

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.

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.