Datum publicatie	Organisatie	Jaargang en nummer	Rubriek
28-05-2010 09:00	Ministerie van Onderwijs, Cultuur en Wetenschap	Staatscourant 2010, 8105	Besluiten van algemene strekking

Regeling van de Minister van Onderwijs, Cultuur en Wetenschap van 23 april 2010, nr. WJZ/205991 (2717), houdende wijziging van de Regeling Wet kinderopvang in verband met het vervangen van de gemeentelijke registraties door het register kinderopvang en de initiële vulling van dat register, het vaststellen van het model gemeentelijk jaarverslag 2009 alsmede enkele ondergeschikte wijzigingen

De Minister van Onderwijs, Cultuur en Wetenschap,

Gelet op de artikelen 47a, 67 en 92a, tweede lid, van de Wet Kinderopvang en de artikelen 4, 6, derde lid en 14 van het Besluit registratie kinderopvang,

Besluit:

ARTIKEL I

De Regeling Wet kinderopvang wordt als volgt gewijzigd:

Het opschrift van paragraaf 3 komt te luiden:

Paragraaf 3. Regels inzake registratie van voorzieningen

De artikelen 5 tot en met 9 vervallen, met dien verstande dat zij van toepassing blijven binnen gemeenten welke nog niet zijn aangesloten op het register kinderopvang en voor de duur dat voor die gemeenten in dat register nog niet alle in artikel 8 van het Besluit registratie kinderopvang genoemde gegevens van alle in die gemeente gevestigde voorzieningen voor kinderopvang zijn opgenomen.

Direct voorafgaand aan paragraaf 4 worden drie artikelen ingevoegd, die luiden:

Artikel 9a. Formulier

Het formulier, bedoeld in artikel 4 van het Besluit registratie kinderopvang wordt, onderscheiden naar categorie voorziening en voor eerste inschrijvingen en wijzigingen, vastgesteld overeenkomstig de bij dit besluit gevoegde bijlagen 1a tot en met 1g.

Artikel 9b. Systeembeschrijving

De systeembeschrijving, bedoeld in artikel 6, derde lid, van het Besluit registratie kinderopvang, wordt vastgesteld overeenkomstig de bij dit besluit gevoegde bijlage 2.

Artikel 9c. Taken van de Dienst Uitvoering Onderwijs

1. Het dagelijks beheer van het register berust bij de directeur-generaal van de Dienst Uitvoering Onderwijs.
2. Gedurende de periode dat een gemeente nog niet is aangesloten op het register kinderopvang zomede nadien op verzoek van het college van burgemeester en wethouders verzorgt de directeur-generaal van de Dienst Uitvoering Onderwijs de invoer van de gegevens van die gemeente in dat register.

Artikel 12 wordt als volgt gewijzigd:

1. In het derde lid, wordt ‘Inspectie Werk en Inkomen’ vervangen door: Inspectie voor het Onderwijs.

2. In het vierde lid wordt achter het woord ‘bijlage’ een 3 geplaatst.

De bijlage bij de Regeling Wet kinderopvang zoals deze luidde tot de inwerkingtreding van dit besluit wordt aangeduid als Bijlage 3.

ARTIKEL II

1. Elk college van burgemeester en wethouders stelt uiterlijk 1 juni 2010 aan de directeur-generaal van de Dienst Uitvoering Onderwijs ter beschikking teneinde deze te doen opnemen in het register kinderopvang:
- a. de gegevens van de op de datum van terbeschikkingstelling in het gemeentelijk register opgenomen gastouderbureaus;
- b. de op die datum voorhanden aanvragen van gastouderbureaus alsmede
- c. de op die datum reeds gegeven beschikkingen aan gastouderbureaus welke nog niet in het gemeentelijk register waren opgenomen.
2. Elk college van burgemeester en wethouders draagt in de periode van 1 mei 2010 tot 15 september 2010 zorg voor de opneming in het register kinderopvang van de in die gemeente aanwezige kindercentra.

ARTIKEL III

Het bij deze regeling als bijlage 3 behorende model jaarverslag, bedoeld in artikel 12, vierde lid, wordt vervangen door het model gemeentelijk jaarverslag Wet kinderopvang 2009, zoals dat bij deze regeling is gevoegd.

ARTIKEL IV

1. Deze regeling treedt in werking met ingang van de dag na de dagtekening van de Staatscourant waarin deze regeling wordt geplaatst. De artikelen I en III werken daarbij terug tot en met 1 januari 2010.
2. Deze regeling vervalt met ingang van 1 januari 2011.

Deze regeling zal met bijlagen en toelichting in de Staatscourant worden geplaatst.

De Minister van Onderwijs, Cultuur en Wetenschap,

A. Rouvoet.

Projectstartarchitectuur Landelijk Register Kinderopvang

Een beschrijving van het systeemcomplex

Documenthistorie

Versie	Datum	Auteur	Opmerking	Status
0.1	19-08-09	K. Helmers	Eerste opzet op basis van de PSA GIR, met vooral een opzet voor wat waar moet.	Concept
0.2	24-08-09	K. Helmers	Eerste verwerking onderwijs-standaarden en toetsingskaders.	concept
0.3	07-09-09	K. Helmers	Eerste en te uitgebreide vulling van H6, Technische Architectuur inclusief review van EvdBerg en JPJ	concept
0.4	09-09-09	K. Helmers	H6 reviewklaar maken, overtollige plannignszaken etc. eruit. Eerste opzet hoofdstuk 1, 2 en 3 toegevoegd.	concept
0.5	17-09-09	V.Grafov E. Nuiten	Hoofdstukken 4 en 5 toegevoegd	concept
0.5 rev KH	17-09-2009	K. Helmers	Par. 6.6 eruit, commentaar Petro verwerkt op de paragrafen	concept
0.6	18-09-2009	V.Grafov E. Nuiten K. Helmers	Wijzigingen verwerkt	concept
0.7	18-09-2009	E. Nuiten	Hoofdstukken 2,3 en 4 bijgewerkt	concept
0.8	22-09-2009	V.Grafov E. Nuiten K. Helmers	Commentaar interne review vewerkt	concept
0.81	24-09-2009	K. Helmers	Redactieslag op lay-out. Begin van verwerking commentaar OCW (Bram Gaakeer) en GGD-N (Yvette Derks).	concept
0.82	01-10-2009	K. Helmers	Versie ten behoeve van ondersteuning parallel werken. Nog verder gegaan met het verwerken van commentaar op Hoofdstuk 6.	concept
0.9	06-10-2009	K. Helmers E. Nuiten V. Grafov	Commentaar op Hoofdstuk 6 verwerkt. Commentaar op Hoofdstukken 1 t/m 4 verwerkt Commentaar op Hoofdstuk 5 verwerkt Ontwerpbveslissingen als aparte document opgeleverd, commentaar verwerkt	concept
1.0	13-10-2009	V. Grafov	Opmerkingen GGD d.d. 12-10-2009 verwerkt. Opmerking Belastingdienst d.d. 13-10-2009 omtrent proactieve signaleringen verwerkt in de Ontwerpbeslissingen document v1.0 (toegevoegd).	Definitief
1.01	20-10-2009	K. Helmers	Aantal raadplegende ouders van 5.000.000 bijgesteld naar 1.000.000.	Definitief
1.02	26-10-2009	K. Helmers	Nar aanleiding van keuze voor ander web-frame-work: nu VOLLEDIG webrichtlijnen-compliant. Aangepast in H6.	Definitief

1. Inleiding

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.

1.1 Doelgroep

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.

1.2 Scope van dit document

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.

1.3 Leeswijzer

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.

1.4 Relatie met de andere architectuurdocumenten

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

1 Referentiearchitectuur sector Onderwijs [15];
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.

1.5 Relatie met andere documenten op lager niveau

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 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 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 Het Deploymentdocument beschrijft welke omgevingen gebruikt worden en hoe de opgeleverde applicatie of voorziening op deze omgevingen gedeployed moet worden.
4 Risicoclassificatie en beveiligingsplan.

1.6 Woordenlijst

Term	Definitie	Bron
BSN (burgerservicenummer)	Burgerservicenummer, bedoeld in artikel 1, onder b, van de Wet algemene bepalingen burgerservicenummer;	Nota van toelichting , versie 10 augustus 2009 (AMvB)
College	college van burgemeester en wethouders	AmvB, zie [3]
Gastouder	De natuurlijke persoon van 18 jaar of ouder die gastouderopvang biedt	Wet Kinderopvang gewijzigd voorstel d.d. 3 juni 2009 (WKo)
Gastouderbureau	Een organisatie die gastouderopvang tot stand brengt en begeleidt en door tussenkomst van wie de betaling van ouders aan gastouders geschiedt	WKo
Gastouderopvang	Kinderopvang: a. die plaatsvindt door tussenkomst van een geregistreerd gastouderbureau; 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 kinderopvangtoeslag onderscheidenlijk een tegemoetkoming of diens partner; c. waarbij de houder in totaal niet meer dan één voorziening voor gastouderopvang exploiteert; d. waarbij de opvang plaatsvindt op het woonadres van de gastouder of op het woonadres van een van de ouders;	WKo
Geregistreerde kinderopvang	Een in het landelijke register ingeschreven organisatie voor kinderopvang.	Wet Kinderopvang Art. 5
GGD	Een gemeentelijke gezondheidsdienst als bedoeld in artikel 14 van de Wet publieke gezondheid	WKo
Handelsregister	Handelsregister, bedoeld in artikel 2 van de Handelsregisterwet 2007;	AMvB
Houder	De rechtspersoon of natuurlijke persoon van 18 jaar of ouder die een kindercentrum, een voorziening voor gastouderopvang of een gastouderbureau exploiteert;	WKo
Handhaving	Handhaving richt zich op de vraag of burgers, bedrijven en overheden zich aan de gestelde regels houden. Het is daarbij gericht op repressief optreden. Deze repressie is de bevoegdheid om dwang uit te oefenen en vrijheden te beperken. Deze bevoegdheid wordt gebruikt voor het verzamelen van informatie of het opleggen van een sanctie.	BZK (2005) Kaderstellende visie op toezicht [14]
Inspectie	Het verzamelen van informatie over de vraag of een handeling of een vraag voldoet aan de eisen die daaraan door de wet worden gesteld en het vervolgens vormen van een oordeel op basis van de verkregen informatie.	BZK (2001) Kaderstellende visie op toezicht [13]
Kindercentrum	Een voorziening waar kinderopvang plaatsvindt, anders dan gastouderopvang;	WKo
Kinderopvang	Het bedrijfsmatig of anders dan om niet verzorgen en opvoeden van kinderen tot de eerste dag van de maand waarop het voortgezet onderwijs voor die kinderen begint;	WKo
Kinderopvangtoeslag	Een tegemoetkoming van het Rijk als bedoeld in artikel 2, eerste lid, onder j, van de Algemene wet inkomensafhankelijke regelingen in de kosten van kinderopvang;	WKo
NORA	Nederlandse Overheid Referentie Architectuur, zie [7]
Organisatie voor kinderopvang	Kindercentrum, gastouderbureau of voorziening voor gastouderopvang;	AMvB
Ouder	De bloed- of aanverwant in opgaande lijn of de pleegouder van een kind op wie de kinderopvang betrekking heeft, met dien verstande dat bij de beoordeling of sprake is van pleegouderschap een subsidie op grond van de Wet op de jeugdzorg buiten beschouwing blijft;	WKo
SoFi nummer (het sociaal-fiscaal nummer	Het sociaal-fiscaal nummer als bedoeld in artikel 2, derde lid, onder k van de Algemene wet inzake rijksbelastingen;	AMvB
Soort kinderopvang	Buitenschoolse opvang of dagopvang;	AMvB
Toetsingskader	Het geheel van normen die zijn ontleend aan wet- en regelgeving, algemene beginselen van behoorlijk bestuur, rechtspraak en professionele en maatschappelijk gangbare standaarden waaraan getoetst wordt.	http://www.iwiweb.nl/cgi-bin/as.cgi/0319000/c/start/file=/9319000/1f/j9vvgdedws2muq1/vgecd3qmz3y2
Toezicht	Toezicht is het verzamelen van informatie of een handeling of zaak voldoet aan de daaraan gestelde eisen, het oordelen daarover en het eventueel naar aanleiding daarvan interveniëren.	BZK (2005) Kaderstellende visie op toezicht
Toezichtskader	Beschrijving van werkwijze in het toezicht en het daarbij te hanteren toetsingskader voor een bepaalde sector, bijvoorbeeld de onderwijssector.	Website Ministerie OCW.

2 Achtergrond

2.1 Programmacontext

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.

2.2 Probleem en oplossing

2.2.1 Probleem

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:

• De fraudegevoeligheid van de huidige Toeslagen-regeling en de daarmee gepaard gaande extra uitgaven.
• 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:

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

2.2.2 Oplossing

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 Een operationeel Landelijk Register van geregistreerde kinderopvang-instanties conform de nieuwe wet per 1-1-2010.
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 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:

4 Ondersteuning van de kwaliteitsprocessen rondom dit register, zijnde het toezichtsproces, het handhavingsproces en de koppeling met de relevante Basisregistraties.
5 Ondersteuning voor de juiste managementinformatie ten behoeve van zowel eerste- als tweede-lijns 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)

2.3 Projectaanpak

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 Realiseer een Landelijk Register van geregistreerde kinderopvang-instanties conform de nieuwe wet per 1-1-2010.
2 Ontsluit dit register voor gebruik door ouders zodat ook zij inzicht hebben in de geregistreerde kinderopvang-instanties.

In een latere fase ook:

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.
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.
5 Borg dat het op te leveren geautomatiseerde deel van de oplossing de juiste managementinformatie levert aan de eerste- en tweede-lijns toezichthouders.

2.4 Kern van de oplossing

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?

• 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.
• Gemeenten zijn vervolgens verantwoordelijk voor het gegevensbeheer het Landelijk Register;
• Het publiek kan (een beperkte set van gegevens uit) het Landelijk Register raadplegen;
• 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.

3 Scope en uitgangspunten

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

3.1 Scope

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:

• Landelijk Register
• Overheidsportaal
• Publieksportaal

3.1.1 Processcope ondersteuning

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.

3.1.2 Koppelvlakken

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

1 Het koppelvlak met het Publieksportaal. Dit is een eenvoudig koppelvlak waarlangs gegevens geleverd worden als antwoord op door het publiek gestelde vragen.
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.

3.1.3 Externe systemen

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.

3.2 Uitgangspunten algemeen en ontwerpbeslissingen

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

• 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.
• De uitvoering van de Wet Kinderopvang en de AMvB [3] zijn uitgangspunt voor het ontwerp van het LR.
• De ontwerpbeslissingen zijn gebaseerd op afspraken met de opdrachtgever OCW en de belanghebbenden. De ontwerpbeslissingen worden in een los document beschreven.

3.3 Kaders en standaarden

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

