Regeling Wet kinderopvang en kwaliteitseisen peuterspeelzalen

De doelgroep voor deze PSA is divers:

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

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

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

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

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

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

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

Dit architectuurdocument gebruikt de volgende hoofdstukindeling:

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

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

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

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

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

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

• 1 Referentiearchitectuur sector Onderwijs [15];

• 2 NORA;

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

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

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

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

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

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

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

• 4 Risicoclassificatie en beveiligingsplan.

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

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

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

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

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

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

In een latere fase ook:

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

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

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

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

In deze context ziet de omgeving als volgt uit:

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

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

• • Gemeenten zijn vervolgens verantwoordelijk voor het gegevensbeheer het Landelijk Register;

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

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

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

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

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

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

Deze PSA beschrijft de volgende voorzieningen:

• • Landelijk Register

• • Overheidsportaal

• • Publieksportaal

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

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

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

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

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

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

DE NORA-TEKSTEN ZIJN LETTERLIJK OVERGENOMEN

Verder wordt gebruikt gemaakt van de volgende standaarden:

• • UML voor gegevensmodellering

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

In het aandachtsgebied zijn vier processen te onderkennen:

• • registreren

• • inspecteren

• • handhaven

• • gebruiken

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

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

Het overzicht bevat per (deel)principe de status:

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

DE NORA-TEKSTEN ZIJN LETTERLIJK OVERGENOMEN UIT VERSIE 2.0

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

• • Ministerie van Onderwijs, Cultuur en Wetenschappen (OCW):

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

    • ○ Het LR valt onder verantwoordelijkheid van de Minister van OCW

• • GGD

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

    • ○ De GGD is verantwoordelijk voor de uitvoering van de inspecties.

• • Gemeente:

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

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

• • Inspectie van het Onderwijs (IvhO)

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

    • ○ De IvhO is verantwoordelijk voor het tweedelijns toezicht.

• • Belastingdienst (BD)

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

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

• • Gastouderbureau (GOB): zie woordenlijst.

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

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

• • Gastouder (GO): zie woordenlijst

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

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

• • Vereniging Nederlandse Gemeenten (VNG)

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

• • GGD-Nederland

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

• • beheerorganisatie van voorzieningen (nog vast te stellen)

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

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

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

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

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

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

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

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

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

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

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

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

Verantwoordelijk voor de uitvoering:

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

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

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

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

4.4.2. Ketenproces Registreren nieuwe kinderopvang

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

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

4.4.2.1. Procesdecompositie binnen ketenproces Registreren nieuwe kinderopvang

De bedrijfsprocessen zijn een decompositie van de ketenprocessen.

• 1 Aanvragen voor registratie in LR

• 2 Ontvangen aanvraag voor registratie

• 3 In behandeling nemen aanvraag voor registratie

• 4 Besluiten over aanvraag voor registratie

• 5 Verwerken van wijzigingen

• 6 Ontvangen klacht

• 7 Beëindigen kinderopvang

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

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

In de bedrijfsprocessen worden de volgende functies uitgevoerd:

4.4.2.2. ICT-ondersteuning functies tbv Registreren

Het systeemcomplex ondersteunt de volgende functies:

legenda

LRK is het totale -systeemcomplex.

LR is het Landelijk Registeren

OP is het OverheidsPortaal

PP is het Publieksportaal

Gem is het geheel aan gemeentelijke processen en systemen

GGD is het geheel aan GGD processen en systemen

BD is het geheel aan Belastingdienst processen en systemen

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.4.3. Ketenproces Wijzigen registratie kinderopvang

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

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

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

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

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

Afbeelding 5: Wijzigen van kinderopvanggegevens

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

4.4.3.1. Procesdecompositie binnen ketenproces Wijzigen registratie kinderopvang

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

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

4.4.3.2. Procesdecompositie binnen ketenproces Wijzigen registratie kinderopvang

4.4.4. Functionele decompositie Inspecteren, Handhaven en Gebruiken

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

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

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

Deze paragraaf beschrijft welke diensten en services de Gemeenschappelijke Inspectieruimte biedt. In de NORA wordt met een DIENST bedoelt het resultaat of effect van een afgeronde inspanning die de overheid op basis van wettelijke taken levert en waarmee in een behoefte van een burger of bedrijf wordt voorzien. Een service is vrij vertaald een interne dienst, ofwel tussen overheidsorganisaties.

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

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

• • Landelijke Register (LR).

• • Publieksportaal (PP) voor de burgers.

• • Overheidsportaal (OP) voor de bevoegde functionarissen.

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

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

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

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

Het aantal afzonderlijke gebruikersaccounts per doelgroep wordt nader bepaald.

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

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

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

5.3.1. Relevante principes Referentiearchitectuur Onderwijs

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

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

Afbeelding 7: Referentiearchitectuur Onderwijssector

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

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

OCW principe			Vertaling
Binnen de Referentiearchitectuur wordt onderscheid gemaakt tussen de volgende portalen:			Publieksportaal levert de volgende diensten aan burgers:
• Portaal onderwijsdeelnemers • Bij het portaal onderwijsdeelnemers kan worden gedacht aan het leveren van de volgende diensten:			– Opvragen van informatie over de ingeschreven organisaties voor kinderopvang in het LR, inspectierapporten en beperkte historische gegevens van de uitgeschreven organisaties voor kinderopvang
	○ Opvragen informatie (Bijvoorbeeld prestaties van scholen).
• Portaal onderwijsinstelling			Overheidsportaal levert de volgende diensten aan de organisaties die betrokken zijn bij de uitvoering van Wet Kinderopvang:
• Dit portaal wordt gebruikt om diensten aan onderwijsinstellingen te leveren.
• Hierbij kan gedacht worden aan de volgende diensten:
	○ Opvragen informatie over onderwijsinstellingen		– Opvragen van informatie over de organisaties voor kinderopvang en hun houders;
	○ Aanleveren van gegevens ○ Voor onderwijsinstellingen die gegevens niet aanleveren vanuit het schoolsysteem wordt functionaliteit beschikbaar gesteld om dit via een portaal te doen. ○ Opvragen informatie over proces ○ Informatie moet verstrekt kunnen worden over de dienstverleningsprocessen (aanleveren brongegevens, bevoorschotten, bekostigen, betalen, verantwoorden en bezwaarprocedures). Hierbij wordt onderscheid gemaakt tussen:
			– Beheerfunctionalitiet voor de gegevens over organisaties voor kinderopvang aan verantwoordelijke instellingen (Gemeenten);
			– Opvragen van informatie over de status van de organisaties voor kinderopvang inclusief de bijbehorende tijdslijnen
		– Gehanteerde procedure met tijdlijnen
		– Status van proces
		– Resultaat van proces
		– Concrete voorbeelden zijn geregistreerde brongegevens, verleend voorschot, definitieve beschikking, uitgekeerde betaling, vastgestelde jaarrekening.
Externe organisaties die toegang willen tot de openbare database kunnen beschouwd worden als een aparte doelgroep. Zoals het er nu uitziet willen zij echter geen portaalfunctionaliteit, maar willen ze automatische uitwisseling van gegevens middels services.			Functionaliteit van de LR wordt ontsloten via services. Diensten die via het Publieksportaal en/of Overheidsportaal aangeboden worden, maken gebruik van deze services.

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.2. Logisch gegevensmodel Landelijk Register

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

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

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

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

Overheidsbeleid:

• 1 Gebruik open standaarden waar mogelijk.

• 2 Gebruik de volgende documentformaten:

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

  • 2.2 Niet-reviseerbare documenten in pdf-formaat.

• 3 Kies voor open source bij gelijke geschiktheid.

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

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

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

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

Non-functional requirements:

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

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

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

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

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

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

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

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

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

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

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

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

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

Aannames over gebruikersaantallen en gegevensomvang:

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

  • 1.1 Gemeentes 500–1500.

  • 1.2 GGD'en 250–350.

  • 1.3 Inspectie van het Onderwijs 10–20.

  • 1.4 Belastingdienst 50–100.

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

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

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

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

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

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

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

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

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

Resultante eisen op basis van deze aannames:

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

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

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

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

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

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

Servicebus

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

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

• • Ondersteuning van foutafhandeling ten behoeve van beheer.

• • Ondersteuning van logging ten behoeve van beheer.

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

Berichtenstandaarden bij gebruik van de webservices

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

Deze paragraaf beschrijft de uitgangspunten betreffende platformen.

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

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

Hardware en Operating Systeem:

Transparant vanwege het gebruik van Java.

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

Infrastructurele software

De eisen die gesteld moeten worden betreffende infrastructurele software zijn:

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

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

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

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

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

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

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

• 4 Systeem-authenticatie vindt plaats op basis van PKIOverheidscertificaten.

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

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

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

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

Afbeelding 9: infrastructuur per 01-01-2010

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

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

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

  • 1.2 Benaderbaarheid van hardware en services.

  • 1.3 Aantal gebruikers op een willekeurig moment.

  • 1.4 Monitoring van response-tijden.

  • 1.5 Monitoring van beschikbaarheid van koppelvlakken.

• 2 Het systeemcomplex moet voldoende logging-informatie geven:

  • 2.1 Alle fouten moeten gelogd worden.

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

• 3 Het systeemcomplex moet wijzigbaar zijn:

  • 3.1 Hardware moet bij te plaatsen zijn in de serverruimte.

  • 3.2 Het systeem moet horizontaal en verticaal schaalbaar zijn.

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

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

  • 4.1 Een gebruikersbeheer-interface ten behoeve van authenticatie.

  • 4.2 Een gebruikersbeheer-interface ten behoeve van autorisatie.

  • 4.3 Een configuratie-interface.

• 5 Geautomatiseerde backup&restore procedures voor de database.

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

Rijksvoorschrift voor informatiebeveiliging (VIR) [9]

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

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

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

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

Wet Bescherming Persoonsgegevens (WBP) [11]

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

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.

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

Vooruitlopend op deze uitwerking zijn de volgende eisen te hanteren:

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

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

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

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

Deze eisen moeten in het beveiligingsplan nader uitgewerkt worden.

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

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

• • Risicoanalyse;

• • Informatiebeveiligingsplan;

• • Verantwoordelijke beveiligingsfunctionaris(sen) benoemd;

• • Gebruiksvoorwaarden opstellen;

• • Beheerprocedures en operationele beveiliging (monitoring) inregelen;

• • Audits laten uitvoeren;

• • Tijdens ontwikkeling: code-scanning en pen-test;

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

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

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

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

Dit document is bedoeld voor:

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

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

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

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

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

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

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

Hierbij is een drietal systeemcomponenten onderkend:

• • publieksportaal

• • overheidsportaal

• • landelijk register (services)

Daarnaast wordt een systeemcomponent onderkend ten behoeve van het beheer.

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

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

2.3.1. Procesflow initiële inschrijving van een OKO

Initiële inschrijving

Toelichting:

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

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

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

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

ICT-ondersteuning:

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

• • Vastleggen ontvangen aanvraag voor registratiekamer

• • Vastleggen inspectierapport

• • vastleggen definitieve inschrijving OKO in LRK

• • afronden registratie

2.3.1.1. Vastleggen ontvangen aanvraag voor registratie

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

4. Vastleggen ontvangen aanvraag voor registratie

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

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

2.3.1.1.1. Inloggen gegevensverwerker Gemeente

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

4.1 Inloggen Gegevensverwerker Gemeente

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

2.3.1.1.2. Vastleggen voorlopige gegevens van nieuwe OKO

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

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

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

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

2.3.1.1.3. Invoeren gegevens houder (gastouder)

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

4.3 Invoeren gegevens houder (gastouder)

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

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

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

2.3.1.2. Vastleggen inspectierapport

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

11. Vastleggen inspectierapport

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

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

2.3.1.3. Vastleggen definitieve inschrijving van OKO in LRK

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

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

12. Vastleggen definitieve inschrijving van OKO in LRK

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

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

2.3.1.4. Afronden registratie

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

15. Afronden registratie

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

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

2.3.2. Verwerken van wijzigingen

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

17. Verwerken van wijzigingen

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

2.3.3. Raadplegen via publieksportaal

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

16. Raadplegen via publieksportaal

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

2.3.4. Raakvlakken met Interactiemodel

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

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

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

De volgende use cases maken gebruik van het Publieksportaal:

• • zoeken LRK-subjecten

• • zoeken organisatie voor kinderopvang (OKO)

• • raadplegen LRK-subject

• • raadplegen OKO

• • tonen inspectierapport

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

De volgende use cases maken gebruik van het Overheidsportaal:

• • uitgebreid zoeken LRK subjecten

• • uitgebreid zoeken OKO

• • inzien gegevens LRK-subject

• • inzien gegevens OKO

• • wijzigen administratieve status OKO

• • registreren OKO

• • registreren LRK-subject

• • wijzigen gegevens OKO

• • wijzigen gegevens LRK-subject

• • registreren inspectierapport

• • inloggen

• • uitloggen

• • registreren gastouder

• • raadplegen historische gegevens OKO

• • Tonen overzichten OKO

• • Afdrukken overzichten

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

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

• • onderhouden gegevens gemeente

• • onderhouden gegevens GGD

• • onderhouden stamtabellen

• • beheren gebruikers

• • beheren autorisaties

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

De use cases gebruiken de verschillende modules.

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

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

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

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

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

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

Schermen in het publieksportaal:

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

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

• • links naar functionaliteiten zoals printen, help

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

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

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

Schermen in het overheidsportaal:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• • opvanglocatie;

• • correspondentieadres;

• • woonadres.

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

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

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

Er zijn verschillende Actoren:

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

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

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

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

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

Er wordt geen relatie gelegd naar document management systemen.

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

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

• • Administratieve statussen;

• • gemeenten van inschrijving

• • soort/vorm van kinderopvang

• • aantal kindplaatsen

• • aantal aangesloten VGO

• • datum laatste inspectierapport

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

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

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

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

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

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

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

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

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

• – medewerker keten

• – gegevensverwerker gemeente

• – publiek

Uit oogpunt van overzichtelijkheid zijn sommige modules twee maal opgenomen in het 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.

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

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

De handelingen worden ook in de audit trail vastgelegd.

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

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

Dit document is bedoeld voor:

• • Eindgebruikers om functionaliteit af te beschrijven en af te stemmen.

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

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

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:

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

• • Hoofdstuk 3 beschrijft de algemene uitgangspunten van de te realiseren portalen

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

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

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

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

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

Dit document is opgesteld met gebruikmaking van:

• • Project Startarchitectuur , versie 0.9

• • Use Case Model Landelijk Register Kinderopvang, versie 1.0

• • Project Initiation Document ICT-ontwikkeling, versie 1.1

• • Requirements List (niet vastgesteld)

• • Globaal Prototype, versie 1.0

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

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

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

• • Inzien van historische gegevens is nog niet uitgewerkt (tijdreizen)

• • Details omtrent het wijzigen van een VGO moeten nog worden uitgewerkt

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

• • Het Publieksportaal is nog niet in detail uitgewerkt.

Deze zaken verdienen extra aandacht bij uitwerking in het DFO.

• 1. Ministerie van OCW, rijkshuisstijl

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

• 2. Webrichtlijnen

  http://webrichtlijnen.nl/toetsen

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

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

• 1 het Overheidsportaal;

• 2 het Publieksportaal;

• 3 de Beheerinterface.

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

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

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

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

Het Publieksportaal bestaat uit de volgende 'hoofdschermen':

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

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

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

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

De schermen kennen de volgende algemene opbouw.

• • Hoofdmenu: hier wordt de primaire navigatie getoond.

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

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

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

Er wordt onderscheid gemaakt naar twee soorten help.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• • kerngegevens;

• • adresgegevens;

• • aan de Houder gerelateerde OKO's;

• • historische gegevens.

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

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

• • kerngegevens;

• • adresgegevens;

• • Houdergegevens;

• • bijbehorende Inspectierapporten;

• • historische gegevens.

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

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

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

5.7.1. Start registreren OKO

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

• 1 Registeren Kindercentrum (BSO, KDV);

• 2 Registeren VGO (inclusief registreren GO);

• 3 Registeren GOB;

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

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

• • Natuurlijk Persoon

• • Niet Natuurlijk Persoon

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

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

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

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

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

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

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

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

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

Het registratieproces doorloopt de volgende stappen:

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

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

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

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

• • een Binnenlands adres, bestaande uit:

  • • een Feitenlijk adres

  • • een Postadres, waarbij onderscheid gemaakt wordt tussen:

    • • een Postbus

    • • een Antwoordnummer

• • een Buitenlands adres

• • Contact/Correspondentie-gegevens

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

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

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

5.12.1. Wijzigen Kindercentrum en Gastouderbureau

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

• • Wijzigen kerngegevens en status

• • Wijzigen adresgegevens

• • Wijzigen betrokken Houder

5.12.1.1. Wijzigen kerngegevens en status

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

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

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

5.12.1.2. Wijzigen adresgegevens

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

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

5.12.1.3. Wijzigen betrokken Houder

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

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

De volgende standaard overzichten kunnen worden geproduceerd:

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

  Alleen vermelding van aantal.

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

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

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

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

• • Zoeken gemeente (7.1.1)

• • Wijzigen gegevens gemeente (7.3.2)

• • Toevoegen nieuwe gemeente (7.3.4)