Inleiding specificaties burgerzakenmodules

Inleiding specificaties burgerzakenmodules Inhoudelijke achtergronden bij – en ontwerpkeuzes in – de specificaties

Versie 3.0.0

8-6-2015 Definitief

Definitief | Inleiding specificaties burgerzakenmodules | 8-6-2015

Inhoud

1

INLEIDING ....................................................................................................................................5 1.1 1.2 1.3 1.4 1.5 1.6

2

DE BASISREGISTRATIE PERSONEN.............................................................................................5 DE BURGERZAKENMODULES ........................................................................................................5 ROL VAN DE SPECIFICATIES BURGERZAKENMODULES ...............................................................6 STATUS VAN DE SPECIFICATIES BURGERZAKENMODULES.........................................................6 DOEL EN LEESWIJZER ..................................................................................................................7 REFERENTIES................................................................................................................................7

UITGANGSPUNTEN EN ONTWERPKEUZES ...................................................................9 2.1 BEPERKT TOT PRIMAIRE PROCESSEN, MET BEPERKTE DIEPGANG .............................................9 2.2 AANSLUITING BIJ GEMMA EN KING-STANDAARDEN ..............................................................9 2.2.1 Procesbeschrijvingen ...................................................................................................10 2.2.2 Rollen en actoren ..........................................................................................................11 2.2.3 Opzet use case model .................................................................................................11 2.2.4 Gebruik van het begrip ‘zaak’ ..................................................................................13 2.3 GERICHT OP INGEZETENEN .......................................................................................................14

3

KETEN USE CASE VIEW ........................................................................................................15 3.1 ACTOREN ....................................................................................................................................15 3.2 OVERZICHT VAN HET KETEN USE CASE MODEL ........................................................................15 3.3 UITGELICHT ................................................................................................................................17 3.3.1 Melden en afhandelen gerede twijfel .....................................................................17 3.3.2 Landelijke taken ............................................................................................................17 3.4 AANVULLENDE FUNCTIONELE SPECIFICATIES...........................................................................18 3.4.1 Termenlijst en business object model ...................................................................18 3.4.2 Aanvullende eisen, bedrijfsregels en meldingregels ........................................18

4

LOGICAL VIEW ..........................................................................................................................19 4.1 INDELING IN BURGERZAKENMODULES......................................................................................19 4.1.1 Documenten en verzoeken ........................................................................................19 4.1.2 Overkoepelende functionaliteit ................................................................................20 4.2 KOPPELVLAKKEN CENTRALE VOORZIENINGEN ..........................................................................20 4.3 VERDELING VERANTWOORDELIJKHEDEN BURGERZAKENMODULES EN CENTRALE VOORZIENINGEN ................................................................................................................................... 20 4.3.1 Beleids- en ontwerpkeuzes........................................................................................20 4.3.2 Vast stramien van communiceren ..........................................................................21 4.3.3 Uitwerking in keten use case realizations en component model ................22

5

KWALITEIT ..................................................................................................................................23

6

OPENSTAANDE PUNTEN ......................................................................................................24 6.1 ONTBREKENDE ONDERWERPEN EN ONDERDELEN ....................................................................24 6.1.1 Wijze van aansluiten IND ...........................................................................................24 6.1.2 Binnengemeentelijke leveringen .............................................................................24 6.1.3 Samenwerkingsverbanden ........................................................................................24 6.1.4 Authenticatie en autorisatie ......................................................................................24 6.1.5 Beheer ...............................................................................................................................24 6.2 VERANDERENDE INVULLING ......................................................................................................25 6.2.1 Fiatteren ...........................................................................................................................25 6.2.2 Status specificaties module Verkiezingen ............................................................25 Pagina 3 van 25

Definitief | Inleiding specificaties burgerzakenmodules| 8-6-2015

6.2.3 Aanvullende diensten centrale voorzieningen ....................................................25

Pagina 4 van 25


1

Inleiding

Dit document heeft tot doel om een globale, inhoudelijke toelichting op de verschillende onderdelen van de specificaties te geven. Het beschrijft de uitgangspunten die gebruikt zijn bij het opstellen van de specificaties en achterliggende ontwerpbeslissingen. 1.1 De Basisregistratie Personen Voor een goede dienstverlening van de overheid aan burgers en bedrijven is het belangrijk de binnen de overheid bekende gegevens over bijvoorbeeld personen, bedrijven of adressen te delen. Daarom worden deze gegevens vastgelegd in basisregistraties, die samen het stelsel van basisregistraties vormen. Alle overheden die voor de uitvoering van hun publieke taken gebruik maken van dergelijke gegevens, zijn verplicht deze uit de basisregistraties halen. Dat betekent dat alle gemeenten, alle provincies, alle waterschappen, alle zelfstandige bestuursorganen en overige organisaties met een publieke taak gebruik maken van de basisregistraties. Eén van de basisregistraties is de Basisregistratie Personen (BRP), waarin persoonsgegevens worden opgeslagen. De BRP bevat persoonsgegevens over alle ingezetenen van Nederland. De BRP bevat daarnaast ook persoonsgegevens over niet-ingezetenen: personen die niet in Nederland wonen – of hier slechts kort verblijven – maar wel een dusdanige relatie met de Nederlandse overheid hebben dat registratie nodig is. De BRP wordt beschreven in de Wet Basisregistratie Personen (Wet BRP, [1]). Deze wet bepaalt dat er een Basisregistratie Personen is, over wie daarin gegevens worden vastgelegd en welke gegevens dat zijn. Bovendien beschrijft de wet de verantwoordelijkheden, rechten en plichten van de degenen die de gegevens invoeren of aanpassen en gebruiken en van degenen over wie gegevens worden bijgehouden. De wet BRP geeft aan dat de BRP bestaat uit gemeentelijke en centrale voorzieningen. Deze voorzieningen vervangen samen de Gemeentelijke Basisadministraties persoonsgegevens (GBA) en de Registratie Niet-Ingezetenen (RNI) waarin de persoonsgegevens over ingezetenen en niet-ingezetenen nu worden (of in het geval van RNI: gaan worden) geregistreerd. De gemeentelijke en centrale voorzieningen ondersteunen de verschillende belanghebbenden bij de uitvoering van hun taken rond het bijhouden, verstrekken en terugmelden van persoonsgegevens en het beheren van diezelfde voorzieningen. 1.2 De burgerzakenmodules Het bijhouden, verstrekken en terugmelden van persoonsgegevens vindt plaats als onderdeel van de burgerlijke stand processen en andere burgerzakenprocessen die bij gemeenten worden uitgevoerd. De ondersteuning van deze burgerzakenprocessen wordt grotendeels gerealiseerd door burgerzakenmodules. De burgerzakenmodules zijn gemeentelijke voorzieningen die bijvoorbeeld de afgifte van reisdocumenten en rijbewijzen, verkiezingen, het bijhouden van huwelijken en partnerschappen en de verstrekking van informatie over in de BRP ingeschreven personen mogelijk maken. De burgerzakenmodules maken hiervoor gebruik van de diensten van de centrale voorzieningen van de BRP voor het bevragen, aanvullen of wijzigen van persoonsgegevens. De burgerzakenmodules vervangen de huidige burgerzakensystemen – en de decentrale GBA-functionaliteit die daarin is vervat – die bij gemeenten in gebruik zijn. De modules zijn dus nodig om aan te sluiten op de centrale voorzieningen van de BRP. Pagina 5 van 25