Nr	Omschrijving fundamenteel NORA principe	Vertaling naar Projectarchitectuur
1	Diensten via internet: organisaties in het publieke domein verlenen hun diensten aan burgers, bedrijven en maatschappelijke instellingen via het internet (elektronisch loket) en stimuleren het gebruik van dit kanaal.	Door het inrichten van het Publieksportaal wordt informatie verstrekt aan het publiek. De ondersteuning van de aanvraag vindt onder verantwoordelijkheid van de gemeente plaats. Het project LR-GIR KO laat dit buiten beschouwing. Het LR bevat dus geen proces informatie over de behandeling van aanvragen.
2	De bestaande kanalen zoals post, telefoon en balie blijven beschikbaar, zodat burgers, bedrijven en maatschappelijke instellingen gebruik kunnen maken van het kanaal van hun keuze	Dit blijft buiten beschouwing van het onderhavige project , het richt zich primair op de ICT.
3	Overheidsinstellingen geven een helder, vindbaar beeld van de diensten en producten die burgers, bedrijven en maatschappelijke organisaties van hen kunnen afnemen. Daartoe zijn hun elektronische loketten benaderbaar via landelijke ingangen zoals de website www.overheid.nl (één loket gedachte ‘no wrong door’)	Wettelijk is bepaald welke gegevens getoond gaan worden via het Publieksportaal. Met in achtneming van de privacyrichtlijnen zullen gegevens verstrekt worden om invulling te geven aan de ‘no wrong door’ gedachte.
4	Overheidsinstellingen werken samen om diensten te leveren, one-door-shopping	De informatieverstrekking is wettelijk vastgesteld. De gemeente zal voor de dienstverlening zorgen voor de aanvraagprocessen, de informatieverstrekking vindt plaats via het Publieksportaal. Daarop ligt de focus van het project. De wijze waarop het Publieksportaal wordt gekoppeld aan bestaande gemeentelijke of overheidskanalen is nog niet vastgesteld.
5	Burgers, bedrijven en maatschappelijke instellingen beschikken over één identiteit die bruikbaar is voor alle contacten met organisaties in het publieke domein die afhankelijk van de soort dienstverlening ook nodig is en gevraagd moet worden.	In de LR wordt gebruik gemaakt van gegevens uit de basisregistraties GBA en NHR. Er wordt vanuit gegaan dat de gemeenten de identificerende kenmerken zoals bepaald in de wet opnemen in de Landelijke registratie.
6	Uitvoeren van controles op vlotte dienstverlening	Dit valt buiten de scope.
7	Organisaties in het publieke domein kennen een transparante en toegankelijke klachten- en bezwarenprocedure	Dit valt buiten de scope.
8	Eénmaal uitvragen van gegevens, meermalen gebruiken; de organisaties in het publieke domein zullen burgers en bedrijven niet opnieuw om gegevens vragen die bij de overheid bekend zijn.	Het aanvraagproces valt buiten scope. Wel zal voor registratie in het landelijk register gecontroleerd worden of alle gegevens voorhanden zijn, zodat deze voor de verdere processen beschikbaar zijn.
9	Organisaties in het publieke domein streven naar zo laag mogelijke administratieve lasten en een zo laag mogelijke regellast voor burgers, bedrijven en maatschappelijke organisaties.	Dit valt buiten scope van het project . Wel wordt zoveel mogelijk gekeken naar hergebruik van gegevensbronnen.
10	Organisaties in het publieke domein zorgen voor een eenvoudige regelgeving, in omvang beperkt, onderling consistent en goed controleerbaar en handhaafbaar.	Dit valt buiten scope.
11	Organisaties geven aan op welke momenten en stadia in het dienstverleningsproces doorlopen worden en streven daarbij naar zo kort mogelijke doorlooptijden.	Dit valt buiten scope.
12	Organisaties geven inzicht in de status van de lopende dienstverleningprocessen.	Dit valt buiten scope.
13	Organisaties in het publieke domein geven burgers, bedrijven en maatschappelijke instellingen inzicht in de status van voor hen lopende dienstverleningsprocessen (transparante, traceerbare dienstverleningsprocessen)	Door toegang te bieden tot de informatie over de kinderopvang en inzicht te bieden in de kwaliteit (inspectierapporten) wordt transparantie gerealiseerd via het Publieksportaal.
14	Organisaties in het publieke domein zorgen dat zij naar burgers, bedrijven en maatschappelijke instellingen periodiek verantwoording afleggen over de kwaliteit van de gerealiseerde dienstverlening	Dit valt buiten scope.
15	Organisaties in het publieke domein maken zichtbaar wat zij doen, welke besluiten zij nemen en welke gegevens zij hebben en gebruiken en wat hun werkwijze is.	Via het Publieksportaal wordt alle informatie verstrekt over de Organisatie voor Kinderopvang zoals bepaald is in de Wet Kinderopvang. Procesinformatie over en besluit- en adviesvorming behoort niet tot de gegevens die getoond verstrekt worden.
16	Organisaties in het publieke domein attenderen burgers en bedrijven op voor hen relevante diensten (pro-actieve dienstverlening) maar bieden ruimte voor eigen regie en verantwoordelijkheid door burgers en bedrijven op de feitelijke afname van diensten (zelfwerkzaamheid). Daarbij verstrekken organisaties begrijpelijke informatie, bij voorkeur geïndividualiseerd over rechten, plichten en mogelijkheden voor burgers en bedrijven.	Dit valt buiten scope.
17	Organisaties in het publieke domein organiseren zich als een onderdeel van een integraal opererende en als eenheid optredende overheid, die haar handelen naar burgers, bedrijven en maatschappelijke instellingen consistent en betrouwbaar	Dit valt buiten scope.
18	Organisaties in het publieke domein gebruiken gegevens die accuraat, actueel en volgens wettelijke normen beveiligd zijn	Dit wordt gerealiseerd door beveiligingsmaatregelen in de ICT-voorzieningen en identificatie en autorisatiemaatregelen.
19	Gebruik waar mogelijk generieke componenten. Organisaties in het publieke domein streven er naar om beschikbare gemeenschappelijke voorzieningen te gebruiken, als deze op de punten functionaliteit, beveiliging en kosten gelijkwaardig zijn aan indi-viduele voorzieningen	Het LR is een nieuwe voorziening. Wel wordt op termijn rekening gehouden met de basisregistraties, gestandaardiseerde koppelvlakken en de reeds ontwikkelde voorzieningen ter ondersteuning van het inspectieproces.
20	Standaardiseer en optimaliseer interne bedrijfsvoering	Dit valt buiten scope.

Verder wordt gebruikt gemaakt van de volgende standaarden:

• UML voor gegevensmodellering

4 Bedrijfsarchitectuur

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.

4.1 Inleiding

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:

• registreren
• inspecteren
• handhaven
• 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.

4.2 Architectuureisen

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:

Status	Omschrijving
De jure	Deze principes vloeien rechtstreeks voort uit bestaande wet- en regelgeving of besluiten van het Kabinet of College Standaardisatie
E-overheidsprincipe	Het volgen van deze principes is wenselijk omdat deze principes zich richten op de onderlinge samenhang die door de realisatie van de Elektronische overheid nodig is.
Intern principe	Een intern principe is gericht op de interne informatiehuishouding van instanties. Het volgen van deze adviezen is wenselijk doch, uit het oogpunt van realisatie van de Elektronische overheid niet noodzakelijk.

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

Nr	Status	Nr fundamenteel principe	Omschrijving
5.1.1	De jure	P15	Overheidsorganisaties zijn soevereine deelnemers binnen de e-overheid
Elke overheidsorganisatie heeft wettelijk bepaalde verantwoordelijkheden, taken (functies en bevoegdheden.
De rol van de overheidsorganisaties in het aandachtsgebied van de kinderopvang, zoals vastgelegd in de Wet Kinderopvang is bepalend voor de autorisaties die worden ingeregeld in de voorzieningen.

5.1.2	E-overheidsprincipe	P15	De functies van overheidsorganisaties zijn inzichtelijk
M.a.w. het is precies duidelijk welke overheidsorganisatie welke functie(s) vervult.
Op basis van de wettelijke taken, zoals bepaald in de Wet Kinderopvang, is bepaald welke autorisaties, verantwoordelijkheden de organisaties hebben.

5.1.3	E-overheidsprincipe	P17	Overheidsorganisaties werken binnen de e-overheid samen
Het programma Andere Overheid roept op te komen tot betere samenwerking tussen de verschillende bestuurslagen. Moderne informatietechnologie maakt vervulling van deze wens eenvoudiger. Het gezamenlijk leveren van gecombineerde, elektronische diensten aan burgers en bedrijven kan deels gebaseerd worden op bestuurlijke arrangementen. Voor het overige zullen soms wetswijzigingen nodig zijn.
Door de inrichting van een gemeenschappelijke (landelijke) registratie van alle vormen van kinderopvang en het centraal verstrekken van identificerende nummers wordt de interoperabiliteit in de kinderopvangketen adequaat gefaciliteerd door ICT.

5.1.4	E-overheidsprincipe	P17	De architectuur opbouw van overheidsorganisaties is gericht op het verlenen van diensten aan burgers en bedrijven via meerdere kanalen, evenals op onderlinge samenwerking door het koppelen van dienstverleningsprocessen en het gezamenlijk gebruiken van gegevens.
De invoering van dienstverlening via meerdere kanalen (onder meer Internet, telefoon, post en balie), is vrij ver gevorderd. Deze beweging is ook beïnvloed door de één-loket-gedachte in de jaren ’90, In veel organisaties wordt gesproken over scheiding van frontoffice en backoffice. Er zijn veel definities van het begrip ‘frontoffice’. In de NORA volstaan we met de simpele definitie: Het frontoffice is de plaats waar de contacten plaatsvinden met de klant. In het frontoffice worden dus ook dienstverleningsprocessen uitgevoerd, er kunnen zowel ambtenaren als computers worden ingezet; er kunnen zowel routinematige, eenvoudige werkzaamheden plaatsvinden, als hoogwaardige, specialistische. Het frontoffice is de zone waarbij de klant aanwezig is; fysiek of via ICT voorzieningen als PC of telefoon.
Op basis van de wettelijke taken, zoals bepaald in de Wet Kinderopvang, is bepaald welke gegevens via het Publieksportaal verstrekt mogen worden, op een zodanige wijze dat het publiek op één plaats toegang krijgt tot informatie over geregistreerde kinderopvang en over de kwaliteit ervan. De dienstverlenende processen zijn buiten beschouwing van het deelprogramma ICT .

5.1.5	E-overheidsprincipe	P4, P17	Overheidsorganisaties werken samen aan diensten aan burgers en bedrijven op basis van een service georiënteerde architectuur.
Dit principe vormt de basis van de samenwerking tussen overheidsorganisaties. Organisaties maken afspraken om elkaar te helpen met verlenen van diensten aan burgers en bedrijven. De onderlinge hulp bestaat uit services: elke organisatie levert vanuit zijn kernfunctie services aan andere organisaties.
Door het verlenen van autorisatie wordt toegang geboden tot informatie ten einde de communicatie tussen organisaties te realiseren. De wijze waarop uitvoerende processen interacteren valt buiten scope van dit project. De servicegeörienteerde architectuur wordt op termijn mogelijk gedeeltelijk ingericht door bijvoorbeeld de aansluiting op de landelijke registraties.

5.2.1.14	De jure	P5	Burgers krijgen door middel van het burgerservicenummer een digitale, unieke identiteit. Dit BSN dient maximaal door overheidsorganisaties te worden toegepast.
Met het burgerservicenummer (BSN) kunnen persoonsgebonden gegevens doelmatig en, indien met het oog daarop passende voorzieningen zijn getroffen, betrouwbaar uitgewisseld worden. Het BSN dient – via tussenkomst van DigiD en/of PKI-overheid – gebruikt te worden bij het verlenen van diensten aan individuele burgers via websites van de overheid. Daarnaast kan het BSN een belangrijke rol spelen in het op uniforme wijze toegankelijk maken van uiteenlopende administraties (ook tussen en binnen organisaties). Daarbij dienen de regels voortvloeiend uit de Wet Bescherming Persoonsgegevens in acht genomen te worden
Uitgangspunt in het project LR-GIR KO is dat gemeenten het BSN vastleggen indien het van toepassing is, waarbij vooraf geverifieerd is dat het BSN juist is. Via het Publieksportaal wordt geen BSN getoond, het BSN wordt wel toegepast bij de informatieuitwisseling tussen overheidsorganisaties in de (keten)processen in het kader van de uitvoering van de Wet Kinderopvang.

5.2.1.15	De jure	P5	Bedrijven en instellingen krijgen door middel van het bedrijven- en instellingennummer een digitale, unieke identiteit.
Het KvK nummer dient gebruikt te worden bij het verlenen van individuele diensten aan bedrijven en instellingen via websites van de overheid, inclusief de OverheidsTransactiePoort (OTP). Daarnaast kan het KvK-nr (BIN) een belangrijke rol spelen in het op uniforme wijze toegankelijk maken van uiteenlopende administraties. Daarbij dienen de regels voortvloeiend uit de Wet Bescherming Persoonsgegevens in acht genomen te worden.
Uitgangspunt in het project LR-GIR KO is dat gemeenten het het BIN-nummer vastleggen indien het van toepassing is, waarbij vooraf geverifieerd is dat het nummer juist is. In de wet is bepaald welke gegevens uit het Handelsregister getoond wordt via het Publieksportaal. Het BIN wordt wel toegepast bij de informatieuitwisseling tussen overheidsorganisaties in de (keten)processen in het kader van de uitvoering van de Wet Kinderopvang.

4.3 Organisatie

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

• Ministerie van Onderwijs, Cultuur en Wetenschappen (OCW):
- − De uitvoering van de Wet Kinderopvang valt onder ministeriële verantwoordelijkheid van de Minister van OCW.
  - ○ Het LR valt onder verantwoordelijkheid van de Minister van OCW
• GGD
- − 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.
  - ○ De GGD is verantwoordelijk voor de uitvoering van de inspecties.
• Gemeente:
- − 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.
  - ○ De gemeente is verantwoordelijk voor de wettelijk bepaalde gegevens in het LR.
• Inspectie van het Onderwijs (IvhO)
- − 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.
  - ○ De IvhO is verantwoordelijk voor het tweedelijns toezicht.
• Belastingdienst (BD)
- − 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.
  - ○ De BD is verantwoordelijk voor uitvoering van de correcte naleving van de Wet Inkomensafhankelijke voor de kinderopvangtoeslag.
• Gastouderbureau (GOB): zie woordenlijst.
- − 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.

• Gastouder (GO): zie woordenlijst
• Publiek: de personen die anoniem informatie willen ontsluiten over kinderopvang.

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

• Vereniging Nederlandse Gemeenten (VNG)
- − 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.
• GGD-Nederland
- − 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.
• beheerorganisatie van voorzieningen (nog vast te stellen)

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

• 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.
- − 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.
- − 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.
• 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.

4.4 Processen

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 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 inspecteren:: het uitvoeren van kwalitatieve controles op de correcte naleving van de wettelijk bepaalde criteria in de Wet Kinderopvang;
3 handhaven:: uitschrijven van aanwijzingen naar aanleiding van vastgestelde tekortkomingen in de kinderopvang en het uitvoeren van controle op de naleving daarvan.
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:

• 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.
• Inspecteren wordt in betreffende gemeente uitgevoerd door de GGD waarvan de directeur is aangewezen als toezichthouder.
• 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.

4.4.1 Positionering ten opzicht van NORA paradigma

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.

NORA-niveau	Landelijk Register
Ketenproces of interactieperspectief	Registreren nieuwe kinderopvang Wijzigen registratie kinderopvang
Bedrijfsproces	Aanvraag, behandelen, inspecteren, besluiten en registreren, handhaven, inzicht verschaffen.
Werkproces	Niet diepgaand uitgewerkt ivm prog. Implementatie wel worden bedrijfsfuncties genoemd.
Processtap	n.v.t.
Handeling	n.v.t.

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

4.4.2 Ketenproces Registreren nieuwe kinderopvang

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.

4.4.2.1 Procesdecompositie binnen ketenproces Registreren nieuwe kinderopvang

De bedrijfsprocessen zijn een decompositie van de ketenprocessen.

1 Aanvragen voor registratie in LR
2 Ontvangen aanvraag voor registratie
3 In behandeling nemen aanvraag voor registratie
4 Besluiten over aanvraag voor registratie
5 Verwerken van wijzigingen
6 Ontvangen klacht
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:

4.4.2.2 ICT-ondersteuning functies tbv Registreren

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 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 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 Vastleggen voorlopige gegevens van nieuwe org. voor kinderopvang:: de wettelijke vastgestelde gegevens worden vastgelegd.
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 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 Controleren wijzigingen:: bij het behandelen van eventuele meldingen van wijzigingen kan raadplegen van het LR noodzakelijk zijn.
7 Verwerken van wijzigingen:: wijzigingen in het LR worden met behulp van daarvoor bestemde functionaliteiten worden verwerkt.
8 Bepalen vervolgacties:: aan de hand van wijzigingen of klachten kan het wenselijk zijn het LR te raadplegen.
9 Ontvangen van klacht m.b.t. kinderopvang:: bij het ontvangen van een klacht kan het noodzakelijk zijn het LR te raadplegen.
10 Behandelen klacht mbt kinderopvang:: voor het behandelen van een klacht kan het noodzakelijk zijn het LR te raadplegen.
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 Vastleggen inspectierapporten:: De gemeente legt de door de GGD ontvangen inspectierapporten vast en maakt deze toegankelijk zoals in de wet bepaald is.
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 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 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.

4.4.3 Ketenproces Wijzigen registratie kinderopvang

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

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 De gemeenten krijgen via de GBA en NHR wijzigingen door inzake gegevens over kinderopvang;
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.

Afbeelding 5: Wijzigen van kinderopvanggegevens

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.

4.4.3.1 Procesdecompositie binnen ketenproces Wijzigen registratie kinderopvang

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.

4.4.3.2 Procesdecompositie binnen ketenproces Wijzigen registratie kinderopvang

4.4.4 Functionele decompositie Inspecteren, Handhaven en Gebruiken

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.

4.5 Diensten en services

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).

4.5.1 Diensten

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

• faciliteit voor kinderopvang om zich in te laten schrijven in het landelijk register
• faciliteit voor informatieverstrekking over geregistreerde kinderopvang
• faciliteit voor informatieverstrekking over kwaliteit van de kinderopvang

4.5.2 Geleverde services

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

• faciliteit voor kinderopvang te registreren voor gemeenten
• faciliteit om wijzigingen van gegevens over kinderopvang te registreren
• landelijke informatie te verstrekken over geregistreerde kinderopvang voor afnemende overheidsorganisaties.
• Mogelijkheid om gegevens uit het LR te bevragen t.b.v. toezicht.
• Op basis van de zoekcriteria van de gebruiker van het Publieks- of Overheidsportaal worden de juiste gegevens getoond aan de gebruiker.
• Mogelijkheid om historische gegevens uit het LR te raadplegen via het Overheidsportaal voor geautoriseerde gebruikers.

4.5.3 Gebruikte services

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

5 Informatiearchitectuur

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.

5.1 Architectuuropzet

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

• Landelijke Register (LR).
• Publieksportaal (PP) voor de burgers.
• 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

Doelgroepen	Services
Doelgroepen	Raadplegen alle gegevens van organisatie voor kinderopvang en houders	Registreren van nieuwe organisaties voor kinderopvang en houders	Wijzigen gegevens van organisaties voor kinderopvang en houders	Genereren van overzichten van organisaties voor kinderopvang op basis van vooraf opgestelde criteria t.b.v. Management informatie
Gemeenten	Ja	Ja	Ja	Ja
Data Entry	Ja	Ja	Ja	Nee
GGD	Ja	Nee	Nee	Ja
OCW	Ja	Nee	Nee	Ja
IvhO	Ja	Nee	Nee	Ja
Belastingdienst	Ja	Nee	Nee	Nee

Het aantal afzonderlijke gebruikersaccounts per doelgroep wordt nader bepaald.

5.2 Architectuurplaat

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).

Afbeelding 6: ICT componenten van oplevering 01-01-2010

