Regeling van de Minister van Sociale Zaken en Werkgelegenheid van 28 september 2004, Directie Arbeidsverhoudingen, nr. AV/KO/2004/65638, houdende nadere regels ter zake van enkele in de Wet kinderopvang geregelde onderwerpen (Regeling Wet kinderopvang)

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.

Aan de databases worden eisen gesteld op de gebieden volume, groei, beveiliging en beschikbaarheid. Voor wat het volume betreft moet de database in staat zijn om zeventigduizend voorzieningen (organisaties voor kinderopvang en peuterspeelzalen) met bijbehorende houders te bevatten. Daarnaast moet de database ingesteld zijn op een jaarlijkse aanwas van tien procent gedurende een periode van zeven jaar. (Na zeven jaar mogen gegevens die niet langer worden gebruikt worden verwijderd.)

Op het gebied van beveiliging van databases geldt dat die moet voldoen aan de maatregelen die horen bij WBP risicoklasse II op basis van Achtergrondstudies en Verkenning 23 (AV23).

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

5.3.2.1. Applicaties

6.1.2.2. KOT&B

5.3.2.1. Applicaties

KOT&B draait in een Oracle cluster onder Oracle Linux.

6.2. Middleware

Binnen LR KO&PSW wordt gebruikgemaakt van GlassFish als applicatie server en Digikoppeling als service bus.

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

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

7. Beheer

Op dit moment is het beheer nog verdeeld over twee organisaties. Het applicatiebeheer is belegd bij ICTU, de partij die het systeemcomplex heeft ontwikkeld. DUO is belast met het beheer van de informatievoorziening en de technische infrastructuur. Er wordt gewerkt aan de overdracht van het applicatiebeheer van ICTU naar DUO. Deze overdracht staat gepland voor begin 2012.

7.1. Beheer informatievoorziening

Bij het beheer van de informatievoorziening wordt onderscheid gemaakt naar systeembeheer en functioneel beheer. Beide taken zijn bij DUO belegd.

7.1.1. Systeembeheer

Systeembeheer is verantwoordelijk voor het zorgen voor een betrouwbaar en – op de juiste momenten – beschikbaar systeemcomplex LR KO&PSW, inclusief de koppelingen naar de buitenwereld. Tot de taken van systeembeheer behoren:

7.1.2. Functioneel beheer

5.4.3.2. LR-objecten

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

Het beheer van de applicaties die deel uitmaken van het systeemcomplex LR KO&PSW is, met uitzondering van het applicatiebeheer op de BAP Services, belegd bij ICTU. ICTU brengt in overleg met de gebruikers en DUO onder aansturing van de Change Advisory Board (CAB) de gewenste wijzigingen aan in de applicaties van het systeemcomplex, test of de wijzigingen voldoen aan de eisen op gebied van functionaliteit, kwaliteit en beveiliging, en test of de aangebrachte wijzigingen de niet hebben geresulteerd in verstoring van de eerder correcte werking van de applicaties.

De aanpassingen in de applicaties worden door ICTU gebundeld tot releases, en aan DUO overgedragen ter implementatie. DUO draagt zorg voor het in productie nemen van nieuwe releases.

7.3. Beheer technische infrastructuur

Het systeemcomplex draait op de infrastructuur van DUO. DUO beheert die infrastructuur en heeft in verband daarmee onder andere de volgende taken:

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:

Op basis van Achtergrondstudies en Verkenning 23 (AV23) Fout! Verwijzingsbron niet gevonden. zijn de in het systeemcomplex opgeslagen gegevens geclassificeerd als vallend in WBP risicoklasse II. De organisaties die gebruik maken van het systeemcomplex hebben de bij deze classificatie behorende beveiligingsmaatregelen getroffen.

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

Binnen de informatiearchitectuur kunnen een beveiligd en een onbeveiligd deel worden onderscheiden. Het onbeveiligde deel is het publieksportaal. Via dat portaal kan een die over internet beschikt toegang krijgen tot de publieke inhoud van de registers kinderopvang en peuterspeelzalen. Bij de constructie van het publieksportaal is zorg gedragen dat alleen gegevens die volgens de wet- en regelgeving openbaar moeten zijn kunnen worden benaderd. Het niet kunnen benaderen van privacygevoelige informatie is door onafhankelijke derden getest.

De toegang tot het beveiligde deel van het systeemcomplex is voorbehouden aan geregistreerde gebruikers, die zich daartoe eerst moeten authenticeren middels een wachtwoord en een eenmalig token met een beperkte geldigheidsduur. De autorisaties die middels deze authenticatie wordt verkregen, is afhankelijk van de rol(len) die de gebruiker zijn toegewezen. Deze rollen worden door de organisatie waarvoor de gebruiker werkt aan de gebruiker toegekend op basis van zijn functie. Deze rollen worden door de beheerder van het systeemcomplex – op verzoek van die organisatie – gekoppeld aan die gebruiker.

Inrichting van het register:

Het systeemcomplex draait op de beveiligde infrastructuur van DUO. Het netwerk waarop de servers draaien is door een DMZ gescheiden van het internet. Via internet kan alleen via een beveiligde verbinding gebruik worden gemaakt van het systeemcomplex. Het berichtenverkeer met de GBA loopt via het beveiligde GemNet, en dat met de belastingdienst via een beveiligde Digikoppeling.

A. Referenties

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.

5.5. Berichten

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. 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. Een service levert een (tussen) resultaat aan een andere overheidsorganisatie, ambtenaar of applicatie.

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

‘Ketenproces’ of interactieperspectief

6. Technische architectuur

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.

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 OMSCHRIJVINGEN VAN DE BASISPRINCIPES VAN NORA ZIJN LETTERLIJK OVERGENOMEN UIT DE NEDERLANDSE REFERENTIE ARCHITECTUUR, VERSIE 3.0, D.D. 19 AUGUSTUS 2009

Overheidsbeleid:

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.

6.2. Applicatie en database

6.2.1. Applicatie-gerelateerd

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:

Aannames over gebruikersaantallen en gegevensomvang:

Resultante eisen op basis van deze aannames:

6.2. Applicatie en database

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.

6.2.1.1. Webrichtlijnen

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

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

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

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

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

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

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

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

6.4. Platformen

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.

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:

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

Deze paragraaf beschrijft de uitgangspunten betreffende platformen.

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:

6.5. Netwerkarchitectuur

Transparant vanwege het gebruik van Java.

6.5. Netwerkarchitectuur

De eisen die gesteld moeten worden betreffende infrastructurele software zijn:

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.

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

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.

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.

7.1. Eisen

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.

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.

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

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.

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

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

8.1.1. Typering van informatie: WBP-classificatie

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

8.1.1. Typering van informatie: WBP-classificatie

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.

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.

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:

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:

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:

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:

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

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:

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.

8.4. Te nemen algemene beveiligingsmaatregelen

B. NORA-definities

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:

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.

B. NORA-definities

Documenthistorie

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.

Procesmodel LRK-applicatie

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

Het globaal functioneel procesmodel 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. 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.

1.3. Scope

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

Dit document is bedoeld voor:

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.

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

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.

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

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

2.2. Functionele decompositie

Hierbij is een drietal systeemcomponenten onderkend:

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.

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

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

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

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.

2.3.1.1. Vastleggen ontvangen aanvraag voor registratie

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.

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.

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

2.3.1.1.1. Inloggen gegevensverwerker Gemeente

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

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

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.

2.3.1.1.2. Vastleggen voorlopige gegevens van nieuwe OKO

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

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

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

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

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.

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.

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.

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

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

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

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.

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.

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.

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.

2.3.2. Verwerken van wijzigingen

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

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

2.3.3. Raadplegen via publieksportaal

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

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

2.3.4. Raakvlakken met Interactiemodel

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.

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

3.1.2. Overheidsportaal

De volgende use cases maken gebruik van het Publieksportaal:

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.

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:

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:

3.3. Relatie use-cases en modules

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

De use cases gebruiken de verschillende modules.

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

De modules zijn benoemd vanuit verschillende invalshoeken.

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:

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

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

4.4. Module Natuurlijke personen

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:

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.

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.

4.5. Module Niet-natuurlijke personen

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

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

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

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.

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:

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:

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.

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.

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.

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

4.10. Module Management informatie

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

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

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.

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.

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.

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.

4.13. Module Help

5.1. Primaire proces

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

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.

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

Interactie Ontwerp

5.4. Beheer stamgegevens en management informatie

Interactie Ontwerp

A. Referenties

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

Documenthistorie

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

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.

Dit document is bedoeld voor:

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.

Dit document is opgesplitst in een aantal hoofdstukken:

Dit document is opgesplitst in een aantal hoofdstukken:

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.

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.6. Openstaande punten

2. Basisstructuur

1.6. Openstaande punten

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

Deze zaken verdienen extra aandacht bij uitwerking in het DFO.

1.7. Externe bronverwijzing

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

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

2.2. Overheidsportaal

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

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 is het portaal dat gebruikt wordt door bevoegde functionarissen om de gegevens van organisaties van kinderopvang te registreren (invoeren, wijzigen) en te gebruiken (raadplegen).

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.

2.4. Beheerinterface

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

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.

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.

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.

3.2. Schermopbouw

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

3.3. Navigatiestructuur

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

3.3.3. Kruimelpad

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

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

Er wordt onderscheid gemaakt naar twee soorten help.

3.4. Helpfuncties

Er wordt onderscheid gemaakt naar twee soorten help.

3.5. Printen van informatie

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

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

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

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

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

3.7. Authenticatie

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

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

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

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

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

3.8. Fout- en andere meldingen

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.

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.

3.9. Gebruik van stamtabellen

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

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.

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

4.1. Rollen

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.

4.1. Rollen

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

4. Gebruikers

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

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

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.

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.

5.2. Wachtwoord vergeten

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.

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:

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:

Het zoekgedeelte van de pagina bestaat uit:

Het zoekgedeelte van de pagina bestaat uit:

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

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

5.5. Tonen gegevens Houder

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.

5.5. Tonen gegevens Houder

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:

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.

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:

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.

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.

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

5.7.1. Start registreren OKO

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:

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.

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

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

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:

5.7.2.2. Invoeren detailgegevens

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

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

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.

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.

5.7.3. Registreren VGO

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

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

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

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:

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

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.

5.7.3.3. Invoeren detailgegevens

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

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

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

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

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

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

5.8. Detailstap: toewijzen Houder

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.

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:

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:

5.8.1. Registreren Natuurlijk Persoon

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.

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:

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:

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

5.11. Detailstap: registreren adresgegevens

Het registratieproces doorloopt de volgende stappen:

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:

5.12. Wijzigen van 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.

5.12.1.1. Wijzigen kerngegevens en status

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

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

5.12.1.1. Wijzigen kerngegevens en status

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

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:

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:

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:

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.

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.

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

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

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.

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:

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.

7. Beheerfunctionaliteit

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

7.1. Onderhouden gegevens gemeente

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

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.

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

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

7.2.1. Tonen lijst GGD's

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

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

7.2.3. Toevoegen nieuwe GGD

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.

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

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

7.3.2. Wijzigen gebruiker

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

7.3.3. Beheren autorisaties gebruiker

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

7.3.4. Toevoegen nieuwe gebruiker

7.3.3. Beheren autorisaties gebruiker

Functioneel Datamodel

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

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

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.

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

1.1. Doel

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.

1.3. Scope

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

Dit document is bedoeld voor:

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

2.1. Register

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.

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

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.

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

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

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

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

De status van een OKO.

Naam van de organisatie voor kinderopvang.

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.

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

Is een soort OKO.

Is een type KC.

Is een type KC.

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.

Is een soort OKO.

Kinderopvang:

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

Nadere gegevens omtrent de geboden opvang.

2.2. Overheids Portaal

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

2.2. Overheids Portaal

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

2.3. Publieks Portaal

Interface module, geen eigen data.

2.4. Natuurlijke Personen

2.3. Publieks Portaal

Interface module, geen eigen data.

Is een adres, in Nederland.

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

Is een adres, in Nederland.

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