De burgerzakenmodules geven op deze manier mede invulling aan de gemeentelijke voorzieningen uit de wet BRP. Maar ze doen méér dan dat: de burgerzakenmodules zijn niet alleen gericht op het bijhouden, verstrekken en terugmelden van persoonsgegevens, maar op het ondersteunen van de burgerzakenprocessen als geheel. 1.3 Rol van de specificaties burgerzakenmodules De centrale voorzieningen van de BRP worden door het Rijk gerealiseerd en beheerd. Gemeenten verwerven en beheren de specificaties van de burgerzakenmodules. Om te borgen dat de burgerzakenmodules en de centrale voorzieningen van de BRP desondanks goed op elkaar aansluiten, heeft programma Modernisering GBA specificaties opgesteld die gemeenten kunnen gebruiken als basis voor de verwerving van deze burgerzakenmodules. Deze specificaties burgerzakenmodules bestaan uit twee hoofdbestanddelen: • Een beschrijving van de functionaliteit die ‘het systeem’ moet bieden voor de ondersteuning van de dienstverlenings- en bijhoudingsprocessen. Als ‘het systeem’ is daarbij de keten van burgerzakenmodules en centrale voorzieningen genomen. De functionaliteit is vastgelegd in de vorm van use cases. Om duidelijk te maken dat het om functionaliteit van burgerzakenmodules en centrale voorzieningen sámen gaat zijn deze use cases keten use cases1 genoemd. • Een beschrijving van hoe burgerzakenmodules en de centrale voorzieningen moeten samenwerken om deze functionaliteit te realiseren. Deze verantwoordelijkheden zijn vastgelegd in de vorm van use case realizations. Om duidelijk te maken dat het om de verdeling van verantwoordelijkheden over de onderdelen van de keten gaat zijn deze use case realizations keten use case realizations genoemd. Een complete beschrijving van deze en andere specificatieonderdelen is te vinden in [3]. De combinatie van wat de keten als geheel moet kunnen en welke rol de burgerzakenmodules daarbinnen moeten spelen, biedt gemeenten een handvat voor het opstellen van meer gedetailleerde specificaties voor de burgerzakenmodules. Aanvulling en nadere uitwerking van dit handvat door gemeenten is noodzakelijk, bijvoorbeeld omdat: • in de specificaties vooral aandacht is besteed aan functionaliteit die in zijn algemeenheid door alle gemeenten op dezelfde wijze gebruikt kan worden. Daar waar gemeenten specifieke behoeften blijken te hebben, heeft op dat detailniveau geen verdere uitwerking plaatsgevonden. • de specificaties geen rekening houden met verschillen ten aanzien van bijvoorbeeld het (applicatie)landschap waarbinnen de modules geïntegreerd moeten worden of van aantallen gebruikers. 1.4 Status van de specificaties burgerzakenmodules De centrale voorzieningen – en daarmee tevens het koppelvlak met de burgerzakenmodules – komen iteratief tot stand. De uitgangspunten met betrekking tot de interactie tussen de BRP en burgerzakenmodules zijn vormgegeven in de specificaties, in het bijzonder de Keten Use Case Realizations. De exacte technische werking ervan zal nader worden uitgewerkt in de koppelvlakbeschrijving, gegevenscatalogus, interfacedefinities en wederzijdse kwaliteitsverwachtingen, die uiteindelijk alle onderdeel zullen uitmaken van het Logisch Ontwerp BRP.

1 Een keten use case heeft dezelfde inhoud als een ‘normale’ use case, alleen is vooraf bekend dat het beschreven gedrag zal worden gerealiseerd door meerdere systemen. Er is voor keten use cases gekozen omdat de BRP bestaat uit meerdere voorzieningen en de goede samenwerking tussen die voorzieningen cruciaal is. Methodisch gezien zijn keten use cases een vorm van business (use case) modeling (een discipline uit Rational Unified Proces), echter met een specifieke focus op (de verantwoordelijkheden van) IT-voorzieningen. Pagina 6 van 25