5.3 Architectuureisen

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.

5.3.1 Relevante principes Referentiearchitectuur Onderwijs

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:’

Afbeelding 7: Referentiearchitectuur Onderwijssector

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

OCW principe			Vertaling
Binnen de Referentiearchitectuur wordt onderscheid gemaakt tussen de volgende portalen:			Publieksportaal levert de volgende diensten aan burgers:
• Portaal onderwijsdeelnemers • Bij het portaal onderwijsdeelnemers kan worden gedacht aan het leveren van de volgende diensten:			– Opvragen van informatie over de ingeschreven organisaties voor kinderopvang in het LR, inspectierapporten en beperkte historische gegevens van de uitgeschreven organisaties voor kinderopvang
	○ Opvragen informatie (Bijvoorbeeld prestaties van scholen).
• Portaal onderwijsinstelling			Overheidsportaal levert de volgende diensten aan de organisaties die betrokken zijn bij de uitvoering van Wet Kinderopvang:
• Dit portaal wordt gebruikt om diensten aan onderwijsinstellingen te leveren.
• Hierbij kan gedacht worden aan de volgende diensten:
	○ Opvragen informatie over onderwijsinstellingen		– Opvragen van informatie over de organisaties voor kinderopvang en hun houders;
	○ Aanleveren van gegevens ○ Voor onderwijsinstellingen die gegevens niet aanleveren vanuit het schoolsysteem wordt functionaliteit beschikbaar gesteld om dit via een portaal te doen. ○ Opvragen informatie over proces ○ Informatie moet verstrekt kunnen worden over de dienstverleningsprocessen (aanleveren brongegevens, bevoorschotten, bekostigen, betalen, verantwoorden en bezwaarprocedures). Hierbij wordt onderscheid gemaakt tussen:

			– Beheerfunctionalitiet voor de gegevens over organisaties voor kinderopvang aan verantwoordelijke instellingen (Gemeenten);

			– Opvragen van informatie over de status van de organisaties voor kinderopvang inclusief de bijbehorende tijdslijnen
		– Gehanteerde procedure met tijdlijnen
		– Status van proces
		– Resultaat van proces
		– Concrete voorbeelden zijn geregistreerde brongegevens, verleend voorschot, definitieve beschikking, uitgekeerde betaling, vastgestelde jaarrekening.
Externe organisaties die toegang willen tot de openbare database kunnen beschouwd worden als een aparte doelgroep. Zoals het er nu uitziet willen zij echter geen portaalfunctionaliteit, maar willen ze automatische uitwisseling van gegevens middels services.			Functionaliteit van de LR wordt ontsloten via services. Diensten die via het Publieksportaal en/of Overheidsportaal aangeboden worden, maken gebruik van deze services.

5.3.2 Relevante NORA principes

5.3.2.1 Applicaties

6.1.1.2	Intern principe	P20	Applicaties voeren services van slechts één functioneel domein uit.
Voor elke dienst, die geleverd wordt aan burgers en bedrijven draagt één overheidsorganisatie de eindverantwoordelijkheid. Combinatie van deze principes levert het beeld op van helder gedefinieerde functionele domeinen, die via services met elkaar samenwerken aan de levering van producten en diensten aan burgers en bedrijven. De overheid als een netwerk, bestaande uit vele organen, die via koppelingen aan elkaar services verlenen. Het is duidelijk welke services een organisatie levert
Dit principe vertaal zich in verdeling van het systeem in drie componenten: het Landelijk Register (LR), Publiekstportaal (PP) en Overheidsportaal (OP)

6.1.1.3	Intern principe	P20	Organisaties en applicaties die in verschillende functionele domeinen werkzaam zijn, werken met elkaar samen op basis van services.
Dit principe is hierboven toegelicht (zie 6.1.1.2).
Deze principe vertaalt zich in de architectuuropzet van het systeemcomplex, waarbij afzonderlijke componenten (PP en OP) gebruik maken van de services die geboden worden door het LR.

6.1.2.2	De jure	P21	Websites van overheidsorganisaties zijn ontwikkeld en ingericht conform de ‘overheidswebrichtlijnen’.
Op 30 juni 2006 heeft de Ministerraad het ‘Besluit kwaliteit Rijksoverheidswebsites’ vastgesteld. In de bijlage van het Besluit is aangegeven aan welke eisen nieuwe websites van de rijksoverheid bij oplevering dienen te voldoen. Deze eisen zijn gelijk aan alle huidige Webrichtlijnen, aangevuld met de eis: ‘Bouw een website volgens de Web Content Accessibility Guidelines (WCAG1.0) van het W3C’.
Dit principe wordt in de ontwerpfase van Publieksportaal en Overheidsportaal vertaald in concrete eisen voor te bouwen Websites.

5.3.2.2 Gegevens

6.2.3.3	Intern principe	P18	Gegevens, berichten en documenten worden voorzien van metagegevens ten behoeve van beheer.
Binnen e-overheid maken ketenpartners afspraken over de metagegevens die nodig zijn voor beheer, rekening houdend met de richtlijnen van Archiefwet en NEN-ISO 15489 (zodra deze definitief is). Hierbij wordt o.a. aangegeven hoe lang gegevens bewaard moeten worden en wanneer ze vernietigd cq. overgedragen moeten worden ( aan het Nationaal Archief).
In het LR wordt aan deze eis voldaan door informatie over de eigenaar van gegevens en de geldigheid van de gegevens te registreren.

6.2.3.4	E-overheidsprincipe	P18	Elk gegeven kent een eigenaar en een beheerder.
Binnen de e-overheid is van elk gegeven duidelijk wie de eigenaar en wie de beheerder is. Om een ‘single point of control’ te krijgen op gegevens die door meerdere organisaties gebruikt worden, kent elk gegeven een eigenaar. De rollen van eigenaar en beheerder kunnen aan één partij toevallen, maar een eigenaar kan ook een andere partij opdragen zijn gegevens volgens ordentelijke principes te beheren. Het eigenaarschap laat onverlet dat er (structureel) overleg gevoerd wordt met meerdere gebruikers van gegevens, teneinde de gebruikswaarde van gegevens voor zoveel mogelijk partijen te optimaliseren.
Deze eis wordt geadresseerd in de autorisatiemodel van het Landelijke Register

6.2.4.4	E-overheidsprincipe	P17	Waar haalbaar onderscheidt een semantisch model expliciet objecten en gebeurtenissen.
Klassiek ligt in informatieprocessen van de overheid grote nadruk op registratie en opslag. In dergelijke gevallen volstaan vaak puur statische semantische modellen (zoals ERD diagrammen). Een transitie naar een dienstverlenende overheid vraagt echter om pro- en reactiviteit van processen en diensten. In een dergelijke omgeving moeten semantische modellen ook gebeurtenissen kunnen uitdrukken.
Aan deze eis is voldaan door informatie over de gebeurtenissen in de levenscyclus van een Organisatie voor Kinderopvang op te nemen in de vorm van statussen.

6.2.4.5	E-overheidsprincipe	P18	De definitie en taxonomie van gegevens die zijn opgenomen in nationale basisregistraties zijn leidend.
Binnen e-overheid worden bij gegevens die in de nationale basisregistraties voorkomen de definitie en taxonomie gevolgd van de basisregistratie waar het betreffende gegeven in voorkomt.
Aan deze eis is voldaan door semantisch model van het Stelsel van basisregistratie als uitgangspunt te nemen bij het opstellen van de logisch gegevensmodel van het Landelijke Register.

6.2.6.5	Intern principe	P20	Objecten worden op een systematische wijze beschreven.
Van een objecttype wordt het volgende in kaart gebracht: • Definitie • Generieke eigenschappen (waaraan kun je zien of een object tot deze soort behoort?) • Identificerende eigenschappen (hoe duid je er één aan?) • Verifiërende eigenschappen (waaraan kun je herkennen dat het er een is dat je al kent?) • Relaties en rolnamen • Populatie • Toelichting • Voorbeelden
Aan deze eis is voldaan door uniform sjabloon aan te houden als uitgangspunt bij beschrijving van de gegevens.

5.4 Gegevens

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.

5.4.1 Ontwerpbeslissingen gegevensmodel

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

Nr	Ontwerpbeslissing	Korte toelichting/verantwoording
G01	Alle Organisaties voor kinderopvang, waaronder ook specifieke vormen van opvang (Buitenschoolseopvang en Kinderdagverbijlf) worden als afzonderlijk objecten opgenomen in het Register	Hoewel in de Wet gesproken wordt over drie soorten van organisaties (Kindercentrum, Voorziening voor gastouderopvang en Gastouderbureau), is Kinderopvang verder gesplitst. Deze splitsing is noodzakelijk om specifieke situaties die afzonderlijk geïnspecteerd kunnen worden en verschillende aanvang en/of einddatum van exploitatie kunnen hebben, te kunnen identificeren.
G02	Alle Organisaties voor kinderopvang worden voorzien van een unieke nummer die in het LR wordt gegenereerd. Dit nummer moet 11-proef zijn.	Uitgifte van de nummer is geregeld per wet. Beschikking over dit nummer is vereist voor de toeslag aanvragen. Hoewel Wet niets over de vorm van het nummer zegt, is het voor de Belastingdienst wenselijk om nummers foutbestendig te kunnen maken. Een van de mechanismen hiervoor is 11-proef.
G03	Gegevensmodel biedt de mogelijkheid om kenmerken van Basisregistratie objecten op nemen in het LR	Hoewel de Wet en de AMvB slechts het BSN of KvK nummers benoemen voor opname in het Register, worden alle gegevens die aan de houders worden uitgevraagd, vastgelegd in het LR. Dit is o.a. noodzakelijk uit de performance overwegingen bij zoekopdrachten in de portalen en wegens het feit dat koppelingen met NHR en GBA nog niet gerealiseerd zijn.
G04	Bemiddelingrelaties liggen tussen Gastouderbureau’s en Voorzieningen voor gastouderopvang	In de Wet en AMvB teksten worden drie termen gebruikt: – Voorziening voor gastouderopvang; – Gastouderopvang – Gastouder Voorzieningen zijn specifieke locaties waar gastouderopvang door gastouder plaats vindt.

		Hoewel in de Wet gesproken wordt over bemiddeling tussen de gastouders en gastouderbureau’s, gebeurt het altijd in de context van een specifieke locatie, namelijk: Voorziening voor Gastouderopvang. Zonder locatie valt er niets te bemiddelen. Als ouder van locatie wisselt, krijgt hij-zijn het nieuwe nummer. Gastouder meldt deze nieuwe locatie aan bij GOB en GOB gaat dan voor deze nieuwe locatie bemiddelen.
G05	Het feit dat een natuurlijk persoon of een organisatie een houder is, wordt aangeduid door specifieke relatie tussen organisatie voor kinderopvang en betrokken natuurlijk persoon of organisatie	Houder is de rol in welke natuurlijk persoon of niet-natuurlijk persoon optreedt in relatie tot organisatie voor kinderopvang. Het hebben van houder is een kenmerk van organisatie voor kinderopvang.
G05	Mogelijke statussen van de Organisatie voor Kinderopvang worden als een lijst gemodelleerd	Lijst kan als onderhoudbare tabel geïmplementeerd worden. Dit maakt het mogelijk om statussen eenvoudig uit te breiden. LET OP! Er wordt geen logica gebouwd die verantwoordelijk is voor de juiste statusovergangen. Het is een handmatige procedure.
G06	Er is geen expliciete koppeling gelegd tussen het GGD en de Organisatie voor kinderopvang.	GGD’en worden gekoppeld aan Gemeenten. In het inspectierapport kan aangegeven worden door welke specifieke GGD de inspectie is uitgevoerd. Dit is voldoende.
G07	Het feit dat een natuurlijk persoon een houder is, wordt aangeduid door specifieke relatie tussen organisatie voor kinderopvang en betrokken natuurlijk persoon	Gastouder is de rol in welke natuurlijk persoon optreedt in relatie tot organisatie voor kinderopvang. Het hebben van gastouder is een kenmerk van organisatie voor kinderopvang.

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

5.4.2 Logisch gegevensmodel Landelijk Register

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. Afbeelding 8: Logisch gegevensmodel Landelijke Register

Afbeelding 8: Logisch gegevensmodel Landelijke Register

5.4.3 Objectdefinities

5.4.3.1 Abstracties

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.

Objecttype	LR Subject
Afkorting objecttype
Definitie objecttype	Dit zijn alle NATUURLIJKE PERSONEN en rechtspersonen die kinderopvang bieden en wiens registratie in het LR noodzakelijk is voor de uitvoering van Wet Kinderopvang
Herkomst definitie objecttype	Eigen definitie
Toelichting objecttype
Identificatie objecttype	Identificatie vindt plaats op het niveau van een concrete object
Attributen	Attributen zijn beschreven bij concrete objecten

Objecttype	NATUURLIJK PERSOON
Afkorting objecttype	NP
Definitie objecttype	Een NATUURLIJK PERSOON is een individueel menselijk wezen (mens)
Herkomst definitie objecttype	Stelsel van Basisregistraties
Toelichting objecttype
Identificatie objecttype	Identificatie vindt plaats op het niveau van een concrete object
Attributen	Attributen zijn beschreven bij concrete objecten

Objecttype	ORGANISATIE VOOR KINDEROPVANG
Afkorting objecttype	OKO
Definitie objecttype	Zie Woordenlijst (paragraaf 1.6)
Herkomst definitie objecttype
Toelichting objecttype	OKO kan worden gepositioneerd als Maatschappelijke activiteit van LR-Subject op één specifieke locatie.
Identificatie objecttype	– Interne unieke nummer (Register identiteit) – Inschrijvingsnummer (administratieve identiteit)
Attributen	– Inschrijvingsnummer – Naam

5.4.3.2 LR-objecten

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

Objecttype	KINDERDAGVEBLIJF
Afkorting objecttype	KDV
Definitie objecttype	Een specifieke vorm van Kinderopvang
Herkomst definitie objecttype
Toelichting objecttype
Identificatie objecttype	Zie OKO
Attributen	Zie OKO + – Aantal kindplaatsen

Objecttype	BUITENSCHOOLSEOPVANG
Afkorting objecttype	BSO
Definitie objecttype	Een specifieke vorm van Kinderopvang
Herkomst definitie objecttype
Toelichting objecttype
Identificatie objecttype	Zie OKO
Attributen	Zie OKO + – Aantal kindplaatsen

Objecttype	VOORZIENING VOOR GASTOUDEROPVANG
Afkorting objecttype	VGO
Definitie objecttype	Zie Woordenlijst (paragraaf 1.6)
Herkomst definitie objecttype
Toelichting objecttype
Identificatie objecttype	Zie OKO
Attributen	Zie OKO + – Aantal kindplaatsen

Objecttype	GASTOUDERBUREAU
Afkorting objecttype	GOB
Definitie objecttype	Zie Woordenlijst (paragraaf 1.6)
Herkomst definitie objecttype
Toelichting objecttype
Identificatie objecttype	Zie OKO
Attributen	Zie OKO

Objecttype	BEMIDDELINSRELATIE
Afkorting objecttype
Definitie objecttype	Aanduiding van het feit van bemiddeling van GASTOUDERBUREAU namens Gastouder voor de specifieke VGO gedurende bepaalde periode.
Herkomst definitie objecttype	Eigen definitie
Toelichting objecttype
Identificatie objecttype	Technisch nummer
Attributen	– Datum aanvang – Datum einde

Objecttype	INSPECTIERAPPORT
Afkorting objecttype
Definitie objecttype	Na aanleiding van uitgevoerde inspectie door GGD opgestelde rapport m.b.t. kwaliteitstoets van OKO volgens de specifieke toetsingskaders.
Herkomst definitie objecttype	Eigen definitie
Toelichting objecttype
Identificatie objecttype	Kenmerk
Attributen	– Kenmerk – Datum Definitief – Rapport gegevens

Objecttype	STATUS
Afkorting objecttype
Definitie objecttype	Aanduiding van een gebeurtenis in de levenscyclus van de OKO.
Herkomst definitie objecttype	Eigen definitie
Toelichting objecttype	In het LR wordt object STATUS gebruikt om aan te duiden welke administratieve status OKO heeft. Attribuut Reden geeft aan op basis van welke besluit in de administratieve processen rondom OKO de STATUS is toegekend .

	Datum begin en datum einde geven aan de tijdsperiode wanneer de STATUS geldig is.

	Datum Mutatie geeft aan waneer wijziging van STATUS in het register plaats heeft gevonden.

	Attribuut Opmerking kan gebruikt worden om eventuele toelichting over de STATUS toe te voegen.

	Zolang LR niet gekoppeld is met de administratieve systemen van de Gemeenten, moet dit object handmatig onderhouden worden.
Identificatie objecttype	Technisch nummer
Attributen	– Datum begin – Datum einde – Datum Mutatie – Soort status – Reden status – Opmerking

Objecttype	SOORT STATUS
Afkorting objecttype
Definitie objecttype	Domeinwaarden van attribuut Soort Status van object Status
Herkomst definitie objecttype
Toelichting objecttype	Bevat de mogelijke waarden die attribuut Soort Status van object Status kan aannemen. Welke Statussen wel en welke niet getoond mogen worden op het Publieksportaal moet nog worden afgestemd met VNG en OCW.
Identificatie objecttype	Technisch nummer
Enumeration	– Aangemeld: Aanmelding van een OKO is in behandeling

	– Voorlopig Ingeschreven± OKO is ingeschreven onder voorbehoud van nog uit te voeren inspectie en goedkeuring. Zou vooral in de overgangsperiode gebruikt worden: OKO’s die voor 1/1/2010 al bestonden, worden met dit status ambtshalve opgenomen in het Landelijk Register.

	– Afgewezen: Aanvraag voor exploitatie is afgewezen.

	– Ingeschreven: OKO is ingeschreven in het Register; ouders die gebruik maken van BSO, KDV of VGO hebben recht op Toeslag; GOB mag de de betalingen ontvangen voor gastouders;

	– Geschorst: OKO blijft bestaan, maar activiteiten zijn tijdelijk geschorst (er vindt geen kinderopvang plaats)

	– Uitgeschreven: OKO is uitgeschreven uit het Register; geen recht op toeslag voor ouders die gebruik maken van een Uitgeschreven BSO, KDV of VGO. Uitgeschreven GOB mag geen betalingen ontvangen voor gastouders en gastouders moeten zich binnen drie maanden na datum besluit bij een ander bureau aansluiten.

	– Bezwaar: Er loopt een bezwaar procedure op eerdere besluit m.b.t. OKO

	– Beroep: Er loopt een beroep procedure op eerdere besluit m.b.t. OKO

Objecttype	INGESCHREVEN NATUURLIJK PERSOON
Afkorting objecttype	Ingeschreven NP
Definitie objecttype	Een NATUURLIJK PERSOON die ingeschreven is in het BRP
Herkomst definitie objecttype
Toelichting objecttype	Betreft populatie van natuurlijke personen die ingeschreven staan in BPR
Identificatie objecttype	BSN of BSN-RNI (na beschikbaarheid)
Attributen	– BSN nummer – Geboortedatum – DatumOverlijden – Geslachtsaanduiding – Geslachtsnaam – Voorletters – Voornamen – Voorvoegsel Geslachtsnaam

Objecttype	NIET-INGESCHREVEN NATUURLIJK PERSOON
Afkorting objecttype	LR-NP
Definitie objecttype	Dit is een NATUURLIJKE PERSOON die niet ingeschreven staat in Basis Personen Registratie, maar wiens registratie in het LR noodzakelijk is vanwege zijn betrokkenheid bij OKO.
Herkomst definitie objecttype	Eigen definitie
Toelichting objecttype	Volgens AMvB is het goed mogelijk dat buitenlandse personen zonder inschrijving in Nederland de kinderopvang bieden. Dit kan gebeuren vooral in de grensstreken.
Identificatie objecttype	Sofi-nummer
Attributen	– Sofi nummer – Geslachtsaanduiding – Geslachtsnaam – Voornamen – Geboortedatum – Land – Adres

Objecttype	BUITENLANDSE NIET-NATUURLIJK PERSOON
Afkorting objecttype	NNP
Definitie objecttype	Dit is een NIET-NATUURLIJKE PERSOON die niet ingeschreven staat in het NHR, maar wiens registratie in het LR noodzakelijk is vanwege zijn betrokkenheid bij OKO.
Herkomst definitie objecttype	Eigen definitie
Toelichting objecttype	Volgens AMvB is het goed mogelijk dat buitenlandse bedrijven zonder inschrijving in het NHR de kinderopvang bieden. Dit kan gebeuren, vooral in de grensstreek.
Identificatie objecttype	Technisch nummer
Attributen	– Naam – Rechtsvorm – Land – Adres

Objecttype	VESTIGING
Afkorting objecttype	VST
Definitie objecttype	Een VESTIGING is gebouw of een complex van gebouwen waar duurzame uitoefening van activiteiten van een onderneming of rechtspersoon plaatsvindt.
Herkomst definitie objecttype	Catalogus NHR
Toelichting objecttype	Hoewel definitie is ontleent aan NHR, worden bij dit object in het LR ook gegevens opgenomen over de Onderneming van welke de vestiging is en de Rechtspersoon die eigenaar is van die Onderneming. Deze gegevens worden als kenmerken van het object VST opgeslagen. Dit maakt het in de toekomst mogelijk om uitvraag van gegevens te doen bij NHR.
Identificatie objecttype	Vestigingnummer + KVK nummer + FI-nummer (indien beschikbaar)
Attributen	– Vestigingsnummer (van NHR Vestiging) – Handelsnaam (van NHR Vestiging) – KVK nummer (van NHR Onderneming) – Rechtsvorm (van NHR Onderneming) – NaamEigenaar NNP (van NHR Niet-Natuurlijk persoon die eigenaar is van de Onderneming) – Finummer Eigenaar ( van NHR Niet-Natuurlijk persoon die eigenaar is van de Onderneming) – DatumAanvang (datum registratie vestiging in het NHR) – DatumEinde (datum beëindiging vestiging in hetNHR)

Objecttype	BINNENLANDS ADRES
Afkorting objecttype	BADRES
Definitie objecttype	BADRES is de aanduiding van de plaats op aarde waar een bepaald ruimtelijk object zich bevindt door nummer, naam, omschrijving of punt met coördinaten, al dan niet in combinatie met verwijzing naar andere ruimtelijke object(en)
Herkomst definitie objecttype	Afgeleid uit NEN3610:2009
Toelichting objecttype	BADRES kot tot stand op basis van BAG gegevens. Het is niet als afzonderlijk object in het BAG gedefinieerd, maar bestaat uit de volgende objecten: – NUMMERAANDUIDING – OPENBARE RUIMTE – WOONPLAATS

	Attributen van object ADRES zijn een verzameling van attributen van BAG deelobjecten waaruit het bestaat. LET OP! Om adressen eenduidig vast te kunnen leggen, zou koppeling met BAG noodzakelijk kunnen zijn (na beschikbaarheid BAG voor afnemers). Hoe om te gaan met verificatie van adressen op feitelijk bestaan in de periode dat er geen koppelingen zijn met Basisregistraties, moet nog worden bepaald.
Identificatie objecttype	– Adresseerbaar Object Aanduiding (BAG atrtribuur) of, bij ontbreken daarvan: – Technisch nummer.
Attributen	– Adresseerbaar Object Aanduiding – Huisnummer – Huisletter – Huisnummertoevoeging – Postcode – Naam openbare ruimte – Woonplaatsnaam – Datum begin geldigheid – Datum einde geldigheid

Objecttype	GEMEENTE
Afkorting objecttype	GEM
Definitie objecttype	Aanduiding van de gemeente die OKO registreert en eindverantwoordelijk is voor de juistheid van gegevens m.b.t. specifieke OKO
Herkomst definitie objecttype	Eigen definitie
Toelichting objecttype	Opname van deze objecttype is noodzakelijk om aan te geven wie verantwoordelijk is voor de kwaliteit van gegevens. Gemeentes zijn zelf verantwoordelijk voor onderhoud van dit object
Identificatie objecttype	Gemeente naam
Attributen	– Gemeente code – Naam – Domeinnaam – E-mailadres – Telefoonnummer – Correspondentieadres

5.4.3.3 LR hulpobjecten

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.

Objecttype	GEMEENTELIJKE GEZONDHEIDSDIENST
Afkorting objecttype	GGD
Definitie objecttype	Aanduiding van de GGD die toezicht houdt op de specifieke OKO
Herkomst definitie objecttype	Eigen definitie
Toelichting objecttype	Opname van deze objecttype is noodzakelijk om aan te geven bij wie de toezicht op de OKO's berust. Onderhoud van GGD gegevens is niet per Wet geregeld
Identificatie objecttype	Naam
Attributen	– Naam – Domeinnaam – E-mailadres – Telefoonnummer – Correspondentieadres

Objecttype	BEREIKBAARHEID
Afkorting objecttype	BER
Definitie objecttype	Contactgegevens van een OKO die door iedereen gebruikt kunnen worden om in contact te treden met houder of zijn vertegenwoordiger.
Herkomst definitie objecttype	Eigen definitie
Toelichting objecttype	Opname van deze objecttype is NIET strikt noodzakelijk voor de uitvoering van de Wet, maar is lijn met de NORA en OCW principes. Voor onderhoud van dit object moet de partij aangewezen worden. In de Wet is deze verantwoordelijkheid niet geregeld.
Identificatie objecttype	Technisch nummer
Attributen	– Domeinnaam – E-mailadres – Telefoonnummer – Correspondentieadres

5.4.4 Historie en tijdslijnen

5.4.4.1 Wettelijke eisen

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:

• 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.
• 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.
• 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.

5.4.4.2 Basis principes

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:

• 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.
• 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:

• 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:

• 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.
• 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.
• LR bewaart de historie over de volgende soorten gegevens m.b.t. aangehouden werkelijkheid:
- − alle primaire kenmerken van de organisaties van kinderopvang (OKO)
- − Inhoud en kenmerken van de gerelateerde inspectierapporten;
- − 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;
- − bemiddelingsrelaties tussen voorzieningen voor gastouderopvang en gastouderbureaus;
- − Opvangadressen van de OKO’s;

Richtlijnen voor de adminstratieproces:

• Van alle gegevens in het Register wordt de mutatiedatum bijgehouden.

5.5 Berichten

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

6 Technische architectuur

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.

6.1 Architectuureisen

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 Gebruik open standaarden waar mogelijk.
2 Gebruik de volgende documentformaten:
- 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 Niet-reviseerbare documenten in pdf-formaat.
3 Kies voor open source bij gelijke geschiktheid.
4 Sluit aan op overheidsstandaarden als de Referentiearchitectuur Onderwijs, NORA, PKIOverheid en OSB.
5 Voor communicatie met gemeenten wordt rekening gehouden met de standaarden uit GEMMA en daarmee met StUF.
6 Sluit aan op de standaardoplossingen binnen de overheid: de basisregistraties en de andere e-Overheidsbouwstenen.
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 Bij 100 gelijktijdige gebruikers is de responsetijd 2 tot 3 seconden.
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 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 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 Responsetijd maximaal 4 seconden bij 5000 gelijktijdige gebruikers. Deze schatting is gebaseerd op gelijktijdig gebruik door 1 promille van de gebruikerspopulatie.
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 Bij 100 gelijktijdige gebruikers is de responsetijd 2 tot 3 seconden.
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 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 De betrokken organisaties leveren de volgende aantallen gebruikers [bron is de PID]:
- 1.1 Gemeentes 500–1500.
- 1.2 GGD'en 250–350.
- 1.3 Inspectie van het Onderwijs 10–20.
- 1.4 Belastingdienst 50–100.
- 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 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 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 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 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.
- 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.
- 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 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 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 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 Het aantal bevragingen op het LR is dermate groot dat de aanwezigheid van load-balancing noodzakelijk is.

6.2 Applicatie en database

6.2.1 Applicatie-gerelateerd

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.

6.2.1.1 Webrichtlijnen

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

6.2.2 Database-gerelateerd

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

• de grote aantallen transacties,
• de grote hoeveelheid data die moet worden opgeslagen binnen de component ,
• de wettelijke bewaartermijn van 7 jaar waarvan 3 jaar online beschikbaar
• het complexe autorisatie-mechanisme dat ondersteund moet worden
• de zware eisen die aan historische gegevens gesteld worden
• 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.

6.3 Middleware

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:

• Ondersteuning van foutafhandeling ten behoeve van beheer.
• Ondersteuning van logging ten behoeve van beheer.
• 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.

6.4 Platformen

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 Uniformiteit van gebruik van infrastructurele software over de verschillende componenten heen voor zover mogelijk.
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].

6.5 Netwerkarchitectuur

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

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 Alle netwerkverkeer is gebaseerd zijn op het TCP/IP-protocol.
3 Gebruikers kunnen de presentatielaag benaderen via het HTTP-protocol maar wel over SSL/TLS (HTTPS dus).
4 Systeem-authenticatie vindt plaats op basis van PKIOverheidscertificaten.
5 Webservices zijn OSB-WUS (raadplegingen) of OSB-ebMS(transacties) compliant.
6 Bovenop de gebruikte HTTP-protocollen vindt versleuteling van de gegevens plaatsvinden via TLS (Transport Layer Security) en SSL 3.0.
7 Gebruik van besloten (overheids-)netwerken, zoals Haagse Ring, indien mogelijk. Afwijking behoeft uitleg (comply or explain!).

6.6 Overzichtsplaat op hoofdlijnen

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.

Afbeelding 9: infrastructuur per 01-01-2010

7 Beheer

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:

• 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.
• Als secundaire taak wordt het uitvoeren van wijzigingen op het systeemcomplex (inclusief onderliggende infrastructuur natuurlijk) verondersteld.
• 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.
• Beheer van autorisatie wordt ondersteund door het systeemcomplex, mogelijk per te onderkennen component.
• 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.

7.1 Eisen

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

1 Het systeemcomplex moet de relevante monitoring-informatie leveren, minstens:
- 1.1 Geheugengebruik, CPU-gebruik, disk gebruik, inclusief waarschuwing bij benaderen van ingestelde grenzen.
- 1.2 Benaderbaarheid van hardware en services.
- 1.3 Aantal gebruikers op een willekeurig moment.
- 1.4 Monitoring van response-tijden.
- 1.5 Monitoring van beschikbaarheid van koppelvlakken.
2 Het systeemcomplex moet voldoende logging-informatie geven:
- 2.1 Alle fouten moeten gelogd worden.
- 2.2 De relevante acties worden gelogd in een audit-log, inclusief de uitvoerder.
3 Het systeemcomplex moet wijzigbaar zijn:
- 3.1 Hardware moet bij te plaatsen zijn in de serverruimte.
- 3.2 Het systeem moet horizontaal en verticaal schaalbaar zijn.
- 3.3 De systeemcomponenten waaruit het systeemcomplex opgebouwd is moeten afzonderlijk wijzigbaar zijn.
4 Het systeemcomplex moet een beheerinterface bieden waarmee de benodigde gegevens beheerd kunnen worden
- 4.1 Een gebruikersbeheer-interface ten behoeve van authenticatie.
- 4.2 Een gebruikersbeheer-interface ten behoeve van autorisatie.
- 4.3 Een configuratie-interface.
5 Geautomatiseerde backup&restore procedures voor de database.

8 Beveiliging

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.

8.1 Kaders, standaarden en achtergrondinformatie

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.

8.1.1 Typering van informatie: WBP-classificatie

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.

WBP Risicoklasse 0

Publiek niveau

(openbaar)

Weinig persoonsgegevens.

Informatie die voor iedereen toegankelijk is of zonder beperkingen gepubliceerd kan/mag worden (bijv. Internet)

Alle geregistreerde gebruikers krijgen toegang tot deze gegevens

WBP Risicoklasse I

Basis niveau

(intern)

Veel persoonsgegevens.

Informatie die voor alle medewerkers toegankelijk is (bijv. Intranet of Rijksweb)

Alle geregistreerde gebruikers krijgen toegang tot deze gegevens

WBP Risicoklasse II

Verhoogd risico

(vertrouwelijk)

Bijzondere persoonsgegevens art 16 WBP, weinig personen.

Financieel en/of economische persoonsgegevens, weinig personen.

Informatie die toegankelijk is voor een gedefinieerde groep personen (bijv. bepaalde afdelingen of bepaalde functies e.d.)

Alle geautoriseerde gebruikers met opsporingsbevoegdheid en gebruikers met toezichthoudende bevoegdheid krijgen toegang tot deze gegevens; voorzover het inspectieobject onder hun toezicht valt.

WBP Risicoklasse III

Hoog risico

(geheim)

Bijzondere persoonsgegevens art 16 WBP, veel personen.

Informatie die slechts bekend mag zijn bij één individu (bijvoorbeeld pincode, wachtwoord) of een beperkt groep gedefinieerde personen (bijv. stukken onder embargo) en waarvan openbaarmaking aan anderen ten strengste verboden is.

Uitsluitend geautoriseerde gebruikers die opereren vanuit Strafrecht kunnen de gegevens ontsluiten waarvoor de eigenaar van die gegevens expliciet toestemming is verleend. Waar het niet is toegestaan de brongegevens rechtstreeks vanuit het Digitaal Dossier te ontsluiten, kunnen deze via een gegevensverstrekking beschikbaar gesteld. De eigenaar blijft ook verantwoordelijk voor deze bron.

8.1.2 Functies van informatiebeveiliging

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.

8.1.3 Beveiligingsmechanismen

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.

8.2 Aandachtspunten per component

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.

8.2.1 Landelijk Register

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 Integriteit van de gegevens;
2 Traceerbaarheid: audit-trail van alle uitgevoerde wijzigingen;
3 Beschikbaarheid. Het Register moet altijd beschikbaar zijn;
4 Backup & Restore-processen. Er mag geen dataverlies optreden bij een systeemstoring;
5 Exclusiviteit, correctheid van ontsluiting van gegevens;

8.2.2 Overheidsportaal

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 Beveiligbaarheid: autorisatie-model (opzet en implementatie);
2 Exclusiviteit: correcte ontsluiting van gegevens;
3 Traceerbaarheid: volledig audit-trail van alle uitgevoerde wijzigingen;
4 Veilige uitwisseling van gegevens met de gebruiker;
5 Traceerbaarheid: logging van alle uitgevoerde zoekopdrachten, inzicht in welke gebruiker of systeem welke informatie ingezien heeft;

8.2.3 Publieksportaal

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 Exclusiviteit: correcte ontsluiting van gegevens. Er mogen geen onjuiste of onvolledige gegevens ontsloten worden, en alleen definitieve inspectierapporten mogen getoond worden.;
2 Beschikbaarheid. Het Publieksportaal moet altijd te benaderen zijn;

8.3 Algemene beveiligingseisen

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 De code voor informatiebeveiliging wordt gebruikt als overkoepelende leidraad voor beveiliging.
2 Het op te leveren systeemcomplex voldoet minimaal aan de eisen zoals gesteld voor WBP classificatie 2.
3 Het ICT-project hanteert de OWASP richtlijn voor veilige systeemontwikkeling (www.owasp.org).
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.

8.4 Te nemen algemene beveiligingsmaatregelen

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:

• Risicoanalyse;
• Informatiebeveiligingsplan;
• Verantwoordelijke beveiligingsfunctionaris(sen) benoemd;
• Gebruiksvoorwaarden opstellen;
• Beheerprocedures en operationele beveiliging (monitoring) inregelen;
• Audits laten uitvoeren;
• Tijdens ontwikkeling: code-scanning en pen-test;

A Referenties

[1] Project Initiatie Document v1.1 d.d. 21 sept 2009
[2] Wet Kinderopvang
[3] AMvB B2681 K- versie 10 augustus 2009
[4] MARTHE, Model Architectuur voor Rijkstoezichts- en Handhavingseenheden, <nog te maken>, Inspectieraad
[5] Software Architectuur Document Landelijk Register Kinderopvang complex, <nog te maken>, Programma LR-GIR KO
[6] Uitgangsdocumentatie IvhO betreffende Publieksportaal, meerdere documenten van de hand van Ronald Jobse.
[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] Code voor Informatiebeveiliging (NEN-ISO-IEC 27001:2005 (nl))
[9] Voorschrift Informatiebeveiliging Rijksdienst 2007 (VIR 2007)
[10] Voorschrift informatiebeveiliging rijksdienst – bijzondere informatie (Vir-bi)
[11] AV23 Beveiliging van persoonsgegevens, Registratiekamer, Den Haag, april 2001
[12] Overheidsservicebus website, http://www.overheidsservicebus.nl/
[13] Kaderstellende Visie op Toezicht 2001, TK 2000–2001, 27831, nr. 1
[14] Kaderstellende Visie op Toezicht 2005, Kamerstuk 27 831, nr. 14
[15] Referentiearchitectuur Onderwijs, 29 september 2008, B. Gaakeer
[16] Deployment Document Landelijk Register Complex, fase 1, <nog te maken>, Programma LR-GIR KO

B NORA-definities

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

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.
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.
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.

Afbeelding 10: procesarchitectuur

‘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).
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.
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.
Processtap:: Een geordende reeks handelingen die ononderbroken wordt uitgevoerd door één mens of machine binnen één bedrijfsfunctie.
Handeling:: Kleinst mogelijke eenheid van werk, uitgevoerd door één persoon of machine op één plek op één moment (eenheid van tijd, plaats en handeling.

C UML toelichting

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.

Tabel A.1 – Belangrijkste begrippen uit de objectoriëntatie met de bijbehorende UML-notatie
Begrip Nederlands (Engels)	UML-notatie (indien aanwezig)
Klasse (Class) = verzameling objecten met overeenkomstige eigenschappen (‘kenmerken, associaties en gedrag’). Abstracte klasse (abstract class) = klasse zonder objecten. Concrete klasse = klasse met objecten.
	Rechthoek met drie compartimenten; Naam van de klasse Attributen (kenmerken) Operaties (gedrag)
Instantie (instance) = een object uit een klasse
Associatie (association) = relatie tussen twee klassen	Een relatie tussen twee of meer klassen. Om weer te geven hoeveel objecten met elkaar zijn gekoppeld gebruiken we de multipliciteit.

	Eén object (instantie) van klasse A heeft een relatie met nul of meer objecten (instanties) van klasse B.
Multipliciteit (multiplicity) = het aantal betrokken objecten in een associatie	Opname van een expliciet aantal (1, 2 enz) Of een reeks; 0.. = nul of meer 1.. = één of meer 2..5 = twee tot vijf
Specialisatie (specialization) = het verfijnen van een klasse (de zgn. superklasse) in onder- of subklassen
Overerving (inheritance) = iedere subklasse erft alle eigenschappen (kenmerken, associaties en gedrag) van zijn superklasse
Aggregatie (aggregation) = een associatie tussen een samengestelde klasse en een component klasse (maakt deel uit van). Objecten van de deelklasse kunnen worden toegevoegd of verwijderd zonder dat de geheelklasse ophoudt te bestaan.
Compositie (composition) = een associatie die aangeeft dat een of meer klassen (componenten) onderdeel zijn van een andere klasse (compositie-klasse), met als restrictie dat een component niet zelfstandig verder leeft als de compositieklasse verdwijnt
Enumeratie (enumeration) = Een klasse die een lijst van waardes weergeeft. Deze kan worden gebruikt op plaatsen waar voor een bepaalde waarde uit een beperkt aantal vooraf bekende mogelijkheiden behoort te worden gekozen. Een enumeratie is een klasse met als stereotype ‘<<Enumeration>>’.
CodeList = Wanneer vooraf niet bekend is welke waardes een bepaald attribuut kan krijgen, maar als er wel een lijst waarschijnlijke waardes is, wordt in plaats van een Enumeratie een CodeList gebruikt. Een CodeList is een klasse met als stereotype ‘<<CodeList>>’.

Procesmodel LRK-applicatie

Globaal functioneel Ontwerp Landelijk Register Kinderopvang

Documenthistorie

Versie	Datum	Auteur	Opmerking	Status
0.1	14-10-09	Edward Nuiten	Initiele versie eerste review 14-09-2009	concept
0.2	16-10-09	Edward Nuiten	Review	concept
0.3	22-10-09	Edward Nuiten	Oplevering na reviewronde	concept
0.9	23-10-09	Edward Nuiten	Aanvullingen en commentaar verwerkt	concept
1.0	17-11-09	Tom Koenraads	Extern reviewcommentaar verwerkt	definitief

1 Beschrijving LRK-applicatie

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

1.1 Doel

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

• Het is een middel om te toetsen of wordt voldaan aan de gewenste architectuur en aan de (wettelijke) eisen;
• 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.

1.2 Doelgroep

Dit document is bedoeld voor:

• Software Architecten, om te toetsen of wordt voldaan aan de gewenste architectuur.
• Functionele Ontwerpers, als basis voor een verdere uitwerking van de hier beschreven modules in een detail functioneel ontwerp.

1.3 Scope

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

1.4 Relaties met andere documenten

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.

1.5 Leeswijzer

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.

2 Procesondersteuning door de LRK-applicatie

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).

2.1 Overview LRK-systeemcomplex

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:

• publieksportaal
• overheidsportaal
• landelijk register (services)

Daarnaast wordt een systeemcomponent onderkend ten behoeve van het beheer.

2.2 Functionele decompositie

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.

2.3 Procesflows

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

2.3.1 Procesflow initiële inschrijving van een OKO

Initiële inschrijving

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:

• Vastleggen ontvangen aanvraag voor registratiekamer
• Vastleggen inspectierapport
• vastleggen definitieve inschrijving OKO in LRK
• afronden registratie

2.3.1.1 Vastleggen ontvangen aanvraag voor registratie

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

4. Vastleggen ontvangen aanvraag voor registratie

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.

2.3.1.1.1 Inloggen gegevensverwerker Gemeente

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.

4.1 Inloggen Gegevensverwerker Gemeente

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.

2.3.1.1.2 Vastleggen voorlopige gegevens van nieuwe OKO

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

4.2 Vastleggen voorlopige gegevens van nieuwe organisatie voor Kinderopvang (OKO)

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.

2.3.1.1.3 Invoeren gegevens houder (gastouder)

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.

4.3 Invoeren gegevens houder (gastouder)

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).

2.3.1.2 Vastleggen inspectierapport

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.

11. Vastleggen inspectierapport

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.

2.3.1.3 Vastleggen definitieve inschrijving van OKO in LRK

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.

12. Vastleggen definitieve inschrijving van OKO in LRK

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.

2.3.1.4 Afronden registratie

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.

15. Afronden registratie

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.

2.3.2 Verwerken van wijzigingen

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

17. Verwerken van wijzigingen

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.

2.3.3 Raadplegen via publieksportaal

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

16. Raadplegen via 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.

2.3.4 Raakvlakken met Interactiemodel

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.

3 Overview use cases

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.

3.1.1 Publieksportaal

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:

• zoeken LRK-subjecten
• zoeken organisatie voor kinderopvang (OKO)
• raadplegen LRK-subject
• raadplegen OKO
• tonen inspectierapport

3.1.2 Overheidsportaal

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:

• uitgebreid zoeken LRK subjecten
• uitgebreid zoeken OKO
• inzien gegevens LRK-subject
• inzien gegevens OKO
• wijzigen administratieve status OKO
• registreren OKO
• registreren LRK-subject
• wijzigen gegevens OKO
• wijzigen gegevens LRK-subject
• registreren inspectierapport
• inloggen
• uitloggen
• registreren gastouder
• raadplegen historische gegevens OKO
• Tonen overzichten OKO
• Afdrukken overzichten

3.1.3 Landelijk register services

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.

3.2 Beheerfunctionaliteit

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:

• onderhouden gegevens gemeente
• onderhouden gegevens GGD
• onderhouden stamtabellen
• beheren gebruikers
• beheren autorisaties

3.3 Relatie use-cases en modules

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

Afk	Modulenaam	Afk	Modulenaam
LR	Landelijk Register	Auth	Authenticatie
PP	Publieksportaal	Doc	Documenten
OP	Overheidsportaal	MI	Management Informatie
NP	Natuurlijke persoon	AuTr	Audit trail
NNP	Niet-natuurlijke persoon	Beh	Beheer
Adr	Adressen	Hlp	Help
Gebr	Gebruikers

De use cases gebruiken de verschillende modules.

4 Modules LRK-applicatie

De modules zijn benoemd vanuit verschillende invalshoeken.

Afk	Modulenaam	Verantwoording onderkenning module
LR	Landelijk Register	Met de module landelijk register wordt de basis gecreëerd voor het LRK-systeemcomplex. Het is de module die de administratie (database) vormt en de services die nodig zijn om gegevens te kunnen registreren, beheren en te raadplegen.
PP	Publieksportaal	Met de module Publieksportaal worden alle aspecten bedoeld, die nodig zijn om via het publieke internet het LRK te kunnen bevragen. Dit is een redelijk autonoom te ontwikkelen onderdeel van het LRK-systeem.
OP	Overheidsportaal	Met de module Overheidsportaal worden de belangrijkste functies van de processen ondersteund. Deze module vereist interactie met gebruikers en heeft een nauwe relatie met de wijze waarop de wet moet worden gerealiseerd. Ook deze module is redelijk autonoom te ontwikkelen. Delen van deze module kunnen mogelijk hergebruikt worden in het publieksportaal, alhoewel er andere (web)richtlijnen van toepassing zijn.
NP	Natuurlijke persoon	De behandeling van gegevens van natuurlijke personen zal in de toekomst mogelijk veranderen, omdat er dan aansluiting op de basisregistratie GBA wordt gerealiseerd. Daardoor zullen de services rondom de registratie van gegevens van Natuurlijke personen in de toekomst wijzigen. Derhalve worden de services benodigd voor de realisatie van deze functionaliteit ontwikkeld als één module.
NNP	Niet-natuurlijke persoon	De behandeling van gegevens van niet-natuurlijke personen zal in de toekomst mogelijk veranderen, omdat er dan aansluiting op de basisregistratie NHR wordt gerealiseerd. Daardoor zullen de services rondom de registratie van gegevens van Niet-Natuurlijke personen in de toekomst wijzigen. Derhalve worden de services benodigd voor de realisatie van deze functionaliteit ontwikkeld als één module.
Adr	Adressen	De behandeling van gegevens van adressen zal in de toekomst mogelijk veranderen, omdat er dan aansluiting op de basisregistraties BAG, GBA en NHR wordt gerealiseerd, die de adresgegevens leveren. Daardoor zullen de services rondom de registratie van gegevens van Adressen in de toekomst wijzigen. Derhalve worden de services benodigd voor de realisatie van deze functionaliteit ontwikkeld als één module.
Gebr	Gebruikers	Deze module is autonoom te ontwikkelen.
Auth	Authenticatie	Deze module is autonoom te ontwikkelen.
Doc	Documenten	Deze module is autonoom te ontwikkelen
MI	Management Informatie	Deze module is autonoom te ontwikkelen en kent een andere prioriteit.
AuTr	Audit trail	Deze module is een specifiek domein, waarvoor specifieke richtlijnen van toepassing zijn. Derhalve als aparte module onderkend.
Beh	Beheer	Deze module is autonoom te ontwikkelen.
Hlp	Help	Deze module is autonoom te ontwikkelen en kent een andere prioriteit.

4.1 Module Landelijk register

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.

4.2 Module Publieksportaal

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:

• zoekscherm(en): de gebruiker kan verschillende waarden invoeren om te zoeken naar kinderopvang;
• raadpleegscherm(en): om de gevonden resultaten op overzichtelijke wijze getoond worden
• links naar functionaliteiten zoals printen, help

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

4.3 Module Overheidsportaal

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:

• inlogscherm: een scherm waarin de gebruiker gegevens ten behoeve van identificatie en authenticatie kan invoeren.
• keuzescherm(en): de geautoriseerde gebruiker kan aangeven welke actie hij wil uitvoeren.
• zoekscherm(en): de gebruiker kan verschillende waarden invoeren om te zoeken naar kinderopvang;
• raadpleegscherm(en): om de gevonden resultaten op overzichtelijke wijze getoond worden
• invoerscherm(en): een scherm waarop de gebruiker gegevens kan invoeren, wijzigen of verwijderen.
• 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.

4.4 Module Natuurlijke personen

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.

Op deze gegevens is de Wet GBA van toepassing. Daarin is bepaald dat voor de uitvoering van wettelijke taken de publieksrechtelijke rechtspersonen altijd actuele persoonsgegevens gebruikt moeten worden. Dit vereist extra inspanning om de gegevens up-to-date te houden. Daarom is op termijn een koppeling met de GBA-V voorzien, waarbij mutaties snel opgemerkt kunnen worden.

Indien de koppeling met de GBA-V gerealiseerd is, zal de gegevensset van natuurlijke personen in het Landelijk Register beperkt kunnen worden tot het BSN of SoFinummer.

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.

4.5 Module Niet-natuurlijke personen

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.

4.6 Module Adressen

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:

• opvanglocatie;
• correspondentieadres;
• 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.

4.7 Module Gebruikers

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:

Anonieme gebruiker	Iedereen die inzicht wil hebben in het openbare gedeelte van het Landelijke Register Kinderopvang
Gegevensverwerker gemeente	Gebruiker die gegevens van de organisaties voor kinderopvang in het LRK beheert, die onder de verantwoordelijkheid van bepaalde gemeente vallen.
Medewerker keten	Gebruiker die op grond van zijn betrokkenheid bij de uitvoering van de WKO inzicht moet hebben in alle in het LRK geregistreerde gegevens over de Organisaties voor Kinderopvang en hun houders, inclusief alle historische gegevens.
Functioneel beheerder	Gebruiker die stamgegevens in het LRK onderhoudt, zoals referentietabellen, gegevens van Gemeenten en GGD’en, enz..
Autorisaties beheerder	Gebruiker die systeem-breed de autorisaties verleent en intrekt.
Gebruikersbeheerder	Gebruiker die gebruikers opvoert, verwijdert en hun gegevens kan wijzigen.

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.

4.8 Module Authenticatie

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.

4.9 Module Documenten

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.

4.10 Module Management informatie

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.

• Administratieve statussen;
• gemeenten van inschrijving
• soort/vorm van kinderopvang
• aantal kindplaatsen
• aantal aangesloten VGO
• 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.

4.11 Module Audit trail/tijdreizen

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.

4.12 Module Beheer

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.

4.13 Module Help

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

5 High level collaboration diagram

5.1 Primaire proces

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:

– medewerker keten
– gegevensverwerker gemeente
– publiek

Uit oogpunt van overzichtelijkheid zijn sommige modules twee maal opgenomen in het diagram.

5.2 Gebruikers/authenticatiebeheer

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

5.3 Audit trail

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

5.4 Beheer stamgegevens en management informatie

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.

A Referenties

[1] Projectstartarchitectuur Landelijk Register Kinderopvang, versie 1.0, 10-2009
[2] Use-case model Landelijk Register Kinderopvang, versie 1.0, 22-10-2009

Interactie Ontwerp

Globaal Functioneel Ontwerp Landelijk Register Kinderopvang

Documenthistorie

Versie	Datum	Auteur	Opmerking	Status
0.1	14-10-09	Jos van Brummelen	Initiële versie	concept
0.2	21-10-09	Jos van Brummelen	Nadere uitwerking en verwerken review commentaar	concept
0.3	22-10-09	Jos van Brummelen	Conceptversie ter review	concept
0.4	04-11-2009	Tom Koenraads	Intern review commentaar verwerkt	concept
0.9	04-11-2009	Jos van Brummelen	Voor externe review	concept
1.0	17-11-2009	Tom Koenraads	Extern review commentaar verwerkt	definitief
1.1	23-11-2009	Tom Koenraads	Verwijzing naar 5.9 opgenomen	definitief

1 Inleiding en achtergrond

1.1 Doel van dit document

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).

1.2 Doelgroep

Dit document is bedoeld voor:

• Eindgebruikers om functionaliteit af te beschrijven en af te stemmen.
• Software Architecten die het document nodig hebben voor het opstellen van de systeemarchitectuur en een inschatting van de benodigde ontwikkelcapaciteit.
• Functioneel ontwerpers die het document gebruiken voor het ontwikkelen van het DFO.

1.3 Scope van het document

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.

1.4 Leeswijzer

Dit document is opgesplitst in een aantal hoofdstukken:

• Hoofdstuk 2 omschrijft de basisstructuur van het Publieksportaal, het Overheidsportaal en de Beheerfunctionaliteit.
• Hoofdstuk 3 beschrijft de algemene uitgangspunten van de te realiseren portalen
• In hoofdstuk 4 worden de verschillende typen gebruikers en de bijbehorende autorisaties omschreven.
• 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).

1.5 Relatie met andere documenten

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.

Dit document is opgesteld met gebruikmaking van:

• Project Startarchitectuur , versie 0.9
• Use Case Model Landelijk Register Kinderopvang, versie 1.0
• Project Initiation Document ICT-ontwikkeling, versie 1.1
• Requirements List (niet vastgesteld)
• Globaal Prototype, versie 1.0

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

1.6 Openstaande punten

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

• Er is nog geen expliciete relatie gelegd met het Use Case Model
• Inzien van historische gegevens is nog niet uitgewerkt (tijdreizen)
• Details omtrent het wijzigen van een VGO moeten nog worden uitgewerkt
• Rapportages: op basis van de nog te houden workshops dienen de benodigde rapportages en de managementinformatie nog verder uitgediept te worden
• Het Publieksportaal is nog niet in detail uitgewerkt.

Deze zaken verdienen extra aandacht bij uitwerking in het DFO.

1.7 Externe bronverwijzing

1. Ministerie van OCW, rijkshuisstijl
http://rijkshuisstijl.communicatieplein.nl/index.cfm/ministerie-van-onderwijs-cultuur-en-wetenschap/middelen/digitaal/applicaties
2. Webrichtlijnen
http://webrichtlijnen.nl/toetsen

2 Basisstructuur

2.1 Inleiding

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 het Overheidsportaal;
2 het Publieksportaal;
3 de Beheerinterface.

2.2 Overheidsportaal

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.

2.3 Publieksportaal

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':

2.4 Beheerinterface

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

3 Algemene uitgangspunten

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.

3.1 Relatie Overheidsportaal en Publieksportaal

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.

3.2 Schermopbouw

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.

• Hoofdmenu: hier wordt de primaire navigatie getoond.
• Linkerkolom: in deze kolom kunnen secundaire navigatie-elementen worden opgenomen die het navigeren door het systeem vergemakkelijken.
• Contentgedeelte: in dit gedeelte wordt alle content getoond die door het systeem wordt gegenereerd.
• Rechterkolom: deze kolom zal met name worden gebruikt voor contentspecifieke helpteksten. Indien noodzakelijk kan het contentgedeelte worden doorgetrokken en komt deze kolom te vervallen.

3.3 Navigatiestructuur

3.3.1 Primaire navigatie

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.

3.3.2 Secundaire navigatie

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.).

3.3.3 Kruimelpad

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

3.4 Helpfuncties

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).

3.5 Printen van informatie

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.

3.6 Autorisatie

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.

3.7 Authenticatie

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.

3.8 Fout- en andere meldingen

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.

3.9 Gebruik van stamtabellen

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.

3.10 Algemene content

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.

3.11 Webrichtlijnen

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'.

4 Gebruikers

4.1 Rollen

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

Portaal	Rol	Beschrijving
PP	Anonieme gebruiker	Iedereen die inzicht wil hebben in het openbare gedeelte van het LRK
OP	Gegevensverwerker gemeente	Gebruiker die gegevens van de organisaties voor kinderopvang in het LRK beheert, die onder de verantwoordelijkheid van bepaalde gemeente vallen.
OP	Medewerker keten	Gebruiker die op grond van zijn betrokkenheid bij de uitvoering van de WKO inzicht moet hebben in alle in het LRK geregistreerde gegevens over de Organisaties voor Kinderopvang en hun houders, inclusief alle historische gegevens.

		Er valt een onderscheid te maken in: • medewerker GGD • medewerker Belastingdienst • medewerker Inspectie van het Onderwijs Er is nog niet vastgesteld dat dit onderscheid noodzakelijk is.
Beheer	Functioneel beheerder	Gebruiker die stamgegevens in het LRK onderhoudt, zoals referentietabellen, gegevens van Gemeenten en GGD’s, enz.
Beheer	Autorisaties beheerder	Gebruiker die systeem-breed de autorisaties verleent en intrekt.
Beheer	Gebruikersbeheerder	Gebruiker die gebruikers opvoert, verwijdert en hun gegevens kan wijzigen.

5 Overheidsportaal

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.

5.1 Inloggen/uitloggen

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).

5.2 Wachtwoord vergeten

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.

5.3 Startpagina

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:

• 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).
• 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).
• Rapportages. Afhankelijk van de gebruikersrol worden verschillende standaardrapportages getoond (5.13).

5.3.1 Zoeken

Het zoekgedeelte van de pagina bestaat uit:

• 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.
• 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).
• 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).
• 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’).

5.4 Tonen zoekresultaten (OKO en Houders)

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.

5.5 Tonen gegevens Houder

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

• kerngegevens;
• adresgegevens;
• aan de Houder gerelateerde OKO's;
• 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.

5.5.1 Kerngegevens

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.

5.5.2 Adresgegevens

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

5.5.3 Gerelateerde OKO's

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.

5.5.4 (Link naar) historische gegevens

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

5.6 Tonen gegevens OKO

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

• kerngegevens;
• adresgegevens;
• Houdergegevens;
• bijbehorende Inspectierapporten;
• 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.

5.6.1 Kerngegevens

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

5.6.2 Adresgegevens

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

5.6.3 Houdergegevens

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.

5.6.4 Tonen inspectierapporten

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.

5.6.5 (Link naar) historische gegevens

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

5.7 Nieuwe aanvraag

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.

5.7.1 Start registreren OKO

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

1 Registeren Kindercentrum (BSO, KDV);
2 Registeren VGO (inclusief registreren GO);
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.

5.7.2 Registeren Kindercentrum en Gastouderbureau

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

1 Toewijzen Houder
2 Invoeren detailgegevens
3 Controleren ingevoerde gegevens

5.7.2.1 Toewijzen Houder

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:

– Zoeken naar een bestaande Houder op basis van een aantal zoekcriteria;
– als de Houder nog niet bestaat, aanmaken van een nieuwe Houder;
– 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.

5.7.2.2 Invoeren detailgegevens

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.

5.7.2.3 Controleren ingevoerde gegevens

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.

5.7.3 Registreren VGO

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

1 Toewijzen Gastouderbureau
2 Toewijzen Gastouder of Houder VGO
3 Invoeren detailgegevens
4 Controleren ingevoerde gegevens

5.7.3.1 Toewijzen Gastouderbureau

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

○ Zoeken naar een bestaande GOB op basis van een aantal zoekcriteria;
○ als de GOB bestaat, selecteren van het GOB;
○ 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.

5.7.3.2 Toewijzen Gastouder of Houder VGO

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:

– Zoeken naar een bestaande Gastouder of de Houder op basis van een aantal zoekcriteria;
– als de Gastouder of de Houder nog niet bestaat, aanmaken van een nieuwe Houder;
– 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.

5.7.3.3 Invoeren detailgegevens

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.

5.7.3.4 Controleren ingevoerde gegevens

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.

5.8 Detailstap: toewijzen Houder

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:

• Natuurlijk Persoon
• Niet Natuurlijk Persoon

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

• 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.
• 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.

5.8.1 Registreren Natuurlijk Persoon

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.

5.8.2 Registreren Niet Natuurlijk Persoon

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

5.9 Detailstap: registreren Gastouderbureau

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

• 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.
• Indien het GOB al bestaat dan zal de gebruiker worden gevraagd om de gegevens te controleren.
• Indien een GOB nog niet is geregistreerd dan zal worden gevraagd om de gegevens van de GOB in te voeren.

5.10 Detailstap: registreren Gastouder

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:

• 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.
• Indien de Gastouder al bestaat dan zal het systeem controleren of de Gastouder actief is op slechts 1 VGO binnen de opgegeven exploitatieperiode.
• Indien een Gastouder nog niet is geregistreerd dan zal worden gevraagd om de gegevens van de Gastouder in te voeren.

5.11 Detailstap: registreren adresgegevens

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:

• een Binnenlands adres, bestaande uit:
- • een Feitenlijk adres
- • een Postadres, waarbij onderscheid gemaakt wordt tussen:
  - • een Postbus
  - • een Antwoordnummer
• een Buitenlands adres
• 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.

5.12 Wijzigen van gegevens

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).

5.12.1 Wijzigen Kindercentrum en Gastouderbureau

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

• Wijzigen kerngegevens en status
• Wijzigen adresgegevens
• Wijzigen betrokken Houder

5.12.1.1 Wijzigen kerngegevens en status

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

• 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.
• Nieuw inspectierapport toevoegen: naast het uploaden van het inspectierapport worden een aantal kenmerken behorende bij het rapport ingegeven.

5.12.1.2 Wijzigen adresgegevens

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).

5.12.1.3 Wijzigen betrokken Houder

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.

5.12.2 Wijzigen Houder

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

• Wijzigen kerngegevens
• Wijzigen adresgegevens

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

5.12.2.1 Wijzigen kerngegevens

In dit scherm kan de gebruiker de kerngegevens aanpassen.

5.12.2.2 Wijzigen adresgegevens

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.

5.12.3 Wijzigen VGO

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

• Wijzigen kerngegevens en status VGO
• Wijzigen Gastouder en adresgegevens
• Wijzigen adresgegevens VGO
• Wijzigen bemiddelingsrelatie GOB

5.12.3.1 Wijziging kerngegevens en status VGO

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

• 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.
• Nieuw inspectierapport toevoegen: naast het uploaden van het inspectierapport worden een aantal kenmerken behorende bij het rapport ingegeven.

5.12.3.2 Wijzigen Gastouder en adresgegevens

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

5.12.3.3 Wijzigen adresgegevens VGO

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.

5.12.3.4 Wijzigen bemiddelingsrelatie GOB

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.

5.13 Rapportages

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 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 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.

6 Publieksportaal

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.

7 Beheerfunctionaliteit

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.

7.1 Onderhouden gegevens gemeente

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

• Zoeken gemeente (7.1.1)
• Wijzigen gegevens gemeente (7.3.2)
• Toevoegen nieuwe gemeente (7.3.4)

7.1.1 Zoeken gemeente

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.

7.1.2 Wijzigen gegevens gemeente

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.

7.1.3 Toevoegen nieuwe gemeente

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.

7.2 Onderhouden gegevens GGD

7.2.1 Tonen lijst GGD's

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

7.2.2 Wijzigen gegevens GGD

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

7.2.3 Toevoegen nieuwe GGD

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.

7.3 Beheren gebruikers

7.3.1 Zoeken gebruikers

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.

7.3.2 Wijzigen gebruiker

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'.

7.3.3 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.

7.3.4 Toevoegen nieuwe gebruiker

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).

Functioneel Datamodel

Globaal Functioneel Ontwerp Landelijk Register Kinderopvang

Documenthistorie

Versie	Datum	Auteur	Opmerking	Status
0.1	06-10-2009	T.Koenraads	Initiële versie	concept
0.2	20-10-2009	T.Koenraads	Aanvullingen en nav review	concept
0.9	04-11-2009	T.Koenraads	Intern review commentaar verwerkt	concept
1.0	17-11-2009	T.Koenraads	Extern review commentaar verwerkt	definitief
1.01	01-12-2009	T.Koenraads	Toelichting toegevoegd in inleiding	definitief

1 Inleiding

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.

1.1 Doel

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

• Het is een middel om te toetsen of wordt voldaan aan de gewenste architectuur.
• 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).

1.2 Doelgroep

Dit document is bedoeld voor:

• Software Architecten, om te toetsen of wordt voldaan aan de gewenste architectuur.
• Functionele Ontwerpers, als basis voor een verdere uitwerking van de hier beschreven gegevens(verzamelingen) in een detail functioneel datamodel.

1.3 Scope

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

1.4 Relaties met andere documenten

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.

1.5 Leeswijzer

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.

2 Classes

2.1 Register

Organisatie voor kinderopvang (OKO)

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

Attribuut		Opmerkingen
OKO.id	v	Identificatie
LRK-ID	v	Externe identificatie (uniek inschrijfnummer)

• 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.

Attribuut		Opmerkingen
OKO.id	v	Identificatie
Periodevolgnummer	v	Identificatie van een periode
Mutatiehistorie.id	v	Identificatie van historie
Datum aanvang	v	Aanvangsdatum van periode van exploitatie: dit is de datum dagtekening van de beschikking die door de gemeente wordt afgegeven.
Datum einde	o	Einddatum van periode van exploitatie
Toelichting	o	Tekstuele toelichting op de exploitatie, met name in het geval van beëindiging.

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

Status

De status van een OKO.

Attribuut		Opmerkingen
OKO.id	v	Identificatie
Periodevolgnummer	v	Identificatie van een periode
Mutatiehistorie.id	v	Identificatie van historie
Datum aanvang	v	Datum waarop de status van toepassing wordt.
SoortStatus	v	Aanduiding van de status van de OKO. Waardebereik: • Aangemeld • Voorlopig ingeschreven • Afgewezen • Ingeschreven • Geschorst • Uitgeschreven • Bezwaar • Beroep
Reden status	v	Reden van verandering van de status. Waardebereik: (nog niet vastgesteld)
Omschrijving	o	Toelichting; vrije tekst

• De status ‘voorlopig ingeschreven’ is alleen van toepassing voor GOB's
• Een OKO in het register heeft ten alle tijden een status.
Dit betekent:
- • Op het moment van vastlegging in het register moet de status worden vastgelegd.
- • De datum einde van de status is per definitie de datum voorafgaand aan de volgende status.

Naam OKO

Naam van de organisatie voor kinderopvang.

Attribuut		Opmerkingen
OKO.id	v	Identificatie
Periodevolgnummer	v	Identificatie van een periode
Mutatiehistorie.id	v	Identificatie van historie
Datum aanvang	v	Datum waarop de naam van toepassing wordt.
Naam	v	De naam van de OKO

• Een OKO in het register heeft ten alle tijden een naam.
Dit betekent:
- • Op het moment van vastlegging in het register moet de naam worden vastgelegd.
- • De datum einde van de naam is per definitie de datum voorafgaand aan de volgende naam.
- • 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.

Attribuut		Opmerkingen
OKO.id	v	Identificatie
Mutatiehistorie.id	v	Identificatie van historie
Indicatie adres van houder	v	Indicatie die aangeeft of het opvangadres gelijk is aan het adres van de houder. In het geval van een VGO is het opvangadres het adres van de vraagouder (indicatie = nee) of van de gastouder (indicatie = ja). Indien de houder een NP is, is de houder tevens de gastouder. Indien de houder een NNP is, is daarbij de gastouder vastgelegd.
Opvanglocatie	o	Verwijzing naar een adres, gebruikt als locatie van opvang (adres.id).

• Een OKO (anders dan een GOB) moet altijd een opvangadres hebben.
• Het adres (als eigenschap van de OKO) kan niet wijzigen. Mutatie is alleen mogelijk in administratieve zin (correctie van foutieve invoer).
• Indien indicatie adres van houder = 'ja', dan is opvanglocatie leeg (en niet muteerbaar);
• indien indicatie adres van houder = 'nee', dan is opvanglocatie verplicht.
• Opvanglocatie is een feitelijk adres.

Bereikbaarheid

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

Attribuut		Opmerkingen
OKO.id	v	Identificatie
Mutatiehistorie.id	v	Identificatie van historie
Correspondentieadres	o	Verwijzing naar een adres, gebruikt voor correspondentie (adres.id)
Contact.id	o	Verwijzing naar contactgegevens

• 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:

a. die plaatsvindt door tussenkomst van een geregistreerd gastouderbureau;
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;
c. waarbij de houder in totaal niet meer dan één voorziening voor gastouderopvang exploiteert;
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.

Attribuut		Opmerkingen
OKO.id-VGO	v	Identificatie, van een OKO van het soort VGO
OKO.id-GOB	v	Identificatie, van een OKO van het soort GOB
Periodevolgnummer	v	Identificatie van een periode
Mutatiehistorie.id	v	Identificatie van historie
Datum aanvang	v	Datum aanvang van de bemiddelingsrelatie
Datum einde	o	Datum einde van de bemiddelingsrelatie

• Periodes van bemiddeling van één VGO bij één GOB mogen elkaar niet overlappen.
• Periodes van bemiddeling van één VGO bij verschillende GOBs mogen elkaar overlappen; een VGO mag gelijktijdig bemiddeld worden door meerdere GOBs.
• Geen beperkingen t.a.v. status van VGO en/of GOB.
• De bemiddelingsrelatie tussen GOB en VGO mag alleen onderhouden worden door de gemeente van de VGO.

Opvang

Nadere gegevens omtrent de geboden opvang.

Attribuut		Opmerkingen
OKO.id	v	Identificatie
Periodevolgnummer	v	Identificatie van een periode
Mutatiehistorie.id	v	Identificatie van historie
Aantal plaatsen	v	Het aantal plaatsen van opvang dat beschikbaar is (het aantal kinderen dat opgevangen kan/mag worden op de locatie)

Houder

De rechtspersoon of natuurlijke persoon van 18 jaar of ouder die een kindercentrum, een voorziening voor gastouderopvang of een gastouderbureauexploiteert.

Attribuut		Opmerkingen
OKO.id	v	Identificatie
Periodevolgnummer	v	Identificatie van een periode
Mutatiehistorie.id	v	Identificatie van historie
Datum aanvang	v	Datum aanvang van het houder-schap
Datum einde	o	Datum einde van het houder-schap

• Een OKO heeft ten alle tijden exact één houder.
Dit betekent:
- • Op het moment van vastlegging in het register moet de houder worden vastgelegd.
- • De datum einde van de houder is per definitie de datum voorafgaand aan de volgende houder. Periodes van houder-schap van één OKO mogen elkaar niet overlappen. Datum einde hoeft niet vastgelegd te worden, maar kan bijvoorbeeld gebruikt worden indien bekend is dat de houder zal gaan stoppen (en er is nog geen nieuwe houder bekend).
- • De vroegste datum aanvang is gelijk aan de vroegste datum aanvang van de status van de OKO.
• Een natuurlijk persoon kan in een aangegeven periode maar op één manier betrokken zijn bij een VGO. Hetzij als NP Houder, hetzij als gastouder van een NNP Houder.

NP Houder

De natuurlijke persoon van 18 jaar of ouder die een kindercentrum, een voorziening voor gastouderopvang of een gastouderbureauexploiteert.

Is een houder. Heeft aanvullende kenmerken:

Attribuut		Opmerkingen
NP.id	v	Identificatie van een natuurlijk persoon

NNP Houder

De rechtspersoon die een kindercentrum, een voorziening voor gastouderopvang of een gastouderbureauexploiteert.

Is een houder. Heeft aanvullende kenmerken:

Attribuut		Opmerkingen
NNP.id	v	Identificatie van een niet-natuurlijk persoon (rechtspersoon)
Gastouder	o	Verwijzing naar een NP (NP.id)

• Gastouder mag alleen worden ingevuld en is verplicht indien de NNP houder is van een VGO.

Ontwerpbeslissingen

De gegevens van een OKO zijn verdeeld over 5 classes, omdat verondersteld wordt dat deze met een verschillende frequentie zullen wijzigen en dat deze daarbij aan verschillende constraints zullen moeten voldoen.

Conform PSA is een houder een buitenlands niet-natuurlijk persoon, een buitenlands natuurlijk persoon, een GBA ingeschreven natuurlijk persoon, of een eigenaar van een NHR ingeschreven onderneming, zijnde een binnenlands niet-natuurlijk persoon of een buitenlands niet-natuurlijk persoon.

Daarnaast dient rekening gehouden te worden met natuurlijke personen die niet in de GBA zijn ingeschreven, of waarvan de inschrijving (nog) niet geverifieerd kan worden, natuurlijke personen in de rol van eigenaar van een NHR ingeschreven onderneming en met ondernemingen die niet in de NHR zijn ingeschreven, of waarvan de inschrijving (nog) niet geverifieerd kan worden.

Om dit iets te vereenvoudigen wordt in dit GFO slechts onderscheid gemaakt tussen natuurlijke en niet-natuurlijke personen, als houder van een OKO.

Een voorziening voor gastouderopvang wordt geëxploiteerd door een houder. Indien de houder een natuurlijk persoon is, is deze persoon tevens de gastouder. Indien de houder een niet-natuurlijk persoon is, dient separaat te worden vastgelegd wie (welk natuurlijk persoon) de gastouder is.

Dit is gemodelleerd als relatie van de houder, aangezien dit per definitie de eigenaar van die onderneming (niet-natuurlijk persoon) is.

2.2 Overheids Portaal

Interface module, geen eigen data.

2.3 Publieks Portaal

Interface module, geen eigen data.

2.4 Natuurlijke Personen

Natuurlijk persoon

Attribuut		Opmerkingen
NP.id	v	Identificatie van een natuurlijk persoon

NP Gegevens

Attribuut		Opmerkingen
NP.id	v	Identificatie van een natuurlijk persoon
Mutatiehistorie.id	v	Identificatie van historie
GBA verificatie	v	Aanduiding of de gegevens GBA geverifieerd zijn
BSN/Sofinummer	o
Geslachtsaanduiding	o
Geslachtsnaam	v
Voorvoegsels geslachtsnaam	o
Voorletters	o
Voornamen	o
Geboortedatum	v
Datum overlijden	o
Woonadres	v	Verwijzing naar een adres (adres.id)
Contact.id	o	Verwijzing naar contactgegevens

• Woonadres is een feitelijk adres of een buitenlands adres.

Opmerking: wellicht nog uit te breiden met gegevens van aanschrijving (vorm, naam partner)

Exploitatieverbod

Attribuut		Opmerkingen
NP.id	v	Verwijzing naar een natuurlijk persoon
Periodevolgnummer	v	Identificatie van een periode
Mutatiehistorie.id	v	Identificatie van historie
Datum aanvang	v	Datum aanvang van de periode waarop het verbod betrekking heeft
Datum einde	o	Datum einde van de periode waarop het verbod betrekking heeft
Gemeente.id	v	Gemeente die het verbod heeft ingesteld
Toelichting	v	Toelichting op exploitatieverbod; bijvoorbeeld een verwijzing naar een voorafgaand handhavingstraject.

Ontwerpbeslissingen

1	Alle natuurlijke personen zijn gemodelleerd als één class.
2	Woonadres is verplicht i.v.m. eigenaarschap gegevens (autorisatie)
3	Het exploitatieverbod is opgenomen bij de persoonsgegevens aangezien het gerelateerd is aan de natuurlijk persoon en niet aan inschrijving in het register

2.5 Niet-Natuurlijke Personen

Niet-natuurlijk persoon

Attribuut		Opmerkingen
NNP.id	v	Identificatie van een niet-natuurlijk persoon (rechtspersoon)

NNP Gegevens

Attribuut		Opmerkingen
NNP.id	v	Identificatie van een niet-natuurlijk persoon (rechtspersoon)
Mutatiehistorie.id	v	Identificatie van historie
NHR verificatie	v	Aanduiding of de gegevens NHR geverifieerd zijn
KVK nummer	o
Vestigingsnummer	o
Handelsnaam	v
Rechtsvorm	o
Datum aanvang	v
Datum einde	o
FI nummer eigenaar	o
Naam eigenaar	o
Vestigingsadres	v	Verwijzing naar een adres (adres.id)
Contact.id	o	Verwijzing naar contactgegevens

• Vestigingsadres is een feitelijk adres.
• Het BIN is een samentrekking van kvk- en vestigingsnummer

Ontwerpbeslissingen

1	Alle niet-natuurlijke personen zijn gemodelleerd als één class.
2	Vestigingsadres is verplicht i.v.m. eigenaarschap gegevens (autorisatie)

2.6 Adressen

Adres

Aanduiding van een locatie (verblijfsobject, standplaats, ligplaats of postadres).

Attribuut		Opmerkingen
Adres.id	v	Identificatie

Binnenlands adres

Is een adres, in Nederland.

Feitelijk adres

Is een adres, in Nederland.

Feitelijk adres gegevens

Attribuut		Opmerkingen
Adres.id	v	Identificatie
Mutatiehistorie.id	v	Identificatie van historie
Adres verificatie	v	Aanduiding of het adres geverifieerd is
Adresseerbaar object aanduiding	o	Externe identificatie van het adres (BAG)
Straat	o
Huisnummer	v
Huisletter	o
Huisnr toevoeging	o
Postcode	v
Woonplaats	o
Naam openbare ruimte	o

Post adres

Is een adres, in Nederland, van een postbus of antwoordnummer.

Postbus

Is een postadres.

Postbus Gegevens

Attribuut		Opmerkingen
Adres.id	v	Identificatie
Mutatiehistorie.id	v	Identificatie van historie
Postbusnummer	v
Postcode	v
Woonplaats	v

Antwoordnummer

Is een postadres.

Antwoordnummer Gegevens

Attribuut		Opmerkingen
Adres.id	v	Identificatie
Mutatiehistorie.id	v	Identificatie van historie
Antwoordnummer	v
Postcode	v
Woonplaats	v

Buitenlands adres

Is een adres, niet in Nederland.

Buitenlands adres gegevens

Attribuut		Opmerkingen
Adres.id	v	Identificatie
Mutatiehistorie.id	v	Identificatie van historie
Land	v
Straat buitenland	v
Huisnummer buitenland	v
Postcode buitenland	o
Woonplaats buitenland	v

Contact gegevens

Attribuut		Opmerkingen
Contact.id	v	Identificatie
Contactpersoon	o	Naam; volledige naam incl. aanschrijving
Url	o
Email	o
Telefoon	o

Van contactgegevens wordt geen mutatiehistorie vastgelegd!

Ontwerpbeslissingen

1	De straat en woonplaats zijn opgenomen in het feitelijk adres. Dit is redundant indien postcode en huisnummer bekend zijn, en voorkomen in de betreffende stamtabel.

2.7 Gebruikers en autorisaties

Medewerker

Medewerker van een van de overheidsorganisaties die gebruik maken van het overheidsportaal. Ook de medewerkers van de beheerorganisatie worden hierin opgenomen.

Attribuut		Opmerkingen
Medewerker.id	v	Identificatie van een medewerker
Geslachtsaanduiding	o
Geslachtsnaam	v
Voorvoegsels geslachtsnaam	o
Voorletters	o
Voornamen	o
Geboortedatum	v
Functie	o	Omschrijving van de functie van een medewerker
Datum in functie	v	Datum waarop de medewerker begint in de functie, op grond waarvan toegang tot het LRK gewenst is
Datum uit functie	o	Datum waarop de medewerker de functie beëindigd
Toegang actief/geblokkeerd	v	Indicatie die aangeeft of de gebruiker toegang heeft tot het LRK; bijvoorbeeld gebruikt voor een (tijdelijke) blokkade als gevolg van een foutieve authenticatie
Email	o
Telefoon	o

Autorisatie

Koppeling van een medewerker aan een of meer rollen (en vice versa).

Attribuut		Opmerkingen
Medewerker.id	v	Identificatie van een medewerker
Rol.id	v	Identificatie van een rol

Rol

Groepering van rechten die nodig zijn om een bepaalde (administratieve) functie te vervullen.

Attribuut		Opmerkingen
Rol.id	v	Identificatie van een rol
Omschrijving	v	Korte omschrijving van de rol

Samenstelling rol

Definitie van de set van rechten die zijn toegekend aan een rol.

Attribuut		Opmerkingen
Rol.id	v	Identificatie van een rol
Recht.id	v	Identificatie van een recht

Recht

Definitie van de set van handelingen die nodig zijn voor uitvoering van een specifieke taak in de LRK applicatie. Hieronder vallen toegang tot schermen, toegang tot gegevens (raadplegen of muteren), en toegang tot acties.

Attribuut		Opmerkingen
Recht.id	v	Identificatie van een recht
Omschrijving	v	Korte omschrijving van het recht

Medewerker GGD

Is een medewerker, van een bepaalde GGD.

Heeft aanvullende kenmerken:

Attribuut		Opmerkingen
GGD.id	v	Identificatie van een GGD

Medewerker Gemeente

Is een medewerker, van een bepaalde gemeente.

Heeft aanvullende kenmerken:

Attribuut		Opmerkingen
Gemeente.id	v	Identificatie van een Gemeente

Medewerker IvhO

Is een medewerker, van de Inspectie van het Onderwijs.

Medewerker BD

Is een medewerker, van de Belastingdienst.

Medewerker Beheer

Is een medewerker, van de organisatie die het (centrale) beheer uitvoert.

Ontwerpbeslissingen

1	Het model ondersteunt geen tijdelijke rechten (dus niet: profiel heeft rol gedurende een bepaalde periode en/of rol heeft recht gedurende een bepaalde periode)
2	Het model ondersteunt geen variabele rechten, zoals
	–	context afhankelijke rechten (dus niet: profiel heeft rol in een bepaalde context en/of rol heeft recht in een bepaalde context)
	–	inhoud afhankelijke rechten (dus niet: profiel heeft rol afhankelijk van de inhoud van bepaalde andere gegevens in de database, zoals de waarde van een status)

	De enige uitzondering hierop is de autorisatie per gemeente. Er kan expliciet rekening gehouden worden met de gemeente behorende bij het profiel. Alle gegevens in de database zijn 'eigendom' van een bepaalde gemeente of worden centraal beheerd.
3	Het model ondersteund geen toegekende/overdraagbare rechten (dus niet: gebruiker a verleent machtiging tot uitvoeren van taken aan gebruiker b).
4	Het model ondersteund geen 'shared services'. Een profiel heeft (mutatie)rechten op de gegevens van precies één gemeente of van alle gemeenten.
5	De meeste ambtenaren zijn natuurlijke personen. Hier is er echter voor gekozen om de gegevens van de medewerkers niet uit het GBA te betrekken maar om deze separaat vast te leggen.
6	Een medewerker heeft slechts één profiel waarmee hij of zij toegang heeft tot de LRK applicatie. Daarmee is er geen noodzaak scheiding aan te brengen tussen de gegevens van de persoon en gegevens van het gebruikersprofiel.

2.8 Authenticatie

Authenticatie

Aanvullende gegevens nodig voor afhandeling van het authenticatieproces.

Attribuut		Opmerkingen
Medewerker.id	v	Identificatie van een medewerker
Gebruikersnaam	v	Korte naam waarmee de medewerker zich aanmeld bij het LRK
Wachtwoord	v	Controlemiddel voor basale authenticatie
Datum wachtwoord geldig t/m	o	Datum tot en met wanneer het wachtwoord geldig is. Na deze datum moet het wachtwoord gewijzigd worden.
Email	o/v	Email adres dat gebruikt wordt in het authenticatieproces, bijvoorbeeld om de medewerker een nieuw wachtwoord te sturen. Optionaliteit afhankelijk van de inrichting van het proces.
Telefoon	o/v	Telefoonnummer dat gebruikt wordt in het authenticatieproces, bijvoorbeeld voor authenticatie met gebruik van sms. Optionaliteit afhankelijk van de inrichting van het proces.

2.9 Documenten

Op dit moment nog slechts voorzien in één document, het inspectierapport.

Indien wordt vastgesteld dat het noodzakelijk is meerdere (type) documenten op te slaan (uitbreiding scope), zal het model aangepast moeten worden.

Inspectierapport

Document dat wordt opgeleverd bij inspectie van een OKO.

Attribuut		Opmerkingen
Rapport.id	v	Identificatie
Mutatiehistorie.id	v	Identificatie van historie
OKO.id	v	Identificatie van een OKO; de OKO waar deze rapportage betrekking op heeft
GGD.id	v	Identificatie van een GGD. Dit is de GGD die de inspectie heeft uitgevoerd en het rapport heeft opgesteld. De gemeente-GGD relatie wordt niet vastgelegd per periode. Bovendien kan deze afwijken van de GGD waar de gemeente haar reguliere overeenkomst mee heeft.
Kenmerk	o	Externe identificatie
Datum rapport	v	Extern attribuut ‘rapportagedatum’
Rapport object	v	Het rapport, als PDF

2.10 Management informatie

Deze module heeft geen eigen data.

2.11 Audit trail/tijdreizen

Audit trail wordt gebruikt voor 3 zaken. Logging van mutaties (die weer gebruikt worden voor tijdreizen), logging van gebeurtenissen (bv. aanmelden door gebruiker) en logging van 'raadplegingen'. De tweede is slechts voor zover gemodelleerd als nu functioneel onderkend is. De logging van raadplegingen is (nog) niet gemodelleerd.

Mutatiehistorie

Tijd-assen van aangebrachte wijzigingen.

Attribuut		Opmerkingen
Mutatiehistorie.id	v	Identificatie
Reden wijziging	v	Codering van de reden dat de mutatie is opgevoerd Waardebereik: • Mutatie van feitelijkheid (handmatige invoer omdat er iets in buitenwereld is veranderd) • Administratieve correctie (verbetering van ‘typefouten’) Later kan dit worden uitgebreid met al of niet automatisch overnemen van gegevens uit koppelingen.
Toelichting wijziging	o	Tekstuele toelichting, bijvoorbeeld op de reden dat de mutatie is opgevoerd.
Datum aanvang	v	Werkelijke tijd: wanneer is/wordt de mutatie van toepassing
Datum informatie	o	Administratieve tijd: wanneer was de informatie op grond waarvan de mutatie is aangebracht bekend bij de overheid
Datum/tijd mutatie	v	Systeem tijd: wanneer is de mutatie aangebracht in de database
Bron	v	Wie heeft de gegevens gemuteerd (identificatie van gebruiker of koppelvlak)
Indicatie logisch verwijderd	v	Indicatie die aangeeft of de gegevens als verwijderd moeten worden beschouwd

• Datum informatie moet kleiner of gelijk zijn aan de datum mutatie
• Datum/tijd mutatie en Bron worden automatisch bepaald

Logging

Registratie van een gebeurtenis (event).

Attribuut		Opmerkingen
Logging.id	v	Identificatie
Datum/tijd event	v	Datum en tijd waarop de gebeurtenis plaats heeft gevonden

Aanmelding

Is een logging; van het aanmelden door een gebruiker, of een poging daartoe.

Attribuut

Opmerkingen

Gebruiker.id

Identificatie

Code resultaat authenticatie

Codering van het resultaat van een poging tot authenticatie

Waardebereik:

• Authenticatie afgebroken door de gebruiker

• Authenticatie niet succesvol: wachtwoord niet correct

• Authenticatie niet succesvol: TAN code niet correct

• Authenticatie succesvol, gebruiker krijgt toegang

Hiermee worden niet de eventuele authenticatie-pogingen van niet bekende gebruikers geregistreerd.

2.12 Beheer

Stamtabel: Postcodetabel TNT

Definieert alle mogelijke postcodes en postcode/huisnummer combinaties.

Legt relatie tussen postcode/huisnummer en straatnaam.

Stamtabel: Postcodetabel 4PP TNT

Legt relatie tussen het numeriek deel van de postcode en woonplaats

Stamtabel: Woonplaatstabel

Definieert alle mogelijke woonplaatsen.

Legt relatie tussen woonplaats en gemeente.

Stamtabel: Gemeentetabel GBA

Definieert alle mogelijke gemeenten.

Stamtabel: Landtabel GBA

Definieert alle mogelijke landen.

OKO Gemeente

Is een Gemeente. Heeft aanvullende kenmerken:

Attribuut		Opmerkingen
GGD.id	v	Identificatie van een GGD; de GGD die namens deze gemeente KO inspecties uitvoert
Contact.id	o	Contactgegevens van de gemeente
Correspondentieadres	o	Verwijzing naar een adres, gebruikt voor correspondentie (adres.id)

• Correspondentieadres kan een feitelijk adres of een postadres zijn.

GGD

Gemeentelijke gezondheidsdienst. Voert namens de gemeente taken uit in de openbare gezondheidszorg, waaronder KO inspecties.

Attribuut		Opmerkingen
GGD.id	v	Identificatie van een GGD; de GGD die namens deze gemeente KO inspecties uitvoert
Naam GGD	v	Naam van de GGD
Correspondentieadres	o	Verwijzing naar een adres, gebruikt voor correspondentie (adres.id)

• Correspondentieadres kan een feitelijk adres of een postadres zijn.

GGD Contact

Contactgegevens van een GGD.

Attribuut		Opmerkingen
GGD.id	v	Verwijzing naar en GGD
Contact.id	v	Verwijzing naar contactgegevens
Omschrijving aard contact	v	Tekstuele omschrijving van de aard van het contact.
Volgorde contact	v	Aanduiding van de volgorde (volgnummer) waarin de contactgegevens van een GGD worden gebruikt (getoond).

2.13 Help

Deze module heeft geen eigen data.

TOELICHTING

Algemeen

In de loop van 2010 wordt het landelijk register in gebruik genomen, dat wil zeggen: alle gemeenten worden erop aangesloten, zodat ze zelf gegevens kunnen invoeren en muteren, en alle gegevens uit de huidige gemeentelijke registers worden overgezet in het landelijk register. Er dient een overgang plaats te vinden van de situatie zoals die tot en met 2009 gold (gemeentelijke registers, waarin gastouderbureaus en kindercentra zijn geregistreerd) naar de vanaf 1 januari 2010 wettelijk voorgeschreven situatie (een landelijk register, waarop alle gemeenten zijn aangesloten en waarin alle gastouderbureaus, kindercentra en ook gastouders die aan de wettelijke eisen voldoen, staan geregistreerd). De colleges blijven verantwoordelijk voor het volledig en actueel houden van het register.

De Belastingdienst zal voor het eerst van het landelijk register gebruikmaken bij de bevoorschotting kinderopvangtoeslag voor het jaar 2011. Die bevoorschotting wordt gebaseerd op de gegevens in het register op 1 oktober 2010. Het is daarom essentieel dat uiterlijk op die datum het landelijk register volledig gevuld en actueel is.

De voorliggende regeling bevat de vaststelling van het model aanvraagformulier en van de systeembeschrijving van het register; het Besluit registratie kinderopvang schrijft dat voor. Ook is in deze regeling opgenomen dat de directeur-generaal van de Dienst Uitvoering Onderwijs is belast met het dagelijks beheer van het register. Dat houdt in feite in: het ‘beheersmatig beheer’. De colleges zijn immers belast met het beheer ’van de inhoud‘: het vullen en anderzijds muteren van het register. Wel kunnen de colleges aan de DG DUO verzoeken om enkele met die mutaties samenhangende taken over te nemen, zoals het verzorgen van correspondentie.

Voor het overige bevat deze wijzigingsregeling de vaststelling van het model jaarverslag over 2009 en is zij gebruikt om een enkele omissie in de Regeling Wet kinderopvang weg te nemen. Hoofdzaak van deze wijzigingsregeling is echter de implementatie van het Register kinderopvang, zoals dat sedert 1 januari 2010 is voorgeschreven in de Wet kinderopvang, en regeling van de initiële vulling van dat register. Dat is een proces dat niet op een enkele dag kan worden gerealiseerd, maar – ook omdat tijdens dat proces het werk gewoon doorgaat – een aantal maanden vergt.

Aanpak van de implementatie van het Register kinderopvang

In de loop van 2010 worden

• alle gemeenten aangesloten op het landelijk register;
• alle gemeentelijke registers overgezet in het landelijk register;
• alle nieuwe aanvragen in het register ingevoerd, alsmede alle beschikkingen die ten aanzien van aangemelde kinderopvangvoorzieningen door het college zijn genomen.

De aansluiting van gemeenten vindt in tranches plaats, om de implementatie zorgvuldig te kunnen vormgeven en begeleiden. Er wordt uitgegaan van het principe, dat het gemeentelijke register wordt overgeheveld naar het landelijk register rond het moment dat de gemeente aansluit op het register. Gemeenten kunnen dan tot het moment van aansluiting in hun gemeentelijk register blijven werken en hebben na aansluiting op het landelijk register meteen hun eigen gegevens daar weer beschikbaar. Dubbele registratie wordt zo voorkomen. Alleen overheveling van de gastouderbureaus uit de gemeentelijke registers vindt eerder plaats, omdat dit het mogelijk maakt om ook de nieuw aangemelde gastouders in het register in te voeren (dat kan namelijk alleen indien ze gekoppeld zijn aan een geregistreerd gastouderbureau). Omdat gemeenten pas in de loop van 2010 zelf in het register kunnen invoeren en muteren, wordt tot hun moment van aansluiting voorzien in centrale data-entry door de Dienst Uitvoering Onderwijs (DUO), die het landelijk register beheert en die door gemeenten aangeleverde gegevens in het landelijk register invoert.

Zolang gemeenten zelf nog niet zijn aangesloten op het landelijk register, zorgt DUO voor de invoer van gegevens.

Gemeenten leveren hiertoe hun aanvraagformulieren en beschikkingen voor gastouders aan DUO aan, en leveren uiterlijk 1 juni 2010 alle bestaande gastouderbureaus uit hun gemeentelijke registers aan. DUO voert deze gastouderbureaus en gastouders in het landelijk register in. Het landelijk register is dan leidend voor GO en GOB. Gemeenten houden Kinderdagverblijven en BSO nog in hun gemeentelijke registers bij totdat ze kunnen aansluiten op het landelijk register.

In de periode 1 mei–1 oktober 2010 sluiten de gemeenten in tranches op het landelijk register aan, en op het moment van aansluiting van een gemeente worden ook de bestaande kinderdagverblijven en BSO-organisaties uit het gemeentelijke register overgeheveld naar het landelijk register. Vanaf het moment van aansluiting houdt een gemeente zelf het register bij.

De uiterste aanleverdatum van de gemeentelijke registergegevens is 15 september 2010, zodat DUO de tijd heeft om de vulling van het landelijk register per 1 oktober afgerond te hebben. De Belastingdienst kan dan op basis van de stand op 1 oktober 2010 de bevoorschotting voor 2011 uitvoeren.

De juridische systematiek onder de invoering van het landelijk register

Deze wijzigingsregeling laat zich – voor wat betreft de bepalingen over het register – alleen goed lezen in combinatie met de bepalingen ter zake in de Wet kinderopvang en het Besluit registratie kinderopvang. In onderlinge samenhang realiseren wet, besluit en de voorliggende wijziging van de regeling de hierna weer te geven juridische systematiek.

De Wet kinderopvang, zoals deze luidt sedert 1 januari 2010, bepaalt in de artikelen 45 tot en met 47a dat er een landelijk register is, aan welke regels een voorziening voor kinderopvang moet voldoen om daarin te worden opgenomen, alsmede wanneer en volgens welke procedures het college van burgemeester en wethouders een voorziening daarin opneemt. Op 1 januari 2010 was het landelijk register evenwel nog in ontwikkeling en ook overigens is het begrijpelijk, dat een dergelijk nieuw register niet van de ene op de andere dag, volgens de regels en inhoudelijk correct, kan worden gevuld. Dat heeft de wetgever ook voorzien: artikel 90 van de wet maakt het – huiselijk samengevat – in die omstandigheden mogelijk om nog enige tijd te blijven werken met de gemeentelijke registers zoals die tot eind 2009 en feitelijk ook nog in de eerste maanden van 2010 in gebruik waren. Het tweede lid van dat artikel beperkt die overgangsperiode weliswaar tot aan 1 juli 2010, maar het tweede lid van artikel 92a maakt het mogelijk om, in verband met een goede invoering van het nieuwe stelsel, ook van die datum af te wijken.

Met de in artikel I, onderdeel B, en artikel II van dit besluit beschreven wijze van werken is, op basis van de zojuist genoemde wettelijke bepalingen, gekozen voor een zorgvuldige procedure van transitie van de gemeentelijke registers naar het landelijke register kinderopvang. Artikel I, onderdeel A, laat de bepalingen in de Regeling Wet kinderopvang vervallen. Dat gebeurt, zo stelt artikel IV, met terugwerkende kracht per 1 januari 2010. Dat is de hoofdregel, waar onderdeel B van artikel I echter direct zelf weer aan afdoet. Daarin staat immers ook dat de bepalingen over gemeentelijke registers van kracht blijven in die gemeenten en voor die voorzieningen, waar en voor duur dat opname in het landelijk register nog niet kon plaatsvinden. Dat maakt een gefaseerde vulling van het landelijk register mogelijk met variaties per gemeente en zelfs per type voorziening voor kinderopvang binnen elke gemeente. Deze keuze biedt maximale waarborg voor zorgvuldige procedures terwijl, omdat waar nodig de gemeentelijke registers nog intact en ’onderhouden‘ blijven, geen afbreuk wordt gedaan aan de gewenste rechtszekerheid. Intussen wordt het nieuwe landelijk register per cohort voorzieningen gevuld; artikel II biedt daartoe het spoorboekje. Het tweede lid van het nieuw in de Regeling in te voegen artikel 9c maakt het vervolgens mogelijk dat binnen de Dienst Uitvoering Onderwijs al werkzaamheden rond de vulling van het register kinderopvang worden verricht, ook als de betreffende gemeente nog niet is aangesloten op het landelijk register. Die situatie kan, ter keuze van het betreffende college, desgewenst nadien ook geheel of ten dele worden bestendigd.

Binnen de gegeven tijdpaden kan versnelling mogelijk blijken. De tekst van deze regeling staat daar, dank zij de flexibele inhoud van artikel I, niet aan in de weg. De genoemde einddata markeren wel fatale termijnen. Zouden die data niet gehaald worden, dan kan de Belastingdienst/Toeslagen immers niet (tijdig) bepalen of iemand recht heeft op kinderopvangtoeslag.

Artikelsgewijs

Artikel I

Onderdelen A en B

Met onderdeel B vervallen de bepalingen in de Regeling die betrekking hebben op de gemeentelijke registers kinderopvang ten faveure van de regels in de Wet kinderopvang en het Besluit registratie kinderopvang. Dat gaat geleidelijk. Voor de systematiek waarmee dat gebeurt verwijs ik naar de slotparagraaf van het algemeen deel van deze toelichting. In verband met deze transitie krijgt de benaming van paragraaf 3 van de Regeling met onderdeel A een meer neutraal karakter.

Onderdeel C

Onderdeel C voegt nieuwe artikelen in de Regeling Wet kinderopvang in. Allereerst gaat het om de vaststelling van het aanvraagformulier van de systeembeschrijving van het register, waartoe de artikelen 4 en 6, derde lid, van het Besluit registratie kinderopvang de minister de opdracht geven. Omwille van de gewenste eenvoud van de formulieren zijn die onderscheiden per categorie voorzieningen voor kinderopvang. Ook zijn afzonderlijke formulieren ontwikkeld voor nieuwe aanvragen en voor verzoeken om wijziging in een bestaande registratie. De vaststellingen zijn opgenomen in de nieuwe artikelen 9a en 9b; het formulier en de beschrijving zijn vervat in bijlagen bij deze regeling.

Het nieuwe artikel 9c draagt in het eerste lid de directeur-generaal DUO het beheer op van het register. Dat betreft het feitelijk beheer. Het tweede lid opent de mogelijkheid dat de dienst ook mutaties verzorgt op verzoek van gemeentebesturen – dus optreedt namens een college – dan wel in elk geval mutaties kan aanbrengen gedurende de tijd, dat een gemeente nog niet is aangesloten op het register. Die laatste variant ziet daarmee op de invoeringsperiode.

Onderdeel D

Dit onderdeel neemt vooreerst een misslag weg die is ontstaan bij de overgang van de beleidsverantwoordelijkheid voor de sector kinderopvang van de minister van Sociale Zaken en Werkgelegenheid naar die van Onderwijs, Cultuur en Wetenschap. De wijziging in het vierde lid van artikel 12 strekt er toe de enige tot nu toe bestaande bijlage te nummeren, hetgeen noodzakelijk werd nu met de nieuwe artikelen 9a en 9b ook nieuwe bijlagen aan de Regeling worden toegevoegd.

Artikel II

In dit artikel wordt de overgang van reeds bij een gemeente bekende gegevens van voorzieningen voor kinderopvang naar het landelijk register gepreciseerd. Dat betreft in eerste instantie gastouderbureaus. Het kan daarbij gaan om zowel de al langer geregistreerde voorzieningen, nieuwe beschikkingen als lopende aanvragen. Nadien komen alle voorzieningen aan bod. De gekozen systematiek is uiteengezet aan het slot van het algemene deel van deze toelichting; dit onderdeel betreft een precisering daarbinnen.

Artikel III

Deze wijziging strekt er toe het bestaande model voor het gemeentelijk jaarverslag te vervangen door een meer actueel model.

Artikel IV

Aan de artikelen I en III wordt terugwerkende kracht verleend, omdat anders de regels onverkort zouden gelden zoals die zijn vastgelegd in de wet en het Besluit registratie. In de praktijk is met de nieuw te realiseren systematiek van het Register kinderopvang en de implementatie er van reeds rekening gehouden. Ook het nieuwe model jaarverslag geldt vanzelfsprekend vanaf het begin van het jaar 2010.

De Minister van Onderwijs, Cultuur en Wetenschap,

A. Rouvoet.

Berichten over uw Buurt

Dienstverlening

Beleid & regelgeving

Contactgegevens overheden

Inhoudsopgave

Extra informatie

Geconsolideerde regelgeving

Publicaties referendum

ARTIKEL I

Paragraaf 3. Regels inzake registratie van voorzieningen

Artikel 9a. Formulier

Artikel 9b. Systeembeschrijving

Artikel 9c. Taken van de Dienst Uitvoering Onderwijs

ARTIKEL II

ARTIKEL III

ARTIKEL IV

Projectstartarchitectuur Landelijk Register Kinderopvang

Documenthistorie

1. Inleiding

1.1 Doelgroep

1.2 Scope van dit document

1.3 Leeswijzer

1.4 Relatie met de andere architectuurdocumenten

1.5 Relatie met andere documenten op lager niveau

1.6 Woordenlijst

2 Achtergrond

2.1 Programmacontext

2.2 Probleem en oplossing

2.2.1 Probleem

2.2.2 Oplossing

2.3 Projectaanpak

2.4 Kern van de oplossing

3 Scope en uitgangspunten

3.1 Scope

3.1.1 Processcope ondersteuning

3.1.2 Koppelvlakken

3.1.3 Externe systemen

3.2 Uitgangspunten algemeen en ontwerpbeslissingen

3.3 Kaders en standaarden

4 Bedrijfsarchitectuur

4.1 Inleiding

4.2 Architectuureisen

4.3 Organisatie

4.4 Processen

4.4.1 Positionering ten opzicht van NORA paradigma

4.4.2 Ketenproces Registreren nieuwe kinderopvang

4.4.2.1 Procesdecompositie binnen ketenproces Registreren nieuwe kinderopvang

4.4.2.2 ICT-ondersteuning functies tbv Registreren

4.4.3 Ketenproces Wijzigen registratie kinderopvang

4.4.3.1 Procesdecompositie binnen ketenproces Wijzigen registratie kinderopvang

4.4.3.2 Procesdecompositie binnen ketenproces Wijzigen registratie kinderopvang

4.4.4 Functionele decompositie Inspecteren, Handhaven en Gebruiken

4.5 Diensten en services

4.5.1 Diensten

4.5.2 Geleverde services

4.5.3 Gebruikte services

5 Informatiearchitectuur

5.1 Architectuuropzet

5.2 Architectuurplaat

5.3 Architectuureisen

5.3.1 Relevante principes Referentiearchitectuur Onderwijs

5.3.2 Relevante NORA principes

5.3.2.1 Applicaties

5.3.2.2 Gegevens

5.4 Gegevens

5.4.1 Ontwerpbeslissingen gegevensmodel

5.4.2 Logisch gegevensmodel Landelijk Register

5.4.3 Objectdefinities

5.4.3.1 Abstracties

5.4.3.2 LR-objecten

5.4.3.3 LR hulpobjecten

5.4.4 Historie en tijdslijnen

5.4.4.1 Wettelijke eisen

5.4.4.2 Basis principes

5.5 Berichten

6 Technische architectuur

6.1 Architectuureisen

6.2 Applicatie en database

6.2.1 Applicatie-gerelateerd

6.2.1.1 Webrichtlijnen