Deze ProjectStartArchitectuur (PSA) bevat een eerste opzet voor de architectuur voor een Landelijk Register Kinderopvang. De opzet van het document is gebaseerd op de Nederlandse Overheid Referentie Architectuur (NORA).

De PSA beschrijft de bedrijfsarchitectuur op hoofdlijnen om een gemeenschappelijk referentiekader te kunnen bepalen, waaraan in de verschillende architectuuraspecten gerefereerd wordt. Beschrijvingen van processen, conversie en organisatorische consequentie als gevolg van de Wet Kinderopvang [2] blijven op hoofdlijnen, maar zullen onder verantwoordelijkheid van een ander deelprogramma/Implementatie worden uitgewerkt. Het beheer zal op hoofdlijnen worden beschreven, maar wordt in een ander deelprogramma Beheer nader uitgewerkt.

De doelgroep voor deze PSA is divers:

Enerzijds is het een document dat (gefaseerd) de kaders voor de tussen- en de eindoplossing beschrijft als ingangsdocument voor functioneel, technisch en database-ontwerp. Hiermee zijn de functioneel en technisch en ontwerpers/lead developers/DBA's doelgroep van dit document.

Anderzijds is het ook een document dat dient voor afstemming met de architecten van de betrokken partijen als GGD'en, gemeenten en OCW. Deze architecten zijn dus onderdeel van de doelgroep.

Tenslotte moet het document, juist door zijn kaderstellende karakter, ook een belangrijke rol spelen bij het borgen van de kwaliteit van het project. Hiermee is het ook onderwerp van review door Project Assurance, die dus onderdeel uitmaken van de doelgroep.

Dit document is een PSA en werkt het ‘negen + twee’-vlakmodel van de NORA uit . Voor een gedetailleerde toelichting wordt verwezen naar het NORA 2.0 rapport.

Het geheel aan voorzieningen (systeemcomponenten) dat het totale werkveld van de uitvoering van de Wet Kinderopvang op termijn zal ondersteunen, is van dusdanige omvang en complexiteit, dat voor een gefaseerde aanpak is gekozen. In het PID ‘Landelijk Register Kinderopvang’ v1.1 [1] is een volledige beschrijving gegeven van het geheel aan voorzieningen.

Voorliggende PSA beschrijft de kaders voor het eerste deel van de ICT-ondersteuning, zoals deze per 1 januari 2010 nodig is om te voldoen aan de wet.

Op dat moment zal in elk geval een voorziening gerealiseerd zijn, waarmee de registratie van kinderopvang ondersteund kan worden en gedragen wordt door direct betrokkenen, het Landelijk Register (LR). Ook zullen er voorzieningen zijn voor het publiek en relevante overheidspartijen om toegang tot informatie over kinderopvang te krijgen.

Dit architectuurdocument gebruikt de volgende hoofdstukindeling:

In hoofdstuk 2 wordt de achtergrond van het programma en de oplossing geschetst.

Hoofdstuk 3 bevat een eerste opdeling in processen en onderkende componenten.

In de hoofdstukken 4, 5 en 6 worden conform NORA de Bedrijfs-, Informatie- en Technische Architectuur uitgewerkt.

Specifieke aandachtspunten en eisen betreffende beveiliging en beheer zijn te vinden in respectievelijk hoofdstuk 7 en 8.

Tenslotte zijn in bijlage A de gebruikte uitgangsdocumenten en in bijlage B de relevante NORA-definities opgenomen en bijlage C bevat een korte uitleg van de gebruikte UML-termen.

In dit deel van het project wordt een aantal andere architecturen toegepast als kaderstellend:

1. 1

   Referentiearchitectuur sector Onderwijs [15];

2. 2

   NORA;

Daarnaast zijn er in het aandachtsgebied Kinderopvang een aantal andere referentiearchitecturen bekend, maar waarvan is vastgesteld, dat deze in deze eerste fase tot 1-1-2010 niet van toepassing zijn. Te denken valt aan GEMMA, de gemeentelijke Model Archtitectuur en de Model Architectuur voor Rijkstoezichts- en Handhavingseenheden (MARTHE) [4].

MARTHE is nog niet relevant aangezien het als architectuur iets zegt over de processen Toezicht houden en Handhaven en deze zijn beide voor deze PSA-versie nog buiten scope.

GEMMA is nog buiten beschouwing aangezien de scope van deze PSA alleen het Landelijk Register en de ontsluiting ervan via portalen betreft en niet de ontsluiting via berichten. Ook zijn de processen niet relevant aangezien deze onder het deel-project Implementatie en niet ICT vallen. Wel is het onderdeel RSGB meegenomen in de beschrijving van het gegevensmodel.

Dit document heeft ook een relatie met een aantal documenten die verdergaan op basis van de inhoud. Het gaat hier om de volgende documenten:

1. 1

   Het Functioneel Ontwerp per uiteindelijk te onderkennen component levert een uitwerking van de requirements en functionaliteit binnen de kaders zoals gesteld binnen dit architectuurdocument.

2. 2

   Het Softwarearchitectuurdocument beschrijft de softwarearchitectuur zoals gehanteerd voor het op te leveren systeem en benoemt te gebruiken tools, pakketten en platformen die voor de ontwikkeling gebruikt gaan worden. Dit document beschrijft het gehele complex en waar nodig wordt per later te onderkennen component een aparte uitwerking in een Technisch Ontwerp gemaakt.

3. 3

   Het Deploymentdocument beschrijft welke omgevingen gebruikt worden en hoe de opgeleverde applicatie of voorziening op deze omgevingen gedeployed moet worden.

4. 4

   Risicoclassificatie en beveiligingsplan.

Het programma Landelijk Register Kinderopvang is een breed programma dat uiteindelijk de volledige ondersteuning van de nieuwe wet Kinderopvang gaat opleveren.

Het programma bestaat, om dit brede doel te realiseren, uit een aantal deelprojecten zoals Implementatie, Beheer en ICT. Het is evident dat er een nauwe relatie is tussen de verschillende deelprojecten.

Deze PSA beschrijft zoals reeds vermeld is het eerste deel van de uiteindelijke bijdrage die het ICT-gedeelte van het programma gaat leveren per 1 januari 2010 aan het bereiken van het eindresultaat. In nieuwe opleveringen van deze PSA zal de uiteindelijke oplossing integraal worden beschreven.

Het probleem dat dit programma dient op te lossen is heel eenvoudig: het ondersteunen bij de implementatie van de nieuwe Wet Kinderopvang.

Reden voor de introductie van deze nieuwe wet is meerledig:

1. •

   De fraudegevoeligheid van de huidige Toeslagen-regeling en de daarmee gepaard gaande extra uitgaven.

2. •

   De ontsluiting van informatie richting ouders over de kwaliteit van toezicht is op gemeentelijk niveau geregeld, met alle gebreken aan toegankelijkheid, uniformiteit en standaardisatie van de ontsluiting van informatie aan ouders van dien.

Daarnaast geldt dat:

1. •

   ‘Vernieuwing toezicht’ eist een beter toezicht (en handhaving) tegen lagere kosten, (verbeterde) automatisering kan hierin een rol spelen.

Om de bovengenoemde problemen op te lossen is een integrale aanpak nodig, zowel ICT als administratieve organisatie hebben een rol te spelen in de oplossing.

ICT-technisch worden de volgende deel-resultaten onderkend:

1. 1

   Een operationeel Landelijk Register van geregistreerde kinderopvang-instanties conform de nieuwe wet per 1-1-2010.

2. 2

   Ondersteuning voor ouders bij het controleren of hun kinderopvang-instantie geregistreerd is door de ontsluiting van het register naar ouders per 1-1-2010.

3. 3

   Ondersteuning van de Belastingdienst, met behulp van dit register, bij de uitvoering van het Toeslagen-beleid door de informatie uit het Register aan de Belastingdienst ter beschikking te stellen per 1-10-2010.

Daarnaast moeten de volgende doelstellingen meegenomen worden:

1. 4

   Ondersteuning van de kwaliteitsprocessen rondom dit register, zijnde het toezichtsproces, het handhavingsproces en de koppeling met de relevante Basisregistraties.

2. 5

   Ondersteuning voor de juiste managementinformatie ten behoeve van zowel eerste- als tweedelijns toezichthouders uit het geautomatiseerde gedeelte van de processen.

Voorliggende PSA richt zich op de eerste iteratie van de totale oplossing, het inrichten van een Landelijk Register en de mogelijkheden (portalen) voor Publiek en Overheden om het register te ontsluiten. (voornoemde punten 1 en 2)

Op basis van de in bovenstaande paragraaf benoemde problemen die opgelost moeten worden en de prioriteit die ligt op het realiseren van een kwalitatief hoogwaardig register volgt de volgende volgorde van op te leveren resultaten:

1. 1

   Realiseer een Landelijk Register van geregistreerde kinderopvang-instanties conform de nieuwe wet per 1-1-2010.

2. 2

   Ontsluit dit register voor gebruik door ouders zodat ook zij inzicht hebben in de geregistreerde kinderopvang-instanties.

In een latere fase ook:

1. 3

   Realiseer de ondersteuning van de kwaliteitsprocessen rondom dit register, zijnde het toezichtsproces, het handhavingsproces en de koppeling met de relevante Basisregistraties. Deze ondersteuning voor zo vroeg mogelijk in 2010 gerealiseerd.

2. 4

   Ondersteun met behulp van dit register de uitvoering van het Toeslagen-beleid door de informatie uit het Register aan de Belastingdienst ter beschikking te stellen.

3. 5

   Borg dat het op te leveren geautomatiseerde deel van de oplossing de juiste managementinformatie levert aan de eerste- en tweede-lijns toezichthouders.

Zoals hierboven al benoemd is de kern van het op te leveren complex van ICT-voorzieningen het register zelf en de andere benoemde voorzieningen ten behoeve van de ontsluiting van de registergegevens.

In deze context ziet de omgeving als volgt uit:

Hoe ziet de omgeving er per 1-1-2010 uit?

1. •

   Gemeenten kunnen per deze datum starten met de inschrijving van die houders, kindercentra, gastouderbureaus en gastouders in het Landelijk Register, die gevestigd zijn in hun gemeente. Gemeenten kunnen besluiten de invoer van de gegevens te laten uitvoeren door een derde, een data-entry bureau.

2. •

   Gemeenten zijn vervolgens verantwoordelijk voor het gegevensbeheer het Landelijk Register;

3. •

   Het publiek kan (een beperkte set van gegevens uit) het Landelijk Register raadplegen;

4. •

   De organisaties die betrokken zijn bij de uitvoering van de Wet Kinderopvang krijgen de mogelijkheid om (de volledige set van gegevens uit) het Landelijk Register te raadplegen.

NB: In hoofdstuk 4 wordt nader gegaan op de taken en verantwoordelijkheden van de verschillende relevante actoren in de omgeving van het Landelijk Register.

Gegeven de gefaseerde aanpak van het project beschrijft dit hoofdstuk voorlopig alleen de scope van de eerste oplevering per 1-1-2010.

De scope van de eerste iteratie van het project heeft gevolgen voor de mate waaraan aan de verschillende referentiearchitecturen wordt voldaan.

Vooruitlopend op een meer gedetailleerde uitwerking in de verschillende hoofdstukken over de bedrijfs-, informatie en technische architectuur (resp. hoofdstuk 4, 5 en 6) wordt in deze iteratie een drietal systeemcomponenten gerealiseerd, die in vervolgfasen verder geïntegreerd zullen worden met de overige benodigde componenten.

De ICT-ondersteuning voor processen die plaatsvinden binnen de gemeenten (zoals het behandelen van aanvragen voor registratie, het verstrekken van beschikkingen) vallen buiten de scope van dit project.

Deze PSA beschrijft de volgende voorzieningen:

1. •

   Landelijk Register

2. •

   Overheidsportaal

3. •

   Publieksportaal

Door de scope op de voorzieningen op deze wijze vast te stellen, wordt tevens afgebakend welke processen ondersteund gaan worden in de eerste oplevering. Het zijn de processen voor Registreren en Gebruiken. Deze processen worden globaal uitgewerkt in paragraaf 4.4.

Op dit moment zijn er vanuit het Landelijk Register gezien twee koppelvlakken in scope:

1. 1

   Het koppelvlak met het Publieksportaal. Dit is een eenvoudig koppelvlak waarlangs gegevens geleverd worden als antwoord op door het publiek gestelde vragen.

2. 2

   Het koppelvlak met het Overheidsportaal. Dit is een complexer koppelvlak waarmee niet alleen gegevens ontsloten worden maar waarbij ook gegevens aangepast moeten kunnen worden.

In deze fase zijn nog geen externe systemen in scope.

(Basis)register(s)

Deze zijn nog niet in scope als externe systemen, de definities zijn al wel meegenomen in het conceptueel gegevensmodel. Op termijn wordt een systeemkoppeling met de landelijke registers GBA en NHR wel voorzien.

De belangrijkste uitgangspunten voor deze fase van het project en daarmee deze versie van de projectstartarchitectuur zijn:

1. •

   De datum van 1-1-2010 staat vast als de datum waarop de nieuwe Wet Kinderopvang in werking treedt. Daarmee is deze datum sturend in de fasering.

2. •

   De uitvoering van de Wet Kinderopvang en de AMvB [3] zijn uitgangspunt voor het ontwerp van het LR.

3. •

   De ontwerpbeslissingen zijn gebaseerd op afspraken met de opdrachtgever OCW en de belanghebbenden. De ontwerpbeslissingen worden in een los document beschreven.

De overheid is voornemens de interoperabiliteit tussen overheidsinstellingen te verbeteren. Daarvoor worden in toenemende maten standaarden benoemd en afspraken gemaakt over de wijze waarop met elkaar gecommuniceerd gaat worden. De NORA is daarvan een uitvloeisel. Om toe te lichten op welke wijze dit ICT-project de NORA principes interpreteert worden de 20 fundamentele principes genoemd en vertaald naar de projectarchitectuur.

NB: De referentiearchitectuur Onderwijs bevat een interpretatie van de NORA principes die in beginsel van toepassing zijn op deze PSA, zij het dat in de eerste oplevering zoals nu voorziening is per 1-1-2010 niet aan alle principes kan worden voldaan. De reden is dat een deel buiten verantwoordelijkheid van het ICT-project valt, voorts wordt er nu nog geen integrale oplossing wordt gerealiseerd, slechts alleen het Landelijk Register onderdeel. Voor inhoudelijke vertaling van de principes van OCW, wordt verwezen naar het document ‘Referentiearchitectuur Onderwijs’ d.d. 29 september 2008 van B. Gaakeer.

DE NORA-TEKSTEN ZIJN LETTERLIJK OVERGENOMEN

Verder wordt gebruikt gemaakt van de volgende standaarden:

1. •

   UML voor gegevensmodellering

De bedrijfsarchitectuur beschrijft de samenhang tussen de diensten en services die de LR moet leveren aan de verschillende belanghebbenden (actoren) die betrokken zijn bij de uitvoering van de Wet Kinderopvang. Om de diensten en services te kunnen leveren, moeten organisaties samenwerken en processen uitvoeren. De processen worden in dit hoofdstuk op hoofdlijnen toegelicht. De processen zijn echter inrichtingsonafhankelijk beschreven en blijven op hoofdlijnen, enerzijds omdat gemeenten en GGD'en eigen keuzes kunnen maken over de wijze waarop men de processen wil inrichten, anderzijds omdat het deelprogramma Implementatie de processen en procedures nader zal uitdiepen.

In het aandachtsgebied van de Wet Kinderopvang, participeren een aantal verschillende organisaties. Elke organisatie heeft wettelijk vastgestelde taken in de uitvoering van de Wet KO. Door de onderlinge samenwerking tussen overheidsorganisaties, kunnen diensten worden geleverd aan het publiek en services tussen de onderlinge overheden. Om de taken adequaat uit te kunnen voeren en de diensten te kunnen verlenen, wordt gebruik gemaakt van ICT-voorzieningen. Welke overheidsorganisaties betrokken zijn, welke diensten en services geleverd worden en welke processen ervoor nodig zijn, wordt in de verschillende paragrafen van dit hoofdstuk toegelicht.

In het aandachtsgebied zijn vier processen te onderkennen:

1. •

   registreren

2. •

   inspecteren

3. •

   handhaven

4. •

   gebruiken

NB: de focus van de eerste fase ligt op de processen Registreren en Gebruiken. Gebruiken kent als belanghebbenden publiek, GGD, Belastingdienst, IvhO en OCW.

In hoofdstuk 3 zijn de fundamentele principes van de NORA behandeld. De relevante afgeleide principes worden in deze paragraaf nader toegelicht. Per principe wordt een toelichting gegeven op de wijze waarop deze PSA het principe interpreteert.

Het overzicht bevat per (deel)principe de status:

De ‘P-code’ refereert aan het fundamenteel principe waar het deelprincipe uit afgeleid is. (§ 3.3)

DE NORA-TEKSTEN ZIJN LETTERLIJK OVERGENOMEN UIT VERSIE 2.0

Bij de uitvoering van de Wet Kinderopvang zijn de volgende organisaties betrokken:

1. •

   Ministerie van Onderwijs, Cultuur en Wetenschappen (OCW):

   1. −

      De uitvoering van de Wet Kinderopvang valt onder ministeriële verantwoordelijkheid van de Minister van OCW.

      1. ○

         Het LR valt onder verantwoordelijkheid van de Minister van OCW

2. •

   GGD

   1. −

      in de Wet Kinderopvang is bepaald dat het college van de gemeente ‘de directeur van de GGD’ aanwijst als toezichthouder. De GGD is afnemer van de gegevens uit het Landelijk Register voor de uitvoering van toezicht op de kinderopvang. Daarnaast heeft de GGD ook een handhavingsbevoegdheid, inzake het bevel.

      1. ○

         De GGD is verantwoordelijk voor de uitvoering van de inspecties.

3. •

   Gemeente:

   1. −

      De gemeente is verantwoordelijk voor het volledig en actueel houden van gegevens in het Landelijk Register (LR), in zoverre de gegevens betrekking hebben op organisaties voor kinderopvang die gevestigd zijn in de gemeente. Daarmee is gemeente de registerhouder en is de enige organisatie die gegevens van de betreffende organisaties voor kinderopvang mag wijzigen in het LR.

      1. ○

         De gemeente is verantwoordelijk voor de wettelijk bepaalde gegevens in het LR.

4. •

   Inspectie van het Onderwijs (IvhO)

   1. −

      De gemeenten zijn verantwoordelijk voor het toezicht op de kinderopvang. De GGD voert het toezicht uit. De IvhO inspecteert de uitvoering op het toezicht. De IvhO is derhalve afnemer van het LR.

      1. ○

         De IvhO is verantwoordelijk voor het tweedelijns toezicht.