Gemeenten kunnen de specificaties burgerzakenmodules nu al gebruiken als basis voor het nader uitwerken van de gemeente-specifieke eisen2. Deze eisen, gecombineerd met het later beschikbaar komende Logisch ontwerp BRP, kunnen uiteindelijk de basis zijn voor het (laten) realiseren van burgerzakenmodules. 1.5 Doel en leeswijzer De specificaties burgerzakenmodules bestaan uit veel soorten onderdelen (zie [3]), zoals keten use cases en keten use case realizations. Deze Inleiding specificaties burgerzakenmodules heeft tot doel om een inhoudelijke toelichting op de verschillende onderdelen van de specificaties te geven. Het beschrijft de uitgangspunten die gebruikt zijn bij het opstellen van de specificaties. Bovendien beschrijft het achterliggende ontwerpbeslissingen, geïllustreerd aan de hand van enkele ‘typische’ voorbeelden. De structuur van het document is gebaseerd op het Rational Unified Process (RUP)3-artefact Software Architecture Description (SAD). De SAD-structuur biedt handvatten om de specificaties zelf toe te lichten aan de hand van: • uitgangspunten en ontwerpkeuzes (hoofdstuk 2); • verschillende invalshoeken op het specificatiemodel, te weten de functionele specificaties (de use case view in hoofdstuk 3), de indeling in modules en de verantwoordelijkheidsverdeling tussen modules en centrale voorzieningen in de vorm van keten use case realizations (de logical view in hoofdstuk 4) en de niet-functionele eigenschappen (hoofdstuk 5). Andere typische SAD-onderdelen, zoals implementation view of deployment view, zijn weggelaten omdat de specificaties uitdrukkelijk géén softwarearchitectuur of softwareontwerp voor de burgerzakenmodules voorschrijven. Het overzicht burgerzakenmodules wordt in hoofdstuk 6 afgesloten met een beschrijving van lopende discussies waarvan duidelijk is dat ze invloed zullen hebben op de inhoud van de specificaties. 1.6 Referenties Binnen dit document worden de volgende referenties gebruikt en aangeduid met [#]: #

Document

Organisatie

Versie

Datum

1

Wet BRP4

Ministerie van Concepttekst Augustus 2011 BZK

2

Referentiemodel Gemeentelijke Basisgegevens Zaken UML (RGBZ) Deel 1/3

KING

1.0

November 2010

3

Productcatalogus ketenspecificaties (BZM)

mGBA

2.0.0

23-04-2013

4

Projectstartarchitectuur Burgerzaken Modules

mGBA

1.2

November 2010

5

BRP-BZM Aanvullende Eisen

mGBA

2.0.0

23-04-2013

6

Aanvullende Eisen BZM

mGBA

2.0.0

23-04-2013

2 Het gebruik van de specificaties is niet verplicht. De specificaties geven aan hoe programma mGBA denkt over de benodigde ondersteuning en – vooral – over de samenwerking tussen burgerzakenmodules en centrale voorzieningen. Door de specificaties als startpunt te nemen borgen gemeenten dat de manier van werken van de burgerzakenmodules aansluit bij de werking van de centrale voorzieningen. 3 Rational Unified Proces, zie http://www-01.ibm.com/software/awdtools/rup/ 4 Op dit moment werkt BZK nog aan de conceptwet BRP. De verwijzingen in dit document hebben betrekking op de eerder verstuurde voorlopige versie van de wet en de memorie van toelichting. Pagina 7 van 25


Een belangrijk deel van de specificaties burgerzakenmodules is als model vastgelegd in het tool Enterprise Architect van Sparx Systems5. Veel van de in dit overzicht besproken onderwerpen en onderdelen van de specificaties zijn alleen terug te vinden in dit model en niet in afzonderlijke documenten.

5 Sparx Systems Enterprise Architect, zie http://www.sparxsystems.eu Pagina 8 van 25


2

Uitgangspunten en ontwerpkeuzes

Bij • • •

het opstellen van de specificaties zijn verschillende uitgangspunten gehanteerd: Beperkt tot primaire processen, met beperkte diepgang; Aansluiting bij GEMMA en KING-standaarden; Gericht op ingezetenen.

2.1 Beperkt tot primaire processen, met beperkte diepgang De specificaties burgerzakenmodules beperken zich tot het specificeren van de gewenste ondersteuning voor het uitvoeren van de primaire burgerzakenprocessen. De burgerzakenmodules maken gebruik van ondersteunende diensten die aanwezig zijn binnen de gemeente. Denk bijvoorbeeld aan zaaksysteem, document management of authenticatie en autorisatie van medewerkers. Daar waar noodzakelijk voor de ondersteuning van de primaire processen beschrijven of benoemen de specificaties slechts de minimaal benodigde functionaliteiten op dit gebied. Dit vanwege de verschillen tussen gemeenten in de uitvoering en automatiseringsgraad van deze diensten: ook zonder de aanwezigheid van bijvoorbeeld een geautomatiseerd documentmanagementsysteem moet een gemeente gebruik kunnen maken van burgerzakenmodules die voldoen aan de specificaties. Bij de nadere uitwerking van de specificaties kunnen gemeenten precies aangeven of – en hoe – burgerzakenmodules moeten aansluiten op bestaande systemen om invulling te geven aan de ondersteunende diensten. Vanwege de nadruk op de keten van burgerzakenmodules en centrale voorzieningen (zie 1.3) beschrijven de specificaties burgerzakenmodules de interactie tussen actor en systeem en tussen de verschillende voorzieningen in de keten onderling alleen op hoofdlijnen. Vragen als “welke attributen zullen exact bewerkt worden binnen een keten use case?”, “hoe wordt een akte opgeslagen?” en “hoe worden de vereiste leges bepaald?” worden niet beantwoord in de specificaties burgerzakenmodules. Gemeenten kunnen op basis van de keten use case realizations en componentbeschrijvingen [3] meer gedetailleerde specificaties voor de burgerzakenmodules opstellen die wel ingaan op deze vragen, zie 1.3. Dit kan bijvoorbeeld door use cases op te stellen specifiek voor de burgerzakenmodules, zogenaamde application use cases. 2.2 Aansluiting bij GEMMA en KING-standaarden Eén van de belangrijkste uitgangpunten bij het opstellen van de specificaties burgerzakenmodules is het aansluiten bij GEMeentelijk Model Architectuur (GEMMA). Zaakgericht werken is een belangrijk principes uit de GEMMA-procesarchitectuur. Een zaak in de GEMMA is gedefinieerd als "een samenhangende hoeveelheid werk met een gedefinieerde aanleiding en een gedefinieerd resultaat, waarvan kwaliteit en doorlooptijd bewaakt moeten worden”. Zaakgericht werken is een verbijzondering van procesgericht werken. Er zijn negen groepen procesbouwstenen waaruit ieder zaakgericht proces kan worden samengesteld.

Pagina 9 van 25


Figuur 1

Zaakgericht werken volgens GEMMA

Door zaakgericht te werken is het voor gemeenten makkelijker om burgers en organisaties te informeren over de voortgang van de afhandeling van diensten. Daarnaast kan de gemeente intern de voortgang bewaken en geeft het een manier om de werkprocessen die de afhandeling implementeren te stroomlijnen. Ten slotte komt op deze manier managementinformatie over serviceniveaus en gestelde normen beschikbaar. Om plaatsonafhankelijke dienstverlening en samenwerking te realiseren is het van belang dat gemeenten op een uniforme wijze hun processen afhandelen. Kenmerkend voor zaakgericht werken is dat voor elke aanvraag een zaak wordt gedefinieerd die als één geheel op een overkoepelend niveau bestuurd, bewaakt en beheerd wordt. Burgers, organisaties en de gemeente hebben inzicht in de stand van afhandeling (status) van alle eigen lopende zaken. Een zaak bestaat uit een combinatie van betrokken(n), zaakinformatie, documenten, status, resultaat en een eventueel besluit. Het principe van zaakgericht werken is op een aantal punten te herkennen in de specificaties burgerzakenmodules, te weten in de: • meegeleverde procesbeschrijvingen, zie 2.2.1, • het gebruik van rollen actoren, zie 2.2.2 en • de opzet van het use case model, zie 2.2.3 . In aanvulling op GEMMA heeft het Kwaliteits Instituut Nederlandse Gemeenten (KING) verschillende standaarden gedefinieerd. Daarvan heeft het Referentiemodel Gemeentelijke Basisgegevens Zaken (RGBZ, zie [2]) invloed op de specificaties burgerzakenmodules, zie 2.2.4. Bij verdere uitwerking van de specificaties burgerzakenmodules door gemeenten kunnen de GEMMA-zaaktypecatalogus (ZTC) en het Referentiemodel Stelsel van Gemeentelijke Basisgegevens (RSGB) gebruikt worden, denk hierbij bijvoorbeeld aan de definitie van zaaktypes. 2.2.1

Procesbeschrijvingen Het uitgangspunt voor de specificaties burgerzakenmodules zijn de burgerzakenprocessen die ondersteund moeten worden. Als eerste stap bij het opstellen van de specificaties zijn de beschrijvingen die de Nederlandse Vereniging voor Burgerzaken (NVVB) voor deze processen heeft opgesteld aangevuld met zaakgerichte processtappen voor het initiëren, bijwerken en afronden van zaken. Op basis van deze bijgestelde procesbeschrijvingen is vervolgens de benodigde burgerzakenmodulefunctionaliteit gespecificeerd. De zaakgerichte procesbeschrijvingen zijn als achtergrondinformatie opgenomen bij de specificaties burgerzakenmodules, zie ook [3]. Pagina 10 van 25


2.2.2

Rollen en actoren De GEMMA-procesarchitectuur kent vijf rollen: klant, klantcontactmedewerker, dienstverleningsmanager (orkestrator), vakspecialist en ketenpartner. Daarvan maken klantcontactmedewerkers en vakspecialisten direct gebruik van de functionaliteit van burgerzakenmodules voor de intake en inhoudelijke afhandeling van zaken op het vlak van burgerlijke stand en andere burgerzakenonderwerpen. Zowel klantcontactmedewerkers als vakspecialisten kunnen dus ‘behandelaar’ van een zaak zijn, afhankelijk van het precieze zaaktype (zie [2]) en de status van zaak. In de specificaties burgerzakenmodules is ervoor gekozen deze behandelaar als actor te beschouwen. Dit is gedaan om de specificaties zo dicht mogelijk bij de procesbeschrijvingen te houden en om te voorkomen dat er schijnbaar onsamenhangende functionaliteit voor bijvoorbeeld klantcontactmedewerker en vakspecialist gespecificeerd wordt die eigenlijk tot de afhandeling van eenzelfde soort zaak behoort. De keten use cases beschrijven daarmee dus niet per se de gebruikerstaak van één persoon, maar de taak van alle personen die de rol van behandelaar in een bepaalde zaak hebben. In de praktijk kan het derhalve voorkomen dat de rol van de actor ‘behandelaar’ door meerdere personen ingevuld wordt. Ook voor niet-zaakgerichte keten use cases is gebruik gemaakt van de behandelaar als actor. Mede als gevolg van deze keuze ontstaan er in de keten use case beschrijvingen ‘wachtmomenten’. Deze wachtmomenten zijn op twee manieren te herkennen: “de use case wacht…” en “het systeem wacht…”. In het eerste geval betreft het een wachtmoment in de keten use case waar het systeem6 geen actieve rol in speelt, denk hierbij aan bijvoorbeeld het wachten op een antwoord van de IND of het wachten op het binnenkomen / afhalen van een reisdocument. In het tweede geval bewaakt het systeem actief de periode. Hierbij kan gedacht worden aan het wachten op bijvoorbeeld het aanbreken van de verhuisdatum of het verlopen van termijn.

2.2.3

Opzet use case model In de specificaties burgerzakenmodules wordt bijna alle burgerlijke stand- en andere burgerzakenfunctionaliteit beschouwd als zaak. De keten use cases, bijvoorbeeld voor het aangeven van een huwelijk of een geboorte, volgen daarom ook bijna allemaal hetzelfde globale GEMMA-stramien van intake, behandelen, besluiten en leveren (zie Figuur 1). Daarbinnen zijn telkens dezelfde globale stappen te herkennen: GEMMA Intake

Behandelen/ Besluiten

Globale stappen in keten use cases 1. Behandelaar voert betrokken persoon in. 2. Systeem zoekt en toont gegevens rond betrokken persoon. 3. Behandelaar voert overige gegevens in die verband houden met de aanvraag/aangifte. 4. Systeem creëert één of meerdere zaken. De stappen behandelen en besluiten van het GEMMA proces, zijn in de use case beschrijvingen samengenomen en verwoord als: 5. Behandelaar bekijkt zaak en complementeert en accordeert de zaak.

Leveren

6. Systeem werkt zaak status bij. 7. Systeem creëert eventueel akte / kennisgeving en verwerkt resultaten van de aanvraag / aangifte. 8. Systeem sluit en archiveert zaak.

6 Let op: met ‘het systeem’ wordt hier dus de keten van burgerzakenmodules en centrale voorzieningen bedoeld, zie 1.3. Pagina 11 van 25


Stappen 4,6 en 8 zijn niet zozeer gerelateerd aan de inhoudelijke procesonderdelen, maar duiden procesovergangen aan die de status van de zaak veranderen. Omdat deze stappen in alle keten use cases terugkomen is ervoor gekozen ze op één plaats generiek te beschrijven, als keten use case Behandelen zaak7. Alle specifieke zaakgerichte use cases, bijvoorbeeld voor het aangeven van een huwelijk, zijn gemodelleerd als specialisatie hiervan. Dit om het telkens opnieuw opnemen van gelijksoortige specificatietekst te voorkomen, zie Figuur 2.

Generiek: behandelen zaak

1. Behandelaar voert betrokken persoon in 2. Systeem zoekt en toont gegevens rond betrokken persoon 3. Behandelaar voert overige gegevens in welke verband houden met de aanvraag / aangifte

behandelen &besluiten

4. Systeem creëert één of meerdere zaken 5. Behandelaar bekijkt zaak en complementeert en accordeert de zaak

Leveren

lIntake

Specifiek: registreer …

7. Systeem creëert eventueel akte / kennisgeving en verwerkt resultaten van de aanvraag / aangifte

6. Systeem werkt zaak status bij

8. Systeem sluit en archiveert zaak

Figuur 2

Gebruik van generalisatie/specialisatie om herhaling te voorkomen

Een zaak start dus pas nadat er een succesvolle intake heeft plaatsgevonden. Klantcontacten die niet leiden tot daadwerkelijk behandelen (bijvoorbeeld het beantwoorden van een vraag om algemene informatie) worden niet onderkend als zaak. Omdat in overeenstemming met de GEMMA-procesarchitectuur de inhoudelijke beoordeling pas start na het creëren van een zaak, zal tijdens de intake van een zaak in principe geen inhoudelijke controle – bijvoorbeeld van bedrijfsregels – plaatsvinden. Op alle plaatsen in de keten use cases waar van behandelaar gewisseld zou kunnen worden of waar een mijlpaal wordt bereikt, wordt de zaak geactualiseerd. De zaak krijgt een nieuwe status en soms wordt een andere behandelaar verantwoordelijk voor het behandelen van de zaak. Omdat het gewenste gedrag mede afhangt van de binnen een gemeente onderkende zaaktypes/zaakstatussen en het al dan niet gebruikte zaaksysteem, is dit niet verder uitgewerkt in de specificaties burgerzakenmodules. Indien een gemeente beschikt over een zaaksysteem dat het toewijzen van zaken ondersteund dan kan dit naar alle waarschijnlijkheid binnen dit zaaksysteem ingesteld worden. Behandelen zaak beschrijft ook algemene functionaliteit rond de eventuele ‘samenloop’ van zaken en (fout)afhandeling. Samenloop van zaken kan bijvoorbeeld gaan om het per ongeluk dubbel opvoeren van zaken of het relateren van hoofd- en deelzaken. In de specifieke zaakgerichte keten use case wordt gebruik gemaakt van publieke ‘extension points’ die verwijzen naar Behandelen zaak, zie Figuur 3.

7 In de specificaties terug te vinden als “KUC200 Behandelen zaak”. Pagina 12 van 25


Specifiek: registreer … 1. … {invoeren gegevens} [referentie naar KUC200] 2. Behandelaar voert persoonsgegevens van nieuwgeborene(n), geboortegegevens en overige geboorteaangifte gegevens (bijv. eventuele naamskeuze) in. 3. Systeem valideert compleetheid persoonsgegevens en geboortegegevens. {compleetheid gevalideerd} [referentie naar KUC200] 4. …

Generiek: behandelen zaak Alternatief verloop Zaak incompleet Als op {compleetheid gevalideerd} (in specialisatie use case) de ingevoerde zaak gegevens incompleet zijn om de intake af te sluiten, dan 1. Systeem toont melding dat de ingevoerde gegevens incompleet zijn. 2. De use case vervolgt op {invoeren gegevens} (in specialisatie use case)

Figuur 3 Gebruik van extension points voor verwijzing naar generieke afhandeling Bij het afsluiten van een zaak zal deze gearchiveerd worden, zodat deze zaak in een later stadium nog geraadpleegd kan worden. Het zoeken naar zaken of het onderhouden van relaties tussen zaken en documenten is wel opgenomen in de specificaties burgerzakenmodules, maar niet in detail uitgewerkt. Dit omdat de exacte specificaties afhankelijk zijn van de individuele wensen en eisen van gemeenten en van de bestaande inrichting binnen een gemeente. 2.2.4

Gebruik van het begrip ‘zaak’ De specificaties burgerzakenmodules volgen de voorschriften voor het creëren van zaken en het koppelen van zaken uit het RGBZ. Daarom is de volgende rationale voor het maken van zaken aangehouden: er wordt een zaak gecreëerd per besluit of gebeurtenis. Dat betekent dat in principe per rechtsfeit per persoon een zaak wordt aangemaakt. Bijvoorbeeld: • een geboorteaangifte van een drieling levert 3 zaken, • een verhuizing van 2 volwassenen levert 2 zaken en • een geboorteaangifte met gelijktijdige erkenning levert 2 zaken. Sommige rechtsfeiten slaan op meerdere personen, zoals bijvoorbeeld een huwelijk. In dat geval wordt één zaak gemaakt. Om bij gerelateerde gebeurtenissen de samenhang te bewaren wordt in de specificaties beschreven dat zaken aan elkaar te relateren moeten kunnen zijn. Dat kan ‘hoofdzaken’ en ‘deelzaken’ betreffen: bij bijvoorbeeld een aangifte van een meerling wordt een hoofdzaak voor de geboorteaangifte gemaakt en per geborene een deelzaak die gekoppeld wordt aan de hoofdzaak. Het kan ook gaan om zaken die een logisch gevolg van elkaar zijn: de zaak die gedefinieerd wordt voor het voorbereiden en vastleggen van een huwelijk moet gekoppeld kunnen worden aan de zaak die eerder was gemaakt voor het vastleggen van de aangifte.

Pagina 13 van 25


2.3 Gericht op ingezetenen Hoewel de registratie van persoonsgegevens over niet-ingezetenen vergelijkbaar is met die bij ingezetenen (bijhouding, raadpleging, levering, terugmelding), is de uitvoering anders georganiseerd. Niet de gemeenten, maar de minister is verantwoordelijk voor de bijhouding van deze gegevens, zie [1]. De minister krijgt deze gegevens aangeleverd van aangewezen bestuursorganen: bestuursorganen die omgang hebben met niet-ingezetenen en door de minister een bijzondere rol toegewezen hebben gekregen bij de bijhouding van persoonsgegevens over niet-ingezetenen. Aangezien de persoonsgegevens over niet-ingezetenen onderdeel uit zullen maken van BRP is binnen de specificaties burgerzakenmodules rekening gehouden met het feit dat de gegevens over niet-ingezetenen bevraagd kunnen worden. De bijhouding van deze gegevens maakt geen onderdeel uit van deze specificaties burgerzakenmodules.

Pagina 14 van 25


3

Keten Use Case View

3.1 Actoren Binnen het use case model wordt gebruik gemaakt van een diversiteit aan actoren. Deze actoren zijn onder te verdelen in primaire actoren en de secundaire actoren. Met primaire actoren zijn actoren bedoeld die het systeem (dus: de keten van burgerzakenmodules en centrale voorzieningen) rechtstreeks gebruiken om een bepaald doel te realiseren. Secundaire actoren zijn de actoren die het systeem ondersteunen bij het uitvoeren van de keten use case. De belangrijkste primaire actor voor de keten use cases op het gebied van burgerlijke stand- en andere burgerzakenfunctionaliteit is de Behandelaar, zie 2.2.2. Een andere belangrijke actor is de Afnemer. In het kader van de burgerzakenfunctionaliteit is die echter bijna alleen betrokken als de afhandeling van een zaak leidt tot nieuwe of aangepaste persoonsgegevens binnen het interessegebied van de afnemer. Burgers zijn geen primaire actoren voor de BRP, al hebben zij via bepaalde voorzieningen van gemeenten of rijksoverheid – zoals mijnoverheid.nl – toegang tot hun gegevens. Als secundaire actors kennen de keten use cases een diversiteit aan systemen of personen die vanuit het perspectief van het systeem een ondersteunende een rol vervullen. Hierbij kan gedacht worden aan: • Beheervoorziening BSN (BV BSN) voor het ophalen en controleren van burgerservicenummers; • RAAS (Reisdocumenten Aanvraag en Archief Station) voor functionaliteit met betrekking tot reisdocumenten, • CRB (Centraal Rijbewijsregister en Bromfietscertificatenregister) voor functionaliteit met betrekking tot rijbewijzen en bromfietscertificaten, • OSV (Ondersteunende Software Verkiezingen) voor functionaliteit met betrekking tot verkiezingen, • JustID (Justitiële Informatiedienst – Almelo) voor kennisgeving van opgestelde akten, • Lokaal BAG (Basisregistraties Adressen en Gebouwen) voor het vastleggen, ophalen of controleren van adres- en/of gebouwgegevens, • IND (Immigratie- en Naturalisatiedienst) voor communicatie rond het aanvragen en verlenen van verblijfstitels. De volledige lijst actoren is opgenomen in het keten use case model. 3.2 Overzicht van het keten use case model De functionaliteit voor ondersteuning van burgerzakenprocessen is in een aantal hoofdgebieden in te delen: •

•

Zaakfunctionaliteit – Om zaakgericht te kunnen werken is functionaliteit nodig voor bijvoorbeeld het kunnen zoeken van zaken of het toevoegen van brondocumenten die in de gemeentelijke en landelijke voorzieningen zijn opgeslagen. Waar beschikbaar zou hiervoor een bestaand gemeentelijk zaaksysteem gebruikt kunnen worden. In het keten use case model is deze functionaliteit te vinden onder 00 Overkoepelende functionaliteit8 en daarbinnen 02 Zaakfunctionaliteit. Raadplegen persoonsgegevens – Het zoeken en tonen van persoonsgegevens gebeurt veelal binnen keten use cases. Voorbeeld is de keten use case Registreren geboorte, waarin bij de intake de gegevens van de moeder en relaties (partner en kinderen) opgezocht en getoond worden. De keten use case Raadplegen persoonsgegevens beschrijft juist het zoeken van personen en het tonen van de gevonden persoons- en

8 Het keten use case model is ingedeeld in ‘packages’, met namen als 00 Overkoepelende functionaliteit. Pagina 15 van 25


•

•

zaakgegevens los van een specifieke zaak. Een ambtenaar kan deze keten use case bijvoorbeeld gebruiken bij het contact met een burger, nog voordat er een zaak gestart is. In het keten use case model is deze functionaliteit te vinden onder 00 Overkoepelende functionaliteit en daarbinnen 01 Generiek. Inhoudelijke zaakafhandeling – binnen de specificaties wordt bijna alle burgerlijke stand- en andere burgerzakenfunctionaliteit als zaak beschouwd, zie 2.2.3. Dat geldt voor functionaliteit op het gebied van bijvoorbeeld afstamming (te vinden onder 01 Afstamming), naam en geslacht (te vinden onder 02 Naam en geslacht) et cetera, maar ook voor de wat meer algemene functionaliteit zoals: – het uitgeven van een uittreksel (keten use case Uitgeven uittreksel/afschrift burgerlijke stand, te vinden onder 00 Overkoepelende functionaliteit en daarbinnen 01 Generiek), – het registreren van (nagekomen) brondocumenten (keten use case Registreren brondocument te vinden onder 10 Overig) – het doen van meldingen met betrekking tot gerede twijfel richting een basisregistratie (keten use case Melden gerede twijfel te vinden onder 00 Overkoepelende functionaliteit en daarbinnen 01 Generiek) en het onderzoeken van eventueel binnengekomen meldingen (keten use case Behandelen onderzoek te vinden onder 11 Onderzoek). Alle zaakgerichte functionaliteit is gemodelleerd als specialisatie van KUC200 Behandelen zaak. Binnengemeentelijke levering, verkiezingen en CRIB – er is binnen het burgerzakendomein ook functionaliteit nodig die verder weinig met de afhandeling van zaken te maken heeft. Zo is er functionaliteit nodig rond verkiezingen (met keten use cases als Onderhouden kiesrecht of Onderhouden kiesdistricten en bureaus), rond het Centraal Registratie en Informatiebureau (CRIB, met keten use case als Onderhouden incidentenplan of Raadplegen slachtoffergegevens) en binnengemeentelijke leveringen. In het keten use case model is deze functionaliteit te vinden onder 12 Binnengemeentelijke levering, 13 Verkiezingen en 14 CRIB.

Figuur 4 geeft een overzicht van deze gebieden en de samenhang tussen de gespecificeerde keten use cases. Alleen de actor Behandelaar is in de figuur opgenomen.

Figuur 4

Samenhang tussen de keten use cases en indeling in modelonderdelen

Figuur 4 laat ook zien dat er bij de inhoudelijke afhandeling van zaken bepaalde functionaliteit vaker terug komt. Deze functionaliteit is gemodelleerd als twee keten use cases – te vinden onder 00 Overkoepelende functionaliteit en daarbinnen 01 Generiek – die vanuit de andere keten use cases gebruikt (of ge-“include”) worden: •

KUC204 Afhandelen betaling – bij de behandeling van zaken spelen soms betalingen (leges) een rol, bijvoorbeeld bij de uitgifte van een rijbewijs. Het betreft voornamelijk processen waar geen aangifteplicht voor geldt. De keten use case KUC204 Afhandeling

Pagina 16 van 25


•

betaling beschrijft algemene functionaliteit zoals het bepalen van leges, het vaststellen van de betaalwijze, het registreren van de betaling en het afhandelen van foutsituaties. Aangezien de hoogte van de leges afhankelijk is van een scala aan criteria is de daadwerkelijke berekening van de leges niet beschreven. KUC205 Afhandelen akte – bij de behandeling van zaken spelen akten regelmatig een rol. De keten use case KUC205 Afhandelen akte beschrijft algemene functionaliteit zoals het creëren van een akte, het printen van een akte, het bevestigen van het feit dat de akte getekend is, het opsturen van de akte richting JustID en het eventueel afhandelen van foutsituaties. Deze keten use case beschrijft tevens – in de vorm van ‘special requirements’ – de voorschriften rond het creëren van akten en de mogelijkheid om de akte te maken met een verklaring van ontbrekende handtekening.

Voor het creëren van documenten zoals bijvoorbeeld kennisgevingen is binnen de keten use cases veelal een algemene stap opgenomen. De daadwerkelijk te creëren documenten – uiteraard met uitzondering van die documenten die vanuit weten regelgeving vereist zijn – kunnen per gemeenten verschillend zijn en zijn derhalve niet gespecificeerd. 3.3 3.3.1

Uitgelicht

Melden en afhandelen gerede twijfel Voor basisadministraties geldt dat afnemers geconstateerde fouten of vermoedens van fouten moeten melden aan de registratiehouder – de ‘melding gerede twijfel’. De registratiehouder moet de meldingen onderzoeken en eventueel de gegevens corrigeren. In de specificaties burgerzakenmodules is functionaliteit rond de melding van twijfel op twee plaatsen te vinden. Het melden van gerede twijfel is beschreven in de keten use case KUC203 Melden gerede twijfel, te vinden onder 00 Overkoepelende functionaliteit en daarbinnen 01 Generiek. De keten use case beschrijft het doen van meldingen over gegevens uit de BRP, maar ook over gegevens uit andere basisadministraties zoals de Basisregistratie Adressen en Gebouwen of het Nationaal Handelsregister. Het ontvangen en onderzoeken van meldingen die een gemeente zélf ontvangt – als registratiehouder van een deel van de gegevens uit de BRP – is beschreven in de keten use case KUC111 Behandelen onderzoek uit 11 Onderzoek. De keten use case beschrijft ook dat de melder van de gerede twijfel op de hoogte gehouden wordt van eventuele uitkomsten van het onderzoek. In het use case model is bij wijze van uitzondering naast de keten use case KUC111 Behandelen onderzoek ook een applicatie use case MUC115 Raadplegen ontvangen BRPberichten opgenomen. Die beschrijft niet het gewenste gedrag van de keten van burgerzakenmodules en centrale voorzieningen, maar specifiek van de burgerzakenmodules. Dit om expliciet duidelijk te maken dat er binnen de burgerzakenmodules functionaliteit aanwezig moet zijn om de meldingen die vanuit de centrale voorzieningen van de BRP worden ontvangen in te kunnen zien.

3.3.2

Landelijke taken De gemeente Den Haag heeft een aantal landelijke taken, uitgevoerd door de afdeling Landelijke Taken. Deze afdeling schrijft bijvoorbeeld buitenlandse akten van Nederlanders in. Ook regelt de afdeling bijvoorbeeld de ondertrouwakte voor een huwelijk of partnerschapsregistratie en de omzetting van een partnerschapsregistratie naar een huwelijk voor Nederlanders die in het buitenland wonen. Een aantal grensgemeenten verleent daarnaast een aantal bijzondere diensten op het gebied van reisdocumenten. Vanwege het specifieke karakter is de ondersteuning van dergelijke taken en diensten niet beschreven in de specificaties burgerzakenmodules. Hierover zal met de betrokken gemeenten nader overleg worden gevoerd.

Pagina 17 van 25


3.4

Aanvullende functionele specificaties

3.4.1

Termenlijst en business object model De keten use cases zijn in tekstvorm beschreven met gebruikmaking van een vast template. De belangrijke concepten uit de beschrijvingen (zoals geboorteaangifte en nieuwgeborene in de keten use case KUC001 Registreren geboorte) zijn toegelicht in een termenlijst. Een business object model (in de vorm van verschillende UML9 class diagrammen) geeft verdere toelichting op de concepten door de samenhang inzichtelijk te maken, bijvoorbeeld door weer te geven dat een geboorteaangifte betrekking kan hebben op één of meerdere nieuwgeborenen en dat per nieuwgeborene één geboorteakte wordt opgemaakt.

3.4.2

Aanvullende eisen, bedrijfsregels en meldingregels In de specificaties burgerzakenmodules is op verschillende manieren aanvullend gewenst gedrag op genomen: • Bedrijfs- en meldingregels – regels die gelden bij de uitvoering van keten use cases. Bedrijfsregels zijn blokkerend: als niet aan de regel voldaan wordt, dan kan de keten use case niet succesvol worden afgerond. Meldingsregels attenderen de actor op uitzonderlijke situaties, maar staan het vervolg van de use case niet in de weg. • Features – gewenst aanvullend gedrag van de modules. Een voorbeeld is dat de module 01 Afstamming de gegevens van een ouder automatisch invult bij de oudergegevens als de aangever van een geboorte de ouder is. Geldende bedrijfs- en meldingsregels zijn opgenomen bij de relevante keten use case beschrijvingen. Bedrijfs- en meldingsregels en features zijn ook opgenomen in het Enterprise Architect model, waarbij daar waar mogelijk is aangegeven welke regels en features gelden voor welke keten use cases. Voor het volledige beeld van de gewenste functionaliteit moeten dus niet alleen de keten use case specificaties bekeken worden, maar ook de al dan niet use case specifieke regels en features. In [5] is nog een aantal andere aanvullende eisen opgenomen die voor meer keten use cases van toepassing zijn. Hierin is bijvoorbeeld uitgewerkt welke variabelen gebruikt moeten kunnen worden om een persoon te zoeken – iets wat in veel keten use cases terugkomt.

9 Unified Modeling Language, zie http://www.uml.org/ Pagina 18 van 25


4

Logical View

De keten use cases beschrijven de functionaliteit die de keten van burgerzakenmodules en centrale voorzieningen moet bieden voor de ondersteuning van de burgerzakenprocessen. Deze functionaliteit moet dus deels door de burgerzakenmodules, deels door de centrale voorzieningen worden gerealiseerd. De keten use case realizations geven per keten use case aan hoe de verschillende componenten uit de keten met elkaar communiceren om de functionaliteit te realiseren. De keten use case realizations gaan daarbij uit van: • een indeling in burgerzakenmodules, • koppelvlakken voor de centrale voorzieningen en • ontwerpkeuzes voor de verdeling van verantwoordelijkheden tussen burgerzakenmodules en centrale voorzieningen. 4.1 Indeling in burgerzakenmodules De specificaties onderkennen de volgende burgerzakenmodules: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.

Afstamming Naam en geslacht Documenten en verzoeken Huwelijk en partnerschap Migratie Nationaliteit Reisdocumenten Rijbewijzen Overlijden Overig Onderzoek Binnengemeentelijke levering10 Verkiezingen Centraal registratie en informatie bureau (CRIB)

Deze modules zijn in de specificaties terug te vinden als de ‘packages’ waarbinnen de verschillende keten use cases gegroepeerd zijn, maar óók als logische componenten of ‘components’. Dit ondanks het feit dat de specificaties burgerzakenmodules uitdrukkelijk géén softwarearchitectuur of softwareontwerp voor de burgerzakenmodules voorschrijven, zie 1.5. De reden om toch modules te definiëren is om tot uitdrukking te brengen dat er geen sprake hoeft te zijn van één gemeentelijke voorziening. De keten van burgerzakenmodules en centrale voorzieningen kan aan de kant van de gemeente bestaan uit verschillende gespecialiseerde voorzieningen – verschillende burgerzakenmodules, dus – eventueel gerealiseerd door verschillende softwareleveranciers. Om dit te faciliteren is onafhankelijke functionaliteit gegroepeerd in onafhankelijke modules. Het is aan de gemeente om te besluiten of daadwerkelijk afzonderlijke burgerzakenmodules gewenst zijn. Functionaliteit die in meerdere modules kan worden gebruikt is onder gebracht in een overkoepelde package “00 Overkoepelende Functionaliteit”. 4.1.1

Documenten en verzoeken Functionaliteit met betrekking tot documenten en verzoeken is in verschillende modules terug te vinden. Verzoeken die betrekking hebben op specifieke functionaliteit zijn opgenomen in de module die die functionaliteit beschrijft. Zo is KUC022 Behandelen verzoek verklaring van verscheidenheid van familienamen onderdeel van de module 02 Naam en

10 Binnengemeentelijke levering is niet uitgewerkt in de specificaties burgerzakenmodules. Hiervoor wordt een aparte uitwerking opgesteld. Pagina 19 van 25


Geslacht en KUC094 Behandelen verzoek opgravingsverlof onderdeel van module 09 Overlijden. Wat meer algemene functionaliteit zoals KUC031 Uitgeven document of KUC032 Behandelen verzoek leveringsbeperking is opgenomen in module 03 Documenten en Verzoeken. 4.1.2

Overkoepelende functionaliteit Hoofdstuk 3 beschrijft functionaliteit die – als er sprake zou zijn van afzonderlijke modules – voor meerdere modules relevant zou zijn. Denk hierbij aan de functionaliteiten als het raadplegen persoonsgegevens, het uitgeven uittreksel/afschrift burgerlijke stand en melden gerede twijfel. In de specificaties burgerzakenmodules is deze functionaliteit ondergebracht in een package 00 Overkoepelende functionaliteit. Bij het realiseren van de gemeentelijke voorzieningen in de vorm van verschillende modules is het een ontwerpvraag waar deze functionaliteit gerealiseerd wordt. 4.2 Koppelvlakken centrale voorzieningen Voor het krijgen van inzicht in de verantwoordelijkheidsverdeling tussen burgerzakenmodules en centrale voorzieningen is de interne structuur van de centrale voorzieningen niet van belang. Wel van belang is dat de componenten binnen de centrale voorzieningen te benaderen zijn via een beperkt aantal koppelvlakken. De keten use case realizations uit de specificaties burgerzakenmodules beschrijven de communicatie tussen de verschillende burgerzakenmodules (zie 4.1) en de volgende koppelvlakken voor de centrale voorzieningen: • •

• •

BRP-Bijhouding – diensten voor het invoeren, muteren en controleren van persoonsgegevens ten behoeve van de bijhoudingsprocessen; BRP-Bevraging – diensten voor de bevraging van persoonsgegevens door gebruikers van de BRP; dit zijn zowel de ‘klassieke’ afnemers (Belastingdienst, SVB,…) als gemeentelijke diensten, niet zijnde burgerzaken.. Bij alle gebruikte diensten ligt het initiatief bij de gebruiker. Het woord “bevraging” is gedacht vanuit die gebruiker; BRP-Levering – diensten voor het op initiatief van de BRP leveren van gegevens aan gebruikers die een bepaald abonnement hebben en voor bewerken van abonnementen (indicaties). “Levering” is gedacht vanuit de BRP; BRP-Terugmelding – diensten met betrekking op het doen en verwerken van meldingen over persoonsgegevens.

Deze koppelvlakken bieden ‘betekenisvolle’ diensten; dat wil zeggen dat uit de naam van een dienst direct te achterhalen is wat de dienst levert en hoe dat aansluit bij het proces (en de handelingen) waarbinnen de dienst wordt aangeroepen. Dat betekent bijvoorbeeld diensten als RegistreerGeboorte in plaats van OpslaanPersoonsgegevens. Er is potentieel een groot aantal handelingen dat leidt tot een bijhouding. Dat leidt, gegeven het voorgaande, automatisch tot een groot aantal diensten binnen de koppelvlakken. Technisch gezien zijn deze bijhoudingen echter grotendeels gelijk, omdat ze dezelfde stappen doorlopen. In programmatuur is uiteindelijk het aantal functies beperkt. De specifieke dienst maakt het ook mogelijk de juiste validatie toe te passen op wat in technische zin gelijksoortige functies zijn. In programmatuur is het aannemelijk dat de fysieke vastlegging door een beperkt aantal functies uitgevoerd wordt, aangestuurd door groter aantal meer functioneel gerichte diensten. 4.3

Verdeling verantwoordelijkheden burgerzakenmodules en centrale voorzieningen

4.3.1

Beleids- en ontwerpkeuzes Eén van de belangrijkste vraagstukken voor de opzet van de BRP is welke functionaliteit door welke voorziening – gemeentelijk of centraal – gerealiseerd wordt. Belangrijk beleidsuitgangspunt is dat de centrale voorzieningen zich richten op diensten rond de in de Pagina 20 van 25


wet BRP beschreven verantwoordelijkheden en gegevens. De wet biedt daarbij een kader voor de verdeling van verantwoordelijkheid en aansprakelijkheid. Een ander, gerelateerd uitgangspunt is om wel zoveel mogelijk van die door de wet bepaalde zaken in de centrale voorzieningen te beleggen. De reden hiervoor is dat geen stelsel van aanvullende afspraken – en controle daarop – nodig is over hoe allerlei partijen hun verantwoordelijkheden moeten invullen: dat is in immers één keer centraal geregeld. Aanvullende overwegingen zijn: •

Het flexibeler en goedkoper aanpassen van de BRP omdat wijzigingen één keer centraal in plaats van in alle gemeentelijke voorzieningen hoeven te worden doorgevoerd. • Er ontstaat een uniforme functionele en technische omgeving rond persoonsgegevens, wat voordelen biedt voor het mogelijk maken van plaatsonafhankelijk werken en het ondersteunen van gemeentelijke samenwerking. In de specificaties – en dan met name in de Keten Use Case Realizations – is uitgewerkt hoe deze verdeling is ingetekend.

4.3.2

Vast stramien van communiceren Voor de verdeling van de functionaliteit voor de ondersteuning van burgerzakenprocessen zijn de bovenstaande uitgangspunten als volgt uitgewerkt: •

•

Daadwerkelijke bijhouding centraal – de daadwerkelijke bijhouding gebeurt in de centrale voorzieningen. De procesondersteuning vindt plaats in de burgerzakenmodules. De reden hiervoor is dat de bijhouding van persoonsgegevens over ingezetenen en nietingezetenen is geregeld in de wet, de verdere ondersteuning van burgerzakenprocessen niet. In die laatste processen zijn door gemeenten ook onderlinge verschillen gewenst. Controles centraal – de controles van persoonsgegevens vinden plaats in de centrale voorzieningen. De reden hiervoor is dat centrale realisatie eenduidige, uniforme controles mogelijk maakt. Doordat bovendien centraal alle persoonsgegevens bij elkaar staan, zijn betere en efficiënte controles mogelijk. De controlefuncties zijn overigens wel te gebruiken in de burgerzakenmodules. De centrale voorzieningen bieden hiervoor prevalidadatie diensten. De burgerzakenmodules vragen de centrale voorzieningen de ingevoerde gegevens vooraf te controleren, zodat correcties en aanvullingen kunnen plaatsvinden. Dit vergroot de voorspelbaarheid van acties en hiermee kan bijvoorbeeld voorkomen worden dat verkeerde gegevens op een akte terechtkomen. De daadwerkelijke registratie van gegevens vindt hierna plaats11.

In de keten use case realizations leidt deze uitwerking tot een herkenbaar communicatiepatroon tussen burgerzakenmodules en (de koppelvlakken van) de centrale voorzieningen: 1. Tijdens de intake van een zaak vraagt de betreffende burgerzakenmodule op basis van identificerende kenmerken de persoonsgegevens van de betrokken personen op bij de centrale voorzieningen via koppelvlak BRP-Bevraging. Afhankelijk van het type zaak kunnen bijvoorbeeld ook de relaties van een persoon en de persoonsgegevens van de gerelateerde personen worden opgevraagd. Validatie of bijvoorbeeld alle voor een aangifte benodigde gegevens zijn ingevoerd vindt plaats in de burgerzakenmodule zelf. 2. Bij de behandeling van een zaak kan de behandelaar nieuwe of gewijzigde persoonsgegevens invoeren in de burgerzakenmodule. Alvorens bijvoorbeeld een akte af te drukken kan de burgerzakenmodule de nieuwe of gewijzigde persoonsgegevens bij de centrale voorzieningen pre-valideren via koppelvlak BRP-Bijhouding. Deze gegevens zijn op dit moment nog niet zichtbaar voor andere gemeenten of afnemers. 3. Na eventuele correctie of bijstelling van de gegevens vindt de verdere inhoudelijke afhandeling van de zaak plaats binnen de burgerzakenmodule, bijvoorbeeld in de vorm van het afdrukken van een akte. Pas daarna vindt de echte vastlegging van de nieuwe 11 Hierbij worden overigens de persoonsgegevens opnieuw gecontroleerd. Dit omdat bijvoorbeeld in de tussentijd de persoonsgegevens veranderd zouden kunnen zijn. Pagina 21 van 25


persoonsgegevens plaats doordat de burgerzakenmodules via koppelvlak BRPBijhouding de persoonsgegevens registreren. Pas na correcte verwerking van de registratie door de centrale voorzieningen zijn de gegevens zichtbaar voor andere gemeenten of afnemers en vindt levering plaats aan geabonneerde afnemers. 4.3.3

Uitwerking in keten use case realizations en component model De keten use case realizations binnen de specificaties burgerzakenmodules zijn uitgewerkt als UML sequence diagrammen. Per keten use case – en zelfs per belangrijke alternatieve ‘stroom’ binnen een keten use case – is in een sequence diagram uitgewerkt hoe de betrokken burgerzakenmodules en BRP-koppelvlakken communiceren. De specificaties burgerzakenmodules bieden in de vorm van UML component diagrammen tevens de mogelijkheid om per component (burgerzakenmodules en BRP-koppelvlakken) te bekijken wat het totaal aan diensten is dat de component biedt.

Pagina 22 van 25


5

Kwaliteit

De specificaties burgerzakenmodules leggen vooral nadruk op de benodigde functionaliteit om de burgerzakenprocessen te ondersteunen. Eisen met betrekking tot de mate waarin die ondersteuning zal moeten plaatsvinden, zullen in het traject dat gemeenten nu zullen inzetten, duidelijk worden. Op verschillende manieren is een aanzet gemaakt tot het specificeren van deze voornamelijk niet-functionele eisen: • Bij het opstellen van de procesbeschrijvingen (zie 2.2.1) zijn direct ook wensen van de betrokken gemeenten vastgelegd; • Vanuit programma mGBA zijn eisen beschikbaar in de vorm van programma-eisen uit de definitiestudie, architectuurprincipes uit de programma-startarchitectuur en algemene acceptatiecriteria voor programmaproducten. Voor een deel zijn deze eisen ook relevant voor de specificaties burgerzakenmodules; • Bij het uitwerken van de specificaties burgerzakenmodules is met de reviewgroep – bestaande uit vertegenwoordigers van gemeenten – aan de hand van het Extended ISO 9126 model12 de lijst van de bovenstaande wensen en eisen besproken. De eisen en wensen zijn ingedeeld naar de verschillende kwaliteitscategorieën. Bovendien is kort stilgestaan voor welke kwaliteitscategorieën aanvullende eisen nodig zijn. Bij iedere eis of wens is vastgelegd of het een eis betreft die voor alle gemeenten hetzelfde zou kunnen zijn, of dat de eis gemeente-specifiek is. Het resultaat is vastgelegd in [6]. Voorbeeld: BRU.1 “Kunnen gebruiken van een paspoortlezer” is een kwaliteitseis met betrekking tot Bruikbaarheid/gebruiksvriendelijkheid. Het kan efficiency van het gebruik van de applicatie vergroten. Het is echter aan de gemeente om te bepalen of een paspoortlezer nuttig is.

12 Het Extended ISO 9126 model beschrijft een aantal soorten kwaliteitskenmerken van software. Het model onderscheidt een zestal hoofdcategorieën die elk weer onderverdeeld zijn in een aantal subcategorieën. Pagina 23 van 25


6

Openstaande punten

De centrale voorzieningen – en daarmee tevens de koppelvlakken met de burgerzakenmodules – komen iteratief tot stand, zie §1.4. Dat betekent dat een aantal onderwerpen nader ingevuld zal worden ter aanvulling op deze specificaties. In enkele gevallen kan dit leiden tot wijzigingen van de specificaties. De beheerder van deze specificaties zal hierop toezicht houden en daar waar nodig wijzigingen doorvoeren en gebruikers hierover informeren. 6.1

Ontbrekende onderwerpen en onderdelen

6.1.1

Wijze van aansluiten IND De wijze waarop de IND op de BRP aansluit is nog onderwerp van nadere uitwerking. De keten use cases beschrijven de communicatie tussen de BRP en de IND nu alleen in algemene termen zoals “use case wacht totdat naturalisatiebesluit is ontvangen van IND”.

6.1.2

Binnengemeentelijke leveringen Binnen het gemeentelijke landschap bestaan ‘lokale afnemers’ die gegevens nodig hebben over ingezetenen van de gemeente. Denk bijvoorbeeld aan de sociale dienst van een gemeente. In de specificaties burgerzakenmodules is een module Binnen gemeentelijke leveringen benoemd, maar de uitwerking van de specificaties op dit vlak ontbreekt, in afwachting van de uitkomsten van een onderzoek dat KING uitvoert in opdracht van VNG en het programma mGBA. De uitkomst van het onderzoek zal de input leveren voor het alsnog specificeren van deze module.

6.1.3

Samenwerkingsverbanden Binnen samenwerkingsverbanden kunnen gemeenten op verschillende manieren werk aan elkaar uitbesteden/overdragen. In praktijk ontstaan er daardoor situaties waarin ambtenaren van één gemeenten persoonsgegevens van ingezetenen uit andere gemeente mogen aanpassen. Om dit te ondersteunen zijn mechanismen nodig die het voor gemeenten mogelijke maken anderen te autoriseren voor het bijhouden van persoonsgegevens. Functionaliteit voor het instellen en controleren van autorisaties is nog niet beschreven in de specificaties burgerzakenmodules.

6.1.4

Authenticatie en autorisatie Los van eventuele samenwerkingsverbanden is ook de ‘normale’ wijze van authenticatie en autorisatie binnen de keten van burgerzakenmodules en centrale voorzieningen nog niet gespecificeerd. De precieze samenwerking en wederzijdse verwachtingen op dit vlak tussen burgerzakenmodules en centrale voorzieningen zullen nog worden uitgewerkt.

6.1.5

Beheer De keten use cases beschrijven nu vooral de functionaliteit die nodig is om de primaire burgerzakenprocessen te ondersteunen. Wat ontbreekt is een beschrijving van de functionaliteit om de werking van de keten in te stellen, bijvoorbeeld rond samenwerkingsverbanden (zie 6.1.3) of het instellen van het omgaan met informatie afkomstig van andere gemeenten of de centrale voorzieningen zelf (zie 6.2.1). Ook deze functionaliteit zal nog worden beschreven als hier meer duidelijkheid over is.

Pagina 24 van 25


6.2 6.2.1

Veranderende invulling

Fiatteren Volgens de wet ([1]) is de gemeente waarin een ingezetene woont verantwoordelijk voor de bijhouding van de persoonsgegevens over die ingezetene. In praktijk bestaan er allerlei situaties waarin bij andere gemeenten informatie ontstaat – soms zelfs in de vorm van wettelijke akten. Denk aan een geboorteaangifte in een gemeente waar de moeder / vader van het kind niet woonachtig is of de aangifte van het overlijden in een gemeente waar de overledene niet woonachtig was. Om dergelijke situaties efficiënt te ondersteunen zonder de wettelijke verantwoordelijkheid uit te hollen, introduceren we bij de centrale voorzieningen binnen de BRP het concept ‘fiatteren’. De gemeente waar het rechtsfeit plaatsvindt kan de betrokken persoonsgegevens invoeren en/of aanpassen. Gemeenten kunnen instellen voor welke gebeurtenissen (en voor welke gemeenten) de centrale voorzieningen die persoonsgegevens ook daadwerkelijk direct mogen veranderen en voor welke gebeurtenissen (en voor welke gemeenten) een eigen ambtenaar expliciet toestemming moet geven om, eventueel na aanpassing, de wijzigingen door te voeren. Hetzelfde mechanisme kan gebruikt worden om vervolghandelingen automatisch door de centrale voorzieningen af te laten handelen. Denk aan het (wettelijke verplichte) verbreken van een huwelijksrelatie na het overlijden van één van beide echtgenoten. Gemeenten kunnen instellen of de centrale voorzieningen dergelijke stappen mogen uitvoeren, of dat een expliciet fiat van een ambtenaar nodig is. Het fiatteringsmechanisme is nog niet beschreven in de specificaties en zal duidelijk worden aan de hand van het koppelvlak van de BRP, waarvan het concept eind 2011 zal worden opgeleverd.

6.2.2

Status specificaties module Verkiezingen De specificaties van de verkiezingen module hebben in tegenstelling tot de overige modules de status: “Concept”. Deze module heeft een afwijkende status omdat op het moment van publiceren voor deze module nog geen breed gedragen consensus was met betrekking tot de werking van deze module. Mogelijke aanpassingen zijn te verwachten in het eventueel integreren van OSV binnen de BZM Verkiezingen of tekstuele aanpassingen met betrekking tot de verantwoordelijkheid van de BZM Verkiezingen ten opzichte van de wettelijke verantwoordelijkheden zoals beschreven binnen de kieswet.

6.2.3

Aanvullende diensten centrale voorzieningen Omdat het ‘groeperen’ van gerelateerde wijzigingen in persoonsgegevens voor afnemers nuttig kan zijn, zouden de centrale voorzieningen kunnen voorzien in diensten die veelvoorkomende combinaties van wijzigingen combineren. Ook zouden de centrale voorzieningen de burgerzakenmodules in voorkomende gevallen alvast van de meest waarschijnlijk nog meer benodigde gegevens kunnen voorzien – denk aan het bij een aangifte van een verhuizing opleveren van de nog meer op hetzelfde adres woonachtige gerelateerde personen. Dergelijke ‘voorzetten’ en andere gecombineerde diensten worden wel voorzien, maar zijn nog niet precies uitgewerkt en verwerkt in de specificaties burgerzakenmodules.

Pagina 25 van 25

Inleiding specificaties burgerzakenmodules

Recommend Documents