IMPACTANALYSE MODERNISERING GBA OVERLIJDEN, MIGRATIE EN REISDOCUMENTEN

Transcriptie

1 IMPACTANALYSE MODERNISERING GBA OVERLIJDEN, MIGRATIE EN REISDOCUMENTEN Antek Wojtaszek Versie Juni-2011

2 Algemeen Versienummer 1.0 Naam organisatie opleiding Hogeschool Rotterdam Auteur Antek Wojtaszek Studiejaar Derde Stageperiode 21 Februari t/m 4 Juli 2011 Plaats en Datum Gouda, Juli 2011 Naam opdrachtgever Centric IT Solutions Naam begeleider Jan van den Bosch Hogeschool Rotterdam Eerste afstudeerdocent Henk Bakker Tweede afstudeerdocent: Fedor Wagenaar Afstudeercoördinator Luuk Delahaye Bezoekadres G.J. de Jonghweg GG Rotterdam Telefoon Website Contactgegevens Centric Begeleider Jan van den Bosch Functie Productmanager Key2Burgerzaken Bezoekadres Antwerpseweg AH Gouda Telefoon Website info@centric.eu i

3 VOORWOORD Voor u ligt een scriptie die het resultaat is van een onderzoek naar de impact van de modernisering Gemeentelijke BasisAdministratie (mgba) ten opzichte van Key2Burgerzaken. Dit is uitgevoerd in opdracht van Centric IT Solutions. Met deze scriptie zal ik de studie Bedrijfskundige Informatica afronden. In de eerste weken heb ik mijzelf ingelezen in het GBA stelsel. Dit heb ik als complex ervaren. Zeker alle overheidstermen, wetten en processen waren voor mij lastig te begrijpen. Daarbij komt ook het onder de knie krijgen van Key2Burgerzaken, een applicatie die vele functionaliteiten bevat. Dit was complexer dan ik in eerst instantie had gedacht. Al met al heb ik deze complexe omgeving na veel (door)vragen en informeren tot mij kunnen nemen en heb ik het een en ander een plek kunnen geven in mijn afstudeeropdracht. Ik wil graag een aantal personen bedanken voor de totstandkoming van dit rapport. Als eerste wil ik mijn begeleider vanuit de Hogeschool Rotterdam, Henk Bakker bedanken voor de plezierige en vlotte samenwerking gedurende mijn afstudeerperiode. Ook wil ik Fedor Wagenaar bedanken voor zijn feedback op mijn opgeleverde producten. Absoluut onmisbaar was mijn begeleider vanuit Centric, Jan van den Bosch. Met Jan heb ik gedurende mijn afstudeerperiode kunnen sparren over het project en Jan heeft mij op een prettige manier begeleid. Ook de consultants burgerzaken die bij mij op de werkkamer zaten hebben mij vaak geholpen als ik een vraag had over Key2Burgerzaken, dit had een positief effect op de voortgang van het project. Als laatste wil ik Myriam Aelen, Rene van den Boomen en Frans Hendriks bedanken voor het beantwoorden van mijn vragen over de functionaliteiten in Key2Burgerzaken en de mgba. Antek Wojtaszek Gouda Juli 2011, Niets uit deze uitgave mag worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand of openbaar gemaakt, in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopieën, opnamen of enige andere manier, zonder voorafgaande schriftelijke toestemming van Centric IT Solutions. ii

4 MANAGEMENTSAMENVATTING Centric levert voor de lokale overheid de applicatie Key2Burgerzaken om burgerzaken processen te ondersteunen. Deze applicatie communiceert met het GBA-stelsel. Dit GBA-stelsel zal beïnvloed worden door het programma Modernisering GBA. Onderdeel van dit programma is de BRP welke de GBA zal vervangen. De BRP brengt op twee plaatsen vereisten met zich mee, functionele en technische vereisten. Dit project richt zich op het onderzoek naar de functionele vereisten die de BRP stelt en de impact op de burgerzaken processen. De onderzoeksdoelstelling van dit project is: 'Centric wil met dit project te weten komen welke aanpassingen gedaan moeten worden in Key2Burgerzaken, wat de gevolgen zijn voor de gebruikers van Key2Burgerzaken en welke aanpak Centric kan hanteren om deze verandering te bewerkstelligen.' De volgende modules met bijbehorende processen zijn onderzocht: Module Overlijden Migratie Reisdocumenten Figuur 1 Onderzochte modulen Proces Overlijden in Nederland Eerste inschrijving en hervestiging Aanvraag reisdocumenten Door middel van afgenomen interviews bij de gemeente Apeldoorn en informatie van de consultants Key2Burgerzaken zijn de huidige processen in kaart gebracht. Samen met de gepubliceerde documenten voor de Burgerzaken modules geeft dit het volgende resultaat: Module Aantal ontbrekende eisen Overlijden 7 3 Migratie 20 8 Reisdocumenten Total Figuur 2 Resultaten ontbrekende eisen Aantal ontbrekende Must Have eisen Centric dient deze functionaliteiten toe te voegen aan Key2Burgerzaken om te voldoen aan de minimale eisen (alle eisen in de categorie Must Have) die beschreven staan in de BZM. iii

5 Gekeken naar de procesanalyse van de drie onderzochte processen is vastgesteld dat op hoofdlijnen weinig verandering plaatsvindt op de processen. Geconstateerd is dat de meeste verandering in de deelprocessen te herkennen zijn. Dit betekent dat de procedures in Key2Burgerzaken beïnvloed worden. De veranderingen die plaatsvinden in de procedures zijn: Toevoeging koppeling met de BAG; Toevoeging geautomatiseerde controles; Toevoeging signalen om de gebruiker te wijzen op mogelijke fouten; Het geautomatiseerd in kennis stellen van de aangever over de status van de aanvraag; Procesgericht werken; Het aantal ontwikkeluren en kosten die benodigd zijn voor het aanpassen van Key2Burgerzaken zijn: Module Aantal eisen Ontwikkeluren Kosten Overlijden Migratie Reisdocumenten Totaal Figuur 3 Eisen, uren en kosten Er kan geconcludeerd worden dat het doel van het onderzoek bereikt is. Het is nu duidelijk welke functionele aanpassingen moeten plaatsvinden voor de onderzochte modulen en de gevolgen voor de bijbehorende processen. Echter de overige modules en de technische specificaties dienen onderzocht te worden voordat een beeld gecreëerd kan worden over de impact van de gehele mgba. iv

6 MANAGEMENTSUMMARY Centric supplies the application called 'Key2Burgerzaken' for the local government to support the civil affairs processes. This application communicates with the GBA-system. The GBA-system will be influenced by the program Modernisering GBA. Part of this program is the BRP, which will replace the GBA-system. BRP brings two types of changes, functional and technical changes. This project focuses on the functional changes and impact on the civil affairs processes from the program Modernisering GBA. The research objective is: Centric wants to find out what changes should be done in Key2Burgerzaken, the consequences for users and what approach can handle this change The following modules and associated processes are investigated: Module Death Migration Travel documents Figure 4 Investigated modules and processes Process Death in the Netherlands Initial registration and resettlement Request travel documents Through interviews with the municipality of Apeldoorn and information from the consultants Key2Burgerzaken Centric, the current processes are mapped. Together with the published documents for the Civil affairs modules, gives the following results: Module Number of missing requirements Death 7 3 Migration 20 8 Travel documents Total Figure 5 Results missing requirements Number of missing must have requirements Centric needs to add the missing functionality in Key2Burgerzaken to meet the minimum requirements (all requirements in the category of Must Have) described in the BZM. v

7 Looked at the process analysis of the three investigated processes, it is found that only small changes made to the outline of the processes. Most changes can be identified in the subprocesses. This means that the procedures in Key2Burgerzaken will be affected. The changes taking place in the procedures: Link to BAG from accessing address; Addition of automated controls; Addition of signals to indicate possible errors; The automated notification to the requester about the status of the application; More process-based working. The number of development time and expenses required for the adaptation of Key2Burgerzaken are: Module Number of Development time Costs requirements Death Migration Travel documents Total Figure 6 Requirements, development time and costs It can be concluded that the purpose of this project is reached. Centric now knows what functional changes take place in Key2Burgerzaken and the impact on the processes. However, the other modules and technical specifications needs to be examined before an overall view can be created about the impact of the whole mgba. vi

8 INHOUD 1 INTRODUCTIE BEDRIJF KEY2BURGERZAKEN ACHTERGROND EN AANLEIDING VOOR OPDRACHT PROBLEEM & ONDERZOEKSDOELSTELLING Probleemstelling Onderzoeksdoelstelling Scope van het onderzoek ONDERZOEKSAANPAK STRUCTUUR VAN SCRIPTIE HUIDIGE SITUATIE GBA HUIDIGE SITUATIE GBA-STELSEL Het GBA-stelsel Communicatie Afnemers Terugmeld Voorziening (TMV) Beheervoorziening Burgerservicenummer (BV BSN) GBA-V Logisch ontwerp Kenmerken GBA stelsel PROCESSEN HUIDIGE SITUATIE Overlijden Migratie Reisdocumenten GEWENSTE SITUATIE MODERNISERING GEMEENTELIJKE BASISADMINISTRATIE MODERNISERING GBA EN DE BRP COMMUNICATIE BURGERZAKENSYSTEEM-KERN EN DE BURGERZAKENMODULES AFNEMERS AANVULLENDE DIENSTEN REGISTRATIE NIET-INGEZETENEN (RNI) LOGISCH ONTWERP BRP KENMERKEN ONDERZOEKSRESULTATEN BURGERZAKENMODULES EN PROCESSEN OVERLIJDEN MIGRATIE REISDOCUMENTEN UITKOMSTEN INVESTERINGSANALYSE OVERLIJDEN MIGRATIE REISDOCUMENTEN INVESTERING CONCLUSIE EN AANBEVELINGEN CONCLUSIE AANBEVELINGEN IMPLEMENTATIEPLAN vii

