Een van die functionaliteiten is opvragen Reisdocumentinformatie in het ReIS Aanvraagportaal (RAP) en de Reisdocumentenmodule (RDM). Hieronder lees je meer over deze functionaliteit.

Wat is functionaliteit de Reisdocumentinformatie?

Met ‘Reisdocumentinformatie’ ook wel ‘Documentinzage’ genoemd, zie je de administratieve levensloop van een reisdocument. Je krijgt detailinformatie over de status van een reisdocument te zien, inclusief de personalisatiegegevens en meldingen die zijn gedaan op het reisdocument. Hierdoor weet je welke reisdocumenten iemand nog meer heeft of heeft gehad, en of een reisdocument in omloop mag zijn. Ook als dit document door een andere uitgevende instantie is versterkt. Dit helpt je om onder andere vast te stellen welke documenten de aanvrager bij de aanvraag van een nieuw document zou moeten inleveren.

Hoe werkt Reisdocumentinformatie?

Reisdocumentinformatie is beschikbaar in het RAP en de RDM.

Je kunt zoeken op:

• Reisdocumentnummer
• BSN of A-nummer
• Personalisatiegegevens

Je ziet dan:

• Detailinformatie over de huidige status van een reisdocument, inclusief personalisatiegegevens en meldingen
• Detailgegevens van het opgevraagde document
• Tijdlijn van het document

Deze informatie komt uit het Basisregister Reisdocumenten (BR).

Toelichting en infographic Meldingen en Statussen in het BR

Er is met het Basisregister Reisdocumenten (BR) een betere manier om de status van en meldingen op een reisdocument te registreren. De volgende twee onderdelen zijn belangrijk:

• Status
• Melding

De status van een reisdocument kan alleen veranderen door een melding. Het systeem past de status automatisch aan als dat nodig is op basis van de melding.

In de infographic ‘statussen van reisdocumenten in het basisregister ’ zie je welke meldingen tot welke statussen leiden.

Wat is een status?

Alleen (bestaande) documenten hebben een status. Dit wil zeggen dat een document een status kan krijgen, nadat het reisdocument is gepersonaliseerd door de producent.

Vanaf dat moment kan een document vier statussen hebben:

• In aanvraag (IA) = Het document is gepersonaliseerd bij de producent en wordt aan de uitgiftelocatie overgedragen.
• Geldig (GD) = Het document is uitgereikt aan de burger en in omloop.
• Ongeldig (OG) = Het document is van rechtswege vervallen en nog in omloop. Het document is niet meer geldig. Het is bijvoorbeeld vermist of de geldigheidsduur is verstreken, maar het document is (nog) niet ingeleverd.
• Definitief onttrokken (DO) = Het document is ingenomen, ongeldig gemaakt door middel van ponsgaten, vernietigd en niet meer in omloop. Een document dat van rechtswege is vervallen en aan de balie wordt ingeleverd, krijgt eerst de status Ongeldig en direct daarna Definitief onttrokken. Een reisdocument kan in bepaalde gevallen als het nog geldig is, direct Definitief onttrokken worden. In dat geval wordt de status Ongeldig overgeslagen.

De status van een document verandert altijd volgens deze volgorde. Het reisdocument heeft altijd maar één status. De status kan niet terug naar een vorige status. Het is wel mogelijk om een status over te slaan. Bijvoorbeeld als een reisdocument is vervallen vóór uitreiking omdat het niet op tijd is opgehaald. Meer uitleg vind je in de infographic.

Wat is een melding?

Een status van een document kan alleen door middel van een melding een melding veranderen. De volgende meldingen zijn mogelijk:

• RGP: reisdocument is gepersonaliseerd
• RVU: reisdocument is vervallen vóór uitreiking
• RRV: reisdocument is van rechtswege vervallen
• RRU: reisdocument is uitgereikt
• RDO: reisdocument is definitief onttrokken

De uitgevende instantie legt deze meldingen vast.

Reisdocumentinformatie in overige processen

Je kunt reisdocumentinformatie ook voor andere processen gebruiken. Kies dan bij de aanleiding voor de optie ‘identiteitsonderzoek’. Bij deze optie is het invoeren van het aanvraagnummer niet verplicht.

