Een moderne GBA mogelijk gemaakt …
Herijking van oorspronkelijke definitiestudie
December 2008
Versie 1.8 – 5 december 2008

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Versie beheer

Versie

Datum

Korte beschrijving wijzigingen

1.3

13-06-2005

Versie van oorspronkelijke definitiestudie
waarmee de stuurgroep mGBA op 9 juni 2005
heeft ingestemd en die als startpunt voor de
herijking is genomen.

1.4

3-10-2008

Eerste review experts Capgemini

1.5

10-10-2008

Tweede interne review experts Capgemini

1.6

15-10-2008

Eerste concept, opgeleverd aan mGBA, tevens
benut als input voor Gatewayreview

1.7.0

24-10-2008

Concept voor verspreiding naar expertteam en
consultatie van direct betrokkenen

1.7.1

5-11-2008

Managementsamenvatting en paragraaf 3.7
toegevoegd

1.8

5-12-2008

Commentaar expertteam en stuurgroep verwerkt

2.0

Versie waarin besluit t.a.v. vervolg verwerkt wordt

Naam auteurs:

•
•
•

De heer E. (Edward) Nuiten
De heer M. (Michael) Stoelinga
De heer R. (Robert) Vrij

Auteurs oorspronkelijke definitiestudie (1.3):

•
•
•
•
•
•
•

Wim Kegel
André Gronsveld
Adriaan Holthuizen
Hans Lapidaire
Lies de Leeuw
Roos Lucieer
Gerrit Slot

De leden van het expertteam dat heeft bijgedragen aan de herijking van de
definitiestudie zijn opgenomen in Bijlage D

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Definitiestudie modernisering GBA versie 2.0

– een herijking met oog op vervolg –

Naam auteur(s):

•
•
•

De heer E. (Edward) Nuiten
De heer M. (Michael) Stoelinga
De heer R. (Robert) Vrij

Bedrijfsnaam:

Capgemini Nederland B.V.

Plaats:

Utrecht

Datum:

5-12-08

© 2008 Capgemini. De informatie in dit document mag noch geheel noch
gedeeltelijk op enigerlei wijze worden aangepast, gewijzigd of verveelvoudigd
zonder voorafgaande toestemming van Capgemini

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Voorwoord
Gereserveerd voor conclusies / goedkeuring door stuurgroep / opdrachtgever

ii

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Inhoudsopgave
Voorwoord

ii

Inhoudsopgave

iii

Lijst van figuren en tabellen

v

Managementsamenvatting

1

1

Inleiding

7

1.1 Opdracht

7

1.2 Leeswijzer

8

2

11

De omgeving van de gemeentelijke basisadministratie

2.1 Context van de GBA

11

2.2 Veranderingen bij gemeenten stellen nieuwe eisen aan GBA

14

2.3 Wensen afnemers zijn ongewijzigd: snelheid en gegevenskwaliteit

16

2.4 Geactualiseerde doelstellingen

17

3

19

Het programma modernisering GBA, hoe verder?

3.1 Het programma modernisering tot nu toe

19

3.2 Keuzemogelijkheden in de ontwikkeling

22

3.3 Oplossingscomponenten

23

3.4 Relatie tussen de deelcomponenten en de doelstellingen

31

3.5 De drie scenario’s

31

3.6 De scope van het programma modernisering GBA

36

3.7 Mogelijke andere accenten in de scenario’s

40

3.8 Conclusie ten aanzien van scenario’s en scope

40

4

41

Het toekomstige GBA stelsel

4.1 De organisatie van het GBA stelsel in de toekomst

41

4.2 Diensten en services van de GBA

50

4.3 GBA-V en andere landelijke voorzieningen in het GBA-stelsel

53

4.4 De Burgerzakensystemen

60

4.5 Het berichtenverkeer en de bijbehorende diensten

67

4.6 Kwaliteitsbewaking (3.5)

71

4.7 Koppeling met de BAG

74

4.8 Relatie met de RNI

75

5

78

Architectuur

5.1 De GBA en de principes van de NORA

78

5.2 Uitgangspunten voor de architectuur van de GBA (5.1)

81

5.3 De GBA en de architectuur van gemeenten

82

5.4 Systeemschets van de toekomstige GBA (5.2)

86

iii

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

5.5 Koppelvlakken in het GBA stelsel (5.3)

87

5.6 De servicebus (5.4)

89

5.7 Technische Architectuur (5.5)

93

6

96

Gegevensmodel

6.1 Gronden voor het wijzigen van het gegevensmodel en de gegevensset

96

6.2 De belangrijkste wijzigingen (4.1)

97

6.3 De NORA-eisen mbt GBA-gegevens

98

6.4 Referentiemodel Stelsel van Gemeentelijke Basisgegevens (4.1.1)

101

6.5 Enkele voorbeelden

104

6.6 Afnemersindicatie

113

6.7 A-nummer/BSN

114

Bijlage A. Samenvatting eisen

115

Bijlage B. Referenties

122

Bijlage C.

Terminologielijst en glossary

125

Bijlage D.

Leden expertteam en begeleidingscommissie

130

Bijlage E. Drie scenario’s (formulering opdrachtverstrekking)

131

iv

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Lijst van figuren en tabellen
Figuur 1: Het NORA 9-vlaksmodel dat gehanteerd wordt voor de nummering van
de eisen. Zie voor verdere uitleg hoofdstuk 5.1 ....................................................9
Figuur 2: Context en betrokkenen bij het GBA-stelsel. Gemeenten houden
persoonsgegevens bij op basis van aangiften van burgers, afnemers gebruiken
de gegevens in processen met betrekking tot diezelfde burgers. .......................11
Figuur 3: De doelstellingen van de modernisering gebaseerd op het advies van
de commissie Snellen...........................................................................................13
Figuur 4: Gemeenten worden in een aantal tussenstappen in 2015 het loket
voor de gehele overheid ......................................................................................15
Figuur 5: De belangrijkste recente veranderingen zijn die bij de gemeenten en
de afnemers vanuit bredere e-overheidsontwikkeling en de afspraken m.b.t.
standaardisatie. ...................................................................................................17
Figuur 6. Geactualiseerde doelstellingen voor vervolg modernisering. Boven de
oorspronkelijke doelstellingen en de mate van realisatie, daaronder nieuwe
doelstellingen. .....................................................................................................18
Figuur 7: Een volledig decentraal stelsel; gemeenten zijn autonome partners. .19
Figuur 8: Uitbreiding van de weergave van ontwikkeling van het programma
modernisering GBA is de definitiestudie 1.3 met een overzicht van de
activiteiten die sindsdien hebben plaatsgevonden. ............................................20
Figuur 9: huidige situatie: een decentraal GBA stelsel met een landelijke kopie
gegevensverzameling (GBA-V) die daarop is aangesloten en waarvan een deel
van de afnemers gebruik maakt. .........................................................................21
Figuur 10: De belangrijkste al gerealiseerde verandering is het ontstaan van een
complete landelijke kopie van de gegevensset bovenop de bestaande
decentrale voorzieningen. ...................................................................................22
Figuur 11: Scheid berichtenstromen....................................................................24
Figuur 12: Scheiding tussen functionaliteit BZS-K en aanvullende modules. ......28
Figuur 13: De drie onderkende scenario’s ...........................................................32
Figuur 14: Uitwerking scenario 1 .........................................................................32
Figuur 15: Uitwerking scenario 2 .........................................................................34
Figuur 16: Uitwerking scenario 3 .........................................................................35
Figuur 17: Scope mGBA: weergave van de onderdelen die binnen de scope van
het programma zijn. ............................................................................................37
Figuur 18: Scope mGBA en relaties met andere projecten en systemen ............39
Figuur 19: De twee verantwoordelijkheden in het toekomstige GBA stelsel ......42
Figuur 20: Verandering van het oude decentraal GBA stelsel naar het
toekomstige stelsel met een landelijke GBA-V voor verstrekkingen. ..................43
Figuur 22. Globaal overzicht van de diensten en services van het GBA stelsel ...50

v

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Figuur 21: Weergave van de diensten die door het GBA-stelsel worden geleverd.
Deze figuur wordt gehanteerd als een vereenvoudiging van figuur 5 in de
oorspronkelijke definitiestudie. ...........................................................................50
Figuur 23: Het dienstenaanbod aan afnemers blijft in grote lijnen gelijk. ..........51
Figuur 24: Het GBA-stelsel weergegeven in de NORA overzichtsplaat waarin de
servicebus als ontkoppelvlak tussen de onderdelen is weergegeven. ................52
Figuur 25: Opdeling in intergemeentelijke en afnemers servicebus ...................53
Figuur 26: Verdere detaillering van de diensten voor landelijke voorzieningen .55
Figuur 27: Belangrijkste stappen in het proces van het doorgeven van een
gebeurtenis die bij gemeente wordt geregistreerd aan een afnemer ................56
Figuur 28: Uitdetaillering van de services van een burgerzakensysteem. ...........61
Figuur 29: Aanpassing ten opzichte van Figuur 28 voor de situatie met een BZS-K
en Aanvullende Modules. ....................................................................................66
Figuur 30: Het koppelvlak tussen BZS-K en de Aanvullende Modules wordt
gerealiseerd met behulp van een binnengemeentelijke servicebus. Afnemers
binnen de gemeenten sluiten op diezelfde bus aan om de GBA te benaderen
(naar figuur 2 in definitiestudie 1.3) ....................................................................67
Figuur 31: Kwaliteitsbewaking .............................................................................73
Figuur 32: De RNI als onderdeel van het GBA-stelsel met berichtenverkeer
tussen de RNI en de gemeenten. .........................................................................76
Figuur 33: het negenvlaksmodel van de NORA dat gebruikt is voor de indeling
van de in deze definitiestudie vastgestelde eisen voor het toekomstige GBA
stelsel. ..................................................................................................................79
Figuur 34: Plaats van het GBA-stelsel in de architectuur van de overheid ..........80
Figuur 35: Service Oriented Architectuur concept: processen worden
samengesteld op basis van services. ...................................................................81
Figuur 36: Huidige GBA inclusief GBA Verstrekkingen Online-1 ..........................83
Figuur 37: Informatie architectuur gemeenten conform GeMMA ......................85
Figuur 38: Overzicht van het nieuwe GBA-stelsel met alle mogelijke scenario’s 86
Figuur 39: Overzicht van de diensten die een zeer uitgebreide servicebus zou
bieden (Enterprise Service Bus) ...........................................................................91
Figuur 40: Referentie architectuur ......................................................................93
Figuur 41: Objectmodel RSGB11 ........................................................................102
Figuur 42: View op objectmodel Natuurlijke persoon RSGB .............................103
Figuur 43: Redundante gegevensopslag ............................................................107
Figuur 44: De oude en nieuwe PL-structuur ......................................................109
Figuur 45: LO3.x vs LO4 ......................................................................................113

vi

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Managementsamenvatting
Het programma modernisering GBA en de opdracht tot herijking
De Gemeentelijke Basis Administratie (GBA) is een essentieel onderdeel van de
overheid. Het programma modernisering GBA is in 2004 ingezet om de GBA
goed te integreren in het geheel van de e-overheid en de daartoe noodzakelijke
vernieuwingen door te voeren. De doelstellingen daarbij zijn:
• spil in de identiteitsinfrastructuur
• snelheid en toegankelijk verhogen
• flexibiliteit en goedkoper aan te passen
• betere gegevenskwaliteit en minder complexe bijhouding
• verhogen marktwerking
Een aantal onderdelen van dit programma zijn gerealiseerd. Op andere
onderdelen zijn forse tegenvallers opgetreden. Hieruit is de behoefte aan een
herijking ontstaan. Deze geactualiseerde definitiestudie is een van de
onderdelen van de herijking, naast een programmaplan, businesscase en
gatewayreview. Op basis van de herijking wordt besloten over de wijze waarop
het programma vervolgd zal worden.
De geactualiseerde definitiestudie geeft aan met welke recente veranderingen
in de omgeving van de GBA bij een vervolg rekening gehouden moet worden,
toetst de houdbaarheid van het oorspronkelijke concept en bekijkt verschillende
ontwikkelscenario’s.
Zijn oorspronkelijke doelstelling en scope nog helemaal adequaat?
De verwerking van de recente veranderingen in de omgeving leiden tot
conclusies die verder reiken dan de definitiestudie en worden hier eerst
behandeld. Het gaat daarbij om de vraag of de doelstellingen en scope van het
programma aangepast moeten worden bij een vervolgbeslissing. Vervolgens
wordt ingegaan op de meer technische vragen ten aanzien van de houdbaarheid
van het concept.
Twee veranderingen in de afgelopen jaren zijn belangrijk genoeg om expliciet
betrokken te worden in de vervolgbeslissing:
•

De visie op de verdere (elektronische) ontwikkeling van gemeenten en met
name het plaatsonafhankelijk werken, de mogelijkheid dat de burger
diensten in de gemeente die hij of zij op dat moment verkiest afhandelt,
ongeacht de woonplaats.

•

De afspraken over standaardisatie en samenhang binnen de e-overheid .

1

Het eerste levert een potentiële extra doelstelling op, namelijk de GBA in te
richten op plaatsonafhankelijk werken. De oorspronkelijke doelstellingen, met
name het verhogen van de snelheid tot “real time”, gaan al wel in de richting

1

Zie Nationaal Uitvoeringsprogramma (NUP) [1]

1

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

van plaatsonafhankelijk werken maar leiden slechts tot het realiseren van
randvoorwaarden voor plaatsonafhankelijk werken. Voor echt
plaatsonafhankelijk werken is een fundamentelere ingreep in het GBA-stelsel
nodig. Omdat het vervolg van de modernisering inmiddels noodgedwongen
enkele jaren verder vooruitkijkt dan initieel het geval was, kan nu de keuze
gemaakt worden om direct door te pakken naar het realiseren van
plaatsonafhankelijk werken. Het gaat daarmee niet enkel om
plaatsonafhankelijk kunnen leveren van enkele burgerzakendiensten maar om
de GBA een geïntegreerd onderdeel (“spil”) van de diensten van een
2
plaatsonafhankelijk werkende gemeente te laten zijn . De keuze voor deze extra
doelstelling heeft tot gevolg dat bijsturing van wijze van realiseren en
3
implementeren van BZS-K , de decentrale component die in oorspronkelijke
concept voor het GBA-stelsel voorzien is, nodig is.
De tweede belangrijke ontwikkeling, standaardisatie, heeft gevolgen voor de
wijze waarop het programma gerealiseerd wordt. De afspraken over
standaarden en samenhang vragen om een andere manier van veranderen. De
oorspronkelijke doelstellingen ten aanzien van flexibiliteit en marktwerking
wijzen al in die richting. Ook hier geldt echter dat de nu voorliggende
vervolgbeslissing een kans biedt om hier nadrukkelijker op te sturen. Juist
omdat het stelsel van basisregistraties en de afspraken over de e-overheid nu
veel verder vorm hebben gekregen, kan de kans aangegrepen worden om voor
het vervolg de expliciete doelstelling op te nemen dat het GBA-stelsel volledig
geïntegreerd wordt in de andere e-overheidsvoorzieningen. Uit de bijeekomsten
met het expertteam die als onderdeel van deze opdracht hebben
plaatsgevonden komt naar voren dat daaraan grote waarde wordt gehecht. De
keuze voor deze extra doelstelling betekent onder andere dat de Moderne
Interfaces die in het oorspronkelijke scenario voorzien zijn volledig gebruik
maken van de OverheidsServiceBus. Daarnaast betekent het dat de huidige
wijze van specificeren in het zogenoemde Logisch Ontwerp (LO), die zeer
specifiek is voor GBA, wordt vervangen door een op standaarden gebaseerde
beschrijving.
Hoe staat het met de houdbaarheid van het technische concept?
De technische houdbaarheid van het toekomstige GBA-stelsel zoals dat in de
oorspronkelijke definitiestudie is geschetst, is zonder meer in orde. Aan het
concept ligt een service geörienteerde architectuur ten grondslag die goed
aansluit op de inmiddels uitgekristalliseerde specificaties van de
OverheidsServiceBus. In het concept zijn duidelijke koppelvlakken vastgelegd.
Aan de zijde van de gemeente maakt dit koppelvlak een goede aansluiting op

2

Dit biedt goede kansen op synergie met de plannen van ministerie van Justitie op dit
gebied
3
Om compactheid en leesbaarheid van deze managementsamenvatting te bereiken wordt
er van uitgegaan dat de lezer de oplossingscomponenten van modernisering GBA: GBA-V,
Moderne interfaces, BZS-K en het LO4 gegevensmodel op hoofdlijnen kent. De beschrijving
hiervan is te vinden in paragraaf 3.3

2

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

toekomstige andere gemeentelijke ICT systemen mogelijk. Richting de afnemers
maakt dit koppelvlak het mogelijk met dezelfde soort processen en middelen
aangesloten te zijn op de GBA als op andere basisregistraties.
Het feit dat het programma GBA van begin af aan met open source
componenten heeft gerealiseerd betekent dat het nu gerealiseerde GBA-V
Online volledig aan de recente richtlijnen hieromtrent voldoet. Deze lijn kan
voortgezet worden, mits voor vervolg nadere aandacht wordt gegeven aan de
schaalbaarheid.
In lijn met de aanbevelingen uit eerdere rapporten is het in vervolg wel zeer
belangrijk om in de uitvoering te blijven sturen op het daadwerkelijk realiseren
conform dit (architectuur-) concept. Daartoe moet meer aandacht besteed
worden aan de traceerbaarheid van de doelstellingen op hoog niveau naar de
vele technische detailbeslissingen. De genummerde eisen uit de oorspronkelijke
definitiestudie die in deze versie geactualiseerd zijn bieden daartoe een goed
startpunt.
De ervaringen van de afgelopen jaren leiden wel tot kanttekeningen op niet
technisch gebied. Door het BZS-K als decentraal systeem bij iedere gemeente
afzonderlijk te implementeren gaat het GBA-stelsel qua verdeling van
verantwoordelijkheden afwijken van andere systemen waarbij sprake is van een
gedeelde gemeentelijke en rijkstaak zoals BAG en WKBP. Ten tweede is het
huidige BZS-K concept niet ontworpen met plaatsonafhankelijk werken en
samenwerken van gemeenten in shared service centra op het oog. Ten derde
heeft het verloop van het programma tot nu toe laten zien dat het niet
gemakkelijk is de realisatie en verplichte implementatie bij gemeenten
bestuurbaar te houden. De opgelopen vertraging biedt nu de kans om van de
nood een deugd te maken en een technisch als landelijke of
bovengemeentelijke voorziening uitgevoerde BZS-K als alternatief te kiezen. Het
programma mGBA levert deze component dan later dan oorspronkelijk gepland,
maar wel op een meer toekomstvaste basis en met minder risico’s voor beheer
en implementatie. Onder andere op basis van de expertteambijeenkomsten kan
geconcludeerd worden dat er draagvlak voor een BZS-K als landelijke
voorziening bestaat. Het verdient de aanbeveling de businesscase voor een
4
dergelijk alternatief door te rekenen .
De tweede kanttekening betreft het parallel aan GBA-V en BZS-K migreren naar
het LO4-gegevensmodel. De wijzigingen in het LO4 gegevensmodel zijn in de
ogen van de experts belangrijk, de benodigde migratie- en
conversievoorzieningen zijn echter ook complex. Omdat de andere
oplossingscomponenten ook allen al bijdragen aan de doelstellingen is het
moeilijk hard te maken of het LO4 gegevensmodel hier iets aan toevoegt dat op
korte termijn noodzakelijk is. Wat zeker is dat het tegelijk uitvoeren leidt tot een
onoverzichtelijk geheel.

4

Dit is inmiddels gebeurd in een aanvullende opdracht. Op basis van de beschikbare
gegevens is de businesscase positief.

3

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Voor de vervolgbeslissing kan gekozen worden dit te faseren. Eerst het GBAstelsel herstructureren en standaardiseren door GBA-V, moderne interfaces en
een vorm van een nieuw Burgerzakensysteem in te voeren en vervolgens in dit
vereenvoudigde GBA-stelsel de migratie naar het LO4 gegevensmodel laten
plaatsvinden. Dat levert extra kosten op omdat nieuwe onderdelen voorlopig
nog op het LO3 gegevensmodel moeten worden gerealiseerd en later
omgebouwd naar LO4. Voor GBA-V is dit echter al gebeurd en indien de
gelaagde architectuur volgens het technische concept wordt uitgevoerd zijn de
kosten van de latere ombouw relatief gering ten opzichte van de
complexiteitsreductie die het faseren oplevert.
Overigens zal het noodzakelijk zijn voor de andere oplossingscomponenten wel
beperktere wijzigingen aan het gegevensmodel en de gegevensset door te
voeren. Het vroegtijdig aan moderne standaarden aanpassen van de LO
procedure is daarom aan te bevelen. Het later invoeren van het LO4
gegevensmodel geeft tevens de ruimte meer tijd te steken in de toekomstige
berichtinhoud en de wijze van definiëren daarvan. De zogenoemde stuf 3.0
standaard dient hiervoor de basis te bieden.
De verschillende scenario’s voor het vervolg
Ter voorbereiding van de vervolgbeslissing zijn door het programma mGBA drie
scenario’s opgesteld. Onderdeel van de opdracht tot herijking is het bepalen van
de effecten van die scenario’s. De scenario’s bestaan allen uit
oplossingscomponenten uit het oorspronkelijke scenario. Deze zijn uitgewerkt
in paragraaf 3.3. Het betreft:
-

GBA-V Full Service: De afnemers vragen nu selecties op en ontvangen
spontane mutaties vanuit de decentrale systemen van de gemeenten via
het GBA-netwerk. GBA-V Full Service houdt in dat deze selecties en
mutaties voortaan vanuit één punt, namelijk het landelijke GBA-V aan de
afnemers worden geleverd. Dit scheidt het berichtenverkeer tussen
gemeenten onderling en GBA-V enerzijds van het berichtenverkeer naar
afnemers anderzijds.

-

Moderne Interfaces: Het bijhouden van de landelijke GBA-V kopie,
spontane mutaties naar afnemers en intergemeentelijk berichtenverkeer
zijn nu niet real time. Moderne interfaces betekent vervanging van het
GBA-netwerk door berichtenverkeer volgens de OSB specificaties en maakt
real time berichtenverkeer mogelijk. Hiertoe dienen de gemeentelijke
burgerzaken systemen te worden aangepast / herbouwd of vervangen door
een BZS-K en dient GBA-V te worden uitgebreid met een
berichtenmakelaar.

-

BZS-K: De implementatie van een BZS-K houdt in dat alle gemeenten een
centraal ontwikkelde uniforme kernapplicatie gaan toepassen voor het
opzoeken, wijzigen en opslaan, van persoonsgegevens t.b.v. burgers en
binnengemeentelijke afdelingen in dienstverlenende processen. Deze
wordt lokaal geïnstalleerd voor gebruik door de gemeenten. BZS-K omvat
alleen de basisfuncties en lokale gegevensopslag en vereist Aanvullende
Modules die de gebruikersinterface, workflow en verdere
burgerzakenfunctionaliteit omvatten en geheel onder verantwoordelijkheid
van de gemeenten door marktpartijen geleverd moeten worden. De huidige

4

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

burgerzakensystemen worden vervangen door een BZS-K met een of meer
Aanvullende Modules.
-

LO4 gegevensmodel: De gegevensmodelwijziging naar LO4 betekent een
forse herstructurering van de manier waarop persoonsgegevens worden
opgeslagen. Gegevens over gerelateerden (ouders, partners, kinderen, etc.)
worden beter gestructureerd en er wordt een onderscheid ingevoerd
tussen echte persoonsgegevens en het logboek waarin procesgegevens
over de bijhouding worden vastgelegd. Daarnaast wordt de gegevensset
opgeschoond en worden wijziging doorgevoerd die het mogelijk maken
vaker dan één keer per dag een mutatie door te voeren.

De samenstelling van de scenario’s uit deze oplossingscomponenten is als volgt
en is verder uitgewerkt in paragraaf 3.5:

De scenario’s hebben tot uitgebreide discussie met de begeleidingscommissie
en het expertteam geleid. De boven gesignaleerde nieuwe kansen en de
kanttekeningen bij het oorspronkelijke concept leiden tot de conclusie dat
enkele aanpassingen nodig zijn om de meest optimale scenario’s voor de
vervolgbeslissing in beeld te brengen. Dat neemt niet weg dat de
oorspronkelijke scenario’s een belangrijke bijdrage aan het proces hebben
geleverd! Alvorens deze aanpassingen uit te werken wordt de oorspronkelijke
scenario’s beoordeeld.
Het derde scenario valt af omdat het de nieuwe doelstellingen van
plaatsonafhankelijk werken en verdere standaardisatie niet dichterbij brengt,
omdat het slechts een beperkt deel van de oorspronkelijke doelstellingen
realiseert en omdat de risico’s van de migratie in dat scenario nog groter
worden geacht dan in scenario 2.
Het tweede scenario is het oorspronkelijke plan. De kanttekeningen bij het LO4
gegevensmodel en BZS-K raken met name dit scenario. Door het scenario aan te
passen in de richting van een technisch centraal BZS-K en het pas uitvoeren van
de migratie naar het LO4 gegevensmodel in een latere fase zou het
tegemoetkomen aan het bovenstaande.
Scenario 1 realiseert slechts een deel van de oorspronkelijke doelstellingen en
het is minder omvangrijk. Echter als scenario 2 wordt aangepast als boven
voorgesteld dan vervallen zelfs de beperkte verschillen tussen het eerste deel
van scenario 1 en 2 die in de oorspronkelijke scenario’s bestonden. Het
belangrijkste punt blijft het moment waarop moderne interfaces richting de
gemeenten worden gerealiseerd.
De huidige burgerzakenpakketten kunnen niet op basis van moderne interfaces
communiceren. Het is gewenst nader te bekijken wat de beste manier is om dat
op te lossen. Een mogelijkheid lijkt het ontwikkelen van een adapter die het
bestaande berichtenverkeer uit een burgerzakensysteem vertaalt in berichten
die via de OverheidsServiceBus getransporteerd kunnen worden. De
marktpartijen zouden deze adapter moeten inbouwen. Dit zou het versneld

5

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

uitfaseren van het GBA-netwerk mogelijk maken, iets dat op zich een potentiële
baat oplevert.
Het verschil tussen scenario 1 en 2 is dan gereduceerd tot de vraag wat de
vervolgstap moet zijn na scenario 1 en of dit onderdeel is van een en dezelfde
grote verandering of beter georganiseerd kan worden als een nieuw
programma. Voor de bestuurlijke keuze is de vraag daarbij dus of enkel naar de
korte termijn gekeken wordt of ook naar de middellange en langere termijn.
Er zijn goede argumenten om niet enkel naar de korte termijn te kijken. De
investeringsbeslissingen van gemeenten en afnemers hebben een langere
horizon, de bovengenoemde kansen op gebied van standaardisatie en het
integreren in de bredere ontwikkeling naar de e-overheid zijn zaken die verder
reiken dan de korte termijn.

Naar een optimaal vervolgscenario
Uitvoering van scenario 1 is op grond van de herijkte definitiestudie in ieder
geval een veilige stap. Deze stap zou in een zo hoog mogelijk tempo uitgevoerd
moeten worden en parallel zouden organisatorische maatregelen genomen
moeten worden die het verdere veranderproces vereenvoudigen, zoals een
standaardisatie van de LO procedure.
Ten aanzien van het verdere vervolg moet nadrukkelijk gekeken worden naar
het ambitieniveau en een keuze gemaakt worden tussen het versneld afronden
van de modernisering waarbij voor lief wordt genomen dat alleen de
belangrijkste doelstellingen zijn bereikt ofwel het op basis van aanvullende
doelstellingen bijsturen tot een moderniseringsprogramma dat de GBA voor
verdere toekomst inricht.

6

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

1 Inleiding
1.1

Opdracht

Ter voorbereiding van een beslissing over het vervolg van het programma
modernisering GBA heeft het programmabureau opdracht gegeven de
oorspronkelijke definitiestudie [9] te herijken en parallel daaraan de
businesscase te actualiseren, een programmaplan uit te werken en een
gatewayreview uit te voeren.

1.1.1
Aanleiding
Het ministerie van BZK staat voor de beslissing ten aanzien van de wijze waarop
het programma modernisering GBA wordt vervolgd. Een aantal onderdelen van
het oorspronkelijke programma zijn gerealiseerd. Op andere onderdelen zijn
forse tegenvallers opgetreden. De gemeenten hebben de afgelopen jaren een
verdere ontwikkeling doorgemaakt, evenals de andere basisregistraties en de
andere afnemers. Tenslotte zijn er ontwikkelingen in het bredere kader van de
e-overheid zoals het Nationaal Uitvoerings Programma [1] en de Nederlandse
Overheids Referentie Architectuur [2] en de verwachtingen ten aanzien van
open source software die ten tijde van de start van het programma nog niet zo
pregnant op de agenda stonden.

1.1.2
Doelstelling
De actualisering van de definitiestudie dient een basis te bieden voor een
onderbouwde beslissing over het vervolg. Relevante veranderingen sinds de
oorspronkelijke definitiestudie dienen benoemd te worden en de houdbaarheid
van het concept dient getoetst te worden. Ten tweede draagt een
geactualiseerde definitiestudie bij aan een goede communicatie met alle
betrokkenen over het vervolg en biedt het een basis om te traceren of de
doelstellingen daadwerkelijk gerealiseerd worden.

1.1.3
Reikwijdte
Naast de herijking van de definitiestudie worden nog drie parallelle opdrachten
uitgevoerd, deze leveren gezamenlijk het materiaal voor de vervolgbeslissing.
De afbakening van de definitiestudie is gebaseerd op de oorspronkelijke
definitiestudie en de punten die in het offertetraject benoemd zijn, vervolgens
is deze waar nodig tussentijds aangescherpt op basis van de opleveringen van
de fasen en de besprekingen met de begeleidingscommissie.
Als onderdeel van de opdracht zijn door de opdrachtgever drie scenario’s
geformuleerd voor het vervolg (zie Bijlage E). In de herijking is weergegeven
welke gevolgen ieder van de scenario’s heeft voor het bereiken van de
doelstellingen en hoe de scenario’s zich verhouden tot het oorspronkelijke
concept.
Tijdens de uitvoering van de opdracht is de behoefte gebleken aan het
uitwerken van enkele alternatieve scenario’s. Dit is gebeurd in paragraaf 3.7.

7

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

1.1.4
Aanpak
De actualisering volgt qua opzet waar mogelijk de bestaande definitiestudie. In
het gehele document is de terminologie geactualiseerd. Ten aanzien van de
reeds gerealiseerde onderdelen is de definitiestudie bijgewerkt. De opbouw is
aangepast om een goede basis te bieden voor de keuze tussen de drie in de
offerteaanvraag genoemde scenario’s.
In de aanpak zijn de genummerde eisen die in de oorspronkelijke definitiestudie
stonden benut. In twee bijeenkomsten met experts uit gemeenten, van BPR en
vanuit ICTU programma’s is een geannoteerde eisenlijst besproken. Daarnaast
zijn de aanpassingen gebaseerd op de documentatie uit het programma tot nu
toe en een aantal interviews.
De opdracht is uitgevoerd in nauwe samenwerking met het team dat aan de
businesscase gewerkt heeft, waarbij de onderzoeksresultaten over en weer
benut zijn en onderling consistent gemaakt. Naast de meetings met het
expertteam zijn de resultaten tussentijds besproken in de
begeleidingscommissie en is iedere fase afgesloten met een oplevering en
validatie van deeldocumenten door de opdrachtgever.

1.2

Leeswijzer

Deze herijkte definitiestudie valt uiteen in twee delen. Het eerste deel omvat de
managementsamenvatting, de context en doelstellingen van modernisering
GBA, de relevante ontwikkelingen in de omgeving daarvan en een uitwerking
van de scenario’s voor het vervolg van het programma. Het tweede deel
beschrijft het concept voor het moderne GBA en de eisen waaraan dat moet
voldoen. Dit tweede deel blijft tekstueel dicht bij de oorspronkelijke
definitiestudie uit 2005 (versie 1.3 [9]), met dien verstande dat puntsgewijs en
op basis van de recente ontwikkelingen en scenario’s die in het eerste deel
beschreven zijn een actualisering heeft plaatsgevonden. In dit deel zijn
nummers van paragrafen die deels zijn overgenomen uit versie 1.3 achter de
paragraaftitels gevoegd.
Een lijst van gehanteerde terminologie is opgenomen in Bijlage C. In deze lijst is
expliciet gemaakt welke begrippen op grond van o.a. de NORA anders
gedefinieerd zijn dan in de oorspronkelijke definitiestudie.
Tekst deze
paragraaf
identiek aan
businesscase

De definitiestudie is een zelfstandig leesbaar document. Enkele paragrafen
overlappen echter geheel met het businesscase rapport, dit is gemarkeerd zoals
hier in de marge.
In het tweede deel is uitgegaan van de genummerde eisen die ook in de
oorspronkelijke definitiestudie voorkwamen. Waar nodig zijn er nieuwe eisen
toegevoegd. Bij de eisen die overgenomen zijn uit de oorspronkelijke
definitiestudie is tussen haakjes het oude nummer opgenomen. In Bijlage A is
een overzicht van alle eisen opgenomen inclusief de veranderingen in de eisen
ten gevolge van de herijking.
De eisen zijn als hieronder zichtbaar gemaakt in de tekst.

ALG 1
(ALG 1)

De gemoderniseerde GBA dient te voldoen aan alle eisen die in dit document zijn
geformuleerd, niet alleen aan de eisen die expliciet zijn benoemd en genummerd

8

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Deze werkwijze op basis van expliciet geformuleerde eisen maakt het mogelijk
beslissingen en voortschrijdend inzicht vast te leggen en te traceren
ALG 2
(ALG 1)

Indien het bij de realisatie nodig blijkt om af te wijken van het programma van
eisen dient dit in de vorm van een wijzigingsvoorstel aan de opdrachtgever te
worden voorgelegd.

De nummering van de eisen volgt de door de NORA voorgeschreven indeling.
Deze wordt toegelicht in paragraaf 5.1. De betekenis is als volgt:
ORG

Organisatie

DST

Diensten en Producten

PRC

Processen

APP

Medewerkers en Applicaties

GEG

Berichten en Gegevens

UIT

Informatieuitwisseling

TEC

Technische Componenten en netwerk

SEC

Beveiliging (security)

BEH

Beheer

TRA

Transitie

Onderstaand figuur toont de bovengenoemde indeling in het NORA 9vlaksmodel:

Figuur 1: Het NORA 9-vlaksmodel dat gehanteerd wordt voor de nummering
van de eisen. Zie voor verdere uitleg hoofdstuk 5.1

9

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Dit document is verder als volgt opgezet:
Hoofdstuk 2 en 3:


Hoofdstuk 2 schetst de GBA in haar context, de oorspronkelijke
doelstellingen van de modernisering en recente invloeden daarop.



Hoofdstuk 3 beschrijft de huidige situatie en werkt de scenario’s voor
het vervolg uit.

Hoofdstuk 4-8: het nieuwe GBA-stelsel
•

•
•

Hoofdstuk 4 bevat een overzicht van de onderdelen van het
toekomstige GBA-stelsel en hun organisatorische inrichting, diensten
en functies.
Hoofdstuk 5 beschrijft de architectuur op hoofdlijnen, de belangrijkste
koppelvlakken van GBA-V met gemeenten en afnemers.
Hoofdstuk 6 beschrijft de principes die ten grondslag liggen aan het
nieuwe gegevensmodel van de GBA en beschrijft dit model op
hoofdlijnen.

Bijlagen:
•
•
•

•
•

Bijlage A: Een overzicht van alle eisen
Bijlage B: Een lijst met referenties
Bijlage C: Een lijst van begrippen en afkortingen. Allereerst de termen
die bij de herijking zijn gewijzigd en vervolgens een glossary van
overige terminologie.
Bijlage D. De leden van het expertteam en overige betrokkenen bij de
herijking
Bijlage E: De formulering van de drie scenario’s zoals deze bij de
opdrachtverstrekking is meegegeven. (BIJLAGE 1 bij brief
BPR2008/U56193)

Aanvullende bijlagen:
De volgende bijlagen betreffen meer technische aspecten. Bijlage I t/m IV zijn
één op één overgenomen vanuit de oorspronkelijke definitiestudie en los
bijgevoegd.
• Bijlage I: De binnengemeentelijke servicebus. Bevat een eerste
opsomming van de diensten (Bijlage E in oorspronkelijke
definitiestudie)
• Bijlage II: Een beschrijving van de implementatie van het nieuwe GBAgegevensmodel in PoC SpA. (Bijlage B in oorspronkelijke
definitiestudie)
• Bijlage III: Een voorbeeld van een deel van een PL, geconverteerd van
het oude naar het nieuwe datamodel. (Bijlage F in oorspronkelijke
definitiestudie)
• Bijlage IV. De platformkeuze (Bijlage G in oorspronkelijke
definitiestudie)
• Bijlage V: Een verkorte versie van het gegevensmodel en een nadere
detaillering van de wijzigingsvoorstellen. Bijlage V bevat tevens een
voorbeeld van een PL in het bestaande en het nieuwe model.

10

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

2 De omgeving van de gemeentelijke
basisadministratie
De GBA is een essentieel onderdeel van de overheid in haar relatie met burgers.
In dit hoofdstuk wordt deze context geschetst en geplaatst in het kader van de
ontwikkeling van de e-overheid. Vervolgens worden de veranderingen bij
gemeenten en afnemers besproken die de modernisering van de GBA
beïnvloeden. Tenslotte wordt gekeken in hoeverre de oorspronkelijke
doelstellingen van modernisering GBA nog actueel en volledig zijn.

2.1

Context van de GBA

De GBA is de basisregistratie van personen. Alle burgers in Nederland zijn in
beginsel in de GBA opgenomen. De GBA bevat de persoonsgegevens die nodig
zijn voor een effectieve uitvoering van overheidstaken. De betrokkenen bij de
GBA zijn: de burgers, de gemeenten en de afnemers. Het geheel aan
5
voorzieningen wordt aangeduid als het GBA-stelsel

Figuur 2: Context en betrokkenen bij het GBA-stelsel. Gemeenten houden
persoonsgegevens bij op basis van aangiften van burgers, afnemers gebruiken
de gegevens in processen met betrekking tot diezelfde burgers.
Enkele basiskeuzes bepalen de rollen van de betrokkenen . Het bijhouden van
de persoonsgegevens gebeurt dicht bij de burger door de gemeenten. De burger
is verplicht verhuizingen en andere gebeurtenissen bij de gemeente aan te
geven. Aan het loket van de gemeente wordt de identiteit van de burger
vastgesteld. Het verstrekken van persoonsgegevens aan overheden is gebaseerd
op het principe dat persoonsgegevens alleen verstrekt worden ten behoeve van
een taak waarvoor dat noodzakelijk is.

5

Het GBA stelsel dient niet verward te worden met het stelsel van basisregistraties. Het
GBA-stelsel is een onderdeel van het stelsel van basisregistraties, zie verder de
terminologielijst in Bijlage C.

11

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Daarmee bestaan twee belangrijke taken in het GBA-stelsel:
•
•

het bijhouden van de persoonsgegevens
het verstrekken aan afnemers als onderdeel van het stelsel van
basisregistraties.

2.1.1
Het programma modernisering GBA
In 2001 heeft de commissie Snellen [51] een heroriëntatie op het GBA-stelsel
voorgesteld. Op basis van de uitwerking daarvan is het programma
modernisering GBA gestart en inmiddels gedeeltelijk opgeleverd. Snellen noemt
de toegenomen mobiliteit, de grotere anonimiteit in de diverse vormen van
elektronisch communicatie, de schaalvergroting in de ICT en webtechnologie als
belangrijke invloeden die vragen om modernisering van de GBA. Ter
voorbereiding van beslissingen over het vervolg van het programma is het van
belang de ontwikkelingen die invloed hebben op de GBA opnieuw te
inventariseren.

Tekst deze
paragraaf
identiek aan
businesscase

2.1.2
De oorspronkelijke doelstellingen en hun realisatie
Op basis van Snellen zijn de volgende doelstellingen voor het programma
6
modernisering geformuleerd :
•
•
•
•
•

GBA als spil in de identiteitsinfrastructuur
Snelheid en toegankelijk verhogen: 24 x 7 online en sneller doorgeven
mutaties
Meer flexibiliteit en lagere kosten voor aanpassingen aan systeem
Betere gegevenskwaliteit en minder complexe bijhouding
Verhogen marktwerking ten aanzien van gemeentelijke ICT pakketten

De visie van Snellen op de GBA als spil in de identiteitsinfrastructuur is in feite
een vooruitblik op het stelsel van basisregistraties dat nu gerealiseerd wordt.
Het verhogen van de snelheid en toegankelijkheid omvat twee aspecten:
• afnemers kunnen de GBA 24 x 7 uur online bevragen en krijgen meteen
antwoord
• afnemers, zowel buitengemeentelijk als binnen de gemeente krijgen
wijzigingen in de GBA gegevens direct, zonder de huidige
tijdsvertraging van minstens 24 uur.
De inmiddels gerealiseerde landelijke GBA-V Online realiseert het eerste aspect
maar niet het tweede.

6

In de wandeling worden dit de “Snellen” doelstellingen genoemd, echter de kabinetsreactie
en verdere uitwerking van deze doelstellingen bevat nadere keuzes. Deze nadere keuzes
die ook uitgangspunt van de oorspronkelijke definitiestudie waren (hoofdstuk 2 aldaar), zijn
hier als uitgangspunt genomen.

12

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

De drie andere doelstellingen, flexibiliteit, gegevenskwaliteit en marktwerking
hangen met name samen met de pakketten die de gemeenten benutten als
burgerzakensysteem. Deze doelstellingen zijn in de latere uitwerking van het
programma modernisering GBA gekoppeld aan de invoering van een uniform
burgerzakensysteem kern (BZS-K, zie paragraaf 3.3.5) bij alle gemeenten. De
ontwikkeling van het BZS-K is medio 2007 stopgezet en heeft dus nog niet
bijgedragen aan de doelstellingen. Andere maatregelen vanuit het separate
programma GBA als basisregistratie en het actieplan kwaliteit GBA hebben wel
bijgedragen aan deze doelstellingen.

Figuur 3: De doelstellingen van de modernisering gebaseerd op het advies van
de commissie Snellen

2.1.3
E-overheid vereist een gemoderniseerde GBA
De modernisering van de GBA is van begin af aan een element van de bredere
realisatie van de e-overheid. Dat is logisch gezien het grote deel van de
overheidstaken waarin eenduidigheid van persoonsgegevens belangrijk is,
zowel voor adequate dienstverlening als voor handhaving en veiligheid
bijvoorbeeld. Een gemoderniseerd GBA-stelsel is een essentieel onderdeel van
het stelsel van basisregistraties. Dit raakt alle afnemers maar nadrukkelijk ook
de gemeenten. Binnengemeentelijk gebruik van de GBA als basisregistratie is
daarom een prioriteit. Op 1 januari 2010 moet dit een feit zijn. Momenteel
voldoen slechts vier gemeentes volledig aan deze verplichting.
Het Nationaal Uitvoerings Programma (NUP, [1]) bakent een basisinfrastructuur
voor de e-overheid af. Het rijk, de gemeenten, provincies en waterschappen
hebben hierin afspraken gemaakt over het gebruiken, beheren, aansluiten,
implementeren, financieren en ontwikkelen van deze basisinfrastructuur.
Het NUP bevestigt het belang van de GBA voor de e-overheid. De GBA is een
onderdeel van de basisinfrastructuur en dus voorwaardenstellend voor andere

13

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

ontwikkelingen. Het NUP noemt allereerst de doelstelling dat de GBA door alle
organisaties die wettelijke taken uitvoeren waarbij persoonsgegevens nodig zijn,
als basisregistratie wordt gebruikt, dat door al deze organisaties wordt
teruggemeld en dat zij hun organisatie inrichten op het slechts eenmalig
bevragen van burgers. Het NUP trekt hieruit de consequentie dat al deze
overheden per 1 januari 2010 aangesloten moeten zijn op de landelijke
voorziening voor afnemers, GBA-V (GBA-Verstrekkingen).
Ten tweede gaat het NUP uit van gezamenlijk gebruik van de kerninfrastructuur
door alle overheden. Voor berichtenverkeer sluiten alle overheden zich aan op
de OverheidsServiceBus (OSB) en ten behoeve van standaardisering dient bij
verdere modernisering van de GBA waar mogelijk en waar relevant de
Nederlandse Overheids Architectuur (NORA, [14][2]) te worden toegepast.
Ten derde worden in het NUP een aantal andere onderdelen van de
kerninfrastructuur en voorbeeldprojecten genoemd die de GBA nodig hebben:
•
•
•
•

RNI (zie paragraaf 4.8)
BSN
DigiD
Mijnoverheid.nl

Tenslotte bevat het NUP afspraken over verdeling van kosten van ontwikkeling
en beheer die gehanteerd zullen worden bij verdere modernisering van de GBA.
Het NUP ziet de GBA dus als een wezenlijk onderdeel van de kerninfrastructuur
van de overheid en noemt expliciete deadlines voor het aansluiten op GBA-V.
Voor het programma modernisering is minstens zo belangrijk dat de afspraken
over standaarden en samenhang in het NUP vragen om een andere manier van
veranderen. De oorspronkelijke doelstellingen ten aanzien van flexibiliteit en
marktwerking wijzen al in die richting. Juist omdat het stelsel van
basisregistraties en de afspraken over de e-overheid nu veel verder vorm
hebben gekregen, kan de kans aangegrepen worden om voor het vervolg de
expliciete doelstelling op te nemen dat het GBA-stelsel volledig geïntegreerd
wordt in de andere e-overheidsvoorzieningen. Dat vereist een nadrukkelijke
sturing op maximaal gebruik van de in het NUP genoemde standaarden, met
name rond de OverheidsServiceBus. Daarnaast betekent het dat de huidige
wijze van specificeren in het Logisch Ontwerp (LO), die zeer specifiek is voor
GBA, wordt vervangen door een op standaarden gebaseerde beschrijving die
aansluit bij de NORA en de gegevensmodelbeschrijvingen van de andere
basisregistraties.

2.2

Veranderingen bij gemeenten stellen nieuwe eisen aan GBA

Mede als gevolg van de e-overheidsontwikkeling veranderen gemeenten en
afnemers in snel tempo. Deze veranderingen hebben invloed op de
modernisering GBA. In de volgende paragrafen worden de belangrijkste
veranderingen beschreven.
De gemeenten zijn druk bezig ieder een elektronische gemeente te realiseren
[4]. Meer recent hebben de gemeente de toekomstvisie ontwikkeld om een
breed klant contact centrum te worden namens de gehele overheid op basis van
het Antwoord© concept. Dit maakt de gemeente een integraal onderdeel van

14

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

de e-overheid: een andere benadering van dienstverlening aan de burger en een
andere manier van werken.

Figuur 4: Gemeenten worden in een aantal tussenstappen in 2015 het loket
voor de gehele overheid

Is Bert Burger in 2015 tevreden over
de GBA
In de brochure Antwoord© worden
enkele voorbeelden geschetst van Bert
Burger die in 2015 tevreden is over de
samenhangende dienstverlening van
de gemeente. Uit de voorbeelden blijkt
dat Bert in de tussentijd verhuist en
scheidt van zijn vrouw. Dat zijn twee
gebeurtenissen in het leven van Bert
waarvoor hij verplicht is aangifte te
doen bij de Burgelijke Stand. Deze
gebeurtenissen leiden tot een
bijhouding van de gemeente in de
GBA. Hoe zou Bert reageren als in een
van de voorbeelden van de mooie
internetdienstverlening van de
samenwerkende overheden op zijn
scherm blijkt te staan dat hij nog niet
gescheiden is van zijn vrouw of als de
post van de Belastingdienst na zijn
verhuizing toch nog op zijn oude adres
bij zijn ex komt? Snelheid van het
doorgeven van wijzigingen en kwaliteit
van de GBA gegevens spelen een grote
rol bij het voor elkaar krijgen daarvan!

Ten tijde van het rapport Snellen liep de GBA voor op deze ontwikkeling. Door
het stopzetten van het BZS-K traject is dit inmiddels niet meer het geval. Omdat
de andere ontwikkelingen hard gaan, zijn noodverbanden gelegd en moet “om
het huidige verouderde burgerzakensysteem heen” georganiseerd worden. Een
duidelijke vervolgbeslissing over modernisering GBA is noodzakelijk om voor de
gemeenten inzichtelijk te maken met welke ontwikkelingen ze rekening moeten
houden en hen in staat te stellen hun investerings- en inrichtingsbeslissingen
daarop af te stemmen.
Voor het realiseren van deze doelstellingen en visie is het op orde hebben van
de basisinformatie en het op elkaar aansluiten van de ICT-systemen een
belangrijke voorwaarde. De eisen die de doelstellingen van gemeenten aan de
ICT stellen leiden er daarnaast toe dat gemeenten vaker gezamenlijk met
andere gemeenten hun ICT vanuit een shared service centrum wensen uit te
voeren.

2.2.1

Plaatsonafhankelijk werken vraagt om stap verder dan puur
decentraal GBA
De ontwikkeling naar de gemeente als poort van de gehele overheid betekent
niet dat de gemeente enkel de poort is voor de burgers die binnen haar grenzen
wonen. Het is de bedoeling dat gemeenten, met name voor een aantal
basisdiensten, dezelfde diensten kunnen verlenen aan burgers die in andere
gemeenten wonen als aan de eigen burgers: plaatsonafhankelijk werken. Net
zoals de burger op internet gewend is geraakt aan plaatsonafhankelijk werken
verwacht de burger dat aan het loket van de gemeente. Het kan ook betekenen
dat de dienstverlening in een logische samenwerking met andere organisaties
plaatsvindt zoals het geboorteloket in ziekenhuizen of verhuisberichten via de
woningbouwvereniging. Plaatsonafhankelijk werken levert bovendien een
duidelijke bijdrage aan de administratieve lastenverlichting van burgers.

15

Definitiestudie mGBA Versie 1.8

2.3

De moderne GBA mogelijk gemaakt…

Wensen afnemers zijn ongewijzigd: snelheid en gegevenskwaliteit

Eenmalige gegevensverstrekking door de burger en meervoudig gebruik binnen
de overheid is de drijvende verandering bij de afnemers. De invoering van het
BurgerServiceNummer en het uitbouwen van het stelsel van basisregistraties
zijn een volgende stap naar een samenhangende gegevenshuishouding die
verder reikt dan één sector. Uitgangspunt voor de basisregistraties is dat
afnemers kunnen vertrouwen op de kwaliteit en actualiteit van de gegevens.
Afnemers mogen niet steeds opnieuw aan de burger vragen of de gegevens nog
juist zijn. Kennis over mogelijke onjuistheden in de basisregistratie wordt via het
systeem van terugmelden doorgeleid naar de bronhouder van de registratie.
Deze doet onderzoek en corrigeert indien nodig de registratie. De consequentie
hiervan is dat afnemers meer dan in het verleden afhankelijk zijn van de
gegevenskwaliteit in de GBA, behoefte hebben aan snelle doorlevering van
wijzigingen en snel uitvoeren van het onderzoek bij terugmelding door de
gemeente die bronhouder is.
De tweede relevante verandering is het verplaatsen van dienstverlening naar
internet. In veel van de vooringevulde formulieren en persoonlijke pagina’s
spelen persoonsgegevens een prominente rol. Nadat de burger zich identificeert
met DigiD worden zijn naam en adres getoond. Deze komen uit de GBA. Dit
maakt de kwaliteit van deze gegevens en de snelheid van het via het GBA stelsel
doorgeven van wijzigingen in de situatie van de burger belangrijker. Als het niet
meteen klopt, ervaart de burger dat veel sneller dan vroeger. Een brief die
verkeerd geadresseerd is, komt veelal bij de verzendende overheidsinstantie
terug, zonder dat de burger het merkt. Via internet wordt straks echter direct
zichtbaar dat de overheid een adreswijziging nog niet verwerkt heeft!
Voor het GBA-stelsel betekent dit dat een puur decentraal stelsel te beperkend
is geworden. Vanaf 1 februari 2004 is daarom de landelijke LRD in gebruik
7
genomen . Inmiddels is deze opgevolgd door de GBA-V die een volledige
landelijke kopie van alle persoonsgegevens in de gemeentelijke GBA’s omvat.
Dit is een belangrijk resultaat van de modernisering GBA. GBA-V stelt afnemers
in staat om sneller actuelere gegevens te gebruiken in hun processen en
dienstverlening.
Momenteel maken afnemers in toenemende mate in de front office gebruik van
GBA-V online. Door al aan het loket de persoonsgegevens uit GBA-V online op te
halen worden kosten voorkomen als verderop in het proces blijkt dat de
gegevens niet actueel zijn of gewacht moet worden (tot 2 x 24 uur) op het
bijwerken van GBA gegevens in een sectorale of eigen registratie. Op langere
termijn voorzien de afnemers echter een echte procesverandering waarbij GBA
gegevens steeds minder in een eigen of sectorale kopie worden bewaard en
steeds vaker de benodigde gegevens online en real time uit de GBA worden
opgehaald. Voor deze ontwikkeling is een verdere doorontwikkeling van GBA-V

7

De LRD is met versie LO3.2 van kracht geworden. In LO3.2 is bjilage B opgenomen die
gaat over de LRD. LO3.2 is in werking getreden op 1 februari 2004.

16

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

naar een volledig real time bijgehouden GBA kopie noodzakelijk. Met “real
time” wordt bedoeld dat het berichtenverkeer zo snel gaat dat een
lokethandeling die berichtenverkeer vereist zonder extra wachttijd doorgang
kan vinden.
Bestaande GBA afnemers hebben allerlei organisatorische maatregelen
genomen om op basis van het huidige GBA stelsel hun taken goed uit te voeren.
De baten van betere gegevenskwaliteit aan de bron en snellere verstrekking van
wijzigingen treden bij die afnemers minder snel en zichtbaar op dan bij nieuwe
afnemers. Diverse e-overheidsprogramma’s leiden tot nieuwe GBA afnemers die
vanaf de eerste dag online en dus zichtbaar voor de burger zijn. In het NUP zijn
dit bijvoorbeeld: mijnoverheid.nl, digitaal klantdossier, verwijsindex
risicojongeren en de omgevingsvergunning.

2.4

Geactualiseerde doelstellingen

In het voorgaande zijn de oorspronkelijke doelstellingen van de modernisering
GBA beschreven, is de GBA geplaatst in het bredere kader van de eoverheidsontwikkeling en de afspraken over standaardisatie die daarvoor van
belang zijn en zijn de belangrijkste recentere veranderingen besproken.

Figuur 5: De belangrijkste recente veranderingen zijn die bij de gemeenten en
de afnemers vanuit bredere e-overheidsontwikkeling en de afspraken m.b.t.
standaardisatie.
Tijdens het verloop van de modernisering GBA heeft het stelsel van
basisregistraties vorm gekregen en met de ontwikkeling van GBA-V Online is een
stap in de richting van het realiseren van de doelstellingen gezet. Ten aanzien
van de afnemers zijn er geen nieuwe ontwikkelingen die de modernisering
beïnvloeden. Uit de bovenbeschreven veranderingen bij gemeenten zijn echter
wel nieuwe doelstellingen af te leiden waarmee in een vervolgbeslissing over
modernisering GBA rekening moet worden gehouden:
•
•

Plaatsonafhankelijk werken door gemeenten
De eis om te kunnen werken met shared service centra

Uit de bredere e-overheidscontext volgt verder de noodzaak om de beslissingen
ten aanzien van standaarden, bijvoorbeeld rond NORA en OSB, te

17

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

implementeren. Dit wordt in het vervolg van deze definitiestudie verder
uitgewerkt.
2.4.1
Conclusie: enige bijstelling van de doelstellingen is gewenst
De oorspronkelijke doelstellingen gebaseerd op Snellen zijn deels gerealiseerd.
Het programma modernisering GBA heeft daaraan met name bijgedragen door
het realiseren van GBA-V Online en de TMV. Parallel hebben andere
ontwikkelingen in dezelfde lijn plaatsgevonden, grotendeels meer
organisatorisch van aard, waarmee een ander deel van de doelstellingen
gerealiseerd is, zij het met andere middelen.
Belangrijke andere doelstellingen zijn echter nog niet gerealiseerd. Naast het
wegnemen van tijdsvertragingen in het doorgeven van mutaties betreft dit de
doelstellingen die gerelateerd zijn aan de GBA systemen in de gemeenten. Dit
maakt het des te belangrijker om een vervolgbeslissing te nemen die aansluit op
de bredere ontwikkeling die de gemeenten doormaken en de ICT consequenties
die dat heeft.
Conform de afspraken in het NUP dient daarnaast het expliciet aansluiten bij de
e-overheidsstandaarden als doelstelling te worden meegenomen.
De overige recente veranderingen hebben geen invloed op de doelstellingen
maar wel op de wijze waarop deze bereikt moeten worden.

Figuur 6. Geactualiseerde doelstellingen voor vervolg modernisering. Boven de
oorspronkelijke doelstellingen en de mate van realisatie, daaronder nieuwe
doelstellingen.

18

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

3 Het programma modernisering
GBA, hoe verder?
Dit hoofdstuk schetst de situatie voorafgaand aan de modernisering, de huidige
situatie en de scenario’s voor het vervolg. Deze scenario’s bestaan uit
verschillende combinaties van oplossingscomponenten. Voorafgaand aan de
scenariobeschrijving worden deze componenten afgebakend. Bij de scenario’s
wordt ingegaan op de relatie tussen de oplossingscomponenten en de
doelstellingen. De gevolgen van de verschillende scenario’s worden in het
vervolg van de definitiestudie weergegeven. Naast de scenario’s die als
onderdeel van de opdracht zijn geformuleerd, worden nog enige andere
overwegingen voor de vervolgbeslissing uitgewerkt. De afbakening van de
componenten en de scenario’s zijn identiek gehanteerd in de businesscase [10].

3.1

Het programma modernisering tot nu toe

3.1.1
De situatie voorafgaand aan modernisering GBA
Het oorspronkelijke in 1994 in gebruik genomen GBA stelsel was een decentraal
stelsel. Net als nu en in de toekomst was iedere gemeente verantwoordelijk
voor de bijhouding van de persoonsgegevens van de burgers binnen de
gemeentegrenzen. Daarnaast voerden de gemeenten ook alle
gegevensverstrekkingen aan afnemers uit. Afnemers hadden, en hebben deels
nog steeds, te maken met de ruim 400 gemeenten die ieder een deel van de
levering aan hen verzorgen.

Figuur 7: Een volledig decentraal stelsel; gemeenten zijn autonome partners.

19

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Bovenstaand figuur toont een volledig decentraal stelsel waarin alle gemeenten
autonome partners zijn. Iedere gemeente communiceert met iedere andere
gemeente en afnemers ontvangen in het algemeen van meerdere of alle
gemeenten gegevensverstrekkingen.

3.1.2
De aanpak van het programma
Na diverse nadere studies waarin de ideeën van de commissie Snellen zijn
uitgewerkt is het programma in 2005 ambitieus aan de realisatie begonnen.
Consequentie van het gekozen ontwikkelscenario was dat daarbij diverse
parallelle projecten moesten worden uitgevoerd.

Figuur 8: Uitbreiding van de weergave van ontwikkeling van het programma
modernisering GBA is de definitiestudie 1.3 met een overzicht van de
activiteiten die sindsdien hebben plaatsgevonden.
Het programma modernisering GBA heeft de volgende zaken opgeleverd [6]:
•
•
•
•

GBA-V Online zoals dat momenteel in productie is
Een eigen terugmeldvoorziening voor GBA, de TMV (zie 4.6.1)
Volledig uitgewerkt ontwerp en detailplanning voor GBA-V Full Service
Uitwerkingen in verschillende stadia voor de andere onderdelen van
het oorspronkelijke plan, in het bijzonder BZS-K

3.1.3
Huidige situatie: eerste stap naar modernisering gezet
Ten opzichte van het oorspronkelijke puur decentrale stelsel is de huidige
situatie een mix van decentraal en centraal. Het oorspronkelijke decentrale

20

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

stelsel is nog vrijwel geheel in gebruik maar daarnaast is een landelijke
gegevensverzameling met de kopie persoonslijsten van alle gemeenten
ontstaan, de GBA-V. Een deel van de afnemers maakt gebruik van dit landelijke
GBA-V en is dus niet meer op het decentrale stelsel aangesloten. Een deel van
8
de afnemers is aangesloten op beide vormen van verstrekking zowel de oude
als de nieuwe.

Figuur 9: huidige situatie: een decentraal GBA stelsel met een landelijke kopie
gegevensverzameling (GBA-V) die daarop is aangesloten en waarvan een deel
van de afnemers gebruik maakt.
Een deel van de gemeenten maakt ook zelf voor binnengemeentelijke afname
9
gebruik van GBA-V online .

8
9

61 afnemers zijn aangesloten op beide vormen van verstrekking (5-11-2008)
Er zijn thans (5-11-2008) 229 GABA’s die GBA-V via web services bevragen.

21

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Figuur 10: De belangrijkste al gerealiseerde verandering is het ontstaan van
een complete landelijke kopie van de gegevensset bovenop de bestaande
decentrale voorzieningen.

3.2

Keuzemogelijkheden in de ontwikkeling

Ten behoeve van de vervolgbeslissing, actualisatie van de definitiestudie en
doorrekening van de businesscase zijn door het programma drie scenario’s
opgesteld voor een vervolg. Deze scenario’s zijn gebaseerd op eerdere
discussies over alternatieven in de loop van het programma. Om alternatieven
goed af te wegen wordt hier eerst de meer theoretische vraag gesteld op welke
aspecten variatie in de ontwikkeling mogelijk is, vervolgens worden de drie
scenario’s die momenteel voorliggen beschreven en tenslotte wordt ingegaan
op andere variaties.
De aspecten waarin keuzes gemaakt moeten worden en die het migratiepad het
meest beïnvloeden zijn:
• De wijze waarop de verandering bestuurd wordt
• De mate waarin wordt ingegrepen op de situatie binnen de gemeente
• De mate waarin functionaliteit in technische zin centraal geleverd
wordt
• De moeite die gedaan wordt om gemeenten onderling en afnemers het
moment van migratie vrij te laten bepalen
• De mate waarin stappen parallel dan wel volgtijdelijk genomen
worden.
• De mate waarin de oorspronkelijke scope gehandhaafd blijft
De wijze waarop de verandering bestuurd wordt is een aspect dat niet in de
definitiestudie thuishoort maar eerder in het programmaplan. Dat neemt niet
weg dat verschillende scenario’s verschillende eisen aan de besturing stellen.
Met name de mate waarin actieve en tijdgebonden stappen van de gemeenten
en afnemers bepalend zijn voor het succes heeft invloed op de besturing. Ten
tweede heeft de complexiteit van de gekozen migratie effect op de interne
besturing van het programma. Hoe complexer de migratie, hoe meer interne
afhankelijkheden waarop zowel in technische als in bestuurlijke zin consequent
gestuurd moet worden. Dit vereist een zeer directe business – ICT alignment en
is in het algemeen moeilijk te realiseren [5].

22

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Omdat de gemeenten een essentiële taak vervullen in het GBA stelsel terwijl
tegelijk het stelsel als geheel moet functioneren is het noodzakelijk eisen te
stellen aan de wijze waarop de gemeente de GBA taak inricht. Dit is vanaf het
begin van de GBA het geval (LO-procedure). De mogelijke scenario’s verschillen
in de wijze waarop deze eisen in de toekomst tot stand komen. Dit heeft grote
impact op het migratiepad. Omdat de GBA niet los te zien is van de overige
onderdelen van de e-overheid moet deze keuze onderdeel zijn van een
totaalvisie op de wijze waarop proces en ICT van e-overheid bij de gemeenten
ingevoerd wordt.
De mate waarin functionaliteit in technische zin centraal geleverd wordt, is sterk
bepaald door de technische mogelijkheden. Deze zijn sinds het begin van het
moderniseringsprogramma gegroeid. Dat betekent dat er momenteel meer
mogelijkheden zijn om functionaliteit voor gemeenten in technische zin centraal
te leveren zonder nadelen voor de gemeente. Centraal leveren staat daarbij
geheel los van de vraag of er een individueel GBA per gemeente blijft bestaan:
bijvoorbeeld een in technische zin centraal systeem met voor iedere gemeente
een afgescheiden BZS-K en los daarvan een GBA-V is technisch gesproken goed
mogelijk.
In het oorspronkelijke migratiescenario is het volledig onafhankelijk van elkaar
kunnen migreren van gemeenten en het onafhankelijk van alle gemeenten
kunnen overgaan van afnemers een uitgangspunt. Dit leidt tot de noodzaak vrij
omvangrijke conversievoorzieningen gedurende de migratie in stand te houden.
De kosten van dergelijke voorzieningen moeten afgewogen worden tegen de
baten van de onderlinge onafhankelijkheid van de grote groep betrokkenen in
het GBA-stelsel en de risico’s van alle complexe conversievoorzieningen.
De mate waarin stappen parallel of volgtijdelijk genomen worden hangt
gedeeltelijk samen met de migratie. In een complexe migratie is het
noodzakelijk bepaalde stappen parallel te nemen. De totale duur van de
verandering wordt korter naar mate er meer parallel gebeurt, het risico van een
bewegend doel wordt dan ook kleiner, maar de besturing van meerdere
parallelle projecten, zeker wanneer daarbij verschillende belanghebbenden
betrokken zijn, is niet eenvoudig.

3.3

Oplossingscomponenten

Het programma modernisering GBA omvat meerdere deelprojecten die ieder
een oplossingscomponent moeten realiseren. De drie scenario’s voor het
vervolg zijn gebaseerd op verschillende combinaties van deze
oplossingscomponenten en worden in de volgende paragraaf uitgewerkt.
Hieronder wordt allereerst een afbakening van de componenten gegeven. De
oplossingscomponenten zijn niet volledig onafhankelijk van elkaar, in de globale
beschrijving is daarvan geabstraheerd, bij de beschrijving van de
deelcomponenten (steeds de tweede paragraaf) is dit expliciet aangegeven.

23

Definitiestudie mGBA Versie 1.8

Tekst deze
paragraaf
identiek aan
businesscase [10]

De moderne GBA mogelijk gemaakt…

3.3.1
GBA Full-service
De afnemers vragen nu selecties op en ontvangen spontane mutaties vanuit de
decentrale systemen van de gemeenten via het GBA-netwerk. GBA-V Full
Service houdt in dat deze selecties en mutaties voortaan vanuit één punt,
namelijk het landelijke GBA-V aan de afnemers worden geleverd. Dit scheidt
het berichtenverkeer tussen gemeenten onderling en GBA-V enerzijds van het
berichtenverkeer naar afnemers anderzijds

Bij het implementeren van GBA-V Full Service zal de verantwoordelijkheid voor
het systematisch verstrekken van gegevens verschuiven van de gemeenten
naar het agentschap BPR. De gemeenten blijven enkel verantwoordelijk voor de
verstrekking van mutatiemeldingen aan GBA-V en hun eigen
binnengemeentelijke verstrekkingen. De gemeenten blijven echter bronhouder
in de zin van de Basisregistraties en zullen daarmee verantwoordelijk blijven
voor het beheer van de data in de GBA als basisregistratie. Mutaties in het GBA
blijven door gemeenten worden gedaan; BPR neemt de rol van het leveren van
verstrekkingen over.

Figuur 11: Scheid berichtenstromen
Meer in detail leidt Full Service tot de volgende veranderingen [30]:
•

•
•
•

•
•

Afnemers communiceren enkel nog met BPR over verstrekkingen, BPR richt
daartoe een serviceorganisatie in waarin het van gemeenten overgenomen
werk terecht komt
Selecties over meerdere gemeenten heen kunnen als één geheel worden
geleverd
Gemeenten hoeven geen selecties meer te doen
Afnemersindicaties verplaatsen van gemeenten naar GBA-V, het
berichtenverkeer voor plaatsen en verwijderen van afnemersindicaties bij
gemeenten vervalt
Enkele wensen van afnemers kunnen worden gerealiseerd
Beheerfunctionaliteit bij BPR voor de landelijke componenten wordt sterk
uitgebreid

24

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

De levering aan afnemers vindt plaats conform het bestaande berichtenverkeer
over het GBA-netwerk of via Alternatief-Medium (AM). De afbakening van Full
Service is gebaseerd op de uitwerking in de inceptionfase ‘GBA-V R5’ [31] die op
16 juni 2008 is opgeleverd.

3.3.2
Deelcomponenten van GBA-V Full Service
Om de bovengenoemde veranderingen te bereiken moeten de volgende
onderdelen gerealiseerd worden, deze onderdelen worden in de paragrafen
4.1.2 en 4.3 verder uitgewerkt.
•

•
•
•
•
•

•

Tekst deze
paragraaf
identiek aan
businesscase

LO3 services: het realiseren van services die de LO3-berichten produceren
voor spontane mutaties en selecties, de functionaliteit voor ontvangen van
berichten van afnemers inzake afnemersindicaties etc. Verder de
selectiefunctionaliteit op GBA-V en het leveren op Alternatief Medium en
een nieuwe vorm van levering middels upload en tenslotte het aanpassen
van GBA-V Online (LO3 Ad hoc service) aan de OSB specificaties
Realiseren van afnemersindicaties op GBA-V (i.p.v. bij gemeenten)
10
Het specificeren van de berichtinhouden (al in LO3.6 verwerkt)
11
Verzorgingsgebieden
Uitbreiden beheerfunctionaliteit BPR
Aanpassingen aan Schouwing en Toetsing en wijze van testen
berichtenverkeer (kan gezien worden als aspect van de
beheerfunctionaliteit)
Aanpassingen aan Mailboxen GBA-netwerk om de andere patronen van
berichtenverkeer mogelijk te maken

3.3.3

Moderne interfaces

Het bijhouden van de landelijke GBA-V kopie, spontane mutaties naar
afnemers en intergemeentelijk berichtenverkeer zijn nu niet real time.
Moderne interfaces betekent vervanging van het GBA-netwerk door
berichtenverkeer volgens de OSB specificaties en maakt real time
berichtenverkeer mogelijk. Hiertoe dienen de gemeentelijke burgerzaken
systemen te worden aangepast / herbouwd of vervangen door een BZS-K en
dient GBA-V te worden uitgebreid met een berichtenmakelaar.

In de huidige situatie is sprake van een vertraging van ten minste 24 uur in de
verstrekking van GBA gegevens en het doorgeven van spontane mutaties. Dit
kan tot gevolg hebben dat een afnemer GBA gegevens van een bepaalde cliënt

10

Aangezien Full Service al in LO3.6 verwerkt is moet bij wijziging van specificaties
gecontroleerd worden of er ook wijzigingen in LO3.6 moeten worden verwerkt.
11
Voorbeeld van een onderdeel dat in definitiestudie genoemd is maar waarvan op grond
van inputdocumentatie niet zeker is of dit wel of niet in scope van Full Service is.

25

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

gebruikt terwijl deze nog niet ‘up to date’ zijn in de landelijk raadpleegbare
GBA-V kopie. Dit kan verwarrend zijn en ergernis oproepen in de
dienstverlening; de burger heeft al aangifte gedaan van bijvoorbeeld een
verhuizing en verwacht dat afnemers daar al van op de hoogte zijn. Een
voorbeeld is de intergemeentelijke verhuizing; als de nieuw gemeente de
aangifte aan het loket reeds heeft verwerkt komen pas na 48 uur of zelfs nog
later de bijbehorende gegevens (de PL) ‘aan’ vanuit de oude gemeente en pas
daarna wordt de verhuizing met een spontane mutatie doorgegeven aan GBA-V
en afnemers.
Meer in detail leidt Moderne Interfaces tot de volgende veranderingen:
•
•
•
•

•

Het berichtenverkeer van burgerzakensystemen naar GBA-V verloopt via de
OSB en kan real time plaatsvinden
Het berichtenverkeer tussen gemeente onderling verloopt via de OSB en
kan real time plaatsvinden
Het berichtenverkeer naar afnemers verloopt via de OSB en kan real time
plaats vinden
Nadat alle gemeenten en afnemers zijn overgegaan kunnen de
componenten die GBA-V verbinden met het huidige GBA-netwerk vervallen
en kan het GBA-netwerk vervallen.
Tenzij alle gemeenten tegelijk overgaan op Moderne Interfaces (hetgeen
niet het uitgangspunt is in de oorspronkelijke definitiestudie) moet de
berichtenmakelaar tijdelijk in staat zijn intergemeentelijke berichten die via
Moderne Interfaces ontvangen worden via het GBA-netwerk door te sturen
en vice versa.

Dit betekent een technisch fundamenteel andere vorm van berichtenverkeer
waarbij in tegenstelling tot het huidige GBA-netwerk op internet /
webtechnologie aansluitende open standaarden van de OSB worden gebruikt.
Het aansluiten op de OSB door afnemers en gemeenten valt buiten de scope
van deze oplossingscomponent aangezien dit toerekenbaar is aan andere Eoverheid programma’s.

3.3.4
Deelcomponenten van Moderne Interfaces
Voor de invoering van Moderne Interfaces zijn de volgende onderdelen nodig,
deze worden verder uitgewerkt in onder meer paragraaf 5.6. Voor het begrip
van Moderne Interfaces is het belangrijk te constateren dat het meer is dan
enkel de vervanging van het netwerk. Moderne interfaces impliceert ook dat
het mogelijk wordt om met een service georiënteerde architectuur te werken,
zie verder 4.2.1.
Moderne interfaces voor gemeenten:
• Gemeenten dienen aangesloten te zijn op de OSB
• Gemeentelijke burgerzakensysteem dient een OSB adapter te hebben
• Een aangepaste synchronisatieservice tussen GBA-V en BZS-K of
burgerzakensystemen. Deze vervangt de synchronisatieservice die in GBA-V
Online (R4) voor de huidige situatie voor het doorgeven van
mutatiemeldingen aan GBA-V gerealiseerd is. Vervanging betreft met name
de wijze waarop LO3 berichten nu via het GBA netwerk deze service
bereiken.

26

Definitiestudie mGBA Versie 1.8

•
•

•

De moderne GBA mogelijk gemaakt…

Realisatie gelaagde adapters GBA-V conform architectuur definitiestudie
Berichtenmakelaar t.b.v routering van berichten van en naar gemeenten
die nog via GBA-netwerk communiceren inclusief de services voor
verwerken van betreffende berichtencycli.
Met netwerk verbonden beveiliging, beheer, routering etc moet omgezet
worden naar OSB standaarden.

Moderne interface voor de afnemers
• Aanpassingen aan de LO3 services t.b.v. de OSB
• De afnemers dienen aangesloten te zijn op de OSB en de applicaties waarin
GBA berichten verwerkt worden dienen een OSB adapter te hebben.
• Met netwerk verbonden beveiliging, beheer, routering etc moet omgezet
worden naar OSB standaarden.
Verder
• Mate waarin in deze stap de berichtinhouden worden aangepast hangt af
van samenhang met de oplossingscomponenten BZS-K en LO4
gegevensmodel. Berichtenveloppen moeten in ieder geval OSB conform
worden.
• Moderne interfaces vereist een aangepaste LO specificatie (ook in scenario
1, echter daar zonder de aanpassingen aan gegevensmodel, maar wel met
aanpassingen aan berichtenstructuur)
• Moderne Interfaces vereist aanpassing van huidige Schouwing en Toetsing.
• Aanpassing van de TMV aan Moderne Interfaces waarbij het in de rede ligt
de TMV gelijktijdig aan te passen aan de TMF, een vergelijkbare voorziening
die als onderdeel van het programma ODP wordt gerealiseerd voor het
geheel van basisregistraties. Terugmeldingen voor het hele stelsel van
basisregistraties moeten aan de TMF kunnen worden opgegeven, van daar
uit moeten ze door de TMV van GBA verwerkt kunnen worden (de hiertoe
benodigde aanpassingen van de TMV zouden ook als onderdeel van Full
Service gerealiseerd kunnen worden of als losstaande release; momenteel
is dit niet expliciet belegd).

Tekst deze
paragraaf
identiek aan
businesscase

3.3.5

Burgerzakensysteem-kern (BZS-K)

De implementatie van een BZS-K houdt in dat alle gemeenten een centraal
ontwikkelde uniforme kernapplicatie gaan toepassen voor het opnemen,
wijzigen en opslaan, van persoonsgegevens t.b.v. burgers en
binnengemeentelijke afdelingen in dienstverlenende processen. Deze wordt
lokaal geïnstalleerd voor gebruik door de gemeenten. BZS-K omvat alleen de
basisfuncties en lokale gegevensopslag en vereist Aanvullende Modules die de
gebruikersinterface, workflow en verdere burgerzakenfunctionaliteit omvatten
en geheel onder verantwoordelijkheid van de gemeenten door marktpartijen
geleverd moeten worden. De huidige burgerzakensystemen worden vervangen
door een BZS-K met een of meer Aanvullende Modules.

Het implementeren van een ‘kern’ houdt in dat de Rijksoverheid de structuur
van dit nieuwe basis burgerzakensysteem specificeert en ontwikkelt. Hierin zit

27

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

de functionaliteit om de GBA-gegevens op te zoeken, te wijzigen, op te slaan en
in kopie te leveren aan de GBA-V via de Moderne Interface (OSB). De
functionaliteit voor het uitvoeren van de in de GBA-wet vastgelegd taken en de
bijbehorende controles op gegevenskwaliteit worden daarmee voor alle
gemeenten uniform .
Het BZS-K zal tot gevolg hebben dat de lokale burgerzakensystemen worden
vervangen. De kern zelf omvat enkel de functies “onder de motorkap”. Een
gemeente zal in aanvulling op het BZS-K dan ook aanvullende software moeten
implementeren waardoor ook daadwerkelijk van de functies in de GBA gebruik
kan worden gemaakt. Deze extra software wordt aangeduid met de term
‘aanvullende modules.’ Eindgebruikers benutten de functies “onder de
motorkap” via Aanvullende Modules die de gebruikersinterface, workflow en
andere functies voor het uitvoeren van de burgerzakentaak en loket leveren.
Tussen BZS-K en de Aanvullende Modules bevindt zich een koppelvlak op basis
van open standaarden. Daarmee wordt de marktwerking ten aanzien van
Aanvullende Modules bevorderd.
Gevolg van de invoering van BZS-K is dat de huidige vergoedingen voor
wijzigingen aan burgerzakensystemen kunnen vervallen en dat de LO
specificatie als instrument om marktpartijen gemeentelijke functionaliteit te
laten ontwikkelen vervangen wordt door de veel minder omvangrijke
beschrijving van het binnengemeentelijke koppelvlak.
De aanvullende modules kunnen door de gemeenten zelf naar eigen keuze
worden toegevoegd, passend in het lokale landschap van architectuur en back
office applicaties en afgestemd op de lokale behoeften.
De volgende figuur geeft de scheiding weer tussen de basisfunctionaliteit in BZSK en de functionaliteit die eindgebruikers benutten op basis van Aanvullende
Modules [7]

Figuur 12: Scheiding tussen functionaliteit BZS-K en aanvullende modules.

3.3.6

Het deelprogramma Burgerzakensysteem: BZS-K en Aanvullende
Modules
BZS-K (Deelprogramma Burgerzakensysteem) kent de volgende
deelcomponenten, zie ook 4.4:

28

Definitiestudie mGBA Versie 1.8

•

•
•
•

•

•
•
•

12

Een project waarin onder verantwoordelijkheid van VNG en NVVB de
specificaties voor de Aanvullende Modules worden opgesteld en waarin
vanuit modernisering GBA bewaakt moet worden dat gemeenten tijdig
Aanvullende Modules met voldoende functionaliteit kunnen aanschaffen bij
marktpartijen.
Specificatie van binnengemeentelijke koppelvlak en bijbehorende
wijzigingen ten aanzien van LO procedure.
Realisatie van BZS-K
Voor de werking van de synchronisatieservice, de intergemeentelijke
berichtenservices en de hersynchronisatie, de terugmeldservices, de BSN
bevraging en de berichtenmakelaar maakt het uit of de gemeenten met een
BZS-K werken of niet, afhankelijk van de volgorde van de planning ten
opzichte van de andere oplossingscomponenten leidt dit tot aanpassingen.
Implementatie van BZS-K bij alle gemeenten (in samenhang met
implementatie Aanvullende Modules) inclusief benodigde
gegevensmigraties.
Inrichten van beheer en onderhoud op BZS-K.
Volledig andere werkwijze ten aanzien van Schouwing en Toetsing
Realisatie van (deels centrale) beheerfunctionaliteit voor BZS-K

3.3.7

Tekst deze
paragraaf
identiek aan
businesscase

De moderne GBA mogelijk gemaakt…

Het LO 4 gegevensmodel

De gegevensmodelwijziging naar LO4 betekent een forse herstructurering van
de manier waarop persoonsgegevens worden opgeslagen. Gegevens over
gerelateerden (ouders, partners, kinderen, etc.) worden beter gestructureerd
en er wordt een onderscheid ingevoerd tussen echte persoonsgegevens en het
logboek waarin procesgegevens over de bijhouding worden vastgelegd.
Daarnaast wordt de gegevensset opgeschoond en worden wijziging
doorgevoerd die het mogelijk maken vaker dan één keer per dag een mutatie
door te voeren.

Het LO (Logisch Ontwerp) specificeert o.a. de eisen die worden gesteld aan een
gegevensset (gegevenswoordenboek) en het gegevensmodel (hoe zijn de
onderlinge relaties gestructureerd). Het huidige LO3.6 [8] is nog sterk gericht op
decentrale bijhouding, gegevensopslag en decentrale verstrekking van gegevens.
Beperkte wijzigingen in het GBA-stelsel worden binnen de LO3-releases
verwerkt. LO3 wordt door gebruikers als complex ervaren, zie o.a. Snellen [51].
De herstructurering is zowel een wijziging van het gegevensmodel als een
wijziging van de gegevensset. De herstructurering leidt tot een model dat veel

12

De door KPMG in haar rapport voorgestelde terminologie leidt niet tot een duidelijke
benaming voor dit deelproject zodanig dat het evident onderscheiden is van de realisatie
van BZS-K, hierdoor blijft een risico van verwarring ten aanzien van de
verantwoordelijkheden bestaan. [7]

29

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

beter aansluit op de wijze van vastleggen in de andere basisregistraties en heft
beperkingen die het gevolg zijn van de huidige structuur die nog direct op de
persoonskaart van voor 1994 gebaseerd is op.
In de modernisering van de GBA worden verbeteringen aan het gegevensmodel
én aanpassing van de gegevensset voorgesteld, die ertoe bijdragen dat de
gegevenskwaliteit wordt verbeterd en de bijhouding vereenvoudigd wordt.
Daarnaast wordt het model zodanig aangepast dat het realtime verwerking
mogelijk maakt en ook beter aansluit op het stelsel van basisregistraties. Het
ontwerp voor de gemoderniseerde gegevensset en het gegevensmodel wordt
aangeduid met LO4.
Het LO4 gegevensmodel omvat een aantal grote verbeteringen zoals:
1.

Vermindering van redundante gegevensopslag (gegevensmodel
13
wijziging). Gerelateerden worden vastgelegd met enkel hun BSN en
dit verwijst altijd naar de meest actuele gegevens op de persoonslijst
die er bij hoort.

2.

Ontkoppeling historie van de persoon (levensloop) en de historie van
de bijhouding van de persoonslijst (logboek) en enige aanpassingen in
de vastlegging van de historie. Deze ontkoppeling maakt het mogelijk
het bijhoudingsproces voor de Burgerzakenmedewerkers te
vereenvoudigen; in de huidige opzet staan de logboekgegevens in de
levensloop en dit kan het zicht ontnemen op de levensloop, die voor
het correct uitvoeren van de bijhouding en voor de communicatie met
de burger essentieel is. Dit is verder van belang voor terugmeldingen
en voor de RNI (zie paragraaf 4.8) waarbij nieuwe logboek gegevens
ontstaan en voor het vereenvoudigen van de bijhouding. Het maakt
veel efficiëntere inrichting van de berichtinhoud voor verstrekking aan
afnemers mogelijk.

3.

Aanpassingen om vaker dan één keer per dag een mutatie op een
bepaalde persoonslijst door te voeren en preciezer het tijdstip van deze
bijhouding vast te leggen. Dit is van belang in een real time stelsel.

4.

Opschoning en overbodig maken van workarounds die toegepast zijn
om beperkingen van het huidige model te omzeilen.

Ad 1: Bij elke persoon in de GBA liggen gegevens vast over de relaties met
andere personen, bijvoorbeeld kinderen en ouders of partner. Omdat kinderen
en ouders in verschillende gemeenten kunnen wonen, komen gegevens over
dezelfde persoon op dit moment voor in verschillende administraties bij
verschillende gemeenten. De redundante en decentrale opslag maken de
bijhouding van gebeurtenissen in een leven van een persoon erg complex. In de
huidige situaties zijn gegevens van gerelateerden op de persoonslijst veelal niet
actueel en bevinden zich van heel veel personen oudere versies van hun

13

Voor zover het ingezetenen betreft, niet ingezeten gerelateerden hebben nu een Rnummer en komen op gegeven moment in RNI.

30

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

gegevens op de persoonslijsten van anderen. De kans op fouten is daardoor
groot. Door een modelwijziging, in combinatie met de aanwezigheid van de
GBA-V, waarin alle persoonslijsten aanwezig zijn, wordt redundantie beperkt, de
kans op fouten verkleind en daarmee kwaliteitsverbetering bereikt.
Ad 2: De persoonslijst is opgebouwd uit een aantal gegevenscategorieën,
groepen en elementen. Op het moment dat één gegeven wijzigt worden hele
“brokken” gegevens als historie betiteld. Alle gegevens uit de persoonslijst
worden vervolgens weer verstrekt aan afnemers, dus ook de opgebouwde
historie. Door de gegevensset aan te passen kan de efficiëntie worden
verbeterd en de historie beter worden verwerkt. Daarbij wordt in het LO4
gegevensmodel voorgesteld om in een logboek de historie over de bijhouding te
gaan opnemen. Daardoor wordt de historie gescheiden van de actuele gegevens,
waardoor in het verleden gemaakte fouten en correcties van die fouten
weliswaar geregistreerd en bewaard blijven, maar geen onderdeel van het
berichtenverkeer meer uitmaken.
Voor verdere uitwerking van de gegevensmodelwijziging wordt zie hoofdstuk 6.

3.3.8

Deelcomponenten ten behoeve van invoering LO4 gegevensmodel

Om de invoering van het LO4 gegevensmodel mogelijk te maken zijn de
volgende voorzieningen nodig:
 De berichtenmakelaar moet niet enkel de berichtenveloppen in elkaar
kunnen omzetten maar tevens LO3 berichten naar LO4 berichten vertalen.
 In GBA-V moet de LO4 database gerealiseerd worden
 Er dient een conversie engine gerealiseerd te worden die LO3 PL-en in LO4
PL-en converteert en vice versa.
 Alle services tussen GBA-V en de gemeente en tussen gemeenten
onderling dienen LO4 berichten te kunnen verwerken.
 Voor afnemers worden de LO4 services gerealiseerd. Dezelfde
functionaliteit als de LO3 services (ad hoc vragen, ad hoc adres vragen,
spontane mutaties, selecties, afnemersindicaties bewerken) maar dan op
basis van LO4 berichten.
 Afnemers dienen hun systemen aan te passen aan de verwerking van LO4
berichten.
 Indien invoering van BZS-K niet tegelijk plaatsvindt dienen BZS-K en de
Aanvullende Modules aangepast te worden aan LO4.
3.4

Relatie tussen de deelcomponenten en de doelstellingen

Dit is uitgewerkt in de businesscase, paragraaf 7.4.

3.5

De drie scenario’s

Gebaseerd op de vier hierboven benoemde oplossingscomponenten zijn door
programma mGBA drie scenario’s gedefinieerd, samengesteld uit een of
meerdere van de oplossingscomponenten. In het schema hieronder zijn de drie
scenario’s weergegeven, gevolgd door een korte toelichting bij ieder scenario.
De businesscase is opgesteld aan de hand van dezelfde scenario’s.

31

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Figuur 13: De drie onderkende scenario’s
In de figuur worden de drie onderkende scenario’s weergegeven. Scenario 1
bestaat uit een combinatie van de oplossingscomponenten GBA-V Full Service
en Moderne interfaces. In scenario 2 wordt ook het BZS-K geïmplementeerd en
zal de LO4 gegevensmodelwijziging worden uitgevoerd. In scenario 3 tenslotte
zal alleen de LO4 gegevensmodelwijziging worden geïmplementeerd zonder de
overige componenten op basis van de bestaande LO wijzigingsprocedure.
Hieronder wordt nader op deze scenario’s ingegaan:

Tekst deze
paragraaf
identiek aan
businesscase

3.5.1

Scenario 1. GBA-V Full Service in combinatie met Moderne interfaces.

Figuur 14: Uitwerking scenario 1
Scenario 1 houdt in dat de componenten Full Service en Moderne Interfaces
worden gerealiseerd. De eindsituatie van scenario 1 houdt in dat systematische
verstrekkingen vanuit één punt, namelijk het landelijke GBA-V aan afnemers
worden geleverd en dat het berichtenverkeer real time via de OSB verloopt.
Zoals weergegeven in het schema hierboven, vervalt de taak van het leveren
van verstrekkingen aan afnemers door gemeenten. Waar de oude taak bestond
uit het bijhouden van gegevens en het verstrekken hiervan, blijft alleen de
bijhoudingstaak over.

32

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Realisatie van Full Service en Moderne interfaces zal betekenen dat de mutaties
die bij de bronhouders (gemeenten) worden doorgevoerd, real time ofwel
direct na verwerking beschikbaar zijn in GBA-V. Iedere verstrekking vanuit GBAV zal daarmee up to date zijn naar de laatste stand van de mutaties bij de
gemeenten en direct in vorm van spontane mutaties aan de afnemers die een
afnemersindicatie hebben worden doorgestuurd.
Omdat in dit scenario, in tegenstelling tot scenario 2 geen BZS-K zal worden
ingevoerd, is het daarnaast nodig om de huidige burgerzakensystemen van de
gemeenten aan te passen voor aansluiting op de OSB. Naast aansluiting dienen
deze systemen zo te worden ingericht dat ze berichten meteen na de
verwerking kunnen verzenden en om kunnen gaan met real time
14
intergemeentelijk berichtenverkeer. Extra investeringen in ieder van de vijf
verschillende burgerzakensystemen zullen hiervoor benodigd zijn evenals een
specificatie van de benodigde wijzigingen in een LO procedure en voorzieningen
om het mogelijk te maken dat deel van de gemeenten al over is op moderne
interfaces terwijl een ander deel van de gemeenten nog via het huidige GBAnetwerk communiceert
De aanname is dat andere wensen van afnemers ten aanzien van de berichten
tegelijk met de invoering van Moderne Interfaces worden gerealiseerd, voor
zover deze geen betrekking hebben op de wijziging naar het LO4
gegevensmodel die in dit scenario geen doorgang vindt (althans niet binnen de
in de businesscase doorgerekende periode).

Tekst deze
paragraaf
identiek aan
businesscase

3.5.2

Scenario 2. GBA-V Full Service i.c.m. Moderne interfaces, de BZS-K en
LO4.
In scenario 2 worden alle componenten gerealiseerd conform de
oorspronkelijke opzet van het programma modernisering GBA. Evenals in
scenario 1 is de eindsituatie dat systematische verstrekkingen vanuit één punt,
namelijk het landelijke GBA-V aan afnemers worden geleverd en dat het
berichtenverkeer real time via de OSB verloopt. Daarnaast vervangen alle
gemeenten hun huidige burgerzakensysteem door een uniform BZS-K en een of
meer Aanvullende Modules geleverd door marktpartijen. Ten derde is het
gegevensmodel na afronding van de migratie zowel in de gemeenten, in GBA-V
als in berichtenverkeer naar afnemers gebaseerd op het LO4 gegevensmodel.

14

Zodra de gemeente Amsterdam de overgang naar het in 2008 na nieuwe aanbesteding
geselecteerde systeem van Centric heeft voltooid blijven er nog vier systemen over.

33

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Figuur 15: Uitwerking scenario 2
De figuur toont de verschillen met scenario 1 in de eindsituatie: allereerst
verschilt de eindsituatie bij de gemeenten aanzienlijk. In scenario 2 worden de
burgerzakensystemen bij de gemeenten geheel vervangen en verdwijnt de
bestaande procedure voor het specificeren van wijzigingen in de door
marktpartijen geleverde burgerzakensystemen. In plaats daarvan onderhoudt
BPR de basisfunctionaliteit in BZS-K en is deze door een open en
gestandaardiseerd koppelvlak gescheiden van de Aanvullende Modules die
volledig onder verantwoordelijkheid van de gemeenten vallen.
De aanname is dat het BZS-K direct gebaseerd wordt op het LO4 gegevensmodel
waarmee een gemeente bij de implementatie van de BZS-K dus ook overgaat op
het LO4 gegevensmodel. Omdat niet iedere gemeente op hetzelfde moment
over kan gaan op de nieuwe BZS-K, stelt dit scenario wel als eis dat de
verstrekkingen vanuit BPR tijdelijk zowel in LO3 als in LO4 beschikbaar zijn. GBAV moet een veel uitgebreidere conversiemodule bevatten dan in scenario 1.
Bovendien moet GBA-V tijdelijk gegevens zowel in LO3 als in LO4 formaat
opslaan.
Voor die systemen van afnemers die na de implementatie van het LO4
gegevensmodel nog niet geschikt zijn voor de berichtenstructuur van LO4, zal
een ‘vertaalmodule’ (conversiemodule) moeten worden behouden tot het
natuurlijk moment van vervanging van het back office systeem, dus mogelijk
langer dan voor de migratie van de gemeenten. Hierbij wordt aangenomen dat
nieuwe releases van die systemen conform de reguliere update procedures
worden uitgerold en dat deze gebaseerd zullen zijn op, c.q. aangepast zullen
zijn aan het LO4 gegevensmodel. De aanname is dat andere wensen van
afnemers ten aanzien van de berichten tegelijk met de invoering van Moderne
Interfaces en het LO4 gegevensmodel worden gerealiseerd.
De uitwerking van dit scenario is gebaseerd op het materiaal dat daarover in
loop van het programma gerealiseerd is zoals bijvoorbeeld [11].

34

Definitiestudie mGBA Versie 1.8

Tekst deze
paragraaf
identiek aan
businesscase

3.5.3

De moderne GBA mogelijk gemaakt…

Scenario 3. Invoering LO4 gegevensmodel.

Figuur 16: Uitwerking scenario 3
In het derde scenario wordt alleen het LO4 gegevensmodel ingevoerd. Het
huidige GBA-netwerk blijft gehandhaafd, evenals de rolverdeling tussen BPR en
gemeenten. Gemeenten blijven dus verantwoordelijk voor de spontane
mutaties en selecties en zullen rechtstreeks aan de afnemers blijven leveren
zonder tussenkomst van de beheerorganisatie BPR. Wel zal de inhoud van de
verstrekkingen (berichten) gaan verschillen omdat de gegevensset en het
gegevensmodel zoals in LO3 gedefinieerd, zullen veranderen. Dit betekent dat
er aan de zijde van de verstrekker (gemeenten) lokaal een conversiemodule
nodig is om zowel LO3 als LO4 berichten te kunnen leveren al naar gelang de
situatie van de afnemer; zodra alle gemeenten en afnemers in staat zijn om op
LO4 gebaseerde berichten te verwerken kan deze conversiemodule komen te
vervallen (in de figuur weergegeven met C). Het inmiddels gerealiseerde GBA-V
Online blijft in productie en dient eveneens aangepast te worden aan het LO4
gegevensmodel. Te verwachten valt dat GBA-V Online meer gebruikt zal worden
en dat het (veel langzamere) stellen van Ad hoc vragen via het GBA-netwerk zal
afnemen en uiteindelijk verdwijnen.
Het is onwaarschijnlijk dat de verandering naar het LO4 gegevensmodel in één
stap kan worden uitgevoerd. Op basis van de ervaring met LO wijzigingen is de
verwachting dat meerdere achtereenvolgende wijzigingen noodzakelijk zullen
zijn. Om de benodigde conversievoorzieningen beperkt te houden is het
noodzakelijk dat alle gemeenten tegelijk deze wijzigingen doorvoeren zoals bij
eerdere grote LO wijzigingen ook het geval was.
In de businesscase worden de scenario’s doorgerekend op basis van
migratiepaden waarin ook het parallel ontwikkelen en moment van opleveren
een rol speelt.

35

Definitiestudie mGBA Versie 1.8

3.6

De moderne GBA mogelijk gemaakt…

De scope van het programma modernisering GBA

Onderstaand wordt een afbakening gegeven vanuit het gezichtspunt van het
moderniseringsprogramma en deze definitiestudie. De afbakening omvat
uiteraard de in paragraaf 3.3 beschreven componenten. Desalniettemin is het
nuttig deze afbakening separaat te beschrijven. Naast het afbakenen van de
onderdelen die binnen de beschrijving van de modernisering en deze
definitiestudie vallen worden relaties weergegeven met voorzieningen die
essentieel zijn voor de werking van de GBA maar buiten de gekozen afbakening
vallen.
De afbakening van het programma modernisering wordt vastgesteld op:
•
•
•

•
•
•

GBA-V c.q. de volledige diensten voor systematische verstrekking en
hetgeen voor verantwoord beheer daarvan nodig is.
Centrale TMV inclusief eventuele nieuwe versies daarvan die ontsloten
worden via de landelijke TMF.
Gebruik maken van de OSB conform de samenwerkingsafspraken
daarover in e-overheidsverband (Moderne Interfaces). Al datgene dat
niet als algemene faciliteit of als onderdeel van andere veranderingen
bij gemeenten en afnemers gerealiseerd wordt dient binnen het
programma modernisering gerealiseerd te worden. Alle beheer en
verantwoordelijkheidsaspecten vallen binnen het toekomstige GBAstelsel, tenzij deze expliciet elders belegd kunnen worden. Voor zover
dat het geval is zal dat in deze definitiestudie worden aangegeven.
De gemeentelijke Burgerzakensystemen eventueel ingevuld door een
BZS-K in combinatie met Aanvullende Modules.
Doorvoeren van wijzigingen aan gegevensmodel en gegevensset (LO4)
maar tevens aan de berichtspecificatie en berichtinhouden.
Conversiefaciliteiten. Diensten die migratie van de ene generatie van
LO specificatie naar de volgende faciliteren (onderdeel van Moderne
Interfaces).

Niet in alle scenario’s worden alle oplossingscomponenten uitgevoerd, de
afbakening verschilt dan ook per scenario. Dit is globaal weergegeven in
onderstaande tabel.
Scenario 1. In scenario 1 is
geen sprake van een BZS-K en
Aanvullende Modules en
wordt de gegevensmodelwijziging naar LO4 niet
uitgevoerd. De functie van
BZS-K en Aanvullende
Modules wordt ingevuld door
burgerzakensystemen van
leveranciers. Daarbij is het niet
verplicht een soortgelijke
architectuur te volgen als voor
BZS-K. De systemen hoeven
geen gebruik te maken van
een binnengemeentelijke
service-bus maar kunnen ook
direct op de landelijke OSB zijn

Scenario 2. De bovenstaande
afbakening van het
programnma geldt.
Het veranderprogramma dient
bovendien de maatregelen te
nemen die nodig zijn om tijdig
en voldoende realisatie van
Aanvullende Modules te
garanderen.
In plaats van Schouwing en
Toetsing vindt beheer van BZSK plaats.

Scenario 3. In scenario 3 is het
programma beperkter. GBA-V
blijft beperkt tot GBA-V Online
en wordt niet uitgebreid,
Moderne Interfaces wordt niet
ongevoerd en er is geen
sprake van een BZS-K en
Aanvullende Modules.
Nader bepaald dient te
worden welke
conversiefaciliteiten
noodzakelijk zijn afhankelijk
van nadere detaillering van de
migratie.

36

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

aangesloten. De wijze waarop
de binnengemeentelijke
afnemers worden aangesloten
valt buiten de afbakening en is
niet voorgeschreven in termen
van services.
De LO beschrijving zal
aangepast moeten worden om
een goede beschrijvingswijze
van OSB en service
gerelateerde aspecten te
garanderen.
Schouwing en Toetsing zal
aangepast moeten worden om
de OSB en service
gerelateerde eisen te kunnen
certificeren.

Figuur 17: Scope mGBA: weergave van de onderdelen die binnen de scope van
het programma zijn.
Terugvertaald naar de bestaande GBA componenten betekent dat de verdere
modernisering GBA de volgende componenten van het stelsel verandert:
• GBA-V
• De TMV
• Het GBA-netwerk
• De berichten en berichtcycli
• De component waarmee afnemers aangesloten zijn op het GBA-stelsel
(de VOA’s)
• De gemeentelijke Burgerzakensystemen c.q. de dienst voor de
bijhouding inclusief de verwerking van terugmeldingen en verstrekking
aan derden evenals de diensten voor systematische verstrekking en
intergemeentelijk berichtenverkeer.

37

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

3.6.1
Relaties van de GBA met voorzieningen
Op basis van de bovenstaande afbakening gelden de volgende relaties met
omliggende voorzieningen. De hier bedoelde relaties leiden tot een
daadwerkelijke technische afhankelijkheid of het over en weer aanroepen van
services. Daarnaast zijn er organisatorische relaties, onder andere met de
diverse e-overheids programma’s die nieuwe afnemers realiseren. Dat type
relaties is hier niet beschreven.
Allereerst zijn er relaties met reeds bestaande voorzieningen:
• BV BSN, onderdeel van de LO 3.6 specificatie. De BV BSN is een
systeem dat voor de introductie van het BurgerServiceNummer is
ingericht. Het bevat een subset van de gegevens uit GBA-V en
daarnaast gegevens vanuit de Belastingdienst. BV BSN is o.a.
noodzakelijk om dubbele uitgifte van BSN nummers te voorkomen. In
termen van functionaliteit is er potentiële overlap met een verder
doorontwikkeld GBA-V en bij invoering LO4 gegevensmodel moet de
koppeling met BV BSN aangepast worden. Momenteel wordt de BV
BSN met gegevens gevoed vanuit GBA-V. Het is wenselijk te
inventariseren welke wijzigingen aan BV BSN nodig zijn om deze goed
en zonder onnodige overlap in functionaliteit in het gemoderniseerde
GBA-stelsel in te passen.
Ten tweede gelden relaties met diensten die in diverse andere
veranderprogramma’s ontwikkeld worden, te weten:
• Binnengemeentelijke BAG koppeling. Deze koppeling is een onderdeel
van het Stelsel van Basisregistraties. Binnen dat stelsel geldt dat de
registratie die een bepaalde relatie legt (bijhoudt in GBA terminologie)
verantwoordelijk is voor deze relatie en dit is ook als zodanig in de wet
GBA opgenomen. De consequenties die dit heeft voor de diensten van
de GBA zijn beschreven [32]. Iedere gemeente dient eind 2009 een
operationele BAG te hebben en de koppeling van GBA naar de BAG
dient ultimo 2010 in werking te zijn.
• OSB. De OSB biedt enkele diensten die voor een goed functioneren van
de GBA noodzakelijk zijn, zoals adressering. Deze samenhang met de
OSB is uitgewerkt in paragraaf 5.6. Deze diensten komen vanaf eind
2008 beschikbaar.
• Binnengemeentelijke servicebussen. De interface tussen BZS-K en de
Aanvullende Modules wordt ingevuld doordat de betreffende diensten
worden aangeboden op de binnengemeentelijke servicebus. Dit stelt
vanuit de GBA eisen aan de binnengemeentelijke servicebus, o.a. dat
deze bus de OSB specificaties volgt en aangesloten is op de landelijke
OSB. Er zullen nog nadere eisen zijn, zie paragraaf 5.6.1
• RNI. De RNI is een aanvulling op het GBA-stelsel voor het vastleggen
van niet ingezetenen. Realisatie is gepland in 2011. Zie paragraaf 4.8.

38

Definitiestudie mGBA Versie 1.8

•

•

De moderne GBA mogelijk gemaakt…

Gemeentelijke systemen die zich als Aanvullende Module zouden
kunnen gedragen, zoals Reisdocumenten, andere systemen van
15
Burgerzaken.
Gemeentelijke kernregistraties, al dan niet onderdeel van een
Aanvullende Module. Diverse gemeenten bezitten al een dergelijke
kernadministratie in een of andere vorm en benutten deze in het kader
van invoering basisregistraties en transitie naar een e-gemeente.

Scenario 1. Er is geen relatie
met binnengemeentelijke
servicebus, tenzij deze door de
leveranciers wordt gekozen.
Realisatie van de BAG
koppeling, bevraging van RNI
en verwerken van
terugmeldingen zijn onderdeel
van het Burgerzakensysteem
en wordt door leveranciers
gerealiseerd. Leveranciers
hebben grote vrijheid in
koppeling naar andere
systemen binnen de
gemeenten, naar
binnengemeentelijke
afnemers en
kernadministraties.

Scenario 2. De bevraging van
RNI, verwerking van
terugmelding, diensten voor
binnengemeentelijk gebruik
en andere gemeentelijke
systemen zullen gebaseerd
zijn op de diensten van BZS-K.
Voor een goede BAG
koppeling zijn daarnaast
voorzieningen in een
Aanvullende Module vereist.

Scenario 3. In scenario 3 is er
geen relatie met OSB en
binnengemeentelijke
servicebussen.
De koppeling naar BAG en
bevraging van RNI worden in
de bestaande GBA-systemen
ingebouwd door leveranciers.
Leveranciers hebben grote
vrijheid in koppeling naar
andere systemen binnen de
gemeenten, naar
binnengemeentelijke
afnemers en
kernadministraties

Figuur 18: Scope mGBA en relaties met andere projecten en systemen

15

Begin oktober 2008 heeft ministerie van Justitie een vernieuwingsproject ten aanzien van
Burgelijke Stand aangekondigd. In samenwerking met o.a. de NVVB. Het verdient de
aanbeveling de samenhang daarmee expliciet te bewaken in overleg met de NVVB.

39

Definitiestudie mGBA Versie 1.8

3.7

De moderne GBA mogelijk gemaakt…

Mogelijke andere accenten in de scenario’s

Als alternatief zou het BZS-K als landelijke voorziening gerealiseerd kunnen
worden. Een dergelijke wijziging zou geïntegreerd moeten worden met de
16
totaalvisie en architectuur van de elektronische gemeente . Zowel in
kwalitatieve zin als ten aanzien van de businesscase heeft een
Burgerzakensysteem als landelijke voorziening potentiële voordelen. Voordelen
die bovendien meer ruimte bieden aan toekomstige ontwikkelingen als
plaatsonafhankelijk werken. Bovendien ontstaan nieuwe opties voor de fasering
van de migratie van het gegevensmodel van LO3 naar LO4. Dat neemt niet weg
dat een landelijke voorziening qua interne structuur op een aantal punten fors
verschilt van het hier beschreven scenario 2.
Een ander alternatief zou zijn om het programma RNI te benutten als pilot voor
BZS-K. Het concept van de RNI bestaat uit een Aanvullende Module, een
technisch centraal systeem dat sterk op BZS-K lijkt en verstrekkingsfunctionaliteit die sterk op GBA-V Full Service lijkt. Oorspronkelijk was het plan
dat de RNI deze zaken zou hergebruiken vanuit modernisering GBA. Nu
realisatie daarvan later gaat worden kunnen de rollen worden omgedraaid. Een
goed ingericht RNI, of een vroege pilot daarvan, zou een voorbeeld geven van
de werking van een BZS-K als landelijke voorziening en daarmee sterk kunnen
bijdragen aan dit vervolgscenario. Evenzeer is de potentiële synergie aan de
verstrekkingenzijde afhankelijk van de volgorde waarin RNI en de
oplossingscomponenten van modernisering GBA gerealiseerd worden.

3.8

Conclusie ten aanzien van scenario’s en scope

De in dit hoofdstuk beschreven oplossingscomponenten en de daaruit
opgebouwde scenario’s vormen een ingewikkeld geheel waaronder een
veelheid aan onderlinge afhankelijkheden schuil gaat. Zodra nadere beslissingen
zijn genomen over het actualiseren van de doelstellingen (zie hoofdstuk 2) en
een bestuurlijke keuze gemaakt is voor het te volgen scenario verdient het de
aanbeveling dat scenario verder aan te scherpen en te optimaliseren. In de
verdere uitwerking van het herstartte moderniseringsprogramma blijft de
behoefte bestaan aan een globale beschrijving van de componenten zoals in dit
hoofdstuk weergegeven. Deze beschrijving dient derhalve onderhouden te
worden in het verdere vervolg.

16

Dit alternatief is in een aanvullende opdracht separaat uitgewerkt

40

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

4 Het toekomstige GBA stelsel
Dit hoofdstuk beschrijft het toekomstige GBA stelsel op hoofdlijnen zoals dat
door het programma modernisering GBA wordt gerealiseerd. Eerst wordt de
organisatie van het GBA-stelsel beschreven, de verantwoordelijkheden,
taakverdeling en besturing. Vervolgens wordt een overzicht gegeven van de
diensten die de GBA levert. Tenslotte wordt de functionaliteit van de
verschillende voorzieningen binnen het GBA stelsel beschreven. Daar waar
mogelijk is de relatie gelegd met relevante NORA-principes.
Scenario 1

4.1

Scenario 2. Verschillen tussen
de drie scenario’s worden
weergegeven in kaders als
deze. De beschrijving van deze
scenario’s is terug te vinden in
hoofdstuk 3.5.

Scenario 3

De organisatie van het GBA stelsel in de toekomst

Het GBA stelsel is essentieel voor de overheid en haar dienstverlening aan
burgers en bedrijven. De overheidstaken en dienstverlening vinden plaats vanuit
een samenspel tussen verschillende organisaties. Dit vereist afstemming,
koppeling en samenwerking. Een nauwgezette afbakening van
verantwoordelijkheden is daarbij vereist (NORA 5.1.1 en 5.1.2).

4.1.1
De verantwoordelijkheden binnen het GBA-stelsel
In tegenstelling tot het oorspronkelijke decentrale GBA stelsel kent het
toekomstige GBA stelsel een scheiding in twee verantwoordelijkheden.
ORG 1

Het GBA stelsel kent twee verantwoordelijkheden:
• de bijhouding van persoonsgegevens en de levering aan binnengemeentelijke
afnemers onder verantwoordelijkheid van de gemeenten
• de verstrekking aan afnemers als onderdeel van het stelsel van
17
basisregistraties onder verantwoordelijkheid van de minister van BZK .

17

implementeert NORA prinicipes 5.1.1 t/m 5.1.4

41

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Figuur 19: De twee verantwoordelijkheden in het toekomstige GBA stelsel
De gemeente is verantwoordelijk voor de bijhouding op basis van
gebeurtenissen in het leven van de burger die binnen de gemeentegrenzen
woont. De gemeenten zijn dus bronhouder van de GBA en voeren deze taak uit
op basis van een geautomatiseerd systeem dat hier aangeduid wordt als een
Burgerzakensysteem. Ook het concept voor de nieuwe Wet Basisregistratie
18
Personen hanteert dit uitgangspunt, met dien verstande dat dit
plaatsonafhankelijke dienstverlening van de ene gemeente namens de andere
introduceert. Door adequate samenwerking tussen gemeenten en BPR kan
kwalitatief goede informatie aan afnemers geleverd worden over
persoonsgegevens (NORA 5.1.3).
Daarnaast voorziet het stelsel in een landelijke voorziening, hier aangeduid als
19
GBA-V, die gebruikt wordt voor de systematische verstrekking aan afnemers.
Het gevolg van de landelijke voorziening is een splitsing van de berichtenstroom
tussen de gemeente naar GBA-V en de berichtenstroom van GBA-V naar de
afnemers. Dit betekent een fundamenteel ander patroon van berichtenverkeer
dan in het huidige decentrale stelsel (zie figuur Figuur 20). Deze splitsing sluit
nauw aan bij de twee afzonderlijke verantwoordelijkheden in het stelsel (NORA
5.1.4). Door de splitsing neemt het aantal direct met elkaar verbonden partijen
in het GBA stelsel drastisch af, de berichtenstromen volgen een ander patroon.

18
19

Informatie over dit interne concept is gebaseerd op interviews met expertteam
In de tekst is specifieke GBA terminologie gebruikt. Deze is uitgewerkt in de begrippenlijst.

42

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Figuur 20: Verandering van het oude decentraal GBA stelsel naar het
toekomstige stelsel met een landelijke GBA-V voor verstrekkingen.
ORG 2

Het GBA stelsel is één geheel gebaseerd op één set aan afspraken met een
wettelijke basis

Scenario 1. In scenario 1 blijft
de bestaande LO procedure de
vorm van deze afspraken.

Scenario 2. Vanwege het
verplicht gebruik van BZS-K
verandert de aard van de
afspraken en wordt het
specificeren van eisen aan
burgerzakensystemen op basis
van de LO procedure
vervangen door het onder
verantwoordelijkheid van BZK
beheren van BZS-K. Voor
andere aspecten zoals het
berichtenverkeer blijft een
vastlegging van afspraken en
technische specificaties
noodzakelijk inclusief een
robuuste wijzigingsprocedure.

Scenario 3. In scenario 3 blijft
de bestaande LO procedure de
vorm van deze afspraken.

Naast de verantwoordelijkheid voor de verstrekkingen is de minister van BZK
verantwoordelijk voor het stelsel als geheel. Dit is verankerd in de wet GBA en
van daar uit uitgewerkt in verdere regelgeving voor de GBA. Het Logisch
Ontwerp (LO, [8]) is onderdeel van deze formele regelgeving en specificeert de
eisen waaraan de op het stelsel aangesloten systemen van gemeenten en
afnemers moeten voldoen en de onderlinge communicatie. Ook in de toekomst
zal een vorm van specificatie noodzakelijk blijven. Vanwege de steeds grotere
samenhang binnen de e-overheid dient de specificatie van het GBA-stelsel waar
mogelijk gebruik te maken van standaarden zoals gespecificeerd in de NORA en
voor bijvoorbeeld de OSB.

43

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

4.1.2
Taakverdeling tussen bijhouden en verstrekken
De splitsing van verantwoordelijkheden leidt tot een duidelijke taakverdeling
waarbij de gemeenten de bijhouding verzorgen en de landelijke voorziening de
systematische verstrekkingen aan afnemers. Gemeenten zijn wel
verantwoordelijk voor hun eigen binnengemeentelijke verstrekking. Conform
deze verdeling bestaat het GBA-stelsel uit decentrale systemen bij de
gemeenten en daarnaast landelijke voorzieningen. De belangrijkste landelijke
voorziening is de GBA-V, een volledige kopie op één plaats van alle
persoonslijsten (PL) die door de gemeenten worden beheerd. Bijhoudingen door
gemeenten worden steeds verwerkt in GBA-V.

ORG 3
(ALG 3)

Iedere gemeente heeft een Burgerzakensysteem dat leidend is bij het beheer van
de GBA-gegevens van die gemeente; GBA-V bevat te allen tijde een kopie van de
gegevens van alle Burgerzakensystemen. (NORA 7.2.3)

Scenario 1

Scenario 2. In tegenstelling tot
de beide andere scenario’s
worden de gemeenten
verplicht BZS-K als uniform
Burgerzakensysteem te
implementeren.

Scenario 3

Aangezien BZS-K en GBA-V
ontworpen zijn om als één
geheel samen te werken is een
efficiënte en zeer solide
proces onder centrale regie
voor het bijhouden van de
landelijke kopie in GBA-V
mogelijk.

Momenteel vindt een deel van de systematische verstrekkingen plaats vanuit
GBA-V (GBA-V Online). In de toekomst geldt dit voor alle systematische
verstrekkingen.
ORG 4

Alle systematische verstrekkingen vanuit de GBA worden uitgevoerd door GBA-V.

(GBA-V 1)

Scenario 1

Scenario 2.

Scenario 3. In tegenstelling tot
de beide andere scenario’s
worden niet alle
systematische verstrekkingen
uitgevoerd door GBA-V. Enkel
de verstrekkingen die door
GBA-V Online uitgevoerd
kunnen worden, voor de
overige systematische
verstrekkingen, te weten
spontane mutaties en
selecties blijft de huidige
decentrale dienstverlening
vanuit gemeenten direct aan
afnemers in stand. De in

44

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Figuur 20 weergegeven
splitsing van berichtenstromen
komt in dit scenario slechts
beperkt tot stand

De taakverdeling tussen bijhouden en verstrekken werkt door in de aansluiting
op het stelsel van basisregistraties. De gemeenten zijn naast het bijhouden van
de persoonslijsten verantwoordelijk voor het vastleggen van de voor het stelsel
essentiële relatie met de BAG, het verwerken van terugmeldingen en de
gegevenskwaliteit. GBA-V draagt zorgt voor het verstrekken van gegevens aan
het stelsel van basisregistraties.
ORG 5

Het GBA stelsel is integraal onderdeel van het stelsel van basisregistraties. Binnenen buitengemeentelijke afnemers zijn afhankelijk van de GBA om aan hun
verplichtingen inzake eenmalige verstrekking, meervoudig gebruik te voldoen. De
gemeente zijn als bronhouder gehouden om terugmeldingen te verwerken (NORA
5.1.1.2).

Het agentschap BPR is het organisatieonderdeel van BZK dat de landelijke taken
en het beheer over de landelijke voorzieningen uitvoert. Door de invoering van
GBA-V verandert de positionering van BPR. In het oude decentrale stelsel was
BPR vooral beheerder, in de toekomst levert BPR daarnaast diensten aan
afnemers en beheert ze de kopie persoonslijsten in GBA-V. BPR biedt deze
diensten nauwkeurig omschreven aan zodat het voor afnemers duidelijk is,
welke diensten afgenomen kunnen worden (NORA 5.2.1.1).
ORG 6

Het agentschap BPR is namens de minister verantwoordelijk voor het beheer van
GBA-V en de andere landelijke voorzieningen en voor de dienstverlening aan
afnemers.

Scenario 1. In scenario 1 is BPR
verantwoordelijk voor beheer
van GBA-V en alle
dienstverlening aan
buitengemeentelijke
afnemers. De
verantwoordelijkheid richting
de burgerzakensystemen
beperkt zich tot de LO
procedure, schouwing en
toetsing en audit.
De nieuwe dienstverlening aan
afnemers vormt samen met
het al gerealiseerde beheer
van GBA-V een forse
organisatieverandering voor
BPR.

Scenario 2. De
verantwoordelijkheden van
BPR gaan verder dan in
scenario 1. In plaats van de LO
procedure en schouwing en
toetsing in huidige vorm is BPR
verantwoordelijk voor het
uitbrengen van nieuwe versies
van BZS-K en het beheer van
BZS-K en de daarbij behorende
specificaties van
koppelvlakken en
berichtenverkeer.
Over de wijze waarop BZS-K
beheerd wordt dienen
nauwkeurige afspraken met
gemeenten te worden
gemaakt. Dit aspect komt
bovenop de
organisatieverandering
genoemd bij scenario 1.

Scenario 3. De
verantwoordelijkheden van
BPR gaan minder ver dan in
scenario 1 omdat slechts een
deel van de dienstverlening
aan afnemers door BPR is
overgenomen, namelijk enkel
GBA-V online.
De organisatieverandering bij
BPR is in dit scenario
beperkter en omvat enkel het
beheer van nu reeds in
productie genomen delen van
GBA-V Online.

Afhankelijk van de
ontwikkelingen aan de
servicebus moet BPR ook
procesregie en andere

45

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

servicebusfunctionaliteit
beheren die noodzakelijk is
voor het GBA stelsel maar
(nog) niet door de OSB is
overgenomen.

Gemeenten zijn zelf ook afnemer. Naast de verstrekking aan buitengemeentelijke afnemers die een wettelijk verankerde toestemming hebben om
GBA persoonsgegevens te gebruiken in hun processen, gebruikt de gemeente
voor haar interne processen GBA gegevens. Voor beide vormen van verstrekking
geldt dat ze vanwege het van kracht worden van het regime van GBA als
basisregistratie door veel meer afnemers benut moeten worden. Vanuit dit
regime vloeit ook voort dat de gemeente niet alleen de eigen GBA moet
benutten voor gegevens over de eigen ingezetenen maar dat de gemeente
wanneer zij met burgers die in andere gemeenten wonen te maken heeft
evenzeer de GBA als authentieke bron moet gebruiken, daarmee zijn de
gemeenten ook afnemer van GBA-V.
Voor al die processen is het wenselijk dat het gebruik van de GBA als
basisregistratie op dezelfde manier plaatsvindt, ongeacht of de betreffende
burger in de eigen gemeente woont of elders. Voor de gebruikers die via de
binnengemeentelijke verstrekking gebruik maken van het GBA-stelsel moet het
transparant zijn of een persoonslijst in het Burgerzakensysteem van de eigen
gemeente aanwezig is of opgehaald wordt uit GBA-V. Transparant, dat wil
zeggen dat ze het verschil tussen beide situaties niet merken en geen extra
handelingen hoeven te verrichten om gegevens uit GBA-V op te halen.
Voorwaarde daarbij is uiteraard dat de betreffende gebruiker geautoriseerd is
om de betreffende gegevens te ontvangen.
ORG 7
(ALG 10)

Gebruikers binnen de gemeente hebben via het gemeentelijke
Burgerzakensysteem een transparante toegang tot GBA-V.

Scenario 1. Omdat de
architectuur van de bestaande
GBA-systemen niet ingericht is
op de benodigde interactie
met GBA-V om in de
transparante toegang te
voorzien is het onzeker of
deze toegang volledig
transparant, direct genoeg en
tegen redelijke kosten te
realiseren is.

Scenario 2. In scenario 2 wordt
middels BZS-K voorzien in de
transparante toegang tot GBAV..

Scenario 3. Omdat de
architectuur van de bestaande
GBA-systemen niet ingericht is
op de benodigde interactie
met GBA-V om in de
transparante toegang te
voorzien is het onzeker of
deze toegang volledig
transparant, direct genoeg en
tegen redelijke kosten te
realiseren is.

In sommige gevallen kan het voor een binnengemeentelijke afnemer
aantrekkelijker zijn om op dezelfde manier als buitengemeentelijke afnemers op
GBA-V aan te sluiten. Deze afnemer wordt dan in feite een buitengemeentelijke
afnemer en staat niet in verbinding met het Burgerzakensysteem van de eigen
gemeente. Op zich vereist dit weer extra aandacht van de bronhouder omdat er
op organisatieniveau (dus de gemeente XYX) één autorisatie wordt verstrekt. In
het geval dat een gemeentelijk organisatieonderdeel een eigen aansluiting
wenst, betekent dat er op dat moment meer dan één organisatieonderdeel van
een gemeente geautoriseerd moet worden.

46

Definitiestudie mGBA Versie 1.8

ORG 8
(BZS-K 3)

De moderne GBA mogelijk gemaakt…

Binnengemeentelijke afnemers kunnen via de transparante toegang van het
gemeentelijke Burgerzakensysteem gebruik maken van GBA-V maar (in bepaalde
gevallen) kunnen zij ook aan de eisen van het gebruik van GBA als basisregistratie
voldoen op basis van een aansluiting "buitenom" op GBA-V (NORA 7.2.1.2)
Scenario 1. In scenario 1 zal
het voor een groter aantal
gemeentelijke afnemers
aantrekkelijk zijn direct op
GBA-V aan te sluiten. Immers
de functionaliteit van GBA-V
wordt spoedig verder
verbeterd terwijl er rond de
transparante toegang via het
eigen Burgerzakensysteem
langer onzekerheid kan
blijven.

Scenario 2. Voor
binnengemeentelijke
afnemers levert de
transparante toegang via BZSK exact dezelfde functionaliteit
als GBA-V met als enige
verschil dat BZS-K intern
binnen de eigen organisatie
toegankelijk is.

Scenario 3. Evenals in scenario
1 zal het voor meer
gemeentelijke afnemers
aantrekkelijk zijn direct op
GBA-V Online aan te sluiten. In
tegenstelling tot scenario 1
kunnen via GBA-V Online
echter geen spontane
mutaties ontvangen worden.
De mogelijkheden van het
“buitenom” afnemen zijn
geringer. In meer gevallen zal
het nodig zijn om zowel
binnengemeentelijk als
buitenom af te nemen.

4.1.3
Indeling van de gegevensopslag
Consequentie van de aanwezigheid van GBA-V is ook dat bepaalde gegevens,
zoals afnemersindicaties en verwijsgegevens niet meer in het gemeentelijke
Burgerzakensysteem hoeven te zitten. Verder maakt een direct toegankelijk
GBA-V een gegevensmodel mogelijk waarbij gegevens die nu redundant worden
opgeslagen in het gemeentelijke Burgerzakensysteem, maar waar een andere
gemeente bronhouder van is, eenmalig op te slaan. In plaats daarvan wordt een
verwijzing naar GBA-V opgenomen. Dit maakt een belangrijke vereenvoudiging
van de gegevensopslag mogelijk die een eind maakt aan het niet actueel zijn van
redundant opgeslagen gegevens (NORA 7.2.2). Dit wordt verder uitgewerkt in
hoofdstuk 6.
ORG 9
(ALG 6)

Omdat de burgerzakensystemen voortdurend in verbinding staan met GBA-V is
het mogelijk per gemeente enkel de gegevens op te slaan waarvan zij bronhouder
is en alle andere gegevens, o.a. die van gerelateerden, bij gebruik in meest actuele
versie op te halen uit GBA-V.

Scenario 1. In scenario 1 wordt
de gegevensmodelwijziging
naar LO4 die voor het
benutten van deze
mogelijkheid nodig is niet
uitgevoerd en wordt deze
mogelijkheid dus niet benut.
Omdat GBA-V wel aanwezig is
kunnen mogelijk processen
worden ingericht die de
kwaliteit van de redundante
gegevensopslag verbeteren
met behulp van GBA-V. Dit is
echter niet uitgewerkt in de
betreffende scenario.

Scenario 2. In scenario 2 wordt
middels BZS-K voorzien in de
transparante toegang tot GBAV en wordt de benodigde
gegevensmodelwijziging
doorgevoerd.

Scenario 3. In scenario 3
wordt beoogd de
gegevensmodel wijziging naar
LO4 door te voeren in het
bestaande systeem.
De hierbij benodigde directe
toegang tot GBA-V vanuit de
burgerzakensystemen zal
door de leveranciers op basis
van de LO procedure moeten
worden gerealiseerd. De
huidige burgerzakensystemen
zijn mogelijk niet ingericht op
een dergelijke afhankelijkheid
van GBA-V.

47

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

De gebruiker merkt bij de uitvoering van het proces niet of de gegevens uit de
eigen lokale GBA of uit de landelijke GBA-V komt, doordat de gegevensservices
uniform zijn beschreven. (NORA 7.2.1.2) en de gegevens zijn altijd te herleiden
tot de bron (NORA 7.2.1.3).

4.1.4
Standaarden ten behoeve van samenwerkende e-overheid
Zowel gemeenten als afnemers zijn onderdeel van de e-overheid. Voor hen is
het van belang dat het GBA-stelsel dezelfde standaarden hanteert als de andere
e-overheidsontwikkelingen. De NORA en daarvan afgeleiden architecturen en
afspraken zijn daarbij het referentiekader.
ORG 10

NORA principes worden toegepast zodanig dat het GBA-stelsel voor gemeenten en
afnemers zo goed mogelijk aansluit op andere ontwikkelingen en standaarden in
de e-overheid.

Een van de belangrijkste pijlers van de overheid is eenmalig uitvragen van
gegevens (NORA fundamenteel principe P8 en 5.3.6, zie paragraaf 5.1) en het
meervoudig gebruik, met als beoogd effect om administratieve lastenverlichting
te kunnen realiseren voor burger en bedrijf. Dit impliceert dat er informatie
uitgewisseld moet worden (NORA 5.3.7 en 6.3.1.1). Het toepassen van de NORA
als referentiekader betekent dat het GBA-stelsel ingericht moet worden als een
stelsel dat diensten levert op basis van een service georiënteerde architectuur
(NORA 5.1.5). Service georiënteerde architectuur betekent een bepaalde manier
20
van het indelen van de diensten, processen en functies . Processen worden
niet uitgevoerd door één applicatie of pakket maar door in een bepaalde
volgorde services toe te passen via een servicebus. Services worden op niveau
van organisatie, proces of ICT-voorziening gedefinieerd. Omdat het toepassen
van een service georiënteerde architectuur grote consequenties heeft die niet
louter technologisch zijn kan dit uitgangspunt als organisatorisch uitgangspunt
gezien worden. Het heeft invloed op de wijze waarop sturing op het GBA-stelsel
en de ontwikkeling er van georganiseerd wordt.
In de praktijk hangt het toepassen van een service georiënteerde architectuur
sterk samen met het gebruiken van de OverheidsServiceBus (OSB), echter een
service georiënteerde architectuur kan niet gereduceerd worden tot het
verzenden van berichten over OSB. Dit wordt uitgewerkt in paragraaf 5.6.
ORG 11

Het GBA-stelsel levert diensten op basis van een service georiënteerde
architectuur. (NORA 5.1.5)

20

Hoofdstuk 5 wordt het concept Service Oriented Architecture nader toegelicht

48

Definitiestudie mGBA Versie 1.8

Scenario 1. Bestaande GBAsystemen zijn niet gebaseerd
op een service georiënteerde
architectuur. Afhankelijk van
de wijze waarop leveranciers
in scenario 1 hun pakketten
aanpassen worden voordelen
van deze architectuur benut.

De moderne GBA mogelijk gemaakt…

Scenario 2. Scenario 2 is in de
definitiestudie 1.3 beschreven
vanuit een consequent
doorgevoerde service
georiënteerde architectuur
(SGA).

Er is geen bijdrage aan
ontstaan van service gerichte
architectuur binnen
gemeenten tenzij de
specificaties die via de LO
procedure aan leveranciers
worden voorgeschreven
worden uitgebreid tot de
binnengemeentelijke kant van
de GBA-systemen en ook voor
dat deel SGA en een (OSB
conforme) servicebus
voorschrijven.

Scenario 3. In scenario 3 geldt
evenals in scenario 1 dat de
mate van toepassing van SGA
geheel afhangt van de
leveranciers en de mate
waarin via de LO procedure
architectuurinrichting kan
worden voorgeschreven. Het
grote verschil met scenario 1
en 2 is dat het huidige GBA
netwerk in stand blijft. Dit past
geheel niet in een SGA en is
geen geschikt uitgangspunt
voor het aansluiten op de SGA
standaarden die eoverheidsbreed zijn gekozen.

In paragraaf 2.2 zijn shared service centra voor gemeenten genoemd als een
belangrijke factor in hun verdere ontwikkeling. Naast technische beperkingen
zijn er momenteel ook juridische beperkingen voor het gezamenlijk gebruik van
een Burgerzakensysteem. Aangenomen mag worden dat het wetsvoorstel
basisregistratie personen (een deel van) deze beperkingen wegneemt. Dit levert
derhalve een duidelijke nieuwe eis op ten opzichte van de definitiestudie 1.3.
ORG 12

Het GBA-stelsel legt geen beperkingen op tegen het door meerdere gemeenten
gezamenlijk beheren van een Burgerzakensysteem, het door één gemeente
beheren van een Burgerzakensysteem waaruit ook dienstverlening voor andere
gemeenten plaatsvindt of het centraal als dienst hosten van BZS-K.

Scenario 1. Deze eis kan in
deze scenario gerealiseerd
worden door de benodigde
eisen op te leggen aan de
leveranciers of doordat
gemeenten zelf de benodigde
eisen aan leveranciers stellen

Scenario 2. Deze eis kan in
scenario 2 gerealiseerd
worden door BZS-K en de
Aanvullende Modules als
zodanig te specificeren en bij
realisatie van BZS-K ook
daadwerkelijk te testen dat
hieraan voldaan wordt.

Scenario 3. Aangezien het
GBA-netwerk ingericht is op
een decentraal systeem kan
deze eis niet gerealiseerd
worden. Het zou wel mogelijk
zijn een Burgerzakensysteem
te realiseren dat intern in
meerdere gemeenten
verdeeld is en naar het GBAstelsel toe zich als meerdere
decentrale systemen gedraagt
en daarmee gemakkelijker
ingezet zou kunnen worden in
een gemeentelijk shared
service centrum dan de
huidige systemen

Het ontstaan van GBA-V maakt dat gemeenten onderling minder afhankelijk van
elkaar zijn. Deze ontwikkeling zou kunnen worden voortgezet door BZS-K
functionaliteit online aan te bieden aan (een deel van) de gemeenten. Een

49

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

dergelijke stap zou ook de mogelijkheden voor plaatsonafhankelijk werken
verder vergroten (NORA 6.1.1.3).

4.2

Diensten en services van de GBA
21

Door te spreken over de diensten die het GBA-stelsel levert aan burgers,
gemeenten en afnemers ontstaat een heel eenvoudige blik op de functionaliteit
van de GBA (NORA 5.2.1.1).
DST 1

Het GBA-stelsel levert de volgende diensten:
•
•
•
•
•
•

Bijhouding door de gemeenten
Systematische verstrekking aan afnemers
Binnengemeentelijke verstrekking
Intergemeentelijke diensten
Overige verstrekkingen
Terugmelden

Figuur 21: Weergave van de
diensten die door het GBA-stelsel
worden geleverd. Deze figuur
wordt gehanteerd als een
vereenvoudiging van figuur 5 in de
oorspronkelijke definitiestudie.

Figuur 22. Globaal overzicht van de diensten en services van het GBA stelsel

21

De NORA hanteert onderscheid tussen de term “dienst” en de term “service”: Een dienst
wordt door de overheid geleverd aan burgers of bedrijven, een service wordt binnen de
overheid geleverd aan een ander onderdeel van de overheid. Diensten kunnen dus onder
de motorkap geleverd worden op basis van services. Omdat het GBA-stelsel zowel aan
burgers diensten levert als services voor andere overheden is dit onderscheid in deze
context tekstueel verwarrend. In dit hoofdstuk wordt daarom consequent over diensten
gesproken (conform de oorspronkelijke definitiestudie) en ten tweede consequent over een
servicebus. De bus die het betreft is namelijk onderdeel van de wijze waarop binnen de
overheid services aan elkaar verleend worden. In hoofdstuk 5 Architectuur wordt het
onderscheid in termen wel zuiver conform de NORA gehanteerd.

50

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Een dienst is het resultaat of effect van een afgeronde inspanning die de
overheid op basis van wettelijke taken levert en waarmee in een behoefte van
de burger of bedrijf wordt voorzien. Een service is het resultaat van een
afgeronde inspanning die een overheidsorganisatie levert. Vanuit het
gezichtspunt van de burger en bedrijf vormt de ‘overheid’ één geheel. Een
aaneenschakeling van services van meerdere organisaties kunnen leiden tot één
dienst (NORA 5.2.2.1, 5.2.2.3 en 6.1.1.3).
De beschrijving in diensten levert op zich geen verandering op ten opzichte van
de huidige situatie. Deze kan net zo goed in termen van diensten beschreven
worden. In deze definitiestudie wordt conform de NORA over diensten (en
services) gesproken omdat dit een eenvoudige beschrijving oplevert op basis
waarvan beslissingen over de inrichting beschreven kunnen worden. Ten
tweede maakt het duidelijk welke diensten een gemoderniseerd GBA-stelsel kan
leveren die momenteel niet voorzien zijn.

Figuur 23: Het dienstenaanbod aan afnemers blijft in grote lijnen gelijk.

4.2.1
Diensten worden geleverd op basis van een servicebus
Op grond van afspraken in NORA en NUP [2][1] worden de services geleverd op
basis van servicebustechnologie (NORA 6.1.1.4, 6.1.1.8). Deze technologie
betekent dat de diensten gestandaardiseerde koppelvlakken hebben en
opgebouwd zijn uit services die ook gestandaardiseerde koppelvlakken hebben.
Deze gestandaardiseerde koppelvlakken op meerdere niveaus maken het
eenvoudiger om diensten aan te passen en nieuwe services te realiseren. Dit
draagt bij aan de doelstelling van flexibiliteit door het gehele stelsel heen en
levert dus een belangrijke bijdrage aan de oorspronkelijke Snellen doelstellingen
(zie 2.1.2). Omdat zowel de gemeenten als de afnemers intern ook voor andere
toepassingen dezelfde servicebustechnologie gebruiken is samenwerking met
andere toepassingen en het leveren van geïntegreerde dienstverlening mogelijk.
De OverheidsServiceBus (OSB) levert de specificaties die deze samenwerking
mogelijk maken (zie 5.6 en [13]).
DST 2

Diensten en services worden geleverd op basis van een service georiënteerde
architectuur waarbij het inzetten van een servicebus centraal staat in de
ontwerpfilosofie (uitwerking van ORG 11)

51

Definitiestudie mGBA Versie 1.8

Scenario 1. De service
georiënteerde architectuur
wordt enkel volledig
gerealiseerd tussen GBA-V en
de afnemers.
Er zijn verschillende
burgerzaken- systemen.

De moderne GBA mogelijk gemaakt…

Scenario 2. Deze eis wordt
volledig gerealiseerd.
Alleen in deze scenario is
sprake van één geheel op
basis van service
georiënteerde architectuur.

Scenario 3. Deze eis wordt niet
gerealiseerd. Het huidige GBAnetwerk is niet geschikt en is
niet vergelijkbaar met of
eenvoudig om te vormen in
een servicebus.

Losstaande systemen
betekent ook dat
binnengemeentelijke
verstrekking van de gegevens
over eigen inwoners niet op
dezelfde wijze gebeurt als
verstrekking uit GBA-V.

Figuur 24: Het GBA-stelsel weergegeven in de NORA overzichtsplaat waarin de
servicebus als ontkoppelvlak tussen de onderdelen is weergegeven.
In de NORA wordt dit weergegeven als in Figuur 24 (NORA 6.4.1, 6.4.2 en 6.4.3).
De gehele hoefijzer wordt daar niet voor niets aangeduid als “servicebussen”.
Dat wil zeggen dat de verschillende onderdelen van de overheid conform de
NORA samenwerken door voor hun onderlinge berichtenverkeer dezelfde
specificaties te gebruiken, namelijk de OSB specificaties. Er zijn drie
verschillende servicebussen te onderscheiden: binnen de gemeente, tussen
gemeenten onderling en de gemeente en GBA-V en ten derde tussen GBA-V en
de afnemers. Deze laatste twee zijn weergegeven in figuur Figuur 24.
In het GBA-stelsel is sprake van meerdere servicebussen conform de
verandering in het berichtenverkeer die beschreven is in paragraaf 4.1.
Onderstaande figuur (naar figuur 3 in definitiestudie 1.3 [9]) geeft de
verschillende servicebussen weer.

52

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Figuur 25: Opdeling in intergemeentelijke en afnemers servicebus

4.3

GBA-V en andere landelijke voorzieningen in het GBA-stelsel

Na de beschrijving van organisatie en diensten in de voorgaande paragrafen
wordt nu ieder van de onderdelen van het GBA-stelsel verder uitgewerkt in
termen van functionaliteit. Eerst worden de landelijke voorzieningen behandeld,
vervolgens de gemeentelijke voorzieningen, het berichtenverkeer en de
kwaliteitscontroles. Tenslotte worden de relaties met de BAG en de RNI
weergegeven.

4.3.1
Opbouw van GBA-V
In essentie is GBA-V niet meer dan een centraal systeem met een database en
aantal bijbehorende modules voor het verwerken van mutatiemeldingen op de
gegevens en voor de verstrekking van gegevens. De gegevens in de database
zijn een kopie van de gegevens in de verschillende gemeentelijke
Burgerzakensystemen. De bijhoudingsprocedures zijn wel anders dan die in
deze Burgerzakensystemen: waar de decentrale services er op gericht zijn om
een foutvrije bijhouding van de GBA-gegevens mogelijk te maken zijn de
bijhoudingsservices in GBA-V er op gericht om zo effectief mogelijk een
getrouwe kopie van een persoonslijst (PL) in GBA-V op te nemen.
Het eerste deel van GBA-V is inmiddels gerealiseerd. Om onderscheid te maken
tussen de verschillende generaties die GBA-V in het veranderproces doorloopt
wordt de onderstaande aanduiding gehanteerd:
•

LO3 Ad hoc service. Aanduiding voor momenteel gerealiseerde services
van GBA-V Online die enkel de ad hoc bevragingen omvatten. De
berichtinhoud is gespecificeerd in LO3.6 (C.1.3 in [8]).

•

LO3 services: volledige systematische verstrekking, c.q. de
functionaliteit als beschreven in paragraaf 4.3.2 op basis van het
huidige LO3 gegevensmodel.

53

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

•

LRD services: leveren dezelfde gegevens als de LO3 Ad hoc service,
echter conform het koppelvlak van de LRD. Door deze services vanuit
GBA-V te leveren kan de LRD als voorziening worden uitgefaseerd
zonder gevolgen voor de LRD afnemers. Deze uitfasering is inmiddels
vrijwel afgerond.

•

LO4 services: volledige systematische verstrekkingen, dus functioneel
gelijk aan de LO3 services, maar gebaseerd op het LO4 gegevensmodel
en nieuwe berichtinhouden.

•

Daarnaast voorziet GBA-V in services voor de interactie met de
gemeentelijke Burgerzakensystemen. In GBA-V Online omdat dit enkel
de synchronisatieservice. Dit is de service die de mutatiemeldingen
vanuit de gemeenten verwerkt in de kopie PL binnen GBA-V. Wanneer
ook het intergemeentelijke berichtenverkeer via Moderne Interfaces
gaat lopen komen de betreffende services daarbij en bij invoering van
een BZS-K komt de hersynchronisatieservice erbij.

Verder omvat de landelijke voorziening de TerugMeldVoorziening (TMV, NORA
6.2.6.4). Deze ontvangt terugmeldingen van afnemers en verzendt deze
vervolgens naar de gemeente die bronhouder is van de betreffende gegevens.
Daarna registreert de TMV de verschillende stadia van verwerking van de
terugmelding.
Om te voorkomen dat alle gemeenten of alle afnemers tegelijk veranderingen
moeten doorvoeren is voor de migratie voorzien in conversiefunctionaliteit die
als onderdeel van GBA-V geleverd wordt.
GBA-V per scenario:
Scenario 1. LO4 services
worden niet gerealiseerd.
Nader te bepalen is welke
andere, niet aan het LO4
gegevensmodel gebonden,
wijzigingen in berichtinhoud in
welk stadium worden
doorgevoerd.

Scenario 2. Nadat alle
afnemers zijn gemigreerd zijn
de LO3 (en de LRD) services
uitgefaseerd en blijven enkel
LO4 services over.

Scenario 3. Enkel de huidige
LO3 Ad hoc services is
gerealiseerd.

4.3.2
Systematische verstrekking aan afnemers uit GBA-V (3.3.2)
GBA-V neemt de taak van systematische verstrekking over van de
burgerzakensystemen. De verschillende typen systematische verstrekking zijn
weergegeven in Figuur 26 en worden in de volgende paragrafen behandeld. De
functionaliteit voor afnemers blijft echter grotendeels dezelfde. De uitbreiding
van de huidige GBA-V Online naar de hier beschreven volledige functionaliteit
van GBA-V is onderdeel van de oplossingscomponent Full Service (NORA 7.3.3)
beschreven in paragraaf 3.3.1.

54

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Figuur 26: Verdere detaillering van de diensten voor landelijke voorzieningen
Ad hoc vragen
Afnemers kunnen nu al gebruik maken van de LO3 Ad hoc service voor het
22
stellen van Ad hoc vragen en Ad hoc adresvragen (dit is GBA-V Online) .
GEG 1
(GBA-V 6)

GBA-V online biedt aan daarvoor geautoriseerde afnemers toegang tot de
volledige set van gegevens op een PL, inclusief de historie. Welke gegevens een
afnemer krijgt en over welke categorieën van personen wordt bepaald door de
autorisatie van de afnemer.
De huidige GBA-V Ad hoc service dient nog op enkele punten te worden
aangepast om te voldoen aan de gewenste eindsituatie
•
•
•

De services voldoen nog niet aan de OSB specificatie
Diverse beperkingen t.a.v. autorisaties die verbonden zijn met huidige
situatie
Het transportnetwerk waarlangs de Online Services bereikbaar zijn

22

In de huidige situatie zijn er dus twee manieren van het stellen van een Ad hoc vraag, via
het “oude” GBA netwerk en via GBA-V Online.

55

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Spontane mutaties
Spontane mutaties zijn bedoeld om afnemers in staat te stellen hun eigen kopie
van de persoonsgegevens waarvoor ze geautoriseerd te zijn bij te werken op
basis van de gebeurtenissen die in de GBA worden vastgelegd.
Het verzenden van de spontane mutaties uit GBA-V wordt geïnitieerd door
bijhoudingsproces waarin de mutatiemeldingen vanuit de gemeentelijke
Burgerzakensystemen worden verwerkt. Direct na verwerking worden de
spontane mutaties aan afnemers gepubliceerd (NORA 6.2.6.3).

Figuur 27: Belangrijkste stappen in het proces van het doorgeven van een
gebeurtenis die bij gemeente wordt geregistreerd aan een afnemer

PRC1

Meldingen worden verstuurd op het moment dat ze beschikbaar zijn

(GBA-V 5)

Ten behoeve van het ontvangen van spontane mutaties is daarnaast voorzien in
de volgende services (die onderdeel zijn van de LO3 services respectievelijk de
LO4 services).
•
•
•
DST 3
(GBA-V 3)

Een service voor het plaatsen en verwijderen afnemersindicaties
Een service voor het specificeren van de gewenste spontane mutaties
en eventuele verzorgingsgebieden
Een service voor hersynchronisatie

Afnemers krijgen de mogelijkheid om te hersynchroniseren met GBA-V

Scenario 1.

Scenario 2.

Scenario 3. In tegenstelling tot
beide andere scenario’s kan
deze hersynchronisatie niet
worden gerealiseerd voor de
systemen van afnemers die
vanuit de gemeenten voorzien
worden van spontane
mutaties en selecties.

Ook als afnemers niet geautoriseerd zijn voor ad-hoc vragen kunnen ze een
verzoek indienen om de gegevens van een persoon opnieuw te leveren; er
wordt dan niet gekeken naar voorwaardenregels maar alleen of de afnemer
inderdaad een indicatie op de desbetreffende PL heeft geplaatst. Afnemers

56

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

doen dat in de huidige opzet zo nu en dan al door hun afnemersindicatie te
verwijderen en daarna opnieuw te plaatsen.
De doelgroep van de afnemers kan worden ingeperkt door middel van een
voorwaardenregel. Per afnemer en per soort verstrekking kan de gegevensset
worden aangegeven (de huidige “kruisjestabellen”).
De functionaliteit van de voorwaardenregel wordt aangepast aan de nieuwe
gegevensset (hoofdstuk 6) en de syntax wordt gemoderniseerd zodat hij
eenvoudiger te implementeren is. De huidige syntax dateert uit de periode dat
er nog geen standaarden beschikbaar waren en diende bovendien te voldoen
aan de voorwaarde dat hij platform onafhankelijk was. In de nieuwe opzet
hoeven de regels alleen geïmplementeerd te worden in GBA-V en vervalt dus de
eis van platformonafhankelijkheid.
Selecties
Selecties leveren aan afnemers alle persoons- of adresgegevens die aan
bepaalde karakteristieken voldoen mits de betreffende afnemer geautoriseerd
is voor de ontvangst daarvan.
DST 4
(GBA-V 9)

UIT 1
(GBA-V 10)

Selecties worden in de nieuwe opzet uitgevoerd door GBA-V. De resultaten van de
selectie worden altijd vastgelegd in een bestand. Dit bestand kan worden
afgeleverd via het netwerk of via een alternatief medium.
Het bestandsformaat voor selecties wordt gebaseerd op XML en zal dus afwijken
van het bestaande GBA uitwisselingsformaat

Afhandeling door GBA-V heeft voor de afnemers het voordeel dat ze nog slechts
één bestand ontvangen in plaats van een bestand van iedere afzonderlijke
gemeente. Door de selectie altijd op te leveren als bestand wordt de
afhandeling van de selectie zowel binnen GBA-V als bij de afnemer vrijwel
onafhankelijk van het medium dat wordt gebruikt voor de levering.
Berichtinhoud
Hoewel de functionaliteit in grote lijnen ongewijzigd blijft zal de berichtinhoud
veranderen. Dit geldt voor alle vormen van systematische verstrekkingen (NORA
6.3.1.2). Uit performance overwegingen zijn de huidige berichtinhouden zo
zuinig mogelijk: enkel van gewijzigde gegevens wordt de oude en nieuwe versie
getoond. In de toekomst is het gewenst alle (actuele) gegevens van de PL waar
de betreffende afnemer voor geautoriseerd is in het bericht te verzenden.
GEG 2
(GBA-V 2)

Afnemers krijgen bij iedere verstrekking vanuit GBA-V alle gegevens waar ze recht
op hebben, en niet alleen de gewijzigde gegevens in oud/nieuw formaat.

In de huidige situatie kunnen er onopgemerkte fouten ontstaan als er een
wijziging verloren gaat; in de nieuwe opzet wordt dit bij een volgende
verstrekking gecorrigeerd.

57

Definitiestudie mGBA Versie 1.8

Scenario 1. De wijziging van de
berichtinhoud was
oorspronkelijke gekoppeld aan
de gegevensmodel wijziging
naar LO4 maar kan ook los
daarvan worden uitgevoerd,
dat vereist wel nadere
ontwerpwerkzaamheden.
Derhalve is het wijzigen van de
berichtinhoud in 3.3.2 als
afzonderlijk onderdeel
genoemd.

De moderne GBA mogelijk gemaakt…

Scenario 2. De wijziging van de
berichtinhoud is hier
gekoppeld aan invoering LO4.
Dit is een aanname, op grond
van de stukken is onduidelijk
in welke oplossingscomponent
de wijzigingen aan de
berichtinhoud die niet aan LO4
gegevensmodel gerelateerd
zijn gepland zijn, zoals eis
GEG2.

Scenario 3. De wijziging van de
berichtinhoud kan hier
gekoppeld worden aan de
invoering van LO4. Mogelijk
dienen daarvoor beperkingen
binnen het GBA-netwerk te
worden opgelost en mogelijk
dienen de VOA’s te worden
aangepast.

De volledig service
geörienteerde architectuur
maakt nadat LO4 geheel is
ingevoerd het splitsen van
doorgeven van gebeurtenissen
en berichtinhoud mogelijk. Dit
is voor de langere termijn het
gewenste model voor het
stelsel van basisregistraties.

Gevolgen voor autorisatie, afnemersindicaties en protocollering
Het GBA Stelsel hanteert een strikt regime voor autorisaties en transparantie
van de verstrekkingen. Dit regime is gebaseerd op de GBA wet en dient om het
evenwicht tussen efficiënt gebruik en privacy te handhaven en transparant te
maken. Voor de uitvoering van dit regime voorziet het GBA stelsel in enkele
specifieke diensten:
•

Autoriseren afnemer

•

Plaatsen afnemerindicaties

•

Inzage protocolleringsgegevens

Voordat een afnemer aangesloten wordt dient deze de autorisatieprocedure te
doorlopen (NORA 9.4.1 t/m 9.4.7). Hierbij wordt gecontroleerd of de afnemer
op grond van de wet en regelgeving GBA gegevens mag ontvangen en zo ja
welke GBA gegevens. In zogeheten autorisatietabelregels wordt vastgelegd
welke gegevens (groepen, rubrieken etc. zie hoofdstuk 6) per afnemer verstrekt
mogen worden. Deze autorisatietabelregels zijn aanwezig in alle
Burgerzakensystemen en in GBA-V.
De doelbinding omvat niet alleen een beperking in de soort gegevens die een
afnemer mag ontvangen maar ook in de eis dat alleen gegevens mogen worden
verstrekt over personen waar de afnemer daadwerkelijk op basis van de wet
recht op heeft. Dat betekent dat op iedere PL vastgelegd wordt welke afnemers
mutaties mogen ontvangen van de gegevens over de betreffende persoon, dit
zijn de afnemersindicaties. Momenteel worden de afnemersindicatie in GBA-V
niet gebruikt. Het beantwoorden van Ad hoc vragen vindt namelijk plaats
ongeacht de afnemersindicaties. Bij het overgaan van de systematische
verstrekking naar GBA-V zullen de afnemersindicaties alleen nog in GBA-V van
belang zijn
PRC 2
(GBA-V 7)

Afnemersindicaties kunnen in de huidige GBA worden gezet door een verzoek van
de afnemer, door middel van een sleutelrubriek of door middel van een selectie.
Deze methoden blijven ook in de nieuwe opzet gehandhaafd.

58

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

De derde specifieke GBA dienst is de inzage protocolleringsgegevens.
Protocollering betekent dat niet alleen in de autorisatietabel en de
afnemersindicaties vast ligt welke afnemers welke persoonsgegevens over
welke persoon mogen ontvangen maar dat daarnaast ook iedere daadwerkelijke
verstrekking geregistreerd wordt. Dit wordt een bepaalde periode (1 jaar)
bewaard. Er ligt niet enkel vast welke afnemers potentieel de gegevens mogen
ontvangen, daarnaast heeft de burger het recht achteraf te vernemen aan
welke afnemers in de afgelopen periode zijn gegevens daadwerkelijk verstrekt
zijn. Momenteel liggen deze gegevens vast in de Burgerzakensystemen, zie
Logisch Ontwerp 3.6, paragraaf 4.2. Wanneer de systematische verstrekking
naar GBA-V verhuist dan wordt dit enkel nog in GBA-V vastgelegd. De gemeente
moet dan bij een verzoek om inzage in de protocolleringsgegevens de
betreffende gegevens uit GBA-V op te vragen.
Indicatie op adres en het definiëren van verzorgingsgebieden
De huidige GBA kent slechts beperkte mogelijkheden om een verzorgingsgebied
te definiëren. Toch zijn er afnemers die slechts in een beperkt gebied werkzaam
zijn (waterschappen en entadministraties bijvoorbeeld). Waar mogelijk wordt bij
deze afnemers de doelgroep ingeperkt door het opnemen van postcodes of
gemeentecodes in de voorwaardenregel van de afnemerstabel. Deze oplossing
kent echter beperkingen: het aantal codes dat in een voorwaardenregel kan
worden opgenomen is gelimiteerd en verzorgingsgebieden van afnemers vallen
niet altijd samen met de gemeentegrenzen.
Daarnaast kent de GBA de mogelijkheid om een afnemersindicatie op adres te
plaatsen. Een afnemer die daarvoor bevoegd is krijgt dan een bericht op het
moment dat zich iemand op dat adres vestigt. Dit mechanisme werkt echter
slechts voor één adres tegelijk.
PRC 3
(GBA-V 8)

In de nieuwe opzet kan er per afnemer een verzorgingsgebied worden
23
gespecificeerd door middel van een afnemerslocatie tabel . Deze functie
vervangt de indicatie op adres.
De specificatie bestaat uit één of meer postcode bereiken die tot het
verzorgingsgebied behoren, en eventueel een aantal postcode bereiken die juist
moeten worden uitgezonderd. Zodra een persoon zich vestigt in het gebied dat
op deze manier is gedefinieerd wordt er automatisch een afnemersindicatie op
de PL geplaatst. Het mechanisme werkt dus ongeveer zoals de sleutelrubrieken.
Voordeel van deze opzet is dat de verzorgingsgebieden zeer nauwkeurig kunnen
worden gedefinieerd, en dat het beheer van de tabel voor het
verzorgingsgebied bij de afnemer gelegd kan worden. De autorisatietabel regels
kunnen in een aantal gevallen worden vereenvoudigd en het afzonderlijke
mechanisme voor een indicatie op adres kan vervallen.

23

Dit voorstel is nog in bespreking met de betrokken afnemers. Als er geen
overeenstemming over wordt bereikt wordt het bestaande mechanisme gehandhaafd.

59

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

4.3.3
Beheerfunctionaliteit in GBA-V
De huidige versie GBA-V Online voorziet slechts beperkt in functionaliteit voor
het beheer van het systeem. Met de komst van GBA Full Service is het nodig de
beheerfunctionaliteit uit te breiden. De huidige losstaande beheerfuncties
dienen te worden opgenomen in een samenhangende beheerapplicatie waarin
de benodigde functionaliteit per werkproces is gegroepeerd. Het resultaat moet
zijn dat enkel voor technisch beheer nog handmatige handelingen (command
line, JMX console e.d.) blijven bestaan en dat al het andere beheer gedaan kan
worden vanuit de beheerapplicatie. Dit dient er toe bij te dragen dat
beheertaken efficiënter kunnen plaatsvinden.
De beheerapplicatie omvat de volgende onderdelen:
 XB beheer in het algemeen
 FB monitoring, starten en stoppen van de applicatie
 RP rapportages
 AF beheer van afnemers
 SB beheer rondom selecties
 GB beheer van de gegevens in GBA-V en de afhandeling van uitvalberichten
en foutberichten
 AM Alternatieve media
Verder dient de beheerfunctionaliteit te voorzien in:
• Een nieuwe user interface gericht op efficiënter werkwijze
• Meer mogelijkheden om te zoeken in berichten
• Koppelen van issues die binnen de beheerfunctionaliteit worden gemeld
aan de incidentmanagementapplicatie van BPR
• Werkvoorraad en toewijzing van afhandeling van issues
• Functiescheiding en autorisatie per gebruikersgroep
• Audittrail ten aanzien van de beheerhandelingen
• Helpfunctionaliteit c.q. documentatie
Deze eisen en wensen zijn nader uitgewerkt in de inceptionfase voor GBA-V Full
Service.

4.4

De Burgerzakensystemen

De Burgerzakensystemen worden gebruikt voor het bijhouden van het GBA op
basis van aangiften van burgers. De workflow voor deze processen is onderdeel
van een brede palet aan Burgerzakendiensten. Als onderdeel van het GBAstelsel voorzien deze systemen in het verzenden van de voorgeschreven
berichten naar het stelsel en het verwerken van de ontvangen berichten.

60

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Figuur 28: Uitdetaillering van de services van een burgerzakensysteem.
Een burgerzakensysteem omvat in de toekomst in ieder geval de volgende
voorzieningen:
•

•
•
•
•

•

Diensten voor bijhouding inclusief de benodigde vraagberichten aan
GBA-V, BV BSN (presentievraag) en andere gemeenten
(intergemeentelijk berichtenverkeer) en de processen voor het
afhandelen van complete berichtcycli.
Diensten voor de inzage en incidentele verstrekking zoals uittreksels uit
GBA.
Verzenden van mutatiemeldingen aan GBA-V en hersynchronisatie
Verwerken van terugmeldingen inclusief doorgeven van
statusinformatie aan de TMV
Voorzieningen voor het aansluiten van binnengemeentelijke afnemers
inclusief benodigde aansluiting op GBA-V voor het verstrekken van
gegevens over burgers uit andere gemeenten (die voldoen aan de eisen
voor transparante toegang, zie ORG7).
Een BAG koppeling om adresaanduidingen conform stelsel van
basisregistraties vast te leggen.

4.4.1
Bijhoudingen (3.3.1)
De bijhouding van GBA gegevens vindt plaats met burgerzakensystemen. Deze
voorzien in een lokale gegevensopslag.
Als onderdeel van iedere bijhouding in het Burgerzakensysteem wordt een
mutatiemelding naar GBA-V verzonden zodat ook de landelijke kopie in GBA-V
bijgewerkt kan worden. Alleen wanneer direct na, of beter nog als onderdeel
van het proces waarin de bijhouding bij de gemeente plaats vindt de
mutatiemelding aan GBA-V wordt verzonden is er sprake van een real time
verwerken van de mutaties in GBA-V. Samen met de eis dat meldingen
verstuurd worden op het moment dat ze beschikbaar zijn (PRC1) leidt dit tot

61

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

een volledig real time werkend GBA-stelsel conform de oorspronkelijke
doelstelling (zie 2.1.2).
PRC4
(ALG 11)

Iedere wijziging in de GBA-gegevens leidt direct tot een mutatiemelding aan GBAV (uitwerking van ORG2).

In scenario 1 is het mogelijk de
(bijna) real time verzending
van de mutatiemelding te
garanderen mits de GBAsystemen van leveranciers niet
enkel aansluiten op de OSB
maar ook samen kunnen
werken met de services voor
procesregie die bovenop de
OSB benodigd zijn.

In scenario 2 is de verzending
van dit bericht onderdeel van
dezelfde transactie en vindt de
verwerking in GBA-V (bijna)
real time plaats. BZS-K en
GBA-V maken op dezelfde
manier gebruik van de
benodigde services voor
procesregie.

In scenario 3 wordt dit bericht
conform de huidige situatie via
het GBA-netwerk verzonden
en is het GBA netwerk de
beperkend factor in het
reduceren van de
tijdsvertraging. Reductie van
tijdsvertraging van 24u naar 1
uur wordt mogelijk geacht,
real time werken niet.

Deze mutatiemeldingen wijken in twee opzichten af van de huidige spontane
mutaties.
GEG 3
(ALG 12)

Bijhoudingsberichten en mutatiemeldingen bevatten de gehele PL (actueel en
historisch), in plaats van slechts een opsomming van de gewijzigde gegevens.

De regels die gelden voor spontane mutaties (zie 4.3.2) richting afnemers,
gelden dus ook voor het berichtenverkeer van de decentrale systemen naar
GBA-V. Dat is voor de hand liggend omdat GBA-V niet kan leveren wat het niet
ontvangt.
GBA-V zal ook de mogelijkheid krijgen om zelf gegevens op te vragen bij het
Burgerzakensysteem en op die manier de eigen gegevens te hersynchroniseren
met de leidende gegevens in het Burgerzakensysteem.
Daarnaast zullen er automatisch steekproefsgewijs controles worden uitgevoerd
om een maat te krijgen hoe betrouwbaar de kopie in GBA-V is ten opzichte van
de bronbestanden in de BZS-K-systemen. Binnen BZS-K en GBA-V zal per PL een
vingerafdruk (hash waarde) worden bepaald die een snelle en efficiënte
vergelijking van gegevens mogelijk maakt.
DST 5
(ALG 42)

De interactie tussen Burgerzakensystemen en GBA-V voorziet in een middel voor
hersynchronisatie om verschillen die onverhoopt toch ontstaan tussen
Burgerzakensystemen en GBA-V op te lossen.
Scenario 1. Nader onderzoek
nodig. Aangezien sprake is van
losstaande systemen dienen
de burgerzakensystemen ook
losstaande uitwijk- en backupvoorzieningen te kennen.

Scenario 2. Hersynchronisatie
is een service die volgt uit de
scenario waarbij BZS-K en
GBA-V als een geheel
opereren. Mocht een BZS-K
systeem uitvallen dan kan het
geheel opnieuw gevuld
worden middels een
hersynchronisatie vanuit GBAV.

Scenario 3. Nader onderzoek
nodig. Aangezien sprake is van
losstaande systemen dienen
de burgerzakensystemen ook
losstaande uitwijk- en backupvoorzieningen te kennen.

62

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

4.4.2
Binnengemeentelijke gegevensverstrekking (3.4)
De binnengemeentelijke gegevensverstrekking wordt veel belangrijker vanwege
het gebruik van de GBA als basisregistratie; daarnaast hebben wijzigingen aan
de Burgerzakensystemen gevolgen voor dat de binnengemeentelijke
gegevensverstrekking.
Bij de binnengemeentelijke gegevensverstrekking bestaat onderscheid tussen
bevragingen en spontane verstrekkingen (zie voor selecties 4.3.2).

4.4.3
Bevragingen (3.4.1)
De volgende uitgangspunten worden gehanteerd voor bevragingen:
•

•

•

•

SEC 1
(BZS-K 3)

Bevragingen worden in beginsel transparant afgehandeld door BZS-K.
BZS-K bevraagt in het algemeen eerst de eigen gegevensverzameling;
als dat niet de gewenste antwoorden oplevert wordt een vervolgvraag
gesteld aan GBA-V. Middels parametrisering kan de reikwijdte van een
vraag worden beperkt tot de eigen gegevensverzameling (zie ORG 7).
Er kan onderscheid worden gemaakt tussen vragen waar een exacte en
unieke match wordt verlangd en situaties waarin “slim zoeken”
gewenst is. De precieze functionaliteit van “slim zoeken” zal worden
24
bepaald bij het opstellen van de functionele specificaties.
De toegang tot de bevraging wordt geregeld via de gemeentelijke
autorisatiemodule. Er wordt dus geautoriseerd op het niveau van
diensten. De gemeente bepaalt daarmee wie of welke afdeling toegang
heeft tot de GBA-gegevens.
Er zijn geen voorwaardenregels of “kruisjes tabellen” waarmee de
reikwijdte van een vraag kan worden ingeperkt. De dienst die wordt
aangevraagd bepaalt welke gegevens nodig zijn en bepaalt daarmee
impliciet voorwaarden en omvang van het gegevenspakket.
Binnengemeentelijk is ook geen sprake van afnemersindicaties.

BZS-K schermt de toegang voor binnengemeentelijke gebruikers tot de
gemeentelijke database af en past voor transparante bevragingen van GBA-V
autorisaties toe. Daarmee wordt ook binnengemeentelijke verstrekking
geformaliseerd (NORA 9.4.5 en 9.4.6).
Scenario 1. Het toepassen van
autorisaties voor
binnengemeentelijk gebruik is
een aspect dat nu niet in het
LO voorgeschreven wordt.
Aanname is dat deze eis in
scenario 1 niet
geïmplementeerd wordt.

24

Scenario 2. Doordat er een
uniform Burgerzakensysteem
is de afscherming van de
gegevensverzameling
verzekerd en kan toepassing
van autorisaties afgedwongen
worden

Scenario 3. Het toepassen van
autorisaties voor
binnengemeentelijk gebruik is
een aspect dat nu niet in het
LO voorgeschreven wordt. Het
transparant bevragen van
GBA-V via Burgerzakensysteem vereist een
herontwerp, bij de huidige

De BV BSN kent nu al een fonetische zoekmogelijkheid

63

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

systemen gebeurt dit
“buitenom” via een separate
aansluiting op GBA-V (GABA
autorisatie).

4.4.4
Spontane verstrekkingen (3.4.2)
Er zijn gemeenten die een Kernregistratie of een soortgelijke constructie
hanteren voor hun interne informatievoorziening (zie Figuur 37). De GBAgegevens zijn daarin opgenomen samen met gegevens uit andere gemeentelijke
administraties en uit landelijke basisregistraties. Er zijn twee manieren om dit
soort systeem aan te passen aan de nieuwe architectuur van de GBA:
•

•

De GBA-gegevens worden uit de Kernregistratie verwijderd. Op het
moment dat de GBA-gegevens nodig zijn worden ze middels de
servicebus rechtstreeks geraadpleegd in het Burgerzakensysteem of
(via de transparante bevraging, zie ORG7 en SEC1) GBA-V.
In de Kernregistratie wordt een kopie van de relevante GBA-gegevens
opgenomen. Middels het mechanisme van de spontane verstrekkingen
wordt er voor gezorgd dat deze gegevens actueel worden gehouden op
dezelfde manier als buitengemeentelijke afnemers dit doen voor hun
sectorale registraties.

Het is goed denkbaar dat de tweede manier eenvoudiger te realiseren is. Daar
bestaan geen principiële bezwaren tegen, mits er gebruik wordt gemaakt van
een systeem van spontane mutaties om de kopie actueel te houden.
PRC 5
(BZS-K 4)

Voor die gevallen waarin de toegang tot de GBA via het Burgerzakensysteem niet
voldoet krijgen de gemeenten de mogelijkheid om spontane verstrekkingen te
ontvangen.
Scenario 1. De aansluiting van
binnengemeentelijke
systemen is een zaak van de
marktpartijen

Scenario 2. BZS-K dient in deze
eis te voorzien maar doet dat
in zodanige samenwerking
met GBA-V dat gegarandeerd
is dat de mutatiemelding eerst
in GBA-V is verwerkt voordat
de spontane verstrekkingen
plaatsvinden.

Scenario 3. De aansluiting van
binnengemeentelijke
systemen is een zaak van de
marktpartijen

De volgorde waarin mutatiemeldingen en spontane mutaties naar
binnengemeentelijke afnemers verwerkt worden is van belang. Voorkomen
moet worden dat een binnengemeentelijke afnemer een mutatie ontvangt die
niet in GBA-V verwerkt is. In een service georiënteerde architectuur kan hierin
voorzien worden door de procesregie op de berichtenstroom goed in te regelen.
In de oorspronkelijke definitiestudie is vermeld dat naast dit mechanisme van
spontane verstrekkingen ook directere doorgifte van mutaties aan
gemeentelijke afnemers gerealiseerd moet worden. Dit lijkt dubbelop en
beperkt de uniforme toepassing van de boven voorgestelde autorisaties.

64

Definitiestudie mGBA Versie 1.8

4.4.5

De moderne GBA mogelijk gemaakt…

BZS-K en de gemeentelijke servicebus (3.1.1)
Deze paragraaf beschrijft
zaken die enkel in scenario 2
gerealiseerd worden.

APP1
(BZS-K 1)

Gemeenten maken in het nieuwe stelsel verplicht gebruik van BZS-K.

BZS-K bestaat uit een database waarin de persoonslijsten van de gemeente
worden opgeslagen en een serie services voor het opvoeren, bijhouden en
raadplegen van een persoonslijst (PL). De technische opzet van BZS-K vertoont
in een service geörienteerde architectuur overeenkomsten met die van GBA-V,
waar mogelijk is dezelfde architectuur gehanteerd (zie Hoofdstuk 5).
BZS-K omvat alleen dat gedeelte van een Burgerzakensysteem dat noodzakelijk
is om een consistente werking van het GBA-stelsel als een geheel op basis van
een service georiënteerde architectuur mogelijk te maken. BZS-K levert enkel de
basisservices en heeft geen gebruikersinterface. De Aanvullende Modules
vormen de gebruikersinterface.
APP2

Gemeenten zijn zelf verantwoordelijk voor de aanschaf en het beheer van
Aanvullende Modules. Afgezien van het koppelvlak met BZS-K hoeven deze niet
uniform te zijn.

APP3

Aanvullende Modules moeten optimaal aansluiten bij de verdere gemeentelijke
ICT.
Eén van die Aanvullende Modules zal de applicatie voor Burgerzaken en de
Burgerlijke stand zijn. BZS-K levert als het ware de motor en het chassis voor
deze applicatie; om er een compleet vervoermiddel van te maken zal er een
carrosserie en een dashboard voor de bediening moeten worden toegevoegd.
Die term is dus in zoverre misleidend dat een gemeente niet zonder kan.

DST 6

BZS-K levert enkel basisservices en heeft geen gebruikersinterface. Als criterium
voor wat tot de basisservices behoort geldt dat datgene is wat noodzakelijk is voor
de integriteit van het GBA-stelsel gezien als één systeem gebaseerd op een service
georiënteerde architectuur.
Consequentie hiervan is dat BZS-K voorziet in opslag van GBA gegevens in een
database en bij iedere bijhouding controles op de ingevoerde gegevens
afdwingt. Hiermee wordt voorkomen dat gegevens die niet aan de eisen
voldoen “het stelsel binnenkomen”.
De diensten voor bijhouding corresponderen qua niveau ongeveer met de
actualiseringen zoals die in het Logisch Ontwerp GBA zijn beschreven; een
eerste inventarisatie is te vinden in Bijlage I. Dit is een zorgvuldig gekozen
compromis: het is mogelijk om de procedures simpel en algemeen te houden,
maar dan bestaat het gevaar dat gebruikers fouten maken in de bijhouding. Het
is ook mogelijk om een zeer uitgebreide set van gespecialiseerde procedures te

65

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

maken waarin alle voorschriften rond de bijhouding volledig zijn uitgeschreven.
De set van procedures zou dan al gauw zo groot worden dat BZS-K nauwelijks
meer te onderhouden zou zijn.

Figuur 29: Aanpassing ten opzichte van Figuur 28 voor de situatie met een BZSK en Aanvullende Modules.

PRC6
(BZS-K 2)

De richtlijn die wordt gehanteerd bij het definiëren van de bijhoudings- en
raadpleeg services in BZS-K is dat fouten in de bijhouding van de GBA-gegevens zo
veel mogelijk moeten worden uitgesloten, maar dat verder de set van services zo
klein mogelijk dient te zijn (NORA 5.3.8 en 5.3.9).
Het koppelvlak tussen BZS-K en de Aanvullende Modules volgt de
ontwerpfilosofie die voor het gehele moderne GBA-stelsel gevolgd wordt. Dit
leidt tot een derde servicebus: de binnengemeentelijke servicebus. Deze
binnengemeentelijke servicebus past in de gemeentelijke architectuur zoals
voorgeschreven in GEMMA (zie verder hoofdstuk 5 architectuur). In de praktijk
hebben diverse gemeenten al een dergelijke servicebus in gebruik of zijn bezig

66

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

deze in het kader van midoffice ontwikkelingen en o.a. Andez aanbestedingen
in gebruik te nemen.

25

Het programma ODP biedt diensten aan om te controleren dat deze
servicebussen daadwerkelijk aan de OSB specificaties voldoen.

Figuur 30: Het koppelvlak tussen BZS-K en de Aanvullende Modules wordt
gerealiseerd met behulp van een binnengemeentelijke servicebus. Afnemers
binnen de gemeenten sluiten op diezelfde bus aan om de GBA te benaderen
(naar figuur 2 in definitiestudie 1.3)
Naast de Aanvullende Modules maken binnengemeentelijke afnemers gebruik
van de services van BZS-K. De binnengemeentelijke servicebus en BZS-K zorgen
er daarbij voor dat personen die niet in BZS-K gevonden worden, opgezicht
worden in GBA-V conform eisen t.a.v. transparant zoeken en autorisatie ORG7
en SEC1.

4.5

Het berichtenverkeer en de bijbehorende diensten

Naast de functionaliteit van enerzijds GBA-V en anderzijds de
burgerzakensystemen zijn de zogeheten berichtcycli, samenhangende
workflows van berichten, essentieel voor het begrijpen van het GBA-stelsel.
Hieronder wordt beschreven hoe dit in het toekomstige GBA-stelsel wordt
vormgegeven (NORA 6.1.1.1).

25

EGEM-i-teams heeft samen met een aantal Nederlandse gemeenten een modelbestek
midoffice opgesteld. Dit bestek – ANDEZ – biedt gemeenten houvast bij de aanschaf van
een midoffice systeem. (Bron: http://www.egem-iteams.nl/andez)

67

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

4.5.1
Samenwerking tussen GBA-V en de Burgerzakensystemen
De wijze waarop decentrale systemen met GBA-V samenwerken, kan
beschreven worden in termen van de berichten die uitgewisseld worden (de
huidige manier van beschrijven in het LO). In een service georiënteerde
architectuur ligt het meer voor de hand de diensten te beschrijven die de
berichtuitwisseling uitvoeren. In onderstaande paragraaf wordt beide gedaan.
De volgende soorten berichten worden onderscheiden:
1.

Gegevensverstrekkingen aan afnemers;

2.

Bijhoudingsberichten (intergemeentelijk): berichten die samenhangen
met vervolginschrijvingen en met toevallige gebeurtenissen.

3.

Intergemeentelijke bevragingen: ad-hoc vragen die gesteld worden ten
behoeve van gemeentelijke taken. Niet alle gemeenten maken hiervan
gebruik; uitsluitend de gemeenten die een GABA autorisatie hebben
(NORA 6.1.1.2).

4.

Bijhoudingsberichten voor GBA-V: berichten die na iedere bijhouding in
het Burgerzakensysteem naar GBA-V worden verzonden om de
landelijke kopie van GBA-V bij te houden. Deze berichtenstroom kent
een tijdsvertraging van maximaal 1 werkdag. Deze zijn identiek aan de
spontane mutaties die als onderdeel van de gegevensverstrekking aan
afnemers (1) worden verstuurd, met dien verstande dat GBA-V
spontane mutaties ontvangt van iedere PL en dat dit niet afhangt van
een afnemersindicatie. Deze speciale bijhoudingen worden verder
aangeduid als mutatiemeldingen.

In scenario 1 vindt
systematische verstrekking
aan buitengemeentelijke
afnemers plaats via GBA-V en
dient berichtenverkeer naar
binnengemeentelijke
afnemers zodanig te worden
gespecificeerd dat
gegarandeerd kan worden dat
GBA-V wordt bijgewerkt
voordat binnengemeentelijke
afnemers een
bijhoudingsbericht krijgen.

In scenario 2 vindt
systematische verstrekking
aan buitengemeentelijke
afnemers plaats via GBA-V en
garandeert de
procesregieservice verzending
van bijhoudingsberichten aan
binnengemeentelijke
afnemers als vervolg op
mutatiemeldingen aan GBA-V.

In scenario 3 blijft de
gegevensverstrekking aan
afnemers vanuit de
burgerzakensystemen
plaatsvinden.

4.5.2
Intergemeentelijke bijhouding (3.3.3)
Uitgangspunt van het GBA-stelsel is dat iedere PL op ieder moment in de tijd
maar op één plek wordt bijgehouden. Consequentie daarvan is dat een PL met
de burger mee verhuist als deze in een andere gemeente gaat wonen.
Consequentie is ook dat de burger normaal gesproken naar het loket van de
eigen gemeente moet om aangifte te doen, tenzij de gemeenten namens elkaar
werk kunnen verrichten aan een PL die in een andere gemeente in beheer is.
Dat laatste wordt plaatsonafhankelijk werken genoemd (zie 2.2.1). Dat is in het
GBA-stelsel nog niet voorzien in algemene zin. Voor een beperkt aantal diensten
is er echter een uitwisseling tussen gemeenten afgesproken die hetzelfde effect
heeft voor de burger. Deze opzet betekent dat gemeenten onderling
bijhoudingsberichten uit wisselen ten behoeve van twee soorten situaties:

68

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Verhuizingen van de ene gemeente naar de andere
Burger doet aangifte in een andere gemeente dan de gemeente die
bronhouder is van zijn PL
Het eerste wordt vervolginschrijving (intergemeentelijke verhuizing) genoemd,
26
het tweede toevallige geboorte en overige toevallige gebeurtenissen.
•
•

Verzending van deze berichten vindt momenteel plaats via het GBA-netwerk.
Aangezien iedere gemeente een keer per dag berichten leest en schrijft duurt
het heen en weer zenden van een bericht minimaal 48 uur. Na de invoer van
gegevens, meestal aan het loket, gaat de verdere verwerking van de berichten
geautomatiseerd, althans voor zover er geen uitzonderingssituaties optreden.
Echter pas nadat deze verwerking gereed is wordt de mutatiemelding naar GBAV gestuurd en starten de spontane mutaties. GBA-V en afnemers kunnen dus
beduidend later worden bijgewerkt dan dat de gebeurtenis door de burger bij
de gemeente wordt aangegeven.
In het toekomstige GBA wordt vanuit een centrale procesregisseur als functie
van de servicebus deze berichtenstroom bewaakt en wordt real time
uitwisseling van berichten mogelijk. Bij toevallige gebeurtenissen wordt GBA-V
gebruikt om te bepalen aan welke gemeente het betreffende bericht moet
worden doorgestuurd. Zie het voorbeeld met Bert Burger in kadertje bij
paragraaf 2.2.
De vervolginschrijving (intergemeentelijke verhuizing) werkt als volgt:
•
•
•
•

de gemeente van vestiging stuurt een signaal naar GBA-V. De GBA-V
stuurt dit signaal door naar de gemeente van vertrek.
De gemeente van vertrek blokkeert de PL en stuurt de gehele PL op
naar GBA-V. Deze stuurt de PL door naar de gemeente van vestiging.
De gemeente van vestiging neemt de PL op, en stuurt een
mutatiemelding naar GBA-V.
GBA-V stuurt aan de gemeente van vertrek een signaal op basis
waarvan ze de geblokkeerde PL kan worden bijgewerkt.

Merk op dat in al deze gevallen GBA-V de gegevens niet direct muteert. Het
Burgerzakensysteem blijft verantwoordelijk voor het feitelijk wijzigen van de
gegevens. De taak van GBA-V is beperkt:
PRC 7
(GBA-V 11)

De servicebus zorgt ten behoeve van de intergemeentelijke bijhouding voor het
routeren van berichten; bepalen welke gemeenten op de hoogte gesteld moeten
worden; de servicebus bewaakt de transacties en zorgt dat er geen berichten
verloren gaan.

26

Een toevallige gebeurtenis is een gebeurtenis die zich niet voordoet in de gemeente waar
hij in de GBA geregistreerd moet worden. De geboorteakte van een baby die wordt geboren
in een streekziekenhuis wordt opgemaakt in de gemeente waar het ziekenhuis is gevestigd.
De baby wordt ingeschreven in de GBA in de gemeente waar de ouders (of de moeder) zijn
ingeschreven. Er moet dan een melding van de burgerlijke stand van de eerste gemeente
naar de bevolkingsadministratie in de tweede gemeente.

69

Definitiestudie mGBA Versie 1.8

In scenario 1 vereist het
verregaande specifieke
voorschriften om te zorgen
dat de Burgerzakensystemen
van marktpartijen deze eis die
samenwerking met GBA-V
impliceert goed
implementeren.

PRC 8
(GBA-V 12)

De moderne GBA mogelijk gemaakt…

In scenario 2 is deze eis
ingebouwd in BZS-K en wordt
geprofiteerd van de
gelijkvormige architectuur van
GBA-V en BZS-K op basis van
service oriëntatie.

In scenario 3 blijft de
intergemeentelijke bijhouding
ongewijzigd

De servicebus zorgt ten behoeve van de intergemeentelijke bijhouding voor
opslaan en doorsturen: als een bericht niet direct aan de betreffende BZS-K kan
worden afgeleverd houdt GBA-V dit vast tot het wel afgeleverd kan worden.
Door deze twee functies bij GBA-V te beleggen worden de
Burgerzakensystemen ontlast en wordt de topologie van het netwerk
eenvoudiger: er is sprake van een sternetwerk in plaats van rechtstreekse puntnaar-punt verbindingen. Dat heeft weer aanzienlijke voordelen voor
bijvoorbeeld de beveiliging.

4.5.3
Intergemeentelijke bevragingen (3.3.4)
In de nieuwe opzet is het essentieel dat burgerzakensystemen de GBA-V kunnen
bevragen (de eis van transparantie, zie ORG7). In de huidige decentrale opzet
moeten gemeenten elkaar onderling bevragen, bijvoorbeeld om gegevens te
achterhalen over een burger die uit de eigen gemeente is wegverhuisd of om
gegevens over ouders of andere gerelateerden op te vragen als deze in een
andere gemeente wonen.
Bij de overgang naar het LO4 gegevensmodel ontstaan nog veel meer situaties
waarin GBA-V bevraagd moet worden omdat dan ook alle gegevens over
gerelateerden via GBA-V worden verkregen (zie paragraaf 6.5.2).
De invoering van de RNI leidt, gezien vanuit een gemeentelijke
Burgerzakensysteem, tot een soortgelijk proces, gegevens over niet ingezetenen
die bijvoorbeeld als gerelateerden optreden of die terugverhuizen naar
Nederland worden opgehaald uit het RNI (zie paragraaf 4.8) op een
vergelijkbare wijze als het ophalen uit GBA-V.
Deze functionaliteit wordt geleverd door de service ZoekPersoon van GBA-V (zie
bijlage I). Deze kan als onderdeel van diensten en services van het
Burgerzakensysteem worden aangeroepen om de gezochte gegevens real time
op te halen.
De huidige constructie waarbij GABA gemeenten twee identiteiten hebben in
het netwerk komt dus te vervallen. Dit maakt de toegang transparant en het
wordt eenvoudig om onderscheid te maken tussen informatieverzoeken die
door een gemeente worden gedaan en informatie verzoeken van afnemers. Dit
kan van belang zijn voor het financieringsmodel.

70

Definitiestudie mGBA Versie 1.8

4.6

De moderne GBA mogelijk gemaakt…

Kwaliteitsbewaking (3.5)

Het ontstaan van een landelijke kopie van persoonsgegevens in de GBA-V heeft
consequenties voor de kwaliteitsbewaking. In plaats van de systematische
verstrekking aan afnemers dragen de gemeenten de voortdurend zorg voor het
doorgeven van mutatiemeldingen aan GBA-V. In de verstrekking aan afnemers
vanuit gemeenten is de niet uniformiteit van processen en systemen in de
gemeenten soms zichtbaar. In de praktijk zijn daar steeds oplossingen voor
gevonden. Nu niet meer aan losse afnemers geleverd wordt maar aan één
centraal GBA-V worden eventuele systematische afwijkingen sneller zichtbaar.
Het bestaan van de GBA-V leidt onherroepelijk tot een grotere behoefte aan
echte uniformiteit in de basisprocessen waarmee de gemeente de bijhouding
van de GBA uitvoert.
Het nieuwe stelsel opent ook nieuwe mogelijkheden voor het verbeteren van de
kwaliteit van de gegevens in de GBA. Dat zal gebeuren op drie manieren:
•

•

•

GEG 4

Consistentie en plausibiliteit controles op de individuele
persoonslijsten (personen ouder dan 120, data in de toekomst, …). Dit
soort controles wordt primair uitgevoerd binnen de
Burgerzakensystemen zelf, als onderdeel van de gegevensinvoer.
Bestaande systemen bevatten echter ook PL-en die zijn aangelegd
voordat dergelijke controles gemeengoed waren. Daarom is het nuttig
dat de controles ook centraal kunnen worden uitgevoerd.
Controles tussen verschillende persoonslijsten. Naast de voor de hand
liggende controles op dubbele A-nummers en dubbele BSN’s kan ook
worden gedacht aan controle op gegevens van gerelateerden en
wederkerigheid van relaties (als op de PL van X staat dat er een
huwelijk is met Y staat dit huwelijk dan ook met identieke gegevens op
de PL van Y?).
27
Op basis van terugmeldingen van afnemers of van andere
gemeenten.

Uniforme consistentie en plausibiliteitcontroles worden ingebouwd in
Burgerzakensystemen.
In scenario 1 vereist dienen
deze controles via de LO
procedure te worden
gespecificeerd en dient op
basis van Schouwing en
Toetsing te worden bepaald of
alle pakketten van
leveranciers ze correct
implementeren.

In scenario 2 worden de
controles in BZS-K ingebouwd
waardoor ze de facto uniform
zijn.

In scenario 3 vereist dienen
deze controles via de LO
procedure te worden
gespecificeerd en dient op
basis van Schouwing en
Toetsing te worden bepaald of
alle pakketten van
leveranciers ze correct
implementeren.

27

Aangezien de terugmeldvoorziening in het kader van GBA als basisregistratie inmiddels
is ingevoerd wordt het begrip terugmelden bij gerede twijfel als bekend veronderstelt

71

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

GEG 5

De uniforme consistentie en plausibiliteitcontroles worden ook gecontroleerd in
het bijwerken van GBA-V op basis van mutatiemeldingen.

GEG 6
(GBA-V 19)

Los van de controles op het moment van bijwerken bezit GBA-V zelfstandige
kwaliteitscontroles die consistentie van PL-en onderling betreffen
Uit de controles ontstaan meldingen. Alleen de gemeenten mogen correcties
uitvoeren. Er dient dus een proces te zijn om de meldingen door te geven aan
de gemeenten. Dit proces is vergelijkbaar met terugmeldingen, met dien
verstande dat de meldingen uit de controles niet de status van een
terugmelding hebben omdat ze niet afkomstig zijn van een afnemer en niet op
basis van gerede twijfel ontstaan.

PRC 9

GBA-V ondersteunt het proces van kwaliteitsbewaking door te fungeren als melden concentratiepunt voor gesignaleerde problemen en door het informeren van
afnemers over de afhandeling voor haar rekening te nemen.

(GBA-V 13)

Dit legt aan de ene kant natuurlijk extra druk op de gemeenten, anderzijds kan
het ook een ontlasting betekenen (als vier afnemers dezelfde melding doen gaat
er slechts één signaal naar de gemeente).
Dat houdt dus in dat het voor kan komen dat onjuiste gegevens moeten worden
opgenomen in GBA-V totdat de betreffende gemeente een correctie heeft
doorgevoerd. GBA-V mag bijvoorbeeld niet afdwingen dat het BSN uniek is.
In technische zin betekent dat overigens niet dat GBA-V altijd alle niet-correcte
gegevens kan overnemen. Indien een mutatiemelding gegevens bevat die
technisch gesproken niet in GBA-V opgenomen kunnen worden dan zal dat niet
gebeuren en een foutmelding volgen. Dergelijke situaties zouden niet voor
mogen komen en hetzij door stringente specificatie van controles en
berichtdefinities, hetzij door nauwkeurige Schouwing en Toetsing moeten
worden tegengegaan. In de huidige situatie komen dit soort foutmeldingen voor
(enkele tientallen per dag) en ook in toekomstige situaties dient er een proces
te zijn om deze af te handelen.

4.6.1
Terugmelden in het kader van basisregistraties
Terugmeldingen vormen een specifiek proces in het kader van de
basisregistraties. Een voorziening voor het terugmelden aan GBA is reeds
gerealiseerd als onderdeel van het programma mGBA (zie [23]). Terugmeldingen
ontstaan op basis van gerede twijfel bij de afnemer. Gerede twijfel wil zeggen
dat de afnemer een aantoonbare reden heeft om te twijfelen aan bepaalde
authentieke gegevens. Dit ontslaat de afnemer van de verplichting om deze
authentieke gegevens uit de basisregistratie te gebruiken, mits er een
terugmelding wordt gedaan. Terugmeldingen kunnen zowel van buiten- als van

72

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

binnengemeentelijke afnemers als van andere gemeenten komen. Het proces
van terugmelden van binnengemeentelijke afnemers is de eigen
verantwoordelijkheid van de gemeente en hier niet beschreven (NORA 6.2.6.4).
PRC 10

De terugmeldvoorziening van de GBA dient één geheel te zijn met andere
28
terugmeldvoorzieningen voor dezelfde afnemers (op basis van ORG5)
Het proces van het signaleren en afhandelen van een terugmelding kan als
volgt worden weergegeven:
•

Het proces begint met een
terugmelding van een afnemer
aan de TMV. In het kader van het
stelsel van basisregistraties
wordt een terugmeldfaciliteit
(TMF) ontwikkeld die voor
terugmeldingen van alle
afnemers van alle
basisregistraties bedoeld is en
ingericht wordt als een service
bovenop de OSB. De huidige
TMV van GBA dient daarop
aangesloten te worden.

•

De kwaliteitscontrole controleert
zoveel mogelijk of er meerdere
meldingen zijn die betrekking
hebben op dezelfde set
gegevens. Deze meldingen
worden gebundeld.

Melden

Informeren

Bundelen

Volgen

Afmelden

Registreren

Onderzoeken

Figuur 31: Kwaliteitsbewaking

•

Het signaal wordt naar de verantwoordelijke gemeente gestuurd en daar
geregistreerd binnen het Burgerzakensysteem en onder de aandacht van de
gemeentelijke beheerder gebracht.

•

De gemeente moet in ieder geval de terugmelding onderzoeken. Van de
gemeente wordt verwacht dat ze aangeeft hoe lang het onderzoek naar
verwachting zal duren. Het onderzoek kan verder inhouden dat één of
meerdere groepen gegevens in onderzoek worden geplaatst.

•

Op het moment dat het onderzoek is afgerond verwijdert de gemeente de
aanduiding(en) “in onderzoek” en meldt de terugmelding af. Dit wordt
binnen de TMV geregistreerd.

28

Dit impliceert geen uitspraak over de inhoudelijke verschillen tussen de TMV en TMF

73

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

•

Afhankelijk van de uitslag van het onderzoek worden uiteraard de
gegevens al dan niet aangepast. Het doorleveren van de aangepaste
gegevens gaat middels de standaard mechanismen die daarvoor zijn
benoemd; dit is immers onafhankelijk van de aanleiding om de gegevens te
wijzigen.

•

GBA-V gaat na welke afnemers de terugmelding hebben gesignaleerd en
informeert ze over het afronden van het onderzoek.

Als een terugmelding wordt afgemeld verdwijnt deze niet uit de administratie
van de kwaliteitsmodule. Immers, als een andere afnemer dezelfde problemen
signaleert, is het niet de bedoeling dat er weer een nieuwe terugmelding naar
de gemeente gaat; de afnemer moet als antwoord krijgen dat dit probleem
eerder is gemeld én onderzocht. Daarbij moet hij ook de uitkomst van het
onderzoek te zien krijgen. De voorzieningen van de TMF op dit punt zijn
mogelijk minder verregaand, dit kan tot aanpassingen leiden wanneer de TMV
op de TMF moet worden aangesloten.
Onderdeel van de regelgeving rond de authentieke registraties is dat een
onderzoek naar juistheid van gegevens aan een termijn wordt gebonden. Het zal
dus niet meer mogelijk zijn om een de onderzoeksvlag te gebruiken als een
indicatie van twijfel over de juistheid van de gegevens en deze permanent te
laten staan. Op een zeker moment zal de gemeente de knoop moeten
doorhakken en besluiten het gegeven aan te passen of ongewijzigd te laten. Een
onderbouwing van deze beslissing kan worden vastgelegd als commentaar in
het logboek (zie hoofdstuk 6). Een burger die het met een dergelijk besluit niet
eens is kan dan een beroep doen op de rechter. Overigens gelden de
verplichtingen over verplicht gebruik, terugmelding en onderzoek alleen voor
het deel van de GBA-gegevens dat als authentiek is aangemerkt.
Naast terugmelding door buitengemeentelijke afnemers en andere gemeenten
is er sprake van terugmeldingen door binnengemeentelijke afnemers of andere
Burgerzakenprocessen. Deze hoeven niet via de TMV te worden afgehandeld.
De gemeente is zelf verantwoordelijk voor de inrichting van de
binnengemeentelijke terugmelding. Daarbij gelden wel dezelfde wettelijke eisen
als voor andere terugmeldingen. De status van de verwerking van een
binnengemeentelijke terugmelding wordt niet teruggekoppeld naar de TMV.
Wel dient het mogelijk te zijn de gegevens op dezelfde manier als bij andere
terugmeldingen in onderzoek te plaatsen. De daartoe benodigde functionaliteit
is onderdeel van de burgerzakensystemen.

4.7

Koppeling met de BAG

Iedere gemeente is verplicht voor eind 2009 een eigen Basisregistraties
Adressen en Gebouwen (BAG) in te richten en deze aan te sluiten op de
Landelijke Voorziening BAG (LV BAG). De BAG bevat gegevens over adressen en
gebouwen en geeft zekerheid over het bestaan van een bepaalde
adresaanduiding door deze te koppelen aan een gebouw of een deel van een
gebouw. Tussen het gemeentelijke BAG systeem en de LV BAG vinden
soortgelijke processen plaats als tussen de Burgerzakensystemen en GBA-V. Alle
burgers in de GBA hebben in principe een woon- of briefadres dat overeen moet
komen met een adresaanduiding in de BAG en die dus gerelateerd is aan een in
de BAG gekend gebouw (NORA 6.2.6.1). De gemeente is op grond van de wet

74

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

BAG die medio 2009 in gaat verantwoordelijk voor het juist leggen van deze
relatie in het bijhoudingsproces van de GBA. De wijze waarop de daartoe
benodigde koppeling met de BAG wordt vormgegeven is uitgewerkt in paragraaf
6.5.3.
PRC 11

Voorzieningen voor de koppeling met de BAG dienen ingebouwd te worden in het
Burgerzakensysteem.
4.8

Relatie met de RNI

De Registratie Niet ingezetenen is een nieuwe basisregistratie waarin personen
worden opgenomen die voor meerdere Nederlandse overheidsinstellingen van
belang zijn, maar niet in Nederland gevestigd zijn. Al deze personen krijgen een
BSN of hebben al een BSN. Degene van hen die al een sofi-nummer of BSN
hebben zijn nu reeds bij de Belastingdienst geregistreerd of zijn eerder in de
GBA geregistreerd. Deze personen zijn nu binnen het GBA-stelsel vindbaar in de
BV BSN.
Het ministerie van BZK is verantwoordelijk voor de RNI en heeft aangekondigd
de wettelijke regeling van de GBA op te nemen in de geplande herstructurering
29
van de GBA-wet in de vorm van het Wetsvoorstel Basisregistratie Personen .
ORG 13

De RNI wordt gerealiseerd als een onderdeel van het GBA-stelsel
De RNI bevat persoonslijsten (PL-en) net als de GBA, maar met enige verschillen
in de gegevens. Aangezien het voorkomt dat iemand eerst in de GBA is
ingeschreven en vervolgens naar de RNI verhuist wegens vestiging in het
buitenland en dan weer terug is het gewenst dat de gehele PL in de RNI
behouden blijft. Voor deze situaties komt opname in de RNI in plaats van
opschorting van de PL in de laatste gemeente van vestiging binnen Nederland.
De RNI functioneert dus in het GBA-stelsel als de “gemeente” waar al diegenen
“wonen” die buiten Nederland gevestigd zijn.

29

De informatie over de RNI is gebaseerd op een interview met de programmamanager
RNI

75

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Figuur 32: De RNI als onderdeel van het GBA-stelsel met berichtenverkeer
tussen de RNI en de gemeenten.
De status van de gegevens in de RNI zal per persoonslijst verschillen, naar
gelang de gegevens afkomstig zijn uit de GBA, van een van de zogenoemde
Aangewezen Organen of van het RNI loket. Voorlopig zullen de gegevens in de
RNI geen authentieke status hebben. In de RNI is het belangrijk om de datum
van de laatste bijhouding of verificatie van de gegevens goed te kunnen tonen,
deze datum geeft namelijk een indicatie van de actualiteit, c.q. een maat voor
de “houdbaarheid”.
Voor de RNI worden enkele eigen loketten ingericht waar personen een BSN
kunnen aanvragen, deze vervangen de bestaande loketten daartoe bij de
Belastingdienst. De functionaliteit die voor deze loketten nodig is lijkt sterk op
de bijhoudingsfunctionaliteit van de gemeenten en zou met een aangepast
Aanvullende Module kunnen worden gerealiseerd.
De registratie zelf wordt niet alleen gevoed met bijhoudingen vanuit dit RNI
loket maar ook met bijhoudingen vanuit de Aangewezen Organen en
verhuizingen van of naar het buitenland van en naar gemeenten. Deze
organisaties hebben de plicht de gegevens in de RNI bij te houden op basis van
hun eigen (sectorale) processen. Deze functionaliteit lijkt sterk op een BZS-K en
zou met een aangepaste versie van BZS-K kunnen worden gerealiseerd.
GEG 7

Een persoonslijst dient ongeschonden van een gemeente naar de RNI te kunnen
worden overgedragen en vervolgens weer in een gemeente voortgezet te kunnen
worden, daarbij dient de levensloop van de betrokkenen zichtbaar te blijven met
alle relevante informatie over het tijdelijke verblijf buiten Nederland.
Voor afname van de RNI gelden dezelfde regels als voor afname van de GBA-V.
Er wordt eveneens gewerkt met afnemersindicaties en zowel de gemeenten als

76

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

veel van de GBA afnemers zullen ook RNI afnemer zijn. De daartoe benodigde
functionaliteit vertoont grote overlap met GBA-V full service.

PRC 12

De transparante toegang (ORG7) op GBA-V dient uitgebreid te worden met een
transparante toegang op RNI, voor zowel gemeenten als afnemers.
Voor de RNI zijn derhalve de volgende oplossingscomponenten van belang:
•

BZS-K voor de registratie zelf

•

GBA-V full service voor de verstrekkingsfunctionaliteit, in het bijzonder
het realiseren van afnemersindicaties op de landelijke voorziening

•

Moderne Interfaces om investeringen in berichtenverkeer via het
huidige GBA-netwerk te vermijden en de beheerkosten te beperken.

•

LO4 gegevensmodel ten aanzien van afscheiding van het logboek, dit
maakt vastlegging van de gegevens waarin de RNI persoonslijst afwijkt
van de GBA persoonslijst veel eenvoudiger, verder zijn ook beperkingen
in de vast te leggen wijzigingsdata een probleem voor RNI. Tenslotte is
het LO4 gegevensmodel nodig om in de GBA op goede manier gebruik
te maken van verwijzingen naar de RNI en dus aan de kant van de
gemeenten de kwaliteit van de verwijzingen naar gerelateerden die in
de RNI staan te verbeteren.

Daarnaast roept realisatie van de RNI de vraag op of herstructurering van de BV
BSN besparingen en vereenvoudiging van het GBA-stelsel zou opleveren.
Immers een zeer groot deel van de functie van BV BSN wordt door de RNI
overgenomen. Wat resulteert is een BV BSN die 100% van de BSN-nen en deel
van de persoonsgegevens kopieert voor het vindbaar houden van een relatief
beperkt (meer dan 100 x zo klein) aantal sofi-nummers.
Daarmee is duidelijk dat er veel synergie is tussen de RNI en modernisering GBA.
De RNI moet in de loop van 2011 zijn ingevoerd.

77

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

5 Architectuur
De architectuur van de GBA is een verdere uitwerking van de eisen die in
paragraaf 3.1 zijn weergegeven. Het daadwerkelijk realiseren conform de
architectuur is van belang om de gewenste flexibiliteit ten aanzien van
wijzigingen te bereiken en om standaardisatie binnen de overheid mogelijk te
maken. De architectuur draagt dus bij aan de doelstelling van flexibiliteit (zie
2.1.2) en aan de afspraken over standaardisatie binnen de overheid (zie NUP en
2.1.3). In de opdracht voor actualisering van de definitiestudie is nadrukkelijk
opgenomen, dat de definitiestudie afgestemd moet worden op de NORA.
Vandaar dat in de eerste paragraaf van dit hoofdstuk, de context van de NORA
wordt aangehaald.

5.1

De GBA en de principes van de NORA

De NORA bevat inrichtingsprincipes, modellen en standaarden voor het ontwerp
en de inrichting van de elektronische overheid. Het biedt een referentiekader
voor het ontwikkelen van architecturen voor vormen van samenwerking binnen
de e-overheid (zie ORG10) op het niveau van organisatie en processen,
informatie en gegevens en technologie. De NORA versie 2.0 dient als
uitgangspunt voor deze definitiestudie [2].
De NORA maakt onderscheid tussen fundamentele en afgeleide principes. De 20
fundamentele principes geven de doelstellingen weer. De fundamentele
principes zijn afgeleid van wensen van burgers én bedrijven én politiek ten
aanzien van het functioneren van de overheid als moderne dienstverlener. Op
basis van de 20 fundamentele principes zijn ongeveer 140 afgeleide principes
gedefinieerd. Een afgeleid principe geeft richting aan het ontwerp. De afgeleide
principes zijn derhalve meer bedoeld voor de communicatie met architecten en
ontwerpers dan voor communicatie met bestuurders. De in dit document
vermelde nummers “NORA n.n.n.n” verwijzen naar de afgeleide principes.
De voor GBA relevante fundamentele principes zijn in onderstaande tabel
weergegeven.

Fundamentele NORA-principes
P8

Eenmaal uitvragen van gegevens, meermalen gebruiken; de organisaties
in het publieke domein zullen burgers en bedrijven niet opnieuw om
gegevens vragen die bij de overheid al bekend zijn

P12

Organisaties in het publieke domein geven burgers, bedrijven en
maatschappelijke instellingen inzicht in de status van voor hen lopende
dienstverleningsprocessen (transparante, traceerbare
dienstverleningsprocessen).

P17

Organisaties in het publieke domein organiseren zich als een onderdeel
van een integraal opererende en als eenheid optredende overheid, die
in haar handelen naar burgers, bedrijven en maatschappelijke
instellingen consistent en betrouwbaar.

78

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

P18

Organisaties in het publieke domein gebruiken gegevens die accuraat,
actueel en volgens wettelijke normen beveiligd zijn en delen die
gegevens met andere organisaties in het publieke domein

P19

Gebruik waar mogelijk generieke componenten. Organisaties in het
publieke domein streven er naar om beschikbare gemeenschappelijke
voorzieningen te gebruiken, als deze op de punten functionaliteit,
beveiliging en kosten gelijkwaardig zijn aan individuele voorzieningen.

P20

Standaardiseer waar mogelijk koppelvlakken en hiermee
samenhangende componenten. Organisaties in het publiek domein
streven er naar hun koppelvlakken en hiermee samenhangende
componenten te standaardiseren, waardoor het eenvoudiger wordt om
in ketens samen te werken en gebruik te maken van generieke
voorzieningen.

De gehanteerde modellen in voorliggende definitiestudie dienen ter
ondersteuning van de tekst en zijn zoveel mogelijk afgestemd op de “look and
feel” van de NORA. Daarom zijn ook de eisen die in de oorspronkelijke
definitiestudie zijn geformuleerd, ingedeeld op basis van het NORA
negenvlaksmodel. De bovenste drie vlakken, wie (organisatorisch), wat
(diensten) en hoe (processen) zijn op hoofdlijnen in hoofdstuk 4 beschreven.
Het middelste vlak (gegevens) is in hoofdstuk 6 uitgewerkt. De verdere
uitwerking van de architectuur is enerzijds een meer technische vertaling van de
daar al gegeven eisen en ten tweede een systeemschets en beschrijving van de
benodigde koppelvlakken.
Transitie

Figuur 33: het negenvlaksmodel van de NORA dat gebruikt is voor de indeling
van de in deze definitiestudie vastgestelde eisen voor het toekomstige GBA
stelsel.

79

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Figuur 34: Plaats van het GBA-stelsel in de architectuur van de overheid
In variant 1 wordt op
hoofdlijnen voldaan aan de
architectuureisen die de NORA
stelt.

In variant 2 kan geheel aan de
architectuureisen vanuit de
NORA voldaan worden

In variant 3 kan slechts zeer
beperkt aan de
architectuureisen voldaan
worden. Variant 3 leidt tot een
GBA dat minder goed
inpasbaar is in de
gezamenlijke eoverheidsstandaarden.

De NORA gaat uit van een service georiënteerde architectuur. De overheid
wil/moet steeds sneller kunnen inspelen op de veranderende vraag van burgers,
bedrijven of andere overheidsinstellingen. Daarbij besluiten organisaties
bijvoorbeeld om in toenemende mate activiteiten te centraliseren, in het geheel
af te stoten of uit te besteden aan derden. Omgekeerd worden ook
samenwerkingsverbanden met ketenpartners aangegaan. Dit vereist een hoge
mate van flexibiliteit van de mensen, organisatie (processen) en de middelen.
Service oriëntatie richt de aandacht op de manier waarop zaken (vragen van de
burger) worden behandeld door de organisatie. Door processen als een
samenstelling van procesbouwstenen (services) te definiëren, kunnen de
services door een aparte besturing als modules in een procesflow worden
gekoppeld. Hierdoor ontstaat maximale flexibiliteit als bedoeld in de
oorspronkelijke Snellen doelstelling.

80

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Concept van Service Oriented Architecture (SOA)
Procesflow
Deel
proces

Deel
proces

Deel
proces

Service
Service

Service
Service

Service

Gegevens / infrastructuur

Figuur 35: Service Oriented Architectuur concept: processen worden
samengesteld op basis van services.

5.2

Uitgangspunten voor de architectuur van de GBA (5.1)

Bij het opstellen van de architectuur van het Startpakket GBA zijn een aantal
architectuur uitgangspunten geformuleerd, deze zijn onverminderd van
toepassing voor het vervolg van de modernisering.
1.

2.

3.

De principes van Service Oriented Architecture (ORG11) worden strikt
doorgevoerd . Dit levert de volgende consequenties op:
a. Bedrijfsvoering wordt beschouwd als een stelsel van gerelateerde
functies
b. Interacties tussen functies worden beschouwd als diensten
services
c. Koppelvlakken zijn open, gestandaardiseerd en gedocumenteerd
d. Door andere samenvoeging van services ontstaat nieuwe
functionaliteit en mogelijkheden.
De toepassing van de principes van Model Driven Architecture leidt tot
grotere flexibiliteit en inzichtelijkheid en minimaliseert de toepassing van
de duurste resource, te weten menskracht, zowel in de bouw als tijdens
beheer. Dit leidt tot de volgende ICT consequenties:
a. Minimaliseren coderingsinspanning door genereren/hergebruik
van code (Middleware)
b. Model ligt zo dicht mogelijk bij Business Processen (LO-3 en HUP)
c. Wijzigingen kunnen flexibel worden doorgevoerd tegen relatief
lage kosten
De principes van Component Based Development leiden tot grotere
herbruikbaarheid van gerealiseerde inspanningen en geven de volgende
consequenties:

81

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

a.

4.

eenduidige en relatief eenvoudige taak. De componenten worden
gerealiseerd op een wijze die optimaal aansluit bij hun plaats in het
geheel. Componenten worden verdeeld in minimaal twee typen.
De Werk componenten zijn verantwoordelijk voor het uitvoeren
van (primitieve) processen. De Stuur componenten zijn
verantwoordelijk voor het coördineren van de Werk
componenten.
b. Stuur componenten kunnen op een hoger aggregatie niveau
worden beschouwd als Werk componenten, waardoor een
gelaagde structuur ontstaat.
Workflow Management principes en standaarden leiden tot het voorschrift
om Stuur componenten in te richten als Workflow.

De indruk bestaat dat deze principes niet op alle punten
consequent zijn toegepast binnen het nu gerealiseerde deel van
GBA-V. De mate waarin dit het geval is dient voorafgaand aan
uitvoeren van een vervolgstap in de vorm van variant 1 of 2
nader onderzocht te worden om te voorkomen dat het vervolg
last heeft van keuzes die in de uitwerking gemaakt zijn die voor
GBA-V Online weliswaar pragmatisch waren maar de
doorontwikkeling minder efficiënt maken.

5.3

In variant 3 wordt GBA-V niet
verder doorontwikkeld en
speelt dit derhalve minder.

De GBA en de architectuur van gemeenten

Gemeenten worden geconfronteerd met snel wijzigende taakstellingen,
verantwoordelijkheden en regelgeving. Om de veranderingen richting egemeenten (zie paragraaf 2.2) door te kunnen voeren zijn forse aanpassingen in
de ICT nodig. Op basis van de NORA is door EGEM een architectuur voor
gemeenten opgesteld om daarin te ondersteunen, de GeMMA.
Toepassing van deze architectuur is eenvoudiger wanneer een nieuw zelfstandig
systeem gerealiseerd wordt dan wanneer ingegrepen moet worden op
bestaande gemeentelijke systemen en pakketten. De keuzes en eisen die voor
het moderne GBA gelden kunnen daarom niet los gezien worden van zowel de
huidige architectuur bij gemeenten als de gewenste toekomstige architectuur
van de gemeenten als beschreven in GeMMA.

5.3.1
Huidige architectuur bij de gemeenten
De huidige architectuur bij de gemeente verschilt. In deze paragraaf wordt een
gegeneraliseerd beeld gegeven. De bestaande burgerzakensystemen hebben
een architectuur die sterk afwijkt van de GeMMA en die meer aansluit bij een
organisatie in afzonderlijk opererende (verkokerde) gemeentelijke diensten en
afdelingen. Grote aanpassingen aan deze systemen of volledige nieuwbouw
lijken noodzakelijk om burgerzaken op een goede manier onderdeel van de
elektronische gemeente te maken. Op dit moment werken de betreffende
marktpartijen ieder conform hun eigen beleid aan deze verandering en nemen
zijn geen deel in bijvoorbeeld de ANDEZ aanbestedingen ten behoeve van
vernieuwen van de ICT van de gemeenten.
Tijdens de expertteamworkshops, ter voorbereiding van de actualisering van de
definitiestudie, is de systeemarchitectuur van verschillende gemeenten

82

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

besproken. Een inrichting rondom de GBA die nu vaak wordt aangetroffen bevat
de volgende componenten:
1.

Burgerzakensysteem

2.

Datadistributiesysteem

3.

Verzend- en Ontvangststation voor Afnemers

4.

Terugmeldvoorzieningservice

Figuur 36: Huidige GBA inclusief GBA Verstrekkingen Online-1
Zowel “GetronicsPinkRoccade” als “Centric”-gemeenten hebben soortgelijke
componenten. Indien men de gemeentelijke inrichting rondom de
Persoonsgegevens eruit licht, dan heeft men vaak een specifieke burgerzaken
applicatie met daaraan gekoppeld een administratie (database) met
Persoonsgegevens. Vanuit deze administraties worden afnemers bediend.
Binnengemeentelijke afnemers worden soms bediend door een centraal
gegevensmagazijn of datadistributievoorziening. Circa 350 gemeenten hebben
bij BPR een licentie aangevraagd om buitengemeentelijke persoonsgegevens te
bevragen (Gemeente Als Buitengemeentelijke Afnemer ofwel de GABAaansluiting). Totdat er een nieuwe landelijke voorziening zoals het nieuwe BZS-K
aanwezig is, zal een Verzend- en Ontvangststation voor Afnemers (VOA) en een
mailbox noodzakelijk zijn voor intergemeentelijk verkeer.
De belangrijkste componenten zijn:
Burgerzakensysteem / Persoonsinformatievoorziening
Met het burgerzakensysteem worden Persoonsgegevens onderhouden op wijze
als beschreven in paragraaf 4.4. Daarnaast bevatten de huidige
Burgerzakensystemen functionaliteit voor het leveren van systematische
verstrekkingen aan afnemers. Het burgerzakensysteem is de enige applicatie
binnen gemeente dat de authentieke persoonsgegevens kan muteren.
Het agentschap BPR heeft de applicaties die ontwikkeld worden door
leveranciers vooraf getoetst en toegelaten om geïmplementeerd te worden bij
gemeenten die daarvan gebruik willen maken. Elke nieuwe release wordt vooraf
getoetst. Het systeem is opgebouwd rond een kern van persoons- en

83

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

adresgegevens. Soms is deze voorzien van webservices, waardoor elektronische
aangiften van verhuizingen bijvoorbeeld automatisch kunnen worden verwerkt.
Dit zijn functionaliteiten die op verschillende wijze kunnen communiceren met
de standaard pakketten. Door middel van StUF berichten worden mutaties via
het datadistributiesysteem gedistribueerd naar al de binnengemeentelijke
afnemers.
In de context van de definitiestudie is dit onderdeel te vergelijken met de BZS-K
plus aanvullende modules.
Daarnaast worden andere Burgerzakenprocessen ondersteund ten behoeve van
verkiezingen, burgerlijke stand, automatische registratie van rijbewijsgegevens,
naturalisatieonderzoek etc.
Datadistributiesysteem
Het Datadistributiesysteem verbindt verschillende (binnengemeentelijke)
applicaties met elkaar en voorziet deze van actuele basisgegevens. Deze
basisgegevens worden in de vorm van StUF-bg-berichten, verspreid naar de
applicaties die op het datadistributiesysteem zijn aangesloten. Beide
mechanismes als beschreven in paragraaf 4.4.4 komen daarbij voor. StUF-bgberichten geven de laatste stand van zaken door aan de aangesloten applicaties.
De afhandeling van een dergelijk bericht verschilt per applicatie. Deze
datadistributiesystemen kunnen zijn voorzien Verzend en Ontvangen module
(VOA) voor buitengemeentelijk berichtenverkeer. Hierdoor kunnen ook
mutaties uit andere gemeenten worden doorgevoerd. In combinatie met de
WEB-enabled browserbesturing kan functionaliteit worden toegevoegd ten
behoeve van het raadplegen.
VOA - Koppeling met GBA-netwerk
De VOA is een GBA-netwerkkoppeling. Deze koppeling is geschikt voor de
geheel automatische afwikkeling van GBA-berichten bij gemeenten en
afnemers. VOA handelt berichtencycli, zoals gedefinieerd in LO3, autonoom af.
Het systeem controleert de berichten en verwerkt uitsluitend de goedgekeurde
berichten.
De VOA is gespecificeerd in LO. Er zijn meer leveranciers en dus ook intern
verschillende VOA’s. Zowel gemeenten als afnemers hebben een VOA, alleen de
afnemers die enkel LO3 Ad hov services afnemen hebben geen VOA.
Terugmeldingen
Veel gemeenten hebben eigen voorzieningen ontworpen of procedures
beschreven om binnengemeentelijke terugmeldingen te kunnen verwerken. Dit
zijn niet altijd nieuwe ICT services maar vaak ook procedures. Sommige
gemeenten hebben hun e-mailpakket ingezet om interne meldingen te kunnen
verwerken. Een medewerker van Burgerzaken plaatst handmatig de “in
onderzoek” indicatie in de PL. Dit leidt tot een update van de GBA-V via de
reguliere mutatiemeldingen.
Er zijn ook gemeenten die een eigen webservice hebben gebouwd en deze via
intranet ter beschikkingstellen. Leveranciers zijn nog niet zover dat men deze
functionaliteit (obv de WSDL van BPR) heeft geïntegreerd in de eigen
applicaties.

84

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

5.3.2
Toekomstige architectuur bij gemeenten
De GeMMA beschrijft de architectuur die nodig is om de gemeentelijke ambities
als beschreven in paragraaf 2.2 mogelijk te maken. De GeMMA architectuur
gaat uit van scheiding tussen front office, mid office en back office en de
toepassing van diverse standaarden. Het omvat meerdere onderdelen, naast
een procesarchitectuur het RSGB gegevensmodel en de StUF
berichtenstandaarden.

Figuur 37: Informatie architectuur gemeenten conform GeMMA
Bovenstaande informatie architectuur voor gemeenten toont een verder
uitgewerkte visie op de processen in de toekomstige gemeente waarin de
frontoffice (kanalen) gescheiden is van back office en waarin de processen
allemaal via een mid-office worden afgehandeld. Belangrijke component in die
mid-office is de “BPM” component die de processen regisseert. Deze hoort
typisch in een service georiënteerde architectuur zoals ook voor de GBA
voorzien in de modernisering.
Belangrijke consequenties zijn:
•

Toepassen van uniform gegevensmodel met een zakendossier voor het
vastleggen van de dienstverlening aan de burger en een volledige
toepassing van het stelsel van basisregistraties. Dit is vastgelegd in de
RSGB (onderdeel van GEMMA), zie paragraaf 6.4.

•

Een binnengemeentelijke diensten- of servicebus met bericht
uitwisseling op basis van Stuf 3.0 specificatie

Een andersoortige consequentie is dat er dermate veel ICT veranderingen op de
gemeenten afkomen dat deze in toenemende mate hun ICT onderbrengen in
shared service centra. Dit is in paragraaf 2.2 en ORG12 al vermeld als een nieuw

85

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

element waarmee bij verdere modernisering van GBA rekening gehouden moet
worden.
In variant 1 hoeft er weinig te
veranderen aan de huidige
architectuur bij gemeenten.
Deze variant staat neutraal ten
opzichte van de invoering van
GEMMA gebaseerde
architectuur

5.4

In variant 2 is een
fundamentele verandering van
de architectuur van de
gemeenten vereist. Realisatie
van variant 2 draagt bij aan
een gemeentelijke
architectuur conform GEMMA.

In variant 3 kan het
handhaven van het GBAnetwerk een beperking
opleveren voor de overgang
naar een GEMMA gebaseerde
architectuur

Systeemschets van de toekomstige GBA (5.2)

De in de vorige paragraaf geïntroduceerde uitgangspunten voor de architectuur
leiden tot de hieronder getoonde schets van het nieuwe GBA-stelsel.

Figuur 38: Overzicht van het nieuwe GBA-stelsel met alle mogelijke scenario’s

Variant 1. In de bovenste helft
van de figuur bevindt zich een
burgerzakensysteem van de
vorm als uiterste links
getekend.

Variant 2. Alle gemeenten
volgen de architectuur van de
middelste twee getekende
gemeentelijke systemen in de
eindsituatie. Tijdens de
migratie bevindt een deel van
de gemeenten zich in de
situatie zoals uiterst rechts
getekend.

Variant 3. Gemeenten blijven
voor afzienbare toekomst in
de situatie uiterst rechts

Het schema is een weergave van de mogelijke eindsituaties. Het stelsel is
opgesplitst in componenten en de communicatie tussen die componenten

86

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

verloopt via een gestandaardiseerde berichtenstructuur d.m.v. een servicebus
zoals ook al weergegeven in hoofdstuk 3 (ORG11) en in Figuur 25. De
belangrijkste architectuureisen zijn in feite eisen aan de servicebus en de
koppelvlakken tussen diensten en interfaces tussen services die door middel van
de servicebus gerealiseerd worden. Door de ontkoppeling van functionaliteit
wordt het eenvoudiger nieuwe functionaliteit op het GBA stelsel aan te sluiten,
onderdelen van het stelsel op een andere plaats onder te brengen en neemt de
flexibiliteit met betrekking tot wijzigingen sterk toe.
De functionele basiscomponenten zijn dus van elkaar ontkoppeld d.m.v. een
servicebus. Hoewel in het schema drie verschillende soorten servicebussen zijn
getekend is hiermee niet bedoeld, dat deze ook fysiek geïmplementeerd dienen
te worden. Het onderscheid in het schema is een logisch verschil.
Op basis van de e-overheidsafspraken (NORA, NUP) worden de benodigde
servicebussen geïmplementeerd op basis van de OSB. Onderdeel van deze
afspraken is dat gemeenten hun binnengemeentelijke servicebus op de OSB
aansluiten. Alle benodigde servicebussen volgen dus dezelfde set afspraken en
hanteren dezelfde adressering en routering.

5.5

Koppelvlakken in het GBA stelsel (5.3)

Koppelvlakken spelen een belangrijke rol in de opzet van het nieuwe GBAstelsel. Door de nieuwe opzet, waarbij het ontwerp tot stand is gebracht vanuit
een landelijk perspectief en een opdeling in componenten op gemeentelijk,
regionaal en landelijk niveau, evenals voorziene koppelingen met andere
systemen, is het zorgvuldig omgaan met koppelvlakken uiterst belangrijk.
Voortbouwend op de eerdere eisen leidt dit tot het volgende:
UIT2 (ALG 24)

Alle koppelvlakken zijn volledig open en daarmee voor iedereen beschikbaar.
In variant 1 geldt dit alleen
voor de koppelvlakken van
GBA-V, het koppelvlak van het
burgerzakensysteem naar
andere gemeentelijke
systemen hoeft niet open te
zijn en mag bepaald worden
door de marktpartijen.

Variant 2. Eis wordt volledig
gerealiseerd. De enige
beperkende factor voor het
gebruik van de koppelvlakken
zijn autorisaties en het
onderliggende
transportnetwerk.

Variant 3. Enkel het koppelvlak
van GBA-V Online voor
afnemers is open.

Hierdoor ontstaat naar de toekomst toe de mogelijkheid voor andere systemen
en processen om aan te sluiten op de bestaande systematiek. Tevens wordt
hierdoor de marktwerking gestimuleerd (een van de Snellen doelstellingen).
Bovendien wordt gestimuleerd, dat nieuwe leveranciers kunnen toetreden met
innovatieve toepassingen om gemeenten te ondersteunen in het stroomlijnen
van hun processen.

87

Definitiestudie mGBA Versie 1.8

UIT3 (ALG 25)

De moderne GBA mogelijk gemaakt…

Alle koppelvlakken zijn gestandaardiseerd, zowel de berichtenveloppe als de
inhoud. Voor de enveloppe wordt de OSB ebMS specificatie voorgeschreven, voor
30
de berichtinhoud de StUF 3.0 standaard.
In variant 1 geldt dit alleen
voor de koppelvlakken van
GBA-V ook in de richting van
gemeenten.

Variant 2. Eis wordt volledig
gerealiseerd.

Variant 3. Het koppelvlak voor
afnemers in GBA-V Online is
nog niet volledig
gestandaardiseerd conform de
OSB. Alle andere
koppelvlakken in deze variant
blijven specifiek voor GBA.

Toepassing van de OSB specificatie betekent een nauwkeurige specificatie van
hoe de standaarden voor webservices gebruikt moeten worden. Vanwege de
eisen aan de integriteit van het berichtenverkeer wordt daarbij gekozen voor de
ebMS specificatie.
Voor de berichtinhoud wordt gebruik gemaakt van de mede op basis van
eerdere deelprojecten van mGBA ontwikkelde STUF 3.0 standaard. Deze
beschrijft nauwkeurig de wijze waarop de inhoud in XML wordt vastgelegd.
TEC1 (ALG 27)

Koppelvlakken tussen een component en de servicebus zijn gelaagd opgebouwd
Een gelaagde opbouw van componenten wil zeggen dat de ene laag vervangen
kan worden zonder de andere laag aan te passen. Dit is relevant om beperking
van de marktwerking te voorkomen en maximale inzet van Open Source
mogelijk te maken. Immers alle lagen waarvoor een goed Open Source product
bestaat kunnen dan met dat product worden ingevuld zonder de andere lagen
aan te tasten. Het is bovendien van belang voor de schaalbaarheid.
Schaalbaarheidsproblemen zijn meestal een bottleneck in een bepaalde laag.
Indien die laag zonder gevolgen voor de andere lagen vervangen kan worden
door een andere implementatie of product is er de meeste garantie dat
schaalbaarheidsproblemen beperkt blijven en tegen verantwoorde kosten
kunnen worden opgelost.
Tussen een component en de servicebus zorgt een adapter voor de benodigde
aanpassingen in het berichtenprotocol.. Hierdoor is de opzet van het nieuwe
GBA-stelsel onafhankelijk van de inzet van een specifieke servicebus.

TEC2 (ALG 28)

Koppelvlakken zijn zodanig gedefinieerd, dat op eenvoudige wijze gebruik kan
worden gemaakt van Open Source componenten
Conform het overheidsbeleid kunnen Open Source componenten op
gelijkwaardige wijze als Closed Source worden ingezet in het stelsel, waardoor
marktwerking wordt gestimuleerd. Het programma ODP draagt hieraan bij

30

Hoewel deze standaard is voorgedragen door het College Standaardisatie blijven er
hardnekkige signalen dat deze nog onvoldoende aansluit op de gekozen service
geörienteerde architectuur. Hier moet nader onderzoek naar gedaan worden.

88

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

doordat in dat programma diverse open en closed source adapters getest zijn
op conformiteit met de OSB specificaties. Voor de berichtenmakelaar en de
adapters in het GBA-stelsel (onderdelen van Moderne Interfaces) dient hiervan
gebruik gemaakt te worden.

In variant 1 is de
implementatie van eis ALG 27
en ALG 28 aan gemeentelijke
zijde een zaak die de interne
opzet van het systeem van een
marktpartij raakt

PRC 13
(ALG 29)

In variant 2 worden eis ALG 27
en ALG 28 voor alle
koppelvlakken mogelijk.

In variant 3 is geen sprake van
een servicebus.

Koppelvlakken zijn geschikt voor real-time verwerking

In het ontwerp van het nieuwe GBA-stelsel is niet de eis gesteld, dat alle
koppelvlakken real-time moeten werken, maar in het ontwerp is geen enkel
beletsel opgenomen om het nieuwe GBA uiteindelijk tot een volledige real-time
realisatie te laten uitgroeien. Hierdoor kan een aanmerkelijke versnelling in de
gegevensverwerking worden bereikt in vergelijking met de huidige situatie.
Toepassing van het ebMS protocol voorziet in real time asynchrone verwerking
waarbij aan de eis dat berichten bevestigd worden voldaan kan worden.
In variant 1 is aanpassing van
de burgerzakensystemen
noodzakelijk om dit te
bereiken. Voor zover nu
bekend bevatten ten minste 3
van de 5 huidige pakketten
beperkingen in de
mogelijkheden ten aanzien
van het real time verzenden
van berichten.

5.6

In variant 2 is real time
verwerking mogelijk

In variant 3 vormen zowel het
GBA netwerk als (3 van de 5)
bestaande GBA systemen
beperkingen die real time
verwerking onmogelijk maken

De servicebus (5.4)

De servicebus speelt niet alleen een belangrijke rol in de ontkoppeling van
functionaliteit en in de verdeling van de functionaliteit over de decentrale en
centrale onderdelen van het GBA-stelsel maar voorziet ook in een aantal
generieke services.
DST 7

Voorzieningen die in een service georiënteerde architectuur gerealiseerd kunnen
worden door generieke services van de servicebus worden op die basis
geïmplementeerd en niet ondergebracht binnen andere functionele services.
In variant 1 is de mate waarin
generieke services gebruikt
kunnen worden vanuit
gemeenten en voor het
berichtenverkeer van-, naar en
tussen gemeenten afhankelijk
van de wijze waarop
marktpartijen de

In variant 2 is maximaal
benutten van generieke
services van de servicebus
mogelijk

In variant 3 is er geen sprake
van een servicebus

89

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

burgerzakensystemen
inrichten. Voor de Moderne
Interface richting afnemers is
maximale benutting mogelijk.

Het GBA-stelsel heeft in ieder geval de volgende generieke services nodig:
TEC 3
(ALG 30)

De servicebus draagt zorg voor buffering van gegevens, waardoor
beschikbaarheidseisen worden verminderd;

PRC 14
(ALG 31)

De servicebus draagt zorg voor protocollering t.b.v. eenduidige verslaglegging van
het berichtenverkeer;
In de huidige ontwerpen is nog niet in deze wijze van protocollering voorzien.

PRC 15
(ALG 32)

De servicebus biedt faciliteiten voor transformatie, d.w.z. het omzetten van de
ene standaard in een andere (Als voorbeeld zou kunnen dienen het omzetten van
XML naar EDI of vice versa);

PRC 16
(ALG 33)

De servicebus biedt faciliteiten voor adressering en routering, d.w.z. het kennen
van de componenten en hun dienstverlening als ook het kiezen van de meest
efficiënte weg van de bron naar het doel; geïmplementeerd en niet ondergebracht
binnen andere functionele services. In deze functie wordt voorzien door de OSB.

TEC 4
(ALG 34)

De servicebus biedt voorzieningen voor asynchrone communicatie tussen
componenten, waarvan verwacht mag worden dat de beschikbaarheid met elkaar
uit de pas loopt;

PRC 17
(ALG 35)

De servicebus biedt faciliteiten voor beperkte workflow teneinde berichten
achtereenvolgens langs verschillende componenten te leiden, bijvoorbeeld voor
een samengestelde zoekopdracht over GBA-V en RNI;

PRC 18
(ALG 36)

De servicebus biedt faciliteiten voor abonnementen, bijvoorbeeld voor het
eenmalig publiceren van informatie t.b.v. afnemersgroepen, waarbij elke afnemer
afzonderlijk op deze publicatie is geabonneerd
In maximale benutting van dergelijke generieke services is nog niet voorzien.
Nader onderzoek hiernaar is wenselijk gezien de grote volumes van
berichtenverkeer naar afnemers.

BEH 1
(ALG 37)

De servicebus biedt faciliteiten voor rapportage m.b.t. frequentie, omvang, fouten
in het berichtenverkeer.
5.6.1
Voor werkende servicebussen is meer nodig dan de OSB
Servicebussen op basis van de OSB zijn een uitgangspunt voor de e-overheid. De
facilitaire services die de OSB levert betekenen echter niet dat er een kant en
klare servicebus is waar het GBA stelsel gebruik van kan maken. De OSB is
slechts een laag in het geheel aan voorzieningen dat nodig is voor het
berichtenverkeer.

90

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Figuur 39: Overzicht van de diensten die een zeer uitgebreide servicebus zou
bieden (Enterprise Service Bus)
In bovenstaande figuur kan bijvoorbeeld de leverende applicatie een onderdeel
van GBA-V zijn en de gebruikende applicatie een onderdeel van BZS-K. De OSB
specificatie legt in feite alleen de laag wachtrij / routering vast.
Nodig voor de GBA

Geleverd door OSB

transportnetwerk

Nee, maar mogelijk kan gemnet vervangen
worden door KPS (een ander onderdeel van het
programma ODP)

services die berichten verzenden en ontvangen
(adapter of gateway)

De OSB levert niet de benodigde software maar
specificeert wel waaraan deze moet voldoen.
De benodigde software is sterk
gestandaardiseerd en zowel in open source
producten als in diverse leveranciersproducten
verkrijgbaar.
OSB levert een faciliteit om te testen of een
adapter conform de specificaties werkt.

specificatie van de berichten

OSB specificeert de enveloppe, niet de
berichtinhoud. Er zijn twee specificaties binnen
OSB: ebMS en WUS.

routering en adressering

OSB levert een standaard voor het adresseren
van berichten over alle aangesloten
servicebussen.

serviceregister (dienstenbekendmaking in
Figuur 39)

Ja

zekere aflevering van berichten en
ontvangstbevestigingen

Ja, mits de ebMS specificatie wordt gevolgd

operationeel beheer van berichtenverkeer en
monitoring

Nee, dit dient door de gebruikers zelf te
worden georganiseerd afhankelijk van het
gekozen transportnetwerk.

regievoering over services / transacties

Nee, dit is wel nodig in de in hoofdstuk 5
beschreven architectuur

andere hoger niveau services als
abonnementen, validatie, quality of service

Nee, dit is deels wel nodig in de in hoofdstuk 5
beschreven architectuur

91

Definitiestudie mGBA Versie 1.8

ORG 14

De moderne GBA mogelijk gemaakt…

Gemeenten zijn zelf verantwoordelijk voor het implementeren en beheren van
een binnengemeentelijke servicebus die voldoet aan de OSB standaarden en
transparant berichten kan doorgeven van en naar de landelijke servicebus.
In variant 1 hoeft er geen
binnengemeentelijke
servicebus te zijn en kan de
aansluiting van het GBAsysteem de enige zijn op de
landelijke OSB, dan is het niet
logisch om ook nog een
binnengemeentelijke
servicebus te voorzien en
wordt deze direct
aangesloten.

In variant 2 is er altijd een
binnengemeentelijke
servicebus en geldt deze eis.

Niet van toepassing in variant
3.

Omdat de binnengemeentelijke servicebus ook benut wordt voor andere
gemeentelijke toepassingen valt deze geheel onder de verantwoordelijkheid van
de gemeente. Zolang de servicebus de specificaties van de OSB volgt en voldoet
aan de NORA eis dat de binnengemeentelijke bus verbonden is met de
landelijke OSB (de intergemeentelijke servicebus) is zeker dat het GBA-stelsel
haar diensten via deze bus kan uitvoeren.
DST 8

De servicebus voorziet in services voor procesregie.
In variant 1 is zeer
nauwkeurige specificatie
noodzakelijk om de
procesregie toegankelijk te
maken voor de systemen van
leveranciers.

In variant 2 maakt BZS-K
gebruik van de centrale
procesregiecomponent

Niet van toepassing in variant
3.

Voor de integriteit van het GBA-stelsel is het van groot belang dat berichten
aankomen bij de ontvanger en dat bij elkaar horende berichten (workflow in
Figuur 40, c.q. dienstenregievoering in Figuur 39) volledig en in juiste volgorde
worden gecommuniceerd en verwerkt. Het verzekeren van ontvangst van
losstaande berichten is ingebouwd in de protocollen voor de berichtverzending
zoals die voor de OSB gelden (ebMS). Dit is een fundamentele wijziging ten
opzichte van de huidige situatie waarin de applicaties aan weerszijde de
boekhouding ten aanzien van welke berichten verzonden en ontvangen zijn zelf
moeten doen. De sturing van de berichtencycli verplaatst van de applicaties zelf
naar de servicebus en algemene services van de servicebus. Het regisseren van
ingewikkeldere berichtenstromen zoals het eerst bijhouden van GBA-V en
vervolgens van een binnengemeentelijke afnemer of de berichtencyclus van een
vervolginschrijving vereist meer. Conform de service georiënteerde architectuur
wordt deze procesregie een aparte service van de servicebus. Aangezien de OSB
niet in dergelijke “hoger niveau” services voorziet dienen deze vanuit het GBAstelsel op de servicebus te worden aangeboden. Er zal in ieder geval een
centrale procesregieservice moeten zijn die via de OSB benaderbaar is voor al

92

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

het berichtenverkeer van en naar gemeenten. Afhankelijk van de situatie is ook
een vergelijkbare service op de binnengemeentelijke servicebus noodzakelijk.

5.7

Technische Architectuur (5.5)

Op grond van de uitgangspunten in architectuur en koppelvlakken is een
technische architectuur gerealiseerd volgens een algemeen model: de
referentie architectuur. Deze referentie architectuur kan toegepast worden
31
voor GBA-V maar in hoofdlijn evenzeer voor BZS-K en Aanvullende Modules .

Figuur 40: Referentie architectuur
In de technische architectuur is in hoge mate gebruik gemaakt van standaard
32
componenten , waardoor de ontwikkelingsinspanning kan worden
geminimaliseerd en de flexibiliteit van het resulterende systeem kan worden
gemaximaliseerd.
Het schema geeft twee dimensies weer:
1.

Verticaal is een opdeling gemaakt naar abstractie niveau. Hierin worden
drie lagen onderscheiden:
a.

Model laag. Deze laag bevat specificaties m.b.t. de wijze waarop
de onderliggende standaard componenten moeten functioneren.

31

Dezelfde referentie architectuur is met succes toegepast in de LV BAG, de landelijke
voorziening van de Basisregistratie Adressen en Gebouwen
32
Op grond van de interviews is geconstateerd dat er discussie is over de vraag of dit in
voldoende mate gerealiseerd is. Nadat het vervolgscenario gekozen is dient dit nader
onderzocht te worden zodat goed hergebruik bereikt kan worden.

93

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

De specificaties betreffen alle benodigde functionaliteit van de te
realiseren toepassing:
i. Dienstontwerp bevat de specificaties voor de benodigde
primitieve functies, waarmee de toepassing wordt
opgebouwd. In het huidige GBA-V Online is dit
dienstenontwerp niet expliciet gemaakt en voldoet het
nog niet aan de OSB specificaties en de afspraken over
beschrijving van diensten in het stelsel van
basisregistraties. Dit is voor de aansluiting op verdere
standaardisatie in de e-overheid wel van belang.
ii. De Workflow component realiseert de eerder genoemde
procesregie. Workflow bevat de sturingslogica waarmee
de primitieve functies aaneengesmeed worden tot
diensten. In het huidige GBA-V Online is deze
functionaliteit nog niet gerealiseerd, voor een efficiënte
doorontwikkeling is het belangrijk dat alsnog te doen.
iii. Object-Relational (O-R) mapping bevat de vertaling van
database gegevens in objecten die voor de dienstenlogica
betekenisvol zijn.
iv. Gegevensmodel bevat de specificatie van het relationele
model, waarmee de gegevens worden opgeslagen in de
database

2.

b.

Applicatie laag. Deze laag is grotendeels ingevuld met standaard
componenten, maar bevat ook een bibliotheek van standaard
diensten die door de andere standaard componenten worden
gebruikt om de applicatiefunctionaliteit te realiseren. Hieronder
wordt nader ingegaan op de eigenschappen van deze laag.

c.

Platform laag. Deze laag biedt de infrastructuur t.b.v. de
bovenliggende lagen op een hardware platform en operating
systeem naar keuze. Door het gebruik van deze laag wordt de
gehele architectuur onafhankelijk van het platform, waarop het
moet functioneren. De laag bevat, naast het operating systeem,
componenten, waarmee berichten worden uitgewisseld (Message
Broker), een eenvormige applicatieomgeving wordt gerealiseerd
(applicatieserver) en een database omgeving die kan worden
aangesproken op een voor de toepassing benodigde wijze
(persistentielaag en database laag)

Horizontaal is in het schema een opdeling getoond in termen van
technische resources die in elke applicatie benodigd zijn:
a.

Opslagschakel. Deze bevat de benodigde componenten t.b.v. het
kunnen opslaan van gegevens op een niet-vluchtig medium.

b.

Logicaschakel. Deze bevat de benodigde componenten voor het
kunnen uitvoeren van de gewenste business logica.

c.

Koppelingsschakel. De schakel bevat componenten om gegevens
te kunnen uitwisselen met gebruikers en/of andere systemen. Dit
is het deel dat wordt ingevuld conform de OSB specificaties.

94

Definitiestudie mGBA Versie 1.8

d.

De moderne GBA mogelijk gemaakt…

Presentatieschakel. Deze bevat de benodigde componenten om
gegevens te kunnen aanbieden in een vorm, die voor de gebruiker
en/of een ander systeem betekenis heeft.

De Applicatie laag is opgebouwd rondom een Workflow Management (WFM)
component. De WFM component bevat alle sturingslogica voor het uitvoeren
van applicatieprocessen. D.m.v. een grafische editor kan deze sturingslogica
worden onderhouden, uitgebreid en aangepast. Voor het kunnen uitvoeren van
de sturingslogica moeten handelingen worden uitgevoerd, die uiteindelijk
resulteren in het gewenste systeemgedrag. Deze handelingen worden
vastgelegd in een bibliotheek met dienstenlogica componenten. Door het
toevoegen van een component met dienstenlogica neemt het repertoire aan
beschikbare handelingen toe, waarvan gebruik gemaakt kan worden in de WFM
component. Door deze opzet ontstaat een zeer flexibele systeemstructuur,
waarmee zo nodig snel en efficiënt aanpassingen kunnen worden gerealiseerd.
Voor de doorontwikkeling is het gewenst alsnog op dit punt strikt de
uitgangspunten van een service georiënteerde architectuur te volgen.
Dienstenlogica componenten worden gerealiseerd door ze te laten acteren op
gegevensobjecten die betekenisvol zijn in de context van de dienst. Om deze
gegevensobjecten te vertalen in een systematiek, die aansluit bij relationele
databases is voorzien in een laag, waarin deze vertaling plaatsvindt. In het
schema is deze laag benoemd als persistentielaag. D.m.v. een XML specificatie,
waarin de relatie tussen het database model en de gegevensobjecten t.b.v.
diensten is vastgelegd, wordt de vertaling door de persistentielaag uitgevoerd.
Dit is in GBA-V Online nauwkeurig geïmplementeerd op basis van een open
standaard (Hibernate) die ook door andere basisregistraties voor dat doel wordt
toegepast en de facto standaard is.
Merk op dat de referentie architectuur geen aannames maakt over de invulling
van de architectuur met concrete producten. Keuzes m.b.t. de te gebruiken
producten zijn afhankelijk van omgevingsfactoren, benodigde performance en
schaalbaarheidseisen. Ook de beschikbare en gewenste beheeromgeving is
daarbij van belang. In GBA-V Online zijn inmiddels productkeuzen gemaakt. Met
name ten aanzien van de horizontale schaalbaarheid van de database dienen
keuzes nader gevalideerd te worden tegen de mogelijk fors toenemende eisen
bij verdere doorontwikkeling.
De uitwerking van de referentie architectuur voor de aanvullende module valt
buiten de scope van dit document, maar is in het kader van de PoC BZS-K nader
uitgewerkt.

95

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

6 Gegevensmodel
In dit hoofdstuk wordt op hoofdlijnen beschreven welke wijzigingen voorgesteld
worden om het gegevensmodel te verbeteren én om de gegevensset aan te
passen aan de behoeften van verschillende partijen en welke uitgangspunten
daarbij gehanteerd zijn. Bij de actualisatie van de definitiestudie is rekening
33
gehouden met de werkzaamheden van de Werkgroep GBA-gegevensset.

6.1

Gronden voor het wijzigen van het gegevensmodel en de gegevensset

In het kader van de modernisering van de GBA zijn de nodige voorstellen
gedaan om de gegevensset van de GBA aan te passen. Een quick scan onder
gemeenten en afnemers van de GBA en een NVVB-rapport “Vereenvoudiging
GBA” en enkele wensen van het Ministerie van Justitie waren in 2005 aanleiding
om wijzigingen in het GBA-gegevensmodel én de gegevensset voor te stellen. Al
deze voorstellen zijn in 2002/2003 getoetst op wenselijkheid en haalbaarheid.
Daarbij is gebleken dat de wijzigingen gerealiseerd zouden kunnen worden door
de ontwikkeling van GBA-V, BZS-K en/of een wijziging van het Logisch Ontwerp.
34
De redenen om het gegevensmodel en de gegevensset aan te passen zijn :
•

•

•

GBA als basisregistratie is wettelijk geregeld. Dit houdt in dat gegevens van
een Persoon waar een andere Persoon een relatie mee heeft (kind, ouder)
ontleend moeten worden aan de persoonslijst (PL) van de andere persoon.
In de huidige situatie ligt een deel van de persoonsgegevens van een relatie
ook in de PL vast van de “hoofdpersoon”. De persoonsgegevens liggen
zodoende op verschillende plaatsen dubbel vast en wordt er weinig
onderhoud op gepleegd waardoor vervuiling van de gegevens optreedt.
GBA-V maakt het mogelijk alleen de identificerende kenmerken van de PL
van relatie (A-nummer of BSN) op te nemen in de PL en de relatiesoort
daarbij aan te geven. Doordat men ook andersoortige relaties wil gaan
opnemen, zoals “briefadresgever”, zullen relatiegegevens vaker wijzigen
dan bijvoorbeeld gegevens over ouders. Door alleen de referenties op te
nemen, zullen gegevens minder snel verouderen.
de architectuurwijzigingen agv landelijke GBA-V. Verwijsgegevens zijn
overbodig geworden als gevolg van het feit dat alle PL-en in één landelijke
gegevensverzameling aanwezig zijn, die geraadpleegd kunnen worden;
betere aansluiting actualiteit. Op dit moment kan een PL slechts één maal
per etmaal worden gewijzigd. Aanpassing van de gegevensset is
noodzakelijk om meerdere mutaties op één dag te kunnen registreren.

33

Een verkorte versie van het gegevensmodel en een nadere detaillering van de
wijzigingsvoorstellen is in bijlage V opgenomen en bevat een voorbeeld van een PL in het
bestaande en het nieuwe model. In PoC BZS-K is een voorlopige versie van het nieuwe
model gerealiseerd; Bijlage II bevat een beschrijving van deze implementatie.
34
Genoemde redenen zijn afkomstig van verschillende documenten van werkgroep
Gegevensset.

96

Definitiestudie mGBA Versie 1.8

•

•

•
•

De moderne GBA mogelijk gemaakt…

vereenvoudiging van de bijhouding. De structuur van de GBA-gegevens is
complex, waardoor de bijhouding ook als complex wordt ervaren. Een
vereenvoudiging in de structuur helpt bij het vereenvoudigen van de
bijhouding, waardoor het ook eenvoudiger wordt om personen op te leiden
en er minder fouten op zullen treden;
gebruikers van de GBA doen regelmatig voorstellen voor aanpassing van de
gegevensset. Het toevoegen of schrappen van gegevens. Een aantal
wijzigingsvoorstellen die door de Stuurgroep Modernisering GBA eerder zijn
goedgekeurd worden in de volgende paragraaf behandeld;
opschoning van ongebruikte gegevens; [15]
om te kunnen voldoen aan de NORA-principes, moet de nodige redundantie
uit de gegevensset gehaald worden en moeten de metagegevens worden
ingericht.

6.2

De belangrijkste wijzigingen (4.1)

Een Persoonslijst is het geheel aan gegevens dat over een persoon in de GBA is
opgenomen. De persoonslijst is opgebouwd in verschillende deelverzamelingen
van gegevens. De persoonslijst in het huidige LO3.6 in de gemeentelijke
administraties, is maximaal opgebouwd uit 15 actuele categorieën (er even
vanuit gaande dat KIND gezien wordt als één categorie, onafhankelijk van het
aantal kinderen). De GBA-V bevat kopieën van de categorieën 1 tot en met 14
van alle persoonslijsten en de bijbehorende historie categorie 51 tot en met 64.
Verwijsgegevens zijn niet opgenomen in de GBA-V. Een verwijzing is een van de
persoonslijst afgeleide verzameling gegevens die verwijzen naar een volgende,
niet noodzakelijk huidige, gemeente van inschrijving. Categorie 15 van de PL’en
is leeg gelaten.
Na de oplevering van de Definitiestudie Startpakket GBA (2005) is een
werkgroep Gegevensset ingesteld en heeft de wijzigingsvoorstellen nader
uitgewerkt en onderzocht, en in de vorm van wijzigingsadviezen aan de
stuurgroep mGBA voorgelegd. Uit verslaglegging is gebleken dat op 16 maart
2006 de stuurgroep mGBA de adviezen overgenomen. De wijzigingsadviezen
hadden betrekking op:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

Scheiding administratieve historie en historie van de persoon
Historie per groep
Opnemen van historie
Logboek
Verstrekken van gegevens
Relaties (gerelateerde personen)
Briefadressen
Brondocumenten
Gebeurtenissen
Verstrekkingsbeperking
Standaardwaarde en onbekend
Coderingen
Schoning van bestanden
Tabel en tabelinhouden
Reisdocumenten
Kiesrecht

97

Definitiestudie mGBA Versie 1.8

•
•
•
•

De moderne GBA mogelijk gemaakt…

Geprivilegieerden
Nationaliteit
Naamgegevens
Gezag van rechtswege als aanvullende module

Afgewezen of aangehouden zijn:
• Aanschrijfadressen
• Opgeschorte PL-en
• Signalering op PL
Ten behoeve van de definitiestudie in 2005 zijn deze voorstellen nog een keer
onder de loep genomen en aangescherpt, mede in het licht van de
mogelijkheden van BZS-K en GBA-V. De komst van GBA-V in de huidige situatie
heeft het mogelijk dat bepaalde gegevens nu al overbodig zijn geworden, omdat
alle PL-en centraal ter beschikking zijn van afnemers. De komst van een
eventueel BZS-K biedt daarbij mogelijkheden om het model grondig te herzien.
Op dit moment (anno 2008) wordt voorzien om een aantal wijzigingsvoorstellen
in normale nieuwe releases van het LO3.x op te nemen, omdat als gevolg van
nieuwe wetgeving aanpassing noodzakelijk is, vermoedelijk al vóór de
implementatie van een eventueel BZS-k (bijvoorbeeld de koppeling met de BAG
35
in LO3.7) .
In de overgangsperiode is het noodzakelijk om in GBA-V gedurende een langere
periode LO3.x en LO4 gegevensmodellen over en weer te kunnen converteren
en deze conversie te toetsen en monitoren, zonder dat dit ingrijpt in de
dagelijkse praktijk van gemeenten en afnemers. Dit speelt bijvoorbeeld in geval
een persoon verhuist van een gemeente met LO3.x naar een gemeente met het
LO4 gegevensmodel en vice versa. Wel is tijdens diverse POC’s in de inceptiefase
geconstateerd dat er gegevensverlies op kan treden als gevolg van verschillen in
gegevensset tussen LO3.x en LO4 [18]. Hierbij speelt dan het logboek een
belangrijke rol.

6.3

De NORA-eisen mbt GBA-gegevens

Voor het leveren van diensten aan burgers en services aan de afnemers zijn in
veel gevallen gegevens uit de GBA noodzakelijk. Er zijn in de NORA een aantal
principes gedefinieerd waarmee het gebruik van de gegevens uit
basisregistraties, o.m. de GBA, mogelijk wordt. Daarbij valt te denken aan
afspraken over toegankelijkheid van de gegevens, verantwoordelijkheden voor
36
beheer, betekenis van de gegevens et cetera . In deze paragraaf worden de
meest relevante NORA-principes voor de mGBA besproken.

35

Memo Inhoud LO3.7: Gebruikersoverleg 2 sept 2008, van BPR, afdeling S&A onderdeel
K&E.
36
Hoofdstuk 6 NORA 2.0

98

Definitiestudie mGBA Versie 1.8

Bert Burger woont in gemeente
Woerden en werkt in gemeente
Utrecht. Hij wil in de lunch bij het
gemeentehuis van Utrecht een nieuwe
paspoort aanvragen. De gemeente
Utrecht past na uitgifte van het nieuwe
reisdocument de rubriek in de
Persoonslijst van Bert Burger aan,
waarin het nummer van het
reisdocument wordt aangepast.

De moderne GBA mogelijk gemaakt…

6.3.1
Eigenaar en bronhouder van gegevens
Gegevens zijn statisch en worden beheerd door een organisatie. Gemeenten zijn
verantwoordelijk voor de bijhouding van de gegevens van de personen die
woonachtig zijn in de eigen gemeente. Elke wijziging wordt in een logboek
vastgelegd. Door de introductie van plaatsonafhankelijk werken, kan “over de
eigen gemeentegrenzen” gemuteerd worden in persoonslijsten van inwoners
van andere gemeenten.
Door de bijhouding van het logboek wordt het mogelijk te achter halen, wie
welke gegevens aangepast heeft in de PL. Daarmee ontstaan nieuwe
mogelijkheden om een gedeelde verantwoordelijkheid over de gegevens van
één PL in te stellen. Dit sluit aan bij het NORA-principe 6.2.3.4 Elk gegeven kent
een eigenaar en een beheerder. De eigenaar van een gegeven is
verantwoordelijk voor de kwaliteit (actualiteit, betrouwbaarheid) van een
gegeven. (NORA 6.2.3.5) Op stelselniveau wordt vaak het begrip “bronhouder”
gehanteerd als zijnde de “eigenaar” van het gegeven.

6.3.2
Metagegevens
Voor het ontsluiten van informatie (gegevens) is het essentieel dat er landelijke
37
afspraken zijn over de metagegevens . Advies@Overheid heeft een voorstel
gemaakt voor een landelijke set met metagegevens voor het ontsluiten van
informatie. Dit betreft een uitbreiding op de Dublin Core Standaard tot de
standaard Dublin Core Government. Daarnaast heeft een werkgroep
Metagegevens in het Stelselhandboek een aantal richtlijnen uitgewerkt. Daarin
is de minimale set van metagegevens en afspraken uitgewerkt, die
basisregistraties moeten opnemen omschreven om het stelsel te laten werken.
In de RSGB is daarvan gebruik gemaakt. (NORA-6.2.3.1) Binnen de e-overheid
worden metagegevens geregistreerd op het moment dat brongegevens worden
ontvangen of zaakgegevens wijzigen. Bij voorkeur geschiedt dit automatisch.
Het gaat hierbij om metagegevens die van gemeenschappelijk belang zijn en
geleverd kunnen worden door elke basisregistratie. Door Snellen is in de eisen
aan GBA is opgenomen dat de basisregistratie integraal onderdeel is van het
stelsel van basisregistraties. Daarmee is GBA ook genoodzaakt om aan deze
afspraken te voldoen. Daarvoor is één van de wijzigingen in het gegevensmodel
nodig, het vastleggen van datum en tijdstip van registratie in het logboek.
De metagegevensset in de GBA bevat nu ten minste:
Stelselhandboek

Wijze van implementatie binnen GBA LO3.6
(administratieve gegevens)

Datum ingang + einde geldigheid (evt met
tijdsaanduiding)

Categorieën zijn opgebouwd uit
gegevensgroepen. Per groep wordt de
geldigheid (groep 85) geregistreerd. Waarin
alleen nog de begindatum geldigheid is
opgenomen. Tijdstip wordt thans niet

37

Metagegevens zijn gegevens óver gegevens.

99

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

opgenomen in het GBA. Knelpunt: slechts één
mutatie per dag mogelijk, door ontbreken van
tijdsaanduiding.
Datum en tijdstip van registratie

Per categorie wordt de opneming vastgelegd op
datum.

Indicatie authentiek

Dit is in de wet geregeld, maar is niet in het
model terug te vinden.

Indicatie bijhouding opgeschort

Dit wordt in een categorie (7 inschrijving)
geregistreerd

Indicatie “geheim”

Dit wordt in een categore (7 inschrijving )
geregistreerd.

Indicatie “in onderzoek”

Op categorie-niveau wordt in de
gegevensgroep Procedure het metagegeven
gebruikt om kenbaar te maken dat een
categorie per bepaalde datum “in onderzoek”
staat.

De gemeente die verantwoordelijk is voor een PL waarbij de indicatie “in
onderzoek” is geplaatst één of meer categorieën, houdt daarvan een
onderzoeksdossier bij, ook voor onderzoeken als gevolg van
binnengemeentelijke terugmeldingen, waarbij geen gebruik wordt gemaakt van
de TMV. Veel gemeenten hebben op dit moment interne procedures (voor
binnengemeentelijke afnemers), waarbij geen gebruik gemaakt wordt van de
landelijke TMV. Voor landelijke afnemers biedt de TMV de mogelijkheid om op
de hoogte te blijven van de status van de behandeling van een terugmelding.
Een terugmelding wordt in een dossier aan een PL gekoppeld door de TMV. De
gemeente zal de terugmelding (dus het dossier) in behandeling nemen en
daarvan een onderzoeksdossier aanleggen. Het onderzoeksdossier kan
relevante informatie bevatten over de persoon, waarmee bij een
buitengemeentelijke verhuizing de ontvangende gemeente geholpen wordt bij
het actualiseren van de PL.
Bij de buitengemeentelijke verhuizing van een persoon, meldt de persoon zich
aan de balie van een nieuwe gemeente en zal het beheer van de PL uiteindelijk
overgenomen worden door de nieuwe woonplaats (gemeente) van de persoon.
Het onderzoeksdossier én de PL wordt aan de nieuwe gemeente ter beschikking
gesteld. De verantwoordelijkheid voor het onderzoek verhuist dus mee.
Gegevensverzamelingen die eigendom zijn van een overheidsorganisatie
worden – met in achtneming van nadere wettelijke regels – ter beschikking
gesteld aan de gehele overheid (NORA 6.2.3.6). Dit NORA-principe wordt
gerealiseerd door de GBA-V in te zetten als distributie (bron) voor
persoonsgegevens naar de afnemers.
Van geleverde gegevens is de kwaliteit bekend (NORA 6.2.3.7). Indien een
afnemer op de hoogte wenst te blijven van de gegevens en daarvoor een
afnemersindicatie geplaatst heeft bij een persoonslijst binnen de GBA-V, wordt
deze ook op de hoogte gebracht van het feit dat het “actuele gegeven” in
onderzoek is. Daarmee wordt een uitspraak gedaan over de kwaliteit van de
gegevens. In juridische zin heeft dat consequenties. De afnemer zal dan zelf
besluiten om eventueel het juiste gegeven bij de burger zelf op te vragen.

100

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

6.3.3
Semantiek
De gebruiker van het gegeven moet de betekenis van het gegeven kennen of
kunnen herkennen. Daarvoor worden semantische modellen opgesteld. Bij het
GBA is het gegevenswoordenboek onderdeel van het LO en fungeert als een
semantisch model. Op stelselniveau wordt ondermeer gewerkt met de
stelselcatalogus.
Gegevens- en procesinhoudelijke communicatiestandaarden moeten een
semantisch model bevatten of verwijzen naar een zodanig semantisch model.
(NORA 6.2.4.1)
Semantische modellen zijn technologie-neutraal (NORA 6.2.4.2). Waar haalbaar
onderscheidt een semantisch model expliciet objecten en
gebeurtenissen.(NORA 6.2.4.4). De definitie en taxonomie van gegevens die zijn
opgenomen in nationale basisregistraties zijn leidend. (NORA 6.2.4.5) Dit heeft
consequenties voor zowel RSGB, die gegevens uit de PL conform GBA moet
opnemen. Daarnaast zal GBA conform andere basisregistraties moeten
definiëren zoals Adresgegevens uit de BAG.
Objecten worden op een systematische wijze beschreven. (NORA 6.2.6.5) Voor
het Stelsel betekent dit dat de definitie van Ingezetene (in GBA Persoon)
afkomstig is uit de GBA. Een naamswijziging van het object Persoon uit het GBA
is noodzakelijk, om het consistent te kunnen toepassen in het Stelsel van
basisregistraties.

6.4

Referentiemodel Stelsel van Gemeentelijke Basisgegevens (4.1.1)

Een belangrijk uitgangspunt van het programma “Andere overheid” is het
algemene principe van “eenmalige verstrekking, meervoudig gebruik”. Dit houdt
in dat een burger (alle wijzigingen in) zijn gegevens één maal verstrekt aan de
overheid en dat de overheid er vervolgens zelf voor zorgt dat deze gegevens
overal waar nodig bekend worden gemaakt. De invoering van een
overheidsbreed stelsel van basisregistraties is één van de meest ingrijpende
ontwikkelingen waarmee gemeenten de komende jaren te maken krijgen. Het
referentiemodel “Stelsel van Gemeentelijke Basisgegevens” (RSGB) biedt
gemeenten en hun leveranciers houvast bij het invoeren en het gebruiken van
deze gegevens.

De gebruikers van deze gegevens kunnen ofwel de authentieke registratie
raadplegen op het moment dat ze de gegevens nodig hebben, ofwel een
schaduwadministratie bijhouden middels een abonnementensysteem. Het is de
bedoeling dat de gemeenten hun gegevenshuishouding in de geest van het
referentiemodel in de komende periode geleidelijk in te voeren. Bij de
totstandkoming van de RSGB is o.m. gebruik gemaakt van de modelwijzigingen
die voorzien waren in de definitiestudie Startpakket GBA 2005.

101

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Figuur 41: Objectmodel RSGB11
In het RSGB is het GBA-aandachtsgebied terug te vinden in het objecttype
NATUURLIJK PERSOON.

102

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

natuurlijk persoon
Ingeschreven persoon
Bert
Burger

Heinz
Deutscher

Ander
Buitenlands
Natuurlijk
persoon

Overige
persoonsrelatie

kind-relatie

ouder-relatie

Partner-relatie

Objecttype niet in
landelijke
administratie

Objecttype niet in
GBA ( RNI )

Objecttype in GBA

Figuur 42: View op objectmodel Natuurlijke persoon RSGB
Bovenstaande figuur is een view op een deel van het objectmodel “Detaillering
subjecten en vestigingen”[28]. Het is dus geen één-op-één overgenomen figuur.
Een natuurlijk persoon komt in verschillende wetgeving terug. Zo is een
ingeschreven persoon, een persoon van wie een persoonslijst in een
basisadministratie is opgenomen, conform de Wet GBA of RNI. Daaruit blijkt al
dat een ingeschreven persoon weer in te delen is in twee specialisaties, namelijk
een INGEZETENE of een NIET-INGEZETENE.

Bert Burger is een ingeschreven
persoon èn ingezetene. Hij is
geregistreerd in de GBA. Heinz
Deutscher was ooit ingezetene, maar is
geëmigreerd en opgenomen in de RNI
vanwege professionele redenen of
vanwege het bezit van een
vakantiewoning in Nederland. Heinz
heeft een relatie gehad met Bert
Burger, bijvoorbeeld. In de historie van
de PL-en komt informatie over de
partner-relatie voor.

De ingezetene persoon is de persoon zoals door de GBA benoemd en
geadministreerd wordt en betreft de INGESCHREVENE die niet overleden is of
niet geëmigreerd is. De wet beschrijft dit op de volgende wijze “wiens
persoonslijst niet het gegeven van zijn overlijden of van zijn vertrek uit
Nederland als actueel gegeven is opgenomen”.
Zoals reeds aangegeven is, worden in het huidige GBA gegevens over relaties
(o.a. ouders, kind en partners) dubbel geregistreerd. Om het hergebruik van
gegevens te benadrukken waarbij alleen referenties naar relaties worden
opgenomen in de PL, wordt in het RSGB informatie over relaties tussen
personen in aparte objecttypen gemodelleerd. Hiermee wordt voorkomen dat
relatiegegevens op verschillende plaatsen in de GBA-administraties worden
opgenomen en onderhouden moeten worden.
NB: Het begrip INGEZETENE is een homoniem, ofwel hetzelfde begrip heeft
verschillende betekenissen. In vele stukken wordt INGEZETENE gebruikt binnen
de gemeentelijke context om aan te geven, dat een burger ingezetene dus
inwoner is van een gemeente. Een NIET-INGEZETENE zou dan persoon zijn die
woonachtig is in een andere gemeente. Daar hoeft dus niet altijd sprake van te
zijn. Een NIET-INGEZETENE kan geregistreerd zijn in de RNI en hoeft niet
woonachtig te zijn in een Nederlandse gemeente.
Het Agentschap BPR is niet betrokken geweest bij de totstandkoming van het

103

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

RSGB. In het RSGB is een model ontwikkeld, dat gemeenten kunnen gebruiken
bij het inrichten van hun gegevenshuishouding. Op bepaalde aspecten rondom
NATUURLIJKE PERSOON worden relaties gesuggereerd, bijvoorbeeld tussen een
Ingezetene en Niet-ingezetene, waarvan in het LO4 gegevensmodel nog geen
sprake is. Ook de relatietypen (relaties tussen natuurlijke personen) en
gehanteerde begrippen wijken af van het LO. Nadere afstemming tussen het
LO4 gegevensmodel en RSGB zal nog moeten plaatsvinden. [26]

6.5

Enkele voorbeelden

Verwijsgegevens zijn in de huidige (gemeentelijke) GBA opgenomen om te
garanderen dat het altijd mogelijk is om de huidige gemeente van inschrijving te
bepalen, als iemands geboorteplaats of een tussentijdse woonplaats bekend is.
GEG8
(ALG 7 & 19)

Het bestaan van GBA-V maakt verwijsgegevens overbodig. De verwijsgegevens zijn
38
daarom vervallen .
In de GBA-V zijn geen verwijsgegevens opgenomen. Indien de gemeente van
“vertrek” geïnteresseerd blijft in de PL, is er de mogelijkheid om een
afnemersindicatie te plaatsen op een PL bij uitschrijving, mits daar een
wettelijke basis voor is. Eventueel kan er voor worden gezorgd dat deze
indicatie bij een vervolginschrijving automatisch wordt geplaatst.
De beheerorganisatie kan daarnaast bij gebleken behoefte een dienst inrichten
die in opdracht van gemeenten op maat gemaakte bevragingen uit¬voert op het
39
GBA-V-bestand. Door middel van een GABA -koppeling kan een gemeente een
bevraging doen op persoonsgegevens in GBA-V van buitengemeentelijke
personen om eventuele vragen te beantwoorden.

6.5.1
Historie
In de bijhouding van de PL treden verschillende knelpunten op die gerelateerd
zijn aan de behandeling van historie.
1. Historie van de PL en historie van de persoon
2. Historie in op categorie en groepen
3. Verschilberichten
4. Einddatum geldigheid in historische categorieën
5. Volgorde historische categorieën
Een oplossing van de verschillende knelpunten wordt gevonden door de
inrichting van een logboek.
GEG 9

De administratieve levensloop moet gereconstrueerd kunnen worden aan de hand
van voorgedefinieerde gebeurtenissen

38
39

ALG 19 vervangt ALG7 uit vorige DS, was dubbelop
Gemeente als Buitengemeentelijke Afnemer (GABA)

104

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Historie van de PL en historie van de persoon (4.1.5)
De huidige opzet van de GBA kent in feite twee soorten historie op een PL:
gegevens over de historie van een persoon (eerdere adressen en ontbonden
huwelijken bijvoorbeeld) en gegevens over de historie van de PL (gegevens die
onjuist zijn bevonden en die met de markering onjuist in de historie zijn
opgenomen, de historie van de bijhouding).
In het nieuwe model worden deze twee gescheiden:
•

In een nieuw onderdeel van de PL, het LOGBOEK, wordt bijgehouden
wat de geschiedenis van de bijhouding is.

•

De rest van de PL bevat alleen nog historie van de persoon.

Vanaf het moment dat vaststaat dat de gegevens onjuist zijn worden de
historische gegevens vanuit de huidige GBA in feite nog maar één maal
verstrekt: op het moment dat de melding over het onjuist zijn wordt verstuurd.
Daarna worden onjuiste gegevens niet meer in de gegevensverstrekking
betrokken.
GEG10
(ALG 22)

In het nieuwe gegevensmodel is het uitgangspunt dat er alleen “juiste” historische
gegevens van de persoon worden opgenomen.
Dit geldt voor migratie naar
het LO4 gegevensmodel

Dit geldt voor migratie naar
het LO4 gegevensmodel

Hierbij wordt uit gegaan van het feit dat de historie van de PL alleen van belang
is voor het afleggen van verantwoording over de bijhouding; om daarin te
voorzien wordt per PL een gestructureerd logboek bijgehouden waarin de
administratieve historie wordt vastgelegd. Het logboek maakt zelf deel uit van
de PL en bevat een aantal gestructureerde gegevens die het mogelijk maken om
snel en efficiënt te zoeken, maar er is ook ruimte voor een tekstveld waarin een
ambtenaar in eigen bewoordingen kan toelichten wat er is gebeurd.
Gegevens uit het logboek worden alleen bij uitzondering aan de afnemers
verstrekt.
Historie categorieën en groepen (4.1.4)
In het huidige model zijn de gegevens ingedeeld in categorieën en daarbinnen in
28 groepen. Categorieën worden op twee manieren gebruikt: als basis voor
herhaling en als basis voor aanleggen historie. Dat laatste houdt in dat als er één
gegeven wijzigt in een categorie, in de huidige situatie de hele categorie
historisch wordt en een nieuwe categorie wordt aangelegd. In de nieuwe
situatie wordt alleen de groep historisch.
GEG11
(ALG 21)

In het nieuwe gegevensmodel is de categorie de basis voor gegevens die herhaald
kunnen voorkomen. Historie wordt aangelegd op het niveau van groepen.
Dit geldt voor migratie naar
het LO4 gegevensmodel

Dit geldt voor migratie naar
het LO4 gegevensmodel

105

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Hierdoor wordt het aantal gegevens in de historie beperkt en is bij het
teruglezen van historie veel duidelijker wat er precies gewijzigd is.
Het bijhouden van historie per groep betekent dat een aantal administratieve
gegevens die nu per categorie voorkomen (zoals datum ingang geldigheid) in
het nieuwe model in iedere groep voorkomen.
Verschilberichten
Bij de opzet van de GBA is er voor gekozen om spontane verstrekkingen te doen
in de vorm van een verschilbericht. Het bericht Gv01-bericht bevat een
wijziging, dus eerst het oude gegeven en daarna het nieuwe gegeven. Als het
een gegeven is, dat is toegevoegd dan blijkft het oude gegeven leeg. En als het
een correctie betreft wordt aan het oude gegeven de indicatie ‘onjuist’
toegevoegd.
In de nieuwe opzet wordt gekozen om geen verschilberichten meer te
verzenden, maar bij wijziging krijgt de afnemer alle gegevens waar hij recht op
heeft. In feite is dat hetzelfde principe dat wordt toegepast bij vulberichten.
Einddatum geldigheid in historische categorieën (4.1.6)
In het huidige model LO3.6 wordt bij een categorie alleen de ingangsdatum
geldigheid opgenomen. De einddatum wordt impliciet vastgelegd: het is de
ingangsdatum van de volgende categorie. Dit leidt tot een aantal kunstmatige
bijhoudingsvoorschriften die ook weer voor interpretatieproblemen kunnen
zorgen.
In het nieuwe model is daarom overal rekening gehouden met een einddatum
geldigheid. Dit betekent ook dat er geen aparte rubrieknummers meer nodig
zijn om historische gegevens aan te duiden: een gegeven is historisch op het
moment dat de einddatum geldigheid is ingevuld en deze datum in het verleden
ligt. Dit is een iets andere benadering dan op dit moment geldt, een gegeven
wordt historisch gemaakt door op te nemen wat de einddatum geldigheid is (en
niet meer door een categorienummer aan te passen).
Volgorde historische categorieën (4.1.7)
In het LO staan nu tamelijk complexe voorschriften om te bepalen wat de
volgorde van historische gegevens is bij gegevensuitwisseling. Daarbij wordt
gebruik gemaakt van de ingangsdatum geldigheid en van datum opneming in de
GBA. In bepaalde gevallen komt het voor dat categorieën in een
gebruikersonvriendelijke volgorde gepresenteerd worden aan de medewerker,
waardoor er fouten kunnen ontstaan.
In het nieuwe model wordt dit voorschrift aangepast. Gegevens worden
gesorteerd in de historisch juiste volgorde (voor zover bekend uiteraard). BZS-K
zorgt er (middels een technische voorziening) voor dat dit verband wordt
vastgelegd, ook in de gevallen waarin dat niet direct uit de datums zelf blijkt
(bijvoorbeeld een gedeeltelijk ingevulde datum of twee dezelfde datums). De
voorschriften voor ordening hebben alleen betrekking op de uitwisseling van
gegevens met afnemers en tussen gemeenten onderling.
Ook de regels wanneer wel en wanneer geen historie wordt bijgehouden zijn
aangepast. In beginsel wordt er in het nieuwe model altijd historie aangelegd.
Bij sommige gegevens worden voorschriften opgenomen die de historie in

106

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

omvang beperken door een periodieke schoningsactie. Dit geldt bijvoorbeeld
voor reisdocumenten, die na 11 jaar worden verwijderd van de PL.

6.5.2
Relaties (Gerelateerden) (4.1.3)
De manier waarop gerelateerden nu in de GBA zijn opgenomen is een
compromis. Er wordt een subset van de persoonsgegevens bijgehouden die in
veel gevallen functioneel voldoende is. Ze worden echter niet geactualiseerd
(behoudens de situatie dat de PL van de gerelateerde wordt opgenomen in
dezelfde gemeente) en de subset voldoet niet altijd. Deze subset was
noodzakelijk omdat gemeenten alleen over de eigen PL’en kon beschikken en de
gegevens van de gerelateerde al of niet in een andere gemeentelijke
administratie stond.

Figuur 43: Redundante gegevensopslag

107

Definitiestudie mGBA Versie 1.8

GEG12
(ALG 6)

De moderne GBA mogelijk gemaakt…

Gegevens van gerelateerden (ouders, kinderen, echtgenoten/partners) worden
alleen nog opgenomen op een PL indien deze gerelateerden zelf niet ingeschreven
40
zijn in de GBA . Indien de gerelateerde wel is ingeschreven wordt alleen een
verwijzing middels een A-nummer opgenomen (zie ook GEG13 en ORG 9).
NB: Voor personen die niet ingeschreven zijn in GBA wordt een soort ”pseudoPL” aangelegd in het vervolg wordt dit aangeduid met RPL. Deze RPL bevat de
subset van gegevens zoals die nu al wordt vastgelegd voor gerelateerden. Deze
gerelateerden krijgen geen A-nummer maar een R-nummer dat is afgeleid van
het A-nummer van de persoon; ze kunnen ook niet rechtstreeks worden
bevraagd maar alleen via de PL van de persoon met wie ze een relatie
41
hebben .

De algemene richtlijn van eenmalige verstrekking (NORA 6.5.1.2) werkt op dit
punt door in het nieuwe gegevensmodel. Immers, als een gerelateerde zelf is
ingeschreven in de GBA dan is zijn/haar PL de authentieke bron van gegevens.
De gegevens van de gerelateerde moeten dan dus middels een abonnementen
systeem worden geactualiseerd of de gebruiker van de gerelateerde gegevens
moet worden doorverwezen naar de PL van de gerelateerde. Dit laatste is het
eenvoudigst en wordt daarom voorgesteld als werkwijze in de vernieuwde GBA.
GEG13
(ALG 20)

In het nieuwe datamodel wordt van gerelateerden alleen het A-nummer en BSN
opgenomen, alsmede de gegevens over de relatie zelf.
Dit geldt voor migratie naar
het LO4 gegevensmodel.

Dit geldt voor migratie naar
het LO4 gegevensmodel

Bijvoorbeeld bij een huwelijk bevat een PL dus aktenummer en de gemeente
waar het huwelijk is gesloten, alsmede A-nummer en BSN van de partner – maar
niet zijn/haar naam. Deze moet in voorkomende gevallen ontleend worden aan
de PL van de partner.

40

Bij inwerkingtreding van RNI zal deze eis kunnen vervallen, als GBA én RNI een alles
afdekkende populatie hebben van alle natuurlijke personen waarmee de overheid een
relatie heeft.
41
NB: De stuurgroep heeft ingestemd met deze voorgestelde modelwijziging, mits voldaan
wordt aan de voorwaarde dat de bijhouding van de RPL beperkt blijft tot de gegeven die nu
ook al worden vastgelegd van een gerelateerde. De RPL is niet rechtstreeks benaderbaar,
alleen via een PL.

108

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Figuur 44: De oude en nieuwe PL-structuur
De PL ziet er qua structuur eenvoudiger uit, omdat er verschillende soorten
relaties voorkomen en het aantal categorieën is terug gebracht door de
verwijzing naar PL-en dmv A-nummers en het BSN.
De enige uitzondering op deze regel is de Beheer Voorziening (BV) van het BSN
stelsel: als een gemeente daar een verificatievraag stelt in het kader van een
eerste inschrijving wordt wel in de verzameling RPL’en gekeken of er al een RPL
aan is gemaakt van de betreffende persoon die zich wil laten inschrijven. De BV
kan dan dus als antwoord krijgen dat de nieuw in te schrijven persoon al bekend
is als (bijvoorbeeld) een ouder van een ingeschrevene. Nadat de persoon is
ingeschreven kan vervolgens met de procedure “actualiseren gerelateerden”
worden gezorgd, dat de verwijzing naar de RPL wordt vervangen door een
verwijzing naar de nieuw ingeschrevene. Ofwel de persoon krijgt een nieuw
Burgerservicenummer dat als verwijzing zal dienen in de PL van de
ingeschrevene.
Met dit geheel aan maatregelen wordt voorkomen dat het vernieuwde stelsel
op dit punt minder functionaliteit zou bieden dan het bestaande.
Relaties zijn generiek, ze bevatten als onderdeel van de relatiesgegevens een
indicatie van het soort relatie. Dit houdt in dat het begrip RELATIE eenvoudig
kan worden uitgebreid met nieuwe soorten relaties. De werkgroep gegevensset
heeft geadviseerd om de noodzaak voor het uitbreiden van het begrip RELATIE
42
in overleg met CZW plaats te laten vinden, omdat het mogelijk strijdig is met

42

(dienst Constitutionele Zaken en Wetgeving bij Min van BZK)

109

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

uitgangspunten van de EU-privacy richtlijn. De werkgroep heeft voorgesteld dit
punt aan te houden voor nader onderzoek. Daarop is geconstateerd dat er geen
43
strijdigheden zijn op dit punt.

6.5.3
BAG-koppeling (Adressen en locaties) (4.1.10)
Iedere gemeente is verplicht voor eind 2009 een eigen Basisregistraties
Adressen en Gebouwen (BAG) in te richten en deze aan te sluiten op de
Landelijke Voorziening BAG (LV BAG). De BAG bevat gegevens over adressen en
gebouwen en geeft zekerheid over het bestaan van een bepaalde
adresaanduiding door deze te koppelen aan een gebouw of een deel van een
gebouw. Tussen het gemeentelijke BAG systeem en de LV BAG vinden
soortgelijke processen plaats als tussen de burgerzakensystemen en GBA-V. Alle
burgers in de GBA hebben in principe een woon- of briefadres dat overeen moet
komen met een adresaanduiding in de BAG en die dus gerelateerd is aan een in
de BAG gekend gebouw.
In het nieuwe model is rekening gehouden met de komst van een authentieke
registratie Adressen en Gebouwen (BAG); een GBA adres kan verwijzingen naar
deze registratie bevatten en er zijn enkele wijzigingen aangebracht die
44
anticiperen op voorstellen die door het BAG-project zijn gedaan . De
wijzigingen houden in dat er twee nieuwe rubrieken worden opgenomen in de
gegevensset, waarin de identificatiecode nummeraanduiding en de
verblijfsobjectcode worden vastgelegd. Het zijn codes die horen bij het
verblijfsobject en de daaraan gekoppelde nummeraanduiding. Een ander
aanvulling is de invoering van een nieuwe rubriek waarin altijd de straatnaam
kan worden vastgelegd, zoals die door het gemeentebestuur is vastgesteld, dus
niet afgekort. Daarnaast wordt een nieuwe rubriek voorzien voor de woonplaats.
De BAG heeft een “sluitende” woonplaatsentabel, in het GBA komen codes
waarmee de vastlegging van woonplaatsen wordt gerealiseerd. De codes
verwijzen naar een woonplaats in de woonplaatstabel van de BAG. Deze
wijzigingen worden voorzien in LO3.7.
Aangezien het bepalen van het woon- of briefadres onderdeel is van de aangifte
van de burger en dus onderdeel wordt van de dienst “bijhouden GBA”, wordt de
relatie tussen een ingezetene (burger) en de aanduiding van zijn woon- of
briefadres onder verantwoordelijkheid van burgerzaken gelegd en opgenomen
in de GBA. In het kader van het stelsel van basisregistraties is de gemeente
verplicht bij het leggen van deze relatie de BAG te gebruiken. Deze verplichting
geldt op grond van de wet BAG vanaf welke op 22 febr door de Eerste Kamer is
aanvaard. Er is een overgangstermijn ingesteld, tot medio 2011. Daarenboven
volgt uit de verplichtingen van het stelsel van basisregistraties dat ieder keer
wanneer een verstrekking gedaan wordt van gegevens uit de GBA de juiste
adresaanduiding moet worden meegeleverd. Juist wil in dit geval niet alleen

43
44

Toelichting Mevr. Esther ’t Hoen, Min Bzk.
Verslag Gebruikersoverleg GBA 2-09-2008, BPR afd S&A onderdeel K&E

110

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

zeggen de adresaanduiding die overeenkomt met de laatste aangiften etc. die
bepalen op welk adres de betreffende persoon woont volgens de GBA maar ook
met een adresaanduiding die exact overeenkomt met de vastlegging in de BAG.
Het mag niet zo zijn dat de gemeente een pand gesplitst heeft waardoor de
huisnummers gewijzigd zijn en dat dat al vastgelegd is in de BAG terwijl
diezelfde gemeente vanuit de GBA nog de adresaanduiding levert van voor de
splitsing. Dit kan op twee manieren bereikt worden:
•

In de GBA wordt alleen het referentienummer van de adresaanduiding
opgenomen en bij iedere bijhouding of verstrekking waarbij het adres nodig
is wordt dit aan de hand van het referentienummer opgehaald uit de BAG.

•

In de GBA worden naast het referentienummer ook de andere gegevens
betreffende de adresaanduiding opgenomen die de wet GBA voorschrijft.
Middels een abonnementensysteem wordt gezorgd dat wijzigingen in die
adresaanduidingen in de BAG worden doorgestuurd naar GBA en daar
verwerkt.

In beide gevallen dient iedere keer wanneer een nieuw adres opgenomen wordt
in de GBA de adresaanduiding opgezocht te worden in de BAG om de relatie te
leggen en in geval van de tweede bovengenoemde mogelijkheid te zorgen dat
het abonnement dienovereenkomstig aangepast wordt.
In scenario 1 is de gehele
benodigde functionaliteit
onderdeel van de GBA
systemen die door
leveranciers worden
aangeboden. De
gemeentelijke BAG applicaties
worden ook door
marktpartijen aangeboden.
Het is aan de markt om zelf de
verschillende combinaties
tussen GBA en BAG systemen
mogelijk te maken.
Een LO 3.7 is reeds in
voorbereiding om de
koppeling te specificeren.
Deze zou zodanig moeten zijn
dat scenario 1 daar geen
majeure wijzigingen op
veroorzaakt.

Scenario 2. De relatie wordt
gelegd in de dienst bijhouding.
De BAG services om een
adresaanduiding te vinden en
de relatie te leggen worden
vanuit de Aanvullende
Modules aangeroepen en de
bijhoudingsservices van BZS-K
vereisen een reeds gelegde
relatie met BAG als
voorwaarde voor een correct
adres. Voorzieningen voor het
ophalen van BAG gegevens bij
een reeds gelegde relatie of
het bijhouden van het adres
op grond van een abonnement
op BAG mutaties zijn
onderdeel van BZS-K.
Aangezien marktpartijen de
werking van BAG applicaties
bepalen bestaat het risico dat
meerdere vormen van BAG
koppeling in BZS-K
onderhouden moeten worden
(aangezien de BAG koppeling
een gemeentelijke
verantwoordelijkheid is staat
dit enigszins haaks op de
financiering van BZS-K door
het rijk).

In scenario 3 is de gehele
benodigde functionaliteit
onderdeel van de GBA
systemen die door
leveranciers worden
aangeboden. De
gemeentelijke BAG applicaties
worden ook door
marktpartijen aangeboden.
Het is aan de markt om zelf de
verschillende combinaties
tussen GBA en BAG systemen
mogelijk te maken.
Een LO 3.7 is reeds in
voorbereiding om de
koppeling te specificeren.
Aangezien op dezelfde wijze
wordt doorgegaan mag
verwacht worden dat
ontwikkeling van scenario 3
niet tot wijzigingen leidt in
deze in LO3.7 geïntroduceerde
functionaliteit

Een LO 3.7 is reeds in
voorbereiding om de
koppeling te specificeren in de
bestaande GBA-systemen. Het
vervolgens opnieuw realiseren
van de koppeling in

111

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Aanvullende Modules en BZSK betekent dat de
functionaliteit van LO 3.7 voor
de tweede maal gerealiseerd
moet worden, tenzij
implementatie van BZS-K
plaats vindt voordat
gemeenten verplicht zijn de
koppeling te leggen (dat is
hoogst onwaarschijnlijk)

De eerstgenoemde methode van gelijk houden van GBA adres aan BAG adres is
meer conform de gedachten van LO4. Net zoals het LO4 gegevensmodel voor
gerelateerden invoert dat enkel een referentie wordt vastgelegd en pas bij
gebruik de actuele gegevens worden opgehaald zo zou het gaan ten aanzien van
de BAG koppeling. Dit vereist echter wel real time bevraging van de BAG
binnengemeentelijk en een gelijke beschikbaarheid van BAG en
burgerzakensysteem. De levering van berichten aan het GBA-stelsel wordt
afhankelijk gemaakt van de beschikbaarheid en de responstijd van de
gemeentelijke BAG applicatie.
Indien een gegevensmagazijn is ingericht, waarin de gegevens uit zowel GBA als
BAG daadwerkelijk zijn gekoppeld, wordt het voor de gebruiker mogelijk om op
eenvoudige wijze GBA en BAG-gegevens te gebruiken in de processen. Indien er
geen gegevensmagazijn aanwezig is, is de realtime bevraging de enige optie en
wordt het om performance-technische redenen lastig om alleen referenties in
de GBA op te nemen, want bij elke raadpleging van persoonsgegevens moet dan
ook een “uitstapje” naar de BAG worden gemaakt om de adresgegevens op te
halen.
Op stelselniveau geldt het uitgangspunt dat de GBA geen eigen adresregistratie
meer bijhoudt. De GBA hanteert alleen de adressen uit de BAG. Daarvoor is het
nodig dat alleen de “sleutel” naar het adresseerbare object (verblijfsobject,
ligplaats of standplaats) wordt opgenomen, waar de burger woont of de brieven
laat bezorgen.
Op semantisch niveau moet men de koppeling tussen het adres en persoon
goed inregelen. In het huidige model wordt de adresgerichte benadering
gevolgd, waarbij een persoon op een adres woonachtig is. In een objectgerichte
benadering woont een persoon in een verblijfsobject dat een adres heeft.

112

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Figuur 45: LO3.x vs LO4

6.6

Afnemersindicatie

Een afnemersindicatie wordt op gemeentelijk niveau geregistreerd. Met de
komst van GBA-V wordt beoogd dat er een ontkoppeling plaatsvindt tussen de
gemeente en (buitengemeentelijke) afnemers.
GEG14
(ALG 3)

GBA-V bevat te allen tijde een kopie van alle PL-en van alle burgerzakensystemen,
met uitzondering van de afnemersindicaties.
Scenario 1: In de
definitiestudie van 2005 was
deze eis uitgebreider, daar
stond nog bij dat BZS-K
leidend is bij het beheer van
de GBA-gegevens en de GBA-V
volgend. Omdat BZS-K geen
onderdeel is van Scenario 1
gaat dit wel op voor scenario 1
maar niet voor de andere
varianten. De lokale GBA is in
scenario 1 leidend, met in
achtneming van een
actualiteitsverschil van max 24
uur als gevolg van
batchverwerking.

Scenario 2: In de
definitiestudie van 2005 was
deze eis uitgebreider, daar
stond nog bij dat BZS-K
leidend is bij het beheer van
de GBA-gegevens en de GBA-V
volgend. Omdat BZS-K
onderdeel is van Scenario 2
gaat dit wel op voor scenario 2
maar niet voor de andere
varianten.
Er is nauwelijks
actualiteitsverschil aanwezig
als gevolg van realtime
verwerking van mutaties op de
gegevens.

Scenario 3: In de
definitiestudie van 2005 was
deze eis uitgebreider, daar
stond nog bij dat BZS-K
leidend is bij het beheer van
de GBA-gegevens en de GBA-V
volgend. Omdat BZS-K geen
onderdeel is van Scenario 3
gaat dit wel op voor scenario 3
maar niet voor de andere
varianten. De lokale GBA is in
scenario 3 leidend, met in
achtneming van een
actualiteitsverschil van max 24
uur als gevolg van
batchverwerking.

Afnemers die ervoor geautoriseerd zijn om ad hoc afnemersindicaties te
plaatsen kunnen dat door gebruikmaking van de GBA-V doen. Daarnaast kunnen
afnemersindicaties worden geplaatst door selecties, of door sleutelrubrieken.
GBA-V voert de plaatsing van indicaties uit. Daarvoor is geen berichtverkeer
meer met de gemeente noodzakelijk. Op termijn, na volledige ontkoppeling
tussen afnemer en gemeenten zullen bij de PL geen afnemerindicaties meer zijn.

113

Definitiestudie mGBA Versie 1.8

6.7

De moderne GBA mogelijk gemaakt…

A-nummer/BSN

Voor de meeste burgers is het Burger Service Nummer dat op 26 nov 2007 is
ingevoerd, gelijk aan het SoFi-nummer en dat zit al lang in het GBA. Bij de
modernisering wordt het BSN een volwaardig alternatief voor het A-nummer.
Het A-nummer wordt nog niet onmiddellijk afgeschaft omdat niet alle afnemers
op dit moment al een SoFi-nummer krijgen en deze uiteraard tijd voor migratie
krijgen.
GEG15
(ALG 8)

Het A-nummer blijft in zijn huidige vorm gehandhaafd als sleutel voor de reeds
aangemaakte PL-en.
45

Het A-nummer kan in zijn huidige vorm nog mee tot 2012 . Dan raakt de Anummer voorraad op. Er is nog geen onmiddellijke noodzaak om het A-nummer
aan te passen.
GEG16
(ALG 9)

In het nieuwe stelsel wordt het BSN als sleutel gebruikt in plaats van het Anummer.

45

Uitfaseren van het A-nummer voor de nieuw aan te leggen persoonslijsten is noodzakelijk
aangezien de A-nummer voorraad opraakt. Dit is nu binnen de planningshorizon van het
programma gekomen en dient expliciet belegd te worden binnen de planning.

114

Definitiestudie mGBA Versie 1.8

Bijlage A.

De moderne GBA mogelijk gemaakt…

Samenvatting eisen

Ten behoeve van het overzicht en het kunnen vastleggen van
wijzigingsbeslissingen zijn in deze bijlage alle eisen nogmaals opgenomen. De
eisen zijn verdeeld over drie groepen, te weten eisen uit definitiestudie versie
1.3 die overgenomen zijn met verwijzing naar het oorspronkelijk nummer.
Vervolgens de nieuw toegevoegde eisen en tenslotte eisen die niet
overgenomen zijn, of buiten de scope van deze versie vallen. Bij de
overgenomen eisen is de formulering geactualiseerd.
A.1 Eisen uit oorspronkelijk definitiestudie
Nieuw

Oud

Eis

ALG1

ALG 1

ALG2

ALG 2

ORG3

ALG 3

ORG4

SPG 1

ORG7

ALG 10

ORG8

SPA 3

ORG9

ALG 6

DST3

SPG 3

De gemoderniseerde GBA dient te voldoen aan alle eisen die in dit document
zijn geformuleerd, niet alleen aan de eisen die expliciet zijn benoemd en
genummerd
Indien het bij de realisatie nodig blijkt om af te wijken van het programma van
eisen dient dit in de vorm van een wijzigingsvoorstel aan de opdrachtgever te
worden voorgelegd.
Iedere gemeente heeft een Burgerzakensysteem dat leidend is bij het beheer
van de GBA-gegevens van die gemeente; GBA-V bevat te allen tijde een kopie
van de gegevens van alle Burgerzakensystemen. (NORA 7.2.3)
Alle systematische verstrekkingen vanuit de GBA worden uitgevoerd door
GBA-V.
Gebruikers binnen de gemeente hebben via het gemeentelijke
Burgerzakensysteem een transparante toegang tot GBA-V.
Binnengemeentelijke afnemers kunnen via de transparante toegang van het
gemeentelijke Burgerzakensysteem gebruik maken van GBA-V maar (in
bepaalde gevallen) kunnen zij ook aan de eisen van het gebruik van GBA als
basisregistratie voldoen op basis van een aansluiting "buitenom" op GBA-V
(NORA 7.2.1.2)
Omdat de burgerzakensystemen voortdurend in verbinding staan met GBA-V
is het mogelijk per gemeente enkel de gegevens op te slaan waarvan zij
bronhouder is en alle andere gegevens, o.a. die van gerelateerden, bij gebruik
in meest actuele versie op te halen uit GBA-V.
Afnemers krijgen de mogelijkheid om te hersynchroniseren met GBA-V

DST4

SPG 9

GEG1

SPG 6

GEG2

SPG 2

PRC1

SPG 5

Meldingen worden verstuurd op het moment dat ze beschikbaar zijn

PRC2

SPG 7

PRC3

SPG 8

UIT1

SPG 10

DST5

ALG 42

Afnemersindicaties kunnen in de huidige GBA worden gezet door een verzoek
van de afnemer, door middel van een sleutelrubriek of door middel van een
selectie. Deze methoden blijven ook in de nieuwe opzet gehandhaafd.
In de nieuwe opzet kan er per afnemer een verzorgingsgebied worden
gespecificeerd door middel van een afnemerslocatie tabel . Deze functie
vervangt de indicatie op adres.
Het bestandsformaat voor selecties wordt gebaseerd op XML en zal dus
afwijken van het bestaande GBA uitwisselingsformaat
De interactie tussen Burgerzakensystemen en GBA-V voorziet in een middel
voor hersynchronisatie om verschillen die onverhoopt toch ontstaan tussen
Burgerzakensystemen en GBA-V op te lossen.

Selecties worden in de nieuwe opzet uitgevoerd door GBA-V. De resultaten
van de selectie worden altijd vastgelegd in een bestand. Dit bestand kan
worden afgeleverd via het netwerk of via een alternatief medium.
GBA-V online biedt aan daarvoor geautoriseerde afnemers toegang tot de
volledige set van gegevens op een PL, inclusief de historie. Welke gegevens
een afnemer krijgt en over welke categorieën van personen wordt bepaald
door de autorisatie van de afnemer.
Afnemers krijgen bij iedere verstrekking vanuit GBA-V alle gegevens waar ze
recht op hebben, en niet alleen de gewijzigde gegevens in oud/nieuw formaat.

115

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Nieuw

Oud

Eis

GEG3

ALG 12

Bijhoudingsberichten en mutatiemeldingen bevatten de gehele PL (actueel en
historisch), in plaats van slechts een opsomming van de gewijzigde gegevens.

PRC4

ALG 11

SEC1

SPA 3

PRC5

SPA 4

APP1

SPA 1

Iedere wijziging in de GBA-gegevens leidt direct tot een mutatiemelding aan
GBA-V (uitwerking van ORG2).
BZS-K schermt de toegang voor binnengemeentelijke gebruikers tot de
gemeentelijke database af en past voor transparante bevragingen van GBA-V
autorisaties toe. Daarmee wordt ook binnengemeentelijke verstrekking
geformaliseerd (NORA 9.4.5 en 9.4.6).
Voor die gevallen waarin de toegang tot de GBA via het Burgerzakensysteem
niet voldoet krijgen de gemeenten de mogelijkheid om spontane
verstrekkingen te ontvangen.
Gemeenten maken in het nieuwe stelsel verplicht gebruik van BZS-K.

PRC6

SPA 2

PRC7

SPG 11

PRC8

SPG 12

GEG6

SPG 19

PRC9

SPG 13

PRC13

ALG 29

TEC1

ALG 27

TEC2

ALG 28

UIT2

ALG 24

UIT3

ALG 25

BEH1

ALG 37

PRC14

ALG 31

PRC15

ALG 32

PRC16

ALG 33

PRC17

ALG 35

PRC18

ALG 36

TEC3

ALG 30

De richtlijn die wordt gehanteerd bij het definiëren van de bijhoudings- en
raadpleeg services in BZS-K is dat fouten in de bijhouding van de GBAgegevens zo veel mogelijk moeten worden uitgesloten, maar dat verder de set
van services zo klein mogelijk dient te zijn (NORA 5.3.8 en 5.3.9).
De servicebus zorgt ten behoeve van de intergemeentelijke bijhouding voor
het routeren van berichten; bepalen welke gemeenten op de hoogte gesteld
moeten worden; de servicebus bewaakt de transacties en zorgt dat er geen
berichten verloren gaan.
De servicebus zorgt ten behoeve van de intergemeentelijke bijhouding voor
opslaan en doorsturen: als een bericht niet direct aan de betreffende BZS-K
kan worden afgeleverd houdt GBA-V dit vast tot het wel afgeleverd kan
worden.
Los van de controles op het moment van bijwerken bezit GBA-V zelfstandige
kwaliteitscontroles die consistentie van PL-en onderling betreffen
GBA-V ondersteunt het proces van kwaliteitsbewaking door te fungeren als
meld- en concentratiepunt voor gesignaleerde problemen en door het
informeren van afnemers over de afhandeling voor haar rekening te nemen.
Koppelvlakken zijn geschikt voor real-time verwerking
Koppelvlakken tussen een component en de servicebus zijn gelaagd
opgebouwd
Koppelvlakken zijn zodanig gedefinieerd, dat op eenvoudige wijze gebruik kan
worden gemaakt van Open Source componenten
Alle koppelvlakken zijn volledig open en daarmee voor iedereen beschikbaar.
Alle koppelvlakken zijn gestandaardiseerd, zowel de berichtenveloppe als de
inhoud. Voor de enveloppe wordt de OSB ebMS specificatie voorgeschreven,
voor de berichtinhoud de StUF 3.0 standaard.
De servicebus biedt faciliteiten voor rapportage m.b.t. frequentie, omvang,
fouten in het berichtenverkeer.
De servicebus draagt zorg voor protocollering t.b.v. eenduidige verslaglegging
van het berichtenverkeer;
De servicebus biedt faciliteiten voor transformatie, d.w.z. het omzetten van de
ene standaard in een andere (Als voorbeeld zou kunnen dienen het omzetten
van XML naar EDI of vice versa);
De servicebus biedt faciliteiten voor adressering en routering, d.w.z. het
kennen van de componenten en hun dienstverlening als ook het kiezen van de
meest efficiënte weg van de bron naar het doel; geïmplementeerd en niet
ondergebracht binnen andere functionele services. In deze functie wordt
voorzien door de OSB.
De servicebus biedt faciliteiten voor beperkte workflow teneinde berichten
achtereenvolgens langs verschillende componenten te leiden, bijvoorbeeld
voor een samengestelde zoekopdracht over GBA-V en RNI;
De servicebus biedt faciliteiten voor abonnementen, bijvoorbeeld voor het
eenmalig publiceren van informatie t.b.v. afnemersgroepen, waarbij elke
afnemer afzonderlijk op deze publicatie is geabonneerd
De servicebus draagt zorg voor buffering van gegevens, waardoor
beschikbaarheidseisen worden verminderd;

116

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Nieuw

Oud

Eis

TEC4

ALG 34

GEG8

ALG 7
ALG 19

De servicebus biedt voorzieningen voor asynchrone communicatie tussen
componenten, waarvan verwacht mag worden dat de beschikbaarheid met
elkaar uit de pas loopt;
Het bestaan van GBA-V maakt verwijsgegevens overbodig. De verwijsgegevens
zijn daarom vervallen .

GEG10

ALG 22

GEG11

ALG 21

GEG12

ALG 6

GEG13

ALG 20

GEG14

ALG 3

GEG15

ALG 8

GEG16

ALG 9

TEC5

ALG 23

In het nieuwe gegevensmodel is het uitgangspunt dat er alleen “juiste”
historische gegevens van de persoon worden opgenomen.
In het nieuwe gegevensmodel is de categorie de basis voor gegevens die
herhaald kunnen voorkomen. Historie wordt aangelegd op het niveau van
groepen.
Gegevens van gerelateerden (ouders, kinderen, echtgenoten/partners)
worden alleen nog opgenomen op een PL indien deze gerelateerden zelf niet
ingeschreven zijn in de GBA . Indien de gerelateerde wel is ingeschreven
wordt alleen een verwijzing middels een A-nummer opgenomen (zie ook
GEG13 en ORG 9).
In het nieuwe datamodel wordt van gerelateerden alleen het A-nummer en
BSN opgenomen, alsmede de gegevens over de relatie zelf.
GBA-V bevat te allen tijde een kopie van alle Pl'en in alle
burgerzakensystemen, met uitzondering van de afnemersindicaties.
Het A-nummer blijft in zijn huidige vorm in ieder geval gehandhaafd als sleutel
voor de reeds aangemaakte PL'en.
In het nieuwe stelsel wordt het BSN als sleutel gebruikt in plaats van het Anummer.
De tekenset van het nieuwe model is gebaseerd op UTF-8.

A.2 Nieuw toegevoegde eisen
Nr

Eis

ORG1

Het GBA stelsel kent twee verantwoordelijkheden:
• de bijhouding van persoonsgegevens en de levering aan binnengemeentelijke afnemers
onder verantwoordelijkheid van de gemeenten
• de verstrekking aan afnemers als onderdeel van het stelsel van basisregistraties onder
verantwoordelijkheid van de minister van BZK.

ORG2

Het GBA stelsel is één geheel gebaseerd op één set aan afspraken met een wettelijke basis

ORG5

Het GBA stelsel is integraal onderdeel van het stelsel van basisregistraties. Binnen- en
buitengemeentelijke afnemers zijn afhankelijk van de GBA om aan hun verplichtingen inzake
eenmalige verstrekking, meervoudig gebruik te voldoen. De gemeente zijn als bronhouder
gehouden om terugmeldingen te verwerken (NORA 5.1.1.2).
Het agentschap BPR is namens de minister verantwoordelijk voor het beheer van GBA-V en
de andere landelijke voorzieningen en voor de dienstverlening aan afnemers.

ORG6
ORG10

ORG11
ORG12

DST1

NORA principes worden toegepast zodanig dat het GBA-stelsel voor gemeenten en
afnemers zo goed mogelijk aansluit op andere ontwikkelingen en standaarden in de eoverheid.
Het GBA-stelsel levert diensten op basis van een service georiënteerde architectuur. (NORA
5.1.5)
Het GBA-stelsel legt geen beperkingen op tegen het door meerdere gemeenten gezamenlijk
beheren van een Burgerzakensysteem, het door één gemeente beheren van een
Burgerzakensysteem waaruit ook dienstverlening voor andere gemeenten plaatsvindt of het
centraal als dienst hosten van BZS-K.
Het GBA-stelsel levert de volgende diensten:
• Bijhouding door de gemeenten
• Systematische verstrekking aan afnemers
• Binnengemeentelijke verstrekking
• Intergemeentelijke diensten
• Overige verstrekkingen
• Terugmelden

117

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Nr

Eis

DST2

Diensten en services worden geleverd op basis van een service georiënteerde architectuur
waarbij het inzetten van een servicebus centraal staat in de ontwerpfilosofie (uitwerking
van ORG 11)
Gemeenten zijn zelf verantwoordelijk voor de aanschaf en het beheer van Aanvullende
Modules. Afgezien van het koppelvlak met BZS-K hoeven deze niet uniform te zijn.

APP2
APP3

Aanvullende Modules moeten optimaal aansluiten bij de verdere gemeentelijke ICT.

DST6

BZS-K levert enkel basisservices en heeft geen gebruikersinterface. Als criterium voor wat
tot de basisservices behoort geldt dat datgene is wat noodzakelijk is voor de integriteit van
het GBA-stelsel gezien als één systeem gebaseerd op een service georiënteerde
architectuur.
Uniforme consistentie en plausibiliteitcontroles worden ingebouwd in
Burgerzakensystemen.
De uniforme consistentie en plausibiliteitcontroles worden ook gecontroleerd in het
bijwerken van GBA-V op basis van mutatiemeldingen.

GEG4
GEG5
PRC10

De terugmeldvoorziening van de GBA dient één geheel te zijn met andere
terugmeldvoorzieningen voor dezelfde afnemers (op basis van ORG5)

PRC11

Voorzieningen voor de koppeling met de BAG dienen ingebouwd te worden in het
Burgerzakensysteem.
De RNI wordt gerealiseerd als een onderdeel van het GBA-stelsel

ORG13
GEG7

PRC12
DST7

ORG14

DST8
GEG9

Een persoonslijst dient ongeschonden van een gemeente naar de RNI te kunnen worden
overgedragen en vervolgens weer in een gemeente voortgezet te kunnen worden, daarbij
dient de levensloop van de betrokkenen zichtbaar te blijven met alle relevante informatie
over het tijdelijke verblijf buiten Nederland.
De transparante toegang (ORG7) op GBA-V dient uitgebreid te worden met een
transparante toegang op RNI, voor zowel gemeenten als afnemers.
Voorzieningen die in een service georiënteerde architectuur gerealiseerd kunnen worden
door generieke services van de servicebus worden op die basis geïmplementeerd en niet
ondergebracht binnen andere functionele services.
Gemeenten zijn zelf verantwoordelijk voor het implementeren en beheren van een
binnengemeentelijke servicebus die voldoet aan de OSB standaarden en transparant
berichten kan doorgeven van en naar de landelijke servicebus.
De servicebus voorziet in services voor procesregie.
De administratieve levensloop moet gereconstrueerd kunnen worden aan de hand van
voorgedefinieerde gebeurtenissen

A.3 Niet verwerkte eisen
Eis

Omschrijving

ALG 4

Er zal een geleidelijke overgang zijn van de bestaande GBA-systemen naar het nieuwe
stelsel met SpA en gerelateerde systemen. De architectuur voorziet in maatregelen
waardoor beide naast elkaar kunnen bestaan.
Er zal een geleidelijke overgang zijn voor afnemers van het huidige regime van
verstrekkingen naar het nieuwe stelsel. De architectuur voorziet in maatregelen waardoor
beide naast elkaar kunnen bestaan.
Ontvangst en verwerking van alle berichten worden bevestigd.

ALG 5

ALG 13
ALG 14

ALG 15

ALG 16

Scenario’s waarbij alle gebruikers van de GBA op één en hetzelfde moment overgaan naar
de nieuwe systemen worden uitgesloten. De risico’s van deze benadering zijn niet
aanvaardbaar.
Gemeenten moeten binnen bepaalde grenzen zelf kunnen bepalen op welk moment ze
overstappen. De invoering van SpA betekent een grote verandering van de
binnengemeentelijke automatisering. De tijd die gemeenten nodig hebben om zich daar op
voor te bereiden zal van gemeente tot gemeente verschillen en er moet rekening worden
gehouden met het investeringsritme van de gemeenten.
Afnemers moeten eveneens zelf kunnen bepalen wanneer ze overstappen. De impact van
alle aanpassingen op de systemen van de afnemers is minder groot dan bij de gemeenten
maar niet triviaal. Bovendien kunnen de nieuwe faciliteiten voor de afnemers aanleiding
zijn om hun werkproces aan te passen, als is dat niet verplicht. Ook dit proces kost tijd.

118

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Eis

Omschrijving

ALG 17

Om planningsrisico’s te vermijden is het wenselijk dat zo min mogelijk onderlinge
afhankelijkheid bestaat tussen de migratie van de afnemers en die van de gemeenten.

ALG 18

Om een soepele overgang te bewerkstelligen sluiten de berichtencycli voor toevallige
gebeurtenissen en voor vervolginschrijving (intergemeentelijke verhuizing) binnen SpA zo
veel mogelijk aan bij de corresponderende berichtencycli in LO3.2

ALG 26

Centraal in de ontwerpfilosofie is het inzetten van een dienstenbus.

ALG 38

Een PL die ontstaat door een herhaalde conversie (oud è nieuw è oud è nieuw) mag alleen
wat betreft zijn logboek verschillen van een PL die in één keer van oud naar nieuw is
geconverteerd.
De groep gegevens die niet kan worden teruggeconverteerd dient zo klein mogelijk te
worden gemaakt door deze gegevenselementen zoveel mogelijk op te nemen in LO3.x.

ALG 39
ALG 40

Voor gegevenselementen die niet op deze manier kunnen worden opgeslagen in LO3.x
systemen zal worden onderzocht of SpG daarvoor als boedelbergplaats kan dienen.

ALG 41

Alle transacties, met name tussen SpA en SpG, worden bevestigd.

ALG 43

Berichten die worden ontvangen via het bestaande GBA-netwerk (LO3 berichten) mogen
worden vertrouwd.
Gegevens worden tijdens transport tussen systemen (met name SpA en SpG) beveiligd.

ALG 44
ALG 45

In aanvulling op de transportbeveiliging wordt waar nodig gebruik gemaakt van
wachtwoorden voor de informatietoegang.

ALG 46

Afnemers worden geautoriseerd op organisatieniveau.

ALG 47

Binnen gemeenten wordt geautoriseerd op individueel niveau.

ALG 48

Protocollering van verstrekking van persoonsinformatie vindt plaats binnen SpG en SpA.

ALG 49

SpG en SpA kennen een actieve signalering voor pogingen tot inbraak en andere incidenten
waarbij de beveiliging van SpA en SpG in het geding is.

ALG 50

Ten behoeve van SpG zal probleemmanagement, incidentenmanagement en
calamiteitenmanagement worden ingericht teneinde kwaliteit en continuïteit van de
dienstverlening te garanderen
Teneinde de gewenste beschikbaarheid en continuïteit te realiseren zal een
uitwijkvoorziening worden gecreëerd die de kwaliteit en continuïteit van de
dienstverlening in het geval van incidenten en calamiteiten waarborgt.
Zowel binnen SpA als binnen SpG worden logfiles bijgehouden waarin het gebruik dat van
het systeem wordt gemaakt wordt vastgelegd.

ALG 51

ALG 52
ALG 53

Indien SpA gebruik maakt van diensten van SpG wordt in de aanvraag van de dienst het
autorisatietoken meegegeven.

SPA 5

Naast het mechanisme voor spontane verstrekkingen zal de mogelijkheid worden geboden
aan binnengemeentelijke applicaties om een duplicaat te ontvangen van iedere
mutatiemelding die SpA doet aan SpG.
Binnen het gemeentelijk domein zal ten behoeve van SpA een authenticatie en autorisatie
server moeten worden ingericht.

SPA 6
SPA 7

Het autorisatiemodel is gebaseerd op een rollenmodel. Aan iedere rol zijn bepaalde
bevoegdheden toegekend. Iedere gebruiker krijgt één of meer rollen toebedeeld.

SPA 8

Er dient een document te komen waarin de diensten die SpA biedt voor gemeentelijke
applicaties exact worden beschreven.

SPA 9

Naast het bestaande leveranciersoverleg dient er een platform te komen waarin de
verdere ontwikkeling van SpA met de belanghebbenden kan worden besproken.

SPA 10

Nog tijdens de ontwikkeling van SpA zullen er criteria ontwikkeld moeten worden voor het
beoordelen van wijzigingsvoorstellen van SpA en voor de kostentoedeling.

SPA 11

Voor SpA zal een testbed moeten worden ontwikkeld om de functionaliteit
(geautomatiseerd) te testen.
Voor SpA zal een referentieplatform worden gedefinieerd waarop de nieuwe versies van
het systeem worden ontwikkeld. Daarnaast zal de beheerorganisatie een versie voor één
alternatief platform ontwikkelen en onderhouden.

SPA 12

SPA 13

SpA dien te voorzien in een mogelijkheid om nieuwe versies te distribueren. Voor het in
gebruik nemen van nieuwe versies kunnen bindende aanwijzingen worden gegeven maar

119

Definitiestudie mGBA Versie 1.8

Eis

De moderne GBA mogelijk gemaakt…

Omschrijving
dit wordt niet centraal afgedwongen.

SPA 14

Er dienen contracten of convenanten afgesloten te worden met een aantal representatieve
gemeenten van verschillende grootte om de prestatie-eisen van SpA te onderzoeken.

SPA 15

SpA dient te voorzien in hulpmiddelen om de kengetallen beschreven in hoofdstuk 12 te
meten.
SpA dient te voorzien in hulpmiddelen om de systeembelasting te meten. Dat houdt in
ieder geval in geheugengebruik, CPU-gebruik, diskgebruik, I/O activiteit en netwerk
activiteit.
SpA dient te beschikken over voorzieningen om de prestaties beschreven in § 12.4 te
meten.
Er wordt aangenomen dat alleen het gebruik van SpG wordt doorbelast; in SpA hoeven dus
alleen voorzieningen te worden getroffen om gegevens te verzamelen over het lokale
gebruik dat van SpA wordt gemaakt.
De techniek voor spontane meldingen aan afnemers wordt gebaseerd op webservices;
impliciet wordt daarmee bereikt dat alle meldingen aan afnemers worden bevestigd.

SPA 16

SPA 17
SPA 18

SPG 4
SPG 14

Het proces gegevensverstrekking construeert uit de nieuwe PL een mutatie bericht
conform de richtlijnen van het LO en bepaalt aan de hand van de afnemerstabel (de
bestaande tabel 35) aan welke afnemers een bericht moet worden verstuurd.

SPG 15

De persoonsgegevens in SpG zijn ook on-line beschikbaar. Daarvoor is er binnen SpG een
component die de huidige LRD emuleert ⑧.

SPG 16

SpG houdt in de overgangsperiode een tabel bij van gemeenten die al zijn overgeschakeld
naar het gebruik van SpA en gemeenten die werken met een LO3.x gebaseerd systeem.

SPG 17

SpG handelt al het bestaande GBA berichten verkeer af namens de SpA-gemeenten.

SPG 18

SpG kent geen lokale wijzigingsmethoden; alle wijzigingen worden doorgevoerd in SpA,
door SpA gemeld aan SpG en daar vervolgens verwerkt.

SPG 20

De configuratie voor SpG dient te voorzien in vier afzonderlijke omgevingen:
ontwikkelomgeving, testomgeving, schouwing- en toetsing en productie.

SPG 21

Het aantal omgevingen voor SpG dient op eenvoudige wijze te kunnen worden uitgebreid.

SPG 22

SpG dient te voorzien in hulpmiddelen om de kengetallen beschreven in hoofdstuk 9 te
meten.
SpG dient te voorzien in hulpmiddelen om de systeembelasting te meten. Dat houdt in
ieder geval in geheugengebruik, CPU-gebruik, diskgebruik, I/O activiteit en netwerk
activiteit.
SpG dient te zijn uitgerust met voorzieningen om de prestaties beschreven in § 9.3 te
meten.
Een financiële module maakt geen deel uit van het startpakket. Het startpakket verzamelt
de nodige basisgegevens ten behoeve van een doorbelasting van kosten; deze kunnen
worden geëxporteerd ter verdere verwerking in een afzonderlijk financieel systeem.

SPG 23

SPG 24
SPG 25

SPG 26

SPG 27

Er wordt aangenomen dat alleen het gebruik van SpG wordt doorbelast; in SpA hoeven dus
alleen voorzieningen te worden getroffen om gegevens te verzamelen over het lokale
gebruik dat van SpA wordt gemaakt.
SpG houdt tellers bij voor het gebruik dat door gemeenten van SpG wordt gemaakt.

SPG 28

SpG houdt tellers bij van de spontane meldingen die aan gemeenten worden verstuurd.

SPG 29

SpG houdt gegevens bij van selecties die in opdracht van gemeenten worden uitgevoerd.

SPG 30

SpG houdt tellers bij voor het gebruik dat door afnemers van SpG wordt gemaakt.

SPG 31

SpG houdt tellers bij van de spontane meldingen die aan afnemers worden verstuurd.

SPG 32

SpG houdt gegevens bij van selecties die in opdracht van afnemers worden uitgevoerd.

SPG 33

SpG verzamelt geen andere gegevens ten behoeve van doorberekening dan de hier
genoemde.
De projectopzet voor SpG dient het mogelijk te maken (met name in versiebeheer) dat er
aan meerdere versies van SpG tegelijk wordt gewerkt.

SPG 34
SPG 35

Het moet mogelijk zijn om binnen de S&T-omgeving van SpG scripts te definiëren waarin
teststappen voor gemeentelijke- en voor afnemersystemen worden vastgelegd.

120

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Eis

Omschrijving

SPG 36

Teststappen moeten kunnen worden uitgevoerd als reactie op binnengekomen berichten.

SPG 37

Binnen SpG moet het mogelijk zijn om een binnengekomen PL te vergelijken met een
referentie PL.
Het moet mogelijk zijn om binnen de S&T-omgeving van SpG meerdere testsessies
tegelijkertijd te laten lopen.

SPG 38

121

Definitiestudie mGBA Versie 1.8

Bijlage B.

De moderne GBA mogelijk gemaakt…

Referenties

[1]

Nationaal uitvoeringsprogramma dienstverlening en E-overheid, versie
1.2, 25-9-2008

[2]

NORA 2.0, Nederlandse Overheids Referentie Architectuur, 25-4-2007

[3]

Scopewijzingen mGBA/Snellen en financiën, memo, 10-7-2007

[4]

Puzzelen met prioriteit, oktober 2005

[5]

IT Architecture in Large Scale Programs, Critical Succes Factors, Jiri
Ludvik, Capgemini, 2008

[6]

Kamerstukken 27589 nr 14,

[7]

Toets afspraken BZS-K, onderzoek KPMG, juni 2008

[8]

Logisch Ontwerp, versie 3.6, 26-11-2007

[9]

Definitiestudie startpakket GBA, versie 1.3, juni 2005

[10]

Businesscase modernisering GBA, versie 2.4, november 2008

[11]

Fasering GBA Verstrekkingen, versie 1.5, 23-10-2006

[12]

Startarchitectuur TMF, versie 1.0, 29-1-2008

[13]

OverheidsServiceBus 1.0 architectuur, versie 0.9, 8-8-2007

[14]

NORA toegelicht, versie 1.0, september 2007

[15]

Dat moet eenvoudiger kunnen!, het gegevensmodel van de moderne
GBA, mei 2006

[16]

Concordantie LO 4.0 LO3.2, 25-10-2005

[17]

Het gegevensmodel GBA LO4.0, stand 16 juli 2007

[18]

Omgaan met conversie, memo, 30-1-2007

[19]

Eindrapportage werkgroep selecties, 17-1-2008

[20]

Eindrapportage werkgroep afnemers, 25-1-2008

[21]

Eindrapportage werkgroep spontane verstrekkingen, 30-1-2008

[22]

Eindrapportage werkgroep omvang berichtenverkeer, 31-1-2008

[23]

Rapport Eindevaluatie pilot Terugmeldvoorziening, 15-4-2008

[24]

Modernisering logisch ontwerp, memo, 22-4-2008

[25]

Factsheet Standaard UitwisselingsFormaat (StUF)

[26]

Factsheet Referentiemodel Stelsel van Gemeentelijke Basisgegevens
(RSGB)

[27]

Standaard Uitwisseling Formaat voor applicaties, StUF 03.00: Kandidaat
Aanbeveling, 20-6-2007

[28]

Referentiemodel Stelsel van Gemeentelijke Basisgegevens, versie 1.0,
juni 2007

122

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

[29]

Draaiboek complete burgerzakensysteem (VKA), versie 1.9, 10-4-2007

[30]

Rapportage 1 helft 2007 Startpakket mGBA, memo, 14-9-2007

[31]

GBA-V Release 5 Vision, versie 1.0, 18-4-2008

[32]

Handreiking GBA Binnengemeentelijke afname Basisregistraties
adressen en Gebouwen, versie 0.99

e

Oorspronkelijke referenties, definitiestudie versie 1.3:
[33]

Projectplan Startpakket, versie 1.7, 12 oktober 2004

[34]

PID SpG, versie 1.1, 18 februari 2005

[35]

Tussenrapportage consequenties Startpakket, 22 juli 2003.

[36]

Beveiligingsplan Startpakket. Concept, 20 januari 2005.

[37]

Enterprise SOA: Services-Oriented Architecture Best Practices (The
COAD Series) by Dirks Krafzig, Karl Banke, Dirk Slama, Prentice Hall PTR
(November 9, 2004), ISBN 0131465759.

[38]

Model Driven Architecture: Applying MDA to Enterprise Computing by
David S. Frankel, Wiley (January 10, 2003), ISBN 0471319201

[39]

Voorstellen gegevensset, Notitie 1: Historie, groepen Procedure en
Onjuist, Bestandsschoning. BPR notitie, Versie 18-12-2002.

[40]

Voorstellen gegevensset, notitie 2: Ingangsdatum geldigheid. BPR
notitie, Versie 18-12-2002.

[41]

Voorstellen gegevensset, notitie 3: Standaardwaarde. BPR notitie,
Versie 30-01-2003

[42]

Voorstellen gegevensset, notitie 4: Brondocumenten en
Brondocumentenstelsel. BPR notitie, Versie 08-04-2003.

[43]

Voorstellen gegevensset, notitie 5: Diverse onderwerpen. BPR notitie,
02-07-2003.

[44]

Voorstellen gegevensset, notitie 6: Leeswijzer en samenvatting. BPR
notitie, 21-08-2003

[45]

Component Based Software Engineering: Putting the Pieces Together.
George T. Heineman, William T. Councill, Addison-Wesley Professional;
1st edition (June 8, 2001), ISBN: 0201704854

[46]

The Workflow Handbook 2004, Published in association with the
Workflow Management Coalition (WfMC) Edited by Layna Fischer,
Future Strategies Inc., Lighthouse Point, FL, USA, ISBN: 0-9703509-6-1

[47]

Actieprogramma Elektronische Overheid, Brief van de Minister voor
Bestuurlijke Vernieuwing en Koninkrijkrelaties, Tweede Kamer,
vergaderjaar 2003-2004, 26387, nr. 20.

[48]

Verwerking commentaar definitiestudie serie 2 V0.4, 4 mei 2005

[49]

ARCHITECTUUR GBA, versie 1.4. Expertisegroep Architectuurstudie
Modernisering GBA, 25 september 2002.

123

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

[50]

Eindrapportage Werkgroep Startpakket Gemeenten (WSG). Versie 1.0,
6 november 2003.

[51]

Eindrapport “GBA in de toekomst”. Commissie-Snellen, maart 2001

[52]

Rapportage Kwartiermaker Startpakket GBA, versie 2.0, 18 november
2004.

[53]

Modernisering van de Gemeentelijke Basisadministratie
Persoonsgegevens. Brief van de Minister voor Bestuurlijke Vernieuwing
en Koninkrijksrelaties aan de Voorzitter van de Tweede Kamer der
Staten-Generaal, Kenmerk BPR2004/U67245, 8 juni 2004.

[54]

Plan van aanpak startpakket: een schets van de vervolgaanpak in de
uitvoering. Expertteam Startpakket, versie 0.7, 1 april 2004

124

Definitiestudie mGBA Versie 1.8

Bijlage C.

De moderne GBA mogelijk gemaakt…

Terminologielijst en glossary

C.1 Aangepaste termen t.o.v. oorspronkelijke definitiestudie
Oude term

Nieuwe term

Omschrijving

Afnemers

Buitengemeentelijke
of binnengemeentelijke
afnemer

Zowel gemeenten als allerlei niet gemeentelijke
uitvoeringsorganisaties zijn afnemer van het GBA-Stelsel.
Voorstel is onderscheid te maken tussen:
Binnengemeentelijke afnemer: Organisatieonderdeel
binnen een gemeente dat gebruik maakt van dat deel van
de persoonsgegevens dat bij diezelfde gemeente in beheer
is (bijv. afdeling Bouw en Woningtoezicht, Gemeentelijke
Sociale Dienst) met uitzondering van Burgerzaken zelf die
beheerder zijn van de GBA gegevens en verantwoordelijk
voor het bijhouden.
Buitengemeentelijke afnemer: Een afnemer van
persoonsgegevens niet behorende tot de gemeente die
betreffende persoonsgegevens beheert, die afneemt via
het landelijke GBA-Stelsel, hetzij het Mailbox systeem,
hetzij GBA-V in een van de ontwikkelstadia (bijv. SVB,
Belastingdienst, CWI of intergemeentelijke bevraging).
Waar over “afnemers” in het algemeen gesproken wordt
worden dus altijd zowel buitengemeentelijke als
binnengemeentelijke afnemers bedoeld, maar niet
Burgerzaken als beheerder van het GBA. Gemeente in de
rol van beheerder van het GBA, c.q. de dienst Burgerzaken
wordt niet als “afnemer” gezien, maar aangeduid als
Burgerzaken.

Basisadministraties

Basisregistraties

Basisregistraties bevatten de vitale gegevens van de
overheid, zoals de gegevens van burgers, bedrijven en
instellingen. Het zijn systemen waarin zogeheten
authentieke gegevens van hoge kwaliteit worden
vastgelegd. Door die hoge kwaliteit kan de gehele overheid
deze gegevens zonder verder onderzoek in haar werk
gebruiken op basis van eenmalige uitvraag, meervoudig
gebruik.

Basisregistratie
Adressen en Basis
Gebouwen
Registratie

BAG

Basisregistratie Adressen en Gebouwen wordt nu als 1
naam voor zowel Adressen als Gebouwen registratie
gebruikt. Het GBA gaat gebruik maken van de BAG voor
adresgegevens via een binnengemeentelijke koppeling.

Berichtendienst

Mailbox Server

Berichtendienst is een te algemene term. Wanneer het
huidige berichtenverkeer over het GBA-netwerk bedoeld
wordt, is “Mailbox Server” gebruikt.

Dienstenbus

Servicebus

Architectuuronderdelen worden in het leveren van
diensten aan andere architectuuronderdelen ondersteund
door een servicebus. Dergelijke bussen kunnen allerlei
neutrale intermediaire communicatiefuncties vervullen.
Servicebussen moeten minimaal berichtenverkeer kunnen
afhandelen, maar kunnen ook rijkere functies bieden zoals
een serviceregister, het monitoren en bewaken van de
serviceverlening, het bundelen van services en een reeks
aan andere functies

LO4

LO-procedure

Met de LO-procedure wordt het geheel aan procedures op
grond van de vigerende wet- en regelgeving bedoeld zoals
die in een bijbehorend Logisch Ontwerp document worden
gepubliceerd en die de minimumeisen inhouden waaraan

125

Definitiestudie mGBA Versie 1.8

Oude term

Nieuwe term

De moderne GBA mogelijk gemaakt…

Omschrijving
GBA-applicaties moeten voldoen.

LO4

LO4 gegevensmodelwijziging

Om het onderscheid met de LO-procedure duidelijker te
maken wordt indien specifiek de voor LO 4.0 geplande
wijzigingen aan het gegevensmodel bedoeld worden
gesproken van "LO4 gegevensmodelwijziging".

Pseudo PL

RPL

Een fictieve persoonslijst, waarvan de sleutel, het Rnummer, is afgeleid van het A-nummer van de persoon
waar betrokkene een relatie van is. Een fictieve
persoonslijst komt slechts dan voor als de betrokkene niet
zelfstandig in aanmerking komt voor opname in de
basisregistratie personen.

Startpakket

ntb

Voor het vervolg is het gewenst een nieuwe projectnaam te
bedenken.

Startpakket
Actualisering
(SpA)

BurgerzakensysteemKern (BZS-K) of
Burgerzakensysteem

Omdat niet in alle scenario’s sprake is van de realisatie van
BZS-K (voorheen SpA) maken we onderscheid tussen BZS-K
en burgerzakensysteem.
BZS-K: BurgerZaken Systeem Kern. Het omvat de functies
die gebruikers nodig hebben om de GBA bij te houden en
beperkt zich tot de in de wet daartoe vastgelegde
processen.
Burgerzakensysteem: Een Burgerzakensysteem omvat
zowel de huidige situatie waarbij burgerzakensystemen
geleverd worden als pakket door marktpartijen als scenario
2 waarin het burgerzakensysteem wordt ingevuld op basis
van een BZS-K en Aanvullende Modules.
Burgerzakensysteem wordt dus als algemene term
gebruikt. Waar nodig wordt in de tekst gesproken over
“huidige Burgerzakensystemen” als de huidige situatie met
het vijftal decentrale systemen van marktpartijen bedoeld
wordt.

Startpakket
Gegevensverstrekking
(SpG)

GBA-Verstrekkingen
(GBA-V)

GBA Verstrekkingen is een landelijke voorziening binnen
het vernieuwde GBA-stelsel die diensten levert aan
buitengemeentelijke afnemers en die de gemeenten
onderling verbindt ten behoeve van intergemeentelijke
processen.

C.2 Glossary
Term

Toelichting

Aanvullende modules

Modules van een burgerzakensysteem die gebruikersinterface en
functionaliteit leveren voor gemeentelijke werkprocessen, met betrekking tot
de burgerzakentaak. Aanvullende modules zijn geen onderdeel van de
functionaliteit die door BZS-K wordt geleverd. De aanvullende modules maken
gebruik van de services van BZS-K. Andere systemen van gemeenten, die geen
onderdeel van de burgerzakentaak uitmaken, worden geen Aanvullende
Modules genoemd maar sluiten technisch op vergelijkbare wijze aan op BZS-K,
deze andere systemen zijn echter enkel afnemer en spelen geen rol in de
bijhouding. De term is in zoverre misleidend dat een gemeente met een BZS-K
niet zonder Aanvullende Modules kan.

Afnemersindicatie

Een indicatie dat een bepaalde afnemer geïnteresseerd is in de afname van
persoonsgegevens. Er zijn twee soorten indicaties: 1) afnemersindicatie
persoonslijst, 2) afnemersindicatie adreslijst.

126

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Term

Toelichting

Alternatief medium

Een alternatief voor de uitwisseling van berichten via het GBA-netwerk; in
principe een bestand volgens een gedefinieerd formaat op een diskette, CD,
email e.d. Alternatieve media worden vooral gebruikt in die gevallen waar er
sprake is van bulktransporten tussen twee GBA-participanten.

Bronhouder

De organisatie die (wettelijk) verantwoordelijk is voor het bijhouden van de
(authentieke) gegevens in een basisregistratie. Voor de GBA is dit de
gemeente.

Dienst

Een dienst is het resultaat of effect van een afgeronde inspanning die de
overheid op basis van wettelijke taken levert en waarmee in een behoefte van
een burger of bedrijf wordt voorzien (NORA).
Nota bene: service en interface worden als term gebruikt voor technische
middelen waarmee diensten geleverd worden in een service geörienteerde
architectuur. Het begrip Dienst is gepaard aan Koppelvlak. Het begrip service
aan servicebus en interface.

E-overheid

Elektronische overheid. Het geheel van toepassingen voor betere
dienstverlening aan burgers en bedrijven met ICT-oplossingen.

GBA-netwerk

Het bestaande gesloten systeem van mailboxen en bijbehorende voorzieningen
voor het berichtenverkeer binnen het GBA-stelsel. Dit is momenteel in beheer
bij GXS. Het logisch ontwerp [8] maakt onderscheid tussen het GBA-netwerk en
het transportnetwerk. Het GBA-netwerk is geen netwerk in de eigenlijke zin,
maar een dienst, die fungeert als opslag- en doorgeefpunt voor GBA-berichten;
voor het transport van de berichten tussen de GBA-systemen en de systemen
waarop deze dienst wordt uitgevoerd, wordt gebruik gemaakt van een
transportnetwerk;Gemnet is het transportnetwerk waar de functionaliteit van
het GBA-netwerk gebruik van maakt.

GBA-stelsel

De GBA, c.q. de Gemeentelijke Basis Administratie is strikt genomen de
benaming voor de gemeentelijke burgerzakensystemen. Deze benaming
dateert uit de tijd van het volledig decentrale systeem. Het GBA-stelsel omvat
alle voorzieningen die nodig zijn voor de uitvoering van de GBA wet en taak,
zowel in de huidige als in de toekomstige situatie. Dit is niet te verwarren met
het stelsel van basisregistraties. Het stelsel van basisregistraties is veel
omvattender en omvat naast de GBA c.q. het GBA-stelsel de andere
basisregistraties.

Gegevenswoordenboek

Deze termen zijn conform LO 3.6 gebruikt

Gegevenswoordenboek: Het gegevenswoordenboek beschrijft de belangrijkste
karakteristieken van de GBA-gegevens, de structuur van de verwijsgegevens en
de structuur van de landelijke tabellen.
Gekende niet
ingeschreven personen

Personen die gekend worden omdat ze gerelateerd zijn aan een in het GBA
ingeschreven persoon. Een deel van deze personen zal in de RNI worden
geregistreerd.

Interface

Een koppeling tussen verschillende computersystemen of tussen mens en
machine (gebruikersinterface).

Kernregistratie
gemeente

Het betreft hier de set van statische basisgegevens, op grond waarvan en met
behulp waarvan de operationele processen binnen de gemeente worden
uitgevoerd. De Kernregistratie is daarbij zo gedefinieerd, dat deze de
aanvullende informatie omvat, die gemeentebreed van belang zijn, maar (nog)
niet zijn opgenomen in de Basisregistratie. Daarnaast omvat de Kernregistratie
ook die gegevens, waarover verschillende partijen een andere opvatting
hebben van de meest recente versie ervan. Deze gegevens zijn op dat moment
in onderzoek, maar de meest actuele gegevens worden in de Kernregistratie
bewaard t.b.v. operationeel gebruik door gemeentelijke afdelingen.

Koppelvlak

Een koppelvlak is een set van afspraken tussen organisaties of tussen
systeemcomponenten omschreven op semantisch niveau.

127

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Term

Toelichting

Modules

Onderdeel van een applicatie of systeem dat een afgebakende dienst levert of
functie heeft. Modules overlappen onderling niet in functionaliteit. Nota bene:
een volledige lijst van alle modules in termen van functionaliteit moet in de
definitiestudie worden opgenomen.

LO3-services

Services die de berichten verwerken voor spontane mutaties en selecties en
ontvangen van berichten van afnemers inzake selecties, muteren
afnemersindicaties etc.

Online

Een dienst is online indien deze op basis van internetstandaarden wordt
geleverd. De diensten via de Mailbox Server zijn niet online, die van de huidige
GBA-V wel.

Overheidsservicebus

Voorzieningen voor overheidsberichtenverkeer met standaarden voor juist en
betrouwbaar verzenden van berichten.

Pakket

Burgerzaken pakketten zoals deze door marktpartijen worden geleverd en
momenteel bij gemeenten voor de GBA taak in gebruik zijn. Er zijn momenteel
vijf pakketen: Procura, Centric, Getronics in twee varianten: HP-UX, en AS/400
en het maatwerksysteem van de gemeente Amsterdam dat vervangen gaat
worden door het pakket van Centric.

Persoonslijst (PL)

De aanduiding voor de verzameling van vastgelegde, actuele en historische
gegevens met betrekking tot één specifiek natuurlijke persoon in de GBA.

Plaatsonafhankelijke
dienstverlening

Het is de bedoeling dat gemeenten, met name voor een aantal basisdiensten,
dezelfde diensten kunnen verlenen aan burgers die in andere gemeenten
wonen als aan de eigen burgers: plaatsonafhankelijk werken. Hieronder valt
tevens het bijwerken van de GBA van gemeente X door gemeente Y als er een
aangifte in gemeente Y wordt gedaan.
Net zoals de burger op internet gewend is geraakt aan plaatsonafhankelijk
werken verwacht de burger dat aan het loket van de gemeente. Het kan ook
betekenen dat de dienstverlening in een logische samenwerking met andere
organisaties plaatsvindt zoals het geboorteloket in ziekenhuizen of
verhuisberichten via de woningbouwvereniging. Plaatsonafhankelijk werken
levert bovendien een duidelijke bijdrage aan de administratieve
lastenverlichting van burgers.

Publiceren service

Het publiceren van een service betekent dat de interface openbaar gemaakt
wordt conform een bepaalde standaard. Dit is een gebruikelijke functie in
servicebussen.

Real-time

Real time wordt hier gebruikt met betrekking op het berichtenverkeer. Real
time wordt niet in technische zin gebruikt. Onder real time wordt verstaan dat
verwerking van berichten in het gehele GBA-stelsel snel genoeg gaat om het
uitvoeren van baliehandelingen en primaire processen zonder wachttijd te
laten verlopen. Dit sluit asynchroon berichtenverkeer in technische zin niet uit.

Service

Een service is het resultaat van een afgeronde inspanning die een organisatie,
medewerker of applicatie op basis van wettelijke taken of onderling gemaakte
afspraken levert en waarmee in een behoefte van één of meer andere
organisaties, medewerkers of applicaties wordt voorzien (NORA). De NORA
definieert een strikt onderscheid tussen Dienst en Service waarbij Dienst
gereserveerd is voor het leveren aan burgers en bedrijven en service voor het
leveren binnen de overheid, meestal als onderdeel van het leveren van een
Dienst. In de context van het GBA-stelsel leidt dit tot een kunstmatig
onderscheid, bijvoorbeeld gemeenten hebben er in sommige situaties een
interne rol (services) en in andere een meer externe (diensten).

Systematische
verstrekkingen

Verstrekkingen aan buitengemeentelijke afnemers (zie definities nieuwe
wetsvoorstel)
Het GBA-stelsel biedt 3 wijzen van systematische gegevensverstrekkingen:
•

spontane mutaties: spontane verstrekking van gegevens bij

128

Definitiestudie mGBA Versie 1.8

Term

Terugmeldfaciliteit

De moderne GBA mogelijk gemaakt…

Toelichting
wijziging van die gegevens waarvoor een afnemer of bijzondere
derde is geautoriseerd
•
selecties: periodieke of eenmalige vertrekking van die gegevens
waarvoor de afnemer is geautoriseerd
•
ad hoc-verstrekking: verstrekking op verzoek van de afnemer van
die gegevens waarvoor de afnemer is geautoriseerd.
Een technische voorziening gerealiseerd door het ICTU programma ODP,
onderdeel Generieke Ontsluiting Basisvoorzieningen als onderdeel van het
Stelsel van basisregistraties om terugmelding te verzenden aan de juiste
registratiehouder. Doelstelling van de TMF is één standaardproces voor
terugmelden aan alle basisregistraties mogelijk te maken. De TMF is nog niet in
productie.

Terugmelding

Een melding van een afnemer aan een basisregistratie dat uit het proces of
bewijsstukken van de afnemer gerede twijfel blijkt over een bepaald
authentieke gegeven. Alleen voor die authentieke gegevens waarvoor de
afnemer een terugmelding heeft gedaan, mag de afnemer de eigen gegevens
gebruiken.

Terugmeldvoorziening

Een technische voorziening voor alle afnemers die geautoriseerd zijn om
gebruik te maken van de GBA-V om terugmeldingen te doen aan het GBAStelsel. De TMV is in productie en wordt gebruikt door alle externe afnemers
die voldoen aan de eisen om het GBA als basisregistratie te gebruiken.

Transactie

Een transactie is een aaneenschakeling van stappen die als een geheel worden
doorgevoerd zodanig dat indien de transactie halverwege wordt afgebroken
alle betrokken onderdelen van het GBA-stelsel terugkeren in de toestand die ze
voor het begin van de transactie hadden. Belangrijk is dat een transactie uit
een workflow van meerdere berichten kan bestaan. Ieder van die berichten
wordt afzonderlijk bevestigd door de ontvanger en de transactie als geheel
wordt geregiseerd door de procesregie component (workflow engine).
Complexe transacties vereisen het zwaardere OSB protocol ebMS.
De NORA omschrijft een bedrijfstransactie als volgt: “Een bedrijfstransactie is
een niet-deelbare (atomaire) communicatieactie tussen twee applicaties (van
twee ketenpartners) bij de uitwisseling van berichten, in beginsel bestaand uit
één ‘verzoek’ en één optionele ‘respons’.”

Webdiensten

Diensten die via internet geleverd worden. Is synoniem met online diensten.

Wet basisregistratie
Personen

Wetsvoorstel dat beoogt de huidige GBA-wet te vereenvoudigen, definitieve
regelingen inzake basisregistraties en landelijke voorzieningen van het GBAstelsel te formuleren en de wettelijke basis voor de RNI te bieden en dat in de
loop van 2009 aan de Kamer moet worden aangeboden.

129

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Bijlage D. Leden expertteam en
begeleidingscommissie
Expertteam herijking definitiestudie:
Tim Berkelaar

ICTU

Vrien de Geest

Gemeente Den Haag

Ton Kassenaar

Gemeente Amsterdam

Marthe van de Veen

Gemeente Delft

Joke van de Drift

Gemeente Soest

Joop Meijer

Gemeente Lochem

Wim Zoet

BZK

Magda Noordenburg

ICTU/ E-GEM

Geert Deenen

Gemeente Helmond

Adriaan Holthuizen

BPR

Rik Duursma

Gem. Haarlemmermeer

Jan Barendse

BPR

Mark van Elswijk

ICTU

Anton Dekkers

Gemeente Breda

Esther ’t Hoen

BZK

Nicolle de Keijzer

VNG

Hans Lapidaire

BPR

Geïnterviewde personen
Mark van Elswijk

ICTU

Ton Kassenaar

Gemeente Amsterdam

Geert Deenen

Gemeente Helmond

Intern reviewteam Capgemini
Jeroen van Disseldorp

Capgemini

Marcel Rietdijk

Capgemini

Gerrit Slot

Capgemini

Jos Smits

Capgemini

Begeleidingscommissie herijking definitiestudie en businesscase
Joep Bosman

BZK

Guus Bronkhorst

BZK

Wim Zoet

BZK

Cees Meesters

NVVB

Nicole de Keijzer

VNG

Kees Keuzenkamp

BZK

Ton van der Burg

VNG

Arnold Reijnders

BZK

Cor van Tilborg

Programma mGBA

Ronald Mauer

Gemeente secretaris
Oegstgeest

Corien Pels Rijcken

Programma mGBA

Alphons van der Toorn

Ministerie financiën

Ferial Abdoel

Programma mGBA

manifestgroep

130

Definitiestudie mGBA Versie 1.8

De moderne GBA mogelijk gemaakt…

Bijlage E. Drie scenario’s (formulering
opdrachtverstrekking)
BIJLAGE 1 bij brief BPR2008/U56193
Toelichting op de Alternatieven voor de voortzetting van het programma mGBA.

1.

Alleen GBA-V

Als wordt gekozen voor het alternatief ‘Alleen GBA-V’ houdt de modernisering
in:
De afronding van de ontwikkeling en in beheer name van de GBA-V, d.w.z. een
landelijke voorziening voor de online verstrekking van GBA-gegevens aan
afnemers en gemeenten met gebruikmaking van webservices, 7 x 24 uur per
week
De GBA-V wordt stapsgewijs ontwikkeld.
GBA-V Online is gerealiseerd.
In de recent afgeronde inceptiefase zijn de scope en de kosten van de afronding
van GBA-V Fullservice in kaart gebracht. Onderdeel van de besluitvorming in het
najaar van 2008 is een besluit over de volgende fasen, waaronder de
elaboratiefase. Bij het gereedkomen van GBA Full Service is de GBA 7 x 24 uur
online raadpleegbaar en verzorgt de centrale voorziening de periodieke
verstrekkingen aan afnemers. Dan wordt nog wel gebruik gemaakt van het
bestaande netwerk voor dataverkeer.
De volgende stap is GBA-V Moderne Interfaces, d.w.z. het gebruik maken van
webdiensten. Het bestaande netwerk is dan niet meer nodig,

2.

GBA-V en BZS-K in combinatie met LO 4

In deze variant wordt er van uitgegaan dat het programma modernisering GBA,
naast de afronding van GBA-V, ook het ontwikkelen van het
Burgerzakensysteem-Kern omvat, alsmede de herziening van het
gegevensmodel, die wordt verwerkt in het Logisch Ontwerp 4.
Kort samengevat houdt BZS-K dat de rijksoverheid de kern specificeert van het
burgerzakensysteem waarmee de gemeenten de persoonsgegevens invoeren,
opslaan, beheren en gebruiken t.b.v. burgers en instellingen in dienstverlenende
processen. De door de rijksoverheid te ontwikkelen kern bevat de functionaliteit
om de GBA-gegevens op te vragen, te controleren, te actualiseren en in kopie te
leveren aan de GBA-V.
Deze kern is gebaseerd op het nieuwe Logisch Ontwerp (LO 4). Dit nieuwe LO
(versie 4) wijkt af van het huidige LO (versie 3.x) en is een vereiste om te komen
tot een modern GBA-stelsel. dat de mogelijkheden van elektronisch dataverkeer
volledig benut. Het nieuwe LO heeft een nieuw gegevensmodel en omvat een
aantal grote verbeteringen en verduidelijkingen ten aanzien van zowel inhoud
als structuur, ten opzichte van het huidige LO.

131

Definitiestudie mGBA Versie 1.8

3.

De moderne GBA mogelijk gemaakt…

Alleen L.O. Wijziging

De derde optie, genaamd “LO-wijziging”, gaat uit van de huidige manier van
werken. De beoogde wijzigingen in het gegevensmodel van de GBA worden
gerealiseerd door het opstellen van een nieuw Logisch Ontwerp door BZK.
Daarna gaan leveranciers dit LO 4 verwerken in hun bestaande systemen. Op dit
moment zijn er vijf verschillende systemen en drie leveranciers.
Het rijk betaalt een vergoeding voor het aanpassen van de systemen volgens
een vooraf afgesproken systeem. Implementatie vindt plaats bij de individuele
gemeenten.
Gedurende enige tijdbestaan LO3-en LO4-gemeenten naast elkaar en moeten
maatregelen worden getroffen om deze gemeenten gegevens met elkaar te
laten uitwisselen.
Bij iedere LO-wijziging wordt aan de hand van een puntensysteem de
bijbehorende vergoeding bepaald; het rijk keert deze vergoeding uit voor ieder
bestaand systeem (momenteel zijn er vijf verschillende systemen).

132

133