9 1 INTRODUCTIE In dit hoofdstuk wordt een introductie gegeven op de afstudeeropdracht. Het bedrijf waar de afstudeeropdracht wordt uitgevoerd komt ter sprake. Vervolgens wordt het product Key2Burgerzaken toegelicht waar dit project betrekking op heeft. Nadat het duidelijk is geworden hoe het bedrijf, de afdeling en Key2Burgerzaken functioneren, wordt er ingegaan op afstudeeropdracht. 1.1 Bedrijf Centric geeft als daadkrachtige automatiseerder dagelijks richting aan de IT van een groot aantal organisaties. Door de groeiende omvang van het bedrijf en de solide financiële positie, realiseert Centric grootschalige projecten en kan continuïteit gegarandeerd worden. Centric biedt gespecialiseerde totaaloplossingen en richt zich op de volgende gebieden: consultancy, IT solutions, software engineering, e-business, systems integration, managed ICT services en training. Centric is actief in diverse branches, waaronder de overheid, financiële dienstverlening, woningcorporaties, retail en groothandel. Centric biedt innovatieve oplossingen en diensten van hoge kwaliteit, mede door hechte samenwerking met diverse gerenommeerde partners. Vanuit de divisie IT Solutions ontwikkelt Centric standaardsoftware voor de automatisering van primaire processen binnen strategische marktsegmenten (lokale) overheid, woningcorporaties, groothandel, bouw, retail, transport en logistiek, uitgeverijen, zorg, lease en non-profit. De divisie IT Solutions is te onderscheiden in verschillende clusters en onderdelen: Public Sector Solutions; Real Estate Solutions; Supply Chain Solutions; Healthcare Solutions; General Solutions; Systems & Services. Deze afstudeeropdracht is uitgevoerd op de businessunit Persoonsinformatievoorziening (BU PIV) binnen het cluster Public Sector Solutions. De BU PIV ondersteunt onder andere gemeenten bij het uitvoeren van wettelijke taken op het gebied van Burgerzaken door het leveren van de procesapplicatie Key2Burgerzaken. Met Key2Burgerzaken registreert en beheert een gemeente de persoonsgegevens van al haar inwoners. 8

10 1.2 Key2Burgerzaken Key2Burgerzaken is een applicatie die gemeenten ondersteunt met het uitvoeren van haar burgerzaken processen. Deze applicatie functioneert als BackOffice systeem bij de gemeenten. Burgerzaken valt uiteen in een aantal aandachtsgebieden waaronder de volgende: Burgerlijke Stand; GBA; Reisdocumenten; Rijbewijzen; Uitreksels. Onderstaand een impressie van Key2Burgerzaken: Figuur 7 Interface Key2Burgerzaken Key2Burgerzaken ondersteunt 216 gemeenten die samen 10.3 miljoen inwoners vertegenwoordigen. Met Key2Burgerzaken wordt wetgeving procesmatig ondersteund op het gebied van: Burgerlijke stand; Verklaring Omtrent Gedrag; Reisdocumenten; Rijbewijzen; Verkiezingen; Bescherming Persoonsgegevens; Vreemdelingen; Rampenbestrijding; Archivering; Bestuursrecht; GBA Audit. Buiten de hierboven beschreven standaard functionaliteiten, is Key2Burgerzaken uit te breiden met Optionele Modules. Deze bestaan onder andere uit de modules Naturalisatie, Raadplegen derden, Verkiezingen en Digitaal Aanleveren Overlijden. 9

11 1.3 Achtergrond en aanleiding voor opdracht De gemeentelijke basisadministratie persoonsgegevens (GBA) bevat persoonsgegevens van iedereen die in Nederland woont of gewoond heeft. De overheid heeft deze gegevens nodig om bijvoorbeeld een paspoort, identiteitskaart of rijbewijs te verstrekken. Ook gebruikt de overheid de gegevens uit de GBA om te weten wie er mogen stemmen bij verkiezingen en bij het verstrekken van uitkeringen. Centric levert met Key2Burgerzaken een geautomatiseerde oplossing voor het uitvoeren van bovengenoemde taken. Binnen het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties is een programma gestart onder de naam Modernisering GBA (mgba). Dit programma heeft als doel de GBA gereed te maken voor de toekomst. In de vorm van de nieuwe Basisregistratie Personen (BRP) draagt deze bij aan de dienstverlening aan burgers, bedrijven en overheidsorganisaties en maakt het deel uit van het stelsel van basisregistraties. De vernieuwing van de GBA maakt plaatsonafhankelijke dienstverlening mogelijk en het bijhouden en verstrekken van gegevens wordt sneller, eenvoudiger en goedkoper. Op dit moment is de applicatie Key2Burgerzaken volledig ingericht op het huidige GBA stelsel. Met de komst van het programma mgba wordt de inrichting van het GBA stelsel vernieuwd. Het mgba project zal voor directe consequenties zorgen voor de applicatie Key2Burgerzaken. Voor Centric ligt hier de uitdaging om een werkbare situatie voor haar klanten te creëren en te voldoen aan de standaarden die gesteld worden door de overheid. 10

12 1.4 Probleem & Onderzoeksdoelstelling Het programma mgba heeft consequenties voor de procesapplicatie Key2Burgerzaken. De huidige GBA is sterk activiteit georiënteerd in tegenstelling tot de BRP. De BRP gaat uit van procesgericht werken, waarbij alle gebeurtenissen in het (klant)proces worden vastgelegd. Van het eerste contactmoment met de burger tot het archiveren. In Key2Burgerzaken is deze nieuwe werkwijze slechts deels aanwezig, waardoor aanpassingen in de applicatie noodzakelijk zijn. Afronding van de implementatie van mgba is vastgesteld medio Probleemstelling Met de komst van de mgba zal zowel de gemeenten als Centric voor uitdagingen komen te staan. De uitdaging voor Centric is, het zodanig aanpassen van Key2Burgerzaken dat het voldoet aan de gestelde standaarden van de overheid en het optimaal ondersteunen van de burgerzaken processen van de gemeenten. Hieruit is de volgende centrale probleemstelling met de bijbehorende deelvragen ontstaan: Hoofdvraag: Hoe kan Centric Key2Burgerzaken aanpassen zodat deze voldoen aan de door de overheid gestelde eisen van het programma mgba. En wat zijn de gevolgen hiervan? Deelvraag1: Wat is de huidige en gewenste situatie (na invoering mgba) van de processen 1 van Key2Burgerzaken? Deelvraag2: Welke aanpassingen moeten er plaatsvinden in Key2Burgerzaken om vanuit de huidige situatie van Key2Burgerzaken te komen tot de gewenste situatie (na invoering mgba)? Deelvraag3: Welke gevolgen heeft het programma mgba voor de gebruikers van Key2Burgerzaken Deelvraag4: Welke aanpak kan Centric hanteren om tot de gewenste situatie van de processen te komen De uitwerkingen van de deelvragen zijn ondersteunend voor het antwoord op de hoofdvraag. 1 Deze processen zijn nader gedefinieerd in hoofdstuk 2.3 Scope van het onderzoek 11

13 1.4.2 Onderzoeksdoelstelling Centric wil met dit project te weten komen welke aanpassingen er gedaan moeten worden in Key2Burgerzaken, wat de gevolgen zijn voor de gebruikers van Key2Burgerzaken en welke aanpak Centric kan hanteren om deze verandering te bewerkstelligen. Centric wil een overzicht zien met hierin de verhoudingen tussen de gestelde eisen en de huidige versie van Key2Burgerzaken. Het doel van dit project is, het inzichtelijk maken van de 'gaten' tussen de huidige en gewenste situatie en bijbehorend de impact op de burgerzakenprocessen. Centric verwacht van beide aspecten een overzicht waarin in één oogopslag te zien is wat de verhoudingen zijn tussen de huidige en gewenste situatie. 12

14 1.4.3 Scope van het onderzoek Het programma mgba erkent meerdere applicaties en stakeholders. Dit onderzoek beperkt zich tot een onderzoek naar de applicatie Key2Burgerzaken en de stakeholders, Centric en gemeenten. Er zal worden gekeken naar de huidige en gewenste situatie en de gevolgen voor de gebruikers van Key2Burgerzaken. De mgba heeft consequenties voor alle burgerzaken processen. De tijd die staat voor dit project is te kort om alle processen te analyseren, hierdoor is er gekozen voor de analyse van de volgende processen: Procesnaam Aangifte overlijden Eerste Inschrijving en Hervestiging Aanvragen reisdocumenten Tabel 1 Processen Argument Ondersteunend voor prototype op beurs Overheid en ICT Door de complexiteit van deze processen is inzicht hierover gewenst Onder de analyse van de processen wordt verstaan, het onderzoeken van de processen en het uitwerken van een procesbeschrijving. De processen worden uitgewerkt in volgorde van de bovenstaande prioriteit. 13