Wat verandert er precies en wat blijft hetzelfde?

De volgende zaken veranderen:

• Je gebruikt de functionaliteit Reisdocumentinformatie om te weten te komen welke documenten de aanvrager moet overleggen.
• Het Basisregister Reisdocumenten (BR) is de nieuwe en leidende bron voor reisdocumentengegevens en statussen. Categorie 12 BRP/PIVA en de RAAS blijven voorlopig bestaan, maar het BR is leidend.
• Het opvragen van Reisdocumentinformatie vindt digitaal plaats (het vervangt het opvragen van een het RAAS-aanvraagformulier).

De volgende zaken blijven hetzelfde:

• Kopie van het foto- en handtekeningformulier vraag je op via een RAAS-aanvraagformulier bij bijvoorbeeld een vermissing of bij twijfel over identiteit.
• Reisdocument statussen in categorie 12 van de BRP/PIVA (Ingehouden, Ongeldig, Rechtswege vervallen) blijven hetzelfde, en bijhouding daarvan blijft voorlopig bestaan.

Veelgestelde  vragen

De veelgestelde vragen en antwoorden lees je op de pagina Veelgestelde vragen over het opvragen van Reisdocumentinformatie.

MEMO Toelichting en voorbeelden wsdl stuurGBAbericht

1. Algemene beschrijving van de stuurGBABericht webserivce

De webservice verleent drie diensten: Controleren PL, Uitwisselen van LO berichten (sPoed) en test webservice (Echo),
Omdat verschillende diensten via een webservice (met 1 wsdl) worden geleverd, vertonen deze diensten op punten gelijk gedrag. Hieronder worden de belangrijkste overeenkomsten en verschillen beschreven.

Figuur 1. Algemene beschrijving

Functionele overeenkomsten zijn:

• Alle diensten in stuurGBABericht draaien om de uitwisseling van 'GBA-berichten'.
• Elke dienst voert een actie uit op een ontvangen bericht (verwerken, controleren etctera);
• Elke dienst bestaat uit een of meer acties;
• Elke actie heeft een vraag- en een antwoordbericht (request resp. response);
• De gewenste actie wordt aangegeven in het vraagbericht in de body van het bericht.
• Het resultaat van de gewenste actie wordt teruggegeven in een antwoordbericht in de body van het bericht

Overeenkomsten in de implementatie zijn:

• StuurGBABericht maakt gebruik van TLS en HTTP basic authentication;
• StuurGBABericht is een SOAP 1.1 webservice over HTTP;
• De SOAP body van een vraagbericht bevat een <stuurGBABerichtRequest als 'root';
• Een vraagbericht bevat altijd het element actie met daarin de naam van de actie;
• Een vraagbericht bevat afhankelijk van de gevraagde actie de elementen gbabericht aanleiding en berichtnummer
• Een antwoordbericht bevat in de body stuurGBABerichtResponse als root;
• Een antwoordbericht bevat altijd het verplichte element resultaatcode. De invulling daarvan verschilt per actie;
• Een antwoordbericht bevat altijd het element referentie; met daarin de activiteit ID van de webservice actie;
• Een activiteit ID is een getal van maximaal 12 posities.
• Voor alle berichten geldt UTF-8 encodering;
• Regelovergangen volgen de XML standaard (LF), zie http://www.w3.org/TR/REC- xml/#sec-line-ends;
• Het GBA-bericht dat meegestuurd wordt, is geencodeerd in Teletex maar wel ingebed in Unicode. Zie ook de uitleg bij Voorbeeld Appendix A;
• Gebruik van character entities in de berichtinhoud en uitsluiting van het gebruik van Form Feed;
• Alle parameters (elementen en element-inhoud) zijn case sensitive;
• De wsdl en xsd zijn opgenomen in Appendix B.

Gebruik van het SOAPAction HTTP request header veld

De WSDL voor stuurGBABericht specificeert geen SOAPAction HTTP header waarde. De SOAPAction header zelf is volgens de SOAP-specificatie echter wel verplicht. In een vraagbericht moet een SOAPAction zonder waarde mee worden geven. Wanneer een gevulde SOAPAction wordt aangeboden in de HTTP volgt een fout(bericht).