5. •

   Belastingdienst (BD)

   1. −

      De Belastingdienst keert de kindertopvangtoeslag uit aan ouders indien zij daartoe recht toe hebben. Om onterechte vergoedingen en toeslagen te voorkomen, is de Belastingdienst afnemer van de LR.

      1. ○

         De BD is verantwoordelijk voor uitvoering van de correcte naleving van de Wet Inkomensafhankelijke voor de kinderopvangtoeslag.

6. •

   Gastouderbureau (GOB): zie woordenlijst.

   1. −

      Een gastouderbureau bemiddelt tussen vraag en aanbod van kinderopvang en is verantwoordelijk voor het doen van het verzoek om een gastouder op te nemen in het LR.

Daarnaast zijn er belanghebbenden die een relevante rol vervullen binnen het aandachtsgebied hetzij in uitvoerende zin, hetzij in afnemende zin.

1. •

   Gastouder (GO): zie woordenlijst

2. •

   Publiek: de personen die anoniem informatie willen ontsluiten over kinderopvang.

Vertegenwoordigers namens de GGD'en en Gemeenten gedurende PSA-fase.

1. •

   Vereniging Nederlandse Gemeenten (VNG)

   1. −

      De VNG behartigt de belangen van de Nederlandse gemeenten en participeert als adviseur bij de inrichting van de voorzieningen ter ondersteuning van de Wet KO.

2. •

   GGD-Nederland

   1. −

      GGD Nederland is de landelijke vereniging voor GGD'en. Namens de GGD'en is zij een gesprekspartner het verschillende ministeries en belangenorganisaties. GGD-Nederland behartigt de belangen van alle GGD'en in samenwerkende projecten.

3. •

   beheerorganisatie van voorzieningen (nog vast te stellen)

In een latere fase volgen volgende actoren en/of betrokkenen:

1. •

   Landelijke voorzieningen voor Basisregistraties: het is wettelijk bepaald dat de overheid voor de uitvoering van wettelijke taken gebruik maakt van gegevens uit basisregistraties. De gegevens in het LR komen overeen met de gegevens in de basisregistraties. Directe koppelingen met de landelijke voorzieningen worden op termijn gerealiseerd.

   1. −

      Gemeentelijke Basis Administratie voor persoonsgegevens (GBA): de GBA is de authentieke bron voor persoonsgegevens van Natuurlijke personen. Het gebruik is verplicht sinds 1 april 2007.

   2. −

      Nieuw Handelsregister (NHR): Het Nieuw Handelsregister is sinds 1 juli 2008 dusdanig uitgebreid, dat alle ondernemingen zich hebben ingeschreven. Daarmee is het de authentieke bron voor ondernemingen en instellingen van Nederland. Het betreft Niet-natuurlijke personen.

2. •

   Inspectieraad. Op het moment dat de processen Toezicht en Handhaving binnen scope komen ontstaat overlap met het werk van de Inspectieraad. Er zijn zeker mogelijkheden voor samenwerking denkbaar.

Bij de uitvoering van de Wet Kinderopvang worden processen uitgevoerd door verschillende organisaties die uiteindelijk het doel van de wet moeten gaan realiseren:

het verbeteren van toezicht op kinderopvang, misbruik en oneigenlijk gebruik van geld en middelen terug te dringen en het stelsel van de Wet kinderopvang toegankelijk en beheersbaar te houden.

Om de benodigde voorzieningen voor ondersteuning van de processen goed te kunnen ondersteunen zijn de hoofdprocessen opgeknipt in deelprocessen:

1. 1

   registreren: het vastleggen en onderhouden van gegevens over actoren die betrokken zijn bij de uitvoering van de Wet Kinderopvang in het Landelijk Register; Het registreren is een ketenproces, ook het verwerken van wijzigingen is een ketenproces.

2. 2

   inspecteren: het uitvoeren van kwalitatieve controles op de correcte naleving van de wettelijk bepaalde criteria in de Wet Kinderopvang;

3. 3

   handhaven: uitschrijven van aanwijzingen naar aanleiding van vastgestelde tekortkomingen in de kinderopvang en het uitvoeren van controle op de naleving daarvan.

4. 4

   gebruiken: het toepassen van informatie uit de LR-administratie ten behoeve van processen bij overheidsinstellingen en gebruiken van de LR-gegevens door het publiek.

Verantwoordelijk voor de uitvoering:

1. •

   Registeren en handhaven worden uitgevoerd door de gemeenten waar de locatie gevestigd is of gaat worden, de GGD kan schriftelijk bevel geven indien de kwaliteit ernstig tekortschiet en uitstel voor ingrijpen niet mogelijk is.

2. •

   Inspecteren wordt in betreffende gemeente uitgevoerd door de GGD waarvan de directeur is aangewezen als toezichthouder.

3. •

   Gebruiken kan door iedereen plaatsvinden. Bij wet is bepaald welk gegeven voor publiek gebruik toegestaan is en welk gegeven alleen binnen de overheid gebruikt mag worden.

NB: de processen worden op hoofdlijnen en inrichtingsonafhankelijk beschreven, omdat elke gemeente de uitvoering van de wettelijke taken anders kan inrichten. Het project Implementatie zal de procedures en processen nader uitwerken.

De NORA hanteert een paradigma om de hiërarchie van procestypen te duiden. De voornoemde procesplaat is te matchen met de NORA-definities, zoals uitgewerkt in onderstaande tabel.

De voor deze PSA relevante ketenprocessen ‘Registreren nieuwe kinderopvang’ en ‘Wijzigen registratie kinderopvang’ worden verder uitgewerkt.

De gemeente ontvangt een aanvraag voor registratie van een kinderopvang in het LR. De aanvraag wordt door de gemeente in behandeling genomen. Na een administratieve toets wordt een opdracht verstrekt aan de GGD voor inspectie. De GGD voert een kwalitatieve toets uit op de documenten en inspecteert afhankelijk van het toetsingskader en de soort kinderopvang de opvanglocatie. Het resultaat van het inspectieproces wordt vastgelegd in een inspectierapport en vergezeld door een advies naar de gemeente gestuurd. De gemeente neemt een besluit en registreert de kinderopvang definitief in het Landelijk Register als aan de eisen is voldaan of wijst de aanvraag af. De registratie en de inspectieresultaten worden vervolgens toegankelijk gemaakt voor het publiek.

Mate van ICT-ondersteuning: alleen het registreren van de kinderopvang in het Landelijk Register wordt in deze eerste fase van het ICT-project LR-GIR KO ondersteund door ICT. De registratie van inspectierapportages door de GGD wordt door bestaande middelen ondersteund. Het aanvraagproces bij de gemeente wordt niet door ICT vanuit het project LR-GIR KO ondersteund.

De bedrijfsprocessen zijn een decompositie van de ketenprocessen.

1. 1

   Aanvragen voor registratie in LR

2. 2

   Ontvangen aanvraag voor registratie

3. 3

   In behandeling nemen aanvraag voor registratie

4. 4

   Besluiten over aanvraag voor registratie

5. 5

   Verwerken van wijzigingen

6. 6

   Ontvangen klacht

7. 7

   Beëindigen kinderopvang

De meeste gemeenten hebben hun handhavingsbeleid vastgelegd. Daarmee is bepaalt elke gemeente, binnen de kaders van de wet, hoe de uitvoering van het beleid plaatsvindt. Wat er gedaan moet worden voor de uitvoering staat in de wetgeving vast. Een wijze om het wat te beschrijven is het toepassen van bedrijfsfuncties in plaats van processen.

Bedrijfsfuncties zijn dus inrichtingsonafhankelijke beschrijvingen van de bijdragen die betrokkenen leveren.

In de bedrijfsprocessen worden de volgende functies uitgevoerd:

Het systeemcomplex ondersteunt de volgende functies:

legenda

LRK is het totale -systeemcomplex.

LR is het Landelijk Registeren

OP is het OverheidsPortaal

PP is het Publieksportaal

Gem is het geheel aan gemeentelijke processen en systemen

GGD is het geheel aan GGD processen en systemen

BD is het geheel aan Belastingdienst processen en systemen

houder is het geheel aan handelingen van de houder van een KO.

In de cellen achter de deelfuncties staan CRUD-tekens dit houdt in:

C= creatie, R = raadplegen, U = updaten (muteren)van gegevens en D = delete (verwijderen).

Uit bovenstaande functionele decompositie is af te leiden op welke wijze het Landelijk Register en de verschillende portalen de volgende functies ondersteunen.

1. 1

   Verifiëren identificatie van aanvrager: de aanvrager kan een gastouderbureau zijn. De gemeente kan door raadpleging in het LR vaststellen dat het daadwerkelijk een ingeschreven GOB betreft.

2. 2

   Vastleggen ontvangen aanvraag voor registratie: Een ‘aanvraag voor registratie’ die volledig is, wordt geregistreerd, waarbij herkenbaar is dat het nog geen definitieve inschrijving betreft.

3. 3

   Vastleggen voorlopige gegevens van nieuwe org. voor kinderopvang: de wettelijke vastgestelde gegevens worden vastgelegd.

4. 4

   Verstrekken inschrijvingsnummer LR: op het moment dat een kinderopvang voldoet aan alle administratieve en kwalitatieve eisen (na GGD-inspectie) wordt de kinderopvang definitief ingeschreven in het LR. Het LR genereert een inschrijvingsnummer.

5. 5

   Identificeren melder: aan de hand van raadpleging van het LR kan mogelijk vastgesteld worden of degene die wijzigingen wenst door te geven daarvoor bevoegd is.

6. 6

   Controleren wijzigingen: bij het behandelen van eventuele meldingen van wijzigingen kan raadplegen van het LR noodzakelijk zijn.

7. 7

   Verwerken van wijzigingen: wijzigingen in het LR worden met behulp van daarvoor bestemde functionaliteiten worden verwerkt.

8. 8

   Bepalen vervolgacties: aan de hand van wijzigingen of klachten kan het wenselijk zijn het LR te raadplegen.

9. 9

   Ontvangen van klacht m.b.t. kinderopvang: bij het ontvangen van een klacht kan het noodzakelijk zijn het LR te raadplegen.

10. 10

    Behandelen klacht mbt kinderopvang: voor het behandelen van een klacht kan het noodzakelijk zijn het LR te raadplegen.

11. 11

    Besluiten afhandeling klacht m.b.t. kinderopvang: bij het besluiten van de afhandeling van een klacht kan het wenselijk of noodzakelijk zijn om het LR te raadplegen.

12. 12

    Vastleggen inspectierapporten: De gemeente legt de door de GGD ontvangen inspectierapporten vast en maakt deze toegankelijk zoals in de wet bepaald is.

13. 13

    Ontvangen verzoek voor beëindiging kinderopvang: bij het in ontvangst nemen van een verzoek voor beëindiging kinderopvang is het noodzakelijk te raadplegen in het LR.

14. 14

    Behandelen verzoek voor beëindiging kinderopvang: bij het behandelen van het verzoek voor beëindiging van de kinderopvang, is het noodzakelijk het LR te raadplegen.

15. 15

    Vastleggen beëindiging kinderopvang: voor de beëindiging van een kinderopvang is het noodzakelijk te wijzigen in het LR.

De overige functies in het overzicht worden niet door ICT van het project LR-GIR KO ondersteunt, maar worden door de gemeente met procedures uitgevoerd of door gemeentelijke systemen.

Er zijn verschillende aanleidingen om mutaties in het register door te voeren:

1. 1

   Na registratie in het Landelijk Register voert de GGD periodiek aangekondigde en onaangekondigde inspecties uit op de kinderopvang. Alle overtredingen of tekortkomingen aan de kinderopvang worden door de GGD aan de gemeenten doorgegeven in de vorm van inspectierapporten en handhavingsadviezen. Afhankelijk van gemeentelijk beleid gaat de de gemeente tot actie over.

2. 2

   De gemeenten krijgen via de GBA en NHR wijzigingen door inzake gegevens over kinderopvang;

3. 3

   Houders van organisaties van kinderopvang geven wijzigingen door aan de gemeenten.

De gemeente behandelt de gemelde wijzigingen en neemt een besluit om vervolgens een handhavingsproces op te starten en/of om direct wijzigingen in te voeren in het Landelijk Register, als de wijzigingen gevolgen hebben voor de geregistreerde gegevens. Afhankelijk van de aard van de gegevens die wijzen, kan een nieuwe inspectie nodig zijn.

Mate van ICT-ondersteuning: het raadplegen van gegevens uit het LR wordt ondersteund. Daarnaast komt er voor geautoriseerde gebruikers bij of namens de gemeenten functionaliteit om gegevens te muteren in het LR.

Alleen het resultaat van het besluiten wordt vastgelegd in het LR.

Dit ketenproces is eruit gelicht, omdat het grootste deel van het ketenproces niet ondersteund wordt door het LR, maar wel het uiteindelijke resultaat vastlegt.

Functionele decompositie voor Inspecteren en Handhaven volgen in een vervolgfase na deze PSA deel 1.

De eerste oplevering zal voor het publiek, de GGD, de BD en de IvhO functionaliteiten opleveren voor het raadplegen van gegevens uit het LR. De gegevens die getoond mogen worden is vastgelegd in de Wet.

Het kunnen raadplegen van de gegevens over kinderopvang door het Publiek (incl. de kinderopvang, vraagouders) is tevens wettelijke bepaald.

Deze paragraaf beschrijft welke diensten en services de Gemeenschappelijke Inspectieruimte biedt. In de NORA wordt met een DIENST bedoelt 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. Een service is vrij vertaald een interne dienst, ofwel tussen overheidsorganisaties.

Voor de relevante definities van deze termen wordt verwezen naar NORA (zie Bijlage B).

Vanuit het NORA-perspectief levert het LR de volgende diensten:

1. •

   faciliteit voor kinderopvang om zich in te laten schrijven in het landelijk register

2. •

   faciliteit voor informatieverstrekking over geregistreerde kinderopvang

3. •

   faciliteit voor informatieverstrekking over kwaliteit van de kinderopvang

Vanuit het NORA-perspectief levert het LR de volgende diensten:

1. •

   faciliteit voor kinderopvang te registreren voor gemeenten

2. •

   faciliteit om wijzigingen van gegevens over kinderopvang te registreren

3. •

   landelijke informatie te verstrekken over geregistreerde kinderopvang voor afnemende overheidsorganisaties.

4. •

   Mogelijkheid om gegevens uit het LR te bevragen t.b.v. toezicht.

5. •

   Op basis van de zoekcriteria van de gebruiker van het Publieks- of Overheidsportaal worden de juiste gegevens getoond aan de gebruiker.

6. •

   Mogelijkheid om historische gegevens uit het LR te raadplegen via het Overheidsportaal voor geautoriseerde gebruikers.

Bij de eerste oplevering wordt alleen gebruik gemaakt van standaard tabellen. Verder worden er geen externe services gebruikt.

Dit hoofdstuk adresseert de 'Hoe' aspecten van de oplossing die in de vorige hoofdstuk beschreven processen en bedrijfsfuncties moet ondersteunen. Als uitgangspunt geldt dat per 1-1-2010 slechts processen ‘Registreren’ en ‘Gebruiken’ relevant zijn en dat het systeemcomplex geen enkele vorm van workflow management voor deze processen ondersteunt. Dit houdt in dat aansturing van de administratieve processen rondom Register procedureel plaats vindt.

In de overeenstemming met de scope van deze versie van het PSA heeft informatiearchitectuur betrekking op de volgende componenten van de totale oplossing:

1. •

   Landelijke Register (LR).

2. •

   Publieksportaal (PP) voor de burgers.

3. •

   Overheidsportaal (OP) voor de bevoegde functionarissen.

Deze componenten worden als afzonderlijke ICT producten beschouwd die samen moeten werken om benodigde functionaliteit te kunnen leveren aan de eindgebruikers.

Aangezien de expliciete splitsing van het systeemcomplex in afzonderlijk op te leveren componenten, wordt als uitgangspunt voor de architectuur de service-geörienteerde benadering gekozen (SGA). Vanuit de oogpunt van service-oriëntatie, beschouwen wij het Landelijke Register als een goed afgebakende systeem die ontsloten wordt via een set van services. Wij noemen ze de Register Services. Zowel de Overheidsportaal als Publieksportaal maken gebruik van deze services.

In de eerste oplevering van het systeemcomplex (1-1-2010) wordt een beperkte set aan services aangeboden. Als uitgangspunt geldt dat in de hoofdstuk 4.4.4 beschreven functies die betrekking hebben op het LR ondersteund worden. Op gebruik van deze functies is een autorisatiemodel van toepassing. Het autorisatiemodel moet door de Overheidsportaal ondersteund worden. Daarnaast wordt die informatie uit het Landelijk Register die als openbaar wordt beschouwd, via een openbare website aangeboden aan alle belangstellenden. Dit vindt plaats via het Publieksportaal.

De onderstaand tabel geeft aan de doelgroepen die gebruik kunnen maken van de services van Overheidsportaal waarop ze afzonderlijk geautoriseerd moeten worden

Het aantal afzonderlijke gebruikersaccounts per doelgroep wordt nader bepaald.

Onderstaande afbeelding geeft de beoogde situatie weer per 1-1-2010. In deze situatie is het Landelijk Register en bijbehorende Register Services gereed voor gebruik en zijn zowel de Publieksportaal als de Overheidsportaal voor de beoogde doelgroep gerealiseerd en toegankelijk gemaakt via een vooraf afgesproken domeinnaam op Internet (het URL).

Architectuureisen die worden gesteld aan deze voorziening zijn principes en richtlijnen die afgeleid zijn van de relevante bovenliggende architecturen en de wettelijk kaders Relevante architecturen zijn in Hoofdstuk 1.4 genoemd. De beschikbare wettelijke kaders zijn de nieuwe Wet Kinderopvang en de AMvB.

Referentiearchitectuur Onderwijs bevat aantal generieke principes die van invloed zijn op de positionering van door het project op te leveren ICT informatievoorzieningen binnen de e-overheid en op de keuzes van functionele scope van de afzonderlijke componenten van het systeemcomplex.

Onderstaande figuur geeft de middellange termijn visie aan op de samenhang van de informatievoorzieningen binnen sector Onderwijs:’

Op dit moment is Kinderopvang niet expliciet benoemd in de architectuur. Om die reden is positioneren van het systeemcomplex in de architectuur van het sector niet eenvoudig. Er kan wel gebruik worden gemaakt van aantal principes die betrekking hebben op de beschreven diensten die Portalen (Portaal Burger en Portaal Instelling) uit de geciteerde architectuurplaat bieden.

In de onderstaand tabel zijn relevante principes uit Architectuur van Onderwijs en hun vertaling naar principes voor het project aangegeven

