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)

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

Is een adres, in Nederland.

Is een adres, in Nederland.

2.7. Gebruikers en autorisaties

Is een postadres.

Is een postadres.

Is een adres, niet in Nederland.

Van contactgegevens wordt geen mutatiehistorie vastgelegd!

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

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

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

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

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

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.

Is een medewerker, van een bepaalde GGD.

Heeft aanvullende kenmerken:

2.8. Authenticatie

Heeft aanvullende kenmerken:

2.8. Authenticatie

Is een medewerker, van de Belastingdienst.

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

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

2.9. Documenten

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

2.10. Management informatie

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

Document dat wordt opgeleverd bij inspectie van een OKO.

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.

Deze module heeft geen eigen data.

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.

2.12. Beheer

Tijd-assen van aangebrachte wijzigingen.

Registratie van een gebeurtenis (event).

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

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

Definieert alle mogelijke postcodes en postcode/huisnummer combinaties.

Definieert alle mogelijke postcodes en postcode/huisnummer combinaties.

Legt relatie tussen postcode/huisnummer en straatnaam.

Legt relatie tussen het numeriek deel van de postcode en woonplaats

Definieert alle mogelijke woonplaatsen.

Legt relatie tussen woonplaats en gemeente.

2.13. Help

Definieert alle mogelijke landen.

Bijlage 3

Bijlage

Ligt ter inzage bij het Ministerie van Onderwijs, Cultuur en Wetenschap en is gepubliceerd op www.ocw.nl en www.onderwijsinspectie.nl.

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

Artikel 17a. Gewijzigde uitvoering voor het kalenderjaar 2010

Vervallen

Bijlage 1. als bedoeld in artikel 9b

Systeembeschrijving registers kinderopvang en peuterspeelzaalwerk.

Tevens is aan het LRKP een toezichts- en handhavingssysteem gekoppeld: de Gemeenschappelijke Inspectieruimte (GIR). Deze GIR is via het Overheidsportaal toegankelijk voor GGD’en en gemeenten en wordt gebruikt om toezicht en handhaving te faciliteren: toezichtsgegevens kunnen makkelijk in het systeem worden vastgelegd en inspectierapporten en handhavingsbrieven kunnen worden gegenereerd. Tevens kan gemakkelijk informatie worden uitgewisseld tussen GGD en gemeente. De GIR wordt ook gebruikt bij het genereren van de jaarverantwoording door gemeenten aan de Inspectie van het Onderwijs (de tweedelijns toezichthouder).

Documenthistorie

Tevens is aan het LRK een toezichts- en handhavingssysteem gekoppeld: de Gemeenschappelijke Inspectieruimte (GIR). Deze GIR is via het Overheidsportaal toegankelijk voor GGD’en en gemeenten en wordt gebruikt om toezicht en handhaving te faciliteren: toezichtsgegevens kunnen makkelijk in het systeem worden vastgelegd en inspectierapporten en handhavingsbrieven kunnen worden gegenereerd. Tevens kan gemakkelijk informatie worden uitgewisseld tussen GGD en gemeente. De GIR wordt ook gebruikt bij het genereren van de jaarverantwoording door gemeenten aan de Inspectie van het Onderwijs (de tweedelijns toezichthouder).

1.3. Leeswijzer

Het LRK staat in verbinding met het toeslagensysteem van de Dienst Toeslagen, die het LRK gebruikt bij de toekenning van de kinderopvangtoeslag.

2. Achtergrond

De binnenkomende aanvragen en bewijsstukken worden in eerste instantie verzameld en handmatig verwerkt. Dit wordt onder andere zo gedaan omdat het belangrijk is de bewijsstukken fysiek te kunnen beoordelen. Nadat een beschikking is afgegeven wordt het dossier als één geheel gescand en zowel fysiek als digitaal gearchiveerd.

2.3. Kern van de oplossing

De informatieverstrekking van het college aan de minister over de uitvoering van de bij of krachtens de wet opgedragen taken toezicht en handhaving in het kader van de wet- en regelgeving kinderopvang en peuterspeelzalen, dient jaarlijks uiterlijk op 1 juli plaats te vinden.

Informatieverstrekking over de toezicht- en handhavingstaken

De informatieverstrekking van het college aan de minister over de uitvoering van de bij of krachtens de wet opgedragen taken toezicht en handhaving in het kader van de wet- en regelgeving kinderopvang en peuterspeelzalen, dient jaarlijks uiterlijk op 1 juli plaats te vinden.

A. Criterium Registervoering

De informatieverstrekking geschiedt aan de hand van de criteria die hieronder zijn opgenomen.

A. Criterium Registervoering

Reden voor de introductie van deze nieuwe wet is meerledig:

C. Criterium ‘uitvoering inspecties’ kindercentra, buitenschoolse opvang, gastouderbureaus en voorzieningen gastouderopvang

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.

2.3. Projectaanpak

Het systeemcomplex wordt gebruikt om de volgende services te leveren:

4.3. Processen

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.

3. Scope en uitgangspunten

In deze context ziet de omgeving als volgt uit:

5.1. Mensen en applicaties

Het systeemcomplex LR KO&PSW bestaat uit de volgende applicaties:

5.1.3. CU-Matrix

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.

5.2.1. Objectmodel

Het centrale object binnen LR KO&PSW is de Voorziening. Een Voorziening is van een Houder, en heeft een Adres. Voorzieningen zijn of een OKO, of een peuterspeelzaal. Geregistreerde Voorzieningen zijn opgenomen in registers. Geregistreerde OKO's in het Landelijk Register Kinderopvang; geregistreerde peuterspeelzalen in het Landelijk Register Peuterspeelzalen. Relevante objecten in de omgeving van LR KO&PSW zijn de Persoonsgegevens bij GBA, en de Geregistreerde Organisaties voor Kinderopvang bij de belastingdienst.

5.2.1.1. Object Houder

In deze fase zijn nog geen externe systemen in scope.

3.1.3. Externe systemen

Een Voorziening heeft een status. Wanneer een Voorziening wordt aangemeld bij een gemeente wordt de status op ‘Aangemeld’ gezet. Na de beschikking van het college wordt die status veranderd in ‘Geregistreerd’ of ‘Afgewezen’. Wanneer de exploitatie van een Voorziening stopt wordt de status veranderd in ‘Niet meer geregistreerd’.

5.2.1.3. Object Adres

Het Landelijk register kinderopvang is de verzameling van alle OKO's die geregistreerd staan, of geregistreerd hebben gestaan.

5.2.1.5. Object Landelijk register peuterspeelzalen

Het Landelijk register peuterspeelzalen is de verzameling van alle peuterspeelzalen die geregistreerd staan, of geregistreerd hebben gestaan.

5.2.1.6. Object Persoonsgegevens

Het systeemcomplex LR KO&PSW stuurt de belastingdienst berichten die de belastingdienst gebruikt om het object Geregistreerde organisaties voor kinderopvang op te bouwen.

5.2.2. Gegevens

Deze gegevensgroep is een afbeelding van het centrale deel van het object Voorziening. De groep bevat de gegevens van een organisatie voor kinderopvang of peuterspeelzaal. Mutaties op deze gegevensgroep kunnen met betrekking op verleden, heden en toekomst worden aangebracht. De mutatiehistorie van deze gegevensgroep wordt vastgelegd, om tijdreizen mogelijk te maken. (Tijdreizen maakt het mogelijk om te bepalen hoe een gegevensgroep er op een bepaalde dag uit heeft gezien/ uit zal zien.)

4.3. Organisatie

Deze groep heeft een relatie met de gegevensgroep:

4.4. Processen

Deze groep heeft een relatie met de gegevensgroepen:

4.4.1. Positionering ten opzicht van NORA paradigma

Verantwoordelijk voor de uitvoering:

4.4.1. Positionering ten opzicht van NORA paradigma

Deze groep heeft een relatie met de gegevensgroepen:

4.4.2. Ketenproces Registreren nieuwe kinderopvang

Deze gegevensgroep bevat de gegevens van de GGD-en.

4.4.2.2. ICT-ondersteuning functies tbv Registreren

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

4.4.3. Ketenproces Wijzigen registratie kinderopvang

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

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.

4.4.3.1. Procesdecompositie binnen ketenproces Wijzigen registratie kinderopvang

De publieksportaal client is in essentie een webbrowser draaiend op een platform dat verbonden is met het internet. In principe kan hiervoor elke webbrowser worden gebruikt, maar de werking is alleen met een aantal specifieke browsers getest, en alleen die browsers worden ondersteund. De ondersteunde browsers zijn Internet Explorer versie 6, 7 en 8, en Firefox versie 3.6. Waarbij geldt dat alleen de laatste (van alle patches voorziene) varianten van deze versies worden ondersteund.

6.1.1.2. Publieksportaal (PP)

Het publieksportaal draait in een GlassFish cluster onder CentOS Linux.

6.1.1.3. OP Client

De overheidsportaal client is in essentie een webbrowser draaiend op een platform dat verbonden is met het internet. In principe kan hiervoor elke webbrowser worden gebruikt, maar de werking is alleen met een aantal specifieke browsers getest, en alleen die browsers worden ondersteund.

4.5.1. Diensten

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:

4.5.2. Geleverde services

Deze applicatie wordt door beheer gebruikt voor het onderhouden van gebruikers met rollen en rechten, en het beheren van tabellen.

4.5.3. Gebruikte services

BAP Services is een maatwerk applicatie voor het raadplegen van de GBA.

5.2. Architectuurplaat

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.

5.2. Architectuurplaat

De koppeling draait in GlassFish onder CentOS Linux.

6.1.2. Databases

Het LR is een Oracle database waarin de gegevens van de registers worden opgeslagen.

5.3.2. Relevante NORA principes

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

Binnen LR KO&PSW wordt gebruikgemaakt van de operating systemen Linux, in de smaken CentOS en Oracle, en MS Server.

6.4. Netwerkarchitectuur

De clients maken via https over het Internet contact met het beveiligde LAN van DUO, waarin de servers van LR KO&PSW staan opgesteld. GBA Services is via SuwiNet en GemNet verbonden met GBA-V. Voor de koppeling met de belastingdienst wordt gebruikgemaakt van een digikoppeling van het type ebMS.

5.4.3. Objectdefinities

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.

5.4.3. Objectdefinities

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.

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.

7.2. Beheer applicaties

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

5.4.4.1. Wettelijke eisen

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.

B. NORA-definities

In deze bijlage staan de relevante definities uit NORA opgenomen.

5.5. Berichten

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

6.1. Architectuureisen

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

6.2. Applicatie en database

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.

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.

6.2.1.1. Webrichtlijnen

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

6.3. Middleware

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

6.4. Platformen

Hardware en Operating Systeem:

6.5. Netwerkarchitectuur

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.

6.5. Netwerkarchitectuur

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

6.5. Netwerkarchitectuur

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.

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

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

7.1. Eisen

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

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

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.

8.1.2. Functies van informatiebeveiliging

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.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. Aandachtspunten per component

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:

8.2.2. Overheidsportaal

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

Vooruitlopend op deze uitwerking zijn de volgende eisen te hanteren:

A. Referenties

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:

A. Referenties

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.

Documenthistorie

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.

Procesmodel LRK-applicatie

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

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

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

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.

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.

1.5. Leeswijzer

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

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

2.2. Functionele decompositie

Daarnaast wordt een systeemcomponent onderkend ten behoeve van het beheer.

2.2. Functionele decompositie

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

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

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

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

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.

2.3.1.2. Vastleggen inspectierapport

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

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.

2.3.1.4. Afronden registratie

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

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.

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.

2.3.3. Raadplegen via publieksportaal

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

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.

3. Overview use cases

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

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.1.3. Landelijk register services

De volgende use cases maken gebruik van het Overheidsportaal:

3.1.3. Landelijk register services

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

3.3. Relatie use-cases en modules

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

4. Modules LRK-applicatie

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

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.

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.

4.4. Module Natuurlijke personen

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.

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

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.

4.8. Module Authenticatie

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

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

4.9. Module Documenten

Er wordt geen relatie gelegd naar document management systemen.

4.10. Module Management informatie

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

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.

5. High level collaboration diagram

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

5. High level collaboration diagram

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:

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:

5.2. Gebruikers/authenticatiebeheer

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.

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

1. Inleiding en achtergrond

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

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 opgesplitst in een aantal hoofdstukken:

1.4. Leeswijzer

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.

1.6. Openstaande punten

Dit document is opgesteld met gebruikmaking van:

2. Basisstructuur

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

2. Basisstructuur

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

2.2. Overheidsportaal

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.

2.4. Beheerinterface

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

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

De schermen kennen de volgende algemene opbouw.

3.3. Navigatiestructuur

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.2. Secundaire navigatie

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

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

3.4. Helpfuncties

Er wordt onderscheid gemaakt naar twee soorten help.

3.5. Printen van informatie

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

3.7. Authenticatie

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

3.8. Fout- en andere meldingen

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.

3.9. Gebruik van stamtabellen

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

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.

4. Gebruikers

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

4.1. Rollen

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.

5.2. Wachtwoord vergeten

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

5.2. Wachtwoord vergeten

Het zoekgedeelte van de pagina bestaat uit:

5.3.1. Zoeken

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

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

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

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

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

5.6. Tonen gegevens OKO

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

5.6.1. Kerngegevens

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

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.

5.6.5. (Link naar) historische gegevens

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

5.7. Nieuwe aanvraag

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

5.7.1. Start registreren OKO

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

5.7.2. Registeren Kindercentrum en Gastouderbureau

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

5.7.2.2. Invoeren detailgegevens

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

5.7.2.2. Invoeren detailgegevens

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.

5.7.3. Registreren VGO

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

5.7.3.1. Toewijzen Gastouderbureau

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

5.7.3.3. Invoeren detailgegevens

De gebruiker heeft de volgende mogelijkheden:

5.7.3.3. Invoeren detailgegevens

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

5.8. Detailstap: toewijzen Houder

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

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

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.8.2. Registreren Niet Natuurlijk Persoon

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 Gastouder nog niet bekend is in het register dan dient deze te worden geregistreerd. De Gastouder is altijd een Natuurlijk Persoon.

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.

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:

5.12. Wijzigen van gegevens

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

5.12.1. Wijzigen Kindercentrum en Gastouderbureau

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

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.

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.

5.12.1.3. Wijzigen betrokken 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. 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.1. Wijzigen kerngegevens

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:

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

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

5.12.3.4. Wijzigen bemiddelingsrelatie GOB

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

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.

7. Beheerfunctionaliteit

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

Via dit scherm kan de beheerder gegevens van een gemeente (bijvoorbeeld gemeentenaam, URL, adres, telefoonnummer; koppeling met GGD) 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.

7.2. Onderhouden gegevens GGD

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

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

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.3. Beheren gebruikers

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

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.

7.3.3. Beheren autorisaties gebruiker

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

7.3.4. Toevoegen nieuwe gebruiker

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

Documenthistorie

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 globaal functioneel datamodel beschrijft de gegevens die nodig worden geacht voor ondersteuning van de gewenste functionaliteit.

1.2. Doelgroep

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

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

2. Classes

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

2.2. Overheids Portaal

Is een houder. Heeft aanvullende kenmerken:

2.2. Overheids Portaal

Is een houder. Heeft aanvullende kenmerken:

2.2. Overheids Portaal

Interface module, geen eigen data.

2.5. Niet-Natuurlijke Personen

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

2.7. Gebruikers en autorisaties

Is een medewerker, van een bepaalde gemeente.

2.8. Authenticatie

Is een medewerker, van de Inspectie van het Onderwijs.

2.8. Authenticatie

Aanvullende gegevens nodig voor afhandeling van het authenticatieproces.

2.9. Documenten

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

2.10. Management informatie

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.

2.12. Beheer

Definieert alle mogelijke gemeenten.

2.13. Help

Is een Gemeente. Heeft aanvullende kenmerken:

Bijlage 3

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

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

Artikel 10d. Bewijsstukken van met goed gevolg afgesloten onderricht dat in elk geval omvat eerste hulp aan kinderen bij ongevallen

• a. aantoonbare kennis van en inzicht in de voor eerstehulpverlening relevante fysieke verschillen tussen zuigelingen, kinderen en volwassenen;

• b. aantoonbare kennis van en inzicht in het gedrag van zuigelingen en kinderen bij ongeval en ziekte alsmede aantoonbare vaardigheid om daarop adequaat te reageren;

• c. aantoonbare vaardigheid in het verlenen van eerste hulp aan zuigelingen en kinderen bij veelvuldig voorkomende stoornissen in de vitale functies en plaatselijke letsels;

• d. aantoonbare kennis van en inzicht in de gevaren die in het bijzonder zuigelingen en kinderen bedreigen; en

• e. aantoonbare kennis van en inzicht in de wijze waarop ongevallen bij zuigelingen en kinderen kunnen worden voorkomen.

• a. zij is onafhankelijk;

• b. zij verzorgt zelf geen onderwijs met betrekking tot het te verlenen certificaat;

• c. zij biedt zelf geen onderwijs aan met betrekking tot het te verlenen certificaat;

• d. zij schrijft geen onderwijsmethode en onderwijsmateriaal voor met betrekking tot het te verlenen certificaat;

• e. zij geeft zelf het certificaat af voor maximaal twee jaar;

• f. zij ziet zelf toe op de kwaliteit van het voor het verkrijgen van het certificaat af te leggen examen; en

• g. zij registreert zelf de behaalde certificaten en de geldigheidsduur in een register.

Paragraaf 5. Administratie van gegevens bij kindercentra en gastouderbureaus

Paragraaf 5a. Bepalingen voor gastouderbureaus en vraagouders

Paragraaf 5b. Administratie van gegevens peuterspeelzalen

Paragraaf 7a. Aanwijzing van gelijkgestelde buitenlandse kinderopvangvoorzieningen

Artikel 17a*

Deze regeling berust mede op artikel 4, eerste lid, van het Besluit basisvoorwaarden kwaliteit voorschoolse educatie.

Bijlage 1e

Bijlage 1. , behorende bij artikel 9b

Projectstartarchitectuur Landelijk Register Kinderopvang

Systeembeschrijving landelijk register kinderopvang.

Systeembeschrijving register buitenlandse kinderopvang

Systeembeschrijving register buitenlandse kinderopvang

3.1. Scope

De benodigde gegevens worden zoveel mogelijk uit de bestaande landelijke gebruikers- en uitvoeringssystemen (het Landelijk Register Kinderopvang en Peuterspeelzalen (LRKP) en de Gemeenschappelijke Inspectie Ruimte (GIR)) gehaald. Deze worden per gemeente verwerkt in een jaarlijks overzicht ten behoeve van de jaarverantwoording kinderopvang en peuterspeelzalen. Dit overzicht wordt vervolgens op de website www.waarstaatjegemeente.nl beschikbaar gesteld.

Informatieverstrekking over de toezicht- en handhavingstaken

A. Criterium Registervoering

De benodigde gegevens worden zoveel mogelijk uit de bestaande landelijke gebruikers- en uitvoeringssystemen (het Landelijk Register Kinderopvang (LRK) en de Gemeenschappelijke Inspectie Ruimte (GIR)) gehaald. Deze worden per gemeente verwerkt in een jaarlijks overzicht ten behoeve van de jaarverantwoording kinderopvang. Dit overzicht wordt vervolgens op de website www.waarstaatjegemeente.nl beschikbaar gesteld.

B. Criterium tijdig afgehandeld kindercentra, buitenschoolse opvang, gastouderbureaus en voorzieningen gastouderopvang

A. Criterium Registervoering

2.2.2. Oplossing

2.4. Kern van de oplossing

3. Scope en uitgangspunten

3.2. Uitgangspunten algemeen en ontwerpbeslissingen

5.2.1.7. Object Geregistreerde organisaties voor kinderopvang

5.2.2.1. LRK

4.3. Organisatie

4.4. Processen

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

Aan de applicaties van het systeemcomplex worden eisen op het gebied van performance, beveiliging en beschikbaarheid gesteld. De eisen op het gebied van performance hebben betrekking op de door de gebruiker ervaren reactietijd van het systeemcomplex. Dit is gedefinieerd als de tijd die verstrijkt tussen het moment waarop een gebruiker op een scherm zijn wensen heeft kenbaar gemaakt (door het invullen van nul, een of meer velden gevolgd door het drukken op een knop die de verwerking triggert), en het moment waarop de inhoudt van het scherm begint te veranderen. Voor normale transacties is die reactietijd gesteld op 3 à 4 seconden (operationeel: in 95% van de gevallen mag die reactietijd niet langer zijn dan 4 seconden). Voor bijzondere transacties (complexe zoekopdrachten en transacties met documenten) mag de reactie tijd oplopen tot tien seconden (mag in 95% van de gevallen niet groter zijn dan 10 seconden).

4.4.4. Functionele decompositie Inspecteren, Handhaven en Gebruiken

6.1.1.1. PP Client

5. Informatiearchitectuur

5.3. Architectuureisen

Het LR draait in een Oracle cluster onder Oracle Linux.

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

5.4.3.3. LR hulpobjecten

5.4.4. Historie en tijdslijnen

8.1. Beveiligingsaspecten bedrijfsarchitectuur

5.5. Berichten

6.1. Architectuureisen

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:

6.2.1. Applicatie-gerelateerd

6.2. Applicatie en database

6.2.1.1. Webrichtlijnen

6.3. Middleware

6.4. Platformen

6.6. Overzichtsplaat op hoofdlijnen

8. Beveiliging

8.2.3. Publieksportaal

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

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.

2. Procesondersteuning door de LRK-applicatie

2.3. Procesflows

2.3.1.1. Vastleggen ontvangen aanvraag voor registratie

2.3.1.1.2. Vastleggen voorlopige gegevens van nieuwe OKO

2.3.1.1.3. Invoeren gegevens houder (gastouder)

2.3.1.2. Vastleggen inspectierapport

2.3.1.3. Vastleggen definitieve inschrijving van OKO in LRK

2.3.1.4. Afronden registratie

4. Modules LRK-applicatie

4.2. Module Publieksportaal

4.3. Module Overheidsportaal

4.4. Module Natuurlijke personen

4.5. Module Niet-natuurlijke personen

4.7. Module Gebruikers

4.8. Module Authenticatie

4.9. Module Documenten

4.11. Module Audit trail/tijdreizen

4.12. Module Beheer

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

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

Interactie Ontwerp

1.5. Relatie met andere documenten

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

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

1.7. Externe bronverwijzing

2.3. Publieksportaal

3.1. Relatie Overheidsportaal en Publieksportaal

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.3.1. Primaire navigatie

3.3.3. Kruimelpad

3.5. Printen van informatie

3.7. Authenticatie

3.8. Fout- en andere meldingen

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.

5. Overheidsportaal

5.4. Tonen zoekresultaten (OKO en Houders)

5.7.2. Registeren Kindercentrum en Gastouderbureau

5.7.2.3. Controleren ingevoerde gegevens

5.7.3. Registreren VGO

5.7.3.2. Toewijzen Gastouder of Houder VGO

5.7.3.4. Controleren ingevoerde gegevens

5.8. Detailstap: toewijzen Houder

5.13. Rapportages

6. Publieksportaal

7.3.1. Zoeken gebruikers

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

Functioneel Datamodel

1.5. Leeswijzer

2. Classes

2.4. Natuurlijke Personen

2.5. Niet-Natuurlijke Personen

2.7. Gebruikers en autorisaties

2.8. Authenticatie

2.10. Management informatie

2.12. Beheer

2.13. Help

Contactgegevens van een GGD.

Bijlage 3

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

Artikel 17b

Deze regeling berust mede op artikel 4, eerste lid, van het Besluit basisvoorwaarden kwaliteit voorschoolse educatie.

Artikel 17a*

Deze regeling berust mede op artikel 4, eerste lid, van het Besluit basisvoorwaarden kwaliteit voorschoolse educatie.

Bijlage 1g

1.2. Scope van dit document

1.2. Scope van dit document

1.3. Leeswijzer

Informatieverstrekking over de toezicht- en handhavingstaken

De informatieverstrekking geschiedt aan de hand van de criteria die hieronder zijn opgenomen.

4.2. Diensten en services

2.4. Kern van de oplossing

5.1.1. Mensen

5.1.2. Applicaties

3.1.3. Externe systemen

3.3. Kaders en standaarden

5.2.1.4. Object Landelijk register kinderopvang

4.1. Inleiding

4.2. Architectuureisen

4.3. Organisatie

4.4. Processen

4.4.2.1. Procesdecompositie binnen ketenproces Registreren nieuwe kinderopvang

4.4.2.2. ICT-ondersteuning functies tbv Registreren

6.1.1.6. Overheidsportaal (OP)

5.1. Architectuuropzet

5.3.1. Relevante principes Referentiearchitectuur Onderwijs

6.1.2.1. LR

KOT&B is een Oracle database waarin de gegevens van de gebruikers, met rollen en rechten, en de verschillende tabellen worden opgeslagen.

6.3. Platformen

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

Functioneel beheer draagt zorg voor het – als benodigd en gewenst – kunnen gebruiken van het systeemcomplex LR KO&PSW. Tot de taken van functioneel beheer behoren:

5.4.4.2. Basis principes

6. Technische architectuur

6. Technische architectuur

6.1. Architectuureisen

6.2.2. Database-gerelateerd

6.2.2. Database-gerelateerd

6.3. Middleware

6.4. Platformen

7. Beheer

8.1. Kaders, standaarden en achtergrondinformatie

8.1. Kaders, standaarden en achtergrondinformatie

8.1.3. Beveiligingsmechanismen

8.3. Algemene beveiligingseisen

8.3. Algemene beveiligingseisen

Deze eisen moeten in het beveiligingsplan nader uitgewerkt worden.

A. Referenties

Documenthistorie

1.4. Relaties met andere documenten

2.1. Overview LRK-systeemcomplex

2.3.1. Procesflow initiële inschrijving van een OKO

2.3.1. Procesflow initiële inschrijving van een OKO

2.3.1.1.3. Invoeren gegevens houder (gastouder)

2.3.1.3. Vastleggen definitieve inschrijving van OKO in LRK

3.1.1. Publieksportaal

3.3. Relatie use-cases en modules

4.1. Module Landelijk register

4.1. Module Landelijk register

4.2. Module Publieksportaal

4.3. Module Overheidsportaal

4.6. Module Adressen

4.7. Module Gebruikers

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

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.

1.4. Leeswijzer

1.5. Relatie met andere documenten

3.2. Schermopbouw

3.4. Helpfuncties

3.6. Autorisatie

3.6. Autorisatie

3.7. Authenticatie

3.11. Webrichtlijnen

5.1. Inloggen/uitloggen

5.3.1. Zoeken

5.4. Tonen zoekresultaten (OKO en Houders)

5.6. Tonen gegevens OKO

5.6.4. Tonen inspectierapporten

5.7. Nieuwe aanvraag

5.7.2.1. Toewijzen Houder

5.7.2.1. Toewijzen Houder

5.7.3.1. Toewijzen Gastouderbureau

5.7.3.2. Toewijzen Gastouder of Houder VGO

5.7.3.4. Controleren ingevoerde gegevens

5.10. Detailstap: registreren Gastouder

5.12.1.2. Wijzigen adresgegevens

5.12.2. Wijzigen Houder

5.12.3.4. Wijzigen bemiddelingsrelatie GOB

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.

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

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

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.

2. Classes

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

2.5. Niet-Natuurlijke Personen

2.7. Gebruikers en autorisaties

2.9. Documenten

2.11. Audit trail/tijdreizen

2.11. Audit trail/tijdreizen

2.12. Beheer

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

2.13. Help

Deze module heeft geen eigen data.

Bijlage 3

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

1.1. Doelgroep

Systeembeschrijving landelijk register kinderopvang.

2.1. Beschrijving context

3. Scope en uitgangspunten

D. Criterium ‘handhaving’ kindercentra, buitenschoolse opvang, gastouderbureaus en voorzieningen gastouderopvang

4.2.2. Services

4.3.1. Vergunning tot het exploiteren van een voorziening

4.2. Architectuureisen

4.3. Organisatie

4.4. Processen

4.4.1. Positionering ten opzicht van NORA paradigma

4.4.1. Positionering ten opzicht van NORA paradigma

4.4.2. Ketenproces Registreren nieuwe kinderopvang

4.4.2.2. ICT-ondersteuning functies tbv Registreren

5.3.2. Belastingdienst

6.1. Applicaties en databases

4.5. Diensten en services

8. Beveiliging

6.1. Architectuureisen

6.3. Middleware

6.4. Platformen

8.1.1. Typering van informatie: WBP-classificatie

2.3.1.1. Vastleggen ontvangen aanvraag voor registratie

2.3.1.1.1. Inloggen gegevensverwerker Gemeente

2.3.1.1.1. Inloggen gegevensverwerker Gemeente

2.3.1.1.3. Invoeren gegevens houder (gastouder)

2.3.1.2. Vastleggen inspectierapport

2.3.1.3. Vastleggen definitieve inschrijving van OKO in LRK

2.3.1.4. Afronden registratie

2.3.2. Verwerken van wijzigingen

2.3.2. Verwerken van wijzigingen

2.3.3. Raadplegen via publieksportaal

3.1.1. Publieksportaal

4.2. Module Publieksportaal

4.3. Module Overheidsportaal

4.4. Module Natuurlijke personen

4.7. Module Gebruikers

4.8. Module Authenticatie

4.9. Module Documenten

4.10. Module Management informatie

4.10. Module Management informatie

4.12. Module Beheer

1.4. Leeswijzer

1.6. Openstaande punten

2.1. Inleiding

2.2. Overheidsportaal

3.7. Authenticatie

3.8. Fout- en andere meldingen

5.3.1. Zoeken

5.5. Tonen gegevens Houder

5.7. Nieuwe aanvraag

5.7.2.2. Invoeren detailgegevens

5.7.2.2. Invoeren detailgegevens

5.7.3.2. Toewijzen Gastouder of Houder VGO

5.7.3.3. Invoeren detailgegevens

5.7.3.3. Invoeren detailgegevens

5.8. Detailstap: toewijzen Houder