Verschillen tussen de diensten zijn:

• Elk van de diensten vereist een andere autorisatie.
• sPoed maakt gebruik van WS-Addressing, de overige diensten niet.
• StuurGBABericht kan in de proefomgeving getest worden. Voor sPoed zal een aparte testomgeving worden ingericht. sPoed werkt immers de database van GBA-V bij.

De dienst sPoed volgt in grote lijnen de sPd operaties: zie LO GBA IV.5.2. In het overzicht hieronder zijn sPd-operaties afgezet tegen de acties in sPoed. Als geen actie aanwezig is nvt opgenomen of wordt een korte toelichting gegeven.

Tabel 1. sPd protocol invulling in de sPoed dienst

sPd-commando	sPoed-webservice commando
LogonRequest	Webservice authenticatie
LogonConfirmation	Webservice authenticatie foutafhandeling
LogoffRequest	nvt, impliciet na ontvangen webservice response-bericht
LogoffConfirmation	nvt
PutMessage	PutMessage
PutMessageConfirmation	PutMessageConfirmation
GetMessage	GetMessage
GetMessageResult	GetMessageResult
GetMessageConfirmation	GetMessageConfirmation
DeleteMessages	nvt
DeleteMessagesConfirmation	nvt
ListMessages	ListMessages
ListMessagesResult	ListMessagesResult
ListMessagesConfirmation	ListMessagesConfirmation
SummarizeConfirmation	nvt: fouten bij het retourneren van een geldig antwoord zijn altijd een 'technische fout'.
ChangePasswordRequest	webservice change password
ChangePasswordConfirmation	webservice change password
NoOperationConfirmation	nvt

Figuur 2. Structuur van een stuurGBAbericht (vraag)

Figuur 3. Structuur van een stuurGBAbericht (antwoord)

2. Voorbeelden van de stuurGBABericht webserivce

1. valideer_pl vraagbericht met Lg01 in CDATA sectie

1. Het gbabericht bevat in dit geval een CDATA sectie met daarin het complete Lg01 bericht. De encodering van dit bericht is in Teletex ingebed in Unicode. Het gbabericht is een verplicht veld.
2. De actie is valideer_pl (let op: kleine letters en _ (underscore)) en is verplicht.
3. De aanleiding is facultatief. In dit geval is 'kwaliteitscontrole' opgenomen.
4. berichtnummer is Lg01. Dit is het berichtnummer zoals vermeld in het Logisch Ontwerp GBA. Let hier ook weer op hoofd- en kleine letters. berichtnummer is verplicht.

2. valideer_pl antwoord: BCM controle geslaagd: 1 of meer fouten gevonden

1. Het antwoord op de vraag bevat een algemene resultaatcode voor de actie valideer_pl: pl_ok wanneer de validatie is doorlopen en er geen fouten/issues in de PL zijn ontdekt; pl_nok wanneer de validatie is doorlopen en er fouten/issues (1 of meer) zijn ontdekt of als de validatie niet succesvol is doorlopen. Als er fouten zijn ontdekt is er een sectie details met hierin voor elk van de issues een detail. Als de validatie niet succesvol is doorlopen is er een sectie details waarin een van de foutcodes is opgenomen (Zie LO GBA tabel C1 par C7.3.5).
2. De toelichting bevat bij pl_ok en pl_nok een vermelding van de naam en de versie van het systeem dat is gebruikt om de PL te valideren. In dit voorbeeld: BCM v4.3. Wanneer de resultaatcode een andere (fout)code bevat, dan bevat toelichting een tekstuele toelichting op deze code.
3. Wanneer de validatie is doorlopen en er fouten/issues in de PL zijn geconstateerd, dan bevat details 1 of meer detail elementen met elk een code en omschrijving. Het element details is facultatief en kan wanneer geen details gevonden zijn afwezig zijn (bij pl_ok, of bij fouten waardoor geen validatie van de PL heeft plaats kunnen vinden).
4. De code komt overeen met de code uit de BCM sheet. De code is altijd aanwezig binnen detail.
5. De omschrijving komt overeen met de code uit de BCM sheet. Het meegeven van een omschrijving is niet verplicht.
6. De referentie bevat de activiteit ID en is primair bedoeld om bij vragen aan RvIG het verzonden bericht terug te vinden.

3. valideer_pl antwoord: BCM controle geslaagd: geen fouten gevonden

4. sPoed vraag: SummarizeMessages

1. MessageID is aanwezig als leeg element. RelatesTo is niet van toepassing en niet verplicht volgens de WSDL, dus niet aanwezig (bij aanwezigheid wordt deze genegeerd).
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard waarde.
3. Action is gevuld met de standaardwaarde "sPoed".
4. De actie is SummarizeMessages.

5. sPoed antwoord: SummarizeResult (0 of meerdere GBA-berichten gevonden)

1. De MessageID is aanwezig (verplicht element), maar bevat geen waarde.
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard waarde.
3. Action is gevuld met de standaardwaarde "sPoed".
4. De resultaatcode is SummarizeResult bij het succesvol ophalen van een bericht (zoals beschreven in sPd protocol) en is case-sensitive.
5. Code is het aantal GBA-berichten die klaar staan ter verzending. omschrijving is niet aanwezig.
6. Referentie is gevuld met het GBA-V activiteit ID dat hoort bij de SummarizeMessages bevraging.

6. sPoed vraag: ListMessages

1. MessageID is aanwezig als leeg element. RelatesTo is niet van toepassing en niet verplicht volgens de WSDL, dus niet aanwezig (bij aanwezigheid wordt deze genegeerd).
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard waarde.
3. Action is gevuld met de standaardwaarde "sPoed".
4. De actie is ListMessages voor het bevragen welke GBA-berichten opgehaald kunnen worden (zoals beschreven in sPd protocol en is case-sensitive).

7. sPoed antwoord: ListMessagesResult (bij gevonden berichten)

1. MessageID is aanwezig als leeg element. RelatesTo is niet van toepassing en niet verplicht volgens de WSDL, dus niet aanwezig (bij aanwezigheid wordt deze genegeerd).
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard waarde.
3. Action is gevuld met de standaardwaarde "sPoed".
4. De resultaatcode is ListMessagesResult bij het succesvol ophalen van een bericht (zoals beschreven in sPd protocol en is case-sensitive).
5. Code is het GBA-berichtID van het op te vragen GBA-bericht. Voor elk gevonden bericht wordt een detail opgenomen met in code het GBA-berichtID van het GBA-bericht.
6. Rreferentie is gevuld met het activiteit ID dat hoort bij de ListMessages bevraging.

8. sPoed antwoord: ListMessagesConfirmation (GEEN gevonden GBA-berichten)

1. MessageID is aanwezig als leeg element. RelatesTo is niet van toepassing en niet verplicht volgens de WSDL, dus niet aanwezig (bij aanwezigheid wordt deze genegeerd).
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard waarde.
3. Action is gevuld met de standaardwaarde "sPoed".
4. De resultaatcode is ListMessagesConfirmation (zoals beschreven in sPd protocol en is case- sensitive) bij geen gevonden bericht(en) ter verzending.
5. Referentie is gevuld met het activiteit ID dat hoort bij de ListMessages bevraging.

9. sPoed vraag: GetMessage

1. MessageID is aanwezig als leeg element. RelatesTo is niet van toepassing en niet verplicht volgens de WSDL, dus niet aanwezig (bij aanwezigheid wordt deze genegeerd).
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard- waarde.
3. Action is gevuld met de standaardwaarde sPoed.
4. De actie is GetMessage (zoals beschreven in sPd protocol en is case-sensitive) voor het ophalen van een bericht.
5. Het GBA-berichtID wordt in berichtnummer geplaatst.

10. sPoed antwoord: GetMessageResult met daarin een GBA-bericht als dat bericht geen reactie is op een eerder bericht (eerste bericht in een GBA-berichtencyclus)

1. MessageID is het GBA-berichtID, toegekend door het GBA-V systeem. RelatesTo is niet aanwezig omdat dit het eerste bericht is in de berichtencyclus.
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard- waarde.
3. Action is gevuld met de standaardwaarde sPoed.
4. De resultaatcode is GetMessageResult (zoals beschreven in sPd protocol en is case- sensitive) bij het succesvol ophalen van een bericht.
5. gbabericht bevat het complete Lq01 bericht.
6. berichtnummer is in dit voorbeeld Lq01. Het is een berichtnummer zoals vermeld in het Logisch Ontwerp. Het berichtnummer is gelijk aan het berichtnummer genoemd in het werkelijke bericht in gbabericht.
7. referentie is gevuld met het activiteit ID dat hoort bij de GetMessage bevraging.

11. sPoed antwoord: GetMessageResult met daarin een GBA-bericht als dat bericht een reactie is op een eerder bericht (vervolgbericht in een GBA-berichtencyclus)

1. MessageID is het GBA-berichtID, toegekend door het GBA-V systeem.
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard- waarde.
3. RelatesTo is gevuld met het MessageID van het bericht waar, in dit voorbeeld, de Pf01 in dit bericht het antwoord op is. De MessageID komt uit MessageID van bijvoorbeeld een PutMessage met een Lg01. De MessageID van dat bericht was in dit voorbeeld 23456.
4. Action is gevuld met de standaardwaarde sPoed.
5. De resultaatcode is GetMessageResult (zoals beschreven in sPd protocol en is case- sensitive) bij het
succesvol ophalen van een bericht.
6. gbabericht bevat het complete Pf01 bericht.
7. berichtnummer is Pf01. Dit is het berichtnummer zoals vermeld in het Logisch Ontwerp GBA-V. Let hier ook weer op hoofd- en kleine letters.
8. referentie is gevuld met het activiteit ID dat hoort bij de GetMessage bevraging.

12. sPoed antwoord: GetMessageConfirmation (GBA-bericht niet gevonden)

1. MessageID en RelatesTo zijn niet van toepassing: de GetMessageConfirmation bevat geen bericht.
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard- waarde.
3. Action is gevuld met de standaardwaarde sPoed.
4. De resultaatcode is GetMessageConfirmation (zoals beschreven in sPd protocol en is case- sensitive) bij niet kunnen ophalen van een bericht.
5. referentie is gevuld met het activiteit ID dat hoort bij de GetMessage bevraging.

13. sPoed vraag: PutMessage met La01 in CDATA sectie

1. MessageID is gevuld met het ID van het, in dit voorbeeld La01, bericht.
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard- waarde.
3. RelatesTo is in dit voorbeeld gevuld met het GBA-berichtID. Deze komt uit MessageID van het webservice bericht waarin het GBA vraagbericht (in dit geval Lq01) was opgenomen. In dit voorbeeld had dit sPoed antwoord: GetMessageResult met daarin het GBA-bericht (eerste bericht in de cyclus)
kunnen zijn.
4. Action is gevuld met de standaardwaarde sPoed.
5. gbabericht bevat in dit geval een CDATA sectie met daarin het complete La01 bericht. De encodering van het bericht in dit voorbeeld is Teletex ingebed in Unicode.
6. De actie is PutMessage (zoals beschreven in sPd protocol en is case-sensitive) voor het versturen van
een bericht.
7. berichtnummer is La01. Dit is het berichtnummer zoals vermeld in het Logisch Ontwerp GBA-V. Let hier ook weer op hoofd- en kleine letters. berichtnummer is verplicht bij de actie PutMessage en is overeenkomstig met het berichtnummer in het GBA-bericht.

14. sPoed antwoord: PutMessageConfirmation (Bevestiging bericht is ontvangen).

1. MessageID en RelatesTo zijn niet van toepassing: de PutMessageConfirmation bevat geen bericht.
2. Vanwege de synchrone communicatie is de binding anoniem en is dit de standaard- waarde.
3. Action is gevuld met de standaardwaarde sPoed.
4. De resultaatcode is PutMessageConfirmation (zoals beschreven in sPd protocol en is case- sensitive) bij het succesvol plaatsen van een bericht.
5. referentie is gevuld met het activiteit ID dat hoort bij de PutMessage bevraging.

15. actie ECHO: stuurGBABerichtRequest

1.  De vaste tekst GBA-BERICHT.
2. De actie ECHO (let op: hoofdletters).
3. De aanleiding is een vrij in te vullen tekst in stuurGBABerichtRequest. De aanleiding wordt zonder verandering teruggestuurd in het antwoordbericht.
4. Het berichtnummer is een vrij in te vullen berichtnummer. Ook dit berichtnummer wordt onveranderd in het antwoord teruggestuurd.

16. actie ECHO: Antwoord op bovenstaand bericht

1. De resultaatcode van een valide ECHO stuurGBABerichtRequest is altijd OK (voorwaarde: er treedt geen technische fout op).
2. De toelichting bij de resultaatcode is Echo Response.
3. In details worden de aanleiding, actie, het berichtnummer en het in de vraag meegestuurde bericht zoals gegeven in de vraag mee terug teruggestuurd.
4. Referentie wordt standaard gevuld met de Activiteit-ID (ter referentie RvIG).

17. Technische fout

De request kan om verschillende redenen worden afgekeurd. In bovenstaand voorbeeld gaat het om een technische fout. Andere mogelijkheden zijn:

• Ongeldige combinatie gebruikersnaam / wachtwoord
• Server is niet geactiveerd voor dit account
• Wachtwoord verlopen
• Geen actuele autorisatietabelregel
• Ongeldige waarde voor parameter

Zie voor een opsomming van de foutcodes LO GBA tabel C1 par C7.3.5).

18. SOAP fout opbouw
 

Appendix A: opbouw en tekst-encodering van <gbabericht>

Er zijn twee varianten van de inhoud van <gbabericht>: een met het bericht in een CDATA sectie en een met het GBA-bericht opgenomen als tekst in de XML. Van beide varianten volgt hieronder een voorbeeld.

element gbabericht met Lg01 in CDATA sectie

① Het gbabericht bevat in dit geval een CDATA sectie met daarin het complete Lg01 bericht. De encodering van dit bericht is in Teletex ingebed in Unicode. Het bericht is een verplicht veld.

Elk bericht dat wordt meegegeven in de XML is in Teletex gerepresenteerd door UTF-8 unicode. Om van het Teletex bericht te komen tot het juiste bericht in de XML worden de volgende stappen doorlopen:
1.Teletex tekens worden geëncodeerd met Teletex bytes.
2.Elke Teletex byte wordt gepresenteerd met (c.q. vervangen door) een Unicode teken op basis van de numerieke waarde.
3.De resulterende Unicode tekens worden geëncodeerd en getransporteerd als UTF-8. Stap 3 is standaard voor webservices. Van belang zijn stap 1 en 2.

Je ziet dit terug in het eerder gegeven XML bericht hierboven.

Het is mogelijk de Lg01 als tekst met gewone markup mee te sturen in plaats van in een CDATA sectie. Let er hierbij op dat de volgende karakters vervangen worden door XML escape karakters (character/entities):

XML character entities

Strikt genomen hoeven alleen & en < vervangen te worden, maar het is goed gebruik al deze karakters te vervangen. Een Carriage Return komt in GBA-berichten zelden voor en is een speciaal geval. Een CR moet altijd worden opgenomen als &#13; en kan niet worden gebruikt in een CDATA sectie. De meest veelzijdige vorm van het versturen van een bericht, waarbij ook rekening wordt gehouden met Carriage Returns, is hiermee het meesturen van de PL als elementinhoud (zonder CDATA) en het escapen van alle hierboven genoemde karakters. Wanneer geen carriage return in het bericht staat is de eenvoudigste vorm die met de CDATA sectie (zonder character references).

Het Teletex karakter voor Form Feed (FF) kan niet worden gebruikt in deze webservice. Ook de character reference #12; is niet toegestaan. Dit Teletex karakter wordt in de praktijk niet gebruikt en vormt dus geen praktische belemmering.

Het element gbabericht met de Lg01 als tekst

In dit voorbeeld is de ampersand in de straatnaam V&D weg vervangen door &amp;.

Appendix B: WSDL en XSD

stuurGBABericht-v1.0.wsdl

Het element <wsaw:UsingAddressing wsdl:required="true" /> betekent dat WS-Addressing verplicht is. Het systeem bepaalt echter aan de hand van welke dienst gebruikt wordt of de WS-Addressing van toepassing is. Voor de Controleren PL en de ECHO
diensten is WS-Addressing NIET verplicht.

De inhoud van de berichten voldoet aan het volgende schema:
XSD voor stuurGBABerichtRequest en stuurGBABerichtResponse

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)

De Webapplicatie LAA (WALAA) is voor gemeenten de digitale omgeving om adresonderzoeken voor de Landelijke Aanpak Adreskwaliteit (LAA) te kunnen doen. Deze korte handleiding biedt ondersteuning aan medewerkers van gemeenten die zich bezighouden met het uitvoeren van adresonderzoek. In de handleiding wordt gebruik gemaakt van testgegevens. Heb je alsnog vragen over de WALAA? Neem dan contact op met je LAA-ambassadeur of LAA-accountmanager van RvIG.

Procedure verwerken signalen

Wanneer gemeenten een signaal in de WALAA ontvangen, moeten zij zo snel mogelijk terugmelden hoe zij dit signaal hebben opgevolgd:

• Binnen vier weken dien je aan te geven of het signaal aanleiding was voor een aanpassing in de BRP of dat de Persoonslijst (PL) op het adres ‘in onderzoek’ is geplaatst. Ook als er geen opvolging wordt gegeven aan het signaal moet dit worden teruggemeld.
• Binnen zes maanden dient het onderzoek afgerond te zijn. De informatie meld je uiterlijk binnen zes maanden terug.

Signalen worden na zes maanden verwijderd uit de WALAA, maar blijven zichtbaar in de ‘Monitor’.

Inloggen

• eHerkenning niveau 3 is nodig voor iedere medewerker die met de WALAA werkt.
• Tijdens het huisbezoek kun je de WALAA gebruiken op een tablet.
• Vanuit beveiligings oogpunt word je na 15 minuten inactiviteit automatisch uitgelogd.
• Maak gebruik van de navigatie-mogelijkheden in de WALAA zelf. Het gebruik van de pijltjes van de webbrowser resulteert in verlies van gegevens.

Casusoverzicht

Chronologisch op volgorde zetten van geleverde signalen.
Hier staan alle filteropties om tot een overzicht van het gewenste signaal te komen.

Menu:

• Casusoverzicht

Voor actuele werkvoorraad

• Monitor

Een overzicht van afgeronde signalen

• Statusoverzicht

Geeft de status van een signaal aan

• Instructies

Toelichting op het signaal

• Download basisvragenlijst

Basisvragen in PDF

• Uitloggen

Geeft de status van het signaal aan.

LET OP: LAA signalen worden maandelijks geleverd. De informatie is op dat moment twee weken oud. Check altijd eerst de actuele inschrijving op het adres in de BRP.

Monitor

Hiermee is het mogelijk een rapportage in Excel te maken.
Stel wel eerst de gewenste filters in voordat je een rapportage maakt.

Vooronderzoek

LET OP: De WALAA is niet gekoppeld aan de BRP. Eventuele mutaties moeten apart in de BRP worden doorgevoerd.

Persoon woont er volgens BRP nog.
Persoon staat geregistreerd met een briefadres.
Persoon woont er volgens de BRP niet meer.
Dit is een verplichte vraag of verplicht veld.
Toevoegen van een nieuw persoon op het adres.

Als een afgerond vooronderzoek toch moet worden aangepast, kan dit via een verzoek aan RvIG. Gebruik bij dit verzoek altijd de adrescode en niet het daadwerkelijke adres.

Huisbezoek

Persoon staat geregistreerd met een briefadres.
Persoon woont op het adres.
Persoon woont niet meer op het adres.

LET OP: De onderzoeken die voor vergoeding in aanmerking komen hebben de status:

• Afgerond (er heeft daadwerkelijk een huisbezoek plaatsgevonden)
• Driemaal bezocht (driemaal het adres bezocht maar er was niemand thuis)
• Weigering (er was iemand aanwezig op het adres, maar weigerde mee te werken aan het huisbezoek.)

Het is dus belangrijk om de uitkomst van je onderzoek op de juiste wijze in de WALAA te registreren.
 

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.