In deze paragraaf zijn de globale gegevensmodel van het Landelijke Register behandeld, de objectdefinities en de wijze waarop omgegaan moet worden met historische gegevens. Bij het opstellen van het model zijn wetsteksten als uitgangspunt gebruikt.

In onderstaand overzicht zijn alle relevante ontwerpbeslissingen die betrekking hebben op het gegevensmodel vastgelegd.

Ontwerpbeslissingen die betrekking hebben op de individuele objecten in het model, zijn bij de objectbeschrijvingen opgenomen.

Het logisch gegevensmodel is opgesteld in UML notatie. UML is een industrie standaard en is zeer geschikt voor de software ontwikkeling. In Bijlage C is een toelichting gegeven op gebruik van UML.

Aantal objecten in het model zijn abstracties die zorgen voor de semantische consistentie van het model en aansluiting op de Semantische kern van het Stelsel van Basisregistraties. Ze kunnen ook worden gedefinieerd zijn verzamelbegrippen die gebruikt worden om gemeenschappelijke kenmerken en gedrag van concrete objecten uit de werkelijkheid aan te duiden.

Dit zijn objecten wiens vastlegging in het Register noodzakelijk is voor de uitvoering van de Wet.

Het zijn de objecten wiens opname in het Register niet noodzakelijk is voor de uitvoering van de Wet, maar wel wenselijk is uit de oogpunt van dienstverlening naar de Burger.

Het aspect historie speelt nadrukkelijke rol in de levenscyclus van de gegevens in het LR. In de AMvB is expliciet vastgelegd dat de datum waarop wijziging van gegevens plaats vindt vermeld dient ter worden. Nota van toelichting voegt daarbij dat actuele gegevens in te zien zijn in het register en dat ’oude’ gegevens gedurende periode van 7 jaar worden bewaard (paragraaf 4.2.Inrichting van het register kinderopvang).

Belastingdienst stelt nog bredere pakken aan eisen m.b.t.’tijdreizen’ en bewaren van oorspronkelijke waarden van gegevens bij de mutaties, te weten:

1. •

   Het moet mogelijk zijn om op ieder moment de historische, actuele of toekomstige situatie van een opvanginstelling of gastouderbureau in het centrale register in te zien, het zogenaamde tijdreizen. Ook het verloop bij fusies of splitsingen moet getraceerd kunnen worden, i.c. de situatie van voor en na de fusie of splitsing.

2. •

   Mutaties in de gegevens (...) dienen op datum bewaard te blijven, zodat achteraf altijd de actuele waarde van deze gegevens op een bepaald moment terug in de tijd inzichtelijk is. Het is wenselijk om eveneens te kunnen beschikken over de ontvangst- en verwerkingsdatum van mutaties in geval van mogelijke conflicten.

3. •

   Mutaties moeten zowel met terugwerkende kracht als met een datum in de toekomst ingevoerd kunnen worden

Aangezien het Register de primaire bron van de gegevens m.b.t. gecertificeerde kinderopvang instellingen is voor meerdere overheidsinstellingen en dat ze deze gegevens nodig hebben voor de uitvoering van hun wettelijke taken, moet de inhoud van het register voldoen aan de vraag.

Als basis voor de invulling van project-specifieke principes voor zijn principes uit de raportage 'Architectuur van het Stelsel, november 2006' gebruikt.

Rapportage spreekt van de volgende twee tijdslijnen m.b.t. attribuutwaarden van objecten in registraties:

1. •

   Wanneer is iets gebeurd, in de werkelijkheid of volgens opgave (wanneer zijn de opgenomen gegevens geldig). Dit valt binnen de tijdlijn van de aangehouden werkelijkheid.

2. •

   Wanneer wist de overheid (als collectief van organisaties) dat, d.w.z. wanneer zijn de gegevens bekend. Dit valt binnen de tijdlijn van het administratieproces.

Inrichting van het register:

In het LR worden allerlei gegevens vastgelegd die betrekking hebben op organisaties voor kinderopvang en hun houders. Deze gegevens kunnen wijzigen gedurende de levenscyclus van individuele objecten in het LR. Voor alle de partijen die gebruik maken van gegevens uit het LR is het van belang om te weten wat en wanneer gewijzigd is in het Register. Voor de partijen die gegevens uit het LR gebruiken als grondslag voor de besluiten of handelingen (wel of niet toekennen van toeslagen, maar mogelijk ook andere handelingen), is het bovendien van belang om te weten in weke periode de gegevens waarop ze besluiten baseren, geldig waren.

Datums van mutaties van gegevens in het LR hebben betrekking op de administratieproces. Moment van opname of wijziging van gegevens in het LR kan van belang zijn voor het bepalen van rechtsgeldigheid van besluiten die op basis van gegeven in het LR zijn genomen.

Datums van geldigheid van gegevens hebben betrekking op de aangehouden werkelijkheid. Het LR is immers de rechtsgeldige bron van gegevens voor het bepalen van recht op toeslag. Geldigheid van bepaalde gegevens kan van invloed zijn op recht op toeslag. Dit is niet hetzelfde als geldigheid van besluit over toekennen van toeslag. Een dergelijk besluit kan genomen zijn op basis van gegevens die op het moment van het nemen van het besluit geldig waren. Zo'n besluit is dus rechtsgeldig tot stand gekomen. Als gegevens op een latere tijdstip niet meer geldig blijken zijn, moet zo'n besluit mogelijk herzien worden op basis van de nieuwe gegevens die op een latere tijdstip bekend zijn geworden. Het oude besluit is niet meer geldig en er komt een nieuw besluit dat betrekking heeft op een periode in het verleden.

Op basis van deze beschouwing kan de vastgesteld worden over de inrichting van het LR:

1. •

   Het LR moet zo zijn ingericht dat de tijdslijn van de aangehouden werkelijkheid met betrekking tot gegevens die van invloed zijn op recht op toeslag en de administratieve tijdslijn over mutaties van gegevens in het Register te reconstrueren zijn.

Richtlijnen voor de aangehouden werkelijkheid:

1. •

   Gegevens over de momenten in de levenscyclus van organisaties voor kinderopvang, zoals inschrijving en uitschrijving zijn primaire gegevens. Momenten in de levenscyclus worden aangeduid door STATUS van organisatie voor kinderopvang.

2. •

   De registratiehouder (gemeente) bepaalt de datum ingang en einde geldigheid van de Status, op basis van de aan de registratiehouder (gemeente) verstrekte officiële stukken en documenten of eigen waarnemingen.

3. •

   LR bewaart de historie over de volgende soorten gegevens m.b.t. aangehouden werkelijkheid:

   1. −

      alle primaire kenmerken van de organisaties van kinderopvang (OKO)

   2. −

      Inhoud en kenmerken van de gerelateerde inspectierapporten;

   3. −

      BSN/Sofi of KvK/Vestigingsnummer van de houders in het geval dat OKO een vestiging was van een onderneming. Bij het ontbreken daarvan, NAW gegevens van de houders;

   4. −

      bemiddelingsrelaties tussen voorzieningen voor gastouderopvang en gastouderbureaus;

   5. −

      Opvangadressen van de OKO’s;

Richtlijnen voor de adminstratieproces:

1. •

   Van alle gegevens in het Register wordt de mutatiedatum bijgehouden.

In de eerste release van het LR is er uitsluitend sprake van de interne communicatie tussen de specifieke modules, te weten: LR, Overheidsportaal en Publieksportaal. Omdat er (nog) geen sprake is van de berichtenuitwisseling met externe systemen, is invulling van dit hoofdstuk niet relevant

Dit hoofdstuk beschrijft de eisen en kaders die gebruikt worden bij de ontwikkeling van het systeemcomplex Landelijk Register Kinderopvang.

Het beschrijft daarnaast onderbouwd de keuzes die op basis van deze kaders gemaakt zijn en de eventuele aanvullende aannames die nodig waren.

Bij het schrijven van dit hoofdstuk is rekening gehouden met alle voorradige informatie, de fasering die in de vorige hoofdstukken is gehanteerd is hier losgelaten om een zo compleet mogelijk beeld te schetsen.

Helaas is het beeld nog niet volledig, dus in een volgende fase kan dit hoofdstuk eventueel nog aangepast worden. Ook uit de nog uit te voeren risicoanalyse kunnen nog nieuwe eisen komen die verwerkt moeten worden.

De eisen waarop de keuze voor onderliggende techniek gebaseerd zijn komen uit een aantal aandachtsgebieden, namelijk overheidsbeleid (zowel centraal als OCW-specifiek), non-functional requirements, beveiligingsbeleid en beheer.

De eisen vanuit beheer en beveiligingsbeleid zijn te vinden in respectievelijk hoofdstuk 7 en 8, de impact ervan op techniek en infrastructuur is wel meegenomen.

Overheidsbeleid:

1. 1

   Gebruik open standaarden waar mogelijk.

2. 2

   Gebruik de volgende documentformaten:

   1. 2.1

      Reviseerbare tekstdocumenten in odt-formaat. Vanuit praktisch oogpunt moet ook Word ondersteund worden, de meeste ketenpartners beschikken niet over software waamee odt-bestanden gelezen kunnen worden.

   2. 2.2

      Niet-reviseerbare documenten in pdf-formaat.

3. 3

   Kies voor open source bij gelijke geschiktheid.

4. 4

   Sluit aan op overheidsstandaarden als de Referentiearchitectuur Onderwijs, NORA, PKIOverheid en OSB.

5. 5

   Voor communicatie met gemeenten wordt rekening gehouden met de standaarden uit GEMMA en daarmee met StUF.

6. 6

   Sluit aan op de standaardoplossingen binnen de overheid: de basisregistraties en de andere e-Overheidsbouwstenen.

7. 7

   Uitsluiting: voorlopig wordt geen rekening gehouden met een koppeling met het RINIS-server of de RINIS-standaarden.

Non-functional requirements:

Deze zijn voor het systeem-complex nog niet in detail bekend, voor zover bekend zullen deze hier benoemd worden, daarnaast zijn een aantal aannames gedaan om te komen tot de voorstelde oplossingen.

Voor de huidige GIR-KO geldt de volgende non-functional requirements, uit eisen-documenten en de bestaande SNO:

1. 1

   Bij 100 gelijktijdige gebruikers is de responsetijd 2 tot 3 seconden.

2. 2

   GIR-KO is 7*24 uur beschikbaar met uitzondering van de afgesproken onderhouds-windows (één keer per twee weken van donderdag 18:00 tot maximaal vrijdag 9:00).

3. 3

   De GIR-KO is in staat om 100 concurrent users te ondersteunen. De performance van de GIR Kinderopvang is maximaal 3 tot 4 seconden bij een goed werkende internetverbinding. Deze eis uit de SNO is anders dan de bovenstaande eis uit het eisen-document van de GGD.

4. 4

   Authenticatie op GIR-KO vindt plaats met behulp van gebruikersnaam en wachtwoord.

Deze eisen zijn in de uitgangsdocumentatie van het Publieksportaal [6] bijna één-op-één overgenomen, hoewel dit qua aantallen concurrent gebruikers een lage schatting lijkt. In plaats daarvan worden de volgende aannames betreffende non-functional gedaan:

1. 1

   Responsetijd maximaal 4 seconden bij 5000 gelijktijdige gebruikers. Deze schatting is gebaseerd op gelijktijdig gebruik door 1 promille van de gebruikerspopulatie.

2. 2

   Beschikbaarheid is 99% op basis van 7*24 uur. Het verschil met GIR KO is het ontbreken van een onderhoudswindow.

Er zijn geen eisen bekend over het Overheidsportaal, als eerste aanname zijn de eisen die aan GIR-KO gesteld zijn overgenomen met een kleine verduidelijking betreffende het beschikbaarheidspercentage:

1. 1

   Bij 100 gelijktijdige gebruikers is de responsetijd 2 tot 3 seconden.

2. 2

   Het Overheidsportaal is 97% beschikbaar op basis van 7*24 uur met uitzondering van de afgesproken onderhouds-windows (één keer per twee weken van donderdag 18:00 tot maximaal vrijdag 9:00).

3. 3

   Voorlopige aanname is dat authenticatie op het Overheidsportaal plaats vindt met behulp van gebruikersnaam en wachtwoord. Dit moet nog worden geverifieerd door middel van de nog uit te voeren risicoanalyse en het nog op te stellen beveiligingsplan. Mogelijk kan gebruik gemaakt worden van initiatieven als OEP

Aannames over gebruikersaantallen en gegevensomvang:

1. 1

   De betrokken organisaties leveren de volgende aantallen gebruikers [bron is de PID]:

   1. 1.1

      Gemeentes 500–1500.

   2. 1.2

      GGD'en 250–350.

   3. 1.3

      Inspectie van het Onderwijs 10–20.

   4. 1.4

      Belastingdienst 50–100.

   5. 1.5

      Ouders met kinderen van 0 tot 12 jaar 5.000.000. Deze zullen niet allemaal gebruik maken van het Landelijk Register. De schatting is dat ongeveer 1.000.000 ouders per jaar één of meerdere raadplegingen op het Landelijk Register zal doen.

2. 2

   Geschat aantal objecten van toezicht 100.000. Deze schatting is gebaseerd op de aanwezigheid van 1200 objecten in de huidige GIR voor één GGD-regio. Aangezien er landelijk 25 zijn levert dit ongeveer 30.000 objecten op. Aangezien de gastouders hier nog niet in opgenomen zijn is aanname gedaan dat op 70.000 objecten voor gastouders extra gerekend moet worden. Dit komt uit op 100.000 objecten in totaal.

3. 3

   Het aantal objecten van toezicht groeit 20% per jaar. Deze schatting is vrij hoog maar er is nog geen input voor schattingen betreffende gastouders. Bij dit percentage is geen rekening gehouden met de opname van nieuwe objecten van toezicht in het LR zoals peuterspeelzalen.

4. 4

   Geschat aantal mutaties op het Landelijk Register voor het eerste jaar (via schermen en via services): 1.000.000. De stijging zal naar verwachting evenredig zijn met het aantal objecten van toezicht. Op basis van 100.000 objecten van toezicht is de aanname gedaan dat hier 50.000 houders bij horen. Dit betekent 150.000 objecten waartussen relaties kunnen bestaan en die gewijzigd kunnen worden. Op basis van geschat 1 wijziging per twee maanden (toevoegen rapport, adreswijziging, wijziging van contactpersoon etc.) rolt, met een kleine afronding naar boven, het getal 1.000.000 eruit.

5. 5

   Geschat aantal raadplegingen op het Landelijk Register per jaar (via schermen en via services): 10.000.000. De stijging zal naar verwachting evenredig zijn met het aantal objecten van toezicht.

   1. 5.1

      Geschat aantal bevragingen vanuit de overheid: 2.500.000. Deze bevragingen lopen voor het overgrote deel over het Overheidsportaal. Anders dan de initiële piek bij het vullen van het Register worden hier geen pieken verwacht. Dit getal is opgebouwd uit een tweetal raadplegingen per mutatie (2 * 1.000.000 = 2.000.000), een aantal losse raadplegingen vanuit onder andere GGD' en en Belastingdienst en het raadplegen van overzichten.

   2. 5.2

      Geschat aantal bevragingen vanuit burgers en bedrijven: 7.500.000. Deze bevragingen lopen over het Publieksportaal. Het getal van 7.500.000 is opgebouwd uit gemiddeld 7,5 raadpleging per ouder per jaar, bijvoorbeeld voor controle bij Belastingaangifte of bij uitzoeken van een Kindercentrum. De verwachting is dat er meer gebruik is voor het schooljaar begint, specifiek voor Buitenschoolse opvang. Er wordt geen piek ingecalculeerd naar aanleiding van de verdeling van geboortes over het jaar. Over verdeling over de uren heen valt nog niets te zeggen.

6. 6

   Geen significante groei in het aantal gebruikers in de afzienbare toekomst. Als blijkt dat door het sterk gestegen aantal inspecties, er worden immers nu geen gastouders geïnspecteerd, meer gebruikers nodig zijn moet dit document aangepast worden.

7. 7

   Conform wet worden gegevens 7 jaar bewaard vanaf moment van ontstaan van de gegevens in het register, de laatste 3 jaar is inzichtelijk via systeem. Voor caching, logging en auditing geldt dat gegevens niet langer dan wettelijk toegestaan bewaard worden.

Resultante eisen op basis van deze aannames:

1. 1

   Het LR moet, gegeven de centrale plek in de keten en de eisen op de gekoppelde systemen, 99,9% beschikbaar zijn met uitzondering van calamiteiten. Hiervoor moeten ook infrastructurele en applicatieve eisen gesteld worden. Eén van de manieren om aan deze eisen te kunnen voldoen is om te gaan clusteren, zowel op applicatief als op database-niveau, en de ondersteuning voor fail-over. De inrichting van de OTA-omgeving moet het aantonen van voldoen aan deze eisen ondersteunen.

2. 2

   Het aantal bevragingen op het LR is dermate groot dat de aanwezigheid van load-balancing noodzakelijk is.

De belangrijkste keuze is het gebruik van JEE 1.5 [Java Enterprise Edition] als platform voor het ontwikkelen van de componenten waar het systeemcomplex uit is opgebouwd.

Deze keuze betekent dat hardware en besturingssysteem 'vrij' zijn, JEE wordt op alle normale hardware en besturingssysteem ondersteund en is voor bedrijfskritische web-applicaties de open source marktstandaard.

Het gebruik van de bovengenoemde marktstandaarden garandeert welhaast de beschikbaarheid van kwalitatief hoogwaardige ontwikkelaars en bekendheid bij mogelijk ontvangende beheerpartijen.

Voor beide onderkende portalen, zowel het Overheids- als het Publieksportaal wordt gebruik gemaakt van het JSF2-framework. Dit framework is volledig webrichtlijnen-compliant.

Voor de opslag van gegevens die binnen het systeemcomplex zelf wordt gebruik gemaakt van een relationele database.

Voor het Landelijk Register zelf geldt dat gegeven

1. •

   de grote aantallen transacties,

2. •

   de grote hoeveelheid data die moet worden opgeslagen binnen de component ,

3. •

   de wettelijke bewaartermijn van 7 jaar waarvan 3 jaar online beschikbaar

4. •

   het complexe autorisatie-mechanisme dat ondersteund moet worden

5. •

   de zware eisen die aan historische gegevens gesteld worden

6. •

   het programma voorstelt om af te wijken van de standaard open source keuze MySql en in dit geval Oracle 11g te gaan gebruiken.

Dit omdat Oracle een bewezen en marktconforme oplossing is, ook voor deze volumes, grootte en complexiteit, waarvoor in ruime mate kennis in de markt aanwezig is. Ook kan

Voor de andere onderkende en nog te onderkennen componenten worden geen afwijkingen van open source marktstandaarden voorzien.

De niet-bulk communicatie met externe systemen verloopt via webservices conform NORA.