15 1.5 Onderzoeksaanpak De gehanteerde aanpak voor dit onderzoek is de FIT-GAP analyse. Er is gekozen voor deze aanpak omdat onderzocht dient te worden welke gaten (GAPS) er tussen de huidige en gewenste situatie zijn. Bij deze analyse zijn een aantal instrumenten gebruikt om tot de oplossing van de deelvragen te komen: Instrument Gebruikt voor Toegepast op deelvraag BPMN In kaart brengen processen Één huidige situatie Argumentatie Beschikking over praktische en theoretische kennis opgebouwd tijdens stages en de minor BPM. MosCow methodiek Onderzoeksresultaten Twee Aangeleverde methodiek door de overheid om te hanteren bij de requirements. Figuur 8 Toegepaste methodieken Met behulp van de handleidingen van Key2Burgerzaken en informatie over het GBA en BRP-stelsel is de huidige en gewenste situatie onderzocht (deelvraag één). Deze weergave is belangrijk om te illustreren welke veranderingen op hoofdlijnen plaatsvinden. Ook zijn interviews gehouden met medewerkers van Centric en de gemeente Apeldoorn. Resultaat hiervan is de omschrijving van de bedrijfsprocessen zoals gedefinieerd in het hoofdstuk Scope van het project. Hiermee is deelvraag één beantwoord. Aan de hand van de onderzoeksresultaten van deelvraag één, is onderzocht welke aanpassingen gemaakt moeten worden in Key2Burgerzaken (deelvraag twee). Hiermee is duidelijk geworden hoe Key2Burgerzaken zich verhoudt tot de gewenste situatie. Aanvullend op de uitkomsten van deelvraag één en twee, is onderzocht welke gevolgen deze aanpassingen hebben voor de gebruikers van Key2Burgerzaken (deelvraag drie). Met de resultaten die leiden tot de beantwoording van de bovenstaande deelvragen, is een aanbeveling gemaakt voor de aanpak die gehanteerd kan worden door Centric om te komen tot de gewenste situatie (deelvraag vier). 14

16 Tijdens het onderzoek zijn een aantal bronnen van cruciaal belang geweest om te komen tot de onderzoeksresultaten. Onderstaand een schema met de belangrijkste bronnen, de hoofdstukken waarin deze geraadpleegd zijn en de deelvragen die hiermee ondersteunt worden: Bron Verwerkt in hoofdstuk Deelvraag Hoofdstuk 2,Huidige situatie Één GBA Architectuur_van_het_BRP-stelsel.PDF Hoofdstuk 3, Gewenste situatie Één mgba Handleiding_uitvoeringsprocedures.PDF Hoofdstuk 4, Processen huidige Één situatie Burgerzaken modules BZK v0.9 Module 09 _Overlijden_.pdf Hoofdstuk 5, Onderzoeksresultaten BZM en processen Twee en drie Burgerzaken modules BZK v0.9 Module 05 _Migratie_.pdf Burgerzaken modules BZK v0.9 Module 07 _Reisdocumenten_.pdf GBA-planning opnieuw niet haalbaar, Automatisering Gids nr. 16, 2011 Hoofdstuk 5, Onderzoeksresultaten BZM en processen Hoofdstuk 5, Onderzoeksresultaten BZM en processen Hoofdstuk 7, Conclusie en aanbevelingen Twee en drie Twee en drie Twee en drie Op zoek naar 132 miljoen, Automatisering Gids nr. 43, 2010 GBA laat gemeenten koud, Automatisering Gids nr. 21, 2010 Figuur 9 Bronnen, hoofdstukken en deelvragen Hoofdstuk 7, Conclusie en aanbevelingen Hoofdstuk 7, Conclusie en aanbevelingen Vier Vier Een overzicht van alle bronnen zijn terug te vinden in het hoofdstuk Literatuur. 15

17 1.6 Structuur van scriptie Nu duidelijk is geworden wat de opdracht is en waar deze zich afspeelt, wordt in hoofdstuk twee de huidige situatie van het GBA stelsel en bijbehorende processen behandeld. In dit hoofdstuk wordt deelvraag één beantwoord: wat is de huidige situatie van de processen van Key2Burgerzaken? Vervolgens in hoofdstuk drie de beschrijving van het nieuwe GBA stelsel (gewenste situatie). In hoofdstuk vier komen de onderzoeksresultaten aan bod die antwoord geven op deelvraag twee: welke aanpassingen moeten plaatsvinden om te komen tot de gewenste situatie (mgba)? In dit hoofdstuk is per proces weergegeven wat de gevolgen zijn van het doorvoeren van de voorgestelde functionaliteiten op de processen. Hierin wordt ook antwoord gegeven op deelvraag drie: welke gevolgen heeft het programma mgba voor de gebruikers van Key2Burgerzaken? Hoofdstuk vijf bevat de investeringsanalyse met betrekking tot de te implementeren functionaliteiten. In hoofdstuk zes komen de conclusie en aanbevelingen aan bod. Tot slot wordt er een implementatieplan weergegeven om antwoord te geven op deelvraag vier. Hierin wordt duidelijk welke aanpak Centric kan hanteren om tot de gewenste situatie te komen. 16

18 2 HUIDIGE SITUATIE GBA Onder de huidige situatie van dit project wordt verstaan het GBA-stelsel en de bijbehorende processen gedefinieerd in het hoofdstuk Scope van het project. Dit hoofdstuk zal antwoord geven op deelvraag één. 2.1 Huidige situatie GBA-stelsel In dit hoofdstuk wordt het stelsel van de Gemeentelijke Basisadministratie, hierna te noemen GBA, beschreven. Key2Burgerzaken is (in)direct onderdeel van dit stelsel. Deze beschrijving geeft de context van dit project weer, illustreert welke (externe)partijen een rol spelen in het stelsel en schetst de basis voor de verandering die de mgba in werking stelt Het GBA-stelsel De GBA bestaat sinds 1 oktober Voorheen werden persoonsgegevens geregistreerd op een persoonskaart. Deze persoonskaarten zijn overgenomen in de GBA database. In de GBA staan persoonsgegevens van elke inwoner van Nederlands. Binnen het GBA-stelsel worden alle gegevens volledig geautomatiseerd opgeslagen en uitgewisseld. Geboorte, verhuizing, huwelijk, vertrek naar het buitenland, overlijden: de GBA bevat alle algemene persoonsgegevens en wijzigingen daarop, van de wieg tot aan het graf. Van elke inwoner van Nederland wordt in de GBA een persoonslijst aangelegd. De GBA registreert de administratieve levensloop van een burger. In Nederland zijn 418 gemeenten (Lijst van Nederlandse gemeenten, Wikipedia 2011) die allemaal over een GBA beschikken. Op de GBA wordt wet en regelgeving (Wet GBA) toegepast waaraan leveranciers van softwaresystemen zich moeten houden. De procedurele inrichting verschilt per leverancier. De GBA kenmerkt zich doordat gegevens ten behoeve van afnemers worden opgeslagen bijvoorbeeld voor de belastingdienst, pensioenfondsen of voor de sociale verzekeringen. Deze instanties voeren een publiekrechtelijke taak uit en hebben hiervoor persoonsgegevens nodig. Deze instanties moeten op de hoogte gehouden worden van wijzigingen van persoonsgegevens. Het GBA is ontstaan uit deze behoefte. De afnemers betalen hiervoor per bevraging een bedrag aan het ministerie van Binnenlandse Zaken ( 0,15). Bij een wijziging van persoonsgegevens wordt gekeken welke afnemers deze gewijzigde gegevens dienen te ontvangen en worden verzonden. Deze wijzigingen worden gestuurd middels het GBA Berichtenverkeer. 17

19 De overheid beschikt over verschillende systemen om gegevens vast te leggen. Bepaalde gegevens worden daardoor in meerdere systemen geregistreerd en bijgehouden. Om dit proces te vereenvoudigen en de dienstverlening te verbeteren is door de overheid besloten een stelsel van basisregistraties te implementeren. Dit stelsel zorgt ervoor dat elk (basis)gegeven één bron kent. Gegevens zullen daardoor betrouwbaarder, actueler en uitwisselbaar zijn. Een basisregistratie erkent zich door authentieke gegevens, dit houdt in dat er door de wet is vastgesteld aan welke verplichtingen moeten worden voldaan op het gebied van de registratie van gegevens. Het GBA maakt deel uit van dit stelsel. Zie onderstaande illustratie voor de grafische weergave van het stelsel: Figuur 10 Stelsel van Basisregistraties 18

20 2.1.2 Communicatie Figuur 11 GBA Stelsel Binnen het stelsel van de GBA heeft elke gemeente en afnemer een elektronische GBA-mailbox. Alle wijzigingen van persoonsgegevens worden via deze postbussen doorgegeven. Zo stuurt bijvoorbeeld een gemeente de gegevens over een vertrek van één van haar inwoners, naar de elektronische postbus van de gemeente waar de inwoner naar toe verhuist. Ook de GBA-afnemers krijgen via de eigen GBA-mailbox de gewijzigde adresgegevens aangeleverd. Deze onderlinge communicatie wordt het GBA berichtenverkeer genoemd. Dagelijks worden zogenaamde batchprocessen uitgevoerd in Key2Burgerzaken waarmee alle berichten worden verstuurd en ontvangen. Met deze manier van werken kan het voorkomen dat, na het uitvoering van een batchproces, een aanvraag is gedaan voor persoonsgegevens uit een andere gemeente. Hierdoor worden de gegevens pas de volgende dag verstuurd en duurt het minimaal vierentwintig uur voordat het antwoord is ontvangen. Deze architectuur is al zeventien jaar operationeel en wordt in stand gehouden doordat de kosten worden betaald door de afnemers van deze persoonsgegevens. Behalve informatie-uitwisseling tussen gemeenten wordt ook gecommuniceerd met Rijksoverheidsdiensten zoals de Rijksdienst voor Wegverkeer (RDW). Deze communicatie is noodzakelijk voor het leveren van producten van de burgerzakenprocessen. Bijvoorbeeld in het geval van het aanvragen van een rijbewijs, wordt gecommuniceerd met de RDW om te verifiëren of een rijbewijs aangevraagd mag worden. Deze communicatie vindt plaats door middel van interactieve webservices. Deze communicatie beperkt zich tot het opvragen van informatie (vraag en antwoord). 19

21 2.1.3 Afnemers Afnemers van persoonsgegevens zijn overheids- en semi-overheidsorganisaties die op de hoogte gehouden moeten worden van de wijzigingen in de persoonsgegevens om haar wettelijke taak uit te kunnen voeren. Hiervoor kunnen afnemers bij de betreffende gemeente een zogenoemde afnemersindicatie laten plaatsen. Voor elke mutatie die uitgevoerd wordt over de betreffende persoonsgegevens wordt automatisch een bericht aangemaakt en verstuurd naar de afnemer. Voordat deze afnemersindicatie geplaatst kan worden moet de afnemer geautoriseerd worden door de minister van Binnenlandse Zaken. Figuur 12 GBA Berichtenverkeer Terugmeld Voorziening (TMV) Er wordt gesteld dat de gegevens in de GBA correct zijn, maar het kan zijn dat de afnemers die gebruik maken van de gegevens nieuwe informatie hebben over de vastgestelde gegevens in de GBA. Hiervoor is de terugmeld voorziening (TMV) ontworpen. De afnemer van de gegevens kan melden aan de TMV, dat de gegevens mogelijk incorrect zijn. Het kan voorkomen, dat meerdere afnemers melden dat de bepaalde gegevens mogelijk incorrect zijn. De TMV maakt van deze informatie een dossier aan en verstuurd dit naar de gemeente waar de betreffende burger ingeschreven staat. Deze gemeente is verplicht om binnen vijf werkdagen dit dossier te behandelen en een onderzoek in te stellen. De TMV stelt de afnemer, die de mogelijk incorrecte gegevens gemeld heeft bij de TMV, in kennis over het verloop van het onderzoek. Zolang het onderzoek loopt mag de afnemer afwijken van de geregistreerde gegevens in de GBA. 20

22 2.1.5 Beheervoorziening Burgerservicenummer (BV BSN) De BV BSN staat voor Beheervoorziening Burgerservicenummer. Op 26 november 2007 is de wet algemene bepalingen burgerservicenummer (Wabb) in werking getreden. Deze wet stelt dat iedere inwoner van Nederland die ingeschreven is in de GBA, een burger servicenummer (BSN) moet hebben. De uitgifte van een BSN wordt verzorgd door de gemeente. Bijvoorbeeld als een geboorte plaatsvindt wordt het BSN toegekend door de gemeente. Deze nummers worden geleverd door de BV BSN. De gemeente vraagt periodiek een voorraad met BSN s op. De BSN s worden opgeslagen in de lokale GBA-database van de gemeenten waarna deze verstrekt worden in willekeurige volgorde. De BV BSN houdt bij welke nummers aan gemeenten worden uitgegeven GBA-V Het GBA-V is een onderdeel van het GBA-stelsel en komt voort uit de modernisering van de GBA. Het GBA-V is een centraal systeem met een database voor de verstrekking van GBA- gegevens aan afnemers. De gegevens in de database zijn een kopie van de gegevens (persoonslijsten) in de verschillende GBA-systemen bij de gemeenten. Iedere wijziging in de GBA-gegevens bij een gemeente leidt tot een synchronisatiebericht aan GBA-V en daarmee tot een actualisatie van de persoonslijst waarop de wijziging betrekking heeft. Afnemers hebben vaak een informatiebehoefte die gemeentegrenzen overstijgt, zoals het opzoeken van de persoonsgegevens van een bepaalde burger waarvan de afnemer op voorhand niet weet in welke gemeente deze woont. Voor de beantwoording van deze ad-hoc vragen van kunnen afnemers terecht bij de voorziening GBA-V. Het verschil tussen het afnemen van gegevens bij gemeenten en het GBA-V is dat bij het GBA-V alleen complete persoonslijsten kunnen worden afgenomen. Een pensioenfonds is bijvoorbeeld alleen geïnteresseerd in de mutatie van de persoonsgegevens van een persoon, de GBA-V biedt deze mogelijk niet. Ook in verband met de privacy wetgeving is het niet mogelijk/wenselijk om gehele persoonslijsten te versturen aan afnemers die uitsluitend geautoriseerd zijn voor een gedeelte van de persoonslijst Logisch ontwerp Het logisch ontwerp (LO) beschrijft de minimaal te stellen functionele eisen aan de aangesloten systemen en aan het GBA-netwerk. Het LO moet de centrale overheid een instrument in handen geven om de consistentie en de kwaliteit van de persoonsgegevens en de gegevensverstrekking naar de afnemers te garanderen. Het LO is opgesteld conform de Wet Gemeentelijke Basisadministratie persoonsgegevens (Wet GBA). De Wet GBA stelt de juridische verplichtingen waaraan de GBA moet voldoen. Marktpartijen (waaronder Centric) bouwen op basis van het Logisch Ontwerp softwarepakketten die deze wetgeving ondersteunt. 21

23 2.1.8 Kenmerken GBA stelsel Het huidige GBA stelsel kenmerkt zich door het volgende: Decentrale opslag van persoonsgegevens; Gemeenten communiceren onderling via het GBA-Netwerk op basis van het GBA berichtenverkeer; Indien er gegevens uitgewisseld worden is er sprake van een asynchrone communicatie; Het kan voorkomen dat het 48 uur duurt voordat de benodigde gegevens beschikbaar zijn; Afnemers communiceren ook met de gemeenten, deze betalen hiervoor een vergoeding van 0,15 per bevraging; Afnemers moeten geautoriseerd zijn bij de betreffende gemeente; Alle wijzigingen die plaatsvinden in de lokale GBA, worden met vertraging doorgestuurd naar de GBA-V; In de GBA-V staat een kopie van alle persoonslijsten van de 418 gemeenten in Nederland. 22

24 2.2 Processen huidige situatie Nu het duidelijk is geworden hoe het GBA stelsel functioneert, wordt in dit hoofdstuk aandacht besteed aan drie processen zoals deze uitgevoerd worden in het huidige GBA stelsel. Deze processen vallen onder de modulen: Overlijden; Migratie; Reisdocumenten. Er is per module één proces uitgewerkt (zie ook hoofdstuk Scope van het project). De processen van de huidige situatie zijn uitgewerkt in de Business Process Management Notation (BPMN). Deze modellen geven inzicht in de processen bij de gemeenten en de processtappen waarin Key2Burgerzaken deze gemeenten ondersteunen. In bijlage 6 is een legenda van de BPMN te vinden. Deze processen zijn gebaseerd op de werkwijze van de gemeente Apeldoorn Overlijden Een aangifte van overlijden kan voorkomen voor de volgende situaties: Overlijden in Nederland; Overlijden niet in Nederland; Lijkvinding; Levenloos geboren kind. Het proces dat onderzocht is, is overlijden in Nederland en erkent de rollen Ambtenaar burgerlijke stand en begrafenisondernemer (aangever). Indien iemand overleden is dient hiervan aangifte te worden gedaan bij de gemeente waar het overlijden heeft plaatsgevonden. Dit is wettelijk bepaald in de 'Wet op de Lijkbezorging'. Na het vaststellen van de dood zal de arts de A-verklaring en de B-verklaring afgeven aan de aangever. De A-verklaring is het document waarop de naam van de overledene staat, de geboorte- en overlijdensdatum. Dit formulier is voor iedereen ter inzage. De B-verklaring is een formulier waarop de arts de oorzaak van het overlijden invult. Dit formulier is bedoeld voor het CBS en wordt door de arts in een B-Enveloppe geplaatst, van zijn handtekening voorzien en gesloten meegegeven aan de aangever. Zowel de A-verklaring als de B-enveloppe worden door de aangever meegenomen voor de aangifte bij de burgerlijke stand. Het overhandigen van de formulieren is de start voor het proces aangifte overlijden bij de gemeente waar het overlijden heeft plaatsgevonden. Dit gebeurt meestal door een begrafenisondernemer. De gemeente registreert de aangifte in Key2Burgerzaken middels het aanmaken van een dossier in de module Burgerlijke Stand van Key2Burgerzaken. Hierin worden de aangiftegegevens, de persoonsgegevens en de gegevens van de gerelateerde van de overledene geregistreerd. Indien sprake is van onjuistheid van deze (persoons)gegevens, worden de afwijkende gegevens ingevoerd in het dossier en wordt er een verzoek verstuurd naar een GBA specialist om een onderzoek in te stellen naar deze (persoons)gegevens. Hierna wordt de akte opgemaakt in Key2Burgerzaken en geprint. Zowel de ambtenaar van de burgerlijke stand als de begrafenisondernemer ondertekent deze akte waarna deze gepasseerd wordt in Key2Burgerzaken. Bij het passeren van een akte bevestigt de ambtenaar van de burgerlijke stand dat de akte ondertekend is. 23

25 Na het passeren van de akte wordt de persoonslijst van de overledene automatisch bijgewerkt (status O, opgeschort). De ambtenaar van de burgerlijke stand drukt een verlof tot lijkbezorging af, ondertekent deze en overhandigt deze aan de begrafenisondernemer. Vervolgens wordt er op de B- enveloppe het aktenummer en de gemeentecode geschreven. Deze B-Enveloppe wordt ongeopend verstuurd naar het CBS. Opgave van de doodsoorzaak voor het CBS is verplicht op grond van artikel 12A van de Wet op de lijkbezorging. Alle documenten die worden geproduceerd door dit proces zijn opgenomen in de bijlage 1 t/m 4. Onderstaand het proces aangifte overlijden: Figuur 13 Aangifte overlijden 2 2 Zie bijlage 7 voor de vergrote versie van het processchema. 24

26 2.2.2 Migratie Op de afdeling burgerzaken zijn een aantal situaties van migratie te onderkennen. Er is sprake van een: Eerste inschrijving op basis van aangifte van verblijf en adres; Hervestiging vanuit het buitenland; Verhuizing binnen Nederland; Vertrek naar het buitenland (emigratie). De processen eerste inschrijving op basis van aangifte van verblijf en adres en hervestiging vanuit het buitenland zijn in dit hoofdstuk geanalyseerd. Eerste inschrijving op basis van aangifte van verblijf en adres Er is sprake van een eerste inschrijving als iemand zich voor het eerst vestigt in Nederland of iemand eerder ingeschreven heeft gestaan in Nederland, maar deze datum ligt voor (ingangsdatum wet GBA). De burger is verplicht om zich binnen vijf dagen te laten inschrijven bij de gemeente waar hij of zij zich wil vestigen. De burger dient hier een afspraak voor te maken met de betreffende gemeente. Er zijn twee situaties te herkennen namelijk: De aangever beschikt over brondocumenten; De aangever beschikt niet over brondocumenten. Deze procesbeschrijving gaat uit van een aangever die over brondocumenten beschikt. In het geval van een eerste inschrijving maakt de aangever een afspraak met de afdeling burgerzaken van de betreffende gemeente om zich in te schrijven. Direct bij aankomst wordt de aangever gevraagd zijn of haar brondocumenten te overhandigen. De medewerker van de gemeente overhandigt het formulier Inlichtingenformulier GBA waarop de aangever al zijn persoonsgegevens dient in te vullen en terug te geven aan de medewerker van de gemeente. Vervolgens controleert de medewerker van de gemeente de brondocumenten op echtheid in het systeem DISCS (Document Information System for Civil Status). Deze processtap is optioneel en wordt naar wens van de betreffende gemeente uitgevoerd. In dit systeem staan de richtlijnen en echtheidskenmerken waaraan een brondocument moet voldoen. Wordt getwijfeld aan de validiteit van het brondocument dan wordt deze ingenomen voor nader onderzoek. Indien de brondocumenten gevalideerd zijn, wordt gecontroleerd op de identiteit van de aangever. Kan de identiteit van de aangever niet vastgesteld worden, dan wordt het proces direct afgebroken. Indien de identiteit van de aangever wel vastgesteld kan worden wordt een controle uitgevoerd bij de Beheersvoorziening BSN (BV BSN). Hiermee wordt gecontroleerd of een persoon al eerder ingeschreven is geweest in Nederland. Is de persoon al eerder ingeschreven in Nederland na , dan wordt het proces hervestiging gestart. Is de persoon nog niet eerder ingeschreven geweest in Nederland, dan wordt er aan de hand van het ingevulde Inlichtingenformulier GBA en de overgelegde brondocumenten een persoonslijst aangemaakt in Key2Burgerzaken. Dit geschied in via de procedure Immigratie. 25

27 Als de persoonslijst is aangemaakt, dient deze gecontroleerd te worden door een medewerker van de afdeling burgerzaken. Indien er fouten op de persoonslijst zijn geconstateerd, actualiseert de verantwoordelijke medewerker de persoonslijst. Is de persoonslijst als correct beoordeeld, wordt een complete uitdraai gemaakt van de persoonslijst en deze per post verstuurd naar de aangever. Figuur 14 Eerste inschrijving 3 Hervestiging vanuit het buitenland Er wordt gesproken van een hervestiging als een persoon zich hervestigt vanuit het buitenland. Voorwaarde is dat deze persoon na uitgeschreven is uit de GBA. Dit heeft ermee te maken dat per de wet GBA in werking is getreden. Met de komst van deze wet is vanaf deze datum verplicht om voor elke ingezetene een persoonslijst aan te leggen. In het geval van een hervestiging meldt de aangever zich bij de balie van de afdeling burgerzaken. Als eerst wordt het legitimatiebewijs overhandigd waarmee de medewerker burgerzaken de persoon gaat identificeren. Als de aangever geen geldig legitimatiebewijs bezit kan er aan de hand van de vragenlijst identificatie geïdentificeerd worden. Is de persoon geïdentificeerd dan wordt geverifieerd bij de BV BSN of de persoon bekend is. Aan de hand van de uitkomst hiervan kan het zijn dat de aangever al eerder in deze gemeente gewoond heeft of de persoon uit een andere gemeente komt. Komt de persoon uit een andere gemeente, dan dient deze persoonslijst via het GBA netwerk opgehaald te worden. Komt de persoon oorspronkelijk uit de eigen gemeente dan kan deze opgezocht worden in de lokale GBA. Hierna wordt gecontroleerd of het adres bewoond is. Is het adres niet bewoond, dan wordt het formulier Wijziging persoonsgegevens overhandigd. Op het formulier verklaart de aangever of wijzigingen zijn voorgekomen op de persoonsgegevens (en zo ja welke) gedurende het verblijf in het buitenland. Is het adres wel bewoond dan dient aanvullend, een toestemmingsformulier ingevuld en ondertekend te worden door de hoofdbewoner van het adres waar de aangever zich wil vestigen. Als de formulieren ingeleverd zijn, maakt de medewerker Burgerzaken een kopie van het legitimatiebewijs. Hierna wordt de persoon via de procedure Inschrijving in Key2Burgerzaken hervestigt en wordt een bewijs van inschrijving afgedrukt een meegegeven aan de aangever. 3 In bijlage 8 is een vergrote versie van het processchema te vinden. 26

28 Figuur 15 Proces hervestiging 4 4 In bijlage 9 is een vergrote versie van het processchema te vinden. 27

29 2.2.3 Reisdocumenten De module reisdocumenten bevat de volgende processen: Aanvragen reisdocument; Inklaren reisdocumenten; Uitreiken reisdocument; Inleveren reisdocument; Vermissing reisdocument; Teruggeven reisdocument; Aanschrijven reisdocument; Actualiseren signaleringen. Het proces dat onderzocht is, is aanvragen reisdocument. De aanvrager, woonachtig in Nederland, kan een nieuw reisdocument aanvragen bij de gemeente waar deze staat ingeschreven in de GBA. Een nieuw reisdocument moet in persoon worden aangevraagd. De aanvrager doet dit bij de afdeling burgerzaken van de betreffende gemeente. In dit proces is een aanvraag van een nieuw Nederlands paspoort als voorbeeld genomen. Het proces wordt gestart door de burger die een aanvraag voor een nieuw reisdocument indient bij de gemeente. In dit geval voor een Nederlands paspoort. Bij deze aanvraag worden de verlopen reisdocumenten en een recente pasfoto overhandigt aan de medewerker burgerzaken. Deze medewerker controleert de identiteit van de aangever. Kan de aangever zichzelf niet identificeren dan wordt het proces afgebroken. Indien de aangever geïdentificeerd kan worden wordt gecontroleerd of de aangever woonachtig is in de gemeente waarvoor de medewerker burgerzaken bevoegd is om reisdocumenten voor aan te vragen. Is dit niet het geval dan wordt het proces afgebroken omdat in de paspoortwet is vastgelegd dat de gemeente alleen voor ingezetenen van de eigen gemeente reisdocumenten mag aanvragen en uitreiken. Woont de aanvrager in de eigen gemeente, dan worden de oude reisdocumenten ingehouden en als zodanig ingevoerd in Key2Burgerzaken. 28

30 Vervolgens wordt de aanvraag ingevoerd in Key2Burgerzaken, het aanvraagformulier Reisdocumenten NGR ingevuld en wordt de pasfoto van de aanvrager bevestigt aan dit formulier. Dit formulier dient geaccordeerd te worden door de aanvrager. Op dit formulier staat een aanvraagnummer welke ingevoerd dient te worden in Key2Burgerzaken. Hierna wordt de aanvraag bevestigd en verstuurd naar het Reisdocumenten Aanvraag en Archief Station (RAAS). Het aanvraagformulier dat inmiddels is geaccordeerd, wordt gescand en voorzien van een vingerafdruk van de aanvrager. Het aanvraagformulier in combinatie met de vingerafdruk wordt verstuurd naar het RAAS. Als laatste wordt er verzocht het verschuldigde bedrag te betalen aan de gemeente. De aanvrager krijgt een kassabon en een afhaalbewijs voor het aangevraagde reisdocument. Figuur 16 Aanvraag Nederlands paspoort 5 5 In bijlage 10 is een vergrote versie van het processchema te vinden. 29

31 3 GEWENSTE SITUATIE MODERNISERING GEMEENTELIJKE BASISADMINISTRATIE In het vorige hoofdstuk is ingegaan op het huidige GBA-stelsel en de bijbehorende processen. In dit hoofdstuk wordt ingegaan op de modernisering Gemeentelijke BasisAdministratie (mgba) welke invloed heeft op dit stelsel. Het uitgangspunt is de Basis Registratie Personen (BRP) dat onderdeel is van de mgba en het huidige GBA-stelsel zal vervangen. 3.1 Modernisering GBA en de BRP Het programma mgba is ontstaan uit het bestuurlijk akkoord GBA dat gesloten is in 2009 (bestuurlijk akkoord GBA, 2009). De BRP vloeit voort uit het ontstaan van het stelsel van basisregistraties, waarbij de BRP er één van is. Omdat er ook wensen waren voor het vernieuwen van de gegevensset van de GBA is deze verandering ondergebracht bij het programma mgba. Het huidige GBA stelsel zal komen te vervallen en hiervoor komt de Basis Registratie Personen voor in de plaats. Het programma mgba maakt de huidige GBA gereed voor de toekomst. Hiermee wordt de nieuwe wet BRP bedoeld welke plaatsonafhankelijke dienstverlening wettelijk mogelijk maakt (concept wet BRP, 2010). In de vorm van de nieuwe BRP draagt deze bij aan de dienstverlening aan burgers, bedrijven en overheidsorganisaties. De vernieuwing van de GBA maakt het bijhouden en verstrekken van gegevens wordt sneller, eenvoudiger en goedkoper (Projectinitatiedocument Implementatie mgba hoofdstuk 2, 2011). De Basisregistratie Personen gaat het huidige GBA stelsel vervangen, dit komt samen met een voorgestelde wetswijziging. Het uitgangspunt van de BRP is het voorzien in een centrale opslag van persoonsgegevens en verstrekkingen hiervan. Onderstaand een illustratie van de communicatie in het huidige GBA stelsel en de BRP: Figuur 17 GBA Figuur 18 BRP 30

32 3.2 Communicatie Figuur 19 Architectuur BRP Waar in het huidige stelsel de gemeenten onderling communiceren om gegevens uit te wisselen, zal er met de komst van de BRP gecommuniceerd worden met de Burgerzaken Systeem Kern (BZS-K). Daar waar voorheen de doorlooptijd 2x24 uur was voordat de gewenste informatie beschikbaar werd gesteld, is dit nu verleden tijd. Doordat de gegevens centraal staan en gebruikt wordt gemaakt van webservices, kan de betreffende gemeente real-time over de gewenste gegevens beschikken. In de communicatie tussen de rijksoverheidsdiensten verandert weinig ten opzichte van het huidige stelsel. Het enige dat verandert is, dat de aanvragen van deze rijksoverheidsdiensten met betrekking tot persoonsgegevens centraal worden afgehandeld. 31

33 In het BRP-stelsel wordt gecommuniceerd op basis van het StUF-BRP. StUF-BRP 6 staat voor Standaard Uitwisselings Formaat Basis Registratie Personen. StUF-BRP wordt verplicht gesteld voor de gemeenten om te hanteren als standaard, voor communicatie met de BRP. Het StUF-BRP zal worden gebruikt voor het ontvangen van meldingen (terug- en bijhoudingsmeldingen), het raadplegen van de BRP, het bijhouden van de BRP en het ontvangen van leveringen. Dit worden ook wel koppelvlakken genoemd. Onderstaande tabel geeft een overzicht van deze koppelvlakken en de definitie hiervan (Projectstartarchitectuur Burgerzaken Modules_versie 1.3_concept, 2010): Naam BRP levering BRP bevraging BRP bijhouding BRP terugmelding Figuur 20 Koppelvlakken Definitie De dienst waarmee, op initiatief van de BRP, persoonsgegevens worden geleverd aan gebruikers die hiertoe geautoriseerd zijn. Hiernaast biedt deze dienst functies aan de beheerorganisatie en aan de afnemers om abonnementen te onderhouden. De dienst voor alle bevragingen door gebruikers van de BRP; dit omvat zowel gemeenten, als afnemers. Het initiatief ligt binnen deze dienst bij de gebruiker(s). Dit koppelvlak biedt diensten voor het invoeren, muteren en controleren van persoonsgegevens ten behoeve van de bijhoudingsprocessen. Deze dienst heeft betrekking op het verwerken van terugmeldingen over persoonsgegevens 6 Deze standaard is op het moment van schrijven nog niet gedefinieerd 32

34 3.3 Burgerzakensysteem-Kern en de Burgerzakenmodules In de BRP bestaat het Burgerzakensysteem uit twee componenten, het Burgerzakensysteem-Kern (BZS-K) en de Burgerzakenmodules (BZM). De BZS-K is het gedeelte van het stelsel dat centraal de bijhouding verzorgt. De BZS-K is een softwaremodule waarmee gemeenten hun berichten op gestandaardiseerde wijze aan een centrale database kunnen doorgeven. De BZS-K biedt voorzieningen in de vorm services en koppelvlakken deze worden beschikbaar gesteld door de Rijksoverheid. In deze architectuur is de waarborging van de beschikbaarheid van de BZS-K van groot belang. Daar waar de overheid Service Level Agreement (SLA) afspraken heeft gemaakt over de beschikbaarheid van de BZS-K, is het niet ondenkbaar dat het ooit voorkomt dat deze niet of slecht beschikbaar is. Hiervoor is de mogelijkheid tot een lokale BZS-K ontworpen. Deze constructie stelt een decentrale BZS-K met de persoonsgegevens van de betreffende gemeente beschikbaar. In geval van bijvoorbeeld centrale calamiteiten of ernstige performanceproblemen, kan de gemeente overschakelen naar de BRP-Lokaal die het mogelijk maakt om de dienstverlening te continueren. De BRP-Lokaal is een lokale kopie van de BZS-K met uitsluitend persoonsgegevens over de betreffende gemeente Deze overschakeling is als volgt: Figuur 21 Overschakeling naar lokale BZS-K Het bewerken op de BZS-K Centraal wordt tijdelijk dichtgezet zodat andere gemeenten geen bijwerkingen kunnen doen.; De aanvullende module (in dit geval Key2Burgerzaken) werkt dan niet met de gegevens uit de centrale GBA-bron maar met de (identieke) gegevens uit het (niet authentieke) BRP- Lokaal; Bijwerkingen op een persoonslijst worden gelogd waarmee een buffer wordt gecreëerd; Zodra de centrale voorziening weer beschikbaar is en de gemeente weer overschakelt op BZS-K Centraal, worden eerst de bijwerkingen uit de buffer aan BZS-K aangeboden. Daarna kan de dienstverlening op reguliere wijze worden voortgezet; De BRP-Lokaal functioneert onder verantwoordelijkheid van de gemeente. In het geval dat de centrale BZS-K wordt aangepast, zal ook de BRP-Lokaal worden aangepast. Deze oplossing is echter optioneel en wordt aangeboden aan de gemeenten die hier behoefte aan hebben (Rapport Atos Positionering BZS-K, 2009). 33

35 Het andere component in het burgerzakensysteem zijn de burgerzakenmodules, hierna te noemen BZM. Deze BZM zorgen voor de ondersteuning van de gemeentelijke processen. De BZM worden geleverd door de leveranciers (waaronder Centric met Key2Burgerzaken). Het programma mgba heeft de eisen voor de BZM vastgesteld en de volgende modules geïdentificeerd: Figuur 22 Burgerzaken Modules Voor elke module zijn er documenten gepubliceerd met functionele eisen waaraan de module moet voldoen. Deze eisen zijn gesteld volgens de MoscoW methode met de volgende prioriteiten: Must Have - deze eis moet in het eindresultaat terugkomen, zonder deze eis is het product niet bruikbaar; Should Have - deze eis is zeer gewenst, maar zonder is het product wel bruikbaar; Could Have - deze eis mag alleen aan bod komen als er tijd genoeg is; Would Have - deze eis zal in dit project niet aan bod komen maar kan in de toekomst bij een vervolg project interessant zijn. 34

36 3.4 Afnemers De introductie van nieuwe koppelvlakken en de uitfasering van het GBA-netwerk en het bestaande berichtenverkeer zal leiden tot aanpassing van bestaande systemen die communicatie met afnemers mogelijk maakt. Deze systemen zijn in de huidige situatie met een mailbox en een Verzend- en Ontvangststation voor Afnemers (VOA) aangesloten op het GBA-stelsel. In het BRP-stelsel moeten deze systemen via het koppelvlak BRP-Verstrekking aangesloten worden. Alle verstrekkingen zullen voortaan door één centrale voorziening worden geleverd. Afnemers hoeven geen contact op te nemen met gemeenten voor levering van gegevens of nazorg daarbij: Figuur 23 Afnemers GBA Figuur 24 Afnemers BRP In het huidige GBA stelsel worden de afnemers aangesloten op de GBA van de betreffende gemeente na autorisatie van de verantwoordelijke minister. Dit proces wordt ervaren door de afnemers als tijdrovend'. Het aansluiten van de afnemers op de GBA wordt met de komst van de BRP centraal belegd. Dit resulteert in een verlaging van de aansluittijd voor de afnemers. 35

37 3.5 Aanvullende diensten Het proces dat de BRP ondersteunt bevat meer dan alleen het muteren en verstrekken persoonsgegevens. Zo zijn de volgende drie diensten opgenomen in het BRP stelsel: TMV; GBA-V; BV BSN. Voor elke dienst zijn koppelvlakken gecreëerd. Hierdoor communiceren gemeenten altijd met de BRP die op haar beurt de juiste dienst inschakelt. 3.6 Registratie niet-ingezetenen (RNI) Ongeveer drie miljoen mensen hebben een relatie met de Nederlandse overheid, maar wonen niet in Nederland. Bijvoorbeeld een Poolse schilder, die steeds voor twee maanden in Nederland werkt. Deze mensen hebben vaak een relatie met meerdere Nederlandse overheidsinstellingen. Die instellingen houden nu nog elk hun eigen registraties van deze 'niet-ingezetenen' bij. De Registratie Niet-ingezetenen RNI gaat een aantal gemeenschappelijke basisgegevens van nietingezetenen gestandaardiseerd en eenduidig vastleggen in één registratie. Een eenduidige informatiebron die straks - net als de GBA - gebruikt wordt door alle daartoe geautoriseerde overheidsorganisaties. Bij de inschrijving in de RNI wordt aan de niet-ingezetene (mits goed identificeerbaar) een BSN toegekend. De RNI vormt straks samen met de GBA de Basisregistratie Personen. De uniforme vastlegging in een basisregistratie verbetert de beschikbaarheid en de uitwisseling van de gegevens die nodig zijn voor het uitvoeren van verschillende overheidstaken. Overheidsinstellingen hoeven niet langer ieder afzonderlijk dezelfde gegevens bij te houden. Nietingezetenen hoeven niet meer aan elke overheidsinstelling afzonderlijk wijzigingen door te geven. 36

38 3.7 Logisch ontwerp BRP Het Logisch Ontwerp van de Basisregistratie Personen (LO-BRP) beschrijft de functie en de werking van de centrale voorzieningen van het BRP-stelsel. De wet Basisregistratie Personen (BRP), nu nog in concept, vormt hiervoor de basis. Het grootste verschil is de manier van opslaan van persoonsgegevens. In de huidige situatie wordt uitgegaan van een Persoonslijst, deze persoonslijst is ontstaan uit de Persoonskaart. Hierop worden de gegevens van een persoon en zijn of haar gerelateerde werden vastgelegd. Als een persoon in de GBA twee ouders heeft, getrouwd is en twee kinderen heeft, dan komt deze persoon voor op zes persoonslijsten: Eigen persoonslijst; Persoonslijst van de ouders; Persoonslijst van de partner; Persoonslijst van de kinderen. Bij alle gerelateerde is niet alleen het BSN opgenomen maar ook de gegevens over de naam, de geboorte en het geslacht. Figuur 25 Persoonslijst en Gegevensset De BRP gaat uit van een Gegevensset in plaats van een Persoonslijst. Deze gegevensset bestaat uit objecten. In de BRP zijn er relaties tussen personen aparte objecten. Bijvoorbeeld via het objecttype Betrokkenheid wordt een persoon betrokken bij een relatie. Zo is een huwelijk een apart object dat niet langer tot één enkele persoonslijst hoort. Het objecttype Betrokkenheid bevat het BSN en niet de volledige set aan persoonsgegevens zoals geslachtsnaam, geboortedatum en geboorteplaats. Door deze constructie wordt voorkomen dat deze persoonsgegevens meerdere malen worden opgenomen. 37

39 3.8 Kenmerken De mgba brengt op hoofdlijnen twee grote veranderingen met zich mee die betrekking hebben op Key2Burgerzaken. Enerzijds op technisch gebied (koppelvlakken en gegevensset) en anderzijds op functioneel gebied (BZM met hierin de functionele eisen). Dit onderzoek richt zich hoofdzakelijk op het functionele gebied. Samengevat betekent de komst van de BRP het volgende: Centrale opslag van persoonsgegevens; Directe beschikbaarheid over actuele en betrouwbare (persoons)gegevens; Plaatsonafhankelijke dienstverlening; Persoonslijst wordt vervangen door een gegevensset; Geen onderlinge communicatie tussen gemeenten; Geen communicatie tussen gemeenten en afnemers. 38

40 4 ONDERZOEKSRESULTATEN BURGERZAKENMODULES EN PROCESSEN Dit hoofdstuk gaat in op de BZM Overlijden, Migratie en Reisdocumenten. Om een totaalbeeld te creëren over Key2Burgerzaken en de BZM, zijn alle functionaliteiten van bovenstaande modules onderzocht. Deze functionaliteiten kunnen betrekking hebben op de processen die buiten de scope van dit project vallen. Aan het eind van elke module wordt er een conclusie getrokken uit de onderzoeksresultaten. Indien er impact is op de onderzochte processen beschreven in hoofdstuk drie, worden deze toegelicht. Op 10 december 2010 heeft het Programma modernisering GBA in het kader van het project BurgerZaken Modules (BZM) een set documenten gepubliceerd. In deze documenten staan de vereiste functionaliteiten van de te ontwikkelen BZM. Deze functionaliteiten zijn ingedeeld volgens de MoSCoW prioriteiten 7. De totstandkoming van deze prioriteiten is het resultaat van een samenwerking tussen het programma mgba en de Vereniging van Nederlandse Gemeenten. Dit hoofdstuk beschrijft hoe deze functionaliteiten zich verhouden tot de aanwezige functionaliteit in Key2Burgerzaken. Centric heeft als doel (in overleg met haar klanten) om te voldoen aan alle eisen met de prioriteit 'Must Have'. 4.1 Overlijden In de BZM overlijden staan in totaal zeventien functionele eisen beschreven. Key2Burgerzaken voldoet in de huidige vorm niet aan de volgende eisen zoals deze beschreven zijn in de BZM overlijden: Modernisering Burgerlijke Stand In de registers van de burgerlijke stand wordt de burgerlijke staat van een persoon vastgelegd. Bij de volgende gelegenheden worden akten opgemaakt: Geboorte; Huwelijk; Echtscheiding; Overlijden. Akten van de burgerlijke stand worden gemaakt en bewaard in de gemeente waar het desbetreffende feit heeft plaatsgevonden. De Modernisering Burgerlijke Stand is een project (zonder relatie met de mgba) met als uitgangspunt het digitaliseren van de Burgerlijke Stand. Eén van de veranderingen die het programma met zich mee brengt, is het verdwijnen van de aktenummers. Op een aktenummer wordt normaliter gezocht indien informatie benodigd is omtrent een akte die bij een persoon hoort. Deze aktenummers worden vervangen door een inhoudloos nummer. Er moet voortaan op BSN gezocht worden om de juiste aktes van een persoon op te zoeken. 7 Zie ook hoofdstuk 3.3 Burgerzakensysteem-Kern en de Burgerzakenmodules 39

41 Als gekeken wordt naar de gegevensset van de mgba kan er gesteld worden dat er geen rekening gehouden is met de modernisering Burgerlijke Stand. De aktenummers komen nog meerdere malen voor in de te hanteren gegevensset. Dit is een aandachtspunt voor Centric bij het aanpassen van Key2Burgerzaken voor de module Overlijden. Bewaking geslacht onbekend (MH) Op dit moment worden aangiften van overlijden (met het geslacht onbekend) doorgevoerd in Key2Burgerzaken zonder bewaking van de overlegging van een doktersverklaring. De wettelijke termijn van deze overlegging is drie maanden. Het programma mgba stelt dat inzichtelijk gemaakt kan worden welke aangiften er zijn met een onbekend geslacht waarvan nog geen doktersverklaring is overlegd. De termijn waarbinnen gezocht kan worden moet instelbaar zijn. Dit kan op dit moment niet in Key2Burgerzaken. Koppeling met BAG Active search (MH) Tijdens de registratie van een aangifte van overlijden worden de adresgegevens van zowel de overledene, de gerelateerde als de aangever geregistreerd in een dossier. Deze gegevens worden nu opgehaald aan de hand van de persoonslijsten van de betreffende personen. Een van de eisen in de BZM Overlijden is de mogelijkheid om de adresgegevens te verrijken of op te zoeken in de Basisadministratie Adressen en Gebouwen (BAG). Het voordeel hiervan is dat er op deze manier gebruik gemaakt wordt van authentieke gegevens. Dit is nu niet mogelijk in Key2Burgerzaken. 40

42 Controle aangever tabel (SH) Tijdens de registratie van een aangifte van overlijden in Nederland moet de gebruiker een aangever invoeren. Omdat aangevers doorgaans begrafenisondernemers zijn en bekend zijn bij de gemeente, heeft Key2Burgerzaken de functionaliteit om uit een lijst (die wordt beheerd door de gemeente) de aangever te selecteren. Deze persoonsgegevens worden eenmalig ingevoerd en zijn op het moment van invoeren actueel. Mocht een wijziging plaatsvinden in deze gegevens dan veranderen deze niet mee in de aangevers tabel. De eis Controle op aangever tabel vereist dat deze persoonsgegevens bij het invoeren worden opgehaald uit de BRP om zo de juistheid van deze persoonsgegevens te waarborgen. Ook dient een controle plaats te vinden of de gegevens nog overeenkomen met de gegevens in de BRP. Dit kan per aangifte of periodiek zijn. Figuur 26 Aangevers tabel 41

43 Digitale verzending van B-Enveloppen (SH) In de BZM Overlijden staat vermeld als eis Digitale verzending van B-Enveloppen. Deze eis impliceert het digitaliseren of automatiseren van deze processtappen. Welke voorwaarden en technische specificaties er aan deze eis zitten is verder onbekend. Op dit moment zijn dit handmatige handelingen in het proces waarin Key2Burgerzaken niet ondersteunt. Geslacht onbekend (SH) Bij een levenloos geboren kind kan het voorkomen dat op het moment van de aangifte het geslacht van het kind in kwestie nog niet bekend is. De aangifte wordt ingevoerd voor de persoon met het geslacht 'onbekend'. Er wordt geen termijn gehanteerd voor het overleggen van een medische verklaring. De eis die in de BZM Overlijden staat is: 'De module ondersteunt het instellen van een termijn (van in dit geval 3 maanden) waarbinnen een medische verklaring overgelegd dient te worden.' Deze functionaliteit komt voort uit het burgerlijk wetboek artikel 19d en ontbreekt op dit moment in Key2Burgerzaken. Automatisch telkaart invullen voor CBS (CH) Ook in het geval van een levenloos geboren kind vult de arts een B-formulier in. De ambtenaar vult een zogenoemde telkaart in en verstuurt deze naar het CBS. Bij het invullen van deze telkaarten wordt gebruik gemaakt van de aangeleverde formulieren van het CBS (op papier). Deze telkaarten zijn blanco te bestellen bij het CBS en dienen ingevuld en ondertekend te worden door de ambtenaar van de burgerlijke stand. In de BZM Overlijden staat als eis Automatisch telkaart invullen voor CBS. Deze eis stelt dat aan de hand van de gegevens in het dossier een telkaart ingevuld en afgedrukt wordt. De ambtenaar van de burgerlijke stand hoeft alleen zijn handtekening en stempel te plaatsen op de telkaart. Zoeken op BSN (MH) Met de komst van de zogenoemde koppelvlakken bestaat de mogelijkheid om via het koppelvlak BRP bijhouding persoonsgegevens op te zoeken in de burgerlijke stand via het BSN. Dit komt de gebruiksvriendelijkheid van Key2Burgerzaken ten goede omdat een BSN uniek is en hiermee dus direct de juiste persoon geselecteerd kan worden. In Key2Burgerzaken wordt op dit moment een persoon opgezocht op geboortedatum en de eerste drie letters van de geslachtsnaam. In de module Burgerlijke Stand van Key2Burgerzaken kan op dit moment niet op een BSN gezocht worden. 42

44 Uitkomsten Uit het onderzoek naar Key2Burgerzaken en de vereiste functionaliteiten voor de BZM Overlijden, staan in onderstaande tabel de onderzoeksresultaten weergegeven: Prioriteit Aantal in BZM Aanwezig in Key2B Must Have 9 6 Should Have 6 3 Could Have 2 1 Totaal Geconstateerd is dat in Key2Burgerzaken ten opzichte van de BZM Overlijden zeven eisen ontbreken waarvan: Drie Must Have eisen; Drie Should Have eisen; Eén Could Have eis. Gekeken het proces 'Overlijden in Nederland' worden de volgende processtappen (aangegeven in het rood) beïnvloed: Figuur 27 Impact proces overlijden in Nederland Personen moeten opgevraagd worden bij de BRP; Met de komst van de mgba wordt het vereist dat er vanuit de burgerlijke stand een persoon opgezocht kan worden op basis van een BSN; Indien Centric er voor kiest om gehoor te geven aan de eisen met een lagere prioriteit (Should Have en Could Have) worden de processtappen Invullen B-enveloppe' en 'Versturen B-enveloppe' deels geautomatiseerd met behulp van Key2Burgerzaken. 43

45 4.2 Migratie In de BZM Migratie staan in totaal vijfenveertig functionele eisen beschreven. Key2Burgerzaken voldoet in de huidige vorm niet aan de volgende eisen, zoals deze beschreven zijn in de BZM Migratie: Berekening nationaliteit (MH) Een kind kan de Nederlandse nationaliteit krijgen als het aan een aantal voorwaarden voldoet. Dit wordt een derde generatie berekening genoemd. Indien de moeder in Nederland is geboren en de moeder van de moeder in Nederland woonachtig was op het moment van de geboorte van de moeder dan krijgt het kind de Nederlandse nationaliteit. De eis Berekening nationaliteit stelt dat Key2Burgerzaken een signaal geeft op het moment dat een kind in hiervoor in aanmerking komt. Key2Burgerzaken biedt op dit moment deze functionaliteit niet. Echter is deze wens wel besproken met de werkgroep GBA van Key2Burgerzaken gemeenten. Deze gemeenten zien hier weinig meerwaarde in deze functionaliteit omdat de medewerker burgerzaken dit aan de balie controleert door middel van het stellen van vragen aan de aangever. De frequentie waarin deze regeling toepasbaar is, is beperkt te noemen. Automatisch afsluiten zaak en versturen kennisgevingen (MH) In Key2Burgerzaken is het mogelijk om een verhuizing in de toekomst te registreren. De verhuizing wordt dan klaar gezet in een wachtkamer. Periodiek (meestal dagelijks) wordt een Autorisatie Routering Systeem (ARS) totaalverwerking uitgevoerd in Key2Burgerzaken. Deze verwerking loopt alle mutaties langs om deze te verwerken, waarbij ook de eventuele toekomstmutaties. Indien het termijn van deze toekomstmutatie is bereikt zal deze doorgevoerd worden. De eis Automatisch afsluiten zaak en versturen kennisgevingen stelt dat in het geval van een mutatie van een toekomstmutatie, een kennisgeving wordt verstuurd aan de betreffende burger(s). Deze functionaliteit is op dit moment niet aanwezig in Key2Burgerzaken. 44

46 Kennisgeving voor overzeese gebieden (binnen koninkrijk) (MH) Indien iemand verhuist naar een overzees gebied binnen het koninkrijk der Nederlanden (Bonaire, Sint Eustatius en Saba) is het noodzakelijk om een uitschrijfbewijs te tonen bij het land van inschrijving. De eis Kennisgeving voor overzeese gebieden stelt dat indien wordt gekozen voor een emigratie naar deze eilanden automatisch een uitschrijfbewijs wordt afgedrukt. Het afdrukken van het uitschrijfbewijs gebeurt nu handmatig in Key2Burgerzaken. Er is bij Centric al eerder over deze eis nagedacht maar gezien de frequentie van deze emigraties en de kosten van het programmeerwerk is deze functionaliteit nog niet ontwikkeld. Ondersteuning keuze voor geheimhouding (MH) In het geval van een hervestiging wordt een persoonslijst bij een gemeente opgevraagd en aan de hand van deze gegevens wordt de persoon ingeschreven. De medewerker van de gemeente waar de burger zich komt hervestigen dient opnieuw te vragen aan de burger of hij geheimhouding van zijn persoonsgegevens wil. Geheimhouden betekent het niet toestaan van het gebruik van persoonsgegevens voor derden 8. De optie voor geheimhouding is op dit moment aanwezig in Key2Burgerzaken. De controle door Key2Burgerzaken of de burger is gewezen op de mogelijkheid tot geheimhouding ontbreekt. Persoon onder curatele mag niet zelfstandig verhuizen (MH) Een persoon die onder curatele staat mag niet zonder toestemming van de curator zelfstandig rechtshandelingen verrichten (Wet GBA, 1994). Één van deze handelingen betreft een verhuizing. Indien iemand onder curatele staat wordt dit vermeld op de persoonslijst van de betreffende persoon. Op het moment dat deze persoon een verhuizing door komt geven zoekt de medewerker van de gemeente de persoon op in Key2Burgerzaken. In principe moet hij opgemerkt hebben dat deze persoon onder curatele staat. Het is echter wel mogelijk deze persoon zelfstandig te laten verhuizen. Hierop wordt in Key2Burgerzaken niet gecontroleerd. De eis 'Persoon onder curatele mag niet zelfstandig verhuizen' stelt dat Key2Burgerzaken de aanvraag moet blokkeren als iemand onder curatele zelfstandig wil gaan verhuizen. 8 Instanties en personen die onder strenge voorwaarden en niet-commerciële doeleinden, gegevens over inwoners kunnen bemachtigen uit de GBA 45

47 Tonen statusinformatie uit BAG (MH) In de Basisregistratie Adressen en Gebouwen (BAG) zijn basisgegevens over gebouwen en adressen in Nederland verzameld. Hierin staan gegevens van hoge kwaliteit die gebruikt kunnen worden voor het uitvoeren van bijvoorbeeld burgerzaken processen. Er zijn twee vormen van de BAG te herkennen. Enerzijds de Landelijke BAG 9 met hierin alle gegevens over gebouwen en adressen in Nederland. Deze wordt beheerd door het Kadaster. Anderzijds de lokale BAG met hierin uitsluitend gegevens over de eigen gemeente, die ook onder het beheer van de gemeente vallen. Indien gezocht wordt op een adres moet er statusinformatie worden weergegeven uit de BAG. De statussen kunnen bestaan uit: Adres is correct; Adres heeft nog geen voorbestemming; Adres komt niet voor in de BAG. Indien een adres niet voorkomt in de BAG of geen woonbestemming heeft en toch moet worden opgevoerd moet dit alleen mogelijk zijn door de daartoe geautoriseerde medewerkers. Overigens dient er altijd een terugkoppeling te zijn naar de landelijke BAG om ervoor te zorgen dat (na onderzoek) dit adres geverifieerd is. Key2Burgerzaken biedt deze functionaliteit op dit moment niet. 9 Zie bijlage 5 46

48 Signaal bij datum verhuizing in verleden (MH) Het moet mogelijk zijn dat een verhuizing wordt ingegeven met een aanvangsdatum in het verleden. Key2Burgerzaken moet een signaal afgeven dat dit het geval is. De mogelijkheid om een verhuizing in het verleden te muteren is mogelijk in Key2Burgerzaken, echter ontbreekt de signalering van een verhuizing in het verleden. Risicoprofielen (MH) Het kan voorkomen dat iemand een bepaald risico met zich mee brengt en de medewerker burgerzaken hierop geattendeerd dient te worden. Op dit moment wordt er een zogenoemde Signalering aangemaakt bij de betreffende persoon. Bij iedere actie die betrekking heeft op deze persoonslijst wordt deze signalering weergegeven. Zie onderstaande schermafdruk voor een voorbeeld hiervan. Figuur 28 Signalering Deze signalering wordt alleen lokaal opgeslagen en in het geval van bijvoorbeeld een verhuizing gaan deze gegevens verloren. De eis Risicoprofielen stelt dat een centrale bijhouding van risicoprofielen geïmplementeerd wordt. Dit ontbreekt nu in Key2Burgerzaken. 47