De interne communicatie tussen de verschillende componenten loopt via services. Voor de in deze eerste fase op te leveren interne services is nog geen noodzaak om deze als webservice extern te ontsluiten.

Over bulk-communicatie met de Belastingdienst moet nog bepaald worden hoe dit gebeurt, via FTP, fysiek medium of via webservices met attachments.

Voor de mogelijk op te leveren directe koppelingen naar gemeente-systemen of aansluiting op GBA wordt zo mogelijk gebruik gemaakt van de GEMMA-infrastructuur, GEMNET.

Servicebus

Gegeven het feit dat alle communicatie tussen de externe systemen en de componenten via webservices loopt is gebruik van een servicebus een vereiste. Vanuit eenvoud is het handig om gebruik te maken van binnen ICTU bekende technologie.

Om een juiste werking van het systeemcomplex te kunnen garanderen, moet de servicebus zijn verantwoordelijkheden kunnen invullen. Hiervoor moet de servicebus voldoen aan de volgende kwaliteitseisen:

1. •

   Ondersteuning van foutafhandeling ten behoeve van beheer.

2. •

   Ondersteuning van logging ten behoeve van beheer.

3. •

   Ondersteuning van alle standaard messaging patronen: fire&forget, request-reply and publish&subscribe ten behoeve van de huidige werking en mogelijke toekomstige uitbreidingen.

Berichtenstandaarden bij gebruik van de webservices

De OSB 2.0-standaarden moeten gebruikt worden, voor de koppelvlakken met de gemeente wordt rekening gehouden met de StUF-standaarden.

Deze paragraaf beschrijft de uitgangspunten betreffende platformen.

Let op, er wordt niet de volledige inrichtingsplaat beschreven, slechts de kaders worden benoemd. De daadwerkelijke inrichting hoort thuis in het Deployment Document horende bij de verschillende implementaties.

De eisen zullen beschreven worden onderverdeeld in de volgende categorieën:

Hardware en Operating Systeem:

Transparant vanwege het gebruik van Java.

Standaard wordt gebruik gemaakt van Linux, tenzij de software de op deze hardware moet gaan draaien een ander operating systeem vereist. Op basis van de niet-functionele eisen op het gebied van prestaties en performance wordt de sizing van de hardware uitgevoerd. Virtualisatie moet ondersteund worden.

Infrastructurele software

De eisen die gesteld moeten worden betreffende infrastructurele software zijn:

1. 1

   Uniformiteit van gebruik van infrastructurele software over de verschillende componenten heen voor zover mogelijk.

2. 2

   In het verlengde daarvan: verplicht gebruik van bouwstenen voor authenticatie en rapportage

Nadere detaillering vindt plaats in de nog op te leveren documenten Systeem Architectuur Definitie [5] en/of het Deployment Document [16].

Voor de netwerkarchitectuur en de verantwoordelijkheid voor delen van het netwerk zijn de volgende eisen te benoemen:

1. 1

   Partijen die gebruik maken van de door de het LR geboden webservices zijn zelf verantwoordelijk voor afspraken met de leverancier van het netwerk tussen hun applicatie en de .

2. 2

   Alle netwerkverkeer is gebaseerd zijn op het TCP/IP-protocol.

3. 3

   Gebruikers kunnen de presentatielaag benaderen via het HTTP-protocol maar wel over SSL/TLS (HTTPS dus).

4. 4

   Systeem-authenticatie vindt plaats op basis van PKIOverheidscertificaten.

5. 5

   Webservices zijn OSB-WUS (raadplegingen) of OSB-ebMS(transacties) compliant.

6. 6

   Bovenop de gebruikte HTTP-protocollen vindt versleuteling van de gegevens plaatsvinden via TLS (Transport Layer Security) en SSL 3.0.

7. 7

   Gebruik van besloten (overheids-)netwerken, zoals Haagse Ring, indien mogelijk. Afwijking behoeft uitleg (comply or explain!).

De onderstaande plaat geeft op hoofdlijnen aan hoe de hardware, de infrastructuur en de software per 1 januari neergezet zal worden in de A-omgeving.

Op basis van de functionele en niet/functionele eisen die aan het Landelijk Register-complex gesteld worden is een eerste set aan eisen ten behoeve van beheer af te leiden.

De inhoud van dit hoofdstuk is gebaseerd op deze set van eisen en is nog niet afgestemd met de (nog niet bekende) toekomstige beheerpartij. In deze paragraaf wordt uitgegaan van één toekomstige beheerpartij.

In dit hoofdstuk zal gebruik gemaakt worden van de volgende aannames:

1. •

   De toekomstige beheerpartij heeft als primaire taak het systeemcomplex (in de brede zin van het woord, dus hardware, infrastructuur en software) operationeel te houden met de gewenste beschikbaarheid en performance. Hiervoor worden vaak de termen correctief en preventief onderhoud gehanteerd.

2. •

   Als secundaire taak wordt het uitvoeren van wijzigingen op het systeemcomplex (inclusief onderliggende infrastructuur natuurlijk) verondersteld.

3. •

   Het beheren van de voor een correcte werking van het systeemcomplex benodigde configuratie en gegevens moet ondersteund worden. Denk hierbij onder andere aan gebruikersbeheer en onderhoud van software-instelling.

4. •

   Beheer van autorisatie wordt ondersteund door het systeemcomplex, mogelijk per te onderkennen component.

5. •

   Uitsluiting: Beheerprocessen op strategisch en tactisch niveau zijn buiten scope voor deze paragraaf (want taak en verantwoordelijkheid van de ontvangende beheerpartij), de focus is gericht op de eisen aan het op te leveren systeemcomplex.

Ten behoeve van de uitvoering van de taken zoals hierboven verondersteld worden de volgende eisen aan het op te leveren systeemcomplex gesteld:

1. 1

   Het systeemcomplex moet de relevante monitoring-informatie leveren, minstens:

   1. 1.1

      Geheugengebruik, CPU-gebruik, disk gebruik, inclusief waarschuwing bij benaderen van ingestelde grenzen.

   2. 1.2

      Benaderbaarheid van hardware en services.

   3. 1.3

      Aantal gebruikers op een willekeurig moment.

   4. 1.4

      Monitoring van response-tijden.

   5. 1.5

      Monitoring van beschikbaarheid van koppelvlakken.

2. 2

   Het systeemcomplex moet voldoende logging-informatie geven:

   1. 2.1

      Alle fouten moeten gelogd worden.

   2. 2.2

      De relevante acties worden gelogd in een audit-log, inclusief de uitvoerder.

3. 3

   Het systeemcomplex moet wijzigbaar zijn:

   1. 3.1

      Hardware moet bij te plaatsen zijn in de serverruimte.

   2. 3.2

      Het systeem moet horizontaal en verticaal schaalbaar zijn.

   3. 3.3

      De systeemcomponenten waaruit het systeemcomplex opgebouwd is moeten afzonderlijk wijzigbaar zijn.

4. 4

   Het systeemcomplex moet een beheerinterface bieden waarmee de benodigde gegevens beheerd kunnen worden

   1. 4.1

      Een gebruikersbeheer-interface ten behoeve van authenticatie.

   2. 4.2

      Een gebruikersbeheer-interface ten behoeve van autorisatie.

   3. 4.3

      Een configuratie-interface.

5. 5

   Geautomatiseerde backup&restore procedures voor de database.

Dit hoofdstuk wordt voorlopig ingevuld op basis van de scope per 1-1-2010. Dit betekent dat deze invulling van dit hoofdstuk zich beperkt tot de componenten Landelijk Register zelf, het Publieksportaal en het Overheidsportaal.

De volgende beveiligingsspecifieke kaders en standaarden zijn gebruikt bij het opstellen van dit hoofdstuk in de PSA. De standaard-architectuurkaders als NORA zijn natuurlijk ook meegenomen.

Rijksvoorschrift voor informatiebeveiliging (VIR) [9]

Voor de rijksoverheid is het Voorschrift Informatiebeveiliging Rijksdienst 2007 (VIR 2007) leidend. Hierin wordt aangegeven (artikel 4) dat ‘het lijnmanagement is verantwoordelijk voor de beveiliging van zijn informatiesystemen’.

Met betrekking tot informatiebeveiliging ‘Stelt [het lijnmanagement] op basis van een expliciete risico afweging de betrouwbaarheidseisen voor zijn informatiesystemen vast’.

Voorschrift informatiebeveiliging rijksdienst – bijzondere informatie (Vir-bi) [10]

Het Vir-bi is bedoeld als extra aanvulling op het VIR ten behoeve van interdepartementale uitwisseling van kwetsbare informatie.

Wet Bescherming Persoonsgegevens (WBP) [11]

Elektronische dienstverlening moet de vertrouwelijkheid van persoonlijke data garanderen, inclusief maatregelen die het mogelijk maken om aan te geven of data voor andere doeleinden mogen worden gebruikt dan waarvoor zij zijn verstrekt. Er moet worden vastgesteld welk type persoonlijke gegevens (volgens WBP) in de generieke voorziening worden verwerkt en vastgelegd.

De typering van de persoonsgegevens bepaalt met name welke beveiligingsmechanismen van toepassing zijn voor verwerking door de Landelijk Register Kinderopvang. Elke daar aan verbonden risicoklasse stelt zijn eigen voorwaarden aan de te overwegen beveiligingsmaatregelen.

Voor het Landelijk Register Kinderopvang en het Overheidsportaal wordt WBP Risicoklasse II ondersteund. Voor de andere onderdelen van het systeemcomplex moet op basis van de eigen gegevens van die onderdelen een nadere inschatting gemaakt worden, rekening houdende met de koppelvlakken tussen die onderdelen en het Landelijk Register.

Wensen en eisen met betrekking tot informatiebeveiliging zijn in te delen in functies van informatiebeveiliging: de voor de gebruiker meest bekende zijn beschikbaarheid, identificatie en authenticatie, autorisatie, exclusiviteit en integriteit. Andere functies waarop eisen te verwachten zijn, zijn controleerbaarheid en onweerlegbaarheid.

De informatiebeveiligingsfuncties kunnen worden ingevuld door één of een combinatie van beveiligingsmechanismen. Beveiligingsmechanismen zijn bijvoorbeeld cryptografie, rollen en toegangsrechten, authenticatie van gebruiker, invoervalidatie, foutafhandeling, machine of proces, regels en richtlijnen, procedure, back-up en restore. Elk mechanisme wordt ingevuld met een combinatie van fysiek, organisatie, procedure, functie en techniek.

De mechanismen vormen een balans tussen maatregelen die preventief, detectief en correctief van aard zijn.

In dit hoofdstuk worden per onderkende component de belangrijkste aspecten op het gebied van beveiliging in kaart gebracht. Hierbij is gebruik gemaakt van zowel de standaard ISO-9126-kwaliteitsattributen als van een aantal meer beveiligings-specifieke attributen.

Voor het Landelijk Register geldt dat het doel van register is om kwalitatief hoogwaardige gegevens te bevatten. Dit betekent dat de primaire focus ligt op de volgende aspecten van beveiliging:

1. 1

   Integriteit van de gegevens;

2. 2

   Traceerbaarheid: audit-trail van alle uitgevoerde wijzigingen;

3. 3

   Beschikbaarheid. Het Register moet altijd beschikbaar zijn;

4. 4

   Backup & Restore-processen. Er mag geen dataverlies optreden bij een systeemstoring;

5. 5

   Exclusiviteit, correctheid van ontsluiting van gegevens;

De belangrijkste taak van het Overheidsportaal is fungeren als beheer-interface op de gegevens in het Register. Daarnaast wordt het ook gebruikt om overheidsmedewerkers inzicht te geven in de inhoud van het register. Op basis hiervan ontstaat de volgende focus op aspecten:

1. 1

   Beveiligbaarheid: autorisatie-model (opzet en implementatie);

2. 2

   Exclusiviteit: correcte ontsluiting van gegevens;

3. 3

   Traceerbaarheid: volledig audit-trail van alle uitgevoerde wijzigingen;

4. 4

   Veilige uitwisseling van gegevens met de gebruiker;

5. 5

   Traceerbaarheid: logging van alle uitgevoerde zoekopdrachten, inzicht in welke gebruiker of systeem welke informatie ingezien heeft;

De belangrijkste taak van het Publiekssportaal is het geven van inzicht in de inhoud van het register aan burgers, meer in het bijzonder ouders. Op basis hiervan ontstaat de volgende focus op aspecten:

1. 1

   Exclusiviteit: correcte ontsluiting van gegevens. Er mogen geen onjuiste of onvolledige gegevens ontsloten worden, en alleen definitieve inspectierapporten mogen getoond worden.;

2. 2

   Beschikbaarheid. Het Publieksportaal moet altijd te benaderen zijn;

De beveiligingseisen zijn uit te werken in het nog te schrijven beveiligingsplan, dat geschreven wordt op basis van de daarvoor uit te voeren risicoanalyse.

Vooruitlopend op deze uitwerking zijn de volgende eisen te hanteren:

1. 1

   De code voor informatiebeveiliging wordt gebruikt als overkoepelende leidraad voor beveiliging.

2. 2

   Het op te leveren systeemcomplex voldoet minimaal aan de eisen zoals gesteld voor WBP classificatie 2.

3. 3

   Het ICT-project hanteert de OWASP richtlijn voor veilige systeemontwikkeling (www.owasp.org).

4. 4

   Het op te leveren systeemcomplex past binnen het normenkader van de NORA voor beveiliging.

Deze eisen moeten in het beveiligingsplan nader uitgewerkt worden.

Wanneer de eisen aan het systeem zodanig zijn dat de risicoanalyse uitwijst dat er sprake is van gegevensverwerking volgens WBP classificatie 3 dan heeft dit een groot aantal extra maatregelen tot gevolg. Een dergelijke opschaling van de classificatie is zeer ingrijpend voor de architectuur.

De opvolgende stappen moeten in kader van het ICT-project en de projecten Implementatie of Beheer genomen worden om het hele scala van beveiliging af te dekken:

1. •

   Risicoanalyse;

2. •

   Informatiebeveiligingsplan;

3. •

   Verantwoordelijke beveiligingsfunctionaris(sen) benoemd;

4. •

   Gebruiksvoorwaarden opstellen;

5. •

   Beheerprocedures en operationele beveiliging (monitoring) inregelen;

6. •

   Audits laten uitvoeren;

7. •

   Tijdens ontwikkeling: code-scanning en pen-test;

1. [1]

   Project Initiatie Document v1.1 d.d. 21 sept 2009

2. [2]

   Wet Kinderopvang

3. [3]

   AMvB B2681 K- versie 10 augustus 2009

4. [4]

   MARTHE, Model Architectuur voor Rijkstoezichts- en Handhavingseenheden, <nog te maken>, Inspectieraad

5. [5]

   Software Architectuur Document Landelijk Register Kinderopvang complex, <nog te maken>, Programma LR-GIR KO

6. [6]

   Uitgangsdocumentatie IvhO betreffende Publieksportaal, meerdere documenten van de hand van Ronald Jobse.

7. [7]

   NORA-website, zie http://www.e-overheid.nl/atlas/referentiearchitectuur/nora/nora.html of Nederlandse Overheid Referentie Architectuur. V2.0 d.d. 25 april 2007

8. [8]

   Code voor Informatiebeveiliging (NEN-ISO-IEC 27001:2005 (nl))

9. [9]

   Voorschrift Informatiebeveiliging Rijksdienst 2007 (VIR 2007)

10. [10]

    Voorschrift informatiebeveiliging rijksdienst – bijzondere informatie (Vir-bi)

11. [11]

    AV23 Beveiliging van persoonsgegevens, Registratiekamer, Den Haag, april 2001

12. [12]

    Overheidsservicebus website, http://www.overheidsservicebus.nl/

13. [13]

    Kaderstellende Visie op Toezicht 2001, TK 2000–2001, 27831, nr. 1

14. [14]

    Kaderstellende Visie op Toezicht 2005, Kamerstuk 27 831, nr. 14

15. [15]

    Referentiearchitectuur Onderwijs, 29 september 2008, B. Gaakeer

16. [16]

    Deployment Document Landelijk Register Complex, fase 1, <nog te maken>, Programma LR-GIR KO

In deze bijlage staan de relevante definities uit NORA opgenomen, zodat er bij lezing van de PSA naar gerefereerd kan worden.

1. Definitie Dienst: het resultaat of effect van een afgeronde inspanning die de overheid op basis van wettelijke taken levert en waarmee in de behoefte van een burger of bedrijf wordt voorzien. (Bron: NORA 5.2.1). Een dienst levert dus een eindresultaat aan een burger of bedrijf.

2. Definitie Service: het resultaat of effect van een afgeronde inspanning die een ambtenaar of applicatie op basis van wettelijke taken levert en waarmee in de behoefte van één of meer andere ambtenaren of applicaties wordt voorzien. (Bron: NORA 5.2.2). Een service levert een (tussen) resultaat aan een andere overheidsorganisatie, ambtenaar of applicatie.

3. Definite Proces: Een proces is een geordende reeks van (in-)direct waarde toevoegende handelingen en oordelen door ‘n mens of machine gericht op een bekend resultaat.

1. ‘Ketenproces’of interactieperspectief: Een ‘ketenproces’ is een geordende reeks services die door verschillende organisaties aan elkaar worden geleverd met als doel om via één organisatie een (combinatie van) dienst(en) te leveren aan een burger of een bedrijf. We spreken hier bij voorkeur over het ‘interactieperspectief’ (zie paragraaf 5.2).

2. Bedrijfsproces: Een bedrijfsproces is een geordende reeks werkprocessen die binnen één organisatie wordt uitgevoerd met als doel om een (combinatie van) dienst(en) te leveren aan een burger, bedrijf of andere organisatie.

3. Werkproces: Een geordende reeks van processtappen die binnen één organisatorische eenheid binnen een organisatie wordt uitgevoerd met als doel een specifieke bijdrage (prestatie) te leveren aan een dienst die uiteindelijke zal worden geleverd aan een burger, een bedrijf of een andere organisatie.

4. Processtap: Een geordende reeks handelingen die ononderbroken wordt uitgevoerd door één mens of machine binnen één bedrijfsfunctie.

5. Handeling: Kleinst mogelijke eenheid van werk, uitgevoerd door één persoon of machine op één plek op één moment (eenheid van tijd, plaats en handeling.

UML is een grafische modelleertaal die zijn oorsprong vindt in de objectoriëntatie. Belangrijke begrippen uit de objectoriëntatie, zoals klasse en overerving, worden in UML aanschouwelijk gemaakt in het klassediagram.

Hieronder een beknopte samenvatting van de belangrijkste begrippen uit de objectoriëntatie met de bijbehorende UML-notatie. Voor een uitvoerige beschrijving van notatie en betekenis wordt verwezen naar de UML Notification Guide.

Dit document beschrijft het globaal functioneel procesmodel. Het is onderdeel van het globaal functioneel ontwerp (GFO) van het Landelijk Register Kinderopvang.

Het globaal functioneel procesmodel beschrijft de relatie tussen use-cases en modules die nodig worden geacht voor ondersteuning van de gewenste functionaliteit.

1. •

   Het is een middel om te toetsen of wordt voldaan aan de gewenste architectuur en aan de (wettelijke) eisen;

2. •

   Het vormt mede basis voor het Detail Functioneel Ontwerp (DFO), het Software Architectuur Document (SAD) en het testplan.

Het globaal functioneel procesmodel bevat niet een volledige en gedetailleerde beschrijving, maar beschrijft slechts op hoofdlijnen de inhoud van de modules. In het globaal functioneel datamodel is aangegeven welke gegevens per module gebruikt en bewerkt worden.

Dit document is bedoeld voor:

1. •

   Software Architecten, om te toetsen of wordt voldaan aan de gewenste architectuur.

2. •

   Functionele Ontwerpers, als basis voor een verdere uitwerking van de hier beschreven modules in een detail functioneel ontwerp.

Dit document beperkt zich tot het procesmodel ter ondersteuning van functionaliteit die per 01/01/2010 gerealiseerd moet zijn.

Het volledige functioneel ontwerp wordt opgebouwd in twee stappen. Eerst wordt het Globaal functioneel ontwerp (GFO) opgesteld. Dit bestaat uit een procesmodel (dit document), een datamodel en het interactie-ontwerp, evenals een prototype. Het Detail functioneel ontwerp (DFO) bevat de uitwerking van hetgeen in het GFO op hoofdlijnen is vastgesteld.

Het functioneel ontwerp baseert zich primair op de project start architectuur (PSA), en op de functionele requirements, beschreven in de geprioriteerde requirements list (PRL). Het functioneel ontwerp vormt samen met prototype en technisch ontwerp (SAD) de basis voor realisatie.

Hoofdstuk 2 beschrijft procesondersteuning door de LRK-applicatie. Hoofdstuk 3 geeft een toelichting op de use cases per module. De modules worden nader toegelicht in hoofdstuk 4. Hoofdstuk 5 bevat een high level collaboration diagram, waarin de samenhang tussen de modules is weergegeven.

De LRK-applicatie ondersteunt de processen van de belanghebbenden die betrokken zijn bij de uitvoering van de Wet Kinderopvang (Wko) en het verstrekken van inkomensafhankelijke toeslagen. De belanghebbenden zijn genoemd in de Project Start Architectuur LRK. De belanghebbenden hebben verschillende behoeften en verantwoordelijkheden. Bij deze verantwoordelijkheden horen autorisaties om handelingen met de LRK-applicatie te mogen doen. De LRK-applicatie is opgedeeld in componenten die zo goed mogelijk worden afgestemd op de doelgroep(en).

In de PSA Landelijk Register Kinderopvang wordt gesproken over LRK-systeemcomplex per 01-01-2010. Het voorliggende document is een nadere concretisering van het LRK-systeemcomplex uit de Informatie-architectuur (hoofdstuk 5).

Hierbij is een drietal systeemcomponenten onderkend:

1. •

   publieksportaal

2. •

   overheidsportaal

3. •

   landelijk register (services)

Daarnaast wordt een systeemcomponent onderkend ten behoeve van het beheer.

In de PSA is een functionele decompositie opgenomen van de processen in het werkveld rondom de Wko. De processen zijn opgedeeld in functies. Een aantal functies wordt ondersteunt door (delen) van het systeemcomplex. Uit die decompositie is af te leiden op welke wijze het Landelijk Register en de verschillende portalen de functies ondersteunen.

De PSA bevat een globale beschrijving van het ketenproces Registreren nieuwe kinderopvang. Een nadere concretisering van het ketenproces is uitgewerkt in dit procesmodel.

Toelichting:

De aanvrager stelt een aanvraag op voor registratie in het Landelijk Register Kinderopvang en dient de aanvraag in bij de gemeente. De gemeente (Gegevensverwerker Gemeente) neemt de aanvraag in behandeling en stelt vast of de aanvraag volledig is. Indien deze niet volledig is, wordt de aanvraag niet in behandeling genomen.

Indien uit de eerste globale analyse blijkt dat de aanvraag volledig genoeg is voor verdere behandeling worden de gegevens van de aanvraag vastgelegd in het LR. Daarbij wordt een kenmerk aangebracht waaruit af te leiden is dat het om een aanvraag gaat en nog geen definitieve inschrijving. Bij de (voorlopige) registratie kunnen zich situaties voordoen, waarbij verwerking in het LR niet mogelijk is. Daarmee wordt het registratieproces beëindigd.

Na een succesvolle, voorlopige registratie wordt de GGD (Medewerker Keten) op de hoogte gebracht van een nieuwe (voorlopige) inschrijving. Binnen 8 weken moet de GGD de inspectie uitvoeren. Na de uitvoering van de inspectie wordt een inspectierapport en advies opgesteld door de GGD en verstrekt aan de aanvrager. Indien deze aanleiding ziet voor verweer, kan de aanvrager een zienswijze opstellen. Indien geen bevinding is aangetroffen, geeft de aanvrager daarmee aan akkoord te gaan met het inspectierapport. De GGD stelt een uiteindelijk inspectierapport op en stuurt het naar de aanvrager en de gemeente waar de OKO gevestigd wordt.

De gemeente legt het inspectierapport vast in het Landelijk Register en bepaald of de OKO definitief mag worden ingeschreven. Als de gemeente besluit niet tot inschrijving over te gaan, wordt in het Landelijk Register bij de voorlopige gegevens van de OKO vastgelegd dat er geen definitieve inschrijving heeft plaatsgevonden. Als de gemeente besluit tot definitieve inschrijving, dan wordt bij de OKO in het Landelijk Register vastgelegd dat per datum X de formele inschrijving heeft plaatsgevonden. Het Landelijk Register genereert dan een definitief inschrijvingsnummer. De gemeente verstrekt dat inschrijvingsnummer aan de aanvrager.

ICT-ondersteuning:

Voor de registratie van de kinderopvang worden de volgende functies nader uitgewerkt:

1. •

   Vastleggen ontvangen aanvraag voor registratiekamer

2. •

   Vastleggen inspectierapport

3. •

   vastleggen definitieve inschrijving OKO in LRK

4. •

   afronden registratie

Het administratieve proces begint met het registreren van de gegevens van een aanvraag in het landelijk register.

Ten behoeve van het registreren dient een gebruiker van het LR te beschikken over voldoende autorisaties om in het systeem te mogen muteren. De Gegevensverwerker Gemeente moet derhalve inloggen in het Overheidsportaal. Na een succesvolle inlogprocedure kan de gebruiker er voor kiezen om een (nieuwe) aanvraag vast te leggen. Daarbij worden eerst de gegevens van de te registreren OKO geregistreerd. Na een succesvolle registratie van de OKO, wordt de houder van de OKO geregistreerd. In die gevallen waarin de houder van de Voorziening voor Gastouderopvang (VGO) een niet-natuurlijk persoon is, worden ook de gegevens van de gastouder apart vastgelegd. Als registratie niet mogelijk blijkt, zal procedureel onderzocht moeten worden wat er mogelijk niet klopt. Op dat moment zal het proces herhaald worden of worden stopgezet.

Als de registratie correct is uitgevoerd wordt de voorlopige registratie van de OKO afgerond.

Ten behoeve van het verkrijgen van toegang tot het overheidsportaal moet de gebruiker geïdentificeerd worden en wordt de juiste autorisatie toegekend door het systeem.

De gebruiker (Gegevensverwerker gemeente) voert inloggegevens in op een scherm van het overheidsportaal. Het ‘systeem’ gaat kijken of de gegevens bekend zijn en of toegang verleend mag worden. Indien dit niet kan, wordt de gebruiker hiervan op de hoogte gebracht. Indien de gegevens bekend zijn, wordt een code gegenereerd en verzonden naar de gebruiker. De gebruiker voert de inlogcode in in het juiste onderdeel van het overheidsportaal. Het ‘systeem’ stelt vast welke autorisaties behoren bij de gebruiker en bevestigd aan de gebruiker dat de inlogprocedure succesvol is afgerond.

Voor de registratie van een nieuwe kinderopvang worden de volgende stappen doorlopen.

De geautoriseerde gebruiker (Gegevensverwerker gemeente) kiest een soort opvang die geregistreerd moet worden. De gegevens uit de aanvraag van de OKO worden ingevoerd in het invoergedeelte van het overheidsportaal. Nadat de gegevens van de OKO ingevoerd zijn, voert het systeem controles uit. Indien verwerking niet mogelijk is, maakt het systeem hier melding van. De bevinding kan bijvoorbeeld zijn het ontbreken van invoer in bepaalde verplichte velden, signalering van reeds bestaand gegevens, het reeds bestaan van een OKO met dezelfde gegevens of afwijkende gegevens. De gebruiker stelt de behandelwijze vast. Hij kan besluiten onderzoek in te stellen en breekt het registratieproces af. De gegevens worden door het systeem vervolgens verwijderd. De gebruiker krijgt een melding dat de gegevens verwijderd worden.

De gebruiker kan besluiten de gegevens te wijzigen die reeds aanwezig zijn, als hij daarvoor geautoriseerd is en zeker is dat de gegevens uit de aanvraag juist zijn. Vervolgens worden de gegevens verwerkt door het systeem. De gebruiker krijgt de mogelijkheid om te bevestigen dat de registratie goed is. Het systeem bevestigd de correcte verwerking. De gebruiker kan de registratie vervolgen.

De gegevens van de OKO zijn ingevoerd. Bij elke OKO moet een een houder worden vastgelegd. Ook de Voorziening van GastouderOpvang (VGO) heeft een houder. Dit zal in de meeste gevallen dezelfde natuurlijke persoon (mens) zijn als de gastouder, maar een persoon kan er volgens de wet ook voor kiezen om te communiceren met de overheid als een onderneming, dus via het KvK-nummer. De wetgever heeft bepaald dat te allen tijde de gastouder die actief is op de VGO bekend moet zijn. Derhalve wordt onderscheid gemaakt tussen de Niet-natuurlijke persoon als houder van een VGO en de gastouder zelf. In alle gevallen moet dus de gastouder worden vastgelegd die de daadwerkelijke uitvoering van de VGO verzorgd.

De gebruiker voert gegevens van de houder van een OKO in. Het systeem controleert of de houder (natuurlijke of niet-natuurlijke persoon) reeds in het register aanwezig is. Indien dit niet het geval is, voert de gebruiker de resterende nieuwe gegevens van de houder. Indien blijkt uit de aanvraag dat de houder van een VGO niet de gastouder zelf is maar een Niet-natuurlijk persoon, dan moeten ook de gegevens van een gastouder ingevoerd worden. Nadat de gegevens zijn ingevoerd worden deze door het systeem gecontroleerd. Indien de invoer correct is bevonden wordt dat door het systeem gemeld.

Indien blijkt dat de ingevoerde gegevens over de Natuurlijke persoon of Niet-Natuurlijke persoon afwijken van de gegevens die reeds in het LR voorkomen, moet vastgesteld worden welke actie ondernomen moet worden. Indien het authentieke gegevens uit de basisregistraties betreft, moet conform de desbetreffende wetgeving van het GBA en NHR een terugmelding worden gedaan via de daarvoor beschikbare voorzieningen en wordt het registratie proces beëindigd. De reeds ingevoerd (OKO) gegevens worden door het systeem verwijderd. Een eventueel gecorrigeerde aanvraag wordt opnieuw ingevoerd.

Indien het geen authentieke gegevens betreft, kan de gebruiker (mits geautoriseerd) de afwijkende gegevens in te voeren. Daarbij geeft de gebruiker aan welke soort wijziging het op de gegevens betreft (typefout of wijziging van gegevens).

De gemeente ontvangt elektronisch of op papier het inspectierapport van de GGD. Dit kan zijn opgesteld naar aanleiding van een inspectie van een nieuwe inschrijving of betrekking hebben op een reguliere (jaarlijkse) inspectie. De inspectierapporten worden zo nodig binnen de gemeente gedigitaliseerd.

De gemeente ontvangt een inspectierapport en advies van de GGD (medewerker keten). Het openbaar maken van de inspectierapporten is een verantwoordelijkheid van de GGD. In principe moeten alle rapporten openbaar worden. De GGD kan afwijken van deze regeling en besluiten dat een rapport niet openbaar mag. Daarnaast beoordeelt de gemeente of het inspectierapport gepubliceerd kan worden. Indien er bevindingen zijn, wordt de GGD daarvan op de hoogte gebracht.

De (ingelogde) gebruiker (gegevensverwerker gemeente) voert zoekgegevens in in het Overheidsportaal om de OKO te vinden, waarop het inspectierapport betrekking heeft. Het ‘systeem’ zoekt de bijbehorende OKO gegevens op en toont deze aan de gebruiker. De gebruiker legt enkele kenmerken van het document vast en koppelt het elektronische inspectierapportdocument aan de OKO. Het systeem legt het inspectierapport bij de OKO vast. Indien de verwerking niet correct is verlopen, kan de gebruiker het nogmaals proberen. Als de verwerking succesvol is afgerond, den is deze processtap afgerond.

Het definitief inschrijven van een OKO is een handeling van de gegevensverwerker gemeente die rechtsgeldige gevolgen kan hebben voor de geregistreerde of gebruikers van de ‘subjecten’ dus de OKO's, die eraan refereren in bijvoorbeeld de aanvragen voor toeslagen.

Daarom wordt de gebruiker door het systeem zo goed mogelijk ondersteund bij het volledig invoeren van de benodigde gegevens over een organisatie voor kinderopvang, zoals in de wet- en regelgeving is bepaald.

Op basis van een advies van de GGD neemt de gemeente het besluit om een organisatie voor kinderopvang op te nemen in het Landelijk Register. De registratie van de aanvraag voor registratie is reeds in het Landelijk Register aanwezig. De gebruiker selecteert de status ‘ingeschreven’ bij de OKO. Daarbij worden de kenmerken van de geldigheid van het besluit vastgelegd. Het systeem voert controles uit op volledigheid, consistentie e.d. De verwerkte gegevens worden nogmaals getoond aan de gebruiker. De gebruiker bevestigt de gegevens of past deze aan. Nadat de bevestiging heeft plaatsgevonden, verwerkt het systeem de gegevens en wordt een definitief inschrijvingsnummer gegenereerd. Het inschrijvingsnummer wordt getoond door het systeem aan de gebruiker. Hiermee is de registratie afgerond.

Er volgt na de inschrijving nog een communicatiestap richting de houder. De gemeente verstrekt het inschrijvingsnummer (= het unieke LRK-ID) aan de aanvrager middels een beschikking. De datum dagtekening van de beschikking is de datum aanvang exploitatie (= datum status is ingeschreven). Vanaf die datum bestaat er dus recht op een toeslag. Dit is een AO stap voor de gemeenten die niet door het LRK wordt ondersteunt.

Indien besloten wordt dat naar aanleiding van een negatief advies van de GGD of om andere redenen er geen inschrijving mogelijk is, worden de gegevens niet verwijderd uit het LR, maar wordt de aanvraag wel vastgelegd, maar dan met de status niet-ingeschreven. Dit is relevant om bijvoorbeeld misbruik of onterechte aanvragen snel te kunnen traceren én om zicht te houden op de werkdruk van zowel gemeente als GGD.

De gebruiker (gegevensverwerker gemeente) besluit de aanvraag van een OKO niet te honoreren en zoekt de geregistreerde aanvraag op in het systeem met behulp van identificerende kenmerken. Het systeem toont de gevonden resultaten. De gebruiker selecteert de juiste voorlopig geregistreerde OKO. De status van de OKO wordt aangepast, zodanig dat afgeleid kan worden dat er geen definitieve inschrijving plaatsvindt. Naast de status aanpassing legt de gebruiker een motivatie vast. Het systeem vraagt om een bevestiging, nadat de gebruiker de invoer heeft gedaan. Vervolgens is de registratie bijgewerkt en heeft er geen definitieve inschrijving van de aanvraag plaatsgevonden.

De afwijzing van het verzoek tot inschrijving wordt gecommuniceerd met de aanvrager. Dit is een AO stap voor de gemeenten die niet door het LRK wordt ondersteunt.

Op basis van meldingen van de houders van OKO's, bevindingen tijdens inspecties of via andere kanalen kunnen wijzigingen gemeld worden bij de gemeenten.

De gebruiker (gegevensverwerker gemeente) moet ingelogd zijn om veranderingen door te kunnen voeren. Na het inloggen voert de gebruiker zoekgegevens in om de OKO of houder te kunnen vinden om wijzigingen te kunnen verwerken. Aan de hand van de zoekcriteria zoekt het systeem de mogelijke OKO's op en toont deze aan de gebruiker. De gebruiker selecteert de juiste OKO of houder en voert de wijzigingen in. Daarbij wordt door de gebruiker aangegeven welk type wijziging het is, een correctie van een typefout of een verandering van de gegevens van een OKO of houder. Na invoer gaat het systeem de gewijzigde gegevens verwerken en stelt vast of de wijzigingen toegestaan zijn. Indien deze niet toegestaan zijn, wordt daarvan een melding getoond aan de gebruiker. Indien de wijziging is toegestaan worden de gewijzigde gegevens getoond aan de gebruiker. De gebruiker controleert de gegevens en besluit of hij klaar is of dat er nog meer gewijzigd moet worden. Als er geen wijzigingen meer verwerkt moeten worden, wordt het registratie-proces beëindigd.

Een anonieme gebruiker (publiek of overheidspersoneel met beperkte benodigde functionaliteit) kan OKO's raadplegen via het publieksportaal.

De anonieme gebruiker heeft het publieksportaal van het LRK gevonden op internet. Hij voert een aantal zoekcriteria in. Het systeem zoekt aan de hand van de criteria alle OKO's op die voldoen aan de criteria. De gebruiker kan één van de zoekresultaten selecteren. Het systeem haalt de detailinformatie van de betreffende OKO op. Deze detailgegevens worden getoond. De gebruiker kan besluiten om te zoeken in de tijd of om de inspectierapporten te raadplegen. Het systeem opent op verzoek van de gebruiker het inspectierapport. De gebruiker kan besluiten om de raadpleging te stoppen of om een ander zoekresultaat te selecteren.

In het Interactiemodel dat onderdeel is van het Globaal Functioneel ontwerp wordt een algemene conceptuele beschrijving gegeven van de gebruikersinterface. Het beschrijft de wijze waarop de mens-machine-interactie plaatsvindt.

In onderstaande tabel is een inventarisatie opgenomen van de mens-machine-interacties per processtap zoals beschreven in het voorliggende procesmodel.

Om een overzicht te creëren van de wijze waarop de LRK-applicatie moet functioneren is een Use-Case Model LRK opgesteld. Een use-case beschrijft ‘wie’ met het betreffende systeem ‘wat’ moet kunnen doen. Per systeemcomponent zijn de volgende use cases relevant. Voor een overzicht van de use cases wordt gerefereerd aan het UCM versie 1.0 d.d. 22-10-2009.

Het publieksportaal is de systeemcomponent die ter beschikking wordt gesteld aan anonieme gebruikers (van het internet) om gegevens over organisaties voor kinderopvang te bekijken.

De volgende use cases maken gebruik van het Publieksportaal:

1. •

   zoeken LRK-subjecten

2. •

   zoeken organisatie voor kinderopvang (OKO)

3. •

   raadplegen LRK-subject

4. •

   raadplegen OKO

5. •

   tonen inspectierapport

Het overheidsportaal is de systeemcomponent dat gebruikt wordt door bevoegde functionarissen om de gegevens van organisaties van kinderopvang te registreren en te gebruiken.

De volgende use cases maken gebruik van het Overheidsportaal:

1. •

   uitgebreid zoeken LRK subjecten

2. •

   uitgebreid zoeken OKO

3. •

   inzien gegevens LRK-subject

4. •

   inzien gegevens OKO

5. •

   wijzigen administratieve status OKO

6. •

   registreren OKO

7. •

   registreren LRK-subject

8. •

   wijzigen gegevens OKO

9. •

   wijzigen gegevens LRK-subject

10. •

    registreren inspectierapport

11. •

    inloggen

12. •

    uitloggen

13. •

    registreren gastouder

14. •

    raadplegen historische gegevens OKO

15. •

    Tonen overzichten OKO

16. •

    Afdrukken overzichten

Vanuit oogpunt van service oriëntatie, wordt het Landelijk register gezien als afgebakend systeem. Het LR wordt ontsloten via een set register services waardoor gegevens opgeslagen, opgehaald en verwijderd kunnen worden.

Het landelijk register en bijbehorende Register services wordt gebruikt door de portalen. Ook bij het onderhoud van het register wordt gebruik gemaakt van services voor de volgende use cases:

1. •

   onderhouden gegevens gemeente

2. •

   onderhouden gegevens GGD

3. •

   onderhouden stamtabellen

4. •

   beheren gebruikers

5. •

   beheren autorisaties

Een module is een op zichzelf staande, identificeerbare groep functies, die als geheel een bepaalde doel hebben.

De use cases gebruiken de verschillende modules.

De modules zijn benoemd vanuit verschillende invalshoeken.

De module Landelijk register bevat de services die nodig zijn om de aangeleverde input te kunnen verwerken en de gevraagde output te kunnen leveren.

Het betreft dan het creëren, raadplegen en wijzigen van gegevens in het register, maar ook het genereren van overzichten.

Via de publieksportaal worden opdrachten voor raadplegen en zoeken ontvangen. Via het overheidsportaal kan naast raadplegen en zoeken ook de opdracht om te creëren en wijzigen.

De Beheermodule kan bepaalde (gegevens)tabellen aanpassen en queries uitvoeren op de administratie van het landelijk register.

De module Publieksportaal is de presentatie laag voor de ‘anonieme gebruiker’ en bevat services om via internet informatie te ontsluiten uit het Landelijk register. De module stelt schermen samen, afhankelijk van de actie die door de gebruiker is uitgevoerd.

Het publieksportaal wordt opgenomen in een website van OCW die ook algemene informatie bevat over de relevante wet- en regelgeving of verwijzingen naar bronnen en actuele informatie.

Schermen in het publieksportaal:

1. •

   zoekscherm(en): de gebruiker kan verschillende waarden invoeren om te zoeken naar kinderopvang;

2. •

   raadpleegscherm(en): om de gevonden resultaten op overzichtelijke wijze getoond worden

3. •

   links naar functionaliteiten zoals printen, help

De gegevens die getoond worden op het Publieksportaal voldoen aan de WBP. Het portaal volgt deze wetgeving.

De module Overheidsportaal vormt de presentatielaag voor de geautoriseerde gebruiker (Gegevensverwerker gemeente, medewerker keten) en bevat services die toegang verschaffen tot het Landelijk register.

De module stelt schermen samen, afhankelijk van de actie die de gebruiker uitgevoerd heeft of kiest om uit te gaan voeren.

Schermen in het overheidsportaal:

1. •

   inlogscherm: een scherm waarin de gebruiker gegevens ten behoeve van identificatie en authenticatie kan invoeren.

2. •

   keuzescherm(en): de geautoriseerde gebruiker kan aangeven welke actie hij wil uitvoeren.

3. •

   zoekscherm(en): de gebruiker kan verschillende waarden invoeren om te zoeken naar kinderopvang;

4. •

   raadpleegscherm(en): om de gevonden resultaten op overzichtelijke wijze getoond worden

5. •

   invoerscherm(en): een scherm waarop de gebruiker gegevens kan invoeren, wijzigen of verwijderen.

6. •

   overzichtscherm(en): een scherm waarop management informatie getoond kan worden.

Het overheidsportaal regelt de controle op wijzigingen door de toepassing van business rules. Bepaalde mutaties op de gegevens in het landelijk register mogen niet zonder meer worden doorgevoerd.

Afhankelijk van de vragende module en autorisaties van de gebruiker worden gegevens over personen getoond.

Deze module behelst alle services die noodzakelijk zijn om persoonsgegevens van natuurlijke personen te bewerken. De gegevens maken onderdeel uit van het landelijk register, maar worden op termijn mogelijk extern ‘opgehaald’, op het moment dat de koppeling met de centrale voorziening van de Gemeentelijke BasisAdministratie Verstrekkingen (GBA-V) een feit is.

Afhankelijk van de vragende module (overheidsportaal of publieksportaal) mogen gegevens geleverd worden.

In welke mate deze module zal wijzigen na de koppeling met de GBA is nu nog niet bekend.

Deze module behelst alle services die noodzakelijk zijn om persoonsgegevens van niet-natuurlijke personen te bewerken. De gegevens maken onderdeel uit van het Landelijk register, maar worden op termijn mogelijk extern ‘opgehaald’, op het moment dat de koppeling met de centrale voorziening van het Nieuw Handelsregister (NHR) een feit is. Ook van deze module is nog niet bekend wat de exacte gevolgen zijn na koppeling met het NHR.

Deze module behelst alle services die noodzakelijk zijn om adresgegevens te beheren. De adresgegevens worden op termijn doorgeleverd door koppelingen met de NHR en GBA.

Er wordt onderscheid gemaakt tussen binnenlandse en buitenlandse adressen. Daarnaast wordt vastgelegd in het LR wat het gebruiksdoel van het adres is, bijvoorbeeld:

1. •

   opvanglocatie;

2. •

   correspondentieadres;

3. •

   woonadres.

In de business rules van deze module wordt geregeld welke adressen gewijzigd mogen worden door de gebruiker, zonder dat dit consequenties heeft voor de inschrijving van de OKO.

De gebruikers van het Overheidsportaal moeten geïdentificeerd kunnen worden. Deze module Gebruikers behelst alle services die noodzakelijk zijn voor het registeren en beheren van gebruikers.

Een gebruiker is ‘iedereen die mens is en feitelijk communiceert met het systeem’ in een bepaalde rol. Een Actor is een rol die interacteert met het systeem. De rol kan door een persoon of door een ander systeem worden vervuld. Per rol wordt bepaald welke rechten de gebruiker heeft om handelingen te verrichten met het systeem. De rechten hebben betrekking op toegang tot schermen, buttons (functies) of velden op het scherm.

Er zijn verschillende Actoren:

De gebruikers worden centraal opgevoerd en beheerd. Er worden gegevens ten behoeve van authenticatie vastgelegd zoals wachtwoord, telefoonnummer, emailadres. Daarnaast wordt geregistreerd aan welk autorisatieprofiel de gebruiker is gekoppeld.

Ten behoeve van het eenduidig vaststellen van de gebruiker, wordt de gebruiker die zich aanmeldt bij het Overheidsportaal in de gelegenheid gesteld, een aantal authenticatiegegevens in te voeren. Vervolgens gaat deze module vaststellen op basis van de geregistreerde gebruikersgegevens of de gebruiker daadwerkelijk toegang mag krijgen tot het overheidsportaal en welke bijbehorende rechten (autorisaties) er bij het gebruikersprofiel behoren.

Tevens wordt het aantal foutieve aanmeldpogingen bijgehouden om een gebruiker eventueel te blokkeren.

Van de succesvolle authenticatie en het starten van een gebruikerssessie wordt in het systeem een registratie gemaakt.

Deze module gaat over de behandeling van documenten. In de eerste oplevering van het LRK worden alleen de GGD-inspectierapporten per OKO opgeslagen.

Er wordt geen relatie gelegd naar document management systemen.

Het inspectierapport wordt in PDF-format opgenomen in het LR en enkele metagegevens van het inspectierapport worden geregistreerd. De documenten worden volgtijdelijk getoond via het publieks- en overheids- portaal.

Ten behoeve van het bieden van management informatie wordt, voor de eerste oplevering in 01-01-2010 een beperkt aantal (vooraf gedefinieerde) overzichten ontwikkeld. Deze module biedt de gebruiker de mogelijkheid om één of meer criteria te selecteren waarmee overzichten gegenereerd kunnen worden.

1. •

   Administratieve statussen;

2. •

   gemeenten van inschrijving

3. •

   soort/vorm van kinderopvang

4. •

   aantal kindplaatsen

5. •

   aantal aangesloten VGO

6. •

   datum laatste inspectierapport

De module biedt de mogelijkheid om de overzichten af te drukken. Omdat deze module vanuit verschillende browsers wordt aangeroepen, wordt voor het afdrukken een opdracht vanuit de module verstrekt aan de lokale browser.

Van alle wijzigingen wordt in de administratie een historie bijgehouden. Indien de gebruiker over voldoende rechten beschikt kan deze de audit trail raadplegen.

De gebruiker kan door deze module een keuze maken om de historie van de gegevens van een OKO te ontsluiten. Daarbij kan gekozen worden om de stand van de ‘administratie’ op een bepaald moment te raadplegen of om te zoeken binnen een bepaalde periode.

Naast de historie wordt bij iedere handeling door een geïdentificeerde gebruiker geregistreerd welke handelingen er met het LR worden uitgevoerd.

Het landelijk register maakt gebruik van stamtabellen. Dit zijn tabellen waaraan gerefereerd wordt in de gegevens van een OKO, zoals gemeenten, landen etc.

Deze gegevens zijn ook aan veranderingen onderhevig. Deze module biedt de mogelijkheid om deze gegevens te onderhouden.

Daarnaast zijn er gegevens die per gemeente worden beheerd zoals contactgegevens van de gemeenten en de GGD.

Deze module biedt de mogelijkheid om informatie over de toepassing van het publieksportaal of overheidsportaal te presenteren.

Voor drie Actoren is het collaboration diagram weergegeven in onderstaande afbeelding. Daarin wordt op hoofdlijnen aangegeven hoe de modules samenwerken om de volgende actoren te ondersteunen:

1. –

   medewerker keten

2. –

   gegevensverwerker gemeente

3. –

   publiek

De Actoren Gegevensverwerker Gemeente en Medewerker Keten hebben verschillende autorisaties. De Actor Gebruikersbeheerder onderhoudt de gebruikersadministratie. Autorisatiebeheerder kan de gebruikers toevoegen aan een autorisatieprofiel.

Voor elke geautoriseerde gebruiker worden mutaties vastgelegd. De geautoriseerde gebruikers zijn de Actoren: Gegevensverwerker Gemeente, Autorisatiesbeheerder, Gebruikersbeheerder.

De geautoriseerde gebruiker (Functioneel beheerder, Gegevensverwerker Gemeente) is verantwoordelijk voor het onderhouden van de gegevens over de GGD en de Gemeente. Daarnaast is de functioneel beheerder geautoriseerd om overzichten te genereren, waarvoor geen standaard rapportage functionaliteiten ontwikkeld zijn.

De handelingen worden ook in de audit trail vastgelegd.

1. [1]

   Projectstartarchitectuur Landelijk Register Kinderopvang, versie 1.0, 10-2009

2. [2]

   Use-case model Landelijk Register Kinderopvang, versie 1.0, 22-10-2009

Dit document beschrijft het Interactiemodel en is onderdeel van Functioneel Ontwerp (FO). Het Interactiemodel is een algemene (conceptuele) beschrijving van de gebruikersinterface en is een verdere uitdieping van, en tekstuele toelichting op, het Globaal Prototype (GP).

Het volledige functioneel ontwerp wordt opgebouwd in twee stappen. Het Globale Functionele Ontwerp (GFO) is een eerste opzet van het functionele ontwerp en zal uiteindelijk dienen als input voor het Detail Functioneel Ontwerp (DFO).

Dit document is bedoeld voor:

1. •

   Eindgebruikers om functionaliteit af te beschrijven en af te stemmen.

2. •

   Software Architecten die het document nodig hebben voor het opstellen van de systeemarchitectuur en een inschatting van de benodigde ontwikkelcapaciteit.

3. •

   Functioneel ontwerpers die het document gebruiken voor het ontwikkelen van het DFO.

Dit document beperkt zich tot functionaliteit die per 1/1/2010 gerealiseerd moet zijn, overeenkomstig de projectplanning en -scope van de Project Startarchitectuur fase 1.

Dit document is opgesplitst in een aantal hoofdstukken:

1. •

   Hoofdstuk 2 omschrijft de basisstructuur van het Publieksportaal, het Overheidsportaal en de Beheerfunctionaliteit.

2. •

   Hoofdstuk 3 beschrijft de algemene uitgangspunten van de te realiseren portalen

3. •

   In hoofdstuk 4 worden de verschillende typen gebruikers en de bijbehorende autorisaties omschreven.

4. •

   De hoofdstukken 5, 6 en 7 gaan in op de functies van het Publieksportaal, het Overheidsportaal en de Beheerfunctionaliteit.

Het GFO beschrijft op globaal niveau alle gewenste systeemfuncties. In het DFO kan besloten worden om in het GFO omschreven functionaliteit niet of slechts voor een gedeelte te realiseren (dit geldt ook voor het GP: het kan besloten worden aspecten van de user interface zoals weergegeven in het globaal prototype uiteindelijk niet te realiseren).

Het volledige functioneel ontwerp wordt opgebouwd in twee stappen. Eerst wordt het Globaal functioneel ontwerp (GFO) opgesteld. Dit bestaat uit een procesmodel (dat de functionele applicatiestructuur beschrijft), een datamodel en het interactie-ontwerp (dit document), evenals een prototype. Het Detail functioneel ontwerp (DFO) bevat de uitwerking van hetgeen in het GFO op hoofdlijnen is vastgesteld.

Het functioneel ontwerp baseert zich primair op de project start architectuur (PSA), en op de functionele requirements, beschreven in de geprioriteerde requirements list (PRL). Het functioneel ontwerp vormt samen met prototype en technisch ontwerp (SAD) de basis voor realisatie.

Dit document is opgesteld met gebruikmaking van:

1. •

   Project Startarchitectuur , versie 0.9

2. •

   Use Case Model Landelijk Register Kinderopvang, versie 1.0

3. •

   Project Initiation Document ICT-ontwikkeling, versie 1.1

4. •

   Requirements List (niet vastgesteld)

5. •

   Globaal Prototype, versie 1.0

Het Interactiemodel is, als onderdeel van het GFO, opgesteld in nauwe samenhang met het Procesmodel en het Datamodel.

In dit document zijn de volgende zaken nog niet of slechts gedeeltelijk uitgewerkt:

1. •

   Er is nog geen expliciete relatie gelegd met het Use Case Model

2. •

   Inzien van historische gegevens is nog niet uitgewerkt (tijdreizen)

3. •

   Details omtrent het wijzigen van een VGO moeten nog worden uitgewerkt

4. •

   Rapportages: op basis van de nog te houden workshops dienen de benodigde rapportages en de managementinformatie nog verder uitgediept te worden

5. •

   Het Publieksportaal is nog niet in detail uitgewerkt.

Deze zaken verdienen extra aandacht bij uitwerking in het DFO.

1. 1.

   Ministerie van OCW, rijkshuisstijl

   http://rijkshuisstijl.communicatieplein.nl/index.cfm/ministerie-van-onderwijs-cultuur-en-wetenschap/middelen/digitaal/applicaties

2. 2.

   Webrichtlijnen

   http://webrichtlijnen.nl/toetsen

In de volgende paragrafen zal de basisstructuur van de LRK-applicatie nader worden beschreven.

Het Landelijk Register Kinderopvang is op te delen in drie onderdelen:

1. 1

   het Overheidsportaal;

2. 2

   het Publieksportaal;

3. 3

   de Beheerinterface.

Het Overheidsportaal is het portaal dat gebruikt wordt door bevoegde functionarissen om de gegevens van organisaties van kinderopvang te registreren (invoeren, wijzigen) en te gebruiken (raadplegen).

Het Overheidsportaal bestaat uit de volgende 'hoofdschermen'. Hiermee wordt de navigatiestructuur aangegeven. Daarnaast worden per hoofdscherm een aantal aanvullende schermen onderscheiden. Deze zijn niet in onderstaand overzicht opgenomen.

Het Publieksportaal is het portaal dat ter beschikking wordt gesteld aan anonieme gebruikers (via het internet) om gegevens over organisaties voor kinderopvang te bekijken. Dit beperkt zich tot die gegevens die wettelijk gezien geregistreerd moeten worden en verstrekt mogen worden, en die de anonieme gebruiker inzicht geeft in het al of niet geregistreerd zijn van een organisatie voor kinderopvang. Procesinformatie behoort expliciet niet tot de gegevens die getoond worden.

Het publieksportaal wordt gepositioneerd als een zelfstandige website en vormt géén onderdeel van een of meer andere website(s).

Het Publieksportaal bestaat uit de volgende 'hoofdschermen':

De beheerinterface wordt gebruikt door daartoe bevoegde beheerders voor het uitvoeren van algemene beheertaken. Hiertoe worden de volgende functies/schermen onderkend:

Dit hoofdstuk behandelt een aantal algemene uitgangspunten ten aanzien van het Overheidsportaal, het Publieksportaal en de Beheerinterface. In de volgende hoofdstukken worden deze onderdelen in meer detail uitgewerkt.

Het Overheidsportaal en het Publieksportaal zullen deels dezelfde functionaliteit bevatten. Hiermee is in het functioneel ontwerp zoveel mogelijk rekening gehouden, zowel in schermopbouw als in functionaliteit. Dit om enerzijds consistentie te bewerkstelligen tussen de portalen, anderzijds om componenten eventueel te kunnen hergebruiken.

De structuur die wordt gehanteerd is gebaseerd op de Overheidscommunicatie Nieuwe Stijl (ONS) en zal de richtlijnen en uitgangspunten daarvan zoveel mogelijk volgen. Dit geldt zowel voor het Overheidsportaal als het Publieksportaal.

Deze richtlijnen zijn gepubliceerd op de website van het ministerie van OCW (zie Externe bronverwijzing 1).

De schermen kennen de volgende algemene opbouw.

1. •

   Hoofdmenu: hier wordt de primaire navigatie getoond.

2. •

   Linkerkolom: in deze kolom kunnen secundaire navigatie-elementen worden opgenomen die het navigeren door het systeem vergemakkelijken.

3. •

   Contentgedeelte: in dit gedeelte wordt alle content getoond die door het systeem wordt gegenereerd.

4. •

   Rechterkolom: deze kolom zal met name worden gebruikt voor contentspecifieke helpteksten. Indien noodzakelijk kan het contentgedeelte worden doorgetrokken en komt deze kolom te vervallen.

De primaire navigatie bestaat uit een persistent hoofdmenu, getoond in het vaste deel boven aan de pagina (zie schermopbouw), daar waar nodig aangevuld met een submenu per onderdeel, getoond aan de linker zijde (zie schermopbouw).

Het menu bestaat slechts uit deze twee lagen. Meer complexe, samengestelde mutaties worden verzorgd door een 'wizard' (stappenplan). Daaronder vallen alle aanvragen die een mutatie betreffen en mogelijk een beperkt aantal mutaties in het beheerdeel.

De secundaire navigatie is met name bedoeld om de gebruiker hulp te bieden bij het navigeren tussen de verschillende schermen (bijvoorbeeld door het bieden van navigatiemogelijkheden van het detailscherm terug naar het zoekscherm, etc.).

Vooralsnog wordt géén kruimelpad gebruikt, aangezien de noodzaak daartoe niet wordt onderkend.

Er wordt onderscheid gemaakt naar twee soorten help.

Enerzijds is er een 'vaste' set help-pagina's, te benaderen met de link rechtsboven op iedere pagina (zie schermopbouw). Deze help bevat een submenu maar is niet context-gevoelig. De tekst van de help bevat géén koppelingen. Er is geen zoekmogelijkheid in de helptekst. De help bevat geen documenten en géén links naar externe sites/pagina's.

Anderzijds zijn er korte stukjes toelichting die getoond worden bij formulieren of bij het tonen van detailgegevens. Deze hebben betrekking op een locale scope, zoals de uitleg van een bepaalde term. Deze worden opgenomen in de rechterkolom (zie schermopbouw).

Pagina's kunnen worden afgedrukt via de printfuncties van de webbrowser. Indien er in specifieke gevallen behoefte is aan een andere manier van het printen van gegevens dan wordt dit apart beschreven.

Autorisatie gebeurt op basis van het gebruikersprofiel waarmee de eindgebruiker zich heeft aangemeld. Een profiel is gerelateerd aan een of meer rollen. Iedere rol bevat een of meer rechten (set van schermen, toegang tot gegevens en acties).

Er wordt géén gebruik gemaakt van tijdelijke rechten (profiel heeft rol gedurende een bepaalde periode en/of rol heeft recht gedurende een bepaalde periode), context-afhankelijke rechten (idem, afhankelijk van context), inhoud-afhankelijke rechten (idem, afhankelijk van inhoud van bepaalde (andere) gegevens in de database, zoals waarde van een status) of toegekende/overdraagbare rechten (gebruiker a verleent machtiging tot uitvoeren van taken aan gebruiker b).

In tegenstelling tot voorgaande wordt expliciet wel rekening gehouden met de gemeente behorende bij het profiel. Alle gegevens in de database zijn 'eigendom' van een bepaalde gemeente of worden centraal beheerd.

Een aantal profielen wordt gebruikt voor 'shared services', deze hebben rechten op de gegevens van meer dan een (maar niet alle) gemeenten. Een aantal profielen wordt gebruikt voor 'data entry', deze hebben rechten op de gegevens van alle gemeenten.

Autorisatie heeft alleen betrekking op de interface-modules Overheidsportaal en Beheer.

Alle geregistreerde gebruikers mogen alle gegevens inzien. Het muteren is gebonden aan bovenstaande autorisaties. Details worden uitgewerkt in het DFO.

De anonieme gebruiker van het Publieksportaal hoeft zich niet te authenticeren.

In het informatie beveiligingsplan zijn de gegevens die via het Overheidsportaal ontsloten worden, geclassificeerd als ‘confidentieel’, WBP risicoklasse II. Dit betekend dat deze gegevens slechts toegankelijk mogen zijn voor een gedefinieerde groep personen (bijv. bepaalde afdelingen of bepaalde functies). Ten aanzien van de te nemen maatregelen wordt géén onderscheid gemaakt naar het raadplegen van gegevens en het muteren van gegevens.

Voor authenticatie wordt een combinatie gebruikt van een persoonlijk gebruikersnaam/wachtwoord, een systeemcertificaat (PKI Overheid), en een zogeheten TAN code. Dit is een code die door een component van de LR applicatie wordt gegenereerd per authenticatie transactie en wordt toegezonden aan de medewerker die zichzelf wil authenticeren. Doordat het alleen de betreffende medewerker is die deze code kan ontvangen is daarmee de authenticiteit gewaarborgd.

Per authenticatie transactie wordt een TAN code gegenereerd en per email aan de medewerker toegezonden. De medewerkers die mutatierechten moeten krijgen op de gegevens die ontsloten worden via het Overheidsportaal zijn (per 01-01-2010) alleen gemeenteambtenaren. Deze worden verondersteld allen te beschikken over een (zakelijk/overheids) email-adres.

Ook de beheerders (gebruikers van de Beheerinterface) authenticeren zich op bovenbeschreven wijze.

Meldingen worden getoond op twee manieren. Indien een keuze van de gebruiker afgedwongen moet worden wordt er een popup getoond waarin de keuze wordt uitgelegd en de gebruiker zijn keuze kan maken. Als het niet noodzakelijk is dat de gebruiker de keuze maakt, dan wordt de melding op de betreffende pagina getoond, op een vaste positie, direct onder de paginatitel.

De eindgebruiker heeft geen 'log' van meldingen. Met het tonen van meldingen zal rekening gehouden worden met de afspraken die daarvoor al zijn vastgelegd in de Huisstijl (zie schermopbouw).

Indien het resultaat van een zoekopdracht geen items bevat die aan de criteria voldoen, is dat geen foutmelding maar het resultaat van die zoekopdracht en wordt als zodanig gepresenteerd.

Het gebruik van stamtabellen om het invoeren van gegevens te vergemakkelijken (bijvoorbeeld postcodes, straatnamen en gemeentenamen) zal aanvankelijk tot een minimum worden beperkt. In het globaal datamodel worden de te gebruiken stamtabellen toegelicht.

Met name binnen het Publieksportaal zullen een aantal contentpagina's beschikbaar worden gesteld met algemene informatie over het portaal en de inhoud daarvan. Het betreft hier bijvoorbeeld informatie over de Wet Kinderopvang, het registratieproces, toe te kennen toeslagen, etc. De algemene pagina's zijn statische HTML-pagina's en kunnen niet via het systeem worden beheerd.

Het Publieksportaal zal zoveel mogelijk dienen te voldoen aan de Webrichtlijnen. Voor de oplevering op 1 januari 2010 zal het portaal in ieder geval voldoen aan de automatische toetsing (47 van de 125 richtlijnen). Dit betreft met name het voldoen aan de W3C-normen. Meer informatie Externe bronverwijzing 2.

Voor het Overheidsportaal en de Beheerinterface gelden de Webrichtlijnen als een 'best effort'.

In dit hoofdstuk worden de verschillende typen gebruikers en de bijbehorende autorisaties per portaal omschreven.

Via het Overheidsportaal kunnen de gegevens van het Landelijk Register worden geraadpleegd, ingevoerd en gemuteerd. Het Overheidsportaal zal alleen toegankelijk zijn voor daartoe bevoegde gebruikers.

In dit scherm kan de gebruiker inloggen door zijn gebruikersnaam en wachtwoord en een (per e-mail toegestuurde) TAN-code op te geven. Als de combinatie van gebruikersnaam, wachtwoord en TAN-code onjuist is, wordt een foutmelding gegeven.

Als voor de eerste maal wordt ingelogd (of voor de eerste maal na het resetten van het wachtwoord), wordt de gebruiker verplicht zijn wachtwoord te wijzigen.

Na een succesvolle inlog komt de gebruiker terecht op het scherm 'Startpagina' (5.3).

Als de gebruiker zijn wachtwoord is vergeten, kan hij een nieuw wachtwoord aanvragen. Het nieuwe wachtwoord wordt gegenereerd en in een e-mail naar het geregistreerde adres verstuurd. Na het verstrekken van een nieuw wachtwoord is de gebruiker de eerste keer dat hij weer inlogt verplicht het wachtwoord te wijzigen.

Dit scherm is het startscherm van de gebruiker. Vanuit dit scherm heeft hij toegang tot de binnen het OP beschikbare informatie. Het scherm bestaat uit een aantal onderdelen:

1. •

   Registeren nieuwe aanvraag. Deze optie is alleen zichtbaar als een gebruiker mutatierechten heeft en leidt naar een wizard voor het invoeren van een VGO, GOB, KDV of BSO (5.7).

2. •

   Zoekfunctionaliteit voor het zoeken van een Houder of een OKO, met als uiteindelijke doel het raadplegen van informatie of (bij voldoende rechten) het wijzigen daarvan (5.3.1).

3. •

   Rapportages. Afhankelijk van de gebruikersrol worden verschillende standaardrapportages getoond (5.13).

Het zoekgedeelte van de pagina bestaat uit:

1. •

   Een filter op type: door middel van het filter kan de gebruiker aangeven dat hij alleen wenst te zoeken op een bepaald type OKO of een Houder.

2. •

   Een aantal zoekboxen waarin de gebruiker één of meerdere zoektermen kan opgeven, waarop hij wenst te zoeken. Een gebruiker kan zoeken binnen verschillende typen data (bijvoorbeeld zoeken op naam, adres, BSN/KvK-nummer) en kan deze typen data combineren (bijvoorbeeld zoeken op naam en adres).

3. •

   Een filter 'zoeken binnen eigen entiteit': op basis van de gebruikersrol heeft de gebruiker de mogelijkheid om te zoeken binnen of buiten zijn eigen entiteit (bijvoorbeeld binnen de eigen gemeente of de eigen GGD).

4. •

   Zoeken in specifieke periode: Via deze zoekopties is het mogelijk om de gegevens op te vragen op een specifiek moment in de tijd ('tijdreizen').

Wanneer meerdere zoektermen worden opgegeven dan worden in het resultaatscherm (zie ) alleen de gegevens getoond die voldoen aan alle opgegeven criteria (‘AND-search’).

Op basis van de zoekactie van de gebruiker worden de resultaten getoond in een lijst. Als de zoekactie geen resultaten oplevert, dan wordt een melding getoond.

Indien er sprake is van meer dan 20 zoekresultaten, dan worden de zoekresultaten over meerdere pagina's verdeeld. De gebruiker kan door deze pagina's heen bladeren.

De resultatenlijst toont de belangrijkste gegevens van een OKO of een Houder. De gegevens van een OKO en een Houder die worden getoond kunnen verschillen.

De naam is aanklikbaar en verwijst naar het detailscherm. Een gebruiker met voldoende rechten heeft een optie om direct naar het wijzigscherm te gaan.

In het scherm is het mogelijk om een nieuwe zoekactie te doen. De zoekcriteria die al eerder zijn opgegeven, zijn vooraf ingevuld.

Dit scherm toont de actuele detailgegevens van de Houder. Het scherm is op te splitsen in 4 onderdelen:

1. •

   kerngegevens;

2. •

   adresgegevens;

3. •

   aan de Houder gerelateerde OKO's;

4. •

   historische gegevens.

Vanuit de details van een Houder is het mogelijk om weer terug te keren naar het zoekresultaat. Per onderdeel heeft de gebruiker daarnaast de mogelijkheid om de gegevens te wijzigen.

Dit onderdeel van het scherm toont de kerngegevens van de Houder. Als het een NNP betreft dan bestaan deze gegevens onder andere uit de handelsnaam, het KVK-nummer en het vestigingsnummer. Bij een NP zijn dit onder andere de naam en het BSN.

In dit deel van het scherm worden de adresgegevens getoond. De adresgegevens kunnen in ieder geval bestaan uit een feitenlijk adres en een postadres.

Op het scherm worden in een overzicht alle aan de Houder gerelateerde OKO's getoond. Van de OKO's worden basisgegevens weergegeven om de OKO te kunnen identificeren. De gebruiker kan vervolgens doorklikken op een OKO om meer detailgegevens in te zien of om deze direct te wijzigen.

Per onderdeel kunnen de mutaties worden ingezien. De details hiervan worden uitgewerkt in het DFO.

Dit scherm toont de detailgegevens van een OKO. Het scherm is op te splitsen in 4 onderdelen:

1. •

   kerngegevens;

2. •

   adresgegevens;

3. •

   Houdergegevens;

4. •

   bijbehorende Inspectierapporten;

5. •

   historische gegevens.

Vanuit de details van een OKO is het mogelijk om weer terug te keren naar het zoekresultaat. Per onderdeel heeft de gebruiker daarnaast de mogelijkheid om de gegevens te wijzigen.

Dit onderdeel van het scherm toont de kerngegevens van de OKO, zoals bijvoorbeeld de naam, het soort kinderopvang, aantal kindplaatsen en de status.

In dit deel van het scherm worden de adresgegevens getoond. De adresgegevens kunnen in ieder geval bestaan uit een feitenlijk adres en een postadres.

In dit deel van het scherm wordt de gerelateerde Houder getoond. De gebruiker kan vervolgens doorklikken op een Houder om de detailgegevens van de Houder in te zien of deze te wijzigen.

In dit deel van het scherm worden de bij de OKO behorende inspectierapporten getoond. Het inspectierapport is een PDF-bestand dat de gebruiker kan downloaden. Standaard worden de laatste 10 inspectierapporten getoond. Op een apart scherm kan de gebruiker de complete historie van de inspectierapporten inzien.

Voor 2010 zal de GGD voor de VGO’s een inspectiebrief (in Word) opstellen. Deze is voor het register equivalent met een inspectierapport.

Per onderdeel kunnen de mutaties worden ingezien. De details hiervan worden uitgewerkt in het DFO.

Via dit scherm kan een OKO worden geregistreerd door middel van het doorlopen van een wizard.

Bij het registeren van gegevens in het Landelijk Register wordt altijd de OKO als uitgangspunt genomen. Gedurende dit registratieproces worden ook de overige gegevens (zoals gegevens van de Houder, Gastouderbureaus, etc.) aangevuld. Deze detailstappen worden apart beschreven.

Voor het registreren van OKO's worden drie afzonderlijke wizards gebruikt:

1. 1

   Registeren Kindercentrum (BSO, KDV);

2. 2

   Registeren VGO (inclusief registreren GO);

3. 3

   Registeren GOB;

In de eerste stap van de wizard dient de gebruiker het type aanmelding te selecteren (KDV, BSO, GOB of VGO). De procedures voor het registeren van een Kindercentrum (KDV en BSO) zijn hetzelfde, voor het registeren van een GOB en een VGO wijken deze af.

Het registeren van een Kindercentrum (KDV en BSO) en een Gastouderbureau verloopt aan de hand van de volgende stappen:

1. 1

   Toewijzen Houder

2. 2

   Invoeren detailgegevens

3. 3

   Controleren ingevoerde gegevens

In deze stap kan de gebruiker een Houder toewijzen. De Houder kan een Natuurlijk of een Niet Natuurlijk Persoon zijn.

De gebruiker heeft de volgende mogelijkheden:

1. –

   Zoeken naar een bestaande Houder op basis van een aantal zoekcriteria;

2. –

   als de Houder nog niet bestaat, aanmaken van een nieuwe Houder;

3. –

   als de Houder wel bestaat, dan kan de gebruiker deze selecteren.

Het toewijzen van een Houder staat in detail beschreven in paragraaf 5.8.

Het resultaat van deze stap is een gekoppelde Houder. In een apart scherm wordt de keuze van de Houder bevestigd. Het is nu nog mogelijk om een andere Houder te kiezen. Is er geen Houder gekoppeld dan kan het proces niet verder gaan.

Via deze stap heeft de gebruiker de mogelijkheid om detailgegevens van het kindercentrum of gastouderbureau in te voeren, zoals naam en adresgegevens. Bij het registeren controleert het systeem of het adres van de OKO binnen de eigen gemeente valt.

Het registreren staat in detail beschreven in paragraaf 5.9.

Op dit scherm krijgt de gegevens een samenvatting te zien van de zojuist ingevoerde gegevens en wordt om een bevestiging gevraagd.

Op dit punt in het proces wordt ook het unieke inschrijvingsnummer aangemaakt.

De status van de organisatie wordt automatisch op 'Aangemeld' gezet.

Het registreren van een VGO geschiedt aan de hand van de volgende stappen:

1. 1

   Toewijzen Gastouderbureau

2. 2

   Toewijzen Gastouder of Houder VGO

3. 3

   Invoeren detailgegevens

4. 4

   Controleren ingevoerde gegevens

Om een VGO te kunnen registeren dient de gebruiker eerst een GOB toe te wijzen. De gebruiker heeft de volgende mogelijkheden:

1. ○

   Zoeken naar een bestaande GOB op basis van een aantal zoekcriteria;

2. ○

   als de GOB bestaat, selecteren van het GOB;

3. ○

   als de GOB nog niet bestaat kan de VGO niet geregistreerd worden!

Het toewijzen van een GOB staat in detail beschreven in paragraaf 5.7.2.1.

Het resultaat van deze stap is een gekoppelde GOB. In een apart scherm wordt de keuze van de GOB bevestigd. Het is nu nog mogelijk om een andere GOB te kiezen. Is er geen GOB gekoppeld dan kan het proces niet verder gaan.

In deze stap kan de gebruiker een Gastouder of een Houder toewijzen.

Allereerst geeft de gebruiker aan of de gastouder communiceert als NP of als NNP. Vervolgens zal in het register worden gecontroleerd of de gastouder al bestaat.

De gebruiker heeft de volgende mogelijkheden:

1. –

   Zoeken naar een bestaande Gastouder of de Houder op basis van een aantal zoekcriteria;

2. –

   als de Gastouder of de Houder nog niet bestaat, aanmaken van een nieuwe Houder;

3. –

   als de Gastouder of de Houder wel bestaat, dan kan de gebruiker deze selecteren.

Het toewijzen van een Houder staat in detail beschreven in paragraaf 5.8.

Via deze stap heeft de gebruiker de mogelijkheid om detailgegevens van de VGO in te voeren, zoals naam, aantal kindplaatsen en adresgegevens.

Eventueel kan de gebruiker aangeven dat de gegevens van de Gastouder gelijk zijn aan die van de VGO.

De controle van gegevens bij de VGO bestaat uit twee gedeelten.

Allereerst krijgt de gebruiker een samenvatting te zien van de ingevoerde gegevens van de Gastouder en de VGO en wordt om een bevestiging gevraagd.

Op het tweede scherm krijgt de gebruiker de gebruiker alle details te zien omtrent de zojuist ingevoerde gegevens. Dit betreft gegevens over het GOB, de Houder, de VGO en de Gastouder.

Op dit punt in het proces wordt ook het unieke inschrijvingsnummer aangemaakt en getoond.

De status van de organisatie wordt automatisch op 'Aangemeld' gezet.

De gebruiker krijgt vervolgens de keuze om nog een VGO te registreren onder hetzelfde GOB of een nieuwe VGO te registeren onder een andere GOB.

Bij het registeren van een OKO dient ook altijd een Houder te worden toegewezen. Op basis van het type OKO dient een onderscheid gemaakt te worden tussen de toewijzing van een:

1. •

   Natuurlijk Persoon

2. •

   Niet Natuurlijk Persoon

Het toewijzen van een Houder geschiedt altijd aan de hand van de volgende stappen:

1. •

   Controleren of de NP/NNP al bestaat: de gebruiker kan op basis van een aantal zoekcriteria zoeken op NP/NNP. Aan de hand van het BSN/Sofinummer zal worden gecontroleerd of de NP al is geregistreerd in het register. Idem Kvk voor NNP.

2. •

   Indien de NP/NNP al bestaat dan zal de gebruiker worden gevraagd om de gegevens te controleren.

Indien de persoon nog niet is geregistreerd dan zal worden gevraagd om de gegevens van de NP of de NNP in te voeren.

Indien een Natuurlijk Persoon nog niet is geregistreerd, dan dient deze eerst te worden aangemaakt. In dit scherm dienen dient de gebruikers de gegevens van een natuurlijk persoon in te voeren.

Personen zonder BSN/Sofinummer kunnen niet in het register worden geregistreerd. Een NP kan wel een buitenlands adres hebben.

Indien een Niet Natuurlijk Persoon nog niet is geregistreerd, dan dient deze eerst te worden aangemaakt.

Indien een Gastouderbureau nog niet bekend is in het register dan dient deze te worden geregistreerd. Het registratieproces doorloopt de volgende stappen:

1. •

   Controleren of het GOB al bestaat: de gebruiker kan zoeken op GOB. Aan de hand van het KvK-nummer zal worden gecontroleerd of het GOB al is geregistreerd in het register.

2. •

   Indien het GOB al bestaat dan zal de gebruiker worden gevraagd om de gegevens te controleren.

3. •

   Indien een GOB nog niet is geregistreerd dan zal worden gevraagd om de gegevens van de GOB in te voeren.

Indien een Gastouder nog niet bekend is in het register dan dient deze te worden geregistreerd. De Gastouder is altijd een Natuurlijk Persoon.

Het registratieproces doorloopt de volgende stappen:

1. •

   Controleren of de Gastouder al bestaat: de gebruiker kan zoeken op Gastouder. aan de hand van het BSN zal worden gecontroleerd of de Gastouder al is geregistreerd in het register.

2. •

   Indien de Gastouder al bestaat dan zal het systeem controleren of de Gastouder actief is op slechts 1 VGO binnen de opgegeven exploitatieperiode.

3. •

   Indien een Gastouder nog niet is geregistreerd dan zal worden gevraagd om de gegevens van de Gastouder in te voeren.

Het opslaan van adresgegevens is een deelproces dat op meerdere plaatsen binnen de applicatie plaatsvindt. Er wordt een onderscheid gemaakt tussen het registeren van de volgende typen adresgegevens:

1. •

   een Binnenlands adres, bestaande uit:

   1. •

      een Feitenlijk adres

   2. •

      een Postadres, waarbij onderscheid gemaakt wordt tussen:

      1. •

         een Postbus

      2. •

         een Antwoordnummer

2. •

   een Buitenlands adres

3. •

   Contact/Correspondentie-gegevens

Het type adresgegevens dat noodzakelijk is kan per module verschillen. In het DFO zal nader worden uitgewerkt welke adresgegevens van toepassing zijn per situatie.

In de volgende paragrafen staat het wijzigen van gegevens door daartoe bevoegde gebruikers beschreven.

Bij het wijzigen van gegevens dient de gebruiker altijd aan te geven of de wijziging een administratieve wijziging betreft (bijvoorbeeld het herstellen van een tikfout) of dat de wijziging gevolgen heeft voor de inspectie (bijvoorbeeld het wijzigen van het aantal kindplaatsen).

In het detailscherm kunnen de gegevens per onderdeel gewijzigd worden. Het wijzigen is opgedeeld in een drietal onderdelen die hieronder verder worden uitgewerkt:

1. •

   Wijzigen kerngegevens en status

2. •

   Wijzigen adresgegevens

3. •

   Wijzigen betrokken Houder

In dit scherm kan de gebruiker de kerngegevens aanpassen. Daarnaast heeft de gebruiker de volgende opties:

1. •

   De administratieve status aanpassen: bij een status wordt altijd een reden en een begin- en einddatum van wijziging opgegeven. Daarnaast wordt de gebruiker via een melding gewezen op de gevolgen van deze statuswijziging.

2. •

   Nieuw inspectierapport toevoegen: naast het uploaden van het inspectierapport worden een aantal kenmerken behorende bij het rapport ingegeven.

Het is mogelijk om adresgegevens te wijzigen. Het wijzigen van de locatiegegevens (feitelijk adres) kan gevolgen hebben voor de inspectie. De gebruiker wordt hiervan via een melding op de hoogte gesteld.

De opvanglocatie van een OKO is een feitelijk adres, in Nederland (plaatje niet juist).

Het is mogelijk om de relatie tussen het Kindercentrum en de betrokken Houder te wijzigen. Bij het wisselen van een Houder dient altijd de datum van aanvang en beëindiging van het Houderschap aangegeven te worden.

In het detailscherm kunnen de gegevens per onderdeel gewijzigd worden. Het wijzigen is opgedeeld in twee delen die hieronder verder worden uitgewerkt:

1. •

   Wijzigen kerngegevens

2. •

   Wijzigen adresgegevens

Het wijzigen van de relatie met de gerelateerde OKO's gebeurt in het wijzigscherm van de OKO.

In dit scherm kan de gebruiker de kerngegevens aanpassen.

In dit scherm is het mogelijk om de adresgegevens van de Houder te wijzigen. Het wijzigen van de locatiegegevens (feitelijk adres) heeft geen gevolgen voor de inspectie.

In het detailscherm kunnen de gegevens per onderdeel gewijzigd worden. Het wijzigen is opgedeeld in een drietal onderdelen die hieronder verder worden uitgewerkt:

1. •

   Wijzigen kerngegevens en status VGO

2. •

   Wijzigen Gastouder en adresgegevens

3. •

   Wijzigen adresgegevens VGO

4. •

   Wijzigen bemiddelingsrelatie GOB

In dit scherm kan de gebruiker de kerngegevens aanpassen. Daarnaast heeft de gebruiker de volgende opties:

1. •

   De administratieve status aanpassen: bij een status wordt altijd een reden en een begin- en einddatum van wijziging opgegeven. Daarnaast wordt de gebruiker via een meldign gewezen op de gevolgen van deze statuswijziging.

2. •

   Nieuw inspectierapport toevoegen: naast het uploaden van het inspectierapport worden een aantal kenmerken behorende bij het rapport ingegeven.

Via dit scherm kan de gebruiker de gegevens van de Gastouder en de bijbehorende adresgegevens wijzigen.

Via dit scherm kan de gebruiker de adresgegevens behorende bij de VGO wijzigen. De adresgegevens van de VGO zijn mogelijk gerelateerd aan de adresgegevens van de Gastouder. Hiermee moet rekening worden gehouden bij het wijzigen ervan.

Periodes van bemiddeling van één VGO bij één GOB mogen elkaar niet overlappen.

Periodes van bemiddeling van één VGO bij verschillende GOBs mogen elkaar wel overlappen; een VGO mag gelijktijdig bemiddeld worden door meerdere GOBs.

Via dit scherm kunnen de Gemeenten, de GGD's en de Inspectie van het Onderwijs rapportages uitdraaien over een vooraf gedefinieerde set aan gegevens. Ad-hoc informatie-overzichten zullen door de beheerorganisatie geleverd worden.

De volgende standaard overzichten kunnen worden geproduceerd:

1. 1

   Aantal OKO's per soort (KDV, BSO, GOB en VGO), op een bepaalde peildatum, per status en totaal, per gemeente of per GGD en totaal landelijk.

   Alleen vermelding van aantal.

2. 2

   Detailgegevens van OKO's per soort (KDV, BSO, GOB en VGO), op een bepaalde peildatum, voor één gemeente of voor één GGD.

   Vermelding van met naam, adres, aantal kindplaatsen en status.

Aanvullend hierop is het gewenst het aantal actieve houders te tellen.

Via het Publieksportaal kunnen de gegevens van het Landelijk Register door het publiekworden geraadpleegd. Het is niet mogelijk om gegevens te wijzigen. Het Publieksportaal is voor elke anonieme gebruiker (het publiek) toegankelijk.

De raadpleegfunctionaliteit van het Publieksportaal zal grotendeels hetzelfde zijn opgebouwd als de raadpleegfunctionaliteit van het Overheidsportaal. Het Publieksportaal zal echter (veel) minder gegevens tonen.

Dit hoofdstuk wordt niet verder uitgewerkt in het GFO.

De beheerinterface wordt gebruikt door daartoe bevoegde beheerders voor het uitvoeren van algemene beheertaken. De interface is afgeschermd. Alleen beheerders hebben toegang. Op basis van de toegekende autorisaties hebben beheerders toegang tot (gedeelten van) de afzonderlijke beheeronderdelen.

Het onderhouden van gegevens van een gemeente is opgedeeld in 3 onderdelen:

1. •

   Zoeken gemeente (7.1.1)

2. •

   Wijzigen gegevens gemeente (7.3.2)

3. •

   Toevoegen nieuwe gemeente (7.3.4)

De beheerder kan zoeken op een gemeente door de gemeentenaam in te typen. Vervolgens worden de zoekresultaten getoond en heeft de beheerder de optie om de details van de gemeente te wijzigen.

Via dit scherm kan de beheerder gegevens van een gemeente (bijvoorbeeld gemeentenaam, URL, adres, telefoonnummer; koppeling met GGD) wijzigen.

Het is niet mogelijk om via de gebruikersinterface een gemeente te verwijderen.

De beheerder heeft de mogelijkheid om een nieuwe gemeente aan te maken. Via een invulscherm krijgt de beheerder de mogelijkheid om een nieuwe gemeente in te voeren.

De beheerder kan de GGD selecteren uit een lijst en de details van deze GGD vervolgens wijzigen.

Via dit scherm kan de beheerder gegevens van een GGD wijzigen.

De beheerder heeft de mogelijkheid om een nieuwe GGD aan te maken. Via een invulscherm krijgt de beheerder de mogelijkheid om een nieuwe GGD in te voeren.

De beheerder kan zoeken op een gebruiker door de gebruikersnaam of de naam van de gebruiker in te typen. Vervolgens worden de zoekresultaten getoond en heeft de beheerder de optie om de details van de gebruiker te wijzigen.

Via dit scherm kan de beheerder gegevens van een gebruiker (bijvoorbeeld naam, gebruikersnaam, wachtwoord, e-mailadres) wijzigen.

Het is niet mogelijk om via de gebruikersinterface een gebruiker te verwijderen.

Via dit scherm is het mogelijk om door te klikken naar 'beheren autorisaties gebruiker'.

De autorisaties (rol) van een gebruiker kunnen op dit scherm worden ingesteld. Aangenomen wordt dat een gebruiker slechts kan worden toegewezen aan één rol.

De beheerder heeft de mogelijkheid om een nieuwe gebruiker aan te maken. Via een invulscherm krijgt de beheerder de mogelijkheid om een nieuwe gebruiker in te voeren. Na het invoeren van de gebruiker is het verplicht ook een autorisatieniveau te kiezen (7.3.3).

Dit document beschrijft het globaal functioneel datamodel. Het is onderdeel van het het globaal functioneel ontwerp (GFO) van het Landelijk Register Kinderopvang.

Het GFO is géén levend document. Het wordt na de fase 'globaal functioneel ontwerp' bevroren. Wijzigingen op het datamodel worden gedocumenteerd in het DFO datamodel.

Het globaal functioneel datamodel beschrijft de gegevens die nodig worden geacht voor ondersteuning van de gewenste functionaliteit.

1. •

   Het is een middel om te toetsen of wordt voldaan aan de gewenste architectuur.

2. •

   Het vormt mede basis voor het Detail Functioneel Ontwerp (DFO), het Software Architectuur Document (SAD) en het testplan.

Het globaal functioneel datamodel bevat niet een volledige, gedetailleerde beschrijving inclusief alle attributen en constraints. Deze worden pas definitief vastgesteld in het detail FO. Het beschrijft slechts de gegevensstructuur van de in de functionele applicatiestructuur onderkende deelverzamelingen (per module, zie procesmodel).

Dit document is bedoeld voor:

1. •

   Software Architecten, om te toetsen of wordt voldaan aan de gewenste architectuur.

2. •

   Functionele Ontwerpers, als basis voor een verdere uitwerking van de hier beschreven gegevens(verzamelingen) in een detail functioneel datamodel.

Dit document beperkt zich tot het datamodel ter ondersteuning van functionaliteit die per 01/01/2010 gerealiseerd moet zijn.

Het volledige functioneel ontwerp wordt opgebouwd in twee stappen. Eerst wordt het Globaal functioneel ontwerp (GFO) opgesteld. Dit bestaat uit een procesmodel (dat de functionele applicatiestructuur beschrijft), een datamodel (dit document) en het interactie-ontwerp, evenals een prototype. Het Detail functioneel ontwerp (DFO) bevat de uitwerking van hetgeen in het GFO op hoofdlijnen is vastgesteld.

Het functioneel ontwerp baseert zich primair op de project start architectuur (PSA), en op de functionele requirements, beschreven in de geprioriteerde requirements list (PRL). Het functioneel ontwerp vormt samen met prototype en technisch ontwerp (SAD) de basis voor realisatie.

Hoofdstuk 2 beschrijft de functioneel onderkende classes per deelverzameling. Een aantal modules (zoals onderkend in het procesmodel) bevat géén eigen gegevens maar zijn omwille van de volledigheid toch opgenomen in dit hoofdstuk. Ontwerpbeslissingen aangaande het datamodel zijn vastgelegd bij de betreffende paragraaf.

Organisatie voor kinderopvang (OKO)

Kindercentrum (kinderdagverblijf of buitenschoolse opvang), gastouderbureau of voorziening voor gastouderopvang.

1. •

   Het LRK-ID wordt toegekend op het moment van vastlegging van de OKO in het register en kan niet worden gemuteerd.

Exploitatie

Periode van rechtsgeldige inschrijving. Er kunnen meerdere perioden per OKO worden vastgelegd.

1. •

   Periodes van exploitatie van één OKO mogen elkaar niet overlappen.

Status

De status van een OKO.

1. •

   De status ‘voorlopig ingeschreven’ is alleen van toepassing voor GOB's

2. •

   Een OKO in het register heeft ten alle tijden een status.

   Dit betekent:

   1. •

      Op het moment van vastlegging in het register moet de status worden vastgelegd.

   2. •

      De datum einde van de status is per definitie de datum voorafgaand aan de volgende status.

Naam OKO

Naam van de organisatie voor kinderopvang.

1. •

   Een OKO in het register heeft ten alle tijden een naam.

   Dit betekent:

   1. •

      Op het moment van vastlegging in het register moet de naam worden vastgelegd.

   2. •

      De datum einde van de naam is per definitie de datum voorafgaand aan de volgende naam.

   3. •

      De vroegste datum aanvang is gelijk aan de vroegste datum aanvang van de status van de OKO.

Adres OKO

Het adres waar de opvang plaats vindt. Niet van toepassing voor GOB; het adres van een GOB is het adres van de houder van het GOB.

1. •

   Een OKO (anders dan een GOB) moet altijd een opvangadres hebben.

2. •

   Het adres (als eigenschap van de OKO) kan niet wijzigen. Mutatie is alleen mogelijk in administratieve zin (correctie van foutieve invoer).

3. •

   Indien indicatie adres van houder = 'ja', dan is opvanglocatie leeg (en niet muteerbaar);

4. •

   indien indicatie adres van houder = 'nee', dan is opvanglocatie verplicht.

5. •

   Opvanglocatie is een feitelijk adres.

Bereikbaarheid

Contactgegevens van de OKO. Deze worden niet vastgelegd per periode; alleen de actuele gegevens worden onderhouden.

1. •

   Correspondentieadres kan een feitelijk adres, een postadres of een buitenlands adres zijn.

Kindercentrum (KC)

Is een soort OKO.

Buitenschoolse opvang (BSO)

Is een type KC.

Kinderdagverblijf (KDV)

Is een type KC.

Gastouderbureau (GOB)

Is een soort OKO.

Een organisatie die gastouderopvang tot stand brengt en begeleidt en door tussenkomst van wie de betaling van ouders aan gastouders geschiedt.

Voorziening voor gastouderopvang (VGO)

Is een soort OKO.

Kinderopvang:

1. a.

   die plaatsvindt door tussenkomst van een geregistreerd gastouderbureau;

2. b.

   die plaatsvindt in een gezinssituatie door een ander dan degene die als ouder op grond van artikel 5, eerste lid, aanspraak kan maken op een kinderopvang toeslag onderscheidenlijk een tegemoetkoming of diens partner;

3. c.

   waarbij de houder in totaal niet meer dan één voorziening voor gastouderopvang exploiteert;

4. d.

   waarbij de opvang plaatsvindt op het woonadres van de gastouder of op het woonadres van een van de ouders

Bemiddelingsrelatie

Relatie die aangeeft dat een VGO gedurende een bepaalde periode is aangesloten bij een GOB.

1. •

   Periodes van bemiddeling van één VGO bij één GOB mogen elkaar niet overlappen.

2. •

   Periodes van bemiddeling van één VGO bij verschillende GOBs mogen elkaar overlappen; een VGO mag gelijktijdig bemiddeld worden door meerdere GOBs.

3. •

   Geen beperkingen t.a.v. status van VGO en/of GOB.

4. •

   De bemiddelingsrelatie tussen GOB en VGO mag alleen onderhouden worden door de gemeente van de VGO.