1

CONCEPT PROGRAMMA VAN EISEN

Informatievoorziening t.b.v. ondersteuning

regie in het sociaal domein: 1-gezin 1-plan 1-regisseur

2

Colofon

Concept-Programma van Eisen

Informatievoorziening t.b.v. ondersteuning regie in het sociale domein: 1-gezin 1-plan 1-

regisseur

Opdrachtgevers KING, Dimpact, GovUnited

Auteurs Zie par. 1.3.

Eindredactie Frank Kuiper

Versie 0.92

Datum 29 juli 2013

3

Inhoudsopgave

1 Inleiding 6

1.1 Voorwoord 6

1.2 Doel Programma van Eisen 7

1.3 Programma van Eisen 10

1.4 Terminologie 11

1.5 Leeswijzer 11

2 Scope 13

2.1 Inleiding 13

2.2 Regiemodellen 17

2.3 Burgerportaal 20

2.3.1 Inleiding 20

2.3.2 Informatievoorziening en vraagverheldering 20

2.3.3 Inzage in eigen integraal klantbeeld (inclusief plan) 21

2.3.4 Communicatie 22

2.4 Regie 24

2.4.1 Integraal klantbeeld (incl. Inkijk) 24

2.4.2 Het ondersteuningsplan (1-plan) 26

2.4.3 Inkomende/uitgaande signalen en meldingen 27

2.4.4 Ongestructureerde communicatie en interactie 28

2.4.5 Gestructureerde ketenberichten 29

2.5 Regie op regie 30

3 Uitgangspunten PvE 32

3.1 Varianten en fasering 32

3.2 Plusfunctionaliteiten 33

3.3 Opties 34

3.4 Overige uitgangspunten 34

3.5 Eisen en wensen 36

3.6 Juridische en financiële eisen en wensen 37

4 PvE: Generieke functionaliteit 39

4.1 Inleiding (generieke functionaliteit) 39

4.2 Processen (regievoering en bewaking) 39

4.2.1 Inleiding 39

4.2.2 Registreren klantcontacten en zaken 40

4.2.3 Zaakbeheer 40

4.2.4 Zaakbehandeling 42

4.3 Gegevens en dossiers 46

4.3.1 Inleiding (gegevens) 46

4.3.2 Gegevensbeheer en -opslag 46

4.3.3 Gegevensregistratie en intake 49

4.3.4 (Management)rapportages 53

4.4 Documenten en sjablonen 54

4.4.1 Inleiding (documenten) 54

4.4.2 Basisfunctionaliteit 54

4.4.3 Documentcreatie en -opslag 55

4.4.4 [Archivering] 57

4

4.5 Medewerkerportaal en werkbak 59

4.5.1 Signaleringen en contacten 59

4.5.2 Filteren en sorteren 60

4.5.3 Beslisondersteuning en vraagverheldering 60

4.5.4 Dienstenboek (product- dienstencatalogus) 62

4.5.5 Zoeken 63

4.5.6 Kalenderfunctionaliteit 65

4.5.7 Financiën en overige regie op regie 67

4.5.8 Medewerkerportaal voor gebruikers buiten de gemeente 68

4.6 Burgerportaal (zelfregie) 70

5 PvE: Specifieke inrichting 72

5.1 Inleiding 72

5.1.1 Overzicht gebruik 72

5.1.2 Primaire en secundaire functies 3D-Suite 76

5.1.3 Specifieke wensen en eisen 81

5.2 Regie 83

5.3 Burgerportaal (zelfregie) 85

5.3.1 Niet-gepersonaliseerd burgerportaal (oriëntatie & informatie) 85

5.3.2 Gepersonaliseerd Burgerportaal 87

5.4 Het regieproces 91

5.4.1 Integraal klantbeeld 91

5.4.2 (Inkomende) signaleringen, meldingen en contacten 92

5.4.3 Intake, doelstelling, maatregelselectie en ondersteuningsplan 94

5.4.4 Taken/acties incl. signalen en ketenberichten 97

5.4.5 Procesbewaking/evaluatie/nazorg 101

5.5 Regie op regie (budget, contract, kwaliteit, etc.) 103

5.6 Standaardcontent 105

6 PvE: Gebruiksvriendelijkheid 107

7 PvE: Integratie 111

7.1 Inleiding 111

7.2 Interne integratie 112

7.3 Gemeentelijke basisadministraties en backofficesystemen 115

7.4 Integratie landelijke en regionale voorzieningen 118

7.5 Zaaksysteem en backofficesystemen van UO‟s 122

7.6 Integratie-tooling 123

8 PvE: Autorisatie, beveiliging en privacy 125

8.1 Inleiding 125

8.2 Wet- en regelgeving 125

8.3 Toegang tot informatie: doelbinding en privacy 127

8.4 Authenticatie en autorisatie 129

8.5 Auditing / logging 130

8.6 Technische beveiliging en integriteit 132

8.7 Overig (beveiliging) 133

9 PvE: Architectuur 134

9.1 Inleiding 134

9.2 Functionele architectuur 134

5

9.3 Softwarearchitectuur 135

9.4 Client- en serverside architectuur 136

9.5 Technische architectuur 137

9.6 Beschikbaarheid en performance 139

9.7 Beleid en (open) standaarden 140

9.8 Openheid systeem 142

10 PvE: Periodieke / doorlopende dienstverlening 143

10.1 Inleiding 143

10.2 Training 143

10.3 Documentatie 144

10.4 Onderhoud 145

10.5 Ondersteuning 146

10.6 Escrow 146

11 PvE: Eenmalige dienstverlening 148

11.1 Inleiding 148

11.2 Algemeen 148

11.3 Implementatie 148

11.4 Migratie 149

11.5 Concept Plan van Aanpak 149

12 Bijlagen 150

12.1 Zaakgericht werken 150

12.2 Overzicht gegevens in Digitaal Klantdossier / Suwinet 151

12.3 Voorbeeldinrichting 153

12.3.1 Functionele informatie-eenheden 153

12.3.2 Generieke informatie-elementen 156

12.4 Voorbeeld: elementen in een zelfredzaamheidsmatrix 161

12.5 Voorbeeld: klantbeeld 162

12.6 Voorbeeld: hoofdprocessen Awbz, Wmo en Jeugdzorg 163

12.7 Voorbeeld: online communities en „marktplaatsen‟ 166

12.8 Afkortingenlijst 167

6

1 Inleiding

1.1 Voorwoord

Met genoegen bieden wij u hierbij versie 0.9 aan van het programma van eisen (PvE)

„informatievoorziening ten behoeve van ondersteuning regie in het sociale domein: 1-gezin 1-plan

1-regisseur‟. Al met al een omvangrijk document dat de stand van zaken weergeeft per mei 2013.

Stand van zaken

Versie 0.9 van het PvE is tot stand gekomen als onderdeel van het project Verkenning

Informatievoorziening Sociaal Domein (VISD) dat door KING in opdracht van de VNG is uitgevoerd

van oktober 2012 tot en met juni 2013. Deze versie van het PvE omvat generieke eisen en wensen

m.b.t. een informatiesysteem voor regie in het Sociaal Domein en is daarom geen definitieve

versie. Een volledig aanbestedingsbestek omvat daarnaast ook een gedetailleerde beschrijving van

de aan te besteden opdracht, procedurele / juridische aspecten, etc. Ook worden de

organisatorische, juridische, en andere aspecten die de inrichting en het gebruik door de gemeente

zelf hier nog niet geadresseerd. Feitelijk gebruik en inrichting zal dan ook per gemeente

verschillen.

Het PvE kan als basis dienen voor een aanbestedingsbestek - of een aanzet geven tot een

functioneel ontwerp wanneer de gemeente eigen reeds aanwezige applicaties gaat inzetten. Voor

individuele gemeenten zal een en ander nog moeten worden herschreven naar de eigen specifieke

situatie.

Hoe nu verder?

Dit document is met veel inzet en enthousiasme van gemeenten tot stand gekomen. Zij hebben

zich daarbij ook laten inspireren door de markt. Wat kunnen gemeenten ermee? Een groot deel van

de gemeenten kan hiermee niet zonder meer aan de slag en zal eerst voorbereidende

werkzaamheden moeten verrichten.

Hoe ziet het beleid eruit? Wat voor sturingsmodel wordt gekozen door gemeenten in overleg met

hun partners? Wat betekent dit voor de organisatie-inrichting en hoe gaan de processen verlopen

al dan niet met sociale partners? Als deze vraagstukken zijn beantwoord, kun je vaststellen welke

ondersteuning op het gebied van informatievoorziening gewenst is.

Bij het vaststellen van de benodigde ondersteuning zal de gemeente ook onderzoeken wat men al

beschikbaar heeft aan informatievoorziening en zich de vraag stellen: „Hoe positioneer ik de nieuwe

functionaliteiten of voorzieningen voor ondersteuning van regie? Informatiemanagers hebben

behoefte aan handvatten bij de interpretatie en toepassing van het PvE.

KING zal deze vraagstukken en de hierbij te maken afwegingen de komende maanden verwoorden

in de vorm van een handreiking bij het PvE. Het kunnen beschikken over inspirerende

voorbeelden is hierbij ook erg belangrijk, hoe hebben andere gemeenten dit opgepakt en ingericht.

In een aantal bijeenkomsten zullen we het PvE en de handreiking ook toetsen aan de praktijk.

Daarnaast zal KING een leveranciersdag organiseren om leveranciers en de gemeenten de kans

te bieden om vrijblijvend van elkaars wensen en mogelijkheden kennis te laten nemen. Dan is de

finale versie van het globale PvE versie 0.9 er om als toetssteen te dienen en in breder verband te

presenteren.

7

Doorontwikkeling

Op basis van het PvE versie 0.92 zal doorontwikkeling plaatsvinden. KING wil hiervoor de regie op

zich nemen en zal hiertoe een proces van beheer en doorontwikkeling inrichten. Ook daarbij is het

vanzelfsprekend dat samen gewerkt gaat worden met gemeenten.

Verspreiding

Het PvE v0.9 en de handreiking worden opgeleverd als onderdeel van het eindadvies VISD in juli

2013. De documenten moeten voor een goed begrip in onderlinge samenhang worden gelezen. Tot

die tijd wordt verzocht de verspreiding waar mogelijk beperkt te houden.

In geval van vragen kan contact met KING worden opgenomen via info@kinggemeenten.nl.

1.2 Doel Programma van Eisen

Het onderhavige document behelst het Programma van Eisen (PvE) voor een informatievoorziening

t.b.v. de ondersteuning van de professionals in het gemeentelijk sociale domein: „1-gezin 1-plan 1-

regisseur‟. Dit in het kader van de decentralisaties in het sociale domein. De kerngedachte achter

de decentralisaties is de integrale aanpak en het versterken van de zelfredzaamheid van de burger.

Om dit te realiseren wordt de (regie-)rol/ verantwoordelijkheid van gemeenten als meest nabije

(en logische) overheid versterkt.

De rijksoverheid draagt grote taken op het gebied van Jeugdzorg, AWBZ en participatie over naar

de gemeenten. Ook de stelselwijziging Passend Onderwijs heeft invloed op het sociale domein.

Deze transitie wordt gevisualiseerd in figuur 1.

Figuur 1 decentralisaties

Deze decentralisaties maken het gemeenten noodzakelijk verbanden te leggen tussen de

Wmo/Awbz, jeugdzorg en werk en inkomen. Dit resulteert in „1 gezin, 1 plan, 1 regisseur‟, waarbij

de gemeente en de ketenpartners worden ondersteund door 1 informatievoorziening met een brede

8

blik over de verschillende werkvelden. Een platform dat de integrale

aanpak en de samenwerking faciliteert en aanvullend is op de eigen bedrijfsvoeringsystemen.

Veel gemeenten zijn al bezig met het vormgeven van een integrale aanpak op wijkniveau en er

moeten daarbij ook slagen gemaakt worden m.b.t. de informatievoorziening van professionals. Een

belangrijke gedachte bij de decentralisaties is de integrale aanpak en het versterken van de

zelfredzaamheid van de burger. Om dit te realiseren wordt de regierol en -verantwoordelijkheid

van gemeenten als meest nabije (en logische) overheid versterkt. Het versterken van de

zelfredzaamheid van de burger zelf is een belangrijk doel. Preventie kan immers zorgen voor lagere

kosten voor ondersteuning en regie. Hier is echter niet perse een nieuw informatiesysteem nodig,

want het bevorderen van zelfredzaamheid kan wellicht al vorm krijgen via bestaande systemen.

Het PvE heeft ook niet als uitgangspunt dat het nieuwe informatiesysteem de inhoudelijke

uitvoeringsprocessen van alle domeinen ondersteunt of dat alle nu in gebruik zijnde

backofficesystemen kunnen worden vervangen. Het doel van het PvE is niet het beschrijven van de

functionaliteiten die benodigd zijn voor de feitelijke uitvoering van ondersteuningsmaatregelen,

maar voor de regie daarover.

Dit PvE richt zich daarom primair op een informatievoorziening t.b.v. de regiefunctie in het sociale

domein. De gevraagde inrichting van een applicatie of set van applicaties wordt in dit document

aangeduid als „3D-Suite‟: een suite van applicaties t.b.v. ondersteuning van de regievoering over

het sociaal domein waar onder meer de 3 decentralisaties (3D) rond Jeugdzorg, AWBZ en

participatie binnen vallen.

Regie omvat hier de waarde die een professional toevoegt aan de ondersteuning van een gezin,

door zelf het gezin te ondersteunen maar ook door indien nodig de afstemming te organiseren

tussen andere ondersteuningsaanbieders (bijv. in geval van multiprobleemgezinnen). Een regisseur

kan dan „vanaf de keukentafel‟ van een burger of gezin regie voeren over verschillende

uitvoeringsorganisaties zoals een Bureau Jeugdzorg en verschillende organisatie-eenheden binnen

de gemeente. Het keukentafelgesprek (als metafoor voor een integrale intake en aanpak) is een

kern van dit PvE.

De informatiestromen rond een enkel gezin waar de regisseur rekening mee moet houden kunnen

schematisch als hieronder in figuur 2 worden weergegeven (bron: Hans Versteeg / VNG).

Figuur 2 Informatiestromen 'rond de keukentafel'

9

Er is echter niet enkel sprake van multiprobleemgezinnen waarbij ieder

traject verschilt, maar ook eenvoudige, enkelvoudige, snelle ondersteuning of van multi-

disciplinaire standaardondersteuning (standaard ondersteuningsvormen, doch met meer betrokken

partijen).

Bij enkelvoudige, maar vooral bij meervoudige hulpvragen is een integrale intake/ beoordeling en

een afgestemde uitvoering essentieel. Daarnaast kan de regie betrekking hebben op de bewaking

en verantwoording van budgetten en de resultaten van ondersteuning(-sancties) en sturing vanuit

management en beleid.

Daarnaast is het denkbaar dat er preventieve maatregelen worden genomen. Regievoering over

generieke brede preventieve maatregelen zoals een bewustzijncampagne of een speelplaats valt

echter buiten de scope van het onderhavig Programma van Eisen (PvE).

10

1.3 Programma van Eisen

Het concept-PvE is opgesteld in opdracht van KING, Dimpact, GovUnited en de gemeente Enschede

in het kader van het project “Verkenning Informatievoorziening Sociaal Domein” (VISD) dat door

KING wordt uitgevoerd in opdracht van de VNG 1. Dit PvE is geschreven door adviesbureau

M&I/Argitek i.s.m. een taskforce PvE van materiedeskundigen vanuit verschillende gemeenten en

vanuit KING:

- Anton van der Linden, gemeente Helmond - Lars Fehse, gemeente Enschede

- Berny Oude Kempers, gemeente Eindhoven - Martin de Bijl, Dimpact

- Frank Kuiper, M&I/Argitek (eindredactie) - Martin Putman, gemeente Rheden

- Frits Dreschler, gemeente Ede - Ronald de Zwart, KING

- Klaas Jan de Regt, gemeente Leeuwarden - Wouter Keller, M&I/Argitek (voorzitter)

De taskforce is t.b.v. domeinspecifieke inrichting aangevuld met een verdiepingsgroep:

- Jannie Holthuis, gemeente Emmen - Remco Groenendal, gemeente Gemert-Bakel

- Joop Kuiper, gemeente Almelo - Tom Uleman, gemeente Zaanstad

- Joost Broumels, KING (voorzitter) - Vanessa Timmer, gemeente Gilze en Rijen

- Marrie Hol, gemeente Zwolle - Vincent Weijers, gemeente Berkelland

- Pieter in 't Hout, gemeente Utrecht

De Stuurgroep specifiek voor het Programma van Eisen bestaat uit:

- Arjen Hof, GovUnited

- Dick Laan, gemeente Enschede (voorzitter)

- Joost Broumels, KING

- Rene Bal, Dimpact

- Wouter Keller, M&I/Argitek (projectleider)

Het PvE leidt voor gemeenten niet perse tot de aanschaf van een nieuw systeem. Het is denkbaar

dat bestaande, bij een gemeente aanwezige, pakketten en functionaliteiten gebruikt gaan worden,

maar ook dat nieuwe systemen worden aangeschaft. De gevraagde suite van applicatie(s) kan ook

bestaan uit een mix van reeds aanwezige en nog in te richten applicaties. Als alle applicaties al

aanwezig zijn en implementatiekosten onder de aanbestedingsgrenzen blijven, zal er geen sprake

hoeven te zijn van een aanbesteding. Termen als „Inschrijver‟ en „3D-Suite‟ dienen dan ook met

deze gedachten te worden gelezen.

Het document is beschreven vanuit een zaakgerichte visie. Om een eenduidige –en bij gemeenten

gangbare– terminologie aan te houden is zaakgericht werken gebruikt als kapstok v.w.b.

modellering, uitvoering en uitwisseling van de processen en dossiers. Echter wordt benadrukt dat

dit géén vooraf vastliggende processen impliceert. Flexibiliteit is noodzakelijk. Een en ander kan

bijvoorbeeld op basis van een al dan niet reeds aanwezig zaaksysteem worden ingericht, met

aanvullend meer ad-hoc flexibiliteit en enige 3D-speficieke functionaliteiten die later in het

programma van eisen zijn beschreven. Doch de gevraagde functionaliteiten kunnen ook op basis

van bijv. een case management of workflow/processysteem worden ingericht. Het gaat om de

functionaliteit.

1 VISD: zie ook https://new.kinggemeenten.nl/decentralisaties/project-visd

11

Als PvE omvat dit document „slechts‟ eisen en wensen m.b.t. het

informatiesysteem. Het is geen volledig aanbestedingsbestek, dat immers ook een gedetailleerde

beschrijving omvat van de aan te besteden opdracht, procedurele / juridische aspecten, etc. Ook

worden de organisatorische, juridische en andere aspecten die de inrichting en het gebruik door de

gemeente zelf hier nauwelijks geadresseerd. Feitelijk gebruik en inrichting zullen ook per gemeente

kunnen verschillen. Niet alle functionaliteiten zijn wellicht (op korte / middellange termijn)

gewenst. Gemeenten zullen eerst een goed beeld willen vormen van het eigen beleid en de

inrichting van hun eigen bedrijfsvoering. Het programma van Eisen kan daarna op het beleid en

bedrijfsvoering worden aangepast.

Het PvE kan als zodanig als basis dienen voor een aanbestedingsbestek - of een aanzet tot een

functioneel ontwerp wanneer de gemeente zelf reeds aanwezige applicaties gaat inzetten. Voor een

specifieke gemeente zal een en ander nog moeten worden herschreven naar de eigen specifieke

situatie. Ook is het PvE onder enige tijdsdruk (in ca. 3 maanden) geschreven en daardoor nog een

concept (versie 0.92) dat verder uitgewerkt kan worden.

1.4 Terminologie

In de verschillende domeinen die binnen de scope van onderhavige PvE liggen, worden soms ver-

schillende termen gebruikt. Waar in dit document sprake is van bijv. een burger, kan ook bijvoor-

beeld „klant‟ of „burger‟ worden gelezen. Dit geldt ook voor andere termen. Tenzij anders geduid in

de tekst kunnen deze termen als synoniemen worden gezien.

- Cliënt, klant, burger, patiënt, persoon zijn veelal synoniem. En alles dat voor een individuele

burger geldt, geldt ook voor een geheel gezin: bijv. 1 ondersteuningsplan voor een gezin is

v.w.b. de benodigde functionaliteiten veelal niet anders dan een plan voor een individu.

- Waar gezin staat, kan ook worden gelezen bijv. familie, samenwonende mensen met / zonder

kinderen, in voorkomende gevallen andere samenlevingsvormen, etc.

- 1-plan, ondersteuningsplan, plan van aanpak zijn synoniemen

- Klantdossier, cliëntdossier, burgerdossier (vormgegeven o.b.v. een zaakdossier) zijn synonie-

men

- Traject, case, zaak, ondersteuningsproces (de uitvoer van het ondersteuningsplan) zijn syno-

niemen

- Zaakbak, werklijst, werkbak, trajectbak, etc. zijn synoniemen

- Dienstenboek, productenlijst, PDC (product- en dienstencatalogus) zijn synoniemen

- Medewerker, professional, hulpverlener, ondersteuner zijn synoniemen (voor zover de onder-

steuner toegang heeft tot het systeem)

- Uitvoeringsorganisatie, ketenpartner zijn synoniemen

- Zorg, ondersteuning, hulp, etc. zijn synoniemen

- Etc.

Later in dit document zullen de verschillende termen worden uitgelegd.

1.5 Leeswijzer

Het onderhavige document bestaat, naast deze managementsamenvatting / leeswijzer, grofweg uit

een drietal onderdelen: een inleidende beschrijving van de scope/beoogd gebruik (hoofdstuk 2),

een aantal uitgangspunten en opmerkingen over de opzet van het PvE, het daadwerkelijke

Programma van Eisen (hoofdstuk 4- 11) en tenslotte de afsluitende bijlagen (hoofdstuk 12).

12

Het lezen van enkel de hoofdstukken 1 tot en met 3 geeft reeds een goed

beeld van het domein en de scope.

Het PvE maakt in de volgende hoofdstukken onderscheid in generieke en specifieke

functionaliteiten. Generieke functionaliteiten zouden ook voor andere domeinen kunnen worden

ingezet. Specifieke functionaliteiten worden met name uitgevraagd in hoofdstuk 5 en zijn gericht

op de 3D-domeinen en betreffen bij voorkeur een specifieke inrichting van de eerdergenoemde

generieke functionaliteiten.

Verschillende gemeenten hebben verschillende behoeften, bijvoorbeeld als het gaat om de invulling

van de regierol. Daarnaast zijn nog lang niet alle kabinetsplannen in detail uitgewerkt. Daarom is

flexibiliteit van het informatiesysteem van groot belang. Dat kan bereikt worden door de specifieke

functionaliteiten van hoofdstuk 5 zo veel mogelijk door middel van generieke functionaliteiten in te

richten. Deze configuratie kan bij voorkeur ook door de gemeente zelf en zonder programmering

(zero-coding) worden aangepast.

13

2 Scope

2.1 Inleiding

Financieel onvermijdelijk

Wat is de unieke functionaliteit die nodig is voor de ondersteuning van de drie decentralisaties? En

waarom is het noodzakelijk deze functionaliteiten nu al te beschrijven terwijl de wetsvoorstellen

nog niet in detail zijn uitgewerkt? Het antwoord daarop zijn de financiële consequenties van het

ongewijzigde beleid. De uitgaven aan de AWBZ stijgen met 4,3 procent per jaar, deze groei is veel

hoger dan de economische groei en daarmee zal het aandeel van het nationaal inkomen wat aan

de AWBZ wordt uitgegeven bij ongewijzigd beleid groeien tot een derde in 2040. Het huidige

kabinet heeft de benodigde bezuinigingen al ingeboekt en daarmee zijn de decentralisaties

onafwendbaar geworden. Mocht dit kabinet tussentijds ten val komen zal dat uiteindelijk alleen

maar vertraging betekenen, de bezuinigingen blijven echter noodzakelijk.

Ongeacht de samenstelling van het kabinet; de stijging van de uitgaven aan zorg/ondersteuning

zal moeten worden aangepakt. In de huidige plannen worden de taken overgedragen met een

korting van 20% tot 30% van het budget. Met de gedecentraliseerde taken zal het aandeel van de

uitgaven op het sociale domein voor sommige gemeenten richting de 50% gaan van de totale

begroting. Daarmee zijn de decentralisaties voor de gemeente een groot financieel risico. Gezien

de aanzienlijke kortingen op het budget en de financiële risico‟s voor de gemeente is het helder dat

de gemeente deze taken structureel anders moet uitvoeren dan het op dit moment door de

rijksoverheid wordt uitgevoerd. De twee centrale pijlers voor deze andere aanpak zijn eigen

kracht/burgerkracht en integrale aanpak/regie.

Mede vanwege de onzekerheden is flexibiliteit van een informatieplatform van groot belang.

Aanleiding PvE

Al enige jaren wordt vanuit de ministeries van Sociale Zaken, Veiligheid en Justitie en VWS een

aantal decentralisaties aangekondigd. Het gaat daarbij om de transitie van de taken (intramurale)

AWBZ, Jeugdzorg, Participatiewet en passend onderwijs (zie ook figuur 1 op blz. 7).

Sinds de bekendmaking door de ministeries zijn gemeenten druk aan de slag gegaan met

onderzoek naar hoe om te gaan met de transities en met de voorbereidingen om de transformaties

te laten plaatsvinden. Daarbij zijn er binnen gemeenten (of samenwerkingsverbanden) in eerste

instantie vaak per transitie (/decentralisatie) werkgroepen ingericht. Na verloop van tijd werd

duidelijk dat de decentralisaties enkel efficiënt opgepakt kunnen worden als de domeinen

ontkokerd worden en de verschillende decentralisaties over het hele sociale domein integraal

opgepakt worden. De vele taken van de verschillende domeinen moeten uitgevoerd worden met de

daarbij opgelegde significante bezuinigen. Daarmee verschoof de focus van de losse

implementaties per decentralisatie/domein naar de ondersteuning van de regierol over alle

ondersteuning in het sociale domein. Al snel werd duidelijk dat informatievoorziening daarvoor een

belangrijke randvoorwaarde wordt.

Dit is initieel vertaald in het architectuurmodel 3D‟s: zie figuur 3 “werkplaat van de gemeente

Enschede”. Hierin is een vertaling gemaakt en een verbinding gelegd tussen de beleidsmatig

ingestoken ondersteuningspiramide en benodigde functionaliteiten.

14

Figuur 3 Ondersteuningspiramide en informatievoorziening

Informatiekundig wordt dus niet het inhoudelijke uitvoeringsproces van de desbetreffende

decentralisaties ondersteund. Functioneel staat de regie op het sociale domein, inclusief een

integraal klantbeeld en integrale klantondersteuning, centraal.

Dit betekent ook iets voor de focus van dit stuk; waar eerst gesproken werd van een systeem ter

ondersteuning van de professionals rond 3D zijn de in dit document beschreven functionaliteiten

gericht op het ondersteunen van de regie. Dit heeft er ook toe geleid dat tijdens het denk- en

schrijfproces binnen de diverse werkgroepen een ander beeld van noodzakelijke functionaliteiten

gevormd is. Een goed voorbeeld is het burgerportaal dat aanvankelijk geen onderdeel van de scope

uit maakte maar nu toch vrij uitgebreid behandeld wordt. Zo zijn er meer kleinere of grotere

onderwerpen te benoemen die aanvankelijk wel of juist geen onderdeel van de scope zijn geweest

en nu terug komen in het uiteindelijke document.

Voor de lezer willen wij het advies mee geven dit stuk niet te lezen als de totaaloplossing voor de

transformatie i.v.m. de decentralisaties (incl. grote organisatorische, juridische, en andere

vraagstukken). Dit stuk is bedoeld om richting te geven aan de behoefte van de gemeente om

regie te voeren op het sociale domein. Hierbij willen wij ook de aanbeveling geven om de door ons

voorgestelde functionaliteiten, wensen en eisen niet zonder meer over te nemen. Zie ook hoofdstuk

3. Wij bevelen aan als organisatie zelf ook het proces te doorlopen en, vanuit de beleidsvisie en de

daaruit volgende proces- en uitvoeringskeuzes, de vertaling te maken naar dit document.

15

Eigen kracht/burgerkracht

Primair zal er moeten worden ingezet op het verbeteren en versterken van de eigen kracht van

burgers (verhogen van de zelfredzaamheid 2). Burgers die zich zelf kunnen redden doen geen

beroep op de overheid. Als een burger toch ondersteuning vraagt op een bepaald leefgebied zal in

kaart worden gebracht wat de eigen kracht is, wat kan de burger zelf en wat kunnen vrienden,

buren en familie betekenen voor de burger. Eventueel wordt er gekeken naar de financiële

draagkracht van de burger of de familie.

Integraal en regie

Daarnaast zullen de problemen van de burgers of het gezin integraal worden aangepakt, daar waar

sprake is van meervoudige problematiek. Dat betekent dat er niet meer vanuit de verschillende

kokers dure suboptimale tweedelijns oplossingen voor een deelprobleem van de burger

aangeboden gaan worden. De problematiek van de burger of het gezin gaat integraal onderzocht

worden en op de ondersteuning komt regie vanuit de gemeente. Bovendien kent de regisseur de

wijk of het dorp en de beschikbare voorzieningen en probeert daar ook ad-hoc passende

oplossingen voor te zoeken.

Deze aanpak lijkt het ei van Columbus, maar dat is het niet. Het integraal aanpakken van alle

problemen op alle leefgebieden kan pas gerealiseerd worden als er een vertrouwensband is

opgebouwd tussen de burger en de ondersteuner. Voor de opbouw van het vertrouwen is tijd en

contact nodig en dus is er geen sprake van een rechtlijnig proces van intake naar

ondersteuningsplan tot nazorg.

De financiële kaders en het gewenste beleid vormen kaders voor de bedrijfsvoering. Hiermee

blijven we in control op de uitgaven en de beschikbare budgetten lopende het jaar van uitvoering.

Bovendien kunnen vanuit beleid onwenselijke en wenselijke trends worden gesignaleerd. Regie op

bedrijfsvoering is dus ook nodig.

Burgerkracht en zelfregie gecombineerd

Daar waar mogelijk zal er door de overheid een beroep gedaan worden op de burger om zelf de rol

van regisseur te voeren. Daarmee worden de concepten burgerkracht en regie gecombineerd.

Daarin kunnen door de gemeenten verschillende keuzes gemaakt worden in welke mate men de

burger zelf de regie laat voeren. Het is mogelijk om de burger zelf te laten bepalen met welke

organisaties de beschikbare informatie gedeeld mag worden.

Functionaliteiten voor de decentralisaties

Om de decentralisaties voor de gemeenten succesvol uit te kunnen voeren moeten de gemeenten

straks over een aantal functionaliteiten beschikken. Preventie zal een belangrijk doel worden voor

de gemeenten omdat daarmee een beroep op ondersteuning kan worden voorkomen. Bovendien is

de burger hier zelf ook het meeste mee gebaat. Preventie kan op twee manieren. De eerste is

2 Zelfredzaamheid is het zelf realiseren van een acceptabel niveau van functioneren op de belang-

rijke domeinen van het dagelijks leven. Indien nodig door de juiste hulp te organiseren op het

moment dat een daling van je functioneringsniveau dreigt of plaatsvindt, die je niet zelf kan

voorkomen of verhelpen (bron; Zelfredzaamheid-Matrix 2013 Handleiding, GGD Amsterdam).

V.w.b. burgerkracht: zie ook bijv. „Burgerkracht, de toekomst van het sociale werk in Neder-

land, RMO, 2011‟ en „Een beroep op de burger, SCP, 2012‟.

16

versterking van de eigen kracht, de tweede is vroegsignalering waarmee

problemen in een vroeg stadium kunnen worden opgespoord en daarmee ernstigere problemen

kunnen worden voorkomen.

Voor het realiseren van de burgerkracht beschikt de burger over een burgerportaal. Met behulp van

dit burgerportaal kan de burger waar en wanneer mogelijk zelf regie voeren, anders kan een

mantelzorger door de burger gemachtigd worden van het burgerportaal gebruik te maken (denk

hierbij bijvoorbeeld aan zelf afspraken plannen & combineren en eigen budgetbeheer voeren). De

burger kan hier zien welke ondersteuning aan de burger wordt gegeven en welke informele

ondersteuning wordt georganiseerd door de sociale omgeving van hem/haar. De burger kan hier

ook zien welke informatie over hem/haar/het gezin gedeeld wordt tussen de gemeente en de

tweedelijns ondersteuners.

Voor de regierol van de gemeente is een totaaloverzicht van alle betrokken ondersteuners

(professionele én informele ondersteuning) nodig. Voor de regierol is het tevens noodzakelijk dat

de voortgang van de hulpverlening kan worden bewaakt en er met de diverse ondersteuners

(professioneel en informeel) en de burger kan worden gecommuniceerd. Deze communicatie kan

gestructureerd (verstrekking start dienstverlening, ketenbericht) of ongestructureerd (bijv. stellen

van een vraag) plaatsvinden.

Veiligheid, beveiliging en privacy

Privacy en beveiliging zijn zeer belangrijke uitgangspunten voor een 3D-Suite. Het gaat immers om

zeer vertrouwelijke informatie over een kwetsbare groep mensen.

Zoals voor alles binnen 3D geldt ook voor bijv. inkijkfunctionaliteit door de burger (inzage in het

eigen klantdossier) dat privacy voorop moet staan. Ongeoorloofde toegang door derden tot bijv.

het klantdossier (doordat men zich voordoet als de burger zelf) moet te allen tijden voorkomen

worden. Dit vraagt niet alleen om strenge beveiliging in de zin van autorisaties op en encryptie van

het dossier, doch met name aandacht voor de identificatie/authenticatie van de burger voor de

toegang tot het systeem. DigiD (zonder token) kan al snel onvoldoende zijn. Dit geldt a fortiori

natuurlijk ook voor de regisseur, professional en/of medewerker, zeker als die in het veld toegang

moeten hebben tot nog meer informatie dan de burger zelf.

De beschreven functionaliteiten gaan grotendeels uit van de “normale” situatie, voor zover er

sprake kan zijn van normaal. In de jeugdzorg maar ook in de andere domeinen kunnen er situaties

optreden waarin de veiligheid voor kinderen en/of volwassenen in het geding komen. De

gemeentelijke overheid zal de burger dan in het dwang- en drangzorgkader benaderen. Denk aan

kindermishandeling, voogdij, reclassering, etc. Het mag duidelijk zijn dat ondersteuning in dit

kader van heel andere spelregels uitgaat dan burgerkracht en eigen regie.

Ook het delen van informatie met de burger kan in dit kader heel goed ongewenst zijn

(bijvoorbeeld: waar de kinderen uit huis zijn geplaatst). Wanneer sprake is van risico‟s voor de

veiligheid (van de burger of anderszins), is het dus mogelijk dat de regisseur bepaalt dat de burger

niet alle informatie kan zien, ook zal bijv. wellicht geen toestemming hoeven te worden gevraagd

voor het, t.b.v. verbeteren van de veiligheid, delen van informatie met externe

uitvoeringsorganisaties. Sommige gegevens dienen altijd vertrouwelijk te blijven (denk

bijvoorbeeld aan opvang op een geheim adres ihkv huiselijk geweld).

Zowel v.w.b. regievoering als voor de informatiehuishouding zal rekening moeten worden

gehouden met zowel reguliere trajecten (uitgangspunt: de burger zelf kan veel inzien en kan zelf in

17

charge zijn), als trajecten waar sprake is van dwang (waar de burger veelal

zelf ook veel minder inzage zal hebben in het eigen dossier).

2.2 Regiemodellen

Regie is een breed begrip. In de context van dit PvE is het begrip regie te relateren aan de wens

van de gemeente om zicht te hebben en controle te hebben op de burgersituatie op het moment

dat er sprake is van verminderde zelfredzaamheid. Met andere woorden: het regisseren van de

ondersteuning van individuele burgers dan wel een gezin.

We onderkennen vier modellen voor het inrichten van de regisseursrol (bron: gemeente Almere).

Deze „basis‟-modellen beschrijven in de kern de wijze waarop de gemeente regie kan inrichten. We

noemen dit basismodellen, omdat elke gemeente in zijn eigen beleid en inrichting van de

operationele werkelijkheid vrij is om keuzes te maken. Waarschijnlijk zullen er daarom nog

subvarianten van de regiemodellen ontstaan. Echter deze vier basismodellen beschrijven feitelijk

de vier uitersten van de varianten die gekozen kunnen worden.

Geen gemeentelijke regie / zelfregie Regisseur als single point of contact (“light”-

versie van regie)

Regisseur als spin in het web Regisseur als uitvoerder

Figuur 4 Vier vormen van regie

18

Elke gemeente zal zijn eigen vorm van regie kiezen. Het is niet

onwaarschijnlijk dat gemeenten hierbij zelfs een vorm kiezen waarbij meerdere regiemodellen

gehanteerd worden. Dit al naar gelang de zwaarte van het vraagstuk. Naar mate de

zelfredzaamheid van de burger afneemt zal er naar verwachting meer behoefte aan een

intensievere vorm van regie zijn.

Bijvoorbeeld: er is sprake van een burger die verminderd zelfredzaam is (en aanspraak doet op

gemeentelijke voorzieningen) maar nog wel voldoende burgerkracht heeft om met volle verstand

zelf zaken te coördineren en organiseren. In deze vorm kan de gemeente kiezen voor het

regiemodel waarbij de burger zelf regie voert. De gemeente zal enkel op afstand acteren en

monitoren in hoeverre het proces goed verloopt.

Een tweede voorbeeld heeft betrekking op de situatie dat een burger helemaal niet meer

zelfredzaam is. In een dergelijk scenario zal de gemeente volledig regie (willen) voeren. Liefst in

het model waarbij de regievoerder mandaat heeft om zelf opdrachten richting de interne en

externe organisaties te geven. Dit om strak te sturen op het juiste oplossingsarrangement. Hierbij

geldt nog steeds: burgerkracht gaat voor. Wat door de burger zelf of in zijn omgeving opgelost kan

worden heeft voorrang. Pas daarna wordt professionele hulp ingeschakeld. Hierbij is het de

doelstelling om vanuit een ondersteuningsplan gecoördineerd de hulpverlening plaats te laten

vinden.

Welk model of welke modellen een gemeente ook kiest voor een specifiek ondersteuningstraject,

regie moet ondersteund worden door de 3D-Suite. Dat wil zeggen; het moet op verschillende

momenten van het proces mogelijk zijn om inzicht te krijgen in de burger- of gezinssituatie. Zowel

vanaf het eerste gesprek, het monitoren en bijhouden van de voortgang van het plan tot het

moment dat de regisseur „de regie‟ afsluit. Hierbij is het belangrijk dat onderscheid gemaakt kan

worden in het presenteren van “dat” en “wat” informatie. In de basis zijn de gebruikte gegevens

hetzelfde maar afhankelijk van (de rechten binnen) de taak of rol worden de meer detailgegevens

(het “wat”) gepresenteerd.

Om het integrale klantbeeld in al zijn facetten te kunnen presenteren is het dus van belang dat

zowel de registraties binnen de 3D-Suite ontstaan als ook het klantbeeld uit derde bronnen

gerelateerd zijn. Slechts dan is het mogelijk zowel tijdens het (regie)proces als in de

verantwoording een samenhangend beeld in de juiste context te creëren.

Een ander aandachtspunt betreft het kunnen omgaan met (inkomende) signalen/meldingen. Deze

signalen en meldingen kunnen op elk willekeurig moment in het proces binnen komen. Ze kunnen

gestructureerd zijn met een vastgesteld doel of het kan gaan om een ongestructureerd signaal

zonder een duidelijk doel (bijvoorbeeld een wijkagent die een mogelijk drankprobleem meldt3). Het

kan ook om een status melding gaan (bijvoorbeeld “burger in behandeling genomen”) die door een

uitvoerende instantie gemeld wordt. Deze meldingen en signalen die via diverse kanalen door

diverse actoren binnen komen moeten op een juiste wijze ondergebracht en gerelateerd kunnen

worden aan (regie over) lopende ondersteuningstrajecten en aan specifieke burgers / gezinnen.

Hierbij is het van belang de bovengenoemde uitgangspunten (integraal klantbeeld en

samenhangende registraties) in acht te nemen.

3 Gemeenten zijn in de toekomst verantwoordelijk voor toeleiding en daarmee het ontvangen en

afhandelen van zorgmeldingen politie

19

In alle gevallen wordt uitgegaan van 1-gezin 1-dossier 1-plan, per gezin of

burger één integraal plan met doelen en maatregelen om de doelen te bereiken, en 1 regisseur.

20

2.3 Burgerportaal

2.3.1 Inleiding

Het gevraagde regie- en samenwerkingsplatform richt zich primair op de ondersteuning van de

professionele regisseur. Eén van de uitgangspunten en doelen van de decentralisaties op het

sociaal domein is echter versterking van de zelfredzaamheid (zie inleiding). Door zelfregie (door de

burger zelf, of door zijn sociale omgeving) te versterken kan de burger ook zelf het initiatief nemen

om zijn zelfredzaamheid te versterken.

Voor de zelfregie moet de burger dus wel over de noodzakelijke informatie beschikken. Maar ook

bij de minder zelfredzame burger is het uitgangspunt dat de deze te allen tijde de beschikking

moet hebben over veel informatie die over hem is vastgelegd op het sociale domein. Echter zal niet

alle informatie kunnen worden gedeeld: niet de wat-informatie in de backoffices van uitvoerings-

organisaties of in de notities van hulpverleners, waar de privacy van andere betrokkenen zou

worden geschaad, of wellicht ook vanwege de risico‟s op schade wanneer op de account van de

burger wordt „ingebroken‟ (lees: wachtwoord heeft deze ergens op een briefje staan).

Voor de zelfregie zal de burger niet alleen over informatie moeten kunnen beschikken, ook is het

mogelijk dat de burger onder eigen regie de mogelijkheid krijgt gebruik te maken van (zelf)intake,

een ondersteuningsplan kan maken en zelfs (beperkt) maatregelselecties kan doen. Wanneer de

burger de beschikking heeft over een Persoonsgebonden budget zal inzet en uitputting daarvan

hier tevens kunnen worden bijgehouden en bewaakt. In de kern is dit dezelfde informatie en

functionaliteit die ook de regisseur nodig heeft met een aantal specifieke autorisatie- en

beveiligingsaandachtspunten

Een burgerportaal met algemene informatie en een klantspecifiek (gepersonaliseerd) deel kan veel

vragen/ contacten overbodig maken, want de burger kan zelf de informatie vinden. Dat kan als

bijeffect hebben dat dit de gemeentelijke organisatie ontlast.

Het is overigens denkbaar dat in eerste instantie het Burgerportaal niet alle functionaliteit bevat die

op termijn nodig of gewenst is. Op korte termijn verwachten we een focus op (ten minste) de

regierol van de gemeente, op langere termijn aangevuld met meer “selfservice”-mogelijkheden.

2.3.2 Informatievoorziening en vraagverheldering

Een zelfredzame burger die enkelvoudige ondersteuning nodig heeft kan met behulp van een

burgerportaal (vaak zonder inloggen) de mogelijkheden onderzoeken voor ondersteuning door

middel van een vraagverhelderingsmodule (ook wel vraaggeleiding genoemd). Met behulp van bijv.

de Eigen Kracht Wijzer 4 kan eigen kracht en mogelijkheden voor informele ondersteuning in kaart

worden gebracht. In het doorlopen van een vraaggeleiding wordt als het ware een klantprofiel (een

beeld van de zorgbehoefte) opgebouwd.

Idealiter zou deze functionaliteit deel uit kunnen maken van het bestaande digitaal loket van de

gemeente, mits de integratie tussen 3D-Suite en digitaal loket voldoende nauw is (enkelvoudige

inrichting en beheer). Voor burgers die op basis van de analyse in de vraagverhelderingsmodule

toch nog aanspraak willen maken op een individuele voorziening kunnen de opgevoerde gegevens

bewaard worden en input zijn voor een keukentafelgesprek waarbij de regisseur „aan de

keukentafel‟ de behoeften van de burger of het hele gezin bespreekt.

4 www.eigenkrachtwijzer.nl

21

Voor burgers die geen vraagverheldering nodig hebben en precies weten

waar ze behoefte aan hebben kan een sociale kaart waarin alle lokale voorzieningen staan een

hulpmiddel zijn. De vraag is echter of deze achter een burgerportaal zou moeten. Het zou van

toegevoegde waarde zijn als op basis van de informatie in het burgerportaal ook een vertaling naar

diensten en bijvoorbeeld kosten kan worden gemaakt. De sociale kaart kan ook een algemene

voorziening zijn binnen in de website van de gemeente.

2.3.3 Inzage in eigen integraal klantbeeld (inclusief plan)

De burger heeft in beginsel toegang tot zijn gegevens/ dossier en heeft daarbij diverse

functionaliteiten tot zijn beschikking. Hierdoor kan de burger in belangrijke mate actief „meedoen‟

in zijn of haar plan en de daarbij uitgezette trajecten. Zelfregie is mogelijk.

Zodra men een beroep moet doen op ondersteuning omdat men het met de eigen netwerken niet

redt, komen ook andere aspecten van het Burgerportaal in beeld. Een burger moet dan de

mogelijkheid krijgen om informatie in te zien en te beheren, een transactie te starten, etc. Kortom,

zelf regie te voeren. Het doel is om deze functionaliteiten te bundelen in een eenduidig, digitaal

Burgerportaal met een heldere toegang. Zie figuur 5, welke een samenvatting geeft van een

mogelijk Burgerportaal.

Figuur 5 Voorbeeldopzet burgerportaal

Het is van groot belang om nauwkeurig de toegang te kunnen regelen. De burger kan vaak (doch

niet altijd) in staat worden gesteld om zelfstandig te kunnen bepalen met wie delen van informatie

uit zijn dossier gedeeld wordt. Dit kunnen professionals van de gemeente zijn,

ondersteuners/zorgverleners, wijkwerkers, familieleden of overige personen. Ook de regisseur van

de gemeente kan deze autorisatiematrix gebruiken om binnen (wettelijke) kaders (delen van)

informatie uit het dossier te delen met collega‟s of derden. We noemen dit “ad-hoc” autorisaties,

i.t.t. de autorisaties die door de functioneel beheerder worden ingericht.

22

Zo kan een ondersteuningsplan gegevens en acties omvatten van/voor het

gezin, maar ook van/voor individuele leden uit het gezin en ook anderen (familieleden of anderen

uit het sociale netwerk) kunnen een rol spelen in het plan. Zo heeft ieder, afhankelijk van zijn rol,

toegang tot delen van het plan. Ook functionaliteiten zoals het toevoegen van notities of

documenten moeten zo ingericht zijn dat de output direct in de juiste context (aan de juiste actie

op het juiste niveau) met de gewenste signalering/ notificatie wordt geplaatst. Alles ten dienst van

een soepele afhandeling en communicatie.

Niet onbelangrijk is dat ook alle uitgevoerde mutaties, acties, registraties en toegang tot het

klantdossier gelogd moet worden. Dit logboek moet –samengevat tot begrijpelijke vormen–

inzichtelijk worden gemaakt voor daartoe geautoriseerde gebruikers, zodat burger (op hoofdlijnen:

bijv. wie heeft toegang) en professional (op meer detail, afhankelijk van de rol van de gebruiker)

kunnen zien wat er gebeurd is en daarmee gewaarborgd kan worden dat er volgens de

privacyregels is gehandeld en er alleen informatie is gedeeld met partijen die daar wettelijk

toegang tot hebben (doelbinding) dan wel daarvoor toestemming hebben van de burger.

Daarnaast, in het kader van het Antwoord©-concept, hebben gemeenten veel energie gestoken in

het verbeteren van de contacten met burgers en bedrijven: het klantcontactcentrum (KCC), een

vernieuwde website incl. een burgerportaal met persoonlijke informatie („Mijn gemeente‟),

accountmanagers, etc. Dit gaat over alle domeinen, waarop de gemeente actief is heen. Vanuit het

1 loket idee verdient de aansluiting/ integratie van het burgerportaal op het sociale domein op het

algemene gemeentelijke burgerportaal aandacht.

2.3.4 Communicatie

Er zijn twee manieren om te communiceren tussen de partijen, zoals regisseur, mantelzorgers en

tweedelijns professional. De gestructureerde wijze van communiceren, waarin een bericht een

vaste vorm en betekenis heeft, en er ook volgens een vast format berichten terug komen. Deze

zgn. ketenberichten (zie ook par. 2.4.5) staat ook de regisseur ter beschikking ter aansturing van

de tweedelijnszorgverlening.

Als er sprake is van zelfregie door de burger zelf of een mantelzorger is deze communicatie-

functionaliteit ook in het burgerportaal denkbaar (waar keuzes van de burger „onderwater‟

resulteren in ketenberichten). Dit geeft ook nieuwe mogelijkheden voor een tussenvorm van

Persoonsgebonden budget (PGB). De burger krijgt een budget, te besteden bij partners waarmee

de gemeente een contract heeft.

De tweede manier van communiceren is via de (v.w.b. berichtinhoud) ongestructureerde berichten.

Algemene vragen van de burger aan regisseur of aan tweedelijnsondersteuners, terugkoppeling

aan de regisseur over de ondersteuning van tweedelijnszorg of een van hen op de hoogte brengen

van de ontwikkelingen. Ook kan hier de communicatie plaatsvinden die nodig is voor de

afstemming tussen professionele en informele ondersteuning. Dergelijke communicatie kan

bestaan uit notities via het Burgerportaal, brieven, maar ook e-mails, chats, etc. Bij voorkeur

gebeurt de communicatie zoveel mogelijk via de 3D-Suite z.d.d. „wat‟-informatie niet wordt

gedeeld, en wordt de burger, mantelzorger of de professional waarbij de e-mail of sms op de

hoogte gesteld van het feit dat er berichten klaar staan.

Een belangrijk aspect bij ook berichtgeving is beveiliging, immers het betreft hier informatie over

„handelen‟ door betrokkenen en eventuele feedback daarop.

23

Multichanneling

De hierboven beschreven functionaliteit gaat uit van een digitaal burgerportaal als een van de

beschikbare kanalen voor de burger. Echter, de burger heeft de vrijheid zijn voorkeurskanaal te

kiezen. Het idee is dat een bericht met minimale handeling direct op de juiste plaats, bij de juiste

persoon (of team) onder de aandacht wordt gebracht en dat verdere follow-up kan worden

gegeven.

De diversiteit aan kanalen is groot en maakt multichannelingmanagement noodzakelijk. Balie, post,

telefoon zijn veelal goed ingebed. Dat is voor en internet (e-formulieren) en e-mails een stuk

minder, evenals voor andere nieuwe kanalen: chat, skype, video-overleg, social media, etc.

verdienen meer aandacht. Uitgewerkt zal moeten worden hoe deze kanalen aansluiten bij de

traditionele kanalen en hoe het geheel aan oplossingen wordt versterkt. Ook hier is beveiliging een

belangrijk aandachtspunt.

De 3D-Suite zal zoveel mogelijk kanalen moeten kunnen ondersteunen, doch de mate waarin de

informatie geautomatiseerd in de 3D-Suite wordt opgenomen kan verschillen. Sommige

communicatie zoals berichten uit social media kunnen bijvoorbeeld ook gekopieerd/geplakt worden

door de regisseur.

24

2.4 Regie

Voor een effectieve aanpak is dus een goede samenwerking tussen instellingen en hulpverleners

van belang, waarbij hulpverleners elkaar informeren, mogelijke risico‟s signaleren en hulpvragen

doorgeleiden naar de juiste hulpverlener. Er is sprake van één plan per gezin (of individuele

burger) en één hulpverlener is verantwoordelijk voor het gezin: de regisseur. De rol van de

regisseur is:

- contactpersoon voor het gezin / burger

- probleemverkenning en opstellen ondersteuningsplan (1-plan), samen met gezin:

o inventariseren van gezinssituatie, problematiek en mogelijke / gewenste ondersteuning

(integrale intake)

o zorgen voor een laagdrempelig “gekanteld” ondersteuningsarrangement. Dat wil zeggen

het liefst buiten de sfeer van betaalde voorzieningen.

o opstellen van het ondersteuningsplan, bewaken van de uitvoering van het ondersteu-

ningsplan

- organiseren en bevorderen van afstemming en samenwerking tussen verschillende hulpverle-

ners

- overzicht houden over welke hulpverleners bij het gezin betrokken zijn en welke hulp zij leve-

ren; organiseren dat op het juiste moment de juiste hulpverlening beschikbaar is

- organiseren van escalatie

- rekening houden met en bewaken van budgetten (persoonsgebonden budget van de betreffende

burger, maar ook andere budgetten)

- kwaliteitsbewaker (tijdens het traject, maar zeker aan het eind bij de evaluatie)

Hiermee is de rol van de regisseur aanvullend op die van de andere hulpverleners. De regisseur

kan puur vanwege de regie bij een gezin betrokken zijn. Maar het kan ook zijn dat één van de bij

het gezin betrokken hulpverleners de rol van regisseur op zich neemt (zie de eerder benoemde

vormen van regie). De regisseur kan als zodanig ook een medewerker van buiten de gemeente

zijn, incl. de burger zelf.

Vanwege de breedte van het sociale domein kan een gemeente te maken hebben met – en moet

regie voeren over - vele tientallen uitvoeringsorganisaties en nog veel meer individuele

hulpverleners. De regisseur houdt het overzicht over de verschillende hulpverleners en stemt waar

nodig met hen en met het gezin af. Hiervoor is het van belang dat de regisseur zicht heeft op zowel

de situatie van het gezin als op welke hulpverleners zijn betrokken en welke hulp zij leveren.

Binnen de regiefunctie is er sprake van drie vormen van informatieuitwisseling. Ten eerste is er

sprake van inkomende en uitgaande signalen en meldingen, ten tweede van (ongestructureerde)

sociale communicatie en interactie en ten derde van (gestructureerde) ketenberichten.

2.4.1 Integraal klantbeeld (incl. Inkijk)

In principe zal de burger / het gezin of de omgeving van de burger waar mogelijk zelf de regie

moeten voeren over de uitvoering van dit plan. In de situatie dat de burger zelf de regie niet kan

voeren en er ook in de sociale omgeving (netwerk) niemand beschikbaar is die de regierol kan

uitvoeren zal een professionele kracht de regierol overnemen. Het is deze regierol waarnaar we

verwijzen als we in dit stuk spreken over de regisseur. Het is de rol van de regisseur om samen

met de burger de keuzes te maken welke ondersteuning er wordt ingezet om de burger weer

zelfredzaam te maken. Vervolgens moet de regisseur erop toezien dat de ondersteuning die rond

de burger georganiseerd is op de afgesproken wijze verloopt. De ondersteuning van de burger kan

25

bestaan uit informele ondersteuning (ondersteuning van buren, vrienden en

familie), en professionele tweedelijns ondersteuning.

Voor het uitvoeren van de regierol zal de medewerker in één oogopslag moeten kunnen zien welke

ondersteuning er voor burger is georganiseerd en wat de status is van die ondersteuning. In de

kern is dat dezelfde informatie die de burger kan inzien door middel van het burgerportaal (doch

kan meer omvatten). Dat noemen we het integrale klantbeeld en dat moet in iedere fase van het

ondersteuningsproces beschikbaar zijn. Zelfs voor het eerste gesprek moet basisinformatie

beschikbaar zijn omdat het ook mogelijk is dat de burger zelf via andere kanalen enkelvoudige

ondersteuning heeft gekregen. Het is de keuze van de regisseur of het klantbeeld eerst wel of niet

wordt geraadpleegd voor het eerste gesprek.

De vastlegging van de informele ondersteuning zal in veel gevallen door de regisseur zelf gedaan

worden als uitwerking van de ondersteuning in overleg met de burger. De informatie over

bestaande tweedelijnszorg zal in de ideale situatie real time worden opgehaald uit de

informatiesystemen van de organisaties die de tweedelijnszorg uitvoeren (zoals men in de werk- en

inkomenketen de informatie uit de keten raadpleegt). De reden hiervoor is dat op deze wijze er

maar één realiteit is en de regisseur over de meest actuele informatie beschikt. Daarnaast is het de

meest efficiënte oplossing omdat de uitvoerder van de tweedelijnszorg maar op één plek de

informatie hoeft bij te houden en geen dubbele boekhouding hoeft te voeren. In de fasering van de

invoering van het 3D informatiesysteem kan eventueel eerst een webportaal beschikbaar zijn om

de handmatige bijwerking van deze informatie door de tweedelijnszorg te faciliteren. Dit omdat het

niet realistisch is te verwachten dat alle organisaties die tweedelijnszorg aanbieden al dan in staat

zijn deze informatie via koppelingen tussen systemen real time te realiseren. Enkele belangrijke

landelijke bronnen zullen wel direct ontsloten moeten worden.

Het totaaloverzicht van de ondersteuning is de kern van het integraal klantbeeld. Daarmee is het

integraal klantbeeld nog niet compleet. Om de regisseur in één oogopslag een overzicht te geven

van de stand van zaken is meer nodig. Te denken valt aan een samenvatting van de laatste meting

van de Zelfredzaamheidsmatrix, weergave van de laatste entries van het contactjournaal, een

overzicht van de eigen aantekeningen over de burger, een financieel overzicht van de gemaakte

kosten tot zover, etc. Wat het ideale klantbeeld zal zijn hangt af van de voorkeuren van de

gebruiker en de gemaakte beleids- en proceskeuzes van de betreffende gemeente. De kern zal

echter het totaaloverzicht van de informele en de eerste en tweedelijnszorg blijven.

Inkijk gaat in het algemeen over identificerende gegevens en 'buitenkant-informatie' (dus het “dat”

i.p.v. het “wat”), zoals o.a.:

- NAW over de betrokken persoon en het gezin

- Werk, inkomens- en uitkeringsverhoudingen

- Ontvangen ondersteuning, waaronder ook schulden en schuldhulpverlening

- Onderwijs en opleidingsgegevens, incl. leerplicht / RMC

- Evt. justitiële gegevens

Deze gegevens worden zoveel mogelijk uit bestaande systemen gehaald. Zo is in de Suwiketen5 de

GeVS (Gezamenlijke elektronische Voorzieningen Suwi) ontwikkeld Via dit knooppunt is informatie

uit verschillende bronnen (zoals GBA, UWV, DUO, RDW, Kadaster) ontsloten en wordt deze

informatie beschikbaar gesteld aan de Suwi-ketenpartijen (SVB, UWV en gemeenten). Met behulp

5 Suwi: de Wet structuur uitvoering werk en inkomen

26

van deze gegevens wordt het DKD (het DigitaalKlantDossier) gevormd en

via een webapplicatie getoond. Het DKD zelf is geen bron maar een virtueel dossier dat uit de

aangesloten bronnen wordt opgebouwd. Geautoriseerde afnemers kunnen ook rechtstreeks

aansluiten op de GeVS (via de component Suwinet-Inlezen) om de brongegevens zelf in „eigen‟

applicatie te verwerken.

In dit document spreken we verder van de GeVS, de officiële en wettelijke benaming voor dit

knooppunt. Zie bijlage 12.2 voor een kort overzicht van de informatie die via de GeVS inzichtelijk

is.

Informatie wordt tevens ontsloten uit de justitiële keten, uit de basisadministraties, en uit

verschillende backofficesystemen (zoals de onderwijsadministratie) van gemeente en

uitvoeringsorganisaties. Er ligt een koppeling met de VIR (VerwijsIndex Risicojongeren 6).

Afhankelijk van de situatie en de rechten moet het mogelijk zijn voor de regisseur om 'door te

prikken' naar meer achterliggende gegevens (het “wat”). In alle gevallen is van belang dat de

inzage transparant is (de betrokken burger kan zien wie welke gegevens heeft ingezien), dat de

inzage aan een doel is gerelateerd en dat een zorgvuldige afweging is gemaakt of de gevraagde

gegevens proportioneel zijn voor het doel (doelbinding). Degene die de inzage doet moet hierover

verantwoording kunnen afleggen.

De inzage is in beginsel alleen beschikbaar voor de regisseur en het gebruik is gebonden aan de

ondersteuning van multiprobleemgezinnen of aan een nader onderzoek op basis van een

(vroeg)signaal. Het gezin en de betrokken personen zelf moeten hun eigen gegevens ook kunnen

inzien, voor zover deze daar voor is geautoriseerd (bijv. niet-vertrouwelijke notities van een

individuele behandelaar, en ook niet wanneer dat vanwege veiligheid de informatie niet kan worden

gedeeld).

2.4.2 Het ondersteuningsplan (1-plan)

Het ondersteuningsplan (zie 1-gezin 1-plan) is het plan van aanpak waarin de afspraken tussen het

gezin en de hulpverleners is vastgelegd. Het is daarnaast de basis waarop de bewaking van de

voortgang van de afgesproken hulp plaatsvindt. Het plan bevat afspraken over de activiteiten die

de burger of het gezin zelf kan/wil/moet doen met de eigen sociale omgeving (in het kader van

versterking zelfredzaamheid, eigen verantwoordelijkheid en eigen kracht & samenkracht) en

afspraken over activiteiten die door professionele hulpverleners worden geleverd.

Het plan kan acties/maatregelen bevatten voor bijvoorbeeld het gehele gezin, maar ook voor

individuele leden van dat gezin. Gegevens, afspraken en documenten moeten aan het juiste

niveau/ onderdeel gekoppeld kunnen worden.

Het plan is in beginsel toegankelijk voor het gezin, de regisseur en - voor zover het hun eigen

dienstverlening betreft - de betrokken hulpverleners. Informatie in eigen dossiers en systemen van

hulpverleners is niet toegankelijk voor gezin en regisseur (hooguit „dat‟, niet „wat‟).

6 VIR: zie ook www.rijksoverheid.nl/onderwerpen/jeugdzorg/vraag-en-antwoord/wat-is-de-

verwijsindex-risicojongeren-vir.html en

http://wetten.overheid.nl/BWBR0027338/geldigheidsdatum_01-05-2013 (de Wet VIR); VIR

werkt via een melding-respons systematiek

27

Afhankelijk van de hoeveelheid en type ondersteuning en afhankelijk van of

er bijv. veiligheid in het geding is, kan de burger zelf (in overleg met de regisseur) de lijst

personen/organisaties met toegang stellen, ontzeggen en inzien. In voorkomende gevallen (bijv.

dwang) zal de regisseur de toegang zonder overleg bepalen.

2.4.3 Inkomende/uitgaande signalen en meldingen

Signalen en meldingen hebben betrekking op informatieuitwisseling omtrent de status van een

burger. Dit is de informatiestroom waar informatie over een burger gedeeld wordt die aanleiding

kan zijn om een burger in regie te nemen of een voorziening aan te bieden.

In situaties waar het misloopt in gezinnen blijkt vaak dat er al langer signalen waren, die daarop

wezen of waaruit de verslechtering van de situatie te voorspellen was. Signalen kunnen ontstaan

vanuit:

- Het gezin of burger zelf, of de omgeving van de burger/ het gezin (onderliggende problematiek,

buren, familie, een voetbaltrainer, overlast gedrag etc.)

- Professionele hulpverleners, incl. eigen waarneming van de regisseur/ wijkwerker

- Objectieve bronnen (zoals databases). Bijvoorbeeld, een signaal dat de maandhuur bij herhaling

niet betaald is bij de woningbouwcorporatie, een signaal dat er bovenmatig wordt gespijbeld,

stopzetten uitkering

Het ontvangen en op de juiste waarde schatten van (vroeg)signalen is belangrijk om te voorkomen

dat gezinnen zwaardere en/of langdurige vormen van ondersteuning nodig hebben of zelfs in een

multi probleemsituatie terecht komen. Vroegtijdig signaleren kan ook voorkomen dat de situatie in

een multiprobleemgezin verder escaleert.

In de huidige uitvoeringssituatie is (vroeg)signalering meestal georganiseerd via de verschillende

losse terreinen. De samenwerking / afstemming tussen de terreinen is beperkt. Zo is rondom

Algemeen Meldpunt Kindermishandeling en Steunpunten Huiselijk Geweld de signalering van

kindermishandeling en huiselijk geweld georganiseerd, in de Verwijsindex Risicojongeren (VIR) kan

jeugdproblematiek gemeld worden, en via Suwinet kunnen hulpverleners in de sector werk &

inkomen elkaar informeren. Terwijl er geregeld sprake is van overlap in gezinnen die binnen multi-

problematiek bekend zijn.

Een signaal kan meer of minder informatie bevatten, veelal met name „dat‟-informatie. Een

(vroeg)signaal bevat minimaal de volgende gegevens:

- Identificatie van de betreffende persoon, gezin

- Contactgegevens van de melder

- Relatie tussen melder en betrokken persoon / gezin

- De situatie die aanleiding gaf tot de melding

- De inhoud van de signalering (het “dat”)

In het verlengde van de definitie van multiprobleemgezinnen is het nodig dat signalen uit

verschillende probleemgebieden kunnen worden gecombineerd en geverifieerd. Daarnaast is het

van belang dat de signalen op één plek samen komen (bij voorkeur bij de regisseur).

Signalen kunnen op meerdere manieren (via verschillende kanalen) binnenkomen én uitgaan,

bijvoorbeeld via de mail, telefoon, via een geautomatiseerd systeem, of in een gesprek. In verband

28

met de transparantie is wel van belang dat elk signaal (goed beveiligd)

wordt vastgelegd. Niet alle (vroeg)signalen zullen leiden tot een melding, de afweging hierbij moet

kunnen worden vastgelegd.

Signalen moeten na enige tijd (een nader door gemeente te bepalen periode, aansluitend op

wettelijke bewaartermijn) uit het actieve systeem verdwijnen: 'het recht om vergeten te worden'.

Meldingen zijn alleen in te zien door de melder, de regisseur, en (in beginsel) het betrokken gezin /

persoon. Er is inzagerecht voor het gezin, maar geen wijzigingsrecht bij bepaalde (nader te

bepalen) signalen. Dit om schaduwregistraties bij professionals te voorkomen.

Vroegsignalering, en de daarbij behorende gegevensuitwisseling en aanpak, is ter voorkoming van

(escaleren van ) multiprobleemsituaties, en zal daarom juist ook van toepassing zijn voor gezinnen

waar nog geen sprake is van zware vormen van hulp en ondersteuning. Dit stelt eisen aan de

zorgvuldigheid, en vraagt een afweging wanneer wel of niet te melden. Vroegsignalering kan ook

leiden tot eenvoudige en enkelvoudige acties ter voorkoming van erger (bijv. begeleiding om

ontslag te voorkomen).

De Verwijsindex Jongeren (VIR) is een voorbeeld van het mechanisme van een signalering (incl.

register) en hoe het kan en wat er geregeld moet worden, al zullen de signaleringen van een VIR

vanwege de aard van de berichten vaker resulteren in dwang dan andersoortige signaleringen.

Het is mogelijk dat er meer landelijke / centrale registers komen. Immers, burgers zijn niet

honkvast en moeten in beeld blijven. En een gezin (of huishouden) kan zich over meerdere

gemeenten uitstrekken. Bijv. juist er sprake is van verhuizingen, is het van belang die informatie

goed en langer te bewaren en in te laten zien voor andere professionals.

In (ook) een landelijk signalenregister wordt dan bijgehouden welk signaal tot welke melding heeft

geleid. Het signalenregister krijgt hiermee een dubbelfunctie (signalen-/meldingenregister). Als en

wanneer sprake zou zijn van landelijke signalen-/meldingenregisters zal een 3D-Suite hierop

moeten aansluiten.

2.4.4 Ongestructureerde communicatie en interactie

Daarnaast zal er ook informatieuitwisseling plaatsvinden die betrekking heeft op interactie tussen

burger en hulpverleners. Hierbij valt te denken aan input van de burger op het ondersteuningsplan

(1-plan), digitale communicatie (gesprekken), notities, e-mails. Brieven, etc. tussen burger en

hulpverlener.

Veel contacten tussen hulpverleners, gezin en regisseur zijn free-format en dus niet in een (v.w.b.

berichtinhoud) gestructureerd format te vangen en zullen dus niet via gestandaardiseerde digitale

berichten tussen informatiesystemen plaatsvinden. Zie ook par. 2.4.3. Informatieuitwisseling

bestaat uit 1. inkomende en uitgaande signalen en meldingen, 2. (ongestructureerde) sociale

communicatie en interactie en 3. (gestructureerde) ketenberichten.

Het is –o.a. vanwege transparantie– wel wenselijk dat bijgehouden wordt welke gegevens en

documenten zijn uitgewisseld, door naast informatieuitwisseling binnen de 3D-Suite (bijv. een

notitieveld of een discussieplatform) ook uitwisselingen via mail en/of chat te laten in de 3D-Suite

op te slaan (bijv. in de context van een cliëntdossier). Omdat de inhoud vaak gevoelige

persoonsgegevens kan bevatten, is het wenselijk dat deze mail/chat in een aparte beveiligde

omgeving kan plaatsvinden, zo mogelijk niet via het reguliere internet. Communicatie vindt zoveel

29

mogelijk plaats via versleutelde en goed beveiligde verbindingen. Via

onversleutelde kanalen zou hooguit een verwijzing kunnen worden gegeven naar de informatie die

(na authenticatie) in de 3D-Suite beschikbaar is.

2.4.5 Gestructureerde ketenberichten

De regisseur zal gespecialiseerde ondersteuning niet zelf gaan leveren, daarvoor zal er in overleg

met de burger een gespecialiseerde tweedelijnshulpverlener worden ingeschakeld. Opdrachten aan

ketenpartners worden–bijv. als deelzaak- in de 3D Suite zelf geadministreerd incl. termijnen, zodat

de regisseur de follow-up kan volgen en bewaken.

Communicatie met externe tweedelijnshulpverleners kan –wanneer en voor zover hier standaarden

voor bestaan of worden ontwikkeld- bestaan uit een standaard set (gestructureerde, digitale)

berichten waarmee opdracht tot zorgverlening kan worden gestart7 en terugkoppeling over de

voortgang (status, resultaat en financieel) kan worden uitgewisseld en ook in de geautomatiseerde

systemen kunnen worden verwerkt.

Hiermee wordt dan het handmatig verwerken van dit soort berichten voorkomen, dat bespaart

fouten. Bovendien laat een geautomatiseerd bericht zijn spoor na in het informatiesysteem van de

regisseur en kan de regisseur ook zien wat de opvolging van het bericht is geweest.

Als voorbeeld van het principe van ketenberichten zou het AZR (Awbz-brede zorgregistratie)

kunnen dienen, niet om het AZR te kopiëren maar meer vanwege het idee en de uitwerking

daarvan.

7 Een VTO (verzoek tot onderzoek aan de Raad voor de Kinderbescherming) is een voorbeeld van

gestructureerd bericht aan tweedelijns partij.

30

2.5 Regie op regie

Onder regie op de regie, en „sturing‟ daarbij verstaan we hier het sturen op

1) doeltreffendheid

a) effectiviteit van handelen (best practices/ wijkaanpak, doelgroepaanpak) en

b) resultaat (gemaakte afspraken met externe partners, maar ook op de beweging van

intensieve naar eenvoudige ondersteuning naar zelf doen ) en

2) efficiency (budgetten/ realisatie).

Het betreft hier dus niet het regisseren van de ondersteuning van individuele burgers dan wel een

gezin. In onderstaand overzicht staat de informatie die in de verschillende „regelkringen‟ wordt

geregistreerd en die nodig is om regie op regie te kunnen voeren:

Figuur 6 regelkringen

Bij regie op regie zijn er verschillende „stakeholders‟ die (sturings)informatie nodig hebben om te

kunnen bijsturen:

- Wijkmanager krijgt van gemeente (beleidsmedewerker, directie en bestuurder) beleidsmatige

en budgettaire kaders en formatie om sociale index naar een bepaald niveau te brengen en bur-

gers hoger op zelfredzaamheidsmatrix te brengen. N.B. Deze kaders worden onderscheiden

naast het primaire proces waar regisseur en wijkmanager in werken

Caseload, € (incl kos-

ten van regie), uren,

%klantcontact, resul-

taat Klantbeeld

Opdracht+ budget

€

Resultaat, €, wij-

kindex

Inkoopvoorwaarden, €,

doorlooptijd, wachttijd/-

lijst, kwaliteit, resultaat

Resultaat

Resultaten

Doelgroepen

Kwaliteit zorg

Efficiency

31

- Externe 2e lijns professionals en gemeentelijke backoffice hebben con-

tractuele verplichtingen voor het leveren van collectieve of individuele voorzieningen. In een

contract/subsidiebeschikking staan de afspraken rondom diensten die gemeten moeten worden

(input, throughput, output, outcome). Externe 2e lijns professionals zullen moeten werken op

basis van een eenduidig format waardoor ze effectief de gegevens kunnen teruggeven aan de

gemeenten waarvoor ze werken (via een gemeenschappelijke voorziening). Daarnaast zijn de

gegevens onderling vergelijkbaar.

Al ten tijde van inkoop zal door de gemeente aandacht moeten worden besteed aan afspraken over

(1) financiële prikkels gericht op betere en eerdere hulp en ondersteuning, (2) outcome-gerichte

informatieuitwisseling van gegevens.

In bovenstaand figuur 6 zijn de relevante stakeholders („zij die sturen‟) centraal gezet. Voor de 3D-

suite is het belangrijk dat de juiste informatie voorhanden is om tijdig te kunnen ingrijpen bij

overschrijdingen, onwenselijke situaties en om nieuwe kaders te kunnen meegeven. Signaleringen,

handreikingen bij de intake, overzichten, etc. geven daarbij (financiële) grip.

Het kunnen sturen op de beschreven „regelkringen‟ vindt plaats op basis van informatie die

beschikbaar is of ontstaat in de processen/ bij de uitvoering. De voor regie op regie benodigde

gegevens worden zoveel mogelijk onttrokken aan het gestructureerde berichtenverkeer. En de

gegevens die „vanzelf‟ ontstaan vanuit de uitvoering. Overige stuurinformatie zal zoveel mogelijk

beperkt moet worden tot het hoogst noodzakelijke, omdat iedere informatiebehoefte die niet

automatisch ontstaat, extra registratieve handelingen vraagt van de regisseur of anderen.

Deze informatie zal ook in het kader van forecasting nodig kunnen zijn: wat komt er op korte /

middellange / lange termijn in geld en in workload op de regisseur en de professional af?

Het verkrijgen van de stuurinformatie zou ook moeten plaatsvinden voor de enkelvoudige

processen waar (financiële) gegevens in uitvoeringsorganisatie-eigen bronsystemen zullen worden

vastgelegd. Een informatieplatform zal deze (financiële) gegevens uit de bronsystemen moeten

kunnen ontsluiten c.q. kunnen ontvangen. Op termijn kan het uitzetten van opdrachten en

budgetten naar een gemeentelijke backoffice/ externe tweedelijns conform een

producten/dienstencatalogus. Dat is per 1-1-2015 wellicht niet haalbaar, doch later misschien wel.

32

3 Uitgangspunten PvE

3.1 Varianten en fasering

Gemeenten kunnen verschillende keuzes maken voor het niveau/de rol van de regiefunctie en

zullen vanaf 2014 hier invulling aan geven (in productie januari 2015?) Feitelijk gebruik en

inrichting van de informatievoorziening kan nu en in de toekomst per gemeente significant

verschillen. Een en ander is v.w.b. de prioritering, timing en fasering ook afhankelijk van het

zorgakkoord en andere landelijke beslissingen. Maar zelfs als het niet ondenkbaar is dat bepaalde

domeinen of taken uiteindelijk niet overgaan naar gemeentes, zal brede regie nodig zijn.

Individuele gemeenten kunnen onder meer verschillende keuzes maken over de vorm van de

ondersteuning aan de burger en de mate van uitbesteding aan / controle van

uitvoeringsorganisaties. Voor veel gemeenten zal concreet beleid dienaangaande nog vorm moeten

krijgen. Daarom wordt in dit PvE rekening gehouden met breder gebruik van de

informatievoorziening door andere organisaties dan gemeenten. Ook bij aanwezigheid van (of

aanschaf van) eenzelfde groep applicaties zal nog de feitelijke implementatie per gemeente kunnen

verschillen.

Idealiter wordt zoveel mogelijk de configuratie van het systeem / de systemen op basis van „zero

coding‟ gedaan, z.d.d. er geen kennis van programmeren nodig is. Idealiter zou een paar uur

cursus moeten voldoen voor de functioneel beheerders. Daarbij zouden sjablonen en

configuratiebestanden idealiter ook gedeeld kunnen worden en daarna aangepast door andere

gemeenten.

Tevens gaan we uit van een gefaseerde invoering van de informatievoorziening die de regisseur als

professional zoveel mogelijk ondersteunt in alle facetten van zijn regierol. Bij aanvang kan een

eenvoudig systeem overzicht bieden aan betrokkenen, nog zonder de meeste zware koppelingen

(wel: GeVS en VIR), beslissingsondersteuning, etc. De regie op de ondersteuning vindt eerst

primair handmatig plaats, automatisering van bepaalde taken kan later. We gaan initieel hierbij

dus uit van de taakvolwassenheid van de gebruikers – en van bestaande systemen los van de 3D-

Suite. Het groeipad v.w.b. de informatievoorziening zit hem dan in het modulair toevoegen van

verder gespecialiseerde functionaliteit, zoals specifieke modules, koppelingen met andere systemen

zoals het koppelpunt GeVS, etc.

Op korte termijn is het belangrijkste: de realisatie van 1 integraal klantbeeld en 1 plan. Bewaking

van de ondersteuning per burger/gezin gebeurt ten minste op hoofdlijnen. Hierbij is dan het

uitgangspunt dat individuele zorgprofessionals eigen (backoffice) systemen gebruiken. En dat ook

rapportages (uren, geld) wellicht nog elders worden verzorgd. Gemeenten krijgen forse budgetten

te beheren in het sociale domein. Om dit beheersbaar te houden zal er goede

verantwoordingsinformatie beschikbaar moeten zijn: horizontaal richting gemeenteraad en

samenleving en verticaal richting het Rijk. Deze ontwikkeling moet meegenomen worden in de

informatievoorziening. Op langere termijn zal de scope zoals die ondersteund zou moeten door de

informatievoorziening derhalve breder zijn. Dit betreft – naast „verdieping‟ van de eerdergenoemde

functionaliteiten – vooral ook ondersteuning voor secundaire functies. Financiële verantwoording

zal worden gevraagd en gegeven.

Fasering kan per gemeente verschillen. De ene gemeente wil bijvoorbeeld een uitgebreid

Burgerportaal „nu‟ en zal de burger zelf nauw betrokken zijn bij de mate waarin de gegevens

worden gedeeld met uitvoeringsorganisaties, in een andere gemeente heeft dit minder prioriteit

33

omdat er minder zelfregie wordt verwacht en / of er meer sprake is van

dwang. En waar de ene gemeente veel taken zoveel mogelijk per bijv. wijk zal uitbesteden, zal de

andere dit zelf doen of per taak uitbesteden zodat de vorm en detaillering van financiële

verantwoording significant kan verschillen. De mogelijkheden en wensen v.w.b. koppelingen zullen

ook verschillen per gemeente, zowel vanwege de beschikbaarheid van koppelvlakken als vanwege

functionele behoeften.

Bepaalde delen van de eisen en wensen zullen dus aan- of uit kunnen worden gezet voor een

individuele gemeente (of groep gemeenten).

Standaardfunctionaliteit

Daarnaast is het denkbaar dat niet alle functionaliteit mogelijk (en noodzakelijk!) is tijdens de

selectiefase van een pakket. Uitgangspunt is vooralsnog dat beantwoording van de eisen en

wensen plaatsvindt o.b.v. de functionaliteiten van de 3D-suite die direct, als

standaardfunctionaliteit („off-the-shelf‟), beschikbaar zijn en als zodanig ook in een Proof of

Concept (PoC) verifieerbaar zijn. Uitzondering hierop zijn de koppelingen; wanneer één of meer

koppelingen (nog) niet als „standaardsoftware‟ worden aangeboden, worden deze als zogeheten

generiek maatwerk (vgl. „nog niet ontwikkelde standaardfunctionaliteit‟) beschouwd.

3.2 Plusfunctionaliteiten

Het pallet aan mogelijke functionaliteiten t.b.v. ondersteuning van de gemeentelijke regievoerders

en van de uitvoerders van ondersteuning is breed. Op korte of middellange termijn zullen niet alle

functionaliteiten in een suite mogelijk zijn. Daarom wordt rekening gehouden met op korte en

middellange termijn ontbrekende functionaliteiten. Ook kunnen bepaalde, op het moment van de

aanbesteding nog niet (volledig) bekende specificaties later worden vervolmaakt als onderhoud van

de 3D-suite. Dit geldt bijvoorbeeld voor nog onbekende wetswijzigingen die gespecialiseerde

functionaliteit vereisen.

Al naar gelang het moment waarop de (eventuele) aanbesteding voor een specifieke gemeente of

groep gemeenten plaatsvindt, kan de inschatting daarom zijn dat het uitgangspunt van

standaardfunctionaliteit („off-the-shelf‟) nog niet (volledig) van toepassing is. In dat geval moet,

wanneer het bestek (aanbestedingsdocument incl. gedetailleerde opdrachtbeschrijving, procedurele

/ juridische aspecten, PvE, etc.) voor de aanbesteding wordt gemaakt, het PvE dienovereenkomstig

worden aangepast. In dit PvE is vooralsnog echter uitgegaan van beantwoording o.b.v.

standaardfunctionaliteit die wordt ingericht.

Wanneer later aanvullende functionaliteiten nodig zijn die nu nog niet „out of the box‟ leverbaar

zijn, kan de gemeente er voor kiezen dit te definiëren als plusfunctionaliteit. Plusfunctionaliteiten

zijn functionaliteit van de 3D-suite welke niet direct als standaardfunctionaliteit (dus niet out-of-

the-box) beschikbaar hoeven te zijn maar wel uiterlijk vanaf een bepaald moment na de acceptatie

(zo is een „plateauplanning‟ mogelijk: bij Acceptatie X, een jaar later X+Y, twee jaar later X+Y+Z).

Van belang is dan wel dat de gekozen leverancier (Contractant) ook daadwerkelijk levert. Als een

plusfunctionaliteit niet uiterlijk op dat moment als standaardfunctionaliteit beschikbaar is, wordt de

Contractant een boete opgelegd in de vorm van een korting op [[#afhankelijk van prijsmodellen

etc.#]]. Deze korting komt te vervallen vanaf het eerstvolgende jaar na het jaar waarin deze

plusfunctionaliteit als standaardfunctionaliteit beschikbaar komt.

34

Plusfunctionaliteit 1

[##Als en waar een gemeente dit wil: voorstel van functionaliteit, implementatie, timing én van

boetes bij niet nakomen #]

[Plusfunctionaliteit 2]

3.3 Opties

Opties zijn functionaliteiten waarvan het onzeker is of - en zo ja wanneer – Gemeente deze zal

afnemen. Daarom behoudt Gemeente zich het recht voor om één of meer van deze opties op enig

moment af te nemen van de Contractant (zij is daartoe echter niet verplicht). In dat geval wordt

gebruikgemaakt van een nadere offerteaanvraag (zie ###). Het betreft onderstaande

functionaliteiten.

Als een Inschrijver in zijn Offerte één of meer opties als standaardfunctionaliteit (out-of-the-box,

dus als onderdeel van (de prijsstelling van) de 3D-Suite en verifieerbaar in de PoC) aanbiedt, zal

deze daar een hogere beoordeling voor krijgen in termen van kwaliteitsscore

([beoordelingsmethoden niet opgenomen in dit PvE, dienen wel in een bestek te zijn opgenomen])

dan een Inschrijver waarbij dat niet het geval is. Ongeacht of een optie als standaardfunctionaliteit

(out-of-the-box, dus verifieerbaar in de PoC) of eventueel op een later moment (na een nadere

offerteaanvraag van Gemeente) wordt geleverd, committeert de Inschrijver zich eraan om de optie

voor Gemeente in de 3D-Suite op te nemen (vgl. Onderhoud, zie par. 10.4) zodat e.e.a. tevens

blijvend ondersteund wordt in alle volgende Nieuwe en Verbeterde Versies.

Indien een Inschrijver één of meer opties niet als standaardfunctionaliteit (out-of-the-box) levert,

vindt er t.z.t. bij de oplevering een acceptatietest plaats om te bepalen of de optie voldoet aan de

betreffende specificaties van de nadere offerte(aanvraag). Indien een Inschrijver één of meer

opties als standaardfunctionaliteit (dus out-of-the-box) levert, vindt acceptatie plaats bij de

Acceptatie. De implementatie van een optie is onderdeel van de Initiële Implementatie (na

definitieve gunning van de opdracht) resp. Vervolgimplementatie (later bij afname van de optie, zie

###) indien deze als standaardfunctionaliteit (out-of-the-box) wordt geleverd en onderdeel van de

Ondersteuning (zie ###) als deze later geleverd wordt.

[Optie 1]

Het is denkbaar dat de gemeente de functionaliteit als plug-in op een bestaand zaaksysteem zou

willen uitvragen.

[Optie 2]

3.4 Overige uitgangspunten

Webcontent

Voor wat betreft webcontent is als uitgangspunt gekozen voor een gekoppeld (3P) CMS. Een „eigen‟

(1P) webcontentmanagementsysteem van de 3D-suite t.b.v. redactie en publicatie van informatie

t.b.v. de burger wordt echter niet uitgesloten. Wel is getracht om, op plaatsten waar dit

onderscheid relevant is, in de vraagstelling een markering aan te brengen door middel van rechte

haken ([ en ]).

Wanneer het bestek (het aanbestedingsdocument incl. een gedetailleerde opdrachtbeschrijving,

procedurele / juridische aspecten, PvE, etc.) t.b.v. van een daadwerkelijke aanbesteding voor een

35

specifieke gemeente of groep van gemeenten wordt opgesteld, dient het

PvE dus eventueel aangepast te worden aan de specifieke voorkeur dienaangaande.

Documentopslag en documentgeneratie

Voor wat betreft documentopslag is als uitgangspunt gekozen voor een gekoppeld (3P)

zaaksysteem / DMS voor langetermijnopslag en archivering. Vanwege de zware

privacygevoeligheid verwachten we echter dat kortetermijnopslag en –ontsluiting binnen de 3D-

Suite plaatsvindt als een koppeling niet de juiste mate van beveiliging kan garanderen. Een „eigen‟

(1P) documentopslagfaciliteit (vgl. „DMS light‟) van de 3D-suite wordt dus niet uitgesloten. Wel is

getracht om, op plaatsten waar dit onderscheid relevant is, in de vraagstelling een markering aan

te brengen middels rechte haken ([ en ]).

Beveiliging, protocollering en auditing/logging mag niet „onderlangs‟ worden omzeilt (wanneer

mensen ten onrechte via het DMS toegang zouden krijgen tot vertrouwelijke documenten). Ook

v.w.b. archivering en vernietiging is van belang dat dit correct en in zowel 3D-Suite als DMS

gebeurt.

Wanneer het bestek (het aanbestedingsdocument incl. een gedetailleerde opdrachtbeschrijving,

procedurele / juridische aspecten, PvE, etc.) t.b.v. van een daadwerkelijke aanbesteding voor een

specifieke gemeente of groep van gemeenten wordt opgesteld, dient het PvE dus eventueel

aangepast te worden aan de specifieke voorkeur dienaangaande.

Hosting

Voor wat betreft het onderscheid tussen lokale installatie vs. afname van de 3D-suite op basis van

ASP / SaaS is vooralsnog besloten dat geen van beide varianten wordt uitgesloten. In het PvE

wordt primair uitgegaan van lokale installatie, of althans dat de hosting en het technisch beheer

van de 3D-suite niet „meegeleverd‟ hoeven te worden door de leverancier van de 3D-suite. Wel is

er getracht om, op die plaatsten waar dit onderscheid relevant is, in de vraagstelling een markering

aan te brengen door middel van rechte haken ([ en ]). Dit geldt echter niet voor par. 9.5

(technische architectuur); deze is primair opgesteld uitgaande van lokale installatie.

Wanneer het bestek (het aanbestedingsdocument incl. een gedetailleerde opdrachtbeschrijving,

procedurele / juridische aspecten, PvE, etc.) t.b.v. van een daadwerkelijke aanbesteding voor een

specifieke gemeente of groep van gemeenten wordt opgesteld, dient het PvE dus eventueel

aangepast te worden aan de specifieke voorkeur dienaangaande. Indien daarbij gekozen wordt

voor ASP / SaaS zijn daarbij mogelijk nog additionele aandachtspunten van toepassing die in het

onderhavige PvE in mindere mate of op andere wijze zijn onderkend, zoals m.b.t.

(randvoorwaarden rondom) beveiliging, beschikbaarheid en performance, back-up en uitwijk,

escrow, implementatie, migratie etc.

Variabelen

Ten aanzien van verschillende aspecten (zoals het aantal gebruikers, gewenste responsetijd, etc.)

is in het onderhavige PvE sprake van „variabelen‟ die op termijn - wanneer het bestek (het

aanbestedingsdocument incl. opdrachtbeschrijving, procedureel/juridische aspecten, PvE, etc.)

t.b.v. van een daadwerkelijke aanbesteding voor een specifieke gemeente of groep van gemeenten

wordt opgesteld - ingevuld dienen te worden conform de specifieke voorkeuren dienaangaande.

In het PvE is getracht om zo veel mogelijk, op die plaatsten waar sprake is van dergelijke

„variabelen‟, in de vraagstelling een markering aan te brengen door middel van rechte haken ([ en

36

]). Daarnaast zijn versienummers van standaarden en dergelijke op

soortgelijke wijze gemarkeerd, om t.z.t. het meest actuele versienummer te kunnen invullen.

Naast dergelijke „variabelen‟ zijn er mogelijk ook nog andere keuzen die, wanneer het bestek t.b.v.

van een daadwerkelijke aanbesteding wordt opgesteld, ingevuld kunnen worden al naar gelang de

specifieke voorkeuren dienaangaande en waarop in het onderhavige PvE in meer of mindere mate

reeds is „voorgesorteerd‟. Dit betreft bijvoorbeeld keuzen t.a.v. de training (zoals wel of geen train-

de-trainer), client- en serverside architectuur, implementatie en eventuele migratie, eventuele

levering van ondersteunende systeemsoftware (zoals web- en applicatieserver, DBMS, etc.),

eventuele additionele koppelingen en dergelijke.

Verder is het ook denkbaar dat sprake is van een gemeentelijke samenwerking (zoals een

gezamenlijke ambtelijke organisatie), hetgeen specifieke voorkeuren oplevert t.a.v. aspecten als

„multi-gemeente‟ en eventueel zelfs „multitenancy‟. Ook t.a.v. dergelijke aspecten zal het PvE in

dat geval, wanneer het bestek t.b.v. van een daadwerkelijke aanbesteding wordt opgesteld,

aangepast moeten worden al naar gelang de specifieke voorkeuren dienaangaande.

Los systeem of plug-in

Ten slotte is het denkbaar dat een 3D-Suite niet zelfstandig maar als plug-in op bijv. een reeds

aanwezig zaaksysteem wordt gerealiseerd. Veel van de generieke functionaliteiten zullen dan

vanzelfsprekend al aanwezig zijn, zoals de functionaliteiten m.b.t. procesbewaking, integratie en

gegevens en documenten. De focus van het gemeentespecifieke PvE/bestek kan dan liggen op de

evt. ontbrekende functionaliteiten zoals m.b.t. ongestructureerde processen en interactie met de

burger (incl. goede authenticatie en autorisatie). Tevens behoeft de samenhang tussen de

verschillende betrokken systemen en organisaties (leverancier zaaksysteem, leverancier plug-in,

gemeente) dan aandacht.

3.5 Eisen en wensen

In dit PvE wordt een onderscheid gemaakt tussen eisen (genummerd als E + volgnummer) en

wensen. Vooralsnog is ervoor gekozen om de eisen te beperken tot de minimaal noodzakelijke

„basisfunctionaliteit‟. Bij een uiteindelijke aanbesteding kan een gemeente desgewenst bepaalde

wensen tot eis maken (en vice versa). Ook kan dan een differentiatie aangebracht worden in de

weging van de wensen, welke in dit PvE vooralsnog in het midden is gelaten. Wanneer het bestek

voor een daadwerkelijke aanbesteding t.b.v. een specifieke gemeente of groep van gemeenten

wordt opgesteld, dient het PvE aangepast te worden conform de specifieke voorkeur

dienaangaande. Ten slotte dient vanzelfsprekend een beoordelingsmethodiek worden opgenomen

t.b.v. bepaling van de beste prijs/kwaliteit verhouding (over de gehele contractduur, incl.

eenmalige en jaarlijkse kosten en incl. een schatting van meerwerkkosten).

Eisen

Eisen zijn genummerd als E + een volgnummer.

Aan elke eis dient zonder voorbehoud en, voor zover die betrekking heeft op functionaliteit,

middels standaardfunctionaliteit („off-the-shelf‟, dus verifieerbaar in de PoC) voldaan te worden.

Enige uitzondering hierop zijn koppelingen; wanneer één of meer van de geëiste koppelingen

(nog) niet als standaardsoftware worden aangeboden, worden deze als zogeheten generiek

maatwerk (vgl. „nog niet ontwikkelde standaardfunctionaliteit‟) beschouwd.

37

Inschrijver dient hiertoe elke eis uitsluitend met „Ja.‟ te beantwoorden

en, indien daar bij de betreffende eis expliciet om gevraagd wordt, te voorzien van een bewijs.

Wanneer Inschrijver zich niet aldus expliciet akkoord verklaart met een eis, wordt dit als voor-

behoud opgevat en wordt de offerte terzijde gelegd.

Wensen

Bij wensen wordt een onderscheid gemaakt tussen open en gesloten wensen (genummerd als O

resp. S of G + een volgnummer).

Bij open wensen (O#) kan Inschrijver zo beknopt / uitgebreid beantwoorden als hij wil, mits „to

the point‟. Licht de beantwoording van alle open wensen zo mogelijk toe d.m.v. schermafbeel-

dingen.

Bij semi-gesloten wensen (S#) dient Inschrijver, tenzij expliciet anders geïnstrueerd, aan te ge-

ven in welke mate aan elk van de in de betreffende wens genoemde aspecten standaard [(„off-

the-shelf‟, dus verifieerbaar in de PoC)] wordt voldaan. Wanneer dit volledig het geval is, dient

te worden volstaan met het volgende antwoord: “Er wordt standaard („off-the-shelf‟) volledig

aan deze wens voldaan.”. Indien er niet volledig aan een wens wordt voldaan, dient Inschrijver

aan te geven aan welk(e) aspect(en) er niet standaard („off-the-shelf‟) voldaan wordt. Ook in

dat geval kan Inschrijver zo beknopt / uitgebreid antwoorden als hij wil (bij voorkeur incl.

schermafbeeldingen), mits „to the point‟.

Gesloten wensen (G#) zijn opgedeeld in verschillende deelwensen (G1.1, G1.2, …). Per deel-

wens dient met „Ja.‟ te worden geantwoord indien standaard [(„off-the-shelf‟, dus verifieerbaar

in de PoC)] wordt voldaan aan de in de betreffende wens genoemde aspecten, anders „Nee.‟.

Sommige eisen en wensen zijn voorzien van specifieke instructies en/of aandachtspunten ten

aanzien van de beantwoording. Bij zijn beantwoording dient Inschrijver rekening te houden met

dergelijke instructies en/of aandachtspunten.

3.6 Juridische en financiële eisen en wensen

In deze paragraaf worden de algemene (met name juridische en financiële) eisen opgenomen die

verband houden met de aanbesteding van de 3D-Suite. Omdat die eisen nauw verband houden

met de specifieke voorkeuren dienaangaande van de betreffende Gemeente, kan e.e.a. pas

ingevuld worden op het moment dat het daadwerkelijke bestek t.b.v. een aanbesteding voor een

specifieke gemeente of groep van gemeenten wordt opgesteld (waarbij in dat laatste geval

mogelijk nog additionele juridische en/of financiële eisen dienen te worden opgenomen). Het feit

dat deze sectie nog grotendeels leeg is gelaten, betekent overigens niet dat het onderwerp daarom

minder belangrijk zou zijn. Ook op deze onderwerpen dienen goede, veelal gemeentespecifieke,

afspraken te worden gemaakt! Onder andere betreft dit de (model)overeenkomst.

Onderstaande eis is echter zodanig generiek dat deze altijd opgenomen kan worden.

E1 Algemeen: match prijsopgave en functionaliteit

Alle geoffreerde prijzen van de aangeboden 3D-Suite zijn gebaseerd op de specificaties in dit be-

stek. Dat wil zeggen dat alle in de offerte beschreven functionaliteiten en specificaties (beant-

woording van eisen en wensen) onder het aanbod vallen en zijn inbegrepen bij de prijsopgave,

tenzij in de betreffende wens of eis expliciet sprake is van het tegendeel.

38

Indien er producten en/of dienstverlening worden / wordt aangeboden waar additionele kosten

mee gemoeid zijn, dient Inschrijver dit expliciet aan te geven. Bij het niet (volledig) specificeren

van de kosten van één of meer elementen van de aangeboden 3D-Suite impliceert Inschrijver

derhalve dat de niet gespecificeerde kosten nihil zijn.

39

4 PvE: Generieke functionaliteit

4.1 Inleiding (generieke functionaliteit)

Dit hoofdstuk 4 omvat de eisen en wensen m.b.t. de generieke functionaliteit van de 3D-suite. De

specifieke inrichting van de 3D-suite wordt bij voorkeur zoveel mogelijk door middel van

configuratie van (generieke) functionaliteit gerealiseerd, met name om de onderhoudskosten te

reduceren. In tegenstelling tot de specifieke functionaliteit zoals opgenomen in hoofdstuk 5 geldt

deze generieke functionaliteit van de 3D-suite niet uitsluitend voor het sociale domein; in theorie

zou dezelfde functionaliteit - wanneer de 3D-suite hiertoe geschikt zou zijn - geconfigureerd

kunnen worden om voor bijvoorbeeld vergunningverlening ingezet te worden.

Kenmerkend voor het 3D-domein zijn de gevraagde flexibiliteit bij bijv. de procesinrichting, de

communicatie en de autorisaties, waar ook op ad-hoc (runtime) basis inrichtingen moeten kunnen

worden aangepast (dus niet alleen in de beheerfase).

Voor wat betreft de regie is een en ander samen te vatten als: processen, gegevens en

documenten. Het document is vanuit een zaakgerichte visie beschreven, doch de gevraagde

functionaliteiten kunnen ook op basis van bijv. een case management of workflow/processysteem

worden ingericht. Ook is bijvoorbeeld een zaaksysteem is combinatie met waar nodig een

workflowsysteem denkbaar. Het gaat om de functionaliteit. Om een eenduidige –en bij gemeenten

gangbare– terminologie aan te houden is zaakgericht werken gebruikt als kapstok.

In par. 4.2 en verder zijn op basis van bovenstaande visies de wensen en eisen geformuleerd voor

de generieke functionaliteit van de 3D-Suite. Zoals in par. 3.5 beschreven wordt daarbij gebruik

gemaakt van Eisen (E#), Gesloten wensen (G#), Open wensen (O#) en Semigesloten wensen

(S#). Zoals gezegd heeft het de voorkeur (vanwege de gewenste flexibiliteit) dat de

domeinspecifieke functionaliteiten in hoofdstuk 5 zoveel mogelijk ingericht zijn op basis van de

generieke functionaliteiten uit onderhavige hoofdstuk.

4.2 Processen (regievoering en bewaking)

4.2.1 Inleiding

De belangrijkste (primaire) processen zijn die van signalering, intake tot en met nazorg (zie 2.8.1).

We zullen een dergelijk proces in dit hoofdstuk vaak aanduiden als een “zaak”. Waar termen als

“zaak” staan, kan bijv. ook ”(ondersteunings)traject” worden gelezen, of “taak”, “actie” of

“maatregel” i.p.v. deelzaak. Afhankelijk van de context kan in plaats van een deelzaak ook een

gerelateerde zaak worden gebruikt (zie ook de GEMMA ZTC 2.0), bijv. wanneer een

uitvoeringsorganisatie deze uitvoert.

Waar hier over zaken, zaakgericht werken, processen, etc. wordt gesproken, wordt benadrukt dat

hier veel verschillende trajecten (uitwerking van ondersteuningsplannen) mogelijk zijn. Dit zal

zowel per gemeente, per type ondersteuning, per groep gebruikers en óók per specifieke burger en

plan kunnen verschillen. Ook zijn ad-hoc processen of ad-hoc taken mogelijk.

Het ondersteuningsplan kan bestaan uit een mix van één of meer (deel)zaken die worden

behandeld door één of meer personen / organisaties. Zaken kunnen al dan niet met elkaar

gerelateerd zijn. Zaakprocessen hebben meestal een doorlooptijd van minimaal enkele dagen en

worden hier onderscheiden van kortlopende processen tijdens bijv. een intakeproces.

40

Bij voorkeur gebeurt de inrichting van de processen op basis van zoveel

mogelijk „zero coding‟ en o.b.v. de GEMMA Zaaktypecatalogus 2.0 8, door de leverancier en/of door

de gemeente zelf. Kenmerkend voor 3D is dat sommige inrichtingen ad-hoc mogelijk moeten zijn.

Dan is een „voorzet‟ ingericht door functioneel beheer, maar voor één specifieke zaak worden door

de regisseur of een andere medewerker runtime aanvullende deelzaken, taken (in de vorm van

extra statussen, of minder gestructureerd extra checklists, etc.) en/of autorisaties gezet.

Zaaktypeconfiguratie (zaaktypebeheer) en zaakbeheer (runtime) zijn in deze context dus nauw

verweven.

4.2.2 Registreren klantcontacten en zaken

G1 Zaakregistratie: algemeen

De 3D-Suite biedt functionaliteit m.b.t. het conform de betreffende zaaktypen registreren van za-

ken in de 3D-Suite door medewerkers zowel van de gemeente als van geautoriseerde ketenpart-

ners. Dit betreft ten minste:

G1.1

- Het o.b.v. de ingevulde gegevensregistratieschermen / -formulieren registreren van nieuwe

zaken, conform de betreffende zaaktypen, incl. het registreren van de betreffende gegevens in

de zaakattributen van de betreffende zaken.

G1.2

- Bij intake n.a.v. een signalering wordt gebruik gemaakt van „prefill‟ (d.w.z. dat wanneer ge-

bruikers de gegevensregistratie starten, alle gegevens automatisch worden overgenomen van

het signaal)

G1.3

- Het volledig geautomatiseerd opnemen van eventuele bijgevoegde documenten in het betref-

fende zaakdossier, alsmede een PDF/A- en/of XML-bestand van berichten / signalen die als

start van een zaak gelden.

S1. Registreren uitvoeringsorganisatie bij klantcontact/door te zenden intake

Bij het registreren van een klantcontact dat doorgezonden moet worden naar een uitvoeringsor-

ganisatie (informatievraag, terugbelnotitie) is vast te leggen op welke uitvoeringsorganisatie het

betrekking heeft, m.a.w. naar welke uitvoeringsorganisatie het bericht daarna doorgezonden

moet worden.

Indien het klantcontact betrekking heeft op een lopende zaak, wordt het klantcontact bij de zaak

geregistreerd. Indien het klantcontact geen betrekking heeft op een lopende zaak, dan kan de

medewerker direct en zeer eenvoudig (met 1 of 2 extra klikken) de juiste uitvoeringsorganisatie

selecteren. Daarbij wordt een nieuwe zaak gestart.

4.2.3 Zaakbeheer

G2 Zaakbeheer: werklijst

G2.1

De 3D-Suite biedt functionaliteit zodat aldus geregistreerde zaken zichtbaar zijn in een werklijst.

(Groepen) medewerkers kunnen, al naar gelang hun autorisaties, de zaken zien in hun respectie-

velijke werklijsten, inclusief ten minste:

8 www.kinggemeenten.nl/ztc/ztc-20

41

G2.2

- Zaaktypen, zaken incl. eventuele bijbehorende notities, contactmomenten en zaakrelaties

(hoofd-, deel- en gerelateerde zaken).

G2.3

- De betreffende betrokkenen, incl. relaties

G2.4

- Actuele status- en andere proces(voortgangs)informatie, waaronder ten minste actuele norm-

/streefdata en –termijnen en (resterende) doorlooptijden.

G2.5

- Actuele attendering om veranderingen in (de status en/of samenstelling van) zaken en dos-

siers kenbaar en inzichtelijk te maken middels visuele markeringen, waaronder ten minste

van:

▪ Nieuwe (hoofd-, deel- en gerelateerde) zaken, status/stappen / taken, etc.

▪ Statuswijzigingen

▪ Nieuwe informatie in zaak(dossier), zoals documenten, notities, contactmomenten, etc.

▪ (Dreigende) overschrijding van norm- / streefdata en -termijnen

▪ Notificaties n.a.v. het “afgaan” van reminders.

G3 Zaakbeheer: handelingen

De 3D-Suite biedt functionaliteit m.b.t. zaakbeheer waarmee op zaken ten minste de volgende

handelingen kunnen worden uitgevoerd:

G3.1

- Aanmaken

Het aanmaken van een nieuwe zaak, „from scratch‟ maar ook o.b.v. een signalering of melding

G3.2

- Accepteren en in behandeling nemen

Zolang zaken nog niet zijn geaccepteerd, kunnen ze door daartoe geautoriseerde gebruikers

worden geaccepteerd en in behandeling worden genomen.

G3.3

- Weigeren

Zolang zaken nog niet geaccepteerd zijn, kunnen ze door gebruikers worden geweigerd, waar-

na

ze als “uitval” worden aangemerkt en volledig geautomatiseerd naar een specifieke werklijst

voor “uitval” worden gerouteerd die inzichtelijk is voor ten minste regisseurs.

G4 Zaakbeheer: handmatig toewijzen

G4.1

De 3D-Suite biedt functionaliteit m.b.t. zaakbeheer v.w.b. handmatig toewijzen van zaken

aan bepaalde behandelaars en/of behandelgroepen (werklijsten).

G4.2

Ook na toewijzing van zaken blijven deze zichtbaar in de oorspronkelijke werklijst; hierdoor

ontstaat een virtuele hiërarchie van werklijsten zodat bijvoorbeeld coördinatoren zaken

kunnen (her)verdelen over andere (groeps- en/of persoonlijke) werklijsten, terwijl zij status

en voortgang kunnen blijven volgen.

G4.3

42

Daartoe geautoriseerde gebruikers (bijv. de regisseur) kunnen te allen tijde zaken van andere

gebruikers overnemen (“pull”, bijv. bij vakantie) of eigen zaken naar andere daartoe

geautoriseerde gebruikers doorzetten (“push”).

G4.4

Een regisseur kan op ieder moment deelzaken (ad-hoc) toevoegen en deze ad-hoc toewijzen

aan bestaande gebruikers in de 3D-Suite én nieuwe gebruikers (bijv. van een niet eerder

bekende uitvoeringsorganisatie).

4.2.4 Zaakbehandeling

G5 Zaakbehandeling: standaardstatussen

G5.1

De 3D-Suite biedt functionaliteit m.b.t. processturing t.a.v. (de behandeling van) zaken zoda-

nig dat deze door middel van een aantal opeenvolgende statussen naar een eindresultaat ge-

leid worden. Dit omvat ten minste de volgende vier statussen: 1) ontvangen, 2) geaccep-

teerd, 3) in behandeling en 4) afgehandeld.

G5.2

Bovendien biedt de 3D-Suite functionaliteit waarmee bij zaaktypen tussen de statussen “in

behandeling” en “afgehandeld” nog additionele statussen kunnen worden geconfigureerd ten-

einde de voortgang en kwaliteit van zaken te kunnen bewaken en/of een (deel)zaak bij een

ander uit te zetten.

G5.3

De standaardsamenstelling van zaaktypen (standaardstatussen, evt. documenttypen zoals in-

takeverslag, standaardtaken, checklists, etc.) is in een zaaktypencatalogus (in de zaaktype-

configuratie van het betreffende zaaktype) per zaaktype vastgelegd cf. GEMMA ZTC 2.0 en

kan door functioneel beheerders van Gemeenten volledig zelfstandig - zonder dat daarvoor

geavanceerde programmeerkennis nodig is (zero coding) - worden beheerd.

G6 Zaakbehandeling: ad-hoc behandeling en aanpassing

De 3D-Suite biedt functionaliteit voor het ad-hoc toevoegen van afwijkingen op een zaak (dus an-

ders dan het normale procesverloop zoals geconfigureerd in het betreffende zaaktype), ten min-

ste:

G5.1

- Het toevoegen van extra stappen/statussen (serieel) binnen een zaak en deelzaken (parallelle

afhandeling), zowel bij aanvang van een zaak als tijdens behandeling ervan.

G5.2

- Het ad-hoc toevoegen van betrokken gebruikers, incl. hun rol daarbij en de rechten (CRUD) op

de (deel)zaak, de hoofdzaak en het klantdossier.

G7 Zaakbehandeling: hoofd-, deel- en gerelateerde zaken

G7.1

- De 3D-Suite biedt functionaliteit dat bij zaken ten minste handmatig (door gebruikers) één of

meerdere in de zaaktypecatalogus gedefinieerde deelzaken (bijv.: „regelen uitkering„) kunnen

worden aangemaakt resp. ontstaan.

43

G7.2

- Deelzaken zijn verder precies hetzelfde als “gewone” (hoofd)zaken en nemen automatisch de

(zaak)attributen van de bijbehorende hoofdzaak over voor zover die attributen in de zaaktype-

configuratie van het zaaktype van de betreffende deelzaak voorkomen en niet anders zijn ge-

configureerd. Ieder zaaktype kan als deelzaak voorkomen.

G7.3

- Eventuele “onderliggende” (deel)zaken en “bovenliggende” (hoofd)zaken zijn zichtbaar bij het

inzien van zaken, waarbij gebruikers direct kunnen “doorklikken” naar iedere betreffende

hoofd- en/of deelzaak.

G7.4

- De regisseur van de hoofdzaak kan bepalen of behandelaars van deelzaken geautoriseerd zijn

tot alle informatie in de bijbehorende hoofdzaak (incl. de betreffende dossiers) en of de regis-

seur zelf inzicht heeft in de informatie van de deelzaken.

G7.5

- De regisseur van de hoofdzaak kan bepalen of behandelaars van deelzaken geautoriseerd zijn

tot door de regisseur te bepalen delen van de informatie in de bijbehorende hoofdzaak.

G7.6

- Bij deelzaken kan een afhankelijkheid in tijd en “en/of” combinaties worden gedefinieerd: eerst

moeten bijv. A,B, en C zijn afgerond voor Y of Z start (bijv.: eerst helpen afkicken en een uit-

kering regelen, dan pas werk of opleiding zoeken). Dit is zowel in de beheerfase (ZTC2.0) door

functioneel beheer te bepalen als bij runtime (ad-hoc) door de zaakbehandelaar/regisseur.

G7.7

- Daarnaast biedt de 3D-Suite functionaliteit dat elke zaak aan één of meer andere zaken gere-

lateerd kan worden. Eventuele relaties met andere zaken zijn zichtbaar bij het inzien van za-

ken, waarbij gebruikers direct kunnen “doorklikken” naar iedere betreffende gerelateerde zaak.

G7.8

- De 3D-Suite biedt functionaliteit dat bij een lopende zaak aanvullende statussen (bijv. een

aanvullende taak uitzetten en handmatig bewaken) kunnen worden toegevoegd door de ver-

antwoordelijke voor de betreffende zaak. Dit is zowel in de beheerfase (ZTC2.0) door functio-

neel beheer te bepalen als bij runtime (ad-hoc) door de zaakbehandelaar/regisseur.

G8 Zaakbehandeling: statusberichten

G6.1

- De 3D-Suite biedt functionaliteit dat bij elke statusovergang van een zaak volledig geautomati-

seerd een statusbericht gegenereerd kan worden ten behoeve van betrokken interne en exter-

ne medewerkers, ten minste via de webinterface en via e-mail.

G6.2

- Statusberichten bevatten ten minste de betreffende zaakidentificatie (zaaknummer), een di-

recte link (URL) en een bijbehorende toelichting en kunnen door gebruikers desgewenst nog

worden aangepast vóór het daadwerkelijk verzenden c.q. afdrukken ervan.

O1 Zaakbehandeling: processturing (beheer)

Beschrijf de functionaliteit van de 3D-Suite m.b.t. het beheren van de functionaliteit m.b.t. pro-

cessturing t.a.v. zaken. Ga daarbij ten minste in op (voor zover van toepassing):

- In welke mate en op welke wijze er per zaaktype - indien van toepassing per status(overgang)

44

en/of afhankelijk van het geselecteerde resultaattype - ingesteld kan worden:

▪ Welke statussen erbij kunnen/moeten voorkomen (en in welke volgorde)

▪ Welke soorten afhankelijkheid kunnen worden gedefinieerd, waarbij bijv. een type besluit,

aanwijzing, resultaat, of document het verder vervolg van een zaak als het ware dicteren

▪ Welke controlevragen er in de eventuele checklist bij een status of zaak worden gesteld

▪ Welke elementen verplicht „aanwezig‟ moeten zijn, zoals gegevens, documenttypen, afge-

vinkte controlevragen (checklist), zaaktypen die als deel- en/of gerelateerde zaak voorko-

men, etc.

▪ Welke werkinstructies en/of andere hulpmiddelen er beschikbaar zijn

▪ Welke (seriële) stappen / taken erbij kunnen/moeten voorkomen (en in welke volgorde),

bijv. o.b.v. checklists / velden binnen een status en o.b.v. extra statussen

▪ Welke autorisaties (rechten en rollen) er gelden, indien van toepassing per deelzaak / sta-

tus

▪ Hoe wordt bepaald wanneer naar een volgende status te gaan?

▪ Welke overige mogelijkheden voor processturing zijn beschikbaar?

- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in de

3D-Suite (zoals via configuratie van zaaktypen in een zaaktypencatalogus) én in welke mate

het ad-hoc (door de zaakbehandelaar/regisseur) kan worden gedaan.

- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-

standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen

beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus, liefst obv. ZTC2).

- Geef aan wat ad-hoc kan en in hoeverre dat eventueel voorbereid (als optie) kan worden in de

ZTC.

S2. Inzage in taakuitvoering

Het is voor elke wijk, elk gezin, elk product (een bepaalde ondersteuningsdienst) en elke zaak

vast te leggen bij welke organisatie, intern (afdeling) dan wel extern (uitvoeringsorganisatie), de

uitvoering/behandeling van het product/de zaak standaard belegd zal worden. Dit is per pro-

duct/dienst en per zaaktype als standaardorganisatieonderdeel vast te leggen in de betreffende

configuratie, te weten product-dienstenbeschrijving en zaaktypeconfiguratie. Ook is het bij aan-

maken en tijdens behandeling door de verantwoordelijke te overrulen.

Het is inzichtelijk in de gebruikersinterface wie (organisatie + afdeling + persoon) de uitvoering

verzorgt, ten minste bij de productinformatie en zaakdetails. Medewerkers in het medewerker-

sportaal hebben daarbij snel toegang (met één extra klik) tot de contactgegevens van de betref-

fende organisatie.

S3. Doorzetten van klantcontact/intake

Klantcontacten en „door te zenden intake‟ (gescande post/e-mail die ten onrechte bij de Gemeen-

te wordt afgeleverd i.p.v. direct bij de uitvoeringsorganisatie) die betrekking heeft op taken die bij

uitvoeringsorganisaties belegd zijn, kunnen door de 3D-Suite incl. e-mail-attendering worden

doorgezet naar de betreffende uitvoerende organisatie. Hierbij wordt enkel „dat‟ verstuurd, de ge-

registreerde toelichting/informatie van het klantcontact/intake, evenals de relevante digitale do-

cumenten (gescande post) zijn op te halen door in te loggen in de beveiligde 3D-Suite (of worden

via beveiligde kanalen als elektronisch bericht verstuurd).

Aangezien bij het klantcontact al de juiste uitvoeringsorganisatie is vastgelegd, is bij de 3D-Suite

bekend waar de e-mail naartoe gezonden moet worden. Het verzenden gebeurt dan ook volauto-

matisch.

45

Het doorzenden via e-mail vindt op de achtergrond plaats via een integratie met de mailserver

van de Gemeente [merk, type, versie]. Medewerkers hoeven t.b.v. het doorzetten van het klant-

contact de interface van de 3D-Suite niet te verlaten.

S4. Bewaken van klantcontact/intake

Op klantcontacten/intake die geïnitieerd zijn bij de Gemeente maar die betrekking hebben op ta-

ken die bij uitvoeringsorganisaties zijn belegd, is standaard een termijn van toepassing waarbin-

nen de taak (=gerelateerde of deelzaak) dient te worden afgerond. Bij het naderen én bij het ver-

strijken van de termijn vindt een notificatie plaats aan de regisseur. De termijn is door functioneel

beheer in het dienstenboek of zaaktypecatalogus ingesteld en door de regisseur te overrulen.

NB: Voorbeeld van gebruik van een dergelijke functie is bijvoorbeeld voor een terugbelverzoek,

maar ook om te zien of actie is ondernomen op doorgezonden intake.

O2 Registratie van klantcontact/’door te zenden intake’

Beschrijf de functionaliteit van de 3D-Suite m.b.t. de registratie van „klantcontact‟ (zoals contact-

momenten en terugbelverzoeken) t.b.v. uitvoeringsorganisaties én de registratie van het door-

zenden van intake (gescande post, e-mail met bijlagen).

Beschrijf of de registratie van dergelijk klantcontact afwijkt van registratie van klantcontact voor

intern gebruik. Geef aan hoe de betreffende uitvoeringsorganisatie bij het klantcontact geregi-

streerd wordt en hoe de termijnbewaking werkt. Ga op vergelijkbare wijze in op de registratie van

„door te zenden intake‟.

Ga tevens in op de wijze waarop door te zenden klantcontacten en intake in de 3D-Suite vastge-

legd worden.

O3 Casusoverleg en communicatie tussen medewerkers, burgers en overig

Beschrijf de functionaliteiten die de 3D-suite biedt om bij voorkeur per signalering, per burger én

per zaak een casusoverleg in te plannen en voor te bereiden en digitaal te voeren. Bij voorkeur

kan dit ten minste doordat de regisseur medewerkers van de gemeente en/of uitvoeringsorgani-

saties toegang geeft tot delen van de omgeving en uitnodigt voor het overleg.

Beschrijf tevens de mogelijkheden die de 3D-Suite biedt om anderszins te communiceren tussen

burger, regisseur, wijkteam, uitvoeringsorganisatie, etc. Denk aan ten minste beveiligde e-mail en

notitievelden, maar ook bijv. beveiligde chat en het beveiligd uitwisselen van documenten.

46

4.3 Gegevens en dossiers

4.3.1 Inleiding (gegevens)

Basisgegevens zijn de meest elementaire gegevens die voor een relatie worden bijgehouden.

Hieronder vallen naam, adres, woonplaats (NAW) en contactgegevens, zoals telefoonnummers en

e-mailadressen. Voor de structuur van deze basisgegevens is het van belang dat er zowel

gegevens van individuele burgers, van gezinnen in verschillende samenstellingen als van bedrijven

en andere organisaties worden bijgehouden. Voor organisaties - incl. gezinnen - moeten behalve

de gegevens van de persoon, ook de organisatiegegevens worden bijgehouden. Waar nodig

moeten ook historische of toekomstige gegevens (zoals adres voor of na verhuizing) worden

vastgelegd.

Organisaties kunnen verschillende adressen hebben voor post, voor de levering van goederen en

voor afspraken. Ook kunnen er bijv. verschillende factuuradressen zijn. Daarnaast kunnen grotere

organisaties uit structuren van kleinere bestaan. Bedrijven en bedrijfsonderdelen hebben

contactpersonen, soms meerdere die elk hun eigen verantwoordelijkheid hebben. Al deze gegevens

kunnen relevant zijn en het bijhouden ervan levert de basisinformatie om professioneel met de

betreffende organisatie te kunnen communiceren en handelen.

Tenslotte is er het netwerk rond een persoon en gezin dat uit zeer verschillende typen personen en

organisaties met verschillende rollen kan bestaan. Deze relaties kunnen formeel zijn, of informeel.

Formele relaties zijn bijv. leverancier van een dienst, huisarts, regisseur (casus-beheerder), of

diverse typen therapeuten. Informele relaties betreft met name het netwerk om een persoon of

gezin. Denk aan relaties binnen het gezin, een vriend, buurman, vader, moeder, pastoor, imam,

wijkagent, etc.

Deze relaties hebben impact op de opbouw en toegang9 tot een gezinsdossier (waarschijnlijk een

aantal individuen die samen een gezin vormen, echter nog uit te werken).

Webintake van gegevens omvat alle functionaliteit voor het ontwikkelen, publiceren, (doen)

invullen en verwerken van webformulieren, alsook voor het beheren daarvan. Dit betreft onder

meer formulierontwerp - zowel qua inhoud (incl. logica en intelligentie) als qua vormgeving /

opmaak - en -beheer (incl. versiebeheer en hergebruik van „veldblokken‟ als NAW). De

functionaliteit t.b.v. formulierontwerp is bij voorkeur zodanig dat de Gemeente op eenvoudige

wijze (liefst o.b.v. „what-you-see-is-what-you-get‟) zelf additionele formulieren kunnen ontwerpen,

zonder hulp van de Contractant. Webintake beperkt zich niet tot gegevensinvoer door burgers

(selfservice) doch ook gegevensinvoer door medewerkers (incl. regisseur, professional, etc.) wordt

bij voorkeur met dezelfde formulierfunctionaliteit ondersteund.

4.3.2 Gegevensbeheer en -opslag

E2 Gegevensbeheer en -opslag: basisfunctionaliteit klantdossiers

De 3D-Suite biedt functionaliteit m.b.t. gegevensbeheer en –opslag, waaronder ten minste:

- Beheer en opslag van gegevens m.b.t. burgers, gezinnen en organisaties, waarbij de betref-

fende gegevens worden beheerd door middel van en opgeslagen in de 3D-Suite (zoals als on-

9 De situatie bijvoorbeeld dat een kind verhuist van het gezin van de moeder naar het gezin van de

vader, levert vragen op ten aanzien van toegang, beheer en het bewaren van historie van de

gegevens.

47

derdeel van klantbeeld, klantdossier of zaakdossier)

- Beheer en opslag van gegevens m.b.t. zaken (inclusief documenten conform RGBZ)

- Beveiliging (zie hoofdstuk 8) m.b.t. bovenstaande, waaronder ten minste autorisaties (rechten

en rollen) en auditing / logging (incl. protocollering).

O4 Gegevensbeheer en -opslag: algemeen

Beschrijf de functionaliteit van de 3D-Suite m.b.t. gegevensbeheer en -opslag van respectievelijk:

- Gegevens m.b.t. burgers, gezinnen en organisaties (zie E2), inclusief documenten.

- Overige objectregistraties (zie O7).

- Gegevens t.a.v. zaken (zaak- en aanverwante gegevens, zie E2).

Ga daarbij ten minste in op (voor zover van toepassing):

- De precieze wijze en “locatie” waarop elk van deze gegevens in c.q. door middel van de 3D-

Suite worden beheerd en opgeslagen (v.w.b. domeinspecifieke gegevens bijvoorbeeld via kop-

peling met een 3P bronsysteem zoals een verwijsindex), incl. de mate waarin en de wijze

waarop daarbij van elk van die gegevens ook historie en relaties worden opgeslagen.

- In welke mate en op welke wijze bovenstaande middels configuratie is ingericht in de 3D-Suite

(zoals via configuratie van zaak-/objecttypen in een zaak-/objecttypencatalogus).

- In welke mate en op welke wijze functioneel beheerders van Gemeenten bovenstaande - incl.

het datamodel van de betreffende gegevens (voor zover toegestaan), zowel v.w.b. entiteiten

en attributen als relaties - volledig zelfstandig, zonder dat daarvoor geavanceerde program-

meerkennis nodig is (zero coding), in de 3D-Suite kunnen beheren na een cursus zoals be-

schreven in par. 10.2, zoals via configuratie van zaak-/objecttypen in een zaak-

/objecttypencatalogus.

Maak daarbij bovendien - voor zover van toepassing - steeds onderscheid tussen de betreffende

gegevens als objectregistratie enerzijds (met een levensduur langer dan 1 specifieke zaak) en in

de context van de uitvoering van zaken anderzijds.

S5. Delen van dossiers

Daartoe geautoriseerde medewerkers kunnen (gezins)dossiers delen met externe partijen die na

ad-hoc autorisatie webbased toegang krijgen tot enkel de aan hen toebedeelde delen van dossiers

en zaken.

O5 Beheer gegevens uitvoerende organisaties

Beschrijf de functionaliteit van de 3D-Suite met betrekking tot het beheren van (gegevens over)

uitvoeringsorganisaties door de Gemeente. Ga daarbij in op de mogelijkheid om alle relevante or-

ganisaties in de 3D-Suite vast te leggen/registreren, incl. algemene contactgegevens en gegevens

over contactpersonen.

Geef tenslotte aan in welke mate en op welke wijze dit middels configuratie door Contractant is

ingericht in de 3D-Suite en in welke mate en op welke wijze functioneel beheerders van

Gemeente e.e.a. volledig zelfstandig -zonder dat daarvoor geavanceerde programmeerkennis

nodig is (zero coding)- kunnen beheren.

NB: Licht uw beantwoording zo nodig toe met afbeeldingen, schematische weergaven, etc.

48

O6 Relatiebeheer burgers, gezinnen en overige betrokkenen

Een gezin of groep samenwonende personen kan vele vormen hebben. Beschrijf de functionaliteit

van de 3D-Suite met betrekking tot het definiëren van gegevens over burgers, gezinsstructuren,

contactpersonen en dergelijke (incl. de mate waarin relevante historische gegevens bewaard blij-

ven).

Beschrijf de mate van flexibiliteit van type en structuur van gegevens die geregistreerd kunnen

worden:

- In welke mate een functioneel beheerder (of zelfs een regisseur, voor een specifieke zaak) zelf

velden kan toevoegen, incl. veldtype (tekst, datum, getal, etc.)

- In welke mate een functioneel beheerder (of zelfs een regisseur, voor een specifieke zaak) zelf

simpele validaties kan toevoegen, zoals datum van-tot

- Is er een technische grens aan aantallen en type te registreren gegevens?

Geef tenslotte aan in welke mate en op welke wijze dit middels configuratie door Contractant is

ingericht in de 3D-Suite en in welke mate en op welke wijze functioneel beheerders van

Gemeente e.e.a. volledig zelfstandig -zonder dat daarvoor geavanceerde programmeerkennis

nodig is (zero coding)- kunnen beheren.

O7 Centrale bedrijfsregels (business rules)

Op diverse plaatsen worden bedrijfsregels gebruikt, bijvoorbeeld bij filtering (“wanneer is sprake

van een veiligheidsrisico en is direct behoefte aan aandacht van de regisseur”), bij het definiëren

van bepaalde velden (“wanneer is iemand volwassen”), bij zowel gegevensinvoer door burgers als

medewerkers, etc.

Een voorbeeld van een business rule betreft de situaties waarin wanneer een signaal wordt aan-

gemaakt als een burger in een (door gemeente bepaalde) tijd een (door gemeente bepaald) aan-

tal eenvoudige/enkelvoudige aanvragen heeft ingediend; of wanneer sprake is van veiligheidsrisi-

co‟s bij een signaal.

Geef aan in welke mate u een centraal ingerichte „business rule engine‟ of vergelijkbaar biedt, de

mate waarin de regels door de functioneel beheerder van de gemeende zijn aan te passen, en de

wijze waarop door de functioneel beheerder de regels zijn te gebruiken.

Maak waar nodig onderscheid tussen verschillende onderdelen van de delen van de 3D-Suite, zo-

als indien bedrijfsregels enkel zijn te gebruiken bij objectenregistraties, o.i.d.

O8 Overige objectregistraties

Beschrijf de functionaliteit van de 3D-Suite met betrekking tot het definiëren t.b.v. het vastleggen

van gegevens over andersoortige objecttypes zoals bijv. rolstoelen waarbij per objecttype (bijv.

rolstoel) gegevens van verschillende types worden vastgelegd (bijv. onderhoud, verwijzing naar

burger waar het is uitgeleend, etc.).

Beschrijf de mate van flexibiliteit van type en structuur van gegevens die geregistreerd kunnen

worden, de relaties die met andere objecten kunnen worden gelegd.

Geef tenslotte aan in welke mate en op welke wijze dit middels configuratie door Contractant is

ingericht in de 3D-Suite en in welke mate en op welke wijze functioneel beheerders van

Gemeente e.e.a. volledig zelfstandig -zonder dat daarvoor geavanceerde programmeerkennis

nodig is (zero coding)- kunnen beheren.

49

4.3.3 Gegevensregistratie en intake

In onderstaande sectie wordt geen onderscheid gemaakt tussen functionaliteit t.b.v. burgers en

t.b.v. medewerkers (binnen en buiten de gemeente). De functionaliteit is grotendeels gelijk, de

mate waarin een bepaalde rol bepaalde gegevens ziet en/of mag muteren verschilt. Waar sprake is

van gegevensregistratie, kan dus ook sprake zijn van zgn. webintake door burgers.

Benadrukt wordt dat de gegevensregistratie op álle momenten kan plaatsvinden, dus niet enkel bij

een eerste intakegesprek.

E3 Gegevensregistratie: basisfunctionaliteit

De 3D-Suite biedt functionaliteit m.b.t. gegevensregistratie en -bewerking, waaronder ten minste:

- Functionaliteit m.b.t. gegevensregistratie (“data entry”) middels gegevensregistratieschermen

/ -formulieren (zie o.a. G10) zodat gebruikers (medewerkers van gemeente en uitvoeringsor-

ganisaties / ketenpartners) gegevens kunnen registreren (CRUD 10, al naar gelang de autorisa-

ties) m.b.t. zaken en “objecten” in de 3D-Suite, incl. functionaliteit om dergelijke gegevensre-

gistratieschermen / formulieren te creëren en beheren, zowel qua inhoud (incl. logica en intel-

ligentie) als qua structuur / lay-out.

- Functionaliteit om gegevensregistratieformulieren (webformulieren) t.b.v. registratie aan te

bieden aan burgers en derden, incl. identificatie (v.w.b. burgers DigiD „middel‟ incl. DigiD

Machtigingen)

- Functionaliteit m.b.t. logica (ten minste single- en multifield bedrijfs-/meldingregels / valida-

ties, incl. meldingen aan burgers en medewerkers wanneer logica “overtreden” wordt) t.a.v.

gegevensregistratie, incl. functionaliteit om die logica te creëren en beheren.

- Functionaliteit m.b.t. intelligentie (d.w.z. dat gegevensregistratieschermen / -formulieren “dy-

namisch” worden aangepast o.b.v. door burgers en medewerkers ingevoerde gegevens) t.a.v.

gegevensregistratie, incl. functionaliteit om dergelijke intelligentie te creëren en beheren.

- Beveiliging dienaangaande (zie hoofdstuk 6), waaronder ten minste autorisaties (rechten en

rollen) en auditing / logging (incl. protocollering).

G9 Gegevensregistratie

G9.1

De 3D-Suite biedt functionaliteit m.b.t. gegevensregistratie (“data entry”) middels gegevens-

registratieschermen / -formulieren door medewerkers (medewerkerintake) t.b.v. zaakregi-

stratie (het registreren van zaken en bijbehorende objecten en documenten) in de 3D-Suite.

Hierbij is in een split screen een zogeheten “embedded preview” of master-detailscherm van

betrokken document(en) of signalen beschikbaar.

G9.2

Medewerkers worden hierbij ondersteund met zoekfuncties naar ten minste basisgegevens

(zoals personen en adressen) en zaaktypen en hebben bovendien de mogelijkheid om aldus

geregistreerde gegevens (het ingevulde gegevensregistratiescherm / -formulier) te printen

(o.a. ter ondertekening door burgers).

G9.3

10 CRUD: Create, Read, Update, Delete.

50

Of elementen (zoals registratie van specifieke gegevens, documenttypen en -attributen, con-

trolevragen, etc.) daarbij verplicht zijn, is op 1 plaats (in een zaaktypecatalogus, objecttype-

catalogus, of vergelijkbaar) vastgelegd en kan door functioneel beheerders van de gemeenten

volledig zelfstandig - zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero

coding) - per zaaktype worden beheerd.

G10 Gegevensregistratie: gegevensregistratieschermen / -formulieren (algemeen)

De 3D-Suite biedt functionaliteit m.b.t. gegevensregistratie (“data entry”) middels gegevensregi-

stratieschermen / -formulieren zodat gebruikers (zowel burgers als medewerkers) gegevens kun-

nen registreren in de 3D-Suite. Daarbij zijn zowel voor medewerkers als voor burgers ten minste

onderstaande functionaliteiten beschikbaar:

G10.1

Functionaliteit m.b.t. verplichte en optionele invoer / selectie bij gegevensregistratie, waarbij

het al dan niet verplicht zijn van de invoer / selectie voor gebruikers in één oogopslag inzich-

telijk is.

G10.2

Of elementen (zoals registratie van specifieke gegevens, documenttypen en -attributen, con-

trolevragen, etc.) daarbij verplicht zijn, is in de zaaktypencatalogus (in de zaaktypeconfigura-

tie van het betreffende zaaktype) vastgelegd en kan door functioneel beheerders van ge-

meente volledig zelfstandig - zonder dat daarvoor geavanceerde programmeerkennis nodig is

(zero coding) - per zaaktype voor elke status worden beheerd.

Functionaliteit m.b.t. verschillende door gemeente in te richten invoermethoden, waaronder

ten minste:

G10.3

“Vrije” tekst (alfanumeriek), radiobuttons, checkboxes, selectie van een datum(range), etc.

G10.4

Zogeheten snelkeuzelijsten om via een door gemeente in te richten dropdown- / picklist een

selectie te maken uit een (meer of minder beperkte) verzameling mogelijke gegevenswaar-

den.

G10.5

Daarbij is sprake van zogeheten auto-aanvullen (d.w.z. dat bij invoer van de eerste en alle

volgende letters automatisch naar de eerste betreffende mogelijkheid gesprongen wordt).

G10.6

Bij de selectie van een waarde uit een snelkeuzelijst wordt bovendien automatisch gecontro-

leerd of deze waarde nog valide is (d.w.z. actueel is t.o.v. de betreffende “bron”).

G10.7

Zogeheten ”master-/detailschermen”. Dat wil zeggen: één schermdeel (de “master”, bijv. ge-

zin) met een lijst / overzicht van bijvoorbeeld personen, zaken, objecten, etc. en een ander

schermdeel (het “detail”, bijv. gezinsleden) met details van het geselecteerde element uit de

“master” (zoals naam, adres, etc. van de geselecteerde persoon) welke vervolgens kunnen

worden gebruikt t.b.v. gegevensregistratie.

G10.8

Functionaliteit m.b.t. zogeheten prefill, zowel vanuit derde system zoals GBA/BRP als vanuit

de 3D-Suite zelf.

G10.9

51

Bij iedere burger, gezin, zaak, etc. zijn notities op te nemen.

G10.10

Notities zijn als vertrouwelijk te duiden.

G11 Gegevensregistratie: gegevensregistratieschermen / -formulieren (logica en intel-

ligentie)

De 3D-Suite biedt functionaliteit m.b.t. gegevensregistratie (“data entry”) door middel van gege-

vensregistratieschermen / -formulieren zodat gebruikers gegevens kunnen registreren in de 3D-

Suite. Daarbij zijn ten minste onderstaande functionaliteiten beschikbaar:

G11.1

- Functionaliteit m.b.t. logica, d.w.z. de controle van gegevensinvoer door middel van bedrijfs-

/meldingregels / validaties, waaronder ten minste:

▪ Singlefield bedrijfs-/meldingregels / validaties. Dit omvat ten minste ”maskers” (zoals gel-

dige datum, postcode, e-mailadres, BSN, etc. maar ook (alfa)numeriek, mini-/maximale

waarde, mini-/maximale lengte, etc.

G11.2

▪ Multifield bedrijfs-/meldingregels / validaties (d.w.z. dat sprake is van afhankelijkheid tus-

sen (de geregistreerde “waarden” van) twee of meer elementen op gegevensregistratie-

schermen / -formulieren).

G11.4

- Functionaliteit m.b.t. attendering aan gebruikers wanneer dergelijke logica “overtreden” wordt

- in voor gebruikers begrijpelijke taal, o.v.v. de element(en) waarop meldingen betrekking

hebben en de aard van de betreffende “overtreding(en)” - waaronder ten minste:

G11.5

▪ Attendering waarbij gebruikers niet verder kunnen tot de “overtreding” hersteld is (blokke-

rend).

G11.6

▪ Attendering waarbij gebruikers wel verder kunnen (deblokkerend; de attendering dient

slechts om aan te geven dat de geregistreerde gegevens onverwacht zijn).

G11.7

▪ Attendering waarbij gebruikers pas verder kunnen nadat zij daar expliciet voor gekozen

hebben (vereiste handeling zoals het afvinken van een checkbox, adviesaanvraag bij ex-

pert, etc.).

G11.8

Functionaliteit m.b.t. zogeheten intelligentie, d.w.z. dat gegevensregistratieschermen/-

formulieren a.h.w. “dynamisch” worden aangepast o.b.v. de geregistreerde gegevens (wizard-

functionaliteit zoals het overslaan/verbergen van veld(blokk)en, deelschermen / -formulieren,

vorige/volgende pagina, tabbladen, etc.).

G11.9

Burgers gebruiken dezelfde formulieren als medewerkers. Medewerkers kunnen dezelfde

webformulieren gebruiken bij andere kanalen (zoals telefoon, balie en post), inclusief de

mogelijkheid om DigiD-authenticatie over te kunnen slaan en te vervangen door zogeheten

„identificerend zoeken‟ (identificatie middels een aantal controlevragen zoals BSN en

geboortedatum/-plaats).

52

O9 Gegevensregistratie: gegevensregistratieschermen / -

formulieren (beheer)

Beschrijf de functionaliteit van de 3D-Suite m.b.t. het beheren van gegevensregistratieschermen /

-formulieren. Ga daarbij ten minste in op (voor zover van toepassing):

- De wijze waarop de structuur / lay-out - incl. de positionering van veld(blokk)en, “master-

/detailschermen”, etc. - en opmaak / huisstijl (zoals via stylesheets) worden gecreëerd, bij-

voorbeeld door middel van een integrated development engine (IDE) o.b.v. WYSIWYG, incl.

eventuele functionaliteit om van elk gegevensregistratiescherm / -formulier een printversie te

creëren (bijvoorbeeld voor postaanvragen).

- De wijze waarop eventuele logica en intelligentie, prefill, etc. worden aangebracht. Ga daarbij

ten minste in op (voor zover van toepassing):

▪ De wijze waarop logica, intelligentie en prefill worden gecreëerd (bijvoorbeeld via reguliere

expressies / scripting, m.b.v. wizards, etc.) en aangebracht, incl. het eventuele gebruik van

variabelen en de afhankelijkheid t.a.v. zaaktype, actuele status en/of andere condities.

▪ De mate waarin 3D-Suite-brede business rules kunnen worden gedefinieerd en beheerd

▪ De wijze waarop de meldingen bij het overtreden van logica vastgelegd worden, incl. het

bijbehorende onderscheid tussen de betreffende meldingtypen (zie G11).

- De wijze waarop snelkeuzelijsten (zie G10) worden beheerd en de verschillende bronnen die

hiertoe gebruikt kunnen worden, zoals: stam-/referentietabellen in de 3D-Suite, een externe

bron (bijv. BAG, het koppelpunt GeVS, etc.), “dynamische” lijst (bijvoorbeeld o.b.v. historie),

etc.

- Centrale vastlegging van elementen zoals veld(blokk)en (bijv. NAW), snelkeuzelijsten, etc.

voor gebruik in meerdere schermen / formulieren, incl. eventuele overerving (zodat wijzigin-

gen doorwerken in alle schermen / formulieren waarin elementen voorkomen) en functionali-

teit om inzichtelijk te maken op welke schermen / formulieren centraal vastgelegde elementen

gebruikt worden.

- Meegeleverde standaardcontent (uitputtende opsomming incl. beschrijving) in de vorm van

voorgedefinieerde (deel)schermen / -formulieren, veld(blokk)en, logica, snelkeuzelijsten, etc.

- Het beheer rondom dergelijke schermen / formulieren, incl. autorisaties (rechten en rollen)

dienaangaande, versiebeheer, agendering (zodat bijvoorbeeld een nieuwe (versie van een) be-

drijfsregel vanaf een bepaalde datum actief wordt), metadata, gebruik van templates en wi-

zards, etc.

- In welke mate en op welke wijze bovenstaande middels configuratie is ingericht in de 3D-Suite

(zoals via configuratie van zaak-/objecttypen in een zaak-/objecttypencatalogus).

- In welke mate en op welke wijze functioneel beheerders van Gemeenten bovenstaande volle-

dig zelfstandig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding),

in de 3D-Suite kunnen beheren, zoals via configuratie van zaak-/objecttypen in een zaak-

/objecttypencatalogus.

Maak daarbij voor zover van toepassing (dus indien verschillend) onderscheid tussen functionali-

teit voor medewerkers van Gemeenten enerzijds en overige gebruikers anderzijds. Indien de

functionaliteit hetzelfde is en/of gerealiseerd is met dezelfde technologie (bijvoorbeeld: hetzelfde

onderdeel van de 3D-Suite), dient dit expliciet vermeld te worden.

G12 Formulierverzending

G12.1

De 3D-Suite biedt functionaliteit voor het versturen van ingevulde webformulieren naar de

3D-Suite. Dit betreft ten minste de creatie van een PDF/A- en XML-bestand van het ingevulde

53

webformulier en het volledig geautomatiseerd kunnen versturen van een ontvangstbevesti-

ging aan de aanvrager. Indien het ingevulde webformulier niet kan worden afgeleverd aan

een broker / in een werkbak, wordt het ingevulde webformulier als PDF/A- en XML-bestand

naar een specifiek e-mailadres gestuurd.

G12.2

Een ingevuld formulier kan leiden tot N zaken.

O10 Overige functionaliteiten: gegevensregistratie

Beschrijf alle eventuele functionaliteiten op het gebied van gegevensregistratie (incl.

webformulieren) voor medewerkers en/of burgers die standaard onderdeel uitmaken van de 3D-

Suite en die naar uw mening in het kader van deze paragraaf relevant zijn, mede in het licht van

het beoogde gebruik van de 3D-Suite zoals beschreven in hoofdstuk 2. Denk in dat kader

bijvoorbeeld aan:

- Het gebruik van de webintakefunctionaliteit t.b.v. vraaggeleiding / beslisbomen.

- Formulierontwerp op basis van „What You See Is What You Get‟ (WYSIWYG).

- Het hergebruiken van reeds eerder ingediende formulieren.

- Geavanceerd formulierontwerp, zonder dat daarvoor programmeerkennis nodig is.

- Geavanceerd hergebruik van (delen van) webformulieren bij formulierontwerp.

- Geavanceerde validatiemogelijkheden (zoals look-up van achterliggende databases).

Geef tenslotte aan in welke mate en op welke wijze dit middels configuratie door Contractant is

ingericht in de 3D-Suite en in welke mate en op welke wijze functioneel beheerders van Gemeente

e.e.a. volledig zelfstandig -zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero

coding)- kunnen beheren.

4.3.4 (Management)rapportages

E4 (Management)rapportage: toegankelijkheid

T.b.v. ten minste (management)rapportage en selecties met behulp van 3P-toepassingen (zoals

BI tools) zijn alle gegevens die in c.q. door middel van de 3D-Suite worden beheerd en/of opge-

slagen volledig, in samenhang met elkaar en incl. historie gestructureerd toegankelijk voor lees-

acties (incl. exports), met inachtneming van de betreffende autorisaties (rechten en rollen).

S6. (Management)rapportage: exportmogelijkheden

Daartoe geautoriseerde gebruikers kunnen het resultaat van iedere zoekopdracht exporteren als

spreadsheet (csv of Excel), als pdf, en als print.

Tevens zijn door functioneel beheer van de gemeente aan te passen gedenormaliseerde dumpta-

bellen te exporteren als Excel-bestand.

O11 (Management)rapportage: algemeen (1P/2P)

Beschrijf de “eigen” (1P/2P) functionaliteit en grafische weergavemogelijkheden van de 3D-Suite

m.b.t. tot (management)rapportage. Ga daarbij ten minste in op (voor zover van toepassing):

54

Functionaliteit m.b.t. het creëren (ad hoc) en beheren van (management)rapportages en queries.

Ga daarbij bovendien ten minste in op de mogelijkheden ten aanzien van:

- Presentatiewijze (zoals taartdiagrammen, staafdiagram, tabellen, vrij te kiezen, etc.).

- Uitvoerwijzen zoals afdrukken, opslaan, exporteren (zoals CSV, XLS, XLSX), etc.

- Selecties en groepering per regio (buurt, stad)

- Selecties en groepering per type ondersteuning / dienst

- Overige selecties en groeperingen (per behandelaar, per uitvoeringsorganisatie, etc.)

- Periodiciteit (per dag, week, maand, kwartaal, jaar, vrij te kiezen, etc.)

- Het gebruik van functies zoals sorteringen, (sub)totalen, etc.

Beschrijf tevens de mate waarin gebruikers rapportages en queries zelfstandig kunnen creëren en

beheren, incl. de daartoe benodigde kennis (van programmeer-/scripttalen, SQL, etc.).

Beschrijf tenslotte (uitputtende opsomming) alle met de 3D-Suite meegeleverde standaardrappor-

tages, incl. een korte beschrijving (bijvoorbeeld: percentage gehaalde doelen per regio). Geef

daarbij aan of het realtime- en/of offline rapportages betreft en in hoeverre functioneel beheer-

ders en gebruikers van Gemeente én bij voorkeur de gebruikers deze zelfstandig kunnen aanpas-

sen.

O12 (Management)rapportage: algemeen (3P)

Zoals beschreven in E4 is databasetoegang mogelijk. Beschrijf of en zo ja welke ondersteuning u

daarbij biedt om betekenis te geven aan de gegevens: ten minste d.m.v. het bieden van correcte

en uptodate documentatie, doch bij misschien ook aanvullende opties zoals het bieden van BI-

view/universe/package/cube of vergelijkbaar voor Cognos, Crystal Reports, Business Objects, MS

SQL Reporting, oid.

4.4 Documenten en sjablonen

4.4.1 Inleiding (documenten)

Deze paragraaf bevat wensen en eisen t.a.v. de (generieke) functionaliteiten van de 3D-suite

m.b.t. opslag en beheer van documenten. Documentcreatie (par. 4.4.3) betreft functionaliteit om

documenten en e-mails te genereren o.b.v. sjablonen, m.b.v. zogeheten „samenvoegvelden‟.

Dossiervorming betreft functionaliteiten rondom het creëren en beheren van klantdossiers

bestaande uit zowel gegevens als documenten, incl. het registreren (CRUD) van documenten in

deze dossiers.

4.4.2 Basisfunctionaliteit

E5 Documenten: basisfunctionaliteit

De 3D-Suite biedt functionaliteit m.b.t. documenten, waaronder ten minste:

- Functionaliteit om [het zij via eigen (1P) functionaliteit, hetzij via een koppeling met de reeds

aanwezige sjabloontoepassing [merk, type]] documenten en e-mails te genereren o.b.v. voor-

55

gedefinieerde sjablonen, m.b.v. tags (samenvoegvelden, bijvoorbeeld %adres%).

- Functionaliteit m.b.t. dossiervorming en -beheer (zie par. 4.5.1), waaronder ten minste het

creëren en beheren (CRUD) van digitale documenten binnen het klantdossiers [in de eigen

(1P) documentopslagfaciliteit van de 3D-Suite / via een koppeling opgeslagen in het reeds

aanwezige zaaksysteem / DMS [merk, type, versie]] en documenten daarin (cf. RGBZ).

- [Functionaliteit m.b.t. archivering van zaken en bijbehorende zaakdossiers, incl. het uitoefenen

van het betreffende archiefregime daarop conform de betreffende archiefkenmerken.

/Functionaliteit om de juiste duiding te geven aan het RMA/archiefsysteem: zie par. 7.2]

- Beveiliging dienaangaande (zie hoofdstuk 6), waaronder ten minste autorisaties (rechten en

rollen) en auditing / logging (incl. protocollering) t.a.v. (handelingen m.b.t.) documenten en

zaak- en objectdossiers.

4.4.3 Documentcreatie en -opslag

O13 Documentcreatie (algemeen)

Beschrijf de functionaliteit van de 3D-Suite m.b.t. het genereren van documenten en e-mails [het

zij via eigen (1P) functionaliteit, hetzij via een koppeling met een 3P sjabloontoepassing (zie

G24)] op basis van voorgedefinieerde sjablonen m.b.v. zogeheten tags (samenvoegvelden zoals

%adres%). Ga daarbij ten minste in op (voor zover van toepassing):

- Hoe het genereren van documenten / e-mails o.b.v. sjablonen geschiedt door de tags ervan te

vullen met de overeenkomstige kenmerken uit de betreffende zaak / het betreffende object

(„parameters‟ t.b.v. documentcreatie) en/of eventuele andersoortige gegevens (zoals d.m.v.

vrije tekst en/of snelkeuzelijsten), incl. de eventuele handelingen die gebruikers daartoe die-

nen uit te voeren.

- Of aldus gegenereerde documenten / e-mails eerst nog als concept getoond worden, ter con-

trole en eventuele handmatige aanpassing door gebruikers (incl. het gebruik van spellingcon-

trole).

- Of aldus gegenereerde documenten / e-mails (m.u.v. uittreksels en afschriften) volledig geau-

tomatiseerd (en zo niet: welke handelingen gebruikers daartoe moeten uitvoeren) opgenomen

worden in het betreffende zaak-/objectdossier en in welk(e) bestandsforma(a)t(en).

- De mate waarin en de wijze waarop de betreffende documentkenmerken („metadata‟) volledig

geautomatiseerd - bijv. via overerving uit de betreffende context (zaak/object) - dan wel

(deels) handmatig worden vastgelegd, incl. eventuele handelingen die gebruikers daartoe

moeten uitvoeren.

G13 Documenten toevoegen

G13.1

De 3D-Suite biedt functionaliteit waarmee gebruikers via een knop „bladeren‟ handmatig één

of meer documenten kunnen toevoegen aan een reeds bestaande zaak (dossier). Dezelfde

functionaliteit is beschikbaar middels „drag & drop‟ vanuit de boomstructuur van het bestu-

ringssysteem. Op te voeren documenten kunnen zich in beide gevallen zowel op een centrale

schijf (netwerk) als op een eventuele lokale schijf (werkstation) schijf bevinden.

G13.2

Bovendien biedt de 3D-Suite functionaliteit welke, bij het toevoegen van documenten aan een

traject- of klantdossier, eventuele relaties tussen documenten (zoals een hoofddocument met

56

één of meer bijlagen) behouden laten blijven.

G13.3

Bij het toevoegen van een document aan een traject- of klantdossier dient alle daarbij ver-

plichte metadata (zoals documenttype en documentattributen, en de naam, rol en organisatie

van de persoon die het opvoert) te worden ingevoerd. Het eventuele verplichte karakter van

metadata is gedefinieerd in de zaaktypeconfiguratie van het betreffende zaaktype.

O14 Documentcreatie (beheer)

[Beschrijf de eigen (1P) functionaliteit van de 3D-Suite m.b.t. het beheren van de functionaliteit

t.a.v. documentcreatie als bedoeld in O13, incl. beheer (CRUD) van de sjablonen. Ga daarbij ten

minste in op (voor zover van toepassing):

- De wijze waarop de inhoud van sjablonen wordt gecreëerd, incl. het koppelen van de tags met

de overeenkomstige bronnen (attributen in het datamodel van de 3D-Suite).

- De wijze waarop de structuur en huisstijl van sjablonen wordt gecreëerd - bijvoorbeeld in een

integrated development engine (IDE) o.b.v. WYSIWYG - c.q. toegepast (zoals m.b.v. styles-

heets).

- De wijze waarop sjablonen worden gekoppeld aan de functionaliteit die ze aanroept (wanneer

welk sjabloon wordt aangeroepen en met welke parameters).

- Centrale vastlegging van elementen zoals veld(blokk)en (bijv. NAW) voor gebruik in meerdere

sjablonen, incl. eventuele overerving (zodat wijzigingen doorwerken in alle sjablonen waarin

het element voorkomt).

- Het beheer rondom sjablonen, incl. autorisaties (rechten en rollen, zie hoofdstuk 8) dienaan-

gaande, versiebeheer, metadata, gebruik van templates en wizards, etc.

- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in de

3D-Suite.

- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-

standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen

beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus).

Beschrijf bovendien de eventueel meegeleverde standaardcontent: een uitputtende opsomming

van voor het 3D-domein relevante voorgedefinieerde sjablonen, incl. toelichting of er updates van

worden verstrekt, of het sjabloon kan worden gebruikt voor het genereren van zowel documenten

als e-mails, etc.]

[Beschrijf de functionaliteit van de 3D-Suite m.b.t. het beheren van de functionaliteit t.a.v. docu-

mentcreatie als bedoeld in O13, v.w.b. de „mapping‟ tussen velden in de 3D-Suite en de sjablo-

nen. Ga daarbij ten minste in op (voor zover van toepassing):

- De wijze waarop de tags met de overeenkomstige bronnen (attributen in het datamodel van de

3D-Suite, zoals burgergegevens).

- De wijze waarop sjablonen worden gekoppeld aan de functionaliteit die ze aanroept (wanneer

welk sjabloon wordt aangeroepen en met welke parameters).

- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in de

3D-Suite.

- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-

standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen

beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus).]

57

4.4.4 [Archivering]

Documenten worden opgeslagen in de documentopslag, maar de regie daarop ligt v.w.b. metadata

en archiefkenmerken volledig bij de 3D-Suite. Deze documentopslag is v.w.b. gebruik en

functioneel volledig geïntegreerd in de 3D-Suite; gebruikers ervaren geen scheiding tussen de 3D-

Suite en de documentopslag. Als gevolg van deze integratie met het zaaksysteem maken

zaakdocumenten altijd deel uit van een (klant-/zaak)dossier en worden de metadata van een

document door het zaaksysteem bepaald (goeddeels via „overerving‟ uit het zaaktype en de zaak,

deels via het documenttype).

De archiefkenmerken (zoals bewaar- en vernietigingstermijn ten behoeve van archivering) worden

door middel van configuratie in de ZTC2.0+ per zaaktype bepaald. Hiermee is archivering en

ontsluiting van elektronische dossiers, documenten en processen mogelijk ten behoeve van een

digitaal archief conform de Archiefwet en de Archiefregeling, alsook de Wet Bescherming

Persoonsgegevens en overige privacy-wetgeving.

Een zaak krijgt bij ontstaan automatisch de archiefkenmerken van het betreffende zaaktype. Nadat

een zaak is afgehandeld wordt deze, conform deze archiefkenmerken, automatisch gearchiveerd

[in het reeds bestaande zaaksysteem]. Hierbij is het archiefregime van toepassing op zaakniveau.

Dit betekent dat zowel de gestructureerde (attributen, etc.) als ongestructureerde (documenten

incl. e-mails, aantekeningen, etc.) informatie van de zaak wordt meegenomen in de archivering.

Daarnaast krijgen alle gegevens van de zaak dezelfde bewaar- en vernietigingstermijn (een enkele

uitzondering daargelaten). Zaken kunnen uiteindelijk, voor langdurige opslag, worden

overgedragen aan het statische (digitale) archief / e-depot.

O15 Archivering

Beschrijf de functionaliteit van de 3D-Suite -systeem m.b.t. het archiveren van zaken, (zaak- en

object)dossiers en documenten daarin. Ga daarbij ten minste in op (voor zover van toepassing):

- Vernietigen van signalen, meldingen

- Bepalen vernietigtermijn per zaaktype, zaak en documenttype (kladjes mogen over jaar weg;

besluiten dienen langer te worden bewaard, etc.)

- Adequate beveiliging van opslag, ontsluiting en eventuele overdracht.

- De precieze wijze en „locatie‟ waarop zaken gearchiveerd worden (d.w.z. dat de zaak en alle

bijbehorende informatie wordt „bevroren‟ en er geen mutaties meer „in‟ de zaak kunnen plaats-

vinden). Maak daarbij onderscheid tussen de verschillende typen informatie die aldus „bevro-

ren‟ worden, waaronder ten minste gegevens, documenten in het betreffende zaakdossier en

het logbestand van de zaak (wie heeft wanneer wat toegevoegd, ingezien, gewijzigd, verwij-

derd), alsmede tussen handmatige (gebruikers-) en geautomatiseerde (systeem)handelingen.

Beschrijf tenslotte of daarna nog mutaties „op‟ zaken kunnen plaatsvinden (zoals registratie

van notities).

- De wijze waarop het archiefregime (bewaar- en vernietigingstermijnen) wordt uitgeoefend

o.b.v. de betreffende archiefkenmerken en de wijze waarop deze worden afgeleid, bijvoorbeeld

volgens de principes van de GEMMA ZTC 2.0 (incl. ingangsmoment, het geselecteerde resul-

taattype en de eventuele aanwezigheid van gerelateerde, deel- en/of vervolgzaken), uit het

documenttype, etc. Beschrijf daarbij ook of alle typen informatie (gegevens, documenten, etc.)

noodzakelijk dezelfde archiefkenmerken krijgen of dat er daarin differentiatie kan plaatsvin-

den, en zo ja op welke wijze (zoals o.b.v. documenttype). Maak daarbij steeds onderscheid

tussen handmatige (gebruikers-) en geautomatiseerde (systeem)handelingen.

58

- De wijze waarop daadwerkelijke vernietiging van zaken, objecten, documenten en (klant-,

zaak- en object)dossiers plaatsvindt, incl. of en zo ja hoe daarvan registratie plaatsvindt. Maak

daarbij onderscheid tussen handmatige (gebruikers-) en geautomatiseerde (sys-

teem)handelingen.

- Autorisaties (rechten en rollen, zie hoofdstuk 8) dienaangaande, ten minste t.a.v. (handelingen

m.b.t.) archiveren en vernietigen.

- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in de

3D-Suite (zoals via configuratie van zaaktypen in een zaaktypencatalogus).

- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-

standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen

beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus).

59

4.5 Medewerkerportaal en werkbak

4.5.1 Signaleringen en contacten

S7. Signalen en meldingen

In het medewerkerportaal is een overzicht van signalen en meldingen, inclusief

- Datum en tijdstip

- Betrokken organisaties (uitvoeringsorganisatie, ketenpartner, etc.)

- Betrokkenen (medewerkers, burgers, etc.)

- Inhoudelijke informatie

- Bron (nuldelijns / eerstelijns / tweedelijns én inwoner, arts, wijkverpleging, etc.)

- Duiding van prioriteit

- Duiding vertrouwelijkheid

- Functionaliteit om een signaal om te vormen naar een melding

- Functionaliteit om een groep signalen om te vormen naar een melding

O16 Contactmomentregistratie, notulen en reminders

Beschrijf de functionaliteit van (de medewerkerportaal van) de 3D-Suite m.b.t. de registratie van

„klantcontact‟ (zoals contactmomenten en terugbelverzoeken), ongeacht het kanaal (dus voor zo-

wel inkomende als uitgaande communicatie). Maak hierbij onderscheid tussen „klantcontacten‟ als

een zelfstandige entiteit (dus onafhankelijk van een specifieke zaak) en contactregistratie bij za-

ken. Beschrijf wat er daarbij (bij voorkeur cf. RGBZ) geregistreerd kan worden, zoals:

- Betrokken organisaties (uitvoeringsorganisatie, ketenpartner, etc.)

- Betrokkenen (medewerkers, burgers, etc.)

- Inhoudelijke informatie als vrije tekst

- Kanalen (bijv. of wordt gebeld, het een e-mail betreft, of anders)

- Datum en tijdstip

- Etc.

Ga bovendien in op de mate waarin en de wijze waarop klantcontacten die een actie vereisen

kunnen worden vastgelegd, bewaakt en behandeld/afgehandeld en hoe een gebruiker een remin-

der (incl. notitie) kan zetten op een bepaalde datum of na een bepaalde termijn waarbij het „af-

gaan‟ van de reminder een notificatie veroorzaakt in de werkomgeving in de 3D-Suite.

Beschrijf daarbij het bedieningsgemak en -snelheid van de betreffende functionaliteit (zowel regi-

stratie als afhandeling), incl. de mate waarin informatie automatisch kan worden ingevuld of ge-

suggereerd (zoals o.b.v. e-mailadres, BSN, context, etc.). Geef bovendien aan of, en zo ja hoe,

een medewerker dergelijke klantcontacten kan zoeken (zoals op burger, wijk, datum, etc.) en in-

zien en of en hoe een klantcontact dat via het gemeentelijke KCC binnenkomt wordt doorgegeven

aan de 3D-Suite.

Geef tenslotte aan in welke mate en op welke wijze dit middels configuratie door Contractant is

ingericht in de 3D-Suite en in welke mate en op welke wijze functioneel beheerders van

Gemeente e.e.a. volledig zelfstandig -zonder dat daarvoor geavanceerde programmeerkennis

nodig is (zero coding)- kunnen beheren. Bijvoorbeeld door een klantcontact als mini-zaak in te

richten.

60

4.5.2 Filteren en sorteren

O17 Filteren en sorteren

Beschrijf de functionaliteiten van de 3D-Suite met betrekking tot filteren en sorteren van signale-

ringen, burgers, zaken en documenten op (combinaties van) bepaalde waarden van velden /

metadata. Denk in dat kader bijvoorbeeld aan:

- Bij signaleringen: belang, bron, beschrijving, betrokkenen, etc.

- Bij burgers: gegevens zoals naam, adres, woonplaats, wijk, leeftijd, etc., maar bijvoorbeeld

ook of de persoon of het gezin betrokken is bij bepaalde zaken.

- Bij zaken: zaakattributen (zoals zaaktype, status, betrokkenen, etc.) maar bijvoorbeeld ook

aan zaken/taken met overschreden doorlooptijd, etc.

- Bij documenten: naam, maar ook documentattributen / metadata (zoals auteur, documentty-

pe, etc.).

Geef hierbij bovendien steeds aan binnen welke context deze functionaliteit kan worden aange-

sproken en de wijze waarop het resultaat wordt gepresenteerd.

Geef aan of het mogelijk is om op alle mogelijke velden te sorteren en te filteren. Geef ten slotte

ook of en zo ja op welke wijze(n) veelgebruikte filters, groeperingen en sorteringen kunnen wor-

den opgeslagen ten behoeve van hergebruik.

4.5.3 Beslisondersteuning en vraagverheldering

O18 Zelfredzaamheidsmatrix, participatieladder, en vergelijkbare hulpmiddelen

Beschrijf de functionaliteit die de 3D-Suite biedt om een Zelfredzaamheidsmatrix,

Participatieladder11 en/of vergelijkbare beslisondersteuning te gebruiken. Geef aan of hierbij ten

minste per domein een classificering (1-5, of vergelijkbaar) en een onderbouwing is te geven via

opmerkingen en documenteren, alsook of en hoe de verbetering of verslechtering in de tijd kan

worden weergegeven.

Geef daarbij aan of in aanvulling daarop een beslisboom kan worden ingericht en gebruikt ter

bepaling van de classificering en bespreek of en hoe het is uit te breiden, bijv. door het

Onderwijs-domein toe te voegen aan de Zelfredzaamheidsmatrix.

Geef tenslotte aan of en hoe de Zelfredzaamheidsmatrix-classificeringen (of vergelijkbaar)

gevisualiseerd kunnen worden bij een klantdossier en hoe een duiding kan worden gegeven van

verslechtering van de situatie van de burger (bijv. via een signalering).

O19 Beslisbomen

Beschrijf de functionaliteit van de 3D-Suite m.b.t. ondersteuning van gebruikers middels beslis-

bomen, incl. vraagverheldering. Ga daarbij ten minste in op (voor zover van toepassing):

- De wijze waarop beslisbomen gepresenteerd worden (binnen 3D-Suite en/of daarbuiten) aan

gebruikers en hoe zij die invullen, incl. de beschikbare vraagvormen (zoals radiobuttons, drop-

down-/picklists, etc.). Beschrijf ook of de uitkomst kan leiden tot geautomatiseerde acties van

3D-Suite (zoals het starten van processen met specifieke parameters, bijv. t.b.v. bieden van

bepaalde diensten / ondersteuning bij bepaalde ketenpartners).

11 www.zelfredzaamheidmatrix.nl resp. www.participatieladder.nl

61

- De wijze waarop beslisbomen worden gecreëerd en beheerd (CRUD). Ga daarbij ten minste in

op (voor zover van toepassing):

▪ De wijze waarop beslisbomen worden gecreëerd.

▪ De wijze waarop wordt aangegeven in welke context beslisbomen worden gebruikt.

▪ Centrale vastlegging van vragen / rules t.b.v. beslisbomen, zodat wijzigingen doorwerken in

alle beslisbomen waarin deze voorkomen.

▪ Het beheer rondom beslisbomen, incl. autorisaties (rechten en rollen), versiebeheer, etc.

▪ Meegeleverde standaardcontent (uitputtende opsomming incl. een beschrijving) in de vorm

van voorgedefinieerde (vragen / rules t.b.v.) beslisbomen.

- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in 3D-

Suite (zoals via configuratie van zaaktypen in een zaaktypencatalogus).

- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-

standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen

beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus).

O20 Checklists

Beschrijf de functionaliteit van de 3D-Suite m.b.t. ondersteuning van gebruikers door middel van

checklists cf. ZTC 2.0. Ga daarbij ten minste in op (voor zover van toepassing):

- De wijze waarop checklists gepresenteerd worden binnen de 3D-Suite aan gebruikers en hoe

zij die afvinken. Beschrijf ook of de uitkomst kan leiden tot geautomatiseerde acties van de

3D-Suite (zoals het genereren van documenten met specifieke parameters).

- De wijze waarop checklists worden gecreëerd en beheerd (CRUD). Ga daarbij ten minste in op

(voor zover van toepassing):

▪ De wijze waarop checklists worden gecreëerd.

▪ De wijze waarop wordt aangegeven in welke context checklists worden gebruikt en of deze

leiden tot geautomatiseerde acties van de 3D-Suite.

▪ Centrale vastlegging van vragen t.b.v. checklists, zodat wijzigingen doorwerken in alle

checklists waarin deze voorkomen.

▪ Het beheer rondom checklists, incl. autorisaties (rechten en rollen), versiebeheer, etc.

▪ Meegeleverde standaardcontent (uitputtende opsomming incl. een beschrijving) in de vorm

van voorgedefinieerde (vragen t.b.v.) checklists.

- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in de

3D-Suite.

- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-

standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen

beheren.

O21 [Externe informatie- / kennisbronnen]

Beschrijf de functionaliteit van de 3D-Suite m.b.t. ondersteuning van gebruikers door middel van

raadpleging van en eventuele interactie met in- en externe informatie- / kennisbronnen (binnen

resp. buiten Gemeente). Ga daarbij ten minste in op (voor zover van toepassing):

- Interne kennisbronnen van Gemeente, zoals:

Het extranet ([merk, type, versie], zie de betreffende specificaties in bijlage [XX]).

De gemeentelijke PDC ([merk, type, versie], zie de betreffende specificaties in bijlage

[XX]).

Eventuele overige informatie- / kennisbronnen waarmee een standaardkoppeling wordt

62

meegeleverd (dus inbegrepen bij de prijsopgave (zie ####) en als zodanig zonder additio-

nele kosten „off-the-shelf‟ beschikbaar), incl. toelichting (merk, type, versie(s), functionali-

teit, etc.).

- Externe kennisbronnen buiten Gemeente, zoals:

Naslagwerken / handleidingen m.b.t. toepassing van Nederlands en vreemd recht.

[…]

Eventuele overige externe informatie- / kennisbronnen waarmee een standaardkoppeling

wordt meegeleverd (dus inbegrepen bij de prijsopgave (zie ##) en als zodanig zonder addi-

tionele kosten „off-the-shelf‟ beschikbaar), incl. toelichting (merk, type, versie(s), functio-

naliteit, etc.). Denk bijv. aan informatie-/kennisbronnen van het Ministerie zoals ###.

Beschrijf daarbij steeds ten minste (voor zover van toepassing):

- Op welke manier een match gemaakt wordt met de burger (ten minste per gezinslid, waarbij

wordt gezocht op BSN)

- Binnen welke context de betreffende functionaliteit kan worden gebruikt, incl. eventuele „con-

textgevoeligheid‟ (zoals: wordt er gelinkt naar de homepage van een informatie-/kennisbron

(gebruikers moeten vervolgens verder zoeken) of naar een in de betreffende context relevant

element?).

- De wijze waarop de betreffende informatie-/kennisbron gepresenteerd wordt aan gebruikers

- Of en zo ja hoe daarbij sprake is van gegevensuitwisseling (incl. welke gegevens en of gebrui-

kers daartoe nog handelingen dienen te verrichten), dan wel of het slechts een URL-koppeling

betreft.

- Of er op de betreffende kennisbron nog apart ingelogd dient te worden (indien van toepassing)

of dat er sprake is van single sign-on (SSO).

- In welke mate de koppeling kan worden onderworpen aan autorisaties (rechten en rollen), zo-

als dat informatie alleen ingezien kan worden als de ingelogde gebruiker daar autorisatie toe

heeft.

- De flexibiliteit (mate van aanpasbaarheid) van de betreffende koppeling, incl. de mate waarin

dit door middel van configuratie (paramaters) kan worden gerealiseerd. Beschrijf daarbij te-

vens in welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig

zelfstandig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding),

kunnen beheren.

NB: Met „context‟ wordt hier gedoeld op de plaatsen / momenten waarop deze functionaliteit kan

worden gebruikt, zoals in de werklijst, detailschermen, etc.

4.5.4 Dienstenboek (product- dienstencatalogus)

Diensten kunnen allerhande diensten van derden betreffen: het UWV, schuldhulp maar ook oppas-

oma‟s. Diensten worden gezamenlijk door regisseur en burger gekozen, bijvoorbeeld met een

persoonsgebonden budget in het achterhoofd.

S8. Dienstenboek

De 3D-Suite bevat een product-dienstencatalogus / kennisbank met ten minste de volgende func-

tionaliteiten:

- Weergave en beheer van beschikbare producten en diensten, incl. levensgebied, vrije tekstvel-

den, URL, betrokken uitvoeringsorganisaties, kosten per voorziening (intern, extern), overige

63

aandachtspunten

- Weergave en beheer van per product en dienst ketenpartners die de dienst kunnen leveren.

De 3D-Suite biedt functionaliteit voor het aanbieden van een overzichtsweergave van beschikbare

producten en diensten, in meerdere varianten van groepering en sortering. Beschikbare weerga-

ven zijn ten minste op alfabet, op doelgroep en op thema.

Gebruik van rechten en rollen: een regisseur mag meer zien dan een uitvoeringsorganisatie (die

bijv. géén bedragen mag zien), die weer meer kan zien dan een burger (die overige nader te

bepalen velden niet kan zien).

S9. Contentbeheer dienstenboek

De 3D-Suite biedt functionaliteit voor het creëren, beheren en publiceren van informatie over pro-

ducten en diensten, inclusief versiebeheer, metadatering, opmaak (vormgeving) en structuur (na-

vigatie) van deze content.

Als de gemeente een abonnement heeft op standaard-content kan per dienst en per blok content

daarbinnen (bijv.: prijsinformatie) een update van de feed worden gebruikt, of kan de gemeente

er voor kiezen voor dat blok juist afwijkende content zelf op te nemen en te beheren.

S10. Integrale medewerkersportaal-inzage en zoeken in externe dienstenboeken, VAQ,

FAQ

De 3D-Suite biedt standaard koppelvlakken (batch, bijv. via ETL) waarmee diensteninformatie én

de kennisbank-informatie (VAC, FAQ, anderszins) van uitvoeringsorganisaties ingelezen kan wor-

den in de 3D-Suite zodat het medewerkersportaal de beschikking heeft over alle content, zowel

intern als van uitvoeringsorganisaties, volledig in de interface van de 3D-Suite (dus zonder alt-tab

en zonder (portlet/iframe-)interfaces van externe software.

Op deze wijze is integraal zoeken in content (dienstenboeken, FAQ en VAC) mogelijk, dus zonder

de zoekvraag in meerdere zoekboxen (per uitvoeringorganisatie) opnieuw te moeten ingeven.

O22 Medewerkersportaal: inzage en zoeken in externe dienstenboeken, VAQ, FAQ

Beschrijf de functionaliteit van de (koppelvlakken van de) 3D-Suite ten behoeve van het mede-

werkersportaal in het kader van content die door uitvoeringsorganisaties aangeboden wordt.

Indien de koppelvlakken alleen content overbrengen, beschrijf de wijze waarop dit gebeurt.

Indien de koppelvlakken werken op een andere wijze, beschrijf tevens hoe dit gebeurt, bijv. met

portlets of i-frames (dus middels de webbased grafische gebruikersinterface van de externe soft-

ware) en beschrijf de voorzieningen omtrent SSO om dit goed te laten werken. Ga tevens in of en

zo ja hoe integraal zoeken tot stand wordt gebracht, dus zonder de zoekvraag in meerdere zoek-

boxen (per uitvoeringorganisatie) opnieuw te moeten ingeven.

4.5.5 Zoeken

E6 Autorisaties bij zoeken

De 3D-Suite biedt functionaliteit waarmee bij zoeken en filteren in de 3D-Suite autorisaties geres-

64

pecteerd worden. Dat wil zeggen dat hierbij uitsluitend resultaten worden gepresenteerd waarvoor

de betreffende gebruiker in de 3D-Suite is geautoriseerd.

O23 Zoeken: algemeen

Beschrijf de functionaliteit van de 3D-Suite m.b.t. zoeken. Ga daarbij ten minste in op (voor zover

van toepassing):

- Welke bronnen (uitputtende opsomming) door middel van zoekopdrachten vanuit de 3D-Suite

doorzocht worden, zoals:

▪ Welke typen gegevens in de 3D-Suite zelf.

▪ Zowel de inhoud als de documentattributen (metadata) van documenten in de documentop-

slagfaciliteit [van het DMS/zaaksysteem.][Ga daarbij ook in op ondersteund bestandsforma-

ten, incl. indexatie- en zoekmethoden (zoals “full-text”).]

▪ Interne bronnen zoals GBA,

▪ Verwijsindices zoals VIR,

▪ Gegevens die beschikbaar zijn via het koppelpunt GeVS,

▪ etc.

- Welke van de aldus benoemde bronnen door middel van zoekopdrachten vanuit de 3D-Suite in

combinatie (dus met één en dezelfde zoekopdracht) doorzocht kunnen worden, al dan niet incl.

relaties tussen resp. binnen deze bronnen (zaken i.r.t. objecten, zaken resp. objecten onder-

ling, etc.).

- De mate waarin bij zoeken rekening gehouden wordt met autorisaties (rechten en rollen), zo-

dat alleen zoekresultaten worden getoond waarvoor de betreffende gebruiker is geautoriseerd.

- Functionaliteit die ervoor zorgt dat gebruikers bij zoeken een goede gebruiksvriendelijkheid

(zoals: een melding als bij zoeken op BSN een ongeldig BSN wordt ingegeven) en performance

ervaren.

G14 Zoeken: geavanceerd

G14.1

De 3D-Suite biedt functionaliteit m.b.t. zoeken waarbij gebruikers zowel vrije (d.m.v. eigen in-

voer) als gestructureerde (d.m.v. selecties uit één of meer dropdown-/picklists) zoekopdrachten

van één of meer “velden” (tekst, categorieën, datum, waarde / bereik, etc.) kunnen “samenstel-

len” om te zoeken in de 3D-Suite. Daarbij is bovendien ten minste onderstaande functionaliteit

beschikbaar:

G14.2

- Het gebruik van zowel enkelvoudige (bijvoorbeeld “Jansstraat”) als samengestelde (bijvoor-

beeld “klachten Jansstraat”) zoektermen.

G14.3

- Het gebruik van zogeheten booleaanse operatoren (ten minste EN, OF, NIET, etc.).

G14.4

- Het gebruik van zogeheten wildcards voor één of meer karakters.

G14.5

- (On)gevoeligheid t.a.v. hoofdletters en diakrieten (z.d.d. zoeken op bijv. Dhr. Sirac en siraç

dezelfde resultaten worden gegeven).

G14.6

- Auto-aanvullen / instant zoeken zodat bij het invoeren van de eerste letter van de zoekterm de

eerste zoekresultaten al getoond worden en er, naarmate er meer letters van de zoekterm

65

worden ingevoerd, steeds minder zoekresultaten overblijven.

G14.7

- Ondersteuning van fuzzy logic (gelijkende woorden, vgl. “bedoelde u …”).

G14.8

- Ondersteuning van synoniemen (gelijkende betekenissen).

G14.9

- De mogelijkheid om met een nieuwe zoekopdracht - incl. alle betreffende functionaliteiten -

verder te zoeken in de zoekresultaten (zoekresultaten verfijnen).

G14.10

- De mogelijkheid om (zowel enkelvoudige als en samengestelde) zoekopdrachten op te slaan

als zogeheten snelzoekopdracht (t.b.v. hergebruik).

G15 Zoeken: zoekresultaten

G15.1

De 3D-Suite biedt functionaliteit zodat zoekresultaten worden gepresenteerd op basis van zo-

geheten relevance ranking.

G15.2

Wanneer er sprake is van relaties tussen zoekresultaten, dan worden deze in samenhang (ge-

groepeerd) gepresenteerd (zoals gezinsleden, eerdere zaken van dezelfde burger, etc.).

G15.3

Zoekresultaten kunnen door gebruikers middels kolommen zowel op- als aflopend worden ge-

sorteerd op ten minste alfabet, datum en relevantie, waarbij gebruikers de kolommen van de

resultatenlijst voorafgaand aan de zoekopdracht zelf kunnen bepalen (aanpassen van de

standaardsamenstelling).

G15.4

Daarbij worden zoekresultaten gepresenteerd inclusief een samenvatting rondom de zoek-

term(en) waarop is gezocht (waarbij de zoekterm(en) is/zijn gemarkeerd) en een link naar de

gevonden zaken, documenten, objecten, personen, etc.

G15.5

Gebruikers kunnen via die link vanuit de zoekresultaten doorklikken naar de gevonden zaken,

documenten, objecten, personen, etc. waarbij documenten in een eigen, geïntegreerde viewer

binnen de 3D-Suite worden getoond.

4.5.6 Kalenderfunctionaliteit

O24 Inplannen afspraken

Beschrijf de mogelijkheden die de 3D-Suite heeft voor het inplannen van een afspraak tussen

burger en medewerker en de mate van flexibiliteit daarbij, incl. het sturen van een uitnodiging

aan de burger(s).

In welke mate wordt een regisseur bijvoorbeeld ondersteund bij het inplannen van periodieke

bezoeken (controles) bij een burger – en kunnen hier ad-hoc afwijkingen op worden ingericht?

Beschrijf tevens de mate van integratie met de kalender van de medewerker ([merk, type, ver-

sie]). Maak daarbij zo nodig onderscheid tussen registratie door interne medewerkers en externen

66

zoals bij een uitvoeringsorganisatie, of de burger zelf.

O25 [Inplannen cursussen]

Beschrijf de mogelijkheden die de 3D-Suite heeft voor het inplannen van cursussen ter onder-

steuning van (groepen van) burgers. Denk daarbij aan:

- Uitnodigen van burgers en groepen burgers

- Inschrijffunctionaliteit voor de burgers

- Aanwezigheidscontrole t.b.v. facturatie

- Wachtrijen voor volgende cursussen

- Etc.

G16 Inplannen afspraken casusoverleg (al dan niet online)

G16.1

- T.b.v. casusoverleg kunnen zowel reguliere als ad-hoc afspraken worden ingepland tussen

groepen medewerkers.

G16.2

- Daarbij worden uitnodigingen verstuurd aan betrokken partijen.

G16.3

- Er is agendafunctionaliteit aanwezig om te controleren of intern betrokkenen aanwezig kunnen

zijn. Voor overige personen wordt een uitnodiging gestuurd.

G16.4

- Er kunnen vaste periodieke tijdsblokken gebruikt worden voor regulier (casus)overleg voor be-

paalde groepen gebruikers zoals een wijkteam.

G16.5

- [Daarbij is sprake van éénwegsynchronisatie van de 3D-Suite naar de agenda van betrokken

interne medewerkers ([merk, type, versie])] / [Daarbij is sprake van tweewegsynchronisatie

met de agenda van betrokken interne medewerkers ([merk, type, versie])]

O26 Gerealiseerde uren [optie]

Het is denkbaar dat op termijn ook een registratie wordt bijgehouden van gerealiseerde uren.

Geef aan in hoeverre de 3D-Suite het (achteraf na een bezoek) registreren van de hoeveelheid

bestede tijd per burger en zaak ondersteunt.

Maak daarbij zo nodig onderscheid tussen registratie door interne medewerkers en externen zoals

bij een uitvoeringsorganisatie, of de burger zelf.

67

4.5.7 Financiën en overige regie op regie

G17 Vastleggen financiële afspraken

- Per ondersteuningsplan en per deelzaak (dienst/maatregel) worden ten minste geaggregeerde

bedragen bijgehouden (budget per plan), alsook de feitelijke realisatie

- Per ondersteuningsplan en per deelzaak (dienst/maatregel) wordt een tijdplan bijgehouden,

alsook de feitelijke realisatie

- Bewaking van persoonsgebonden budgetten is mogelijk (ten minste o.b.v. handmatig bij ge-

houden invulvelden)

O27 Verantwoording

Beschrijf de mate waarin door de 3D-Suite ondersteuning wordt geboden bij de financiële en in-

houdelijke verantwoording van geleverde ondersteuning, denk daarbij aan:

- Het verloop van een zaak / ondersteuningsplan: acties x doorlooptijd x doelen x kosten &

schatting

- Naast doorlooptijd ook doelbudget / deelbudget

- Per doel en maatregel (~deelzaak): geld en tijd

- Gebruik van KPI‟s, zowel automatisch uit systeem gegenereerd als handmatig verzameld.

Denk aan normtijden, behaalde resultaten (bijv. ZRM-scores per regio), caseloads, budgetten.

- Persoonsgebonden budget per periode (ten minste o.b.v. handmatig bijgewerkte vel-

den/notities doch bij voorkeur incl. kosten cf. dienstenboek)

- Uitputting persoonsgebonden budget, incl. bijhouden van bewijzen (scans van facturen) van

door de burger gemaakte kosten

- Wijk- of afdelingsbudget per jaar en de uitputting ervan (ten minste o.b.v. handmatig bijge-

werkte velden/notities), bij voorkeur incl. geschreven uren (zie vorige paragraaf).

Geef tevens of u nu of in een volgende release ondersteuning biedt voor financiële budgettering,

regie en monitoring – inclusief langetermijnplanning en –budgettering aanvullend op bestaande

3P financiële/ERP-functionaliteit.

O28 Overige functionaliteit voor regie op regie

Beschrijf de mate waarin de 3D-Suite ondersteuning biedt voor het vastleggen en bewaken van

financiële afspraken met uitvoeringsorganisaties en burgers.

Denk daarbij aan

- Registreren inhoudelijke en financiële afspraken (gerelateerd aan een specifieke zaak / taak) in

een document vastleggen tussen regisseur en UO. Deze communicatie is daarbij vanzelfspre-

kend enkel inzichtelijk voor de gemeentelijke regisseur en managers.

- (bij voorkeur door middel van een deelzaak) een fiat vragen / krijgen via een manager, wan-

neer nader te bepalen dure of afwijkende diensten een akkoord behoeven.

- Tijdens het samenstellen van een ondersteuningsplan een offerte met calculatie opvragen[ in-

cl. eventuele mogelijkheden om gebruik te maken van veilingen].

O29 Overige functionaliteit voor regie op regie

Geef eventuele overige standaard out of the box aanwezige functionaliteiten op het gebied van

regie-op-regie, mede in het licht van het beoogd gebruik zoals beschreven in hoofdstuk 2.

Denk daarbij aan bijvoorbeeld:

68

- Bewaking van budget, deelbudget, aantallen beschikbare rolstoelen/adviesuren/ etc. incl. visu-

alisatie en monitoring daarbij.

- Offertes met calculatie opvragen t.b.v. vulling van het dienstenboek

- Overige ondersteuning van inkoop van diensten, alsook monitoring van diensten en betalen

ervan.

- Eventueel gebruik van elektronische berichten daarbij, zoals AW-berichten.

- Etc.

4.5.8 Medewerkerportaal voor gebruikers buiten de gemeente

S11. Toegang t.b.v. zaken en klantinformatie voor de uitvoeringsorganisaties

De 3D-Suite bevat een portal of vergelijkbaar die de uitvoeringsorganisaties toegang geeft tot alle

klantcontacten, lopende en afgesloten zaken van de Gemeente die aan haar organisatie zijn ge-

koppeld/toegewezen, voor zover de betreffende persoon daartoe is geautoriseerd.

In deze portal kan de uitvoeringsorganisatie ten minste lopende (deel)zaken beheren, klantcon-

tacten hieraan koppelen, de status van klantcontacten en lopende zaken verzetten en een toelich-

ting bij deze statusverandering vastleggen.

Tevens zijn nader te bepalen delen van de klantinformatie inzichtelijk voor geautoriseerde gebrui-

kers bij de uitvoeringsorganisatie.

De portal is na authenticatie via internet toegankelijk in een browser.

S12. Documenten in de portal t.b.v. de uitvoeringsorganisaties

De genoemde portal (S11) biedt tevens de mogelijkheid om documenten toe te voegen aan de

lopende zaken die aan haar organisatie zijn gekoppeld.

In deze portal kan de uitvoeringsorganisatie de status van klantcontacten en zaken verzetten en

een toelichting bij deze statusverandering vastleggen.

O30 Portalfunctionaliteiten t.b.v. uitvoeringsorganisaties

Beschrijf de functionaliteit van de 3D-Suite m.b.t. de portal t.b.v. uitvoeringsorganisaties. Geef

aan welke informatie beschikbaar is en welke acties uitgevoerd kunnen worden.

Geef tevens aan of de portal een specifieke portaalpagina voor uitvoeringsorganisaties is, of dat

deze portal in feite dezelfde interface is als voor medewerkers van de Gemeente maar dan door

middel van rollen en rechten zodanig beperkt dat alle niet relevante functionaliteiten en content is

afgeschermd.

G18 Inzicht in klantbeeld gezin / burger voor medewerkers (incl. UO’s)

G18.1

Per gezin en per burger is voor zover daartoe geautoriseerd alle in de 3D-Suite opgenomen

informatie beschikbaar binnen 1 overzichtspagina, incl. verwijzing naar eventuele derde bron-

nen.

G18.2

69

Alle signalen, meldingen, trajecten, gegevens, dossiers, documenten, afspraken, plannen en

overige bekende informatie over eerdere hulpverlening, etc. over een persoon én een gezin

zijn inzichtelijk voor daartoe geautoriseerde gebruikers.

G18.3

Alle personen zijn in relatie tot het gezin en andere relaties weer te geven, de gebruiker kan

doorklikken naar het gezin en naar de gezinsleden.

G18.4

Bij een burger en een gezin kan de gebruiker doorklikken naar trajecten, deelzaken (master-

detailschermen of vergelijkbaar).

G18.5

Bij een burger en een gezin is realtime alle via het koppelpunt GeVS beschikbare informatie

inzichtelijk voor daartoe geautoriseerde gebruikers: afhankelijk van de rechten niets, DAT, of

WAT

G18.6

Bij een kind zijn realtime alle gegevens zichtbaar die in het leerplichtsysteem bekend inzichte-

lijk voor daartoe geautoriseerde gebruikers: afhankelijk van de rechten niets, DAT, of WAT

70

4.6 Burgerportaal (zelfregie)

Een burgerportaal heeft betrekking op een afgeschermd gedeelte binnen de gemeentelijke website.

Burgers kunnen hier gepersonaliseerde informatie inzien. Dit betreft naast status,

ondersteuningsplannen en dossiers ook onder meer contactmomenten en persoonlijke gegevens.

Via het portaal kan de burger communiceren met de gemeente, naast ook e-mail / telefoon /

fysiek. Idealiter wordt de burger tijdig op de hoogte gesteld van wijzigingen, waarbij de

berichtgeving ook in de zogeheten berichtenbox binnen de „Mijn Gemeente‟ pagina kan worden

ingezien. Dit kan als een aanvulling / uitbreiding gezien worden op „Mijn Overheid‟, waarbij men

door middel van een e-mailservice geïnformeerd. Ook het gebruik van mobiele devices is relevant

i.h.k.v. persoonlijke informatievoorziening.

Daarnaast kunnen klanten via hun „Mijn Gemeente‟ pagina ook informatie verstrekken aan

Gemeente, zoals het uploaden van ontbrekende documenten bij een aanvraag, het wijzigen van

een afspraak, etc. Via een elektronisch (contact)formulier kan eenvoudig informatie gevraagd

worden als bijvoorbeeld de gemeentelijke website of kennisbank van de 3D-Suite tekortschiet of de

afhandeling van een ondersteuningstraject vragen oproept. Burgers hebben aldus de mogelijkheid

om contact te leggen met hun regisseur. Voor authenticatie van personen maakt de persoonlijke

informatievoorziening gebruik van ten minste DigiD EI en Machtigingen.

G19 Aanbod: Persoonlijke informatievoorziening

De 3D-Suite bevat persoonlijke informatievoorziening (een „Mijn ondersteuning‟-pagina) met ten

minste de volgende functionaliteiten:

G19.1

- Toegang mogelijk via DigiD Eenmalig Inloggen (ten minste zekerheidsniveau midden) en DigiD

Machtigingen.

- [Bij deze niet-sterke authenticatie is géén toegang tot informatie die als zodanig is aangeduid.]

G19.2

- Inzage in gepersonaliseerde informatie

G19.3

- Inzage in persoonlijke gegevens en lopende en zaken

G19.4

- Informatieuitwisseling met de behandelaars

G19.5

- Inzage in eigen „lopende zaken‟ en het ondersteuningsplan

G19.6

- Gebruik van webintake-formulieren en beslisbomen o.b.v. dezelfde inrichting als werknemers,

zoals beschreven in par. 4.3 en 4.5.3

G19.7

- De 3D-Suite biedt functionaliteit om burgers op een „Mijn ondersteuning‟-pagina inzage te ge-

ven in hun eigen gegevens, waaronder ten minste e-mailadres en telefoonnummers. Hierbij

wordt bovendien de mogelijkheid geboden om deze gegevens zelf aan te vullen / te wijzigen

G19.8

- De 3D-Suite biedt functionaliteit om burgers op een „Mijn ondersteuning‟-pagina inzage te ge-

ven in de gegevens en zaken van minderjarige gezinsleden

G19.9

71

- De 3D-Suite biedt functionaliteit om burgers op een „Mijn ondersteuning‟-pagina inzage te ge-

ven in de gegevens en zaken van overige gezinsleden, indien daartoe geautoriseerd door de

regisseur

O31 Autorisatie van toegang tot gegevens

Geef aan of en hoe (ten minste door dit aantoonbaar aan de regisseur door te geven) de burger

zelf de autorisatie kan inzien én bepalen wie toegang heeft tot zijn/haar gegevens.

G20 Persoonlijke berichtenbox

G20.1

De 3D-Suite biedt burgers een persoonlijke berichtenbox. Hierin komt gepersonaliseerde in-

formatie van de Gemeente of een ketenpartner niet alleen binnen, maar wordt deze ook be-

waard. Melding van nieuwe persoonlijke berichten worden via het voorkeurskanaal van de

burger verstuurd.

G20.2

De 3D-Suite stuurt tevens een e-mail of SMS (naar wens van de burger) wanneer een bericht

klaar staat of een taak dient te worden volbracht (deelzaak).

G20.3

De burger kan tevens berichten sturen naar de regisseur en naar de uitvoerder van een zaak.

O32 De burger als mede-uitvoerder

Als een burger en/of een mantelzorger ook taken uit het ondersteuningsplan moeten uitvoeren

dan heeft die voor het systeem de rol van „ondersteuner‟/ „uitvoerder‟ en als zodanig grotendeels

dezelfde functionaliteit nodig als een medewerker van een uitvoeringsorganisatie.

Beschrijf de mate waarin via het burgerportaal de burger zelf alle functionaliteiten kan gebruiken

als een medewerker, voor zover daartoe geautoriseerd door de regisseur. Geef daarbij aan in wel-

ke mate en met welke granulariteit de regisseur ad-hoc rechten kan geven om bovenstaande

functionaliteiten en gegevens in te zien dan wel te beperken indien de burger een rol speelt in het

ondersteuningsplan.

O33 Overige functionaliteiten: persoonlijke informatievoorziening

Beschrijf alle eventuele functionaliteiten op het gebied van persoonlijke informatievoorziening die

standaard onderdeel uitmaken van de 3D-Suite en die naar uw mening in het kader van deze pa-

ragraaf relevant zijn. Denk in dat kader bijvoorbeeld aan:

- Inzage van eerdere ondersteuningsplannen.

- Inzage van correspondentie en andere documenten behorende bij een zaak.

- Netwerk rond de burger bijhouden

- Correctiemogelijkheden

72

5 PvE: Specifieke inrichting

5.1 Inleiding

De context / het werkveld van het beoogde gebruik is geschetst in hoofdstuk 2. De benodigde

functionaliteit wordt grotendeels ingevuld d.m.v. generieke functies, die flexibel (=

configureerbaar) zijn. In dit hoofdstuk worden een aantal voor het 3D-domein specifieke

functionaliteiten beschreven. Ook worden situaties aangeduid, die bijzondere eisen stellen aan de

configuratie van de generieke functionaliteiten.

Deze specifieke inrichting dient met name de aanpak zoals beschreven in 2.1 met de pijlers „eigen

kracht‟ en „integraal en regie‟ te ondersteunen. Een kanttekening hierbij is dat de scope van dit PvE

met name gericht is op de ondersteuning van specifieke burgers en professionals, m.a.w.

functionaliteit op het gebied van de anonieme zelfredzaamheid (denk aan een website) laten we

hier grotendeels buiten beschouwing.

Een relevante vraag is wel in hoeverre de burger inzage heeft in zijn plan/ dossier en zelf gegevens

en informatie kan toevoegen/ beheren en evt. een rol heeft in de uitvoering van het plan. Dit is

nog niet in detail uitgewerkt. Hierbij is het van belang situaties met en zonder dwang te

onderscheiden. Bij situaties zoals risicojongeren in de jeugdzorg is dwang soms onvermijdelijk en

zal bijv. inzage door de burger beperkter zijn dan wanneer er geen sprake is van dwang. Het

systeem moet beide situaties echter volledig ondersteunen.

Bijlage 12.3 geeft een voorbeeldinrichting met een voorzet van o.a. de geregistreerde gegevens.

5.1.1 Overzicht gebruik

Het model van “één professional” (die wordt ondersteund door diverse deskundigen of mensen uit

het netwerk van de burger) kan helpen om de informatiestromen in het sociale domein in beeld te

brengen. Het model is niet bedoeld als een sluitende afbakening van de manier waarop de

dienstverlening móet plaatsvinden. De specifieke inrichting zal per gemeente sterk kunnen

verschillen. Ook zal het gebruik bij een individuele gemeente mettertijd significant kunnen gaan

schuiven, bijvoorbeeld bij gewijzigde wetgeving. Kenmerk van de decentralisaties is juist dat er

vele werk- en organisatievormen zullen ontstaan.

73

De informatiestromen kunnen schematisch als hieronder in figuur 7 worden

weergegeven (bron: Hans Versteeg / VNG).

Figuur 7 Informatiestromen 'rond de keukentafel'

Het principe van ‘1-gezin 1-plan 1-regisseur 1-dossier’

Een of meer gesprekken tussen de eerstelijns professional en de burger vinden zijn weerslag in een

plan, dat de basis is voor de vervolgdienstverlening. Dit gebeurt volgens het principe van „1-gezin

1-plan 1-regisseur 1-dossier‟, waaraan ook toegevoegd kan worden „1 regisseur, 1-budget, 1-

informatievoorziening‟.

Het plan bevat zoals eerder aangegeven de afspraken tussen de overheid en de burger en

beschrijft welke acties van de burger en zijn sociale omgeving mogen worden verwacht, en welke

voorzieningen de overheid ter ondersteuning daarvan kan organiseren. Hierbij maakt het voor het

model of de denkwijze niet uit of het gaat om een enkelvoudige te leveren voorziening

(bijvoorbeeld in het kader van de Wmo), of een meervoudige casus of multiprobleemsituatie.

Het 1-plan (ondersteuningsplan) is de start van het 1-dossier (klantdossier). Het klantdossier (of

gezinsdossier) bevat naast het plan enkele essentiële gegevens over de burger, zijn omgeving en

zijn problematiek. Daarnaast biedt het dossier aan alle betrokkenen de mogelijkheid om de voort-

gang van de uitvoering van het plan te volgen. Het ene plan is echter niet in beton maar kan later

worden bijgesteld, bijv. wanneer blijkt dat bepaalde maatregelen niet meer nodig zijn of juist meer

tijd vereisen. De opbouw van het dossier is waarschijnlijk een aantal individuen dat samen een ge-

zin vormt, echter nog nader uit te werken).

Er kan onderscheid gemaakt worden tussen een integraal klantbeeld en integraal klantdossier. Een

klantbeeld is een aggregatie van klantinformatie uit met name verschillende externe bronnen. Een

klantdossier betreft alle gegevens en documenten incl. alle zaken die binnen de 3D-suite ontstaan

of zijn opgenomen: zeg maar het zaakdossier. Het klantbeeld is vaak het startpunt van een traject

en een hulpmiddel tijdens het traject, het klantdossier en het gevolg. In beide gevallen betreft het

gevoelige en vertrouwelijke informatie die enkel inzichtelijk of wijzigbaar is door daartoe

geautoriseerde organisatie(onderdelen) en personen.

74

Ondersteunende functionaliteiten

Ondersteunend voor het klantdossier zijn de volgende functionaliteiten en gegevensuitwisselingen

van belang. Zie ook de nadere beschrijvingen in hoofdstuk 2.

Het relatieve belang van een functionaliteit kan per domein (jeugd, ondersteuning, werk &

inkomen) verschillen:

Signalering / meldingen

Het dienstverleningsproces kan starten met een vorm van signalering (zie ook par. 2.4.4)

vanuit een professional, vanuit de burger zelf (bijv. een melding op het Werkplein, of een

aanvraag bij het Wmo-loket) of vanuit de omgeving van de burger (bijvoorbeeld een mel-

ding bij het Advies- en Meldpunt Kindermishandeling, of een buurvrouw). De vorm en wijze

van signalering en melding kunnen zeer divers zijn. Van belang is dat de signalering altijd

wordt geregistreerd én opgevolgd. Een signaal – in welke vorm dan ook – zal in het alge-

meen leiden tot een gesprek tussen een professional en de betrokken burger.

Als automatisch filteren mogelijk is, dan moet de professional wel in charge zijn: individue-

le regisseurs mogen geen signalen missen. De verantwoordelijkheid voor bundelen en filte-

ren, en het al of niet er iets mee doen ligt bij hen. Naast inkomende signaleringen kan een

medewerker of kan het 3D-systeem zelf o.b.v. vooraf gestelde regels zelf (uitgaande) sig-

nalen aanmaken. Deze kunnen intern worden opgepakt, of aan ketenpartners worden

doorgegeven.

Inkijk / klantbeeld

Om het gesprek te kunnen voeren en het plan op te kunnen stellen dient de eerstelijns pro-

fessional te kunnen beschikken over een beperkt deel van de gegevens over de burger uit

de systemen van de organisaties die betrokken zijn bij de ondersteuning van de burger. Bij

die organisaties is in het algemeen veel informatie bekend over de situatie van de burger

op een bepaald leefgebied en de al geleverde dienstverlening. Door tijdens het gesprek een

beperkt „klantbeeld‟ elektronisch beschikbaar te hebben kan de professional het gesprek ef-

fectiever voeren en kunnen professional en burger sneller bepalen welk aanbod passend is.

De burger zelf moet in beginsel akkoord geven op delen van de informatie aan derden, incl.

uitvoeringsorganisaties. De vorm verschilt per gemeente: van een intentieverklaring t/m

formeel contract en een vinkje incl. DigiD t/m papieren handtekening. Doch in uitzonde-

ringsgevallen (denk aan dwang zoals bij uithuisplaatsing waar de ouder het er niet mee

eens is) kan de goedkeuring ontbreken.

NB zowel klantbeeld als klantdossier (cf. 1-plan) geven veelal géén volledig beeld van een

burger. Veel vertrouwelijke gegevens zullen in diverse „backofficesystemen‟ van de ge-

meente of uitvoeringsorganisaties zijn geregistreerd. Van veel gegevens zal in de 3D-Suite

hooguit in het klantbeeld zijn weergegeven of in klantdossier zijn geregistreerd dat de ge-

gevens bekend zijn bij een bepaalde organisatie of in een bepaald systeem, niet wat die

gegevens zijn. Er zal binnen de 3D-Suite een klantbeeld moeten zijn dat volstaat voor het

voeren van regie en voor het verlenen van de ondersteuning.

Processturing

Op basis van het plan moet de professional in zijn rol als regisseur de processen of dien-

sten bij de diverse ondersteunende organisaties in gang kunnen zetten. Overigens kan de

burger of zijn/haar zaakwaarnemer ook regisseur zijn. Die moet (tenzij dwang) akkoord

75

geven op het ondersteuningsplan. Immers moet de burger zelf de-

len van het plan uitvoeren, en moet hij het doel zelf willen bereiken.

Onderdeel van de processturing is de toeleiding naar de ondersteuning. Dit is de manier

waarop de keuze voor (een) bepaalde tweedelijns ondersteunende organisatie / zorgaan-

bieder(s) wordt bepaald. Overigens kunnen voor de ondersteuning natuurlijk ook mantel-

zorgers e.d. uit het sociale netwerk van de burger zelf ingezet worden, en zal de burger

zelf taken en verantwoordelijkheden kunnen krijgen.

De ondersteuningstoewijzing bestaat uit twee stappen. In de eerste stap is er sprake van

een vorm van inkoop, via bijvoorbeeld een contract of een convenant, waarmee de relatie

tussen de gemeente en de aanbieder wordt bekrachtigd. Dit leidt tot een register of een

sociale kaart waarin inzichtelijk is welke partijen lokaal of regionaal beschikbaar zijn voor

welke diensten. De tweede stap vindt plaats naar aanleiding van het gesprek met de bur-

ger en het ondersteuningsplan en bestaat uit het daadwerkelijk selecteren van een of meer

aanbieders. Deze stap biedt volop mogelijkheden voor ICT-innovatie, bijvoorbeeld door het

inrichten van een online marktplaats voor aanbieders, het organiseren van online veilingen

voor begeleidingstrajecten e.d.

Benadrukt wordt dat niet alleen gemeenten onderling erg kunnen verschillen, ook binnen

de gemeente zal dat het geval zijn. Het is van groot belang dat een proces geen dwangbuis

is. Niet alleen zal een functioneel beheerder van de gemeente zelf standaardprocessen

moeten kunnen aanpassen, ook zal een individuele regisseur (een gebruikersrol) voor een

specifiek ondersteuningsplan ad-hoc zelf taken moeten kunnen toevoegen. Daarnaast zal

de regisseur ook ad-hoc rollen / rechten willen kunnen zetten. Het is bijvoorbeeld denkbaar

dat een ondersteuningsdienst nodig is van een organisatie die niet eerder bekend was bin-

nen de gemeente, of dat taken ook buiten een ondersteuningsplan om worden gezet: bijv.

„ik zie N signalen in jullie wijk, kunnen jullie uitzoeken hoe dat zit?‟

ICT-ondersteuning voor de burger

De Burger zal via het Burgerportaal inzicht kunnen hebben in het plan, het klantdossier,

zijn taken, etc.

Verwijsindex en casusoverleg

Om de samenwerking en samenhang van de betrokken organisaties te kunnen organiseren

en bewaken is in een aantal gevallen een verwijsindex en een ondersteuning voor een ca-

susoverleg nodig. Een verwijsindex bevat informatie over welke ondersteu-

ners/ondersteunende instanties bij een burger of een gezin betrokken zijn: „dat‟ ipv. „wat‟.

Een casusoverlegfunctie is een functie / deelsysteem waarmee geselecteerde en geautori-

seerde professionals een beperkt deel van de inhoudelijke wát-informatie met elkaar kun-

nen uitwisselen en daarover kunnen discussiëren.

Toezicht, verantwoording en beleidsinformatie (regie op regie)

Er is informatie nodig om toezicht te kunnen houden op de kwaliteit van de uitvoering en

om verantwoording te kunnen afleggen over de geleverde prestaties. De gegevens zijn bij

voorkeur zodanig opgeslagen dat ze in geaggregeerde vorm ook op landelijk beleidsniveau

zijn te gebruiken.

76

5.1.2 Primaire en secundaire functies 3D-Suite

We maken onderscheid tussen de primaire bedrijfsfuncties en de secundaire functies. De primaire

functies zijn onderdeel van het daadwerkelijke ondersteuningsproces. De secundaire functies zijn

daar ondersteunend aan of helpen mee om de primaire processen te sturen.

Primaire functies

De primaire functies zijn gevisualiseerd in figuur 8. Deze visualisatie wekt misschien de suggestie

dat het ondersteuningsproces loopt van Aanmelding naar Evaluatie en Nazorg. Dit is een logische

volgorde, maar niet de noodzakelijk volgorde. In een daadwerkelijke casus is het goed mogelijk dat

sommige functies overgeslagen worden en anderen een aantal malen herhaald.

Figuur 8 De primaire functies

De primaire functies zijn als volgt gedefinieerd:

1. Signalen en meldingen. De aanmeldingsfunctie is erop gericht een burger met een

potentiële ondersteuningsbehoefte bekend te maken. Er zijn meestal twee partijen (rollen)

betrokken bij deze functie: de aanmelder en de ontvanger van de aanmelding. De

aanmelder kan de burger zelf zijn, maar er kan ook een signaal of melding komen van een

derde instantie of van een medeburger. Het resultaat van deze functie is de registratie van

de aanmelding en, indien van toepassing, het in kennis stellen van de aangemelde

burger(s).

Het kan zijn dat de burger zichzelf aanmeldt via een digitaal of fysiek loket, via telefoon of

post, of dat de burger door een derde, zoals politie, of familielid, wordt aangemeld. Maar

het is ook denkbaar dat een geautomatiseerd signaleringssysteem op basis van bepaalde

regels een potentiële ondersteuningsbehoefte bij een burger identificeert, bijv. op basis van

meldingen in de verwijsindex risicojongeren (VIR).

Generieke functionaliteit t.b.v. deze functie betreft onder meer ontvangst, prioritering van

bewaking van de binnengekomen signalen.

77

2. Intake. De intakefunctie is erop gericht zoveel mogelijk relevante

informatie te verzamelen om een eerste beoordeling te kunnen doen over een aanmelding.

Het betreft een of meer gesprekken met de (potentiële) burger. Hierin worden vragen

beantwoord als: Wat is er aan de hand? Welke problematiek speelt er bij burger? Is nader

onderzoek nodig? Het resultaat van deze functie is een intakeverslag. Op basis van dit

intakeverslag moet een besluit kunnen worden genomen over het al dan niet starten van

een ondersteuningstraject of dat de burger wordt doorverwezen naar een ander domein.

Het genomen (acceptatie-, verwijzings-)besluit is een tweede resultaat van deze functie.

Generieke functionaliteit t.b.v. deze functie betreft onder meer de burgerintake en

documentgeneratie.

3. Onderzoek. De onderzoeksfunctie is erop gericht om een goed en zo compleet mogelijk

beeld te krijgen van de burger, zijn of haar omgeving, de problematiek, de

voorgeschiedenis en de afgeronde en lopende ondersteuningstrajecten. Hierbij zou een

opdeling naar leefgebieden (wonen, participatie / werk, onderwijs / scholing, financiën /

schulden, gezondheid / welzijn, relaties, zorg / hulpverlening, politie / justitie) kunnen

worden gebruikt. Als onderdeel van het onderzoek kunnen verschillende informatiebronnen

worden geraadpleegd of specialisten worden ingeschakeld om informatie te verzamelen.

Het resultaat van deze functie is een klantbeeld (ook wel: assessment / onderzoeksbeeld /

diagnostisch beeld genoemd).

Dit onderzoek kan deels alvorens (voorbereiden), en deels na (vervolmaken)

intakegesprekken plaatsvinden.

4. Doelstelling. De doelstellingsfunctie is erop gericht om op basis van de verzamelde

informatie voor een of meer leefgebieden ondersteuningsdoelen op te stellen in

samenspraak met de burger. Het resultaat van deze functie is een doel (of verzameling

doelen). Deze doelen worden gebruikt binnen de planningsfunctie (zie hierna) en in het

ondersteuningsplan.

5. Maatregelselectie. De maatregel selectiefunctie is erop gericht om maatregelen,

interventies, zorgvormen en andere middelen die nodig zijn te selecteren om de gestelde

doelen te kunnen bereiken. Het resultaat van deze functie is een lijst van geselecteerde

ondersteuningsmaatregelen. De maatregelen kunnen worden voorgesteld o.b.v. een

Dienstenboek, maar ook kunnen ad-hoc maatregelen worden opgenomen (oma gaat

helpen schoonmaken, of bijv. een dienst van een niet eerder bekende organisatie).

Tussen maatregelen / deelzaken zitten afhankelijkheden. Bijv. eerst A, D, E en H. Dan B en

C. En als het weer stabiel is in het gezin F en tenslotte G. Er zijn daarbij verschillende

soorten relaties mogelijk (begin na einde, niet eindigen voor einde enz.). Die moeten in het

plan vastgelegd worden. Dit mag handmatig, doch bij voorkeur geautomatiseerd.

6. Opstellen ondersteuningsplan. Binnen de planningsfunctie wordt een

ondersteuningsplan opgesteld. In dit ondersteuningsplan worden de doelen, geselecteerde

maatregelen en aanvullende afspraken vastgelegd. Daarnaast zorgt de planningsfunctie dat

de afgesproken vormen van ondersteuning en dienstverlening in gang gezet worden.

7. Ondersteuning. De ondersteuningsfunctie omvat alle (operationele) activiteiten waarin de

burger ondersteuning ontvangt, inclusief het voeren van de regie daarop. Het resultaat van

78

deze functie is de geleverde zorg, hulp of ondersteuning, waarvan

de voortgang wordt bewaakt in de 3D-Suite. De resultaten kunnen tevens worden gebruikt

om effectiviteit en efficiency te monitoren en t.b.v. externe en interne verantwoording.

Generieke functionaliteit t.b.v. deze functie betreft onder meer bewaking van uitgezette

taken en verantwoordelijkheden.

8. Evaluatie. Elk ondersteuningstraject wordt periodiek geëvalueerd. Er wordt zowel met de

burger als binnen het ondersteuningsteam geëvalueerd. Met name in de eindevaluatie

worden de resultaten van de ondersteuning getoetst aan de doelstellingen uit het

ondersteuningsplan. Ook kunnen hierin noodzakelijke nazorgactiviteiten worden

geïdentificeerd. Al deze activiteiten behoren tot de evaluatiefunctie. Het resultaat van deze

functie is een evaluatierapport. Op basis van het evaluatierapport kan worden beslist of de

ondersteuning wordt afgesloten en of er nog nazorg of een hernieuwde intake ingezet

wordt.

9. Nazorgverlening. Soms vindt er, nadat het ondersteuningstraject formeel is afgesloten,

nog een vorm van nazorg plaats. Bijvoorbeeld dat een wijkcoach na een maand nog eens

gaat kijken hoe het met de burger gaat. Anderen zullen misschien wel iedere paar

maanden of weken worden bezocht, afhankelijk van de inschatting van de betrokken

medewerkers.

Secundaire functies

De primaire taak van de gemeente het kader van de 3D-domeinen is regie: zorgen dat de burger

geholpen wordt. Naast de regie kan de gemeente ook een rol spelen in de uitvoering, maar dit is

afhankelijk van de beleidskeuzes die elke gemeente voor zich maakt. Bijdragen van andere partijen

in het verlenen van de ondersteuning beschouwen we ook als primaire taak. Een andere

belangrijke taak van de gemeente is de (financiële) verantwoording. Dit zien we als een secundaire

taak, maar daarmee niet minder belangrijk.

Primaire functies zijn de functies waarmee de benodigde ondersteuning kan worden verleend en

regie kan worden gevoerd, secundaire functies zijn ondersteunend hieraan zoals facturering,

managementinformatie en budgetbeheersing. Ook tijdsplanning beschouwen we hier als een

secundaire functie.

De secundaire functies zijn gevisualiseerd in figuur 9.

79

Figuur 9 Secundaire bedrijfsfuncties

Naast de primaire bedrijfsfuncties onderscheiden we de volgende secundaire bedrijfsfuncties:

1. Besluitvorming. Op verschillende punten in het hulpverleningsproces moeten besluiten

worden genomen en vastgelegd, bijv. over het accepteren van een nieuwe burger, over het

stellen van een indicatie, over het verwijzen naar een andere vorm van hulpverlening of

over het afsluiten van een traject. Het nemen en vastleggen van dergelijke besluiten is

onderdeel van de besluitvormingsfunctie. Het resultaat van deze functie is een besluit.

Bijvoorbeeld kan tooling m.b.t. de Zelfredzaamheidsmatrix 12 een belangrijk hulpmiddel

zijn bij ieder van de primaire functies. Een ander deel van deze functie is de eventueel

benodigde fiattering alvorens bepaalde ondersteuningsdiensten kunnen worden afgegeven

of alvorens een door de gemeente bepaald maximumbudget wordt overschreden.

2. Trajectbeheer & Dossiervorming. Het trajectbeheer omvat het registreren, vastleggen

en ontsluiten van informatie over burgers en ondersteuningstrajecten. Dit betreft zowel

historische informatie over de geschiedenis van burgers als actuele informatie over lopende

trajecten.

Enerzijds worden binnen trajectbeheer externe gebeurtenissen geregistreerd, zoals het

behalen van een diploma, het verliezen van een woning en het beëindigen van een

(tweedelijns) zorgtraject. Anderzijds wordt informatie vastgelegd die binnen de eerstelijns

hulpverlening zelf wordt geproduceerd, zoals een aanmelding, een intakeverslag, een

evaluatieverslag en een indicatiebesluit. Met deze functie kunnen trajectbeelden worden

ontsloten (een trajectbeeld bevat een beeld van een ondersteuningstraject). Een

contactenboek (overzicht van alle contacten met de burger of een betrokkene bij een

ondersteuningstraject) maakt ook onderdeel van deze bedrijfsfunctie.

3. Monitoren. Op basis van de gebeurtenissen en gegevens die zijn vastgelegd binnen

Trajectbeheer, waaronder aanmeldingen, meldingen aanvang en einde ondersteuning en

evaluatierapporten, heeft monitoren betrekking op het controleren van de voortgang en

kwaliteit van de ondersteuningstrajecten. Het resultaat van deze functie zijn indicatoren en

kengetallen over de lopende ondersteuningstrajecten, op basis waarvan besluiten kunnen

worden genomen over het bijsturen, uitbreiden, aanpassen of beëindigen van trajecten.

12 Zie ook www.zelfredzaamheidmatrix.nl

80

4. Verantwoording. De verantwoordingsfunctie heeft betrekking op

het opstellen van rapportages over de kosten en resultaten van de verleende

ondersteuning, de ingezette ondersteuningsmiddelen en andere procesindicatoren en -

kengetallen. In tegenstelling tot monitoren betreft het hierbij altijd geaggregeerde

informatie die niet terug te herleiden is tot individuele burgers, hulpverleners of

ondersteuningstrajecten. Het resultaat van deze functie zijn de rapportages. Deze dienen

als input voor beleidsmakers om de effectiviteit van hun beleid te kunnen evalueren en zo

nodig bij te stellen.

5. Betaling & Incasso. Met de inzet van ondersteuningsmiddelen en –diensten zijn ook

kosten gemoeid. Er wordt op een zeker moment afgerekend met externe hulpverleners en

leveranciers. Op basis van de afspraken gemaakt met deze partijen vindt financiële

afwikkeling plaats. Hier wordt geregistreerd, gecontroleerd en betaald. Tegelijkertijd kan

het nodig zijn om een deel van de kosten te verhalen op de burger (eigen bijdrage). Dit is

het incasso deel van deze functie. Het resultaat van deze functie zijn betalingen en

vorderingen.

6. Inkoop en Contractbeheer. Voor de ondersteuning zullen op allerlei wijzen derden

ingezet worden, zoals hulpverleners, zorgaanbieders, coaches en leveranciers van

ondersteuningsmiddelen. Met al deze partijen worden van te voren afspraken gemaakt

over dienstverlening, verantwoording en betaling. Deze afspraken worden vastgelegd in

een contract. De functie inkoop en contractbeheer omvat alle activiteiten met betrekking

tot het opstellen, afsluiten, monitoren en beëindigen van dergelijke contracten. Het

resultaat van deze functie is een contract.

7. Beroep en Bezwaar. Tegen elk besluit t.a.v. de ondersteuning moeten burgers bezwaar

kunnen aantekenen. Daarom is er een functie nodig die de afhandeling van dergelijke

bezwaren ondersteunt.

Overzicht rollen

De gemeente zal ondersteuning moeten kunnen bieden voor verschillende typen huishoudens. Een

individu, een gezin met kinderen, maar ook bijv. diverse samenwonende volwassenen. Het gezin is

uitgangspunt, doch verschillende domeinen en eventueel gekoppelde systemen hebben hier

verschillende definities. Een gezin kan in deze context worden gezien als een flexibel te definiëren

(vader, moeder, dochter, zoon, opa, inwonende vriend, …) groep van individuen. Bij koppelen met

ketenpartners en interne backofficesystemen dient rekening gehouden worden met verschillende

definities van een gezin of huishouden.

Een ondersteuningsplan kan een individu betreffen, maar ook kan een ondersteuningsplan taken

voor het gehele huishouden omvatten, alsook ondersteuning voor vader, moeder, oma en

kinderen. Waar in dit document wordt gesproken over een burger, kan dat ook een gehele

huishouden betreffen. Idealiter kunnen klantdossiers en ondersteuningsplannen zowel op gezins-

als persoonsniveau vorm krijgen, met relaties tussen beiden.

Waar wordt gesproken over medewerkers, kan dit zowel medewerkers van de gemeente betreffen,

van een uitvoeringsorganisatie of van een ketenpartner.

(Voorbeelden van) gebruikers van het systeem: binnen de gemeente of bij een ketenpartner:

Regievoerder / regisseur

81

Regievoerder. Veelal gemeentemedewerker, doch niet perse. De

regisseur is ook niet per se dé spin in het web, eventueel kan de functie verspreid zijn over

meer personen, bijv. een multidisciplinair team dat gezamenlijk de beslissing neemt.

(Wijk)team-manager

Aansturing en managen van team van regisseurs. Grotere gemeenten zullen wellicht de re-

gisseurs bijv. per wijk aansturen.

Professional

Feitelijke hulpverleners, onderzoekers, etc. Bijvoorbeeld een lid van een wijkteam. Veelal

géén medewerker van de gemeente maar zelfstandige of medewerker van een uitvoerings-

organisatie.

Overige uitvoerders

De burger zelf, of bijv. een familielid of mantelzorg kan tevens taken toebedeeld krijgen en

als zodanig wellicht (beperkte) toegang tot het systeem krijgen.

Aanmelder signaal

Veelal géén medewerker van de gemeente maar zelfstandige of medewerker van een uit-

voeringsorganisatie. (Een signaal kan ook komen van enige derde)

Secretariaat gemeente

Inzage in de agenda‟s, doorverbinden, etc.

Managers

Van gemeente, buiten gemeente. Dergelijke rollen kunnen nodig zijn t.b.v. fiattering. Ook

zijn ze gebruikers van managementinformatie.

Functioneel beheerder bij gemeente

Deze beheren op functioneel niveau de ICT-voorzieningen van de gemeente, zoals applica-

tieprogrammatuur en gegevensverzamelingen (en de bijbehorende documentatie). Ze laten

deze voorzieningen optimaal aansluiten op de bedrijfsprocessen en daarmee samenhan-

gende wensen van gebruikers en andere belanghebbenden. Dit omvat ten minste gege-

vensbeheer, procesbeheer en gebruikersbeheer.

Technisch beheerder bij gemeente

Technisch beheer omvat voornamelijk het operationeel houden van de – voor de 3D-Suite

benodigde – technische infrastructuur. Bijvoorbeeld: netwerkverbindingen, back-ups, en

beheer van de serverhardware en van ondersteunende software zoals databaseservers,

evenals het installeren en (v.w.b. technische aspecten) testen van nieuwe en verbeterde

versies van de 3D-Suite.

Burgers, burgers en betrokkenen

Burger (of ingezetene) Gezin (huishouden) en gezinslid Familielid, vriend, kennis, etc.

Huisarts, wijkagent, thuiszorg medewerker, etc. Onderwijzer/docent, sportleraar, pastoor/imam, etc.

5.1.3 Specifieke wensen en eisen

In par. 5.2 en verder zijn op basis van bovenstaande visies de wensen en eisen geformuleerd voor

de generieke functionaliteit van de 3D-Suite. Zoals in par. 3.5 beschreven wordt daarbij gebruik

82

gemaakt van Eisen (E#), Gesloten wensen (G#), Open wensen (O#) en

Semigesloten wensen (S#). Zoals gezegd heeft het de voorkeur (vanwege de gewenste flexibiliteit)

dat de specifieke functionaliteiten in dit hoofdstuk zoveel mogelijk ingericht zijn op basis van de

generieke functionaliteiten uit hoofdstuk 4.

83

5.2 Regie

Regie is een breed begrip. In de context van dit PvE is het begrip regie te relateren aan de wens

van de gemeente om zicht te hebben en controle hebben op de burgersituatie op het moment dat

er sprake is van verminderde zelfredzaamheid. Met andere woorden: het regisseren van de

ondersteuning van individuele burgers dan wel een gezin.

Zoals in paragraaf 2.2 reeds beschreven voorzien we vier hoofdmodellen regie, waar binnen een

gemeente deze vier regiemodellen én tussenvormen daarvan dienen te kunnen worden gebruikt.

Geen gemeentelijke regie / zelfregie Regisseur als single point of contact (“light”-versie

van regie)

Regisseur als spin in het web Regisseur als uitvoerder

Figuur 10 Vier vormen van regie

De regisseur wordt ondersteund door de in hoofdstuk 4 weergegeven functionaliteiten.

E7 Regievormen

Dit PvE gaat uit van vier regiemodellen (zie figuur 10): geen regie/zelfregie, regisseur als single

point of contact, regisseur als spin in het web, regisseur als uitvoerder. Het gaat hier om de regie

op de ondersteuning (van klantvraag t/m nazorg). Alle vormen –en tussenvormen ervan– worden

ondersteund door de 3D-Suite.

84

O34 Ondersteunen regie(vormen)

Beschrijf de wijze waarop de 3D-suite ondersteuning biedt aan de genoemde regievormen. En

neem daarbij ook mee dat de vormen gelijktijdig binnen één gemeente toegepast kunnen worden.

Betrek in het antwoord ook de volgende aspecten:

- Zelfregie door de burger

- Het onderscheid tussen “wat” en “dat” informatie

- Het actuele, integrale klantbeeld

- Het registreren en doorzetten van signalen/meldingen

O35 Regie en uitvoering

De regisseur kan puur vanwege de regie bij een gezin betrokken zijn. Maar het kan ook zijn, dat

één van de bij het gezin betrokken hulpverleners de rol van regisseur op zich neemt. In dat

laatste geval is er sprake van één functionaris met verschillende rollen (die van regisseur en die

van uitvoerder).

Beschrijf de wijze waarop deze combi-rol in de 3D-suite toegepast kan worden, beschrijf daarbij

tevens eventuele beperkingen van het systeem als de betreffende hulpverlener geen medewerker

is van de gemeente. Beschrijf tevens in welke mate het klantbeeld afhankelijk van de rechten en

de rol van de medewerker meer of minder informatie kan geven bij de uitvoering van de regie

(i.h.k.v. doelbinding).

85

5.3 Burgerportaal (zelfregie)

In par. 2.3 is het Burgerportaal belicht, waarbij een onderscheid is gemaakt tussen:

A. Informatievoorziening en vraagverheldering. Het gaat hier om op een gebruiksvriende-

lijke wijze toegang bieden tot actuele, complete informatie over (jeugd)zorg, ondersteu-

ning, werk, inkomen en onderwijs. Zie par. 5.3.1.

B. Inzage in eigen plan/dossier en het burgerportaal als communicatieplatform. Dit betreft

het gepersonaliseerd burgerportaal (Mijn „omgeving‟). Zie par. 5.3.2.

Waar nodig dient u in uw beantwoording onderscheid te maken tussen de functionaliteit en de

content. Bijvoorbeeld bevat een set vraag-antwoordcombinaties ter ondersteuning van een klant

enerzijds uit functionaliteit t.b.v. creëren, beheren en publiceren van de VAC door gemeente en

functionaliteit om er doorheen geleid te worden voor de burger. Anderzijds bevat het ook feitelijke

vragen/antwoorden die de gemeente of zelf moet aanmaken, of kan het van de Contractant een

standaardset krijgen die de gemeente vervolgens zelf aanpast.

[NB zie ook hoofdstuk 3 en 11 v.w.b. fasering.]

5.3.1 Niet-gepersonaliseerd burgerportaal (oriëntatie & infor-

matie)

Er komen steeds meer Online community- en „Marktplaats‟-oplossingen, waarmee burgers elkaar

ondersteunen op het brede veld van zorg en welzijn (zie bijlage 0). Daarnaast zijn er functionalitei-

ten, die vooral ingericht zijn en gebruikt worden door burgers, maar ook van belang zijn voor pro-

fessionals in hun werk. Deels betreft het algemene voorzieningen, maar ook voorzieningen, die

door de gemeente zelf worden aangeboden, zoals product- en dienstencatalogus, vraagverhelde-

ring, sociale kaarten.

O36 Online interactie

Beschrijf alle eventuele functionaliteiten op het gebied van online interactie tussen burger en

medewerkers die standaard onderdeel uitmaken van de 3D-Suite en die relevant zijn in het kader

van beoogd gebruik als beschreven in hoofdstuk 2. Geef hierbij vooral aan hoe de vastlegging is

geregeld.

O37 Informatievoorziening en vraagverheldering

Beschrijf alle eventuele functionaliteiten (incl. geboden standaardcontent) op het gebied van m.n.

niet-gepersonaliseerde informatievoorziening en vraagverheldering die standaard onderdeel

uitmaken van de 3D-Suite en die relevant zijn in het kader van beoogd gebruik als beschreven in

hoofdstuk 2. Denk hierbij aan:

- Webcontent management (CMS), zowel publicatie- als redactie-functionaliteit

- Product- en Diensten catalogus (PDC/ kennisbank) inclusief:

▪ functionaliteit voor het aanbieden van een overzichtsweergave van beschikbare producten

en diensten, in meerdere varianten van groepering en sortering.

▪ Onderscheid tussen externe en interne informatie, m.a.w. hoe kan productbeschrijving-

informatie toegevoegd worden, die alleen voor medewerkers beschikbaar is?

- Vraaggeleiding/beslisbomen om burgers en medewerkers door middel van vraaggeleiding / be-

slisbomen naar relevante (op de situatie/behoefte toegespitste) informatie. Dat kan een be-

86

schrijving zijn van een product of dienst, maar ook een antwoord op de vraag (FAQ of VAC) of

men voor een voorziening in aanmerking komt.

▪ In het doorlopen van een vraaggeleiding wordt als het ware een klantprofiel (een beeld van

de zorgbehoefte) opgebouwd. Deze informatie wordt dan bij voorkeur doorgegeven aan een

digitaal aanvraagformulier of een digitale afspraak (onderdeel van het gepersonaliseerde

klantportaal).

▪ Standaard content: door u te leveren content of integratie met andere content leveranciers

- Sociale kaart: een digitale gids met informatie over dienstverleners en instellingen (functionali-

teit en/of standaard content).

- Zoeken in (niet-gepersonaliseerde) content. De 3D-Suite biedt zoekfunctionaliteit. Speciale

aandacht verdient het zoeken in verschillende bronnen en een overzichtelijke weergave en het

geïntegreerd tonen van zoekresultaten. Bijvoorbeeld bij het zoeken naar een bepaald onder-

werp worden op een overzichtelijk wijze alle relevante productbeschrijvingen, beslisbomen, so-

ciale kaarten en „ook van belang‟ (bijvoorbeeld links naar externe sites, verwijzingen naar re-

gelgeving en beleidsinformatie) getoond.

Geef aan in welke mate dit wordt geconfigureerd o.b.v. de in voorgaande hoofdstuk beschreven

standaardfunctionaliteiten.

O38 Integratie met de gemeentelijke website/ digitaal loket

Veel gemeenten hebben de onder O37 genoemde functionaliteit al in huis via hun website, digitaal

loket en klantcontactsysteem. Beschrijf de mate van integratie tussen de 3D-Suite en de

genoemde systemen. Maak daarbij een onderscheid tussen de doelgroepen burger en

medewerker.

- Onze denkrichting is dat burgers en professionals bij hun vragen en activiteiten op het sociaal

domein werken vanuit één platform/interface. Burgers zullen zich op het Burgerportaal infor-

meren naar mogelijkheden in ondersteuning. Professionals kunnen diezelfde informatie gebrui-

ken in het (intake) gesprek aan de keukentafel of aan de telefoon in het klantcontactcentrum.

- Uitgangspunt hierbij is eenmalig vastleggen en meervoudig gebruik van content, maar ook

geen redundantie qua functionaliteit.

- Er moet bovendien rekening gehouden worden met diverse organisatievormen, m.a.w. de on-

dersteuning op het sociaal domein kan geheel buiten de gemeente geplaatst worden (regie op

afstand) of men kan kiezen voor een grote inzet in de regie en uitvoering door gemeente zelf.

O39 Online community en ‘Marktplaats’ oplossingen

Beschrijf alle eventuele functionaliteiten die standaard onderdeel uitmaken van de 3D-Suite en die

naar uw mening relevant zijn op het gebied van Online community en „Marktplaats‟ voor burgers

onderling (waar burgers elkaar onderling kunnen vinden en helpen, zie bijv. bijlage 12.7. Denk

hierbij o.a. aan:

- 1P functionaliteiten van de in bijlage 0 genoemde voorbeelden (We Helpen.nl, Wikiwijk Tilburg,

Buuv.nu, Jeugdcloud, Toegankelijk Enschede, Zorgsite (Helmond)).

- Integratie met 3P-oplossingen.

Het idee is dat een burger, indien hij ondersteuning bij de gemeente aanvraagt, zelf (een deel

van) zijn informele „community‟ beschikbaar kan stellen voor de regisseur/professional, zodat

informele en formele ondersteuning optimaal op elkaar afgestemd kunnen worden.

Geef aan in welke mate dit wordt geconfigureerd o.b.v. de in voorgaande hoofdstuk beschreven

87

standaardfunctionaliteiten.

5.3.2 Gepersonaliseerd Burgerportaal

Dit omvat het deel van de 3D-suite waarop de burger toegang heeft tot zijn gegevens/ dossier en

diverse functionaliteiten tot zijn beschikking heeft. Hierdoor kan de burger in belangrijke mate ac-

tief „meedoen‟ in de uitgezette trajecten. Zelfregie is mogelijk.

O40 Zelfdiagnose

Hoewel het ondersteuningsplan (zie ook S14) als een gezamenlijk (van regisseur en burger/gezin)

actieplan gezien kan worden weerspiegelt de bovengenoemde functionaliteit een reactieve burger.

Het is zaak om de burger juist in de intake c.q. bij het opstellen van het ondersteuningsplan zelf

het initiatief/ de regie te laten nemen. Inzicht in de eigen situatie en zelf aan de slag gaan met

voorgestelde acties is een belangrijk gegeven.

Geef aan welke functionaliteit de 3D-Suite biedt om burgers een zelfdiagnose uit te laten voeren.

Op basis van bij voorkeur het (zelf aangevulde) klantbeeld en een zelf ingevulde

zelfredzaamheidmatrix evt. met inzet van andere instrumenten verkrijgt de burger:

- Relevante (regionale) informatie

- Waar mogelijke voorstellen om zelf actie te ondernemen

- Overzicht naar juiste hulpverleners met de nadruk op collectieve voorzieningen en de informele

sector/ het eigen netwerk.

Beschrijf uw functionaliteit in deze. Geef tenslotte aan in welke mate dit wordt geconfigureerd

o.b.v. de in voorgaande hoofdstuk beschreven standaardfunctionaliteiten.

S13. Persoonlijke gegevens inzien en aanpassen (basis)

De 3D-Suite biedt functionaliteit om burgers inzage te geven in eigen gegevens, waaronder ten

minste:

- de eigen algemene persoonsgegevens uit het GBA

- e-mailadres en telefoonnummers. Hierbij wordt bovendien de mogelijkheid geboden om het e-

mailadres en de telefoonnummers zelf in/aan te vullen / te wijzigen

- de eigen gegevens uit het DKD, Digitaal Klant Dossier – mits daartoe geautoriseerd

O41 Persoonlijke gegevens inzien en aanpassen (aanvullend)

Geef aan welke functionaliteit de 3D-Suite biedt om burgers inzage te geven in hun eigen

klantprofiel dat wordt opgebouwd aan de hand van scores op o.a.:

- De zelfredzaamheidmatrix

- De participatieladder

De 3D-Suite biedt functionaliteit om burgers in een Burgerportaal het eigen klantbeeld te verrijken

(aanpassen) en te beheren. Men kan daarbij denken aan:

- Gegevens qua opleiding, werkervaring

- Eigenschappen, competenties, voorkeuren (evt. aangevuld door anderen)

88

Beschrijf uw functionaliteit in deze. Geef aan in welke mate dit wordt geconfigureerd o.b.v. de in

voorgaande hoofdstuk beschreven standaardfunctionaliteiten.

S14. Mijn ondersteuningsplan (basis)

De 3D-Suite biedt functionaliteit om burgers inzage te geven in:

- Het ondersteuningsplan

- Lopende zaken (de afgesproken acties) en lopende contacten. Hierbij wordt ten minste de ac-

tuele statusinformatie (incl. toelichting) getoond.

Er is ook functionaliteit om te reageren op de lopende zaken en de eigen zaken te beheren.

Daarbij kan gedacht worden aan:

- Online toevoegen van informatie (vragen, opmerkingen) aan het ondersteuningsplan en/of lo-

pende zaken/ contacten

- Beheren van de eigen (aan de burger zelf toegewezen) acties uit het ondersteuningsplan

O42 Mijn ondersteuningsplan

Beschrijf de mate waarin de burger ondersteund wordt om zo gebruiksvriendelijk mogelijk de

functionaliteiten kan gebruiken als beschreven in voorgaande wens.

Geef tevens aan in welke mate dit wordt geconfigureerd o.b.v. de in voorgaande hoofdstuk be-

schreven standaardfunctionaliteiten.

S15. Mijn dossiers

De 3D-Suite biedt functionaliteit om burgers:

- inzage te geven in de documenten die hij heeft ingediend en in andere documenten waar hij

toe is geautoriseerd (bijv. documenten in deelzaken waar hij zelf verantwoordelijk voor is)

- reacties op documenten online toe te voegen

- zelf documenten toe te voegen

G21 Notificatie en persoonlijke berichtenbox

G21.1 De 3D-Suite biedt functionaliteit om burgers voorkeuren voor gepersonaliseerde informatie

in het Burgerportaal op te laten geven. Aan de hand van het ingegeven interesseprofiel krijgt de

burger een e-mail-notificatie, waarin een korte omschrijving met een link naar het nieuwsbericht

is opgenomen. Dit omvat ten minste

- Statuswijziging van ondersteuningsplan en/of acties

- Wijzigingen aangaande de contactpersoon/regisseur

- Uitnodiging om afspraak te maken en/of reminder vlak voor een geplande afspraak

- Reminder voor het indienen van gevraagde informatie

- Toegevoegde informatie (brochures e.d.) door de regisseur aan „Algemene informatie‟ (of ge-

lijkwaardig)

G21.2 De berichten worden afgeleverd en bewaard in een persoonlijke berichtenbox.

S16. Mijn contactpersoon

De 3D-Suite biedt functionaliteit om burgers snel contact te leggen met hun regisseur/

contactpersoon. De contactgegevens en bereikbaarheid van de contactpersoon en/of team zijn

89

beschikbaar. Daarbij is ook functionaliteit opgenomen om direct een bericht aan de

contactpersoon online in te dienen.

S17. Mijn Agenda

De 3D-Suite biedt functionaliteit om burgers met betrokken hulpverleners en andere daartoe

geautoriseerde personen (zoals familieleden of mantelzorg) een gezamenlijke agenda te voeren.

Dit betreft ten minste:

- Het toevoegen van afspraken door burgers

- Het plaatsen van uitnodigingen voor overleg door de regisseur en andere professionals

- Het opnemen van mijlpalen van het ondersteuningsplan. Hierdoor is het mogelijk om een be-

knopt overzicht (in grafische vorm) van de mijlpalen en voortgang van het ondersteuningsplan

apart toe te voegen. Dat overzicht kan bij de agenda, maar ook op de pagina van het onder-

steuningsplan geplaatst worden.

S18. Algemene informatie

- De 3D-Suite biedt functionaliteit om burgers in een „Mijn Omgeving‟ snel toegang te geven tot

(voor hun situatie c.q. ondersteuningsplan) relevante algemene niet-gepersonaliseerde infor-

matie zoals brochures etc.

- Burgers kunnen zelf het onderdeel beheren, maar ook de regisseur/ professionals kunnen al-

gemene informatie aanbieden.

- Via het interesseprofiel kan de burger hiervoor toestemming geven. Via notificatie krijgt de

burger bericht als er nieuwe informatie toegevoegd is.

O43 Digitale aanvragen

Beschrijf de mate waarin de 3D-Suite functionaliteit biedt om burgers digitale aanvragen te laten

indienen. Hierbij moet men denken aan:

- Het indienen van een aanvraag via een e-formulier incl. voorinvulling (prefill) van reeds be-

kende gegevens

- Digitale aanvragen kunnen een nieuw (nog op te starten) ondersteuningsplan betreffen

- Digitale aanvragen kunnen vanuit een lopend ondersteuningsplan gestart worden. De aanvraag

heeft dan ook de kenmerken van (is gekoppeld aan) het ondersteuningsplan.

- Opslaan van gedeeltelijk ingevulde e-formulieren, die later weer opgepakt kunnen worden voor

verdere invulling

- Hergebruik van vorige (de laatst ingediende) aanvraag als basis voor de nieuwe aanvraag. Dit

is handig als er frequent (jaarlijks) een nieuwe aanvraag ingediend moet worden en de situatie

vrijwel ongewijzigd is

- Een betaalmodule. In een traject, waarin betaling aan de orde is een stap ingebouwd waar een

specificatie incl. factuur wordt opgesteld en aan „Mijn Omgeving‟ wordt aangeboden. Daar kan

de burger met online betaling (iDEAL) de betaling regelen. Gemak voor de burger, efficiëntie

voor de gemeente/ondersteuner en snelheid voor beide partijen.

- Etc.

NB dit betreft het gebruik door burgers (vaak met verminderde zelfredzaamheid). Het inrichten en

beheren van de formulieren is gevraagd in par. 4.3.

90

S19. Koppeling met de landelijke voorziening ‘MijnOverheid’

De 3D-Suite biedt bij voorkeur functionaliteit voor directe aansluiting op de landelijke voorziening

MijnOverheid.nl, zodat per zaak ten minste actuele statusinformatie en de zaakdocumenten uit

het zaakdossier - rekening houdend met autorisaties – onder „lopende zaken‟ in de landelijke

voorziening MijnOverheid.nl worden getoond.

Daarnaast worden gepersonaliseerde berichten getoond in de „berichtenbox‟ van MijnOverheid.nl.

Dit betreft ten minste: ontvangstberichten, verzoeken om nadere informatie, besluiten,

attenderingen, betaalspecificaties, oproepen, etc.

O44 Visie op zelfregie

Natuurlijk beogen we het „zelf doen‟ te stimuleren, maar de hoofdrol ligt bij de professionele

regisseur. De 3D-Suite dient vooral die regisseur te ondersteunen. Geef uw visie – en de mate

waarop dit nu en in de toekomst wordt ondersteund met uw 3D-Suite - hoe u met de ontwikkeling

van uw oplossing aankijkt tegen zelfregie.

91

5.4 Het regieproces

Het gaat hier om het regieproces. In par. 2.4 is de rol incl. taken van de regisseur beschreven. Om

die rol mogelijk te maken is in par. 5.1.2 een aantal uitgangspunten benoemd, waarbij vooral de

primaire functies relevant zijn. In par. 5.4 worden functionaliteiten beschreven, die betrekking

hebben op componenten, die in het gehele regieproces relevant zijn. Denk daarbij bijvoorbeeld aan

het integrale klantbeeld (inkijk). Daarnaast zullen ook andere functionaliteiten beschreven worden,

die inhoud geven aan een primaire functie. Voor de duidelijkheid: steeds als aanvulling op de gene-

rieke functionaliteit.

5.4.1 Integraal klantbeeld

O45 Integraal klantbeeld (basis)

Het integrale klantbeeld (zie ook par. 2.4.1) bestaat uit gegevens van de burger, zoals NAW, in-

komen, schulden, opleidingen, die zoveel mogelijk uit andere systemen worden betrokken. Ook

indicaties van ontvangen voorzieningen voor jeugdhulp, zorg of ondersteuning vormen een on-

derdeel.

Beschrijf alle functionaliteiten op het gebied van basisgegevens die standaard onderdeel uitmaken

van de 3D-suite en die relevant zijn in het kader van beoogd gebruik als beschreven in hoofdstuk

2. Denk hierbij aan:

- NAW over de betrokken persoon en het gezin

- Werk, inkomens- en uitkeringsverhoudingen

- Ontvangen ondersteuning, waaronder ook schulden en schuldhulpverlening

- Onderwijs en opleidingsgegevens, incl. leerplicht / RMC

- Evt. justitiële gegevens

Geef aan welke bronnen hierbij gebruikt worden c.q. vanuit de 3D-suite bevraagd worden (zie ook

bijlage 12.2 v.w.b. de informatie die via de GeVS kan worden geleverd).

Denk ook aan

- indicaties van ontvangen voorzieningen voor jeugdhulp, zorg of ondersteuning

Deze indicaties kunnen vanuit diverse registratiesystemen komen, zoals gemeentelijke backoffice-

systemen.

Geef aan in welke mate bij / voor weergave rekening wordt gehouden met de autorisatie en rol

van de persoon die informatie wil zien (doelbinding).

O46 Toegevoegde gegevens door burger

Via het Burgerportaal kan de burger bij voorkeur zelf gegevens en documenten toevoegen en die

vrijgegeven voor gebruik (zie ook O40 op blz. 87). Beschrijf de mate waarin de burger hierbij

wordt ondersteund en de wijze waarop deze gegevens kunnen worden toegevoegd en als inte-

graal onderdeel van het klantbeeld kunnen worden gepresenteerd .

O47 Het sociaal netwerk van de burger

Beschrijf de mate waarin en de wijze waarop het sociale netwerk van de burger geregistreerd en

toegevoegd kan worden aan het Klantbeeld (familieleden, vrienden, buren, …). Geef aan of en op

welke wijze hier een onderscheid gemaakt kan worden tussen het „algemene‟ netwerk en het net-

werk dat relevant is voor een specifiek behandelplan.

92

Beschrijf de wijze waarop het netwerk rondom de burger in één oogopslag inzichtelijk is. Voor-

beeld om een relatienetwerk in beeld te brengen is een sociogram.

De burger kan (al dan niet samen met de regisseur) wellicht ook zijn sociale netwerk betrekken

bij het uitvoeren van het ondersteuningsplan. Geef aan of en in welke mate specifieke delen van

een behandelplan inzichtelijk kunnen gemaakt voor die derde burgers – zonder dat de privacy van

de burger in gevaar komt.

O48 Overzicht van informele ondersteuning

Een burger kan (als mede-uitvoerder) participeren in het behandelplan en de 3D-suite gebruiken

als informatie- en communicatieplatform. De burger kan (daarnaast) ook zaken regelen, die niet

geregistreerd worden in de 3D-suite, maar die wel relevant zijn voor het behandelplan. Dat zal

ook gelden voor personen uit zijn netwerk.

Beschrijf de mate waarin de informele omgeving van de klant verbonden kan worden met de 3D-

suite (of uw visie daarop). Denk bijv. aan het verbinden van „online community‟ en „marktplaats‟

oplossingen (zie par. 5.3.1) met de 3D-suite en/of de functionaliteit van de 3D-suite te verbreden

en de toegang laagdrempelig te maken m.b.v. bijvoorbeeld mobiele toepassingen, apps, e.d. –

voor zover dit de privacy en beveiliging niet kan schaden.

O49 Klantprofiel

Er zijn diverse methodes om de situatie van de klant te meten/ kwalificeren in een klantprofiel.

Eén van bekende methodes is de „Zelfredzaamheidsmatrix‟. Op het domein van werk en inkomen

is de Participatieladder een veel toegepast instrument. De score op de Zelfredzaamheidsmatrix

geeft een indruk/beeld van de zelfredzaamheid en waar ondersteuning nodig is. Dit instrument

kan bij de intake ingezet worden (als nulmeting), maar ook als monitorinstrument tijdens en aan

het eind van het behandeltraject. De actuele score kan als het ware als een foto van de situatie

van de klant aan het klantbeeld toegevoegd worden.

Beschrijf de mate waarin de 3D-Suite functionaliteit biedt en de wijze waarop de Zelfredzaam-

heidsmatrix en/of de Participatieladder toegepast kan worden c.q. integraal onderdeel uitmaakt

van de 3D-suite om een zo volledig mogelijk klantbeeld te vormen.

O50 Klantbeeld (overig)

Beschrijf alle eventuele additionele functionaliteiten inzake het klantbeeld die standaard onderdeel

uitmaken van de 3D-suite en die relevant zijn in het kader van beoogd gebruik als beschreven in

hoofdstuk 2. Denk hierbij aan:

- weergave van de laatste entries van het contactjournaal

- overzicht van de eigen aantekeningen over de burger

- financieel overzicht van de gemaakte kosten tot zover

- etc.

5.4.2 (Inkomende) signaleringen, meldingen en contacten

Het gaat hier om inkomende signaleringen, meldingen en contacten. De interne signalering wordt

beschreven in par. 5.4.4. Signalen en meldingen hebben betrekking op de situatie van een burger /

gezin. Er wordt iets (opmerkelijks) onder de aandacht gebracht. Daarnaast is er sprake van inter-

actie (contacten) tussen burger en hulpverleners. Hierbij valt te denken aan input van de burger op

het behandelplan, digitale communicatie tussen burger en hulpverlener.

93

S20. Inkomende signaleringen en meldingen (basis)

- Op basis van een bericht uit ieder kanaal (een webformulier, e-mail, een telefoongesprek, een

gesprek, maar ook een geautomatiseerd systeem) kan een signaal worden vastgelegd.

- Signaleringen kunnen zowel handmatig als geautomatiseerd worden ingevoerd.

- Een filtermechanisme zorgt ervoor dat het signaal eerst wordt getoetst aan de hand van door

de gemeente ingestelde en aanpasbare business rules, waarbij informatie uit andere bijvoor-

beeld bronsystemen worden opgehaald voordat het signaal wordt omgezet in een melding en

deze melding ook wordt doorgezet.

- Signalen kunnen automatisch én handmatig een prioriteit krijgen. Bijvoorbeeld: signaleringen

inzake veiligheid krijgen standaard een hoge urgentie

- De gemeente heeft de mogelijkheid om deze prioritering en de business rules zelf te configure-

ren.

- Een signaal bevat minimaal de volgende gegevens:

▪ Identificatie van de betreffende persoon, gezin

▪ Contactgegevens van de melder

▪ Relatie tussen melder en betrokken persoon / gezin

▪ De situatie die aanleiding gaf tot de melding

▪ De inhoud van de signalering

- Signalen verdwijnen (op basis van door Gemeente in te stellen bewaartermijnen) uit het actie-

ve systeem: 'het recht om vergeten te worden'

- De toegang tot vastgelegde signalen wordt op basis van autorisatie geregeld

O51 Inkomende signaleringen en meldingen (additioneel)

Beschrijf alle eventuele additionele functionaliteiten inzake signaleringen / meldingen die stan-

daard onderdeel uitmaken van de 3D-suite en die relevant zijn in het kader van beoogd gebruik

als beschreven in hoofdstuk 2. Denk hierbij aan:

- Handmatig en geautomatiseerd invoeren van een signalering / melding, m.a.w. de wijze waar-

op de 3D-suite de mogelijkheid biedt om signaleringen direct in te voeren (bijvoorbeeld aan de

hand van een e-formulier).

- De mate waarin signaleringen / meldingen gestructureerd worden vastgelegd en dat vastleg-

gen gegevens verplicht gesteld worden

- Signalering / melding koppelen aan een burger/gezin (automatisch, bijv. o.b.v. BSN, of hand-

matig) en/of (lopend) behandelplan

- Doorvoeren van een signalering / melding voor follow-up. Dat kan een terugbelnotitie zijn, een

notitie/reminder, of een deelzaak. Uiteraard kan bij voorkeur aan een vervolgactie ook een

termijn incl. (interne) signalering / melding gekoppeld worden.

- De mate waarin bij het invoeren/vastleggen van een signaal in de 3D-suite de (meta)gegevens

op een efficiënte, gebruiksvriendelijke wijze kunnen worden vastgelegd t.b.v. zowel manage-

mentinformatie (t.b.v. sturing op een hoger niveau zoals inzake beleid of afspraken tussen or-

ganisaties) en de informatie voor de uitvoering.

- De mate waarin door de gemeente aanpasbare business rules worden toegepast t.b.v. priorite-

ring en gefilterd doorsturen, incl. hoe de regisseur de prioritering/filtering handmatig kan over-

rulen.

- De wijzen waarop een indiener een automatische bevestiging van zijn melding kan krijgen.

Er zijn landelijk steunpunten/systemen, die op deelterreinen (vroeg)signalering regelen. Zo is

94

rondom Algemeen Meldpunt Kindermishandeling en Steunpunten Huiselijk Geweld de signalering

van kindermishandeling en huiselijk geweld georganiseerd. In de Verwijsindex Risicojongeren

(VIR) kan jeugdproblematiek gemeld worden en via Suwinet kunnen hulpverleners in de sector

werk & inkomen elkaar informeren. Via de justitiële keten zullen de volgende signalen ontvangen

worden: „informering over maatregel jeugdbescherming en/of - reclassering‟, „melding onderzoek

gestart VTO‟, „melding ambtshalve onderzoek‟, „beslissing opleggen maatregel‟. De interactie tus-

sen gemeenten, gecertificeerde instellingen en VenJ uitvoeringsorganisaties zal verlopen via de

Collectieve Opdracht Routeer Voorziening13, conform de beschrijving in de Project Start Architec-

tuur van deze voorziening. Dit betekent ondermeer dat gebruik gemaakt moet worden van digi-

koppeling melding ebMS en gestandaardiseerde berichten. CORV zorgt voor een goede routering

en vertaling van berichten tussen het justitiedomein en het gemeentelijk domein.

O52 Contacten

Veel contacten tussen hulpverleners, gezin/burger en regisseur zijn niet in een standaardformaat

te vangen. Daarnaast zijn burgers vrij in het kiezen van het communicatiekanaal. Deze ogen-

schijnlijk ongestructureerde wijze van contact kan wel gestroomlijnd worden. Want meer struc-

tuur is nodig, zodat ook deze informatie toegankelijk en beschikbaar is. Bovendien wordt veel be-

lang gehecht aan een veilige manier van communicatie.

Beschrijf de mate waarin u het beoogd gebruik ondersteunt t.b.v. contacten, voor zover deze die

standaard onderdeel uitmaken van de 3D-suite en die naar uw mening relevant zijn. Denk hierbij

aan:

- De inzet van het burgerportaal, waarin de burger na te zijn ingelogd via een contactformulier

snel en eenvoudig vragen kan stellen aan de regisseur of anderen, en de hulpverlener de bur-

ger kan bereiken

- Gebruik van KCC-functionaliteit om telefonische contacten vast te leggen en evt. van follow-up

te voorzien.

- Door koppeling aan „Mijn Overheid‟ statusberichten (via „Lopende zaken‟) en ander berichten

(via de „Berichtenbox‟) beveiligd verzenden aan burgers.

5.4.3 Intake, doelstelling, maatregelselectie en ondersteu-

ningsplan

Dit omvat de fases/functies van intake, onderzoek, doelstelling, maatregelselectie en behandel

(ondersteunings)plan (zie par. 5.1.2). Het betekent niet dat in alle gevallen alle functies ingezet

worden noch impliceert het dat er sprake is van een vaste volgorde. In het behandelplan zijn de

afspraken tussen de burger/ het gezin en de regisseur vastgelegd. Het vormt het de basis, waarop

de ondersteuning wordt geleverd.

13 De desbetreffende PSA Keteninformatie is formeel vastgesteld in het opdrachtgeversoverleg stelselherziening

Jeugd (VNG, VWS en VenJ) op 25 juni 2013. Er zal (1) gegevens uitwisseling tussen gemeente, jeugdstraf-

rechtketen en jeugdbeschermingsketen gaan plaatsvinden, bijvoorbeeld een gestandaardiseerd Verzoek tot On-

derzoek (VTO) als startmoment voor de jeugdbeschermingsketen; ook zullen de gemeenten allerlei gestan-

daardiseerde berichten uit de justitiële jeugdketens ontvangen en (2) beleidsinformatie richting V&J. VWS, VenJ

en enkele gemeenten gaan hiervoor een proeftuin inrichten.

95

Er is sprake van één ondersteuningsplan, dat alle doelen bevat incl. de

maatregelen / taken / acties van zowel de burger zelf, zijn netwerk, gemeentelijke medewerkers,

als de betrokken uitvoeringsorganisaties.

Alle situaties (eenvoudig, complex, enkelvoudig, multi-probleem, vrijwillig en onder dwang) passen

in dit stramien. Juist omdat het flexibel is.

O53 Intake & onderzoek

T.b.v. intake en onderzoek kan een zo compleet mogelijk (binnen de kaders van wetgeving / pri-

vacy) overzicht van alle geleverde ondersteuning richtinggevend zijn voor het op te starten tra-

ject: betreft het een geheel nieuwe burger? Is er sprake van herhaling, terugval wellicht? Is er op

andere terreinen recent ondersteuning gevraagd en toegewezen? Etc.

Beschrijf alle functionaliteiten inzake Intake & onderzoek die standaard onderdeel uitmaken van

de 3D-suite en die naar uw mening relevant zijn. Denk hierbij aan:

- Het complete klantbeeld (zie ook par. 5.4.1)

- Direct, on line inzicht in de ingediende (aan)vraag

- Direct, on line inzicht in de resultaten van de vraagverheldering, indien de burger die evt.

voorafgaand aan de ingediende aanvraag of afspraak heeft ingevuld.

- Direct, online inzicht in afgesloten trajecten.

- Functionaliteit voor een casusoverleg t.b.v. bespreking van de situatie van de burger (casus) in

een team van professionals.

De intake hoeft niet één regisseur en één burger (of gezin) te betreffen. Ook mantelzorgers

kunnen een rol spelen, net als andere professionals. Beschrijf de mate waarin een een regisseur

ondersteunt wordt om ad-hoc rollen en taken te toebedelen.

O54 Ondersteuning tijdens intakegesprekken

Beschrijf tevens de ondersteuning v.w.b. diagnose en zelfdiagnose: welke mogelijkheden zijn er

voor de regisseur én de burger om de intake en diagnose bijvoorbeeld aan de hand van een

beslisboom zelf uit te voeren. Zie ook het voorbeeld in bijlage 0.

Beschrijf ook de wijze waarop de Zelfredzaamheidsmatrix en de Participatieladder (en evt.

vergelijkbare instrumenten) door de medewerker en de burger zelf zijn in te zetten. Geef daarbij

aan op welke wijze dergelijke instrumenten geïntegreerd zijn in de 3D-suite. Is er bijvoorbeeld

sprake van een intake-vragenlijst op basis van de Zelfredzaamheidsmatrix? Op welke wijze is de

Zelfredzaamheidsmatrix gekoppeld aan de doelstellingen en de maatregelen?

Er is vaak sprake van overleg bij de burger thuis. Ook dan zal de 3D-suite beschikbaar moeten

zijn, zowel om gegevens/ documenten te raadplegen als ook gegevens/ documenten toe te

voegen/ te wijzigen. Beschrijf de wijze waarop dat mogelijk is, bijvoorbeeld door –beveiligd- een

subset van data mee te nemen, of door een versie van de applicatie te bieden die bruikbaar is

i.c.m. mobiele toegang.

G22 Het plan (doelstelling, maatregelselectie en opstellen plan) (basis)

In toenemende mate zal een mix van professionele en informele ondersteuning de oplossing bie-

den. Handwerk van de regisseur blijft nodig, maar een voorstel van het systeem kan hem daarbij

zeker helpen. Zowel het voorstel als de uiteindelijke keuze van de regisseur (en burger) worden

96

vastgelegd, zodat later op basis van nadere analyses de regisseur betere keuzes kan maken en

het systeem beter ingeregeld kan worden.

De functionaliteiten inzake intake & onderzoek die standaard onderdeel uitmaken van de 3D-suite

omvatten ten minste:

G22.1

- Gestructureerd vastleggen van doelen per gezin. Er zijn per gezin meerdere doelen mogelijk

waarbij het te bereiken doel verschilt per leefdomein. Doelen kunnen ook aan specifieke ge-

zinsleden gekoppeld worden.

- Relaties/ afhankelijkheden tussen de doelen vastleggen.

G22.2

- Vastleggen van met de klant afgestemde de termijnen waarop doelen gehaald worden.

G22.3

- Vastleggen van evaluatiemomenten waarop geëvalueerd wordt of de doelen bereikt zijn

G22.4

- De mogelijkheid om vast te leggen in hoeverre de doelen bereikt zijn op een evaluatiemoment,

ten minste o.b.v. tekstvelden.

G22.5

- De mogelijkheid om één of meer maatregelen (taken/acties, zie paragraaf 5.4.4) te selecteren

en te koppelen aan de vastgestelde doelen z.d.d. maatregelen aan doelen zijn te matchen.

G22.6

- Vastleggen van de termijnen waarop de taken uitgevoerd dienen te zijn (gerelateerd aan de

ter-mijnen van de doelen)

G22.7

- Vastleggen van de kosten van de geselecteerd acties (mogelijkheid om bij acties standaard-

kosten op te nemen), ten minste o.b.v. tekstvelden

G22.8

- Vastleggen van de uitvoerder of uitvoerders van de acties (gezin, omgeving, en/of professione-

le ondersteuners)

G22.9

- Verschaffen van actuele totaaloverzichten per plan incl. doelen, taken, kosten, termijnen, ge-

kozen ondersteuners, etc.

O55 Het plan (doelstelling, maatregelselectie en opstellen plan)

Beschrijf alle aanvullende functionaliteiten inzake intake & onderzoek die standaard onderdeel

uitmaken van de 3D-suite en die naar uw mening relevant zijn bij het opstellen – en tijdens uit-

voering zonodig aanpassen – van een ondersteuningsplan. Denk hierbij aan de mate waarop de

regisseur, burger en ondersteuner worden ondersteund bij het vastleggen van de in voorgaande

wens gevraagde aspecten en:

- Gestructureerd vastleggen van doelen per gezin bij voorkeur o.b.v. een instrument / methode

als de Zelfredzaamheidsmatrix

- De wijze waarop afhankelijkheden tussen doelen worden vastgelegd (eerst doel 1 en 2, als dat

97

gereed is doel 3 en tenslotte doel 4).

- De mogelijkheid om de realisatie van doelen vast te leggen in kwantitatieve en kwalitatieve zin

(bijv. zelfredzaamheid inkomen was 1 en groeit in 3 jaar naar 4, met een beschrijving van de

eindsituatie)

- De mogelijkheid om vast te leggen in hoeverre de doelen bereikt zijn op een evaluatiemoment

(zelfredzaamheid „inkomen‟ is nu 3 en verbeterd, en 60% is gerealiseerd).

- De mogelijkheid om één of meer maatregelen (taken/acties, zie paragraaf 5.4.4) te selecteren

en te koppelen aan de vastgestelde doelen z.d.d. maatregelen bij voorkeur door de 3D-Suite

aan doelen zijn te matchen.

- Taken selecteren o.b.v. standaardlijsten (bijv. dienstenboek) maar ook ad-hoc acties opnemen

(oma gaat helpen schoonmaken, of bijv. een dienst van een niet eerder bekende organisatie).

- Vastleggen van relaties tussen de taken (bijv. o.b.v. gerelateerde zaken)

- Vastleggen van de kosten van de geselecteerd acties (mogelijkheid om bij acties standaard-

kosten op te nemen), ten minste o.b.v. tekstvelden doch bij voorkeur ook gestructureerde vel-

den i.r.t. voornoemde standaardlijsten (bijv. dienstenboek)

- Aanvullende informatie over bijvoorbeeld „best practices‟ (een succesvolle aanpak in een ver-

gelijkbare situatie).

- Verschaffen van actuele informatie over de ondersteuner zoals wachttijden.

- Informatie over collectieve voorzieningen en informele ondersteuning

- Ondertekenen van het behandelplan. Hierbij kan gedacht worden aan de inzet van digitale

handtekening

- Actuele totaaloverzichten per plan incl. doelen, taken, kosten, termijnen, gekozen ondersteu-

ners, etc. zijn bij voorkeur realtime / dynamisch (zodra het plan wordt aangepast worden de

overzichten automatisch aangepast).

- Etc.

5.4.4 Taken/acties incl. signalen en ketenberichten

Het ondersteuningsplan is vastgesteld. Vervolgens gaat het om een effectieve, samenhangende

uitvoering van de acties uit het plan. Op hoofdlijnen omvat dit:

- Uitzetten van de acties

- Bewaken van de acties (verloopt het conform de afspraken?)

- Bewaken en evt. bijstellen van het ondersteuningsplan

- Evalueren van het ondersteuningsplan (zijn de resultaten, doelen bereikt?)

- Nazorg

De regisseur bewaakt de voortgang en kwaliteit van het totale ondersteuningsplan, maar is niet

noodzakelijkerwijs verantwoordelijk voor de uitvoering van de afzonderlijke acties. Dat is het

domein van de tweedelijns professionals/ondersteuners.

Het ondersteuningsplan is dynamisch. Dat wil zeggen, tijdens de uitvoering kan het plan bij

voorkeur eenvoudig aangepast worden op alle onderdelen ervan (doelen, termijnen, acties, de

volgorde van doelen en acties, uitvoerders). Het systeem laat bij voorkeur ook zien wat de

gevolgen zijn van die aanpassingen (in kosten, doorlooptijden etc.). Het draait dus om flexibiliteit

(ad-hoc en snel doorvoeren van aanpassingen), integrale aanpak en samenhang.

In Bijlage 0 is als referentie een aantal van huidige hoofdprocessen van Awbz, Wmo en Jeugdzorg

opgenomen. De 3D-Suite moet bij deze indelingen passen.

98

Hier worden de functionaliteit gevraagd, die aanvullend is op de generieke

functies, zoals genoemd in hoofdstuk 4. Daar is veelal uitgegaan van de zaakgericht werken-

concepten. Het proces rond de regie op het ondersteuningsplan (het ondersteuningstraject) vormt

dan bijvoorbeeld de hoofdzaak, met waar nodig losse maatregelen als verschillende deelzaken

(taken die zijn uitgezet bij verschillende hulpverleners). Binnen iedere zaak (incl. de hoofdzaak)

kunnen dan zowel aanvullende statussen worden toegevoegd, als aanvullende deelzaken.

O56 Inrichting processen / zaken

Beschrijf de wijze waarop u de standaard procesinrichting modelleert o.b.v. de in hoofdstuk 4

gevraagde / aangeboden functionaliteiten. Denk daarbij aan o.a.

- Inrichten van ondersteuning (hoofdzaak per ondersteuningsplan + deelzaken met maatregel?)

- Zowel de mogelijkheden tot modelleren door functioneel beheer als ad-hoc aanpassing

- Het op ten minste op hoofdlijnen modelleren van (deel)zaaktypen als „aanvraag subsidie‟) en

daar naar verwijzen vanuit dienstenboek.

- Hoe onverwachte of anderszins niet gemodelleerde maatregelen („oma past op‟) ad-hoc zijn in

te richten én bewaken, bijv. middels een standaard zaaktype met enkele statussen die regis-

seur zelf zet en enkele generieke velden met afgesproken resultaten en tijden

- Per status een aantal standaardvelden en taken / vinkjes

- Etc.

O57 Uitzetten van taken

Beschrijf alle functionaliteiten op het gebied van uitzetten/verdelen van taken (in de vorm van

een deelzaak of evt. een los mailtje), die standaard onderdeel uitmaken van de 3D-Suite. Denk

hierbij aan:

Het meegeven van voor uitvoering van de taak noodzakelijke informatie. Het gaat hier om

(delen van) gegevens en het dossier (documenten). Dat betreft zowel informatie over het on-

dersteuningsplan als geheel, zodat voor iedere professional de context duidelijk is (integraal

werken), als informatie over de taak/taken.

Het meegeven van informatie over de uitvoering. M.a.w. de regisseur kan instruc-

ties/verzoeken/aandachtspunten meegeven over de afhandeling. Dat kan zowel gebaseerd

zijn op vooraf vastgestelde (contract) afspraken als op afspraken, die specifiek voor de case

gelden.

Het uitzetten van taken naar:

- de (professionele) ketenpartners

- de individuele burger

- het gezin

- relaties in het netwerk van de burger/ het gezin

Het uitzetten van taken op basis van relaties/afhankelijkheden, zoals vastgelegd in het On-

dersteuningsplan.

De mate waarin de 3D-Suite de mogelijkheid biedt om handmatig en bij voorkeur ook auto-

matisch een (vervolg)taak weg te zetten, zodra aan de voorwaarde is voldaan (bijvoorbeeld:

eerst moet een onderzoekstaak uitgevoerd worden, voordat een behandeltaak kan starten).

Dit kan ingeregeld worden, zodat het automatisch wordt uitgevoerd, maar de regisseur kan

ook kiezen voor een attendering (signaal), waarop hij zelf (handmatig) de behandeltaak door-

zet.

De wijze waarop taken worden uitgezet: bij voorkeur zowel via deelzaken (die parallel worden

uitgevoerd en separaat worden bewaakt) als in de vorm van een aparte status (seriële uit-

99

voer) binnen een zaak of deelzaak.

Het uitzetten van taken valt grotendeels samen met het geven van een opdracht om een indivi-

duele voorziening te leveren. Ook de fase „Toeleiding‟ uit het Bedrijfsfunctiemodel van IZO (zie

bijlage 1) valt hiermee min of meer samen. In de (huidige) praktijk selecteert de regisseur (sa-

men met de burger) de ondersteuner en die krijgt de opdracht/ de taak om de ondersteuning te

leveren volgens de voorwaarden uit het contract. Er dienen zich ook andere toewijzingsmethodes

aan. Eén van die methodes is het „Veilingmodel‟. Via aanbesteding worden vooraf alle mogelijke

ondersteuners via een raamcontract gecontracteerd. De individuele zorgvraag wordt anoniem ge-

publiceerd (op de veiling aangeboden), waarna de aangesloten ondersteuners een passende on-

dersteuning kunnen aanbieden. De beste ondersteuner mag de ondersteuning leveren. Er wordt

naast het algemene raamcontract per individu/ gezin een contract gesloten.

Beschrijf alle functionaliteiten op het gebied van uitzetten/verdelen van taken en geef daarbij aan

welke toewijzingsmethodes ondersteund worden. Ga daarbij expliciet in op de boven vermelde

„veilingmethode‟.

O58 Uitvoeren van taken

De uitvoering van taken vindt plaats in de eigen systemen van de uitvoerder. Het betreft dan een

deelzaak. Waar mogelijk worden gegevens/documenten uit die systemen automatisch doorgezet

naar de 3D-Suite. Het gaat om informatie, die bijdraagt het actueel en compleet houden van het

klantbeeld, die nodig is voor de regisseur in zijn regietaak en voor andere uitvoerende professio-

nals

Beschrijf alle functionaliteiten op het gebied van uitvoeren van taken, die standaard onderdeel

uitmaken van de 3D-Suite. Denk hierbij aan:

Toevoegen van gegevens over de deelzaak, zoals gewijzigde status, het resultaat, het besluit

Toevoegen van gegevens aan het klantbeeld/ -profiel. Voorbeeld: de uitvoering leidt tot ver-

betering van de situatie van de burger en (dus) tot een hogere score op de zelfredzaamheid-

matrix. Die „doorvertaling‟ zowel handmatig als geautomatiseerd uitgevoerd worden.

Toevoegen van documenten, waarbij tevens de autorisatie (voor wie toegankelijk) is geregeld

Toevoegen van notities, waarbij tevens de autorisatie (voor wie toegankelijk) is geregeld.

Hierbij kan men ook denken aan losse bevindingen c.q. kladnotities, die later verwerkt worden

in bijvoorbeeld rapportages.

Toevoegen van contact(notities). De 3D-Suite biedt functionaliteit voor het vastleggen van

notities n.a.v. telefonische c.q. fysieke contacten

Verzenden van berichten incl. notificatie.

Voorbeeld: in de uitvoering blijkt dat er extra gegevens van de burger nodig zijn. De professional

kan vanuit de taak direct een e-mail (brief) daaromtrent versturen of kan een attendering verstu-

ren. De burger kan dan via „Mijn omgeving‟ het verzoek/bericht inzien, waarna de burger bijvoor-

beeld aan de hand van een (deels vooringevuld) formulier de ontbrekende gegevens kan indie-

nen.

De genoemde functionaliteiten zullen gebruikt worden op het niveau van de taak, maar dienen op

het niveau van het Ondersteuningsplan of op het niveau van het individu of samenstel van indivi-

duen (gezin) beschikbaar te zijn. De essentie is dat informatie op het juiste niveau wordt gekop-

peld/opgeslagen.

100

O59 Signalering en bewaking

Bij het uitvoeren van de taak gaat het vooral om de inhoud. Er worden handelingen uitgevoerd,

die de burger verder (meer zelfredzaam) moeten brengen. Het gaat om kwaliteit (wordt het be-

oogde resultaat behaald volgens de gemaakte afspraken?) Goede afstemming en communicatie is

een vereiste. Naast kwaliteit speelt tijd een belangrijke rol. Beide moeten bewaakt worden, zowel

op taak- als op het ondersteuningsplan-niveau.

Beschrijf alle functionaliteiten op het gebied van bewaking en signalering, die standaard onderdeel

uitmaken van de 3D-Suite. Denk hierbij aan:

- Het automatisch vastleggen van alle acties incl. tijdstip tijdens de uitvoering van de deelzaak

- Het vastleggen van informatie op het juiste niveau (betreft het de burger, een specifiek be-

handeltraject / zaak, een maatregel / subzaak, etc). Het betreft de voortgang van het totale

ondersteuningsplan, maar ook de voortgang van een specifieke taak/actie voor een burger als

ook een gecombineerde set van acties voor een burger als ook acties voor een gezin. Kortom,

een ondersteuningsplan kan veel acties voor veel betrokkenen bevatten. Die acties (en het to-

tale ondersteuningsplan) dienen in verschillende combinaties bewaakt te kunnen worden.

- De mogelijkheid om percentage-gereed vast te leggen voor de realisatie van de acties (som-

mige acties lopende gedurende en aantal maanden en dan is soms zinvol te weten welke % de

actie gereed is).

- Signaleringen: ten minste van statuswijzigingen, nieuwe informatie / documenten en (dreigen-

de) overschrijding van norm- en streefdata en –termijnen.

▪ Beschrijf ook welke additionele informatie/ functionaliteit beschikbaar is. Bijvoorbeeld: indi-

catie met kleuren of anderszins. Standaard aanduiding/ presentatie van urgentie c.q. be-

lang.

▪ Beschrijf de functionaliteit voor het instellen wanneer een signaal moet worden afgegeven.

- Doorlooptijden (norm- en streefdata en –termijnen). De 3D-Suite biedt functionaliteit voor

termijnbewaking. Hierbij worden ten minste de volgende termijnen bewaakt: normtermijn.

Streeftermijn. Dat kan het gehele ondersteuningsplan betreffen of een actie of een individu of

een samenstel van individuen (een gezin) of een samenstel van acties.

- Reminders. De 3D-Suite biedt functionaliteit om een reminder te kunnen zetten. Daarbij kan

het „afgaan‟ van de reminder gezet worden op een bepaalde datum of na een bepaalde ter-

mijn. Het „afgaan‟ van de reminder veroorzaakt een notificatie. De reminder kan ook een korte

notitie bevatten, waardoor de regisseur/uitvoerder niet alleen tijdig wordt gesignaleerd, maar

ook input meekrijgt voor de te volgen actie.

- Bewaking op besluiten en resultaten. Zeker in multi-probleemsituaties en complexe trajecten

worden vele besluiten genomen en resultaten geboekt. Voor de regisseur, maar ook voor an-

dere professionals is het handig indien de besluiten en resultaten in samengevatte (liefst grafi-

sche) vorm toegankelijk zijn, Vanuit deze „samenvatting‟ kan dan worden doorgeklikt naar de

achterliggende informatie/stukken. Als denkrichting is hieronder een „Besluitenlijn‟ weergege-

ven.

101

- Het systeem dient de regisseur hierbij zo goed mogelijk te ondersteunen, bij voorkeur door per

doel te laten zien welke acties gereed zijn en in hoeverre de afgesproken (wellicht bijgestelde)

doelen gerealiseerd zijn (bijv. „zelfredzaamheid inkomen is op het afgesproken niveau‟).

- Kwaliteit betreft enerzijds de kwaliteit van het proces, m.a.w. is de afhandeling volgens de

procedures verlopen. Voor overheidsorganisaties is de rechtmatigheid een belangrijk aspect in

de kwaliteit. Anderzijds staat de vraag centraal of de resultaten behaald zijn en de doelen be-

reikt. Beschrijf de functionaliteit die de kwaliteitsbewaking van zowel het proces als van de

outcome ondersteunt.

- Acties (Meldingen kunnen als ad hoc acties gezien worden. Bijvoorbeeld: een regisseur kan

vanuit zijn (frequente) contact met de burger een melding doorzetten naar één van de profes-

sionals om bijvoorbeeld de taakuitvoering op te schorten vanwege gewijzigde omstandighe-

den)

O60 Ketenberichten

In de keten van de uitvoering (van plan t/m nazorg) vinden veel berichten plaats. Taken worden

uitgezet. Statusberichten worden handmatig of automatisch uit backofficesystemen naar de 3D-

suite teruggekoppeld. Ook het terugkoppelen van resultaten en financiële gegevens is gewenst.

Beschrijf de wijze waarop ketenberichtenverkeer plaatsvindt en de mate waarop dit geautomati-

seerd plaatsvindt. Ga daarbij vooral in op de automatische uitwisseling (via lees- en/of schrijfkop-

pelingen) tussen de 3D-suite en backofficesystemen van ondersteuners, aanvullend aan mogelijk-

heden voor uitvoeringsorganisaties om (ook) handmatig statussen en %-gereed te zetten.

Beschrijf ook welke standaarden in berichtenverkeer ondersteund wordt. Bijvoorbeeld: StUF-

zaken, AZR, e.d. Zie ook hoofdstuk 7.

5.4.5 Procesbewaking/evaluatie/nazorg

O61 Evaluatie

Evaluatie kan ook als een vorm van kwaliteitsbewaking gezien worden. Het is een eindcontrole op

het totale Ondersteuningsplan, waarin een aantal aspecten gemonitord worden. Beschrijf alle

functionaliteiten op het gebied van evaluatie, die standaard onderdeel uitmaken van de 3D-Suite.

Denk hierbij aan:

- De inzet van de zelfredzaamheidmatrix (incl. doorvertaling naar het klantprofiel)

- Inzet van klanttevredenheidsonderzoek. Hierbij kan ook sprake zijn van onderzoeken (vragen-

102

lijsten) van externe partijen. De uitkomsten van onderzoeken dienen (rekening houdend met

autorisatie en privacy) toegevoegd worden aan het Ondersteuningsplan.

- Input van de ondersteuners en andere betrokkenen

- Gespreksverslagen

- Gestructureerd vastleggen van informatie. De kern is een goede afronding van het individuele

Ondersteuningsplan. Door een juiste opzet en waar mogelijk gebruik te maken van gestructu-

reerde informatie wordt een goede basis voor managementinformatie gelegd.

Adequate en gerichte informatie kan opgedaan worden door meer continu te monitoren. Al de

metingen en meningen bij elkaar opgeteld geven een beter beeld van het totale proces, de (kwali-

teit van) afzonderlijke taken, acties, contacten en communicatie.

Beschrijf alle functionaliteiten op het gebied van continue monitoring, die standaard onderdeel

uitmaken van de 3D-Suite.

O62 Nazorg

Beschrijf alle functionaliteiten op het gebied van nazorg, die standaard onderdeel uitmaken van

de 3D-Suite. Denk hierbij aan:

De relatie met het afgeronde ondersteuningsplan

Latere signaleringen relateren aan eerdere ondersteuningsplannen

Op door de regisseur te bepalen intervallen een bezoek door regisseur of wijkteam inplannen

Etc.

103

5.5 Regie op regie (budget, contract, kwali-teit, etc.)

Onder „Regie op regie‟ verstaan we hier het sturen op doeltreffendheid met als twee subdoelen: het

sturen op effectiviteit van handelen (best practices/ wijkaanpak, doelgroepaanpak) en het sturen

op resultaat (gemaakte afspraken met externe partners, maar ook op de beweging van intensieve

naar eenvoudige ondersteuning naar zelf doen). Daarnaast gaat het om sturen op efficiency (bud-

getten/ realisatie). Het betreft hier dus niet het regisseren van de ondersteuning van individuele

burgers dan wel een gezin. Zie ook par. 2.5.

Sturingsinformatie is van belang voor de regisseur maar ook voor beleidsmedewerkers.

Hieronder is een aantal voorbeeld opgenomen van het soort sturingsinformatie dat geleverd moet

worden. [Deze opsomming is niet limitatief en zal nader met de opdrachtgever uitgewerkt moeten

worden, bij voorkeur zo veel mogelijk vóór aanvang van een selectietraject. Waar dit later gebeurt,

zullen de deliverables helder moeten zijn, teneinde de hoeveelheid meerwerkkosten te minimalise-

ren.]

De informatie die zoveel mogelijk grafisch weergegeven zou moeten worden:

- Overzichten per straat, buurt, wijk, dorp, gemeente van:

o Ondersteuningsvragen

o Ingezette ondersteuningsacties

o % gerealiseerde doelen per gezin

o Zelfredzaaamheid per domein

o Wijzigingen op zelfredzaaamheid per domein

- Effectiviteit per leverancier

o Per leverancier % gerealiseerde doelen,

o Per leverancier % doelen gereed binnen termijn

o % activiteiten gerealiseerd binnen termijn

- Trends in de tijd (maand, kwartaal, jaar) per wijk, leverancier, etc., op:

o Soorten ondersteuningsvragen van klanten

o Ingezette soort ondersteuning

o Gerealiseerde kosten

- Financiële rapportages

o Gerealiseerde kosten per straat, buurt, wijk, dorp, gemeente. Per periode (maand,

kwartaal, jaar)

o Gerealiseerde kosten per periode per leverancier

o Kosten per gezin per periode

o Kosten per type doelstelling (gerelateerd aan Zelfredzaamheidsmatrix)

o Kosten per type ondersteuningvraag

O63 Sturingsinformatie

Beschrijf op welke wijze de 3D-suite basisgegevens aandraagt voor de bovengenoemde sturings-

informatie.

Schenk daarbij vooral aandacht aan de mate waarin het merendeel van de gegevens tot stand

komen in de uitvoering, m.a.w. er behoeft niet/nauwelijks apart gegevens toegevoegd te worden

t.b.v. de sturing op tactische of strategisch niveau.

Maak onderscheid tussen:

104

- een door de gemeente aanpasbare/parameteriseerbare basisset van relevante rapportages,

geef een lijst van rapportages die u gegeven het in par. 2.5 geschetste gebruik aanbiedt

- de mate waarin tevens meer ad-hoc vragen worden ondersteund, zoals informatie t.b.v. ge-

meenteraad of tweede kamer: gebeurt dat binnen uw suite of via een BI-tool?

O64 Aansturing teams

Beschrijf op welke wijze de 3D-suite ondersteuning biedt voor operationele en/of strategische

aansturing en regie van/over wijkteams of andere groepen regisseurs (bijv. door een

wijkmanager), aanvullend aan de casusoverleggen als beschreven in O3 op blz. 45.

Denk daarbij aan aanvullende teamoverleg- en sturingsfunctionaliteit maar ook aan (bij voorkeur

interactieve) rapportages zoals

- (Wijk)budget in Euro en uitputting daarvan over de tijd

- (Wijk)budget in besteedbare uren en uitputting daarvan over de tijd

- Bewaken resultaten per wijk, per gemeente: zowel financieel als inhoudelijk (gehaalde doelen,

etc.)

- Kosten (in euro en uren) van regie

- Bewaken caseloads per regisseur, per groep, etc.

Beschrijf tevens in welke mate de 3D-suite ondersteuning biedt aan forecasting, zowel v.w.b.

budgetten als workloads . Wat valt de komende tijd te verwachten, waar dient de regisseur reke-

ning mee te houden?

105

5.6 Standaardcontent

Voor standaardcontent zou er idealiter landelijk beheerde content moeten komen zoals nu

bijvoorbeeld door Stichting opvoeden.nl wordt opgesteld. Voor het hele sociale domein zou

dergelijke content moeten komen in een format welke in elke gemeentelijke website is in te lezen.

Te denken valt aan informatie over mantelzorg, ouders van licht verstandelijk gehandicapten,

psychogeriatrie, jeugd GGZ, etc. Deze aanpak is financieel aantrekkelijk voor de gemeenten omdat

de content maar op een plek ontwikkeld en actueel gehouden hoeft te worden (vergelijk de

gemeentelijke PDC-contentabonnementen nu). Tevens is er het voordeel dat het niet uitmaakt

waar de burger ook zoekt, iedere keer de burger bij de zelfde informatie uitkomt (ongeacht

gemeente en/of kanaal). Daarmee waarborgt de gemeente de betrouwbaarheid van de informatie

die ze aan de burger beschikbaar stelt.

O65 Standaardcontent

Geef aan of de 3D-Suite geleverd worden met standaardcontent en - zo ja - beschrijf deze. Geef

daarbij steeds duidelijk aan welke informatie beschikbaar is en in welke mate deze aanpasbaar is.

Denk in dat kader bijvoorbeeld aan:

- Standaard zaaktypen, processen: zowel v.w.b. primaire functies (ondersteuningsplan, uitzetten

vak taken, etc.) als secundaire functies zoals mandatering

- Meegeleverde vraaggeleiding / beslisbomen

- Meegeleverde informatie over producten / diensten (zoals wanneer en voor wie van toepas-

sing, procedurebeschrijvingen, eventuele benodigde informatie en/of bescheiden, van toepas-

sing zijnde wet- en regelgeving, relevante termijnen en dergelijke)

- Meegeleverde veelgestelde vragen (FAQ‟s)

- Meegeleverde sociale kaart(en)

Maak daarbij onderscheid tussen door Contractant in eigen beheer ontwikkelde en onderhouden

content, en het standaard mee kunnen leveren van eventuele landelijk ontwikkelde en beheerde

content op het gebied van 3D.

O66 Gebruik van de facto content

Geef aan of de 3D-Suite gebruik maakt van/ een integratie/ koppeling heeft met standaardcontent

van content leveranciers, zoals bijv:

- Content van Regelhulp

- Thesaurus zorg en welzijn

- Of andere bronnen, die in het sociale domein veelvuldig gebruikt worden.

Geef tevens aan in welke mate gemeenten deze content op fijnmazige onderdelen aan kan passen

zonder dat nieuwe versies van de content leverancier deze aanpassingen overschrijven.

O67 Import en export van klantendossiers

Wanneer een burger naar de gemeente verhuist is het denkbaar dat –wetgeving, privacy en

beveiliging in acht nemende– delen van klantdossiers van de andere gemeente geïmporteerd

106

kunnen worden. Beschrijf daartoe in welke mate (en o.b.v. welke standaarden: bijvoorkeur StUF-

Zaken en/of de Zaak-DMS-services 14) gestructureerde en ongestructureerde gegevens en

documenten kunnen worden geïmporteerd door een functioneel beheerder of regisseur.

Geef tevens aan in welke mate een regisseur wordt ondersteund bij het maken van een export

van een klantdossier, incl. selectie van privacygevoelige informatie, anonimiseren waar nodig of

mogelijk, en het evt. vervangen van „wat‟-informatie door „dat‟.

14 Zie ook https://new.kinggemeenten.nl/gemma/stuf/koppelvlakken/zs-dms

107

6 PvE: Gebruiksvriendelijkheid

Deze en de volgende hoofdstukken met eisen en wensen betreffen het geheel van generieke

functionaliteit (hoofdstuk 4) inclusief specifieke inrichting daarvan (hoofdstuk 5).

E8 Gebruiksvriendelijkheid: Nederlandstalig

Alle gebruikersinterfaces (incl. schermen, foutboodschappen, helpteksten, etc.) van de 3D-Suite

voor eindgebruikers en functioneel beheerders zijn volledig Nederlandstalig.

NB: De term „eindgebruiker‟ heeft hier betrekking op medewerkers van Gemeente (uitgezonderd

functioneel beheerders) en van daartoe geautoriseerde derden bij uitvoeringsorganisaties / ke-

tenpartners.

O68 Gebruiksvriendelijkheid: burgers

Beschrijf (incl. schermafbeeldingen) de gebruiksvriendelijkheid van alle browser- en eventuele

overige grafische interfaces van de 3D-Suite t.b.v. burgers voor wat betreft:

- Intuïtiviteit en consistentie van (de structuur van) de user interface (incl. de mate waarin tab-

volgorde consequent is doorgevoerd), navigatie, (context)menu‟s, toetsenbordgebruik, datum-

notatie, verplichte elementen, look & feel, etc. Beschrijf daarbij tevens in welke mate scher-

men als (proces)stappen met een logische bundeling/opeenvolging van handelingen worden

gepresenteerd, incl. de mogelijkheid om de functionaliteiten zoals beschreven in de verschil-

lende keten use cases te combineren resp. sequentieel uit te voeren.

- Schermindeling, inclusief minimale en maximale schermgrootte en resolutie.

- Helpfuncties en -teksten (on-/offline, contextgevoelig, taal, beschikbaarheid van mouse-overs,

etc.), incl. de wijze waarop foutboodschappen worden weergegeven (zoals: al dan niet voor-

zien van datum / tijd en het onderdeel waarop ze betrekking hebben, indicaties m.b.t. de ernst

van de fout, een - ook voor niet technisch onderlegde mensen begrijpelijke - inhoudelijke be-

schrijving, etc.).

- Het ongedaan maken (undo) van handelingen, incl. voor hoeveel en welke handelingen dit

kan.

- Inzicht in autorisatierestricties (zoals het verbergen/”uitgrijzen” van knoppen, tabs, menu‟s,

etc.).

- Het markeren van verplichten velden / handelingen (zoals met kleuren, symbolen, etc.).

- De mate waarin ze voldoen aan de Webrichtlijnen (v2.0), Drempels Weg, de W3C Richtlijnen

Toegankelijkheid (WCAG 2.0), etc.

▪ Mogelijkheden m.b.t. personalisatie (aanpasbaarheid van look & feel van interfaces), zoals:

▪ Huisstijl, stylesheets, logo‟s en dergelijke.

▪ Kleurgebruik, fontgrootte, contrast, resolutie en dergelijke.

▪ Indeling (navigatie, menu‟s, knoppen, tabbladen, vensters, etc.).

▪ Snelkoppelingen (vgl. „favorieten‟) en soortgelijke functies.

▪ Help- en andere teksten.

Beschrijf daarbij ook op welke wijze e.e.a. generiek (voor alle burgers) en/of specifiek (door indi-

viduele burgers) aanpasbaar is, alsmede of aanpassingen intact blijven na uit-/inloggen en bij

Nieuwe en Verbeterde Versies van de 3D-Suite.

Beschrijf (incl. schermafbeeldingen) ten slotte de mate waarin de 3D-Suite de burger ondersteunt

t.a.v. gegevensregistratie, behandeling van eigen taken/zaken, beslisbomen en controlelijsten,

informatie-/kennisbronnen, etc.

108

NB: De term “burger” heeft hier betrekking op zowel cliënten, als bewindvoerders, familieleden en

anderen die eventueel toegang hebben tot de 3D-Suite.

O69 Gebruiksvriendelijkheid: medewerkers

Beschrijf (incl. schermafbeeldingen) de gebruiksvriendelijkheid van alle browser- en eventuele

overige grafische interfaces van de 3D-Suite t.b.v. gebruikers voor wat betreft:

- Intuïtiviteit en consistentie van (de structuur van) de user interface (incl. de mate waarin tab-

volgorde consequent is doorgevoerd), navigatie, (context)menu‟s, toetsenbordgebruik, datum-

notatie, verplichte elementen, look & feel, etc. Beschrijf daarbij tevens in welke mate scher-

men als (proces)stappen met een logische bundeling/opeenvolging van handelingen worden

gepresenteerd, incl. de mogelijkheid om de functionaliteiten zoals beschreven in de verschil-

lende keten use cases te combineren resp. sequentieel uit te voeren.

- Schermindeling, inclusief minimale en maximale schermgrootte en resolutie.

- Toetsenbordgebruik (zoals control- en altfuncties, shortcuts, tabgebruik, functietoetsen, etc.),

incl. de mate waarin de 3D-Suite desgewenst geheel met het toetsenbord bediend kan worden.

- Helpfuncties en -teksten (on-/offline, contextgevoelig, taal, beschikbaarheid van mouse-overs,

etc.), incl. de wijze waarop foutboodschappen worden weergegevens (zoals: al dan niet voor-

zien van datum / tijd en het onderdeel waarop ze betrekking hebben, indicaties m.b.t. de ernst

van de fout, een - ook voor niet technisch onderlegde mensen begrijpelijke - inhoudelijke be-

schrijving, etc.).

- Het ongedaan maken (undo) van handelingen, incl. voor hoeveel en welke handelingen dit

kan.

- Inzicht in autorisatierestricties (zoals het verbergen/”uitgrijzen” van knoppen, tabs, menu‟s,

etc.).

- Het markeren van verplichten velden / handelingen (zoals met kleuren, symbolen, etc.).

- De mate waarin ze voldoen aan de Webrichtlijnen (v2.0), Drempels Weg, de W3C Richtlijnen

Toegankelijkheid (WCAG 2.0), etc.

▪ Mogelijkheden m.b.t. personalisatie (aanpasbaarheid van look & feel van interfaces), zoals:

▪ Huisstijl, stylesheets, logo‟s en dergelijke.

▪ Kleurgebruik, fontgrootte, contrast, resolutie en dergelijke.

▪ Indeling (navigatie, menu‟s, knoppen, tabbladen, vensters, etc.).

▪ Snelkoppelingen (vgl. „favorieten‟) en soortgelijke functies.

▪ Help- en andere teksten.

Beschrijf daarbij ook op welke wijze e.e.a. generiek (voor alle gebruikers) en/of specifiek (door

individuele gebruikers) aanpasbaar is, alsmede of aanpassingen intact blijven na uit-/inloggen en

bij Nieuwe en Verbeterde Versies van de 3D-Suite.

Beschrijf (incl. schermafbeeldingen) tenslotte de mate waarin de 3D-Suite de gebruikers

ondersteunt t.a.v. gegevensregistratie, zaakbeheer en –behandeling, documentcreatie,

(management)rapportage, beslisbomen en controlelijsten, informatie-/kennisbronnen, etc.

NB: De term “gebruiker” heeft hier betrekking op medewerkers van Gemeenten en ketenpartners

(uitgezonderd functioneel en technisch beheerders).

O70 Gebruiksvriendelijkheid: functioneel beheerders

Beschrijf (incl. schermafbeeldingen) de gebruiksvriendelijkheid van alle browser-, grafische en

109

command line interfaces van de 3D-Suite t.b.v. functioneel beheerders voor wat betreft:

- Intuïtiviteit en consistentie van (de structuur van) de user interface (incl. de mate waarin tab-

volgorde consequent is doorgevoerd), navigatie, (context)menu‟s, toetsenbordgebruik, datum-

notatie, verplichte elementen, look & feel, etc. Beschrijf daarbij tevens in welke mate scher-

men als (proces)stappen met een logische bundeling/opeenvolging van handelingen worden

gepresenteerd, incl. de mogelijkheid om de functionaliteiten zoals beschreven in de verschil-

lende keten use cases te combineren resp. sequentieel uit te voeren.

- Schermindeling, inclusief minimale en maximale schermgrootte en resolutie.

- Toetsenbordgebruik (zoals control- en altfuncties, shortcuts, tabgebruik, functietoetsen, etc.),

incl. de mate waarin de 3D-Suite desgewenst geheel met het toetsenbord bediend kan worden.

- Helpfuncties en -teksten (on-/offline, contextgevoelig, taal, beschikbaarheid van mouse-overs,

etc.), incl. de wijze waarop foutboodschappen worden weergegeven (zoals: al dan niet voor-

zien van datum / tijd en het onderdeel waarop ze betrekking hebben, indicaties m.b.t. de ernst

van de fout, een - ook voor niet technisch onderlegde mensen begrijpelijke - inhoudelijke be-

schrijving, etc.).

- Het ongedaan maken (undo) van handelingen, incl. voor hoeveel en welke handelingen dit

kan.

- Inzicht in autorisatierestricties (zoals het verbergen/”uitgrijzen” van knoppen, tabs, menu‟s,

etc.).

- Het markeren van verplichten velden / handelingen (zoals met kleuren, symbolen, etc.).

- De mate waarin ze voldoen aan de Webrichtlijnen (versie 1.3 / 2.0), Drempels Weg, de W3C

Richtlijnen Toegankelijkheid (WCAG 2.0), etc.

▪ Mogelijkheden m.b.t. personalisatie (aanpasbaarheid van look & feel van interfaces), zoals:

▪ Huisstijl, stylesheets, logo‟s en dergelijke.

▪ Kleurgebruik, fontgrootte, contrast, resolutie en dergelijke.

▪ Indeling (navigatie, menu‟s, knoppen, tabbladen, vensters, etc.).

▪ Snelkoppelingen (vgl. „favorieten‟) en soortgelijke functies.

▪ Help- en andere teksten.

Beschrijf daarbij ook op welke wijze e.e.a. generiek (voor alle gebruikers) en/of specifiek (door

individuele gebruikers) aanpasbaar is, alsmede of aanpassingen intact blijven na uit-/inloggen en

bij Nieuwe en Verbeterde Versies van de 3D-Suite.

Beschrijf (incl. schermafbeeldingen) tenslotte - aan de hand van concrete voorbeelden - de mate

waarin de 3D-Suite functioneel beheerders ondersteunt t.a.v. de functionele beheeraspecten zoals

gevraagd in dit document.

O71 [Gebruiksvriendelijkheid: technisch beheerders]

Beschrijf (incl. schermafbeeldingen) de gebruiksvriendelijkheid van alle browser-, grafische en

command line interfaces van de 3D-Suite t.b.v. technisch beheerders voor wat betreft:

- Intuïtiviteit en consistentie van (de structuur van) de user interface (incl. de mate waarin tab-

volgorde consequent is doorgevoerd), navigatie, (context)menu‟s, toetsenbordgebruik, datum-

notatie, verplichte elementen, look & feel, etc. Beschrijf daarbij tevens in welke mate scher-

men als (proces)stappen met een logische bundeling/opeenvolging van handelingen worden

gepresenteerd, incl. de mogelijkheid om de functionaliteiten zoals beschreven in de verschil-

lende keten use cases te combineren resp. sequentieel uit te voeren.

110

- Schermindeling, inclusief minimale en maximale schermgrootte en resolutie.

- Toetsenbordgebruik (zoals control- en altfuncties, shortcuts, tabgebruik, functietoetsen, etc.),

incl. de mate waarin de 3D-Suite desgewenst geheel met het toetsenbord bediend kan worden.

- Helpfuncties en -teksten (on-/offline, contextgevoelig, taal, beschikbaarheid van mouse-overs,

etc.), incl. de wijze waarop foutboodschappen worden weergegeven (zoals: al dan niet voor-

zien van datum / tijd en het onderdeel waarop ze betrekking hebben, indicaties m.b.t. de ernst

van de fout, een - ook voor niet technisch onderlegde mensen begrijpelijke - inhoudelijke be-

schrijving, etc.).

- Het ongedaan maken („undo‟) van handelingen, incl. voor hoeveel en welke handelingen dit

kan.

- Inzicht in autorisatierestricties (zoals het verbergen/”uitgrijzen” van knoppen, tabs, menu‟s,

etc.).

- Het markeren van verplichten velden / handelingen (zoals met kleuren, symbolen, etc.).

Beschrijf (incl. schermafbeeldingen) tenslotte - aan de hand van concrete voorbeelden - de mate

waarin de 3D-Suite technisch beheerders ondersteunt t.a.v. de technische beheeraspecten.

O72 Gebruik van tablets en mobile devices

Beschrijf de mate waarin er beperkingen en/of juist aanvullende functionaliteiten zijn in gebruik

van het systeem via mobiele devices (tablets / smartphones). Denk bijvoorbeeld aan het gebruik

van responsive design (waarbij weergave en functionaliteit aangepast worden aan het device),

het wel of niet downloaden en toevoegen van documenten, afhankelijkheden van 3G / mobiele

ontvangst (en de consequenties van het wegvallen van de verbinding), etc.

Beschrijf tevens de eventuele impact op beveiliging bij gebruik via mobiele apparaten, zoals

v.w.b. encryptie en verlies van apparatuur.

Maak waar nodig onderscheid per rol (burger, regisseur, etc.).

O73 Visie op minimalisering administratieve lasten

We realiseren ons dat we veel functionaliteiten uitvragen. Het gebruiksgemak voor de burger,

maar ook de professional is zeer belangrijk. De administratieve lastenverlichting voor de regisseur

is daarbij ook van groot belang. Deze zal bij voorkeur zo weinig mogelijk registreren „om het

registreren‟, zoveel mogelijk t.b.v. regie-op-regie of anderszins benodigde informatie wordt vanuit

het proces gevormd. Er zal zodoende een afweging tussen functionaliteit (bijv.: veel informatie

uitvragen t.b.v. rijke managementinformatie) en gebruiksgemak gemaakt kunnen worden.

Geef in dat kader uw visie op de wijze waarop en de mate waarin uw 3D-Suite de administratieve

lasten voor regisseur, wijkteam, overige medewerkers en voor de burger kan minimaliseren -

terwijl wel de ondersteuning kan worden geleverd en de horizontale en verticale verantwoording

(rapportages aan o.a. gemeenteraad resp. ministeries) kan worden gegeven.

111

7 PvE: Integratie

7.1 Inleiding

Bij koppelingen tussen systemen dient onderscheid gemaakt te worden tussen schrijven (van 3D-

Suite naar derde applicatie, of andersom) en lezen van bronnen naar de 3D-Suite. Bij voorkeur

wordt voor koppelingen gebruik gemaakt van open standaarden i.c.m. reeds aanwezige API‟s 15

van de betreffende te koppelen systemen. We spreken van een “betonnen vrouwtje” als de

specificaties van het externe koppelvlak een gegeven zijn, zoals bv bij landelijke voorzieningen.

Echter bestaat niet in alle gevallen een dergelijk „mooi‟ koppelvlak en soms moeten koppelvlakken

met systemen nog gedefinieerd worden. V.w.b. leeskoppelingen, kan dan worden volstaan met het

uitlezen van de database, rekening houdend met evt. autorisaties.

Bij schrijfkoppelingen dient altijd een API te worden gebruikt i.v.m. de business rules van het

ontvangende systeem. Waar dat niet mogelijk is, zal moeten worden “gekloppeld”: overtypen van

informatie, bijv. n.a.v. een attenderingsmailtje aan de gebruiker van het te koppelen systeem.

Voordat een concrete implementatie wordt voorbereid, kan voor een specifieke gemeente worden

onderzocht welke koppelvlakken wel/niet aanwezig zijn en welke informatie nodig én beschikbaar

is. Dit betreft zowel koppelen binnen de gemeentelijke firewall, als bijv. met ketenpartners.

Er zal bijv. onderzocht moeten worden in welke mate het koppelen met basisregistraties mogelijk is

i.r.t doelbinding: bijv. bij een WMO-aanvraag is er geen wettelijke basis om Suwinet te bevragen.

Dan is alsnog een koppeling met de GBA/burgerzakenmodule nodig, nog steeds incl. bewaking van

de doelbinding. Een gemeente wil wellicht ook koppelen met gemeentelijke belastingen

(openstaande betalingen), de basisadministratie adressen en gebouwen (“we zien 12 mensen op

50 m2”), etc.

Er komen daarnaast mettertijd wellicht meer landelijke knooppunten die kunnen worden gebruikt

om het aantal koppelvlakken te minimaliseren, doch daar is nu nog niets over te zeggen v.w.b.

inhoud, timing, of techniek.

Er wordt vaak verwezen naar een [bijlage XX] of vergelijkbaar. Iedere gemeente heeft eigen

applicaties met elk andere koppelmogelijkheden. Het is van belang dat bij een eventuele

aanbesteding helder en correct wordt omschreven welke API‟s en welke berichten mogelijk zijn, om

te voorkomen dat de verschillende betrokken partijen (leverancier van “mannetje”, leverancier van

“vrouwtje” en de gemeente) allen naar elkaar gaan wijzen.

In alle gevallen is het bijwerken van de koppelvlakken in de tijd onderdeel van het geleverde

Onderhoud.

[[Verzoek aan gemeenten: maak bij voorkeur gebruik van de KING softwarecatalogus. Hierin kun-

nen gemeenten per referentie componenten aangeven met welke software ze deze invullen en zien

welke standaarden daarmee ondersteund worden. Indien er dan in de praktijk problemen komen

kunnen leveranciers via het convenant van operatie nup er op aangesproken worden alsnog te vol-

doen aan de betreffende standaarden.]]

15 API: Application Progamming Interface, koppelvlak waarmee kan worden gekoppeld met de be-

treffende applicatie.

112

7.2 Interne integratie

Deze paragraaf betreft de koppeling tussen de 3D-Suite en een reeds aanwezig (3P) generiek

zaaksysteem / documentmanagementsysteem (DMS) t.b.v. documentopslag (zogeheten

documentenkoppeling). E.e.a. dient nadrukkelijk als voorbeeld en zal t.z.t aangepast (of

weggelaten) moeten worden al naar gelang de betreffende specifieke voorkeuren en

mogelijkheden.

[NB Er wordt veelal bewust in het midden gelaten of, en zo ja hoe, gegevens al dan niet naar het

gegevensmagazijn van de 3D-Suite gerepliceerd worden dan wel op het moment dat ze nodig zijn

uit het gekoppelde systeem worden “opgehaald” (voor zover de betreffende bron dit toelaat),

bijvoorbeeld via een rechtstreekse koppeling of via het gegevensdistributiesysteem. Een en ander

hangt o.a. af van de mogelijkheden van de te koppelen applicatie.]

G23 [Koppeling met [zaaksysteem/DMS]: documentenkoppeling (basisfunctionaliteit)]

De 3D-Suite integreert v.w.b. documentopslag op dusdanige wijze met het [zaaksysteem/DMS]

van Gemeente ([merk, type, versie]) dat alle functionaliteiten en berichten als beschreven in de

specificaties van het betreffende „vrouwtje‟ in bijlage [XX] volledig worden ondersteund (voor zo-

ver van toepassing realtime (i.t.t. batch) en zowel lezen als schrijven).

Hierbij wordt het ZK-DMS koppelvlak ondersteund.16

O74 [Koppeling met [zaaksysteem/DMS]: documentenkoppeling (beheer)]

Bij voorkeur is het [DMS/Zaaksysteem] gebruikt als een „domme opslagdoos‟ waarbij inrichting en

beheer volledig vanuit de 3D-Suite plaatsvinden, incl. bijbehorende autorisaties.

Beschrijf de mate van integratie m.b.t. het beheer van de 3D-Suite en het [zaaksysteem/DMS]

van Gemeente t.a.v. (de inrichting van) documentopslag, gezien vanuit de functioneel beheerder.

Geef tevens aan in welke mate het ZK-DMS koppelvlak wordt ondersteund.

Ga expliciet in op de wijze waarop veilige opslag en beheer wordt gegarandeerd, incl. authentica-

tie/autorisaties/beveiliging per persoon die een document via de 3D-Suite of direct via het DMS

opvraagt of aanpast.

Beschrijf daarnaast ten minste in hoeverre en op welke wijze sprake is van volledig enkelvoudig

beheer van de 3D-Suite en het [zaaksysteem/DMS] d.m.v. de beheeromgeving van de 3D-Suite,

incl. de inrichting van documentopslag in het [zaaksysteem/DMS]. Beschrijf in dat kader expliciet

wat er daartoe in de 3D-Suite resp. het [zaaksysteem/DMS] dient te worden ingericht, incl. de

(on)mogelijkheid om buiten de beheeromgeving van de 3D-Suite om de inrichting van het [zaak-

systeem/DMS] v.w.b. documentopslag aan te passen.

Indien geen sprake is van volledig enkelvoudig beheer, beschrijf hoe de inrichting van beide sys-

temen gelijk wordt getrokken en welke beheertaken dubbel moeten worden uitgevoerd. Ga daar-

bij ten minste in op de synchronisatie tussen de beheeromgeving van de 3D-Suite en (de ZTC /

het DSP van) het [zaaksysteem/DMS], incl. alle metadata (zoals „zaaktypekenmerken‟ en bijbeho-

rende zaak-, dossier- en proceskenmerken), incl. bijbehorende autorisaties (rechten en rollen) en

bewaar- en vernietigingstermijnen.

Beschrijf voor elk van beide gevallen ten minste wat er precies wanneer en hoe wordt uitgewis-

16 Dit koppelvlak is ontwikkeld in samenwerking met operatie NUP. Zie ook htt-

ps://new.kinggemeenten.nl/gemma/stuf/koppelvlakken/zs-dms

113

seld tussen de 3D-Suite en het [zaaksysteem/DMS]. Beschrijf daarbij ook of veranderingen in (de

configuratie van) de 3D-Suite realtime doorwerken in het [zaaksysteem / DMS] en vice versa, in-

cl. of daarbij validaties (van het de 3D-Suite resp. het [zaaksysteem/DMS]) t.b.v. de integriteit

van configuraties en andere inrichtingen actief zijn en zo ja welke.

G24 Koppeling met sjabloontoepassing (basisfunctionaliteit)

G24.1

De 3D-Suite integreert op dusdanige wijze met de sjabloontoepassing van Gemeente ([merk, ty-

pe, versie]) dat alle functionaliteiten en berichten als beschreven in de specificaties van het be-

treffende „vrouwtje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing real-

time (i.t.t. batch) en zowel lezen als schrijven).

G24.2

Dit geldt zowel vanaf locatie van Gemeente, als daarbuiten. [[afhankelijk van de mogelijkheden

van de sjablonentool, als dit niet volledig webbased is dan wil je misschien géén sjablonentool ge-

bruiken]]

G24.3

[D.w.z. dat ten minste (doch niet noodzakelijkerwijs uitsluitend) [voor zover van toepassing real-

time en volledig geautomatiseerd] [aandachtspunten o.b.v. de specificaties van het betreffende

„vrouwtje‟ in bijlage [XX]]].

S21. Koppeling met agendasysteem (basisfunctionaliteit) ([lezen] [en] [schrijven])

De 3D-Suite integreert op dusdanige wijze met het agendasysteem van Gemeente ([merk, type,

versie]) dat afspraken kunnen worden gemaakt in de 3D-Suite [én door de clientside applicatie

[naam, versie] (er wordt dus direct gecommuniceerd met de server van de Gemeente en niet de

clientside applicatie)] / [die inzichtelijk zijn in de clientside applicatie [naam, versie]].

G25 Koppeling met financieel systeem (basisfunctionaliteit) (lezen en schrijven)

G25.1

De 3D-Suite integreert op dusdanige wijze met het financiële systeem van Gemeente ([merk, ty-

pe, versie]) dat alle functionaliteiten en berichten als beschreven in de specificaties van het be-

treffende „vrouwtje‟ in bijlage [XX enkel relevante berichten opgeven! Bijv. journaalposten XX]

volledig worden ondersteund (voor zover van toepassing realtime en zowel lezen als schrijven).

G25.2

Het recht op betalingen kan vastgelegd worden met besluiten. Voor het genereren van een over-

zicht van aan te maken boekingen kan het financiële systeem via live databasetoegang met lees-

rechten de benodigde gegevens uitvragen.

G25.3

D.w.z. dat ten minste (doch niet noodzakelijkerwijs uitsluitend) [voor zover van toepassing real-

time en volledig geautomatiseerd] [aandachtspunten o.b.v. de specificaties van het betreffende

„vrouwtje‟ in bijlage [XX]].

S22. Koppeling met directory server (basisfunctionaliteit) (lezen)

De 3D-Suite integreert op dusdanige wijze met de directory server van Gemeente ([merk, type,

114

versie]) dat alle functionaliteiten en berichten als beschreven in de specificaties van het betref-

fende „vrouwtje‟ in bijlage [XX] volledig worden ondersteund (realtime en zowel lezen als schrij-

ven).

De 3D-Suite integreert met de directory server van de Gemeente zodanig dat alle gebrui-

kers/wachtwoorden van interne medewerkers van de Gemeente worden geverifieerd door de Di-

rectory server en dat alle rollen die binnen de 3D-Suite worden gebruikt voor authenticatie en au-

torisatie gekoppeld kunnen worden aan één of meer groepen uit de centrale directory server van

de Gemeente.

G26 [Koppeling met Klantcontactsysteem] [[Alternatief is dat het KCC direct de 3D-

Suite gebruikt]] (lezen en schrijven)

De 3D-Suite integreert op dusdanige wijze met het klantcontactsysteem van de Gemeente

([merk, type, versie]) dat alle functionaliteiten en berichten als beschreven in de specificaties van

het betreffende „vrouwtje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing

realtime en zowel lezen als schrijven).

[D.w.z. dat ten minste (doch niet noodzakelijkerwijs uitsluitend) [voor zover van toepassing real-

time en volledig geautomatiseerd]

- signaleringen die bij het KCS binnenkomen kunnen worden doorgegeven aan de 3D-Suite

(schrijven)

- klantcontacten (telefoon, e-mails, anders) die bij het KCS binnenkomen kunnen worden door-

gegeven aan de 3D-Suite (schrijven)

- het KCS de contactgegevens kan inzien van de regisseurs (lezen)

- [aandachtspunten o.b.v. de specificaties van het betreffende „vrouwtje‟ in bijlage [XX]]].

115

7.3 Gemeentelijke basisadministraties en backofficesystemen

S23. Gemeentelijke basisadministratiesysteem (GBA) (lezen)

De 3D-Suite integreert op dusdanige wijze met het gemeentelijke basisadministratiesysteem van

de Gemeente ([merk, type, versie]) zodat de 3D-Suite beschikt over persoonsgegevens in de be-

treffende basisadministratie.

[Alle functionaliteiten en berichten als beschreven in de specificaties van het betreffende „vrouw-

tje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing realtime lezen).]

O75 GBA-V

Beschrijf óf en zo ja op welke wijze de 3D-Suite geïntegreerd kan worden met [GBA-V applicatie,

merk, type, versie] zodat de 3D-Suite beschikt over persoonsgegevens van niet-inwoners van de

Gemeente.

Beschrijf op welke manier eventuele gegevensmagazijnen/databases van de 3D-Suite en de ma-

gazij-nen/caches van het aanwezige datadistributiesysteem hierbij een rol hebben.

Beschrijf tevens hoe gezorgd kan worden dat de gegevens actueel zijn/blijven. Licht toe of dit vol-

ledig automatisch „onderwater‟ plaatsvindt m.b.v. afnemersindicaties of dat hiervoor een handma-

tige actie is vereist via de gebruikersinterface van de 3D-Suite. Geef ten slotte aan hoe in de ge-

bruikersinterface van de 3D-Suite zichtbaar is of een persoon wel of geen inwoner van de Ge-

meente is.

S24. Basisregistratie Adressen en Gebouwen (BAG) (lezen)

De 3D-Suite integreert op zodanige met het Basisregistratie Adressen en Gebouwen (BAG-

systeem, [merk, type, versie] dat alle functionaliteiten en berichten zoals beschreven in de speci-

ficaties van het betreffende vrouwtjes ([bijlage X]) volledig worden ondersteund (voor zover van

toepassing realtime lezen).

S25. Status doorgeven aan Zaaksysteem (schrijven)

De 3D-Suite integreert op dusdanige wijze met het zaaksysteem van de Gemeente ([merk, type,

versie]) dat de 3D-Suite van alle in de 3D-Suite geregistreerde zaken deelzaken de status kan

worden doorgegeven aan het gemeentelijk zaaksysteem.

[Alle functionaliteiten en berichten als beschreven in de specificaties van StUF-Zkn en/of het ZK-

DMS koppelvlak worden – zover van toepassing – voor het betreffende „vrouwtje‟ in bijlage [XX]

volledig worden ondersteund (voor zover van toepassing realtime en zowel lezen als schrijven).]

S26. Zaaksysteem als bron van zaakdossiers (lezen)

De 3D-Suite integreert op dusdanige wijze met het zaaksysteem van de Gemeente ([merk, type,

versie]) dat de 3D-Suite van alle zaken deelzaken de status kan opvragen.

[Alle functionaliteiten en berichten als beschreven in de specificaties van StUF-Zkn en/of het ZK-

DMS koppelvlak worden – zover van toepassing – voor het betreffende „vrouwtje‟ in bijlage [XX]

volledig worden ondersteund (voor zover van toepassing realtime en zowel lezen als schrijven).]

S27. [Schuldhulpverlening] (lezen)

De 3D-Suite integreert op dusdanige wijze met het schuldhulpverleningsysteem van de Gemeente

116

([merk, type, versie: bijv. Allegro, Suite4Zorg, Key2Schuldhulpverlening]) dat daartoe geautori-

seerde gebruikers informatie over de burger en zijn / haar lopende schuldhulpverleningstra-

ject(en) kunnen opvragen dat is geregistreerd in het te koppelen systeem.

[Alle functionaliteiten en berichten als beschreven in de specificaties van het betreffende „vrouw-

tje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing realtime le-

zen).][Hierbij wordt de database van het te koppelen systeem uitgelezen].

S28. [Uitkeringenverstrekking] (lezen)

De 3D-Suite integreert op dusdanige wijze met het uitkeringenverstrekkingsysteem van de Ge-

meente ([merk, type, versie: bijv. Suite4Inkomen]) dat daartoe geautoriseerde gebruikers infor-

matie over de burger en zijn / haar lopende uitkering(en) kunnen opvragen dat is geregistreerd in

het te koppelen systeem.

[Alle functionaliteiten en berichten als beschreven in de specificaties van StUF-Zkn en van het

betreffende „vrouwtje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing re-

altime lezen).][Hierbij wordt de database van het uitkeringenverstrekkingsysteem uitgelezen.]

S29. [Re-integratie] (lezen)

De 3D-Suite integreert op dusdanige wijze met het reïntegratiesysteem van de Gemeente ([merk,

type, versie: bijv. Civision WIZ]) dat daartoe geautoriseerde gebruikers informatie over de burger

en zijn / haar lopende schuldhulpverleningstraject(en) kunnen opvragen dat is geregistreerd in

het te koppelen systeem.

[Alle functionaliteiten en berichten als beschreven in de specificaties van het betreffende „vrouw-

tje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing realtime le-

zen).][Hierbij wordt de database van het te koppelen systeem uitgelezen].

S30. [Leerlingadministratie / leerplichtverzuim] (lezen)

De 3D-Suite integreert op dusdanige wijze met het leerlingadministratiesysteem van de Gemeen-

te ([merk, type, versie: bijv. Suite4Onderwijs/LLA4all/Key2Onderwijs/Key2Jongerenmonitor]) dat

daartoe geautoriseerde gebruikers informatie over de burger en zijn / haar lopende schuldhulp-

verleningstraject(en) kunnen opvragen dat is geregistreerd in het te koppelen systeem.

[Alle functionaliteiten en berichten als beschreven in de specificaties van het betreffende „vrouw-

tje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing realtime le-

zen).][Hierbij wordt de database van het te koppelen systeem uitgelezen].

S31. [Overige indicaties van ontvangen voorzieningen] (lezen)

De 3D-Suite integreert op dusdanige wijze met het bijv. overige applicaties voor jeugdhulp, zorg

of ondersteuning] van de Gemeente ([merk, type, versie: bijv. Civision WIZ]) dat daartoe geauto-

riseerde gebruikers informatie over de burger en zijn / haar ontvangen voorzieningen kunnen op-

vragen dat is geregistreerd in het te koppelen systeem.

[Alle functionaliteiten en berichten als beschreven in de specificaties van het betreffende „vrouw-

tje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing realtime le-

zen).][Hierbij wordt de database van het te koppelen systeem uitgelezen].

117

118

7.4 Integratie landelijke en regionale voor-zieningen

E9 Koppeling met VIR (lezen en schrijven)

De 3D-Suite integreert op zodanige wijze met de Verwijsindex Jongeren dat alle functionaliteiten

en berichten als beschreven in de specificaties van het betreffende vrouwtje volledig worden on-

dersteund (voor zover van toepassing realtime en zowel lezen als schrijven).

D.w.z. dat ten minste (doch niet noodzakelijkerwijs uitsluitend) het mogelijk is

- signalering ontvangen, incl. metadata

- signalering versturen, incl. metadata

Toelichting: de Verwijsindex Risicojongeren (VIR) is een landelijk informatiesysteem dat bedoeld

is om hulpverleners binnen verschillende organisaties inzicht te geven in elkaars betrokkenheid bij

een jongere.

S32. Signaalwerking: inkomend

De 3D-Suite biedt een gedocumenteerde API waarbij daartoe geautoriseerde systemen signalerin-

gen kunnen indienen bij de 3D-Suite.

O76 Signaalwerking

Beschrijf de mogelijkheden die de voorgaand gevraagde API van de 3D-Suite biedt, voor wat be-

treft

- identificatie en autorisatie van betrokken organisaties (bijv. een inkomend signaal van een

arts)

- identificatie van de betrokken burgers (burger, gezin)

- gestructureerde en ongestructureerde gegevens m.b.t. de signalering

- vertrouwelijkheid van de melding

Beschrijf tevens welke functionaliteiten de 3D-Suite biedt om uitgaande signaleringen te sturen

aan overige systemen.

E10 Koppeling met de GeVS: SUWInet-Inlezen (lezen)

De 3D-Suite integreert op zodanige wijze met Suwinet-Inlezen dat alle functionaliteiten en berich-

ten als beschreven in de specificaties van het betreffende vrouwtje volledig worden ondersteund

(voor zover van toepassing realtime).

D.w.z. dat ten minste (doch niet noodzakelijkerwijs uitsluitend)

- het mogelijk is informatie op te vragen van de burger, t.b.v. het klantbeeld

- informatie wordt enkel getoond indien er voldoende autorisatie is voor de betreffende persoon

(dus niet iedere gebruiker)

Bijlage 12.2 geeft een overzicht van de beschikbare gegevens. Enkel voor daartoe geautoriseerde

personen is alle informatie inzichtelijk

119

Koppeling met CORV

De 3D-suite integreert op zondanige wijze met de Collectieve Opdracht Routeer Voorziening17, zo-

als beschreven in de desbetreffende Project Start Architectuur. Dit betekent ondermeer dat ge-

bruik gemaakt moet worden van digikoppeling melding ebMS en gestandaardiseerde berichten.

CORV zorgt voor een goede routering en vertaling van berichten tussen het justitiedomein en het

gemeentelijk domein. Deze voorziening moet voor 1 januari 2015 operationeel zijn.

S33. Dienst Justitiële Inrichtingen (lezen en schrijven)

De 3D-Suite integreert op zodanige wijze met het DJI dat ten minste t.b.v.:

- infoverstrekking van DJI: signaleringen dat een persoon is gedetineerd (en er o.a. geen recht

is op een bijstandsuitkering) worden verwerkt door de 3D-Suite

- In het kader van de nazorg van volwassen (ex-)gedetineerde burgers is er ten minste een

verwijzing naar het samenwerkingsmodel tussen gemeenten en justitie: Digitaal Platform Aan-

sluiting Nazorg

- Infoverstrekking aan DJI: het DJI kan inzicht krijgen in wat de gemeente weet (ten minste

DAT) van een gedetineerde.

S34. Veiligheidshuizen (schrijven en lezen)

De 3D-Suite integreert op zodanige wijze met het Casus ondersteunend systeem voor

Veiligheidshuizen (GCOS) dat

- Burgers kunnen worden aangemeld, en

- De voortgang van een burger kan worden gemonitord

S35. Regionaal Meld- en Coördinatiepunt (lezen)

De 3D-Suite integreert op zodanige wijze met het Regionaal Meld- en Coördinatiepunt (RMC) dat

- vroegtijdige schoolverlaters binnen de gemeente automatisch als signalering de 3D-Suite bin-

nen komen, en

- in het integrale klantbeeld voor leerplichtige kinderen een aanduiding is dat het een vroegtijdi-

ge schoolverlater betreft

S36. Overige adapters met landelijke systemen

De 3D-Suite integreert op zodanige wijze met onderstaande systemen dat alle functionaliteiten en

berichten als beschreven in de specificaties van het betreffende vrouwtje volledig worden

ondersteund (voor zover van toepassing realtime en lezen en schrijven).

17 De desbetreffende PSA Keteninformatie is formeel vastgesteld in het opdrachtgeversoverleg stelselherziening

Jeugd (VNG, VWS en VenJ) op 25 juni 2013. Er zal (1) gegevens uitwisseling tussen gemeente, jeugdstraf-

rechtketen en jeugdbeschermingsketen gaan plaatsvinden, bijvoorbeeld een gestandaardiseerd Verzoek tot On-

derzoek (VTO) als startmoment voor de jeugdbeschermingsketen; ook zullen de gemeenten allerlei gestan-

daardiseerde berichten uit de justitiële jeugdketens ontvangen en (2) beleidsinformatie richting V&J. VWS, VenJ

en enkele gemeenten gaan hiervoor een proeftuin inrichten.

120

- Adapter t.b.v. landelijke voorziening „Mijn Overheid‟, o.a. verzenden van berichten aan burgers

- Adapter t.b.v. betalingskassa, o.a. verzenden van berichten aan burgers

- Adapter t.b.v. authenticatiesysteem DigiD EI en DigiD Machtigingen

O77 Koppelingen: overig

Geef een uitputtende opsomming van alle eventuele overige koppelingen met specifieke landelijke

voorzieningen waarmee standaardkoppelingen met de 3D-Suite worden meegeleverd en desge-

wenst geïmplementeerd bij Gemeenten (inbegrepen bij de prijsopgave en als zodanig zonder ad-

ditionele kosten “out-of-the-box” beschikbaar en verifieerbaar in de PoC).

Besteed daarbij expliciet aandacht aan privacy en beveiliging, incl. doelbinding, en geef aan of het

lezen of schrijven van berichten betreft.

Denk aan

- Justitie (zie ook http://justid.nl/ebv/ en gegevenswoordenboeken van justitie)

- Externe politiebroker

- Vecozo t.b.v. declaraties

- Awbz-brede zorgregistratie (AZR), zorgkantoren

- Overige systemen en organisaties, bijv. i.h.k.v. AWBZ/Wmo

- Etc.

O78 Koppelingen: toelichting

Beschrijf de functionaliteit van elk van de koppelingen tussen het 3D-systeem en de onderstaande

landelijke voorzieningen:

- VIR

- GeVS

- DJI

- Eventuele overige koppelingen met landelijke en regionale voorzieningen.

Beschrijf bovendien de functionaliteit van elk van de koppelingen tussen de 3D-Suite en de be-

treffende gemeentelijke voorzieningen in het kader van:

- Documentopslag

- Documentcreatie en gebruik van sjablonentools

- Eventuele overige koppelingen met gemeentelijke voorzieningen.

Beschrijf daarbij voor elke koppeling, dus zowel koppelingen met landelijke voorzieningen als met

gemeentelijke voorzieningen, steeds ten minste (voor zover van toepassing):

- De functionaliteiten van de betreffende koppeling, onder vermelding van de betreffende ver-

sie(s) van de betreffende te koppelen voorziening / het betreffende vrouwtje waarvoor deze

gelden. Beschrijf daarbij steeds ten minste of en zo ja hoe er bij de betreffende koppeling - in-

dien het betreffende vrouwtje dit ondersteunt - daadwerkelijk sprake is van gegevensuitwisse-

ling, incl. welke gegevens het betreft en of gebruikers daartoe nog handelingen dienen te ver-

richten (en zo ja welke, zoals: wordt bij een URL-koppeling gelinkt naar de betreffende “home-

page” en moeten gebruikers daar verder zoeken of naar een in de betreffende context relevant

element). Maak daarbij indien van toepassing steeds onderscheid tussen lezen uit en schrijven

in de betreffende voorziening (incl. het meegeven van parameters in URL‟s), alsook tussen re-

altime en batchgewijs.

- Autorisatie op applicatie-niveau (bijv. d.m.v. certificaten en encryptie), incl. de mate waarin

beveiliging en privacy worden gewaarborgd.

121

- Of en zo ja hoe de betreffende koppeling - indien het betreffende vrouwtje dit ondersteunt - is

onderworpen aan autorisaties per persoon (rechten en rollen, bijvoorbeeld dat de koppeling al-

leen “actief” is als de ingelogde gebruiker daar autorisatie toe heeft), incl. doelbinding. Be-

schrijf daarbij bovendien of bij de betreffende voorziening nog ingelogd dient te worden (indien

van toepassing) dan wel dat er sprake is van SSO en geef aan of de koppeling (incl. eventuele

SSO) ook functioneert vanaf een device dat zich niet in het gemeentenetwerk bevindt (thuis-

werkplek, mobiel device, etc.).

- De flexibiliteit (mate van aanpasbaarheid) van de betreffende koppeling, incl. de mate waarin

dit door middel van configuratie (“paramaters”) kan worden gerealiseerd (indien het betreffen-

de vrouwtje dit ondersteunt). Beschrijf daarbij tevens in welke mate en op welke wijze functio-

neel resp. technisch beheerders van Gemeenten de betreffende koppeling volledig zelfstandig,

voor zover mogelijk zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero co-

ding), functioneel resp. technisch kunnen beheren.

122

7.5 Zaaksysteem en backofficesystemen van UO’s

O79 Jeugdzorg (lezen en schrijven)

Er zijn verschillende lokale oplossingen voor gegevensuitwisseling tussen gemeente en Bureaus

Jeugdzorg en tussen gemeente en Jeugd & Opvoedhulp-organisaties. Het is denkbaar dat op korte

termijn hier nieuwe applicaties worden ingericht, waardoor de beschikbare koppelvlakken kunnen

gaan afwijken. De bureaus jeugdzorg investeren momenteel in de noodzakelijke herziening van

de verouderde ICT-systemen IJ/Kits. Het systeem zal aansluiten op de keteninformatiesystemen

justitiële jeugdketens en de Collectieve Routerings Voorziening (CORV).

Beschrijf de mogelijkheden die u (binnen de geoffreerde prijzen) biedt om een koppelvlak te ont-

wikkelen op de „vrouwtjes‟ van Jeugdzorg-systemen v.w.b. uitwisseling van gegevens over perso-

nen, (indicatie)besluiten en te verlenen ondersteuning uit te wisselen en welke koppelingen u

reeds heeft gerealiseerd.

Indien u niet binnen de geoffreerde prijzen koppelvlakken biedt, geef aan op welke wijze (binnen

de geoffreerde prijzen) informatieuitwisseling plaatsvindt.

S37. [Top-N uitvoeringsorganisaties: status en informatie uitwisselen (lezen en schrij-

ven)]

De 3D-Suite integreert op dusdanige wijze met het zaaksysteem van de volgende uitvoeringsor-

ganisaties dat de 3D-Suite van alle in de 3D-Suite geregistreerde zaken / deelzaken de status kan

worden doorgegeven aan het gemeentelijk zaaksysteem.

Alle functionaliteiten en berichten als beschreven in de specificaties van StUF-Zkn en van het be-

treffende „vrouwtje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing real-

time en zowel lezen als schrijven).

- Schuldhulpverleningsbedrijven [A, B] cf. standaard [X1] en API als beschreven op [Y1]

- Re-integratiebedrijven [C, D] cf. standaard [X2] en API als beschreven op [Y2]

- etc.

[[NB Zie ook wens S11 voor de gevallen waar nog géén systeem-systeemkoppeling mogelijk is,

dan kunnen derde partijen gebruik maken van een „portal‟]]

123

7.6 Integratie-tooling

O80 Overige functionaliteiten: adapters

Beschrijf alle eventuele additionele functionaliteiten op het gebied van adapters (koppelingen) die

standaard onderdeel uitmaken van de 3D-Suite en die naar uw mening relevant zijn, mede in het

licht van het beoogde gebruik van de 3D-Suite zoals beschreven in hoofdstuk 2. Denk in dat kader

bijvoorbeeld aan:

- Beschikbare generieke webservices / API‟s t.b.v. gebruik van derde applicaties door de 3D-Suite.

- Beschikbare generieke webservices / API‟s t.b.v. gebruik door derde applicaties van functionali-

teiten en gegevens in de 3D-Suite.

- Beschikbare generieke import/export mogelijkheden van metadata en/of documenten, die zelf-

standig in te richten en geautomatiseerd te schedulen is (bij voorkeur o.b.v. StUF-Zkn en/of ZS-

DMS koppelvlak.

- Met welke andere landelijke en/of sectorale voorzieningen de 3D-Suite over een gestandaardi-

seerde koppeling beschikt voor de bi-directionele uitwisseling van gestructureerde en/of onge-

structureerde gegevens (incl. toelichting, zoals of daarbij gebruikgemaakt wordt van Digikoppe-

ling, welke producten / processen ermee worden ondersteund, etc.) en of deze onderdeel is/zijn

van de aanbieding.

- Beschikbare generieke (technologie)adapters zoals CMIS, XML, SMTP, HTTP, WUS, ebMS, COM+,

JMS, databasekoppelingen, etc. of documentkoppelingen

NB: Benoem uitsluitend functionaliteiten welke zijn inbegrepen bij de prijsopgave en die als zoda-

nig zonder (additionele) kosten direct beschikbaar zijn.

O81 Procesbewaking en -beheer (A2A)

Beschrijf de functionaliteiten van de 3D-Suite met betrekking tot het real-time bewaken van lo-

pende A2A processen (oftewel „applicatie workflow‟). Denk in dat kader bijvoorbeeld aan:

- Gebruik en bewaking van adapters.

- Logging (incl. foutregistratie), audit trails, etc.

- Het onderscheid tussen real-time en offline rapportages.

- Notificatie en bij excepties.

- Optimalisatie (incl. load balancing).

- Aspecten rondom integriteit, zoals „transactional integrity‟, roll-back, het gebruik van „compensa-

ting transactions‟, etc. Maak hierbij - indien van toepassing - onderscheid tussen synchroon en

asynchroon berichtenverkeer.

- Beveiliging en autorisatie.

- Etc.

Beschrijf bovendien de functionaliteiten van de 3D-Suite met betrekking tot het beheer van A2A

processen (oftewel „applicatie workflow‟) en de autorisaties (rollen en rechten) daar omheen.

Denk in dat kader bijvoorbeeld aan:

- Het wijzigen van standaardprocessen.

- Versiebeheer rondom A2A processen (incl. de eventuele consequenties van wijzigingen voor

reeds lopende processen).

- Etc.

Geef daarbij tevens aan welke mogelijkheden er zijn met betrekking tot het genereren van docu-

mentatie / handleidingen over processen en processtappen, de procesgang, etc.

124

O82 Overige functionaliteiten: Broker/ESB

Beschrijf alle eventuele additionele functionaliteiten op het gebied van de broker/ESB die stan-

daard onderdeel uitmaken van de 3D-Suite en die naar uw mening relevant zijn, mede in het licht

van het beoogde gebruik van de 3D-Suite zoals beschreven in hoofdstuk 2. Denk in dat kader bij-

voorbeeld aan:

- Of er in de 3D-Suite sprake is van een centrale broker- of een decentrale ESB-architectuur.

- Specifieke mogelijkheden m.b.t. translatie en transformatie, zoals of hierbij validatie mogelijk is

en de wijze waarop „mapping‟ mogelijk is (visueel d.m.v. drag-and-drop, door middel van scrip-

ting, etc.).

- Mogelijkheden m.b.t. het uitwisselen van processen met andere gemeenten zoals import-

/exportfunctionaliteit, bijbehorende bestandsformaten.

- Aspecten rondom beveiliging zoals encryptie, authenticatie en certificaten maar ook het gebruik

van secure messaging en dergelijke.

- Ondersteunde webservice- en andere standaarden, zoals StUF, SuwiML en de gegevenstandaar-

den jeugd.

- Ondersteunde webservice- en andere standaarden, zoals XML, WSI, SOAP en WSDL, WS Adress-

ing, WS Security, WS Reliable Messaging, XSD-authoring, XSLT, Xpath, MIME (voor attach-

ments), etc.

NB: Benoem uitsluitend functionaliteiten welke zijn inbegrepen bij de prijsopgave (zie ##) en die

als zodanig zonder (additionele) kosten direct beschikbaar zijn.

125

8 PvE: Autorisatie, beveiliging en

privacy

8.1 Inleiding

De 3D-Suite bevat zeer vertrouwelijke informatie over burgers in kwetsbare posities. Door middel

van de Inkijk-functionaliteit (integraal klantbeeld) kan toegang worden verschaft tot nog meer

vertrouwelijke gegevens, soms met medische of justitiële achtergrond. De beveiliging van deze

gegevens en de bescherming van de privacy van de betrokkenen is daarom van het grootste

belang.

Aan de andere kant kan het niet zo zijn dat er omwille van de privacybescherming géén enkele

uitwisseling van gegevens mogelijk is. Het WRR-rapport iOverheid18 adviseert dat er in de

ontwikkeling van nieuwe wetgeving en nieuw beleid juist een goede balans moet zijn tussen de

mogelijkheden van ICT, en de benodigde bescherming van de privacy. De beginselen van de Wet

Bescherming Persoonsgegevens en andere relevante wetgeving zijn echter van groot belang,

gegeven de zeer vertrouwelijke informatie. Er wordt enkel informatie uitgewisseld als de betrokken

burger daar toestemming voor heeft gegeven, of als er in de wet een grondslag (inclusief

doelbinding) voor is gecreëerd.

De burger zelf moet akkoord geven voor het delen van de informatie aan derden, incl. uitvoerings-

organisaties. De vorm van dit akkoord kan per gemeente verschillen: v.w.b. de inhoud van een

intentieverklaring t/m formeel contract, en v.w.b. de vorm van een vinkje (na DigiD-autorisatie)

t/m papieren handtekening. Doch in uitzonderingsgevallen (denk aan een uithuisplaatsing waar de

ouder het er niet mee eens is) kan de goedkeuring van de klant ontbreken.

8.2 Wet- en regelgeving

E11 Beveiliging: wet- en regelgeving

De 3D-Suite functioneert v.w.b. aspecten van beveiliging en privacy volledig conform alle betref-

fende wet- en regelgeving.

Contractant verleent medewerking aan eventuele beveiligingstests/-audits (ten minste eenmaal

per jaar is deze medewerking kosteloos), door één of meer daartoe gespecialiseerde onafhankelij-

ke derde partijen. Eventuele vergoedingen aan dergelijke derde partijen in dat kader worden door

Gemeente gedragen. Deze beveiligingstests/-audits kunnen naast de wettelijk vereiste audits on-

der meer hackerstests en tests m.b.t. de beveiliging van de onderdelen van de 3D-Suite waar

burgers mee in aanraking komen (zoals m.b.t. cross-site scripting en serverside scripts) omvat-

ten, alsmede data- en communicatiebeveiliging (incl. encryptie, certificaten, etc.), autorisatiemo-

dellen, logging, en dergelijke.

Eventuele gebleken tekortkomingen m.b.t. beveiliging n.a.v. dergelijke beveiligingstest/-audits

dienen te worden meegenomen bij de doorontwikkeling van de 3D-Suite (als onderdeel van het

onderhoud) en zonodig op de kortst mogelijke termijn te worden gepatcht. Eventuele kosten die

gemoeid zijn met het verhelpen van dergelijke tekortkomingen, zijn voor rekening van

Contractant (als onderdeel van de onderhoudskosten).

Contractant garandeert bovendien de toekomstige (door)ontwikkeling van de 3D-Suite gedurende

18 www.ioverheid.nu

126

de looptijd van de overeenkomst (incl. eventuele verlenging, binnen de jaarlijkse prijzen) zodanig

dat de 3D-Suite „meegroeit‟ met alle ontwikkelingen op het gebied van de betreffende wet- en

regelgeving. D.w.z. zeggen dat Contractant garandeert dat de 3D-Suite v.w.b. aspecten van

beveiliging volledig i.o.m. alle betreffende wet- en regelgeving blijft functioneren en zich eraan

conformeert om de 3D-Suite binnen [XX weken] dienovereenkomstig aan te passen (door middel

van een nieuwe of verbeterde versie van de 3D-Suite) zodra de betreffende wet- en regelgeving

verandert.

E12 Beveiliging: basisfunctionaliteit

De 3D-Suite biedt m.b.t. beveiliging ten minste (doch, indien noodzakelijk om te voldoen aan

E11, niet uitsluitend) afdoende functionaliteit met betrekking tot:

- Authenticatie en autorisatie

▪ De 3D-Suite biedt zodanige functionaliteit m.b.t. authenticatie en autorisatie, zowel voor

gebruikers als voor applicaties, dat alle functionaliteiten van en gegevens in (c.q. te bena-

deren via) de 3D-Suite zodanig aan autorisaties onderworpen zijn dat ten minste kan wor-

den voldaan aan E11.

- Auditing/logging (incl. protocollering)

▪ De 3D-Suite biedt zodanige functionaliteit m.b.t. auditing/logging (incl. protocollering) dat

van alle relevante handelingen en pogingen daartoe - door zowel door gebruikers als appli-

caties - d.m.v. logging een historie wordt vastgelegd (van welke handelingen en pogingen

daartoe, wanneer en door wie zijn uitgevoerd) dat ten minste kan worden voldaan aan E11.

- Technische beveiliging (incl. integriteit, back-up & herstel, uitwijk, etc.)

▪ De 3D-Suite biedt zodanige functionaliteit m.b.t. technische beveiliging (waaronder ten

minste integriteit, back-up & herstel en uitwijk) dat de continuïteit en integriteit van (de

gegevens in c.q. te benaderen via) de 3D-Suite zodanig gewaarborgd is dat ten minste kan

worden voldaan aan E11.

Dit betreft in alle gevallen zowel aanmaken, lezen, aanpassen als verwijderen (Create, Read,

Update, Delete, CRUD) op attribuutniveau.

G27 Verklaring van getrouwheid

De infrastructuur en organisatie van de Inschrijver [incl. rekencentra (incl. back-up)] zijn

adequaat beveiligd volgens ISO/IEC 27001 en ISO/IEC 27002 of vergelijkbaar.

Inschrijver is bereid op eigen kosten jaarlijks (de eerste voor Acceptatie van de 3D-Suite) een

verklaring van getrouwheid (of vergelijkbaar) te verkrijgen via een onafhankelijke derde partij,

om aan te tonen dat zij als Contractant veilig om gaat met vertrouwelijke informatie.

127

8.3 Toegang tot informatie: doelbinding en privacy

G28 Informatieuitwisseling en -verschaffing

- Er wordt enkel informatie uitgewisseld als er in de wet een grondslag (inclusief doelbinding)

voor is gecreëerd, of als de betrokken burger daar toestemming voor heeft gegeven. Wanneer

sprake is van een burger jonger dan een door wetgeving bepaalde leeftijd (nu: zestien jaar)

moet deze toestemming door de ouders worden afgegeven.

- Voor alle registraties en gegevensuitwisselingen geldt dat de systemen alleen op basis van ge-

autoriseerde toegang kunnen worden gebruikt.

- Bij iedere module of gegevensstroom is bekend welke persoonsgegevens zij omvat en per ge-

gevenselement wat de risicoklasse daarvan is en wat de verwerkingsgrond is.

- Binnen het klantdossier is informatie te ontsluiten aan specifieke personen (i.h.k.v. doelbin-

ding).

- Alle gebruik wordt gelogd, zowel bij handmatige toegang als via koppelvlakken en zowel lezen,

wijzigen, verwijderen en schrijven (CRUD).

- Gegevensuitwisseling vindt versleuteld plaats, via onversleutelde kanalen gaat enkel niet-

gevoelige informatie zoals een attenderings-mail.

- Het ondersteuningsplan is v.w.b. door de functioneel beheerder of regisseur vrijgegeven in-

formatie toegankelijk voor de burger / daartoe geautoriseerde personen in het gezin, de regis-

seur en - voor zover het hun eigen dienstverlening betreft - de betrokken hulpverleners.

- Het klantdossier is v.w.b. door de functioneel beheerder of regisseur vrijgegeven informatie

toegankelijk voor de burger / daartoe geautoriseerde personen in het gezin, de regisseur en -

voor zover het hun eigen dienstverlening betreft - de betrokken hulpverleners.

- Het klantbeeld is v.w.b. door de functioneel beheerder of regisseur vrijgegeven informatie toe-

gankelijk voor de burger/ daartoe geautoriseerde personen in het gezin, de regisseur en - voor

zover het hun eigen dienstverlening betreft - de betrokken hulpverleners.

- De betrokken burger heeft een correctie- en inzagerecht met betrekking tot de geregistreerde

gegevens, en heeft het recht om te weten aan welke personen /organisaties zijn of haar gege-

vens zijn verstrekt. Voor wat betreft toegang tot klantinformatie voorziet de gemeente een vier

ogen-principe: regisseur en burger bepalen samen wie toegang heeft.

- In uitzonderingsgevallen (bijv. bij gevaar of dwang) kan de regisseur er voor kiezen géén toe-

stemming te vragen en / of géén inzage voor de burger / het gezin te verschaffen. De regis-

seur dient dan op te geven welke wettelijke grondslag daarvoor is.

NB deze toestemming en het inzicht zijn niet verplicht realtime en via het Burgerportaal. Dit

kan ook bijv. via de regisseur en een papieren rapportage gebeuren.

O83 Informatieuitwisseling (aanvullend)

De wát-informatie over burgers blijft zoveel mogelijk binnen de separate informatiesystemen van

de verschillende betrokken backoffices en uitvoeringsorganisaties / ketenpartners. Er worden niet

meer gegevens uitgewisseld dan strikt noodzakelijk: bij de uitwisseling tussen organisaties en

domeinen wordt zoveel mogelijk alleen dát-informatie uitgewisseld.

Geef aan in welke mate de 3D-Suite out-of-the-box ondersteuning om de uitwisseling van wat-

informatie te minimaliseren zonder dat dat de efficiency en/of de beveiliging van de betreffende

burgers beperkt.

128

O84 Toegang verschaffen tot informatie

Informatie die via de GeVS wordt bevraagd kan enkel getoond worden aan daartoe

geautoriseerde personen. Ook kan bepaalde informatie in een klantdossier vertrouwelijk zijn. Geef

aan hoe en waar wordt bepaald in welke situatie informatie wordt getoond: in welke mate wordt

dit vooraf door Contractant bepaald, vooraf door functioneel beheer of juist ad-hoc door de

regisseur en /of de klant zelf?

Geef tevens aan hoe de 3D-Suite de beveiliging en privacy bewaakt wanneer de professional „aan

de keukentafel‟ de 3D-Suite gebruikt.

Beschrijf de mate waarin de gemeente de burger zelf eigenaar en regisseur van de eigen

gegevens kan laten zijn, o.a. door de burger zelf te laten bepalen welke informatie in het

klantdossier terecht komt, en welke partijen daar toegang toe krijgen. Geef daarbij aan of en hoe

de burger vanuit het Burgerportaal inzicht heeft, of dat dit via de regisseur gaat (bijv. wanneer de

gemeente een fysiek document met „natte handtekening‟ van de burger vraagt v.w.b. de

toestemming.

Geef tenslotte aan hoe de gemeente voor eigen beheerdoelen én om tegemoet te komen aan

verzoeken van betrokkenen (en bijv. WOB-verzoeken) een geautomatiseerd overzicht kan krijgen

van de gegevens die op klantniveau zijn verwerkt (lezen, schrijven).

S38. Vernietigen van informatie

- De burger heeft het recht vergeten te worden. Als een dergelijk verzoek komt, wordt – behalve

als de veiligheid in het geding is – alle informatie over de burger verwijderd (incl. alle lopende

ondersteuning).

- Alle signaleringen worden na een door de gemeente te bepalen periode verwijderd.

- Klantdossiers worden tevens na een door de gemeente te bepalen periode verwijderd.

- Vernietiging van een dossier, signaal of anderszins te vernietigen informatie kan worden opge-

schort als en zo lang functioneel beheer daar aanleiding toe ziet (bijv. als er een rechtszaak

loopt). Toegangslogs (CRUD) worden niet vernietigd.

- De gemeente kan er t.b.v. rapportages en analyse tevens voor kiezen anonieme (gestructu-

reerde) gegevens te bewaren. De 3D-Suite ondersteunt dit anonimiseren.

O85 Privacy by design

Bij voorkeur was reeds bij de ontwikkeling van de applicatie aandacht voor privacy-verhogende

maatregelen (“privacy enhancing technologies”), zodat wordt voldaan aan de “privacy by design”

principes als verwoord in artikel 23 van de concept Verordening Bescherming Persoonsgegevens 19.

Beschrijf derhalve in welke mate dit het geval is – voor álle door Inschrijver aangeboden

applicaties die deel uitmaken van de 3D-Suite. Geef tevens aan in welke mate privacy by design

een uitgangspunt is bij door ontwikkeling.

Denk hierbij aan o.a.:

19 http://ec.europa.eu/justice/data-protection/document/review2012/com_2012_11_nl.pdf

129

- Gegevensminimalisatie:

▪ waar mogelijk anonimiseren van gegevens;

▪ enkel tonen van identiteit van personen en van andere informatie wanneer nodig voor de

betreffende rol

▪ verwijderen van gegevens zodra dit kan

- Registratie van de voor het klantdossier verantwoordelijke organisatie en medewerker(s)

- Technische beveiliging van de databases

▪ Encrypted dataopslag en backup

▪ Toegang enkel na autorisatie en authenticatie

▪ Gescheiden opslag van persoonsgegevens en overige gegevens.

▪ Passende instrumenten om datalekken te detecteren en de omvang daarvan te bepalen om

daarvan melding te kunnen maken.

- Scheiding binnen de database tussen persoonlijke bevindingen en meningen van de professio-

nal, en de overige gegevens (met het oog op verstrekking persoonsgegevens, Wob-verzoeken

en publicatie)

8.4 Authenticatie en autorisatie

E13 Authenticatie burgers

De 3D-Suite biedt functionaliteit om burgers te authenticeren via DigiD EI en DigiD Machtigingen.

DigiD EI en DigiD Machtigingen gebruiken niveau midden (loginnaam, wachtwoord én SMS),

wanneer beschikbaar tevens niveau hoog (t.z.t. o.b.v. elektronische Nederlandse Identiteitskaart

of vergelijkbaar).

G29 Authenticatie medewerkers

Authenticatie van medewerkers van Gemeente t.b.v. de 3D-Suite verloopt binnen de firewall van

Gemeente via de directory server van Gemeente [merk, type, versie].

Via andere netwerken is inloggen mogelijk voor daartoe geautoriseerde personen o.b.v. tweefac-

tor-authenticatie (gebruikersnaam+wachtwoord én verificatie via SMS). Na authenticatie via deze

directory server hebben medewerkers van Gemeente via single sign-on (SSO) toegang tot alle

onderdelen van de 3D-Suite (voor zover zij daartoe geautoriseerd zijn).

Authenticatie van medewerkers van buiten de Gemeente t.b.v. de 3D-Suite verloopt via login-

naam/paswoord in combinatie met verificatie via SMS (tweefactor-authenticatie). Gemeente kan

vereisen dat een fysiek token wordt gebruikt.

S39. Autorisatiestructuur

De autorisaties van gebruikers t.b.v. de 3D-Suite worden binnen de 3D-Suite vastgelegd. Hiertoe

worden alle rechten (CRUD) in de 3D-Suite gekoppeld aan rollen in de 3D-Suite. Rollen in de 3D-

Suite zijn door functioneel beheerders van Gemeente geheel zelfstandig, zonder dat daarvoor ge-

avanceerde programmeerkennis nodig is (zero coding), vrij te definiëren en kunnen gekoppeld

worden aan één of meer groepen in de directory server van Gemeente, die hiertoe realtime inge-

lezen worden in de 3D-Suite.

130

Naast door functioneel beheer vooraf gedefinieerde rollen zijn tevens ad-hoc rechten uit te geven

door daartoe voor de betreffende dossier / burger / zaak geautoriseerde personen (zoals regis-

seurs).

O86 Autorisatiemodel

Beschrijf het autorisatiemodel van de 3D-Suite. Ga daarbij ten minste in op (voor zover van toe-

passing):

- Het ad-hoc uitdelen van rollen en rechten door de burger en door de regisseur.

- De „granulariteit‟ (fijnmazigheid) waarmee autorisaties kunnen worden beheerd (CRUD) en de

wijze waarop dit geschiedt. Ga daarbij ten minste in op (voor zover van toepassing):

Het toekennen van verschillende typen rechten (CRUD).

Het toekennen van rechten aan rollen [(incl. de rol „burger‟)], groepen, individuen, applica-

ties, etc. Ga daarbij ook in op de eventuele mogelijkheid tot het „clusteren‟ van rechten in

„profielen‟ (vgl. „clusteren‟ van individuen in rollen/groepen) die op soortgelijke wijze kun-

nen worden toegekend, alsmede op het „afleiden‟ van autorisaties uit aanvullende geregi-

streerde gegevens bij gebruikers (zoals kennis van specifieke onderwerpen).

Het toekennen van rechten op het niveau van zaken / deelzaken, maar bijvoorbeeld ook op

registraties, entiteiten, attributen / velden („rubrieken‟), etc. en hun onderlinge relaties en

op individuele cliënten, dossiers, documenten, etc.

De eventuele afhankelijkheid van dergelijke autorisaties t.a.v. aspecten zoals het betreffen-

de zaaktype, de actuele status / stap / taak (zie par. 4.2.4), de van toepassing zijnde be-

drijfs-/meldingregels, behandel-/archieffase, etc.

Beschrijf ook in welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a.

volledig zelfstandig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero co-

ding), kunnen beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus).

- De wijze waarop door middel van autorisaties en/of eventuele andere soortgelijke maatregelen

invulling gegeven wordt aan wettelijke voorschriften zoals doelbinding, functiescheiding, etc.

- Of en zo ja hoe wordt afgedwongen dat bij autorisatiewijzigingen de betreffende gebruiker(s),

vanaf het moment waarop deze worden doorgevoerd, geen handelingen meer kunnen verrich-

ten die zij dan niet meer mogen (c.q. juist wel), bijvoorbeeld door opnieuw inloggen te „force-

ren‟.

O87 Visie en mogelijkheden autorisatie

Beschrijf uw visie op – en de mate waarin dit ondersteund wordt door de 3D-Suite – autorisatie

en authenticatie van burgers, medewerkers binnen de gemeente, etc.

Bespreek daarbij zowel het gebruiksgemak, als de privacy en het beperken van de gevaren voor

veiligheid en privacy wanneer onverhoopt iemand ten onrechte toegang verschaft tot de 3D-Suite

(als burger of als medewerker).

8.5 Auditing / logging

O88 Auditing / logging

Beschrijf de functionaliteit van de 3D-Suite m.b.t. auditing / logging. Ga daarbij ten minste in op

131

(voor zover van toepassing):

- De verschillende handelingen en pogingen daartoe waarvan logging plaatsvindt, zoals opvra-

gen (incl. zoeken), inzien (incl. printen), creëren / toevoegen, muteren, verwijderen, archive-

ren, etc. van gegeven, maar ook het in- / uitloggen op het netwerk, in de 3D-Suite, etc.

- De verschillende elementen waarop dergelijke handelingen worden gelogd, zoals registraties,

entiteiten, attributen / velden („rubrieken‟), etc. maar bijvoorbeeld ook zaken en zaakattribu-

ten, documenten en documentattributen, notities, statuswijzigingen, het afvinken van check-

lists, etc.

- Wat er precies wordt vastgelegd, zoals wie de handeling of poging daartoe heeft uitgevoerd

(personen resp. applicaties, zo mogelijk incl. de „achterliggende‟ personen), wanneer (datum /

tijd) dit geschiedde, etc.

- De wijze waarop gegevensuitwisseling via koppelvlakken wordt gelogd en geaudit (incl. wie,

wanneer, wat)

- Hoe lang de logs bewaard blijven, incl. de flexibiliteit dienaangaande (zoals mogelijkheden om

ad hoc af te wijken en (delen van) logging (tijdelijk) uit te zetten) en hoe dit wordt geautori-

seerd. Beschrijf ook hoe en op welke wijze niveaus (objecten, attributen, gebruikers, etc.) de

logs geraadpleegd kunnen worden in de 3D-Suite en hoe dit wordt geautoriseerd. Geef tenslot-

te aan of van de eventuele vernietiging van logs voldoende informatie beschikbaar blijft om dit

te traceren.

- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in de

3D-Suite (zoals via configuratie van zaaktypen in een zaaktypencatalogus).

- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-

standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen

beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus).

O89 Protocollering

Beschrijf de wijze waarop door middel van auditing / logging en/of eventuele soortgelijke maatre-

gelen invulling gegeven wordt protocollering. Ga daarbij ten minste in op (voor zover van toepas-

sing):

- Of daarbij ten minste daartoe alle noodzakelijke gegevens (identificatie zoals een BSN, datum,

behandelende ambtenaar, gebruikte procedure, verstrekte gegeven worden geregistreerd.

- Of daarbij zowel alle verplicht als optioneel te protocolleren handelingen worden geprotocol-

leerd (bij voorkeur wel), zoals inzage d.m.v. geautoriseerde toegang, herleidbare verstrekkin-

gen d.m.v. geautoriseerde toegang (systematisch, spontaan en selecties), etc. Beschrijf tevens

hoe voorkomen wordt dat verplicht niet te protocolleren handelingen geprotocolleerd worden.

- Het eventuele onderscheid tussen interne (binnen Gemeente) en externe verstrekkingen resp.

automatisch en handmatig protocolleren, of dat in alle gevallen van dezelfde handelingen de-

zelfde gegevens worden geregistreerd.

- De wijze waarop het „archiefregime‟ (bewaren / vernietigen) van de betreffende logging is in-

geregeld en kan worden beheerd.

- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in de

3D-Suite (zoals via configuratie van zaak-/objecttypen in een zaak-/objecttypencatalogus).

- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-

standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen

beheren (zoals via configuratie van zaak-/objecttypen in een zaak-/objecttypencatalogus).

132

O90 Inzichtelijkheid audit logs

Beschrijf de functionaliteit van de 3D-Suite m.b.t. weergave van auditing / logging. Ga daarbij ten

minste in op (voor zover van toepassing):

-

- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in de

3D-Suite (zoals via configuratie van zaaktypen in een zaaktypencatalogus).

- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-

standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen

beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus).

8.6 Technische beveiliging en integriteit

O91 Technische beveiliging en integriteit

Beschrijf welke maatregelen er door wie (Contractant, Gemeente [resp. de partij die de hosting

van de 3D-Suite verzorgt]) getroffen dienen te worden, alsmede welke functionaliteit de 3D-Suite

daartoe biedt, om:

- Een adequate (informatie)beveiliging in technische zin te garanderen, alsmede welke functio-

naliteit de 3D-Suite daartoe biedt. Ga daarbij tenminste in op (voor zover van toepassing):

Data- en communicatiebeveiliging (zoals SSL, HTTPS, WS-Security, SAML 1/2, XCAML,

etc.).

Netwerkbeveiliging (zoals firewalls).

Integriteit, authenticiteit, vertrouwelijkheid, onweerlegbaarheid, etc.

De wijze waarop de beveiliging van koppelvlakken in technische zin gegarandeerd is, zoda-

nig dat uitsluitend daartoe geautoriseerde systemen met de 3D-Suite kunnen „interacteren‟.

Denk in dat kader bijvoorbeeld aan het gebruik van:

Encryptie (zowel t.a.v. gegevens als t.a.v. communicatie).

PKI- en andere certificaten, elektronische handtekeningen, WYSIWYS, etc.

Het gebruik van protective markings, timestamps, etc.

Het rollen- en rechtenmodel (zie par. 8.4).

Websitebeveiliging (zoals m.b.t. serverside en cross-site scripting), hackerstests (zoals

i.v.m. SQL-injects en dergelijke), etc.

- De integriteit van gegevens (incl. documenten) te waarborgen, bijvoorbeeld indien (delen van)

de 3D-Suite, externe applicaties (incl. bij ketenpartners en/of landelijke voorzieningen), etc.

niet beschikbaar zijn. Ga daarbij ten minste in op (voor zover van toepassing):

Hoe omgegaan wordt met vastgelopen / afgebroken transacties (zowel batch als realtime).

Roll-back, incl. toelichting van het roll-back mechanisme o.v.v. de minimale en maximale

omvang van roll-backs (hoeveel/welke gegevens daarbij betrokken zijn).

Back-up & herstel (zonder downtime), incl. herstelprocedure m.b.t. berichtenverkeer.

Record locking.

Uitwijk t.b.v. calamiteiten (met maximale beperking van downtime en dataverlies).

Maatregelen die het wijzigen van gegevens (incl. documenten) buiten (de webinterface van)

de 3D-Suite om voorkomen (zoals bij koppelingen).

133

8.7 Overig (beveiliging)

O92 Beveiliging: overige functionaliteiten

Beschrijf alle eventuele additionele standaardfunctionaliteit van de 3D-Suite m.b.t. beveiliging die

naar uw mening i.h.k.v. hoofdstuk 8 relevant is. Denk in dat kader bijvoorbeeld aan:

- (Functionele en/of technische) „maatregelen‟ die voorkomen dat auditing / logging en (automa-

tische) protocollering merkbaar ten koste gaan van de performance van de 3D-Suite.

- Functionaliteiten m.b.t. (randvoorwaarden aan) wachtwoorden, zoals de verplichting tot sterke

wachtwoorden, de verplichting om wachtwoorden periodiek te veranderen, of accounts worden

geblokkeerd na een instelbaar aantal mislukte inlogpogingen, etc.

- Functionaliteit m.b.t. signalering / logging van (dreigend) misbruik, incl. beveiliging tegen ex-

terne DoS- en andere aanvallen, virussen, malware, etc.

- Functionaliteit m.b.t. het monitoren remote access.

NB: Benoem uitsluitend functionaliteit die is inbegrepen bij de prijsopgave en als zodanig zonder

(additionele) kosten direct „off-the-shelf‟ beschikbaar is. Licht de beantwoording zo mogelijk toe

d.m.v. schermafbeeldingen.

134

9 PvE: Architectuur

9.1 Inleiding

Dit hoofdstuk 9 bevat wensen en eisen t.a.v. de architectuur van de 3D-Suite. Hierbij wordt een

indeling gehanteerd naar verschillende typen architectuur: functionele architectuur (par. 9.2),

softwarearchitectuur (par. 9.3), client- en serverside architectuur (par. 9.4) en technische

architectuur (par. 9.5), aangevuld met de onderwerpen beschikbaarheid en performance (par. 9.6)

en beleid en (open) standaarden (par. 9.7). Tenslotte volgen

9.2 Functionele architectuur

O93 Functionele architectuur: algemeen

Geef een uitputtende opsomming van alle bij de beantwoording van de wensen en eisen in dit PvE

gebruikte applicatie(module)s, incl. alle eventuele add-ons, (configuratie)tools, etc. Benoem

daarbij tevens alle applicatie(module)s, add-ons, (configuratie)tools, etc. van de 3D-Suite voor

zover:

- het intellectueel eigendomsrecht daarvan berust bij verschillende (niet: meerdere) partijen -

hoofdaannemer, onderaannemer, deelnemers aan de combinatie, toeleveranciers (incl. OEM),

etc. - en/of

- die ontwikkeld en/of onderhouden worden door verschillende (niet: meerdere) partijen -

hoofdaannemer, onderaannemer, deelnemers aan de combinatie, toeleveranciers (incl. OEM),

etc. - en/of

- die middels een (interne) koppeling geïntegreerd worden, en/of

- die ontwikkeld zijn m.b.v. verschillende (niet: meerdere) technologieën - zoals C#, C++,

Delphi, Java, Perl, php, PL/SQL, Progress, Ruby, VB .NET, etc.) - en/of

- daarbij sprake is van een verschillende (niet: meerdere) „codebase‟, en/of

- daarbij sprake een verschillende (niet: meerdere) gebruikers- en/of beheerinterface.

Vermeld bij alle aldus benoemde elementen steeds de eventuele versie- en andere relevante aan-

duidingen (zoals „enterprise‟, „basic‟, „community‟, etc.), alsmede of deze open source zijn. Indien

er afhankelijkheden bestaan tussen aldus benoemde elementen, dient dit te worden aan te geven

(bijv. als deze technisch en/of functioneel niet gescheiden kunnen worden).

Beschrijf ten slotte de functionele (software)architectuur van de 3D-Suite, incl. architectuur-

schets; deze dient alle aldus benoemde (applicatie(module)s, add-ons, (configuratie)tools, etc.) te

bevatten. Beschrijf daarbij hoe de verschillende functionele elementen van de 3D-Suite samen-

hangen c.q. zich tot elkaar verhouden, incl. in hoeverre de 3D-Suite modulair van opzet is en of

sprake is van gedeelde repositories, beheer-, configuratie- en/of andere tools en/of -interfaces,

etc. Beschrijf daarbij ook in hoeverre de architectuur van de 3D-Suite „open‟ is en voldoet aan

(architectuur)standaarden zoals GEMMA, NORA, etc.

E14 Functionele architectuur: (configuratie)tools

Voor alle eventuele (configuratie)tools die nodig zijn voor implementatie, gebruik en/of (functio-

neel en/of technisch) beheer van de 3D-Suite geldt dat deze of deel uit maken van de levering

en/of commercieel vrij verkrijgbaar zijn.

O94 Releasebeleid

Beschrijf het releasebeleid van de 3D-Suite met betrekking tot Nieuwe en Verbeterde Versies zo-

als (major- en minor)releases, patches, updates, etc. Voeg tevens een releaseplanning / roadmap

135

bij met alle geplande (major- en minor)releases, updates, etc. van de komende 2 jaar. Vermeld

daarbij ook de eventuele uitfasering, vervanging, etc. van (onderdelen van) applicaties.

Geef tevens per onderdeel van de 3D-Suite aan in hoeverre het is toegestaan dat de Gemeente

nog ten minste 2 jaar na een nieuwe major release nog op de vorige major release blijft. Beschrijf

ten slotte in hoeverre updates van de 3D-Suite door de Gemeente zelf zijn uit te voeren.

NB: Deze wens heeft betrekking op de volledige 3D-Suite. Indien uw 3D-Suite uit meerdere appli-

caties bestaat, ga bij uw beantwoording dan in op elke applicatie afzonderlijk.

O95 Multi-tenancy

Geef aan of, en zo ja welke, functionaliteiten de 3D-Suite biedt met betrekking tot multi-tenancy.

Dat wil zeggen dat verschillende gemeenten - ook in technische zin - gebruikmaken van één 3D-

Suite (één codebase, bijv. o.b.v. SaaS), met logisch gescheiden „compartimenten‟ voor de

configuratie per gemeente („tenants‟) doch met gescheiden databases, waarbij elke gemeente

gebruik maakt van dezelfde versie van de 3D-Suite.

Maak bij uw beantwoording (per niveau) indien van toepassing steeds ten minste onderscheid

tussen de onderstaande onderdelen van de 3D-Suite. Besteed tevens aandacht aan de mate

waarin privacy en beveiliging gegarandeerd kunnen worden.

O96 Toekomstvisie

Beschrijf uw visie op het sociale domein voor gemeenten in het algemeen en voor Gemeente in

het bijzonder - voor zowel de korte (binnen 2 jaar) als de langere termijn (2-10 jaar) - incl. hoe

deze visie zich verhoudt tot de huidige functionaliteit van de 3D-Suite en de releaseplanning. Ga

daarbij ook in op de “toekomstvastheid” van de 3D-Suite t.a.v. relevante ontwikkelingen m.b.t. de

e-overheid, zoals de verschillende andere basisregistraties en het toenemende belang van “self-

service” door burgers (elektronische dienstverlening via het web).

9.3 Softwarearchitectuur

O97 Softwarearchitectuur: algemeen

Beschrijf de wijze waarop de software van (de verschillende elementen van) de 3D-Suite wordt

(door)ontwikkeld, incl. het eventuele gebruik van (meer of minder geformaliseerde) methoden en

best-practices (zoals agile / scrum, prototyping / RAD, RUP, waterval / SDM, etc.) en de wijze

waarop daarbij invulling wordt gegeven aan quality assurance.

Ga daarbij v.w.b. softwareontwikkeling ten minste in op de wijze waarop daarbij rekening gehou-

den wordt met aspecten als integriteit, onderhoudbaarheid, portabiliteit, betrouwbaarheid,

schaalbaarheid, beveiliging, efficiency, performance en andere aspecten als beschreven in de ex-

tended ISO 9126 norm, incl. de wijze waarop het ontwikkelproces wordt gedocumenteerd.

Ga daarbij v.w.b. quality assurance ten minste in op de wijze waarop invulling wordt gegeven aan

testen (incl. de daartoe gehanteerde meer of minder geformaliseerde methoden en best-

practices), incl. aard, omvang en frequentie van de verschillende tests (zoals unit-, integratie- en

systeemtests) en de wijze waarop het testproces wordt gedocumenteerd.

Relateer e.e.a. daarnaast aan privacy by design zoals gevraagd in O85 op blz. 128.

Beschrijf tenslotte waar - in Nederland, near-shore, off-shore - en door wie (organisatie) de soft-

136

ware (door)ontwikkeld wordt en met welke tooling. Beschrijf daarbij ook de (omvang en specifie-

ke expertise van) ontwikkel- en testteam(s), incl. eventuele relevante certificeringen t.a.v. soft-

wareontwikkeling - incl. tooling en beheerkennis - en quality assurance, v.w.b. zowel organisaties

als personen.

9.4 Client- en serverside architectuur

E15 Clientside architectuur: webbased

- Burgers en eindgebruikers: Alle gebruikersinterfaces van de 3D-Suite voor burgers (incl.

gezinnen) zijn „volledig webbased‟; d.w.z. dat clientside plug-ins (zoals Java, Flash, ActiveX,

SilverLight, etc.) niet zijn toegestaan (NB: Javascript is wel toegestaan).

- Functioneel beheerders en managementrapportages: Alle gebruikersinterfaces van de

3D-Suite voor eindgebruikers zijn „webbased‟, waarbij clientside plug-ins (zoals Java, Flash,

ActiveX, SilverLight, etc.) wel zijn toegestaan

- [Technisch beheerders: Gebruikersinterfaces voor technisch beheerders hoeven niet nood-

zakelijkerwijs „webbased‟ te zijn.]

NB: volledig webbased wil hier bovendien zeggen dat deze gebruikersinterfaces ten minste bena-

derbaar zijn met browsers MS Internet Explorer (versies [XX] en hoger), Mozilla Firefox (versie

[XX] en hoger) en Google Chrome (versie [XX] en hoger), v.w.b. álle gevraagde en geboden func-

tionaliteit zonder enige beperking voor wat betreft weergave en functionaliteit.

NB: De term „eindgebruiker‟ heeft hier betrekking op medewerkers van Gemeente (uitgezonderd

functioneel [en technisch] beheerders), maar ook van alle ketenpartners.

E16 Clientside architectuur: communicatie o.b.v. HTTPS

Alle communicatie tussen clients en de 3D-Suite geschiedt volledig op basis van HTTPS, voor alle

gebruikersinterfaces (dus t.b.v. zowel eindgebruikers als functioneel [en technisch] beheerders).

NB: De term „eindgebruiker‟ heeft hier betrekking op medewerkers van Gemeente (uitgezonderd

functioneel [en technisch] beheerders) [alsook op burgers (voor zover van toepassing)].

O98 Clientside architectuur: algemeen

Beschrijf welke clientside technologieën de 3D-Suite ondersteunt, incl. besturingssystemen (Win-

dows, Linux, etc.) en browsers (Internet Explorer, FireFox, Opera, Safari, Chrome, etc.). Geef

daarbij steeds aan welk(e) versienummer(s) het betreft, incl. het beleid t.a.v. op- en neerwaartse

compatibiliteit m.b.t. versies van de betreffende browser.

Beschrijf bovendien voor elke clientside technologie de mogelijkheden, randvoorwaarden en even-

tuele beperkingen m.b.t. Javascript en overige clientside scripting, alsmede m.b.t. Java, Flash,

ActiveX, SilverLight en overige plug-ins (plug-ins zijn bij voorkeur niet nodig). Beschrijf bovendien

of - en zo ja welke - er specifieke (beveiligings)instellingen op de client nodig zijn voor het correct

functioneren van de 3D-Suite.

Beschrijf tevens alle randvoorwaarden (minimale en eventuele specifieke requirements) m.b.t.

clientside hardware voor zowel werkplekken als mobiele devices (tablets, smartphones, etc.) voor

het correct functioneren van de 3D-Suite. Ga daarbij ten minste in op (voor zover van toepassing)

minimale en maximale schermresolutie, benodigde processorsnelheid/geheugen/bandbreedte en

eventuele beperkingen bij gebruik van een „hosted desktop‟ (Citrix en vergelijkbaar).

NB: Maak bij de beantwoording steeds onderscheid tussen de rollen eindgebruiker en functioneel

137

[en technisch] beheerder.

O99 Serverside architectuur: algemeen

Beschrijf de serverside architectuur van de 3D-Suite, incl. architectuurschets (schema met appli-

catie-, web- en databaseservers, etc.). Deze beschrijving dient alle applicatie(module)s, add-ons,

(configuratie)tools, etc. van de 3D-Suite te bevatten (zie O93 op blz. 134), waarbij de nadruk bij

de beschrijving dient te liggen op de technische aspecten van de softwarecomponenten. Beschrijf

daarbij ook hoe deze componenten samenhangen c.q. zich tot elkaar verhouden. Ga daarbij ten

minste in op (voor zover van toepassing):

- De verdeling over web-, applicatie- en databaseservers en de mogelijkheden van de software-

componenten dienaangaande, gegeven de gewenste performance, beschikbaarheid en beveili-

ging.

- Virtualisatie, clustering, load balancing, caching, fail-over, etc. en de mogelijkheden van de

softwarecomponenten dienaangaande, gegeven de gewenste beveiliging, beschikbaarheid en

performance.

- De N-tier architectuur en de mogelijkheden van de softwarecomponenten dienaangaande.

Beschrijf ten slotte hoe de verschillende applicatie(module)s, add-ons, (configuratie)tools, etc.

zoals benoemd in beantwoording van O93 op blz. 134 samenhangen c.q. zich tot elkaar verhou-

den, v.w.b. serverside platforms (Linux, Windows, etc.), componentmodellen (.NET, Java, etc.) en

programmeer- en scripttalen (C#, C++, Delphi, Java, Perl, php, PL/SQL, Progress, Ruby, VB .NET,

etc.).

NB: Maak bij de beantwoording steeds onderscheid tussen T, A, P en U.

9.5 Technische architectuur

In onderhavige paragraaf wordt van uit gegaan dat hosting en technisch beheer van de 3D-Suite

niet meegeleverd worden door de leverancier van de 3D-Suite, maar wordt gedaan door de

Gemeente zelf of door een derde partij. Als het bestek voor een daadwerkelijke aanbesteding t.b.v.

een specifieke gemeente of groep van gemeenten wordt opgesteld, dient e.e.a. dan ook mogelijk

aangepast te worden conform de specifieke voorkeuren dienaangaande. Daarnaast kunnen

gemeentespecifieke omstandigheden aanleiding zijn tot additionele eisen / wensen, zoals m.b.t.

eventuele complicaties in een Citrix- of soortgelijke omgeving en andere randvoorwaarden t.a.v. de

technische infrastructuur (zoals server- en DBMS-platforms).

E17 Technische architectuur: compatibiliteit

[Evt. eisen en randvoorwaarden t.a.v. compatibiliteit met bestaande technische infrastructuur.]

O100 Technische architectuur: schaalbaarheid

Beschrijf de technische en functionele infrastructuur van de 3D-Suite die nodig is t.b.v. schaal-

baarheid, gegeven het beoogde aantal gebruikers (ca. [XX]) en de gewenste performance, be-

schikbaarheid en beveiliging. Voeg hiertoe een architectuurschets bij en beschrijf de verschillende

mogelijke „maatregelen‟ en technieken om zowel de horizontale (zoals extra servers, load balan-

cers, etc.) als verticale schaalbaarheid (zoals zwaardere servers) van de 3D-Suite verder uit te

bouwen. Ga daarbij ten minste in op (voor zover van toepassing): caching, clustering, load balan-

cing, fail-over, virtualisatie, etc. en beschrijf welke merkbare gevolgen het verhogen van de hori-

zontale resp. verticale schaalbaarheid heeft voor eindgebruikers [(incl. burgers)], functioneel [en

138

technisch] beheerders, etc.

Beschrijf tenslotte de (technische en/of functionele) grenzen t.a.v. het aantal openstaande en af-

gesloten zaken / processen, (zaak-/object)documenten en -dossiers, etc. alsmede t.a.v. reële

maxima m.b.t. de omvang van attachments, (zaak-/object)documenten en -dossiers, etc. in de

3D-Suite.

NB: Maak bij de beantwoording steeds onderscheid tussen T, A, P en U.

O101 Technische architectuur: algemeen

Beschrijf de verschillende mogelijkheden en randvoorwaarden (minimale en eventuele specifieke

requirements, incl. benodigde aantallen) v.w.b. de technische infrastructuur (incl. alle servers,

SAN‟s, domein-/netwerkstructuur, plaatsing van firewalls, etc.) van de 3D-Suite in termen van:

- Virtualisatie-architectuur van web-, applicatie en database-servers en/of opslag.

- Sizing en redundantie van de verschillende elementen (zoals servers, hubs, SAN‟s, etc.) incl.

aantallen CPU‟s, geheugen, opslag, etc.

- Serverside platforms (zoals typen besturingssystemen, web- en applicatieservers, databa-

se(server)s, bestandssystemen, SAN‟s, etc.).

- De mate waarin sprake is van gedeelde servers, communicatie (hubs etc.) en databa-

ses/SAN‟s.

- Eventuele andere technische / infrastructurele aspecten (zoals netwerk, bandbreedte, opslag-

capaciteit, hubs, firewalls, etc.).

- Communicatie tussen de verschillende elementen (zoals netwerk, protocollen en poortnum-

mers, beveiliging, autorisaties, etc.).

- Koppelingen met internet en landelijke voorzieningen, gemeentelijke systemen en dergelijke

(incl. bandbreedte en redundancy).

Beschrijf daarbij wat nodig is om de 3D-Suite correct te laten functioneren, gegeven de gewenste

performance, beschikbaarheid en beveiliging en het beoogde aantal medewerkers (ca. [XX]), uit-

gesplitst naar T-, A-, P- en U (ten minste [XX] separate omgevingen, bijvoorbeeld [XX]. Geef

daarbij bovendien aan welke merken / typen / versies systeemsoftware (besturingssystemen, da-

tabases, web-/applicatieservers, etc.) verplicht zijn en welke alternatieven mogelijk zijn.

Beschrijf tenslotte het transitieproces tussen T, A, P en U i.h.k.v. nieuwe en verbeterde versies

van (elementen van) de 3D-Suite aan de hand van een voorbeeld (incl. schematische weergave).

Beschrijf daarbij ook de eventuele consequenties van wijzigingen in de implementatie-inrichting /

configuratie van (elementen van) de 3D-Suite, incl. de voor het functioneren van de 3D-Suite be-

nodigde systeemsoftware.

NB: Maak bij de beantwoording steeds onderscheid tussen T, A, P en U.

O102 Technische architectuur: technisch beheer

Beschrijf de functionaliteit en beschikbare hulpmiddelen van de 3D-Suite m.b.t. het technisch be-

heer van de 3D-Suite. Ga daarbij ten minste in op:

- Eigen (1P) beheer-, rapportage-, monitoring- en analysetools - incl. de betreffende beheerin-

terface(s) - incl. toelichting.

- Alle eventuele met de 3D-Suite meegeleverde standaardkoppelingen met beheer-, rapportage-

, monitoring- en analysetools van derden (3P), incl. toelichting per standaardkoppeling.

- Scripting.

Beschrijf bovendien hoeveel FTE Gemeente structureel nodig heeft om de 3D-Suite technisch te

139

beheren, o.v.v. de specifieke expertise, kennis, vaardigheden, etc. die hiertoe aanwezig veronder-

steld wordt bij technisch beheerders. Doe dit zowel voor de volledige 3D-Suiteals geheel als voor

elk van de afzonderlijke elementen daarvan (indien van toepassing).

[Beschrijf tenslotte of - en zo ja en onder welke voorwaarden - nieuwe en verbeterde versies, up-

dates, (beveiligings)patches, etc. van de 3D-Suite door medewerkers van de partij die de hosting

van de 3D-Suite gaat verzorgen geheel zelfstandig zijn uit te voeren, o.b.v. expliciete (gedocu-

menteerde) installatie-instructies, -scripts, etc. die daartoe door Contractant worden verstrekt.]

O103 Technische architectuur: ASP / SaaS

Beschrijf de mogelijkheden om de 3D-Suite geheel of gedeeltelijk „in de cloud‟ te plaatsen. Ga

daarbij ten minste in op de mate waarin de 3D-Suite in technische zin geschikt is om op afstand

te benaderen en geef aan welke eisen en randvoorwaarden dit stelt aan bandbreedte, beveili-

gingsaspecten, etc. gegeven de gewenste beveiliging, beschikbaarheid en performance. Beschrijf

daarbij ook mogelijkheden m.b.t. de bijbehorende dienstverlening, zoals i.h.k.v. technisch beheer.

9.6 Beschikbaarheid en performance

E18 Beschikbaarheid

De 3D-Suite wordt ingericht zodanig dat, uitgaande van een beschikbaarheid van de technische

infrastructuur van 100%, de beschikbaarheid van productieomgeving van de 3D-Suite op [Werk-

dagen van 07:00 tot 21:00] uur voor ten minste [99,9%] gegarandeerd wordt en voor de overige

uren van de week (incl. weekenden) voor ten minste [99,0%] gegarandeerd wordt.

De beschikbaarheid van test-, acceptatie- en uitwijkomgevingen van de 3D-Suite wordt op

[Werkdagen van 07:00 tot 19:00] uur voor ten minste [98,0%] gegarandeerd.

De beschikbaarheid wordt daarbij gemeten over een periode van een kwartaal.

G30 Beschikbaarheid (additioneel)

De 3D-Suite wordt ingericht zodanig dat, uitgaande van een beschikbaarheid van de infrastruc-

tuur van 100%, de beschikbaarheid van de productieomgeving van de 3D-Suite op werkdagen

van [XX] tot [XX] uur voor ten minste [XX]% is gegarandeerd en in de overige uren van de week

(incl. weekenden) voor ten minste [XX]% is gegarandeerd.

De beschikbaarheid wordt daarbij gemeten over een periode van [XX].

E19 Performance

De 3D-Suite is in staat om de medewerkers en de burgers met een acceptabele performance te

bedienen, gegeven voldoende doch realistische lokale hardware. Dat wil zeggen dat:

- In de productieomgevingen van de 3D-Suite alle interactieve gebruikersinterfaces voor rollen

eindgebruikers en functioneel beheerders in ten minste 90,0% van de gevallen binnen #2# se-

conden worden getoond.

- In de test-, acceptatie- en uitwijkomgevingen van de 3D-Suite alle interactieve gebruikersin-

terfaces van de 2D-Suite voor rollen eindgebruikers en functioneel beheerders in ten minste

90,0% van de gevallen binnen #2# seconden worden getoond.

140

G31 Performance (additioneel)

De 3D-Suite is in staat om de [XX] gebruikers van Gemeente (zie de toelichting in bijlage [XX])

met afdoende performance te bedienen, gegeven voldoende doch realistische hardware.

Dat wil zeggen dat in de productieomgeving van de 3D-Suite alle interactieve gebruikersinterfaces

van de 3D-Suite voor de rollen eindgebruikers en functioneel beheerders in ten minste [XX]% van

de gevallen binnen [XX] seconden worden getoond en de responstijd voor batchverwerkingen in

ten minste [XX]% van de gevallen maximaal [XX] seconden bedraagt.

Dit geldt zowel bij een reguliere belasting van [XX] transacties / zaken / documenten per [perio-

de] als bij een piekbelasting van [XX] transacties / zaken / documenten per [periode]. De 3D-

Suite is hiertoe ook in staat wanneer het een archief van [XX] jaar bevat dat kan worden door-

zocht (op basis van gemiddeld [XX] burgers en bijbehorende dossiers per jaar).

9.7 Beleid en (open) standaarden

E20 Beleid: open source software

Contractant conformeert zich gedurende de looptijd van de overeenkomst (incl. eventuele verlen-

ging) aan het beleid van Gemeente met betrekking tot open source software. Dit beleid is con-

form het kabinetsbeleid als vastgelegd in het actieplan Nederland Open in Verbinding (NOiV).

E21 Beleid: open standaarden (conformiteit)

Contractant conformeert zich gedurende de looptijd van de overeenkomst (incl. eventuele verlen-

ging) aan alle (open) standaarden zoals vastgelegd in het actieplan Nederland Open in Verbinding

(NOiV). Dit betreft ten minste de voor de opdracht relevante standaarden die door het Forum

Standaardisatie op de „lijst met veelgebruikte open standaarden‟ of de „lijst met open standaarden

voor pas-toe-of-leg-uit‟ zijn geplaatst (peildatum [XX]).

Contractant conformeert zich aan deze open standaarden [o.b.v. het principe van „pas-toe-of-leg-

uit‟]. Dit geldt tevens voor eventuele toekomstige nieuwe releases van deze open standaarden,

d.m.v. de eventuele toepassing daarvan (binnen [XX]) in nieuwe versies van de 3D-Suite. Daar-

naast garandeert Contractant een neerwaartse compatibiliteit van de 3D-Suite met ten minste

[XX] major versie[s] ten aanzien van deze open standaarden.

O104 Verhouding tot KING Basisgemeente

Beschrijf de mate waarin de functionele architectuur van de 3D-Suite conform KING

basisgemeente en/of GEMMA is opgezet en wordt doorontwikkeld.

S40. Beleid: open standaarden (leveranciersmanifest)

Inschrijver heeft het conformeren aan de open standaarden die door het Forum Standaardisatie

zijn aangewezen formeel vastgelegd, door het ondertekenen van het leveranciersmanifest „open

standaarden‟ van NOiV en het ondertekenen van het convenant van Operatie NUP 20.

G32 (Open) standaarden: RGBZ [versie]

Daar waar binnen de 3D-Suite zaakgegevens worden geconfigureerd, geregistreerd of in welke

20 https://new.kinggemeenten.nl/operatie-nup

141

vorm dan ook worden gebruikt of verwerkt, geschiedt dit conform het RGBZ [versie].

Het (datamodel van het) zakenmagazijn is opgezet conform het RGBZ [versie] en ondersteunt

daarmee alle objecttypen en hun respectievelijke attributen in het RGBZ, inclusief hun onderlinge

relaties.

NB: Deze wens heeft betrekking op de volledige 3D-Suite.

S41. (Open) standaarden: RSGB [versie]

Daar waar binnen de 3D-Suite gemeentelijke basisgegevens worden geregistreerd die in het RS-

GB zijn gemodelleerd of in welke vorm dan ook worden gebruikt, verwerkt of uitgewisseld, ge-

schiedt dit conform het RSGB [versie].

Het (datamodel van het) gegevensmagazijn of vergelijkbaar is opgezet conform RSGB [versie] en

ondersteunt daarmee alle objecttypen en hun respectievelijke attributen in het RSGB, inclusief

hun onderlinge relaties.

NB: Deze wens heeft betrekking op de volledige 3D-Suite.

S42. (Open) standaarden: GEMMA ZTC 2.0

Daar waar binnen de 3D-Suite zaaktypen en de bijbehorende aspecten geconfigureerd of in welke

vorm dan ook gebruikt worden, geschiedt dit - tenzij nadrukkelijk anders voorgeschreven in dit

PvE - ten minste (d.w.z. dat uitbreiding is toegestaan) conform de kenmerken zoals deze voor-

komen in de GEMMA ZTC 2.0.

S43. (Open) standaarden: StUF-ZKN

Overal waar binnen de 3D-Suite en/of tussen de 3D-Suite en externe systemen (zoals gemeente-

brede systemen, landelijke voorzieningen, etc.) zaak- en documentgegevens worden uitgewisseld,

geschiedt dit - tenzij nadrukkelijk anders voorgeschreven in dit PvE - ten minste (d.w.z. dat uit-

breiding is toegestaan) conform StUF versie [XX] met sectormodel StUF-ZKN versie [XX] (en dus

niet op een subset daarvan) of het daarvan afgeleide Zaak-DMS-koppelvlak.

Bovendien is het zakenmagazijn van de 3D-Suite o.b.v. StUF-ZKN versie [XX] en het Zaak-DMS-

koppelvlak volledig toegankelijk voor leesacties, met inachtneming van de betreffende autorisa-

ties.

O105 (Open) standaarden: Landelijke Standaard Informatieverkeer Jeugdzorg

De 3D-Suite ondersteunt de standaarden in het jeugddomein. Deze standaarden in het jeugd-

domein zijn een gegeven voor de gemeenten bij het aansluiten op de jeugdketen. De stan-

daarden zijn weergegeven in het document “ Uitgangspunten gegevensstandaarden jeugd”Dit

document is door de VNG, VWS en VEnJ vastgesteld en biedt een compleet overzicht van de

standaarden die in het jeugddomein van belang zijn. Dit betekent dat voor uitwisseling van

gegevens betreffende de jeugdzorg, -bescherming, en -straf de semantiek van de vigerende

standaarden gevolgd wordt. (jzXML resp. EBV).

G33 (Open) standaarden: MO-standaard

De 3D-Suite ondersteunt informatieuitwisseling o.b.v. het BEP-model WMO volledig 21.

21 https://www.zorgregistratie.nl/bep/wmo10/html/aa_reportstart.html

142

G34 [(Open) standaarden: overig domeinspecifiek]

[..]

O106 (Open) standaarden: overig

Beschrijf uw visie en (release)beleid - inclusief roadmap - ten aanzien van (de functionaliteiten

van de 3D-Suite op het gebied van) de ondersteuning van (open) standaarden in het algemeen en

de in deze paragraaf 9.7 genoemde (open) standaarden in het bijzonder.

Geef daarbij bovendien aan welke andere - al dan niet open - (overheids)standaarden de 3D-

Suite ondersteunt en op welke wijze, alsmede in hoeverre de ondersteuning van welke (open)

standaarden door de 3D-Suite is „bewezen‟ (bijvoorbeeld door middel van formele certificering,

positieve testresultaten op testen zoals het StUF-testplatform22, etc.) en voeg eventuele certifica-

ten, testrapporten, verwijzing naar opname in de GEMMA softwarecatalogus, etc. dienaangaande

bij.

9.8 Openheid systeem

G35 Open source tooling

Bij voorkeur wordt gebruik gemaakt van zoveel mogelijk open source tooling. Beschrijf de mate

waarin de 3D-Suite bestaat uit open source componenten (database, configuratietools, etc.) en de

mate waarin de Suite zelf open source wordt aangeboden.

O107 Delen van configuratie met andere gemeenten

Export is mogelijk, excl. vertrouwelijke gegevens, z.d.d. een import mogelijk is dat i.c.m. een ba-

sisimplementatie een werkend systeem oplevert.

Import is mogelijk, z.d.d. een import mogelijk is dat i.c.m. een basisimplementatie een werkend

systeem oplevert. Daarna is de inrichting.

22 Zie www.stuftestplatform.nl

143

10 PvE: Periodieke / doorlopende

dienstverlening

10.1 Inleiding

Dit hoofdstuk 10 bevat wensen en eisen t.a.v. de periodieke / doorlopende dienstverlening m.b.t.

de 3D-suite. Hierbij wordt een indeling gehanteerd naar verschillende typen periodieke /

doorlopende dienstverlening: training (par. 10.2), documentatie (par. 10.3), onderhoud (par.

10.4), ondersteuning (par. 10.5) en escrow (par. 10.6).

10.2 Training

E22 Training: algemeen

Contractant dient eindgebruikers en functioneel [en technisch] beheerders van Gemeente op dus-

danige wijze te trainen en van (trainings)documentatie en eventuele andere hulpmiddelen te

voorzien dat:

- Eindgebruikers geheel zelfstandig met de 3D-Suite hun werkzaamheden uit kunnen voeren.

- Functioneel [resp. technisch] beheerders geheel zelfstandig de 3D-Suite functioneel [resp.

technisch] kunnen configureren en beheren.

O108 Training: eindgebruikers en beheerders

Beschrijf de beschikbare trainingen voor (de verschillende elementen van) de 3D-Suite. Maak

daarbij ten minste onderscheid tussen de onderstaande rollen:

- Regisseur, incl. add-hoc gebruikers-/autorisatie

- Medewerkers bij uitvoeringsorganisaties

- Managers, incl. regie-op-regie

- Functioneel beheerders: Functioneel beheerders zijn verantwoordelijk voor de (functionele)

beheertaken i.h.k.v. het dagelijkse gebruik van de 3D-Suite, zoals functionele applicatie-

instellingen (incl. koppelingen, op functioneel niveau). De training van deze groep dient dan

ook met name hierop betrekking te hebben.

- [Technisch beheerders]: Technisch beheerders zijn verantwoordelijk voor de (technische) be-

heertaken i.h.k.v. de technische infrastructuur „onder‟ de 3D-Suite, incl. de installatie van

nieuwe en verbeterde versies, patches, etc., en technische applicatie-instellingen (incl. koppe-

lingen, op technisch niveau). De training van deze groep dient dan ook met name hierop be-

trekking te hebben.

Vermeld bij de beschrijving van iedere training bovendien ten minste:

- De duur (aantal dagen en sessies, incl. eventueel benodigde voorbereiding), opzet en inhoud.

- Het verondersteld kennisniveau en de mogelijkheden m.b.t. certificering.

- Het maximumaantal deelnemers (groepsgrootte).

- De mogelijkheden m.b.t. on-site training (bij Gemeente) en train-de-trainer.

- De prijs (per deelnemer en/of groep).

NB de burger dient volledig zonder training gebruik te kunnen maken van het systeem!

144

10.3 Documentatie

E23 Documentatie: taal en bestandsformaat

Alle Documentatie voor de gebruikers (medewerkers van Gemeenten) en functioneel beheerders

van de 3D-Suite is volledig Nederlandstalig en bovendien in zodanig “begrijpelijke” taal gesteld

dat ook mensen die wat minder technisch onderlegd zijn e.e.a. kunnen begrijpen. Systeem- en

andere (technische) Documentatie voor technisch beheerders van de 3D-Suite is volledig Neder-

lands- en/of Engelstalig. Alle Documentatie van de 3D-Suite wordt door Contractant aan Gemeen-

te (ook) beschikbaar gesteld in aanpasbare bestandsformaten (dus niet (alleen) als PDF en derge-

lijke).

E24 Documentatie: datamodel(len)

Een volledig gedocumenteerd, integraal datamodel van de 3D-Suite is onderdeel van de levering,

evenals volledig gedocumenteerde individuele datamodellen van de verschillende onderdelen van

de 3D-Suite(voor zover van toepassing). Deze Documentatie wordt gedurende de looptijd van de

Overeenkomst (incl. eventuele verlenging) door Contractant actueel gehouden en voor iedere

Nieuwe en Verbeterde versie van de 3D-Suite aan Gemeente opgeleverd.

E25 Documentatie: API’s

Alle API‟s waarover de 3D-Suite beschikt, worden meegeleverd en zijn gedocumenteerd.

E26 Documentatie: duplicatie

Gemeente heeft het recht om alle Documentatie van de 3D-Suite te dupliceren en te distribueren

voor intern gebruik, alsmede aan uitvoeringsorganisaties en andere partijen die voor c.q. namens

Gemeente werkzaamheden verrichten.

E27 Documentatie: eventuele toekomstige aanbesteding / migratie

T.b.v. een eventuele toekomstige aanbesteding en/of migratie (bijvoorbeeld na de beëindiging

van de Overeenkomst) verklaart Contractant zich bereid tot het verstrekken (aan Gemeente) van

alle voor het betreffende doel (migratie) relevante (aanvullende) Documentatie van de gehele 3D-

Suite, incl. alle functionele ontwerpen en beschrijvingen met inbegrip van (logische) datamodellen

en technische ontwerpen van alle relevante koppelingen. Daarnaast verklaart Contractant zich ak-

koord met de verstrekking daarvan - onder toezegging van vertrouwelijkheid - aan eventuele be-

langhebbenden in dat kader (zoals potentiële deelnemers aan een dergelijke aanbesteding, partij-

en die diensten leveren aan Gemeente op het gebied van migratie, etc.).

O109 Documentatie: algemeen

Beschrijf de beschikbare Documentatie voor de 3D-Suite. Maak daarbij (indien van toepassing)

onderscheid tussen de verschillende rollen waaronder ten minste de verschillende typen gebrui-

kers en functioneel en technisch beheerders. Vermeld bij de beschrijving van deze Documentatie

ten minste:

- Of deze generiek en/of specifiek (voor Gemeente) is en in welke taal en vorm (online, elektro-

nisch, hardcopy, etc.) deze beschikbaar is.

- De beschikbaarheid van zoekfuncties (incl. de contextgevoeligheid daarvan), wizards, etc.

- Of bij Nieuwe en verbeterde Versies van (het betreffende onderdeel van) de 3D-Suite de be-

treffende Documentatie wordt geüpdatet, incl. een begeleidende samenvatting (“what‟s new”).

145

- De mogelijkheid om elektronische Documentatie (incl. helpschermen) te wijzigen en/of aan te

vullen, incl. in welke mate dit door Gemeente zelf kan worden gedaan, alsmede of dergelijke

wijzigingen/aanvullingen intact blijven bij Nieuwe en Verbeterde Versies van de 3D-Suite.

10.4 Onderhoud

E28 Onderhoud: algemeen

Contractant garandeert de toekomstige (door)ontwikkeling en Ondersteuning van de gehele 3D-

Suite - dus incl. koppelingen etc. - gedurende de looptijd (incl. eventuele verlening) van de Over-

eenkomst, zonder additionele kosten. D.w.z. dat Contractant gedurende de looptijd (incl. even-

tuele verlenging) van de Overeenkomst verantwoordelijk is voor het correct en probleemloos

(blijven) functioneren en kunnen (blijven) gebruiken en beheren van de gehele 3D-Suite, alsmede

voor het installeren (door middel van expliciete (gedocumenteerde) installatie-instructies, -

scripts, etc.) en configureren van Nieuwe en Verbeterde versies van de gehele 3D-Suite, waaron-

der major- en minorreleases, (beveiligings)patches, updates, etc.

Als zodanig is ten minste vereist dat de gehele 3D-Suite “meegroeit” met alle ontwikkelingen op

het gebied van de betreffende wet- en regelgeving, wijzigingen in onderliggende technologieën en

platforms (zoals besturingssystemen, server- en DBMS-platforms, etc.), wijzigingen in de vrouw-

tjes van koppelingen, etc.

Contractant is tevens verantwoordelijke voor het afsluiten van alle eventuele contracten met Toe-

leveranciers voor alle Onderhoud en Ondersteuning die nodig zijn voor het correct en probleem-

loos (blijven) functioneren en kunnen (blijven) gebruiken en beheren van de gehele 3D-Suite.

De volledige bovenstaande garantie is van toepassing op alle voor het correct en probleemloos

(blijven) functioneren en kunnen (blijven) gebruiken en beheren van de gehele 3D-Suite benodig-

de software en is onafhankelijk van de wijze waarop softwareleveranciers in de aanbieding parti-

ciperen.

O110 Onderhoud: domeinkennis

Beschrijf hoe Contractant invulling geeft aan het garanderen van Onderhoud en toekomstige

(door)ontwikkeling van de 3D-Suite, zodanig dat dit “meegroeit” met alle ontwikkelingen op het

gebied van de betreffende wet- en regelgeving (zie o.a. E11), incl. geleverde content.

Geef daarbij aan welke activiteiten daartoe door welke partij(en) - Hoofdaannemer en/of kennis-

partner(s) zoals Onderaannemer(s) en/of Toeleverancier(s) - worden ondernomen, incl. de wijze

waarop wet- en regelgeving en andere relevante ontwikkelingen m.b.t. het sociale domein “ge-

monitord” worden en door wie en hoe deze domeinkennis binnen de betreffende organisatie(s)

geborgd is.

Indien er sprake is van één of meer van dergelijke (kennis)partners: beschrijf op welke wijze de

bestendigheid van de relatie met deze partij(en) is geborgd - met name in het kader van het On-

derhoud m.b.t. wet- en regelgeving - zowel in juridische als in commerciële zin. Beschrijf in dat

geval tevens op welke wijze van de relatie met deze partij(en) is geborgd in functionele en techni-

sche zin (t.a.v. de “interoperabiliteit” van de software van elk van de betreffende partijen, incl. ).

Indien één of meer van de applicatie(module)s, add-ons, (configuratie)tools, etc. van de 3D-Suite

open source zijn: beschrijf - indien van toepassing - welke commerciële partij(en) betrokken is /

zijn bij (door)ontwikkeling, Onderhoud en Ondersteuning daarvan. Ga daarbij tevens in op de wij-

146

ze waarop de “regie” daarop geregeld is en hoe de continuïteit van de betreffende software gega-

randeerd is.

10.5 Ondersteuning

G36 Ondersteuning: kennisbank

G36.1

Voor de Ondersteuning van functioneel (applicatie)beheerders bij Gemeente stelt Contractant een

online kennisbank beschikbaar met veelgestelde vragen (FAQ‟s).

G36.2

De antwoorden op vragen die meer dan één keer gesteld zijn bij de Helpdesk (door Gemeeen/nte

of andere klanten), worden door Contractant in deze kennisbank opgenomen.

G36.3

Wanneer een vraag vervolgens nog steeds gesteld wordt bij de Helpdesk, worden de betreffende

antwoordtekst en de bijbehorende zoekingangen verbeterd.

G36.4

In de kennisbank zijn ook “work-arounds” voor bekende problemen met de 3D-Suiteopgenomen,

alsook de wijzigingen (releases en andere vormen) die beschikbaar zijn om deze problemen te

verhelpen.

G36.5

Bovendien worden in deze kennisbank “tips & trucs” in bijgehouden - op basis van ervaringen van

gebruikers - en biedt deze kennisbank op gestructureerde wijze toegang tot de Documentatie en

instructiemateriaal.

10.6 Escrow

E29 Escrow

Escrow omvat het bij dezelfde partij als de 3D-Suite in depot geven en actueel houden (ten min-

ste voor elke major release) van alle Code en Documentatie van de 3D-Suite van Contractant en

eventuele Onderaannemers, met het oog op de nakoming van de verplichtingen op grond van de

Overeenkomst (zoals Onderhoud). Dit teneinde de continuïteit van de Gemeentelijke Dienstverle-

ning te garanderen ook in het geval van bijvoorbeeld een faillissement.

Contractant draagt de verantwoordelijkheid dat alle Code van de 3D-Suite, incl. eventuele aan-

vullende software die daartoe benodigd is, o.b.v. gedeponeerde gedetailleerde instructies van

Contractant één maal per jaar wordt gecompileerd en geverifieerd door voornoemde partij (op

een locatie van deze partij), waarbij alle bevindingen en resultaten van de compilatie en verifica-

tie aan Gemeente worden gerapporteerd. Contractant is verantwoordelijk voor een positief resul-

taat van de compilatie en verificatie.

Voordat de compilatie- en verificatieprocedure begint, wordt er gecontroleerd of alle Code en an-

dere materialen (incl. Documentatie) in het depot aanwezig zijn. T.b.v. van de compilatie en veri-

ficatie wordt vervolgens alle benodigde Systeemsoftware geïnstalleerd en worden de gedeponeer-

de materialen, incl. eventuele aanvullende software die daartoe benodigd is, gecompileerd op ba-

sis van de gedeponeerde gedetailleerde instructies. Voor onderdelen van de 3D-Suite die geleverd

worden door Toeleveranciers, waarvan de Code dus niet bij voornoemde partij gedeponeerd is,

verschaft Contractant zo nodig de betreffende software incl. Licenties voor de duur van de compi-

latie- en verificatieprocedure. Het behoort in dit kader bovendien nadrukkelijk tot de verantwoor-

147

delijkheden van Contractant dat eventuele Toeleveranciers, met het oog op continuïteit, de Code

van hun software gedeponeerd hebben bij een onafhankelijke partij.

Code omvat alle broncode van de 3D-Suitevan Contractant en eventuele Onderaannemers, bij-

voorbeeld geschreven in een programmeer- of scripttaal, incl. beschrijvingen/documentatie van

de benodigde inrichting (van gegevens, processen, logica en dergelijke) waaronder de inrichting

van RDBMS‟en, inclusief alle benodigde leesbare en binaire bestanden (met inbegrip van afbeel-

dingen). Daarnaast omvat Code alle tools en scripts (incl. beschrijvingen/documentatie hiervan)

die nodig zijn om deze broncode te onderhouden en te executeren.

148

11 PvE: Eenmalige dienstverlening

11.1 Inleiding

Dit hoofdstuk bevat wensen en eisen t.a.v. de eenmalige dienstverlening m.b.t. (de implementatie

van) de 3D-suite. Hierbij wordt een indeling gehanteerd naar de verschillende aspecten

dienaangaande.

NB: Zoals uiteengezet in de inleiding van dit document is het onderhavige Programma van Eisen

geen volledig bestek voor de verwerving van een 3D-Suite, dat bevat immers onder meer een

gedetailleerde beschrijving van (de scope van) de aan te besteden opdracht omvat. In een

dergelijke opdrachtomschrijving dienen begrippen als (de verschillende onderdelen van de)

implementatie, migratie, etc. nader gedefinieerd te worden, al naar gelang de specifieke

voorkeuren dienaangaande van de betreffende Gemeente.

Ook kan de gemeente desgewenst een fasering / plateauplaning eisen / vragen, zie ook hoofdstuk

3.

11.2 Algemeen

E30 Algemeen: Nederlandstalig

Alle aan Contractant (incl. eventuele Onderaannemers) gerelateerde personen, die betrokken zijn

bij contacten met Gemeente (zoals projectmanagers, projectleiders, functionele / technische ont-

werpers, functionele / technische architecten, docenten, etc.), spreken en schrijven Nederlands op

ten minste taalniveau B1.

E31 Algemeen: vervanging van Personeel

Terzake van de uitvoering van de Overeenkomst wordt door Contractant (incl. eventuele Onder-

aannemers) steeds het in het Projectplan genoemde Personeel ingezet. Behoudens uitdiensttre-

ding of langdurige ziekte van het genoemde Personeel, kan vervanging van het genoemde Perso-

neel op initiatief van Contractant slechts bij hoge uitzondering plaatsvinden.

Bij vervanging op initiatief van Contractant (incl. uitdiensttreding, excl. langdurige ziekte) van een

personeelslid dat korter dan één (1) jaar werkzaamheden in het kader van de Overeenkomst

heeft verricht, verbeurt Contractant een Boete van ###. Heeft het betreffende personeelslid tus-

sen de één (1) en twee (2) jaar werkzaamheden in het kader van de Overeenkomst verricht, dan

verbeurt Contractant een Boete van ###.

E32 Algemeen: continuïteit maatwerk

Eventueel Generiek Maatwerk dient - zonder extra kosten - opgenomen te worden in de 3D-Suite

en dient als zodanig blijvend te worden ondersteund in alle volgende Nieuwe en Verbeterde Ver-

sies - waaronder (major- en minor)releases - van (de betreffende onderdelen van) de 3D-Suite.

Hiermee wordt al het eventuele Generiek Maatwerk derhalve beschouwd als “nog niet ontwikkelde

standaardfunctionaliteit” van de 3D-Suite.

11.3 Implementatie

In deze paragraaf worden t.z.t. de eventuele eisen en/of wensen opgenomen rond de

implementatiefasering, een grove implementatiebeschrijving, en met name ook acceptatie, etc.

Omdat dit sterk afhangt van de specifieke situatie van de betreffende gemeente(n), kan e.e.a. pas

149

ingevuld worden op het moment dat het daadwerkelijke bestek ten

behoeve van de aanbesteding voor een gemeente of groep van gemeenten wordt opgesteld.

11.4 Migratie

In deze paragraaf worden t.z.t. de eventuele eisen en/of wensen opgenomen voor de eventuele

migratie van gegevens uit de huidige syste(e)m(en) van Gemeente en misschien zelfs van

bestaande ketenpartners naar de 3D-Suite. Omdat dit sterk afhangt van de specifieke situatie van

de betreffende gemeente(n), kan e.e.a. pas ingevuld worden op het moment dat het

daadwerkelijke bestek ten behoeve van de aanbesteding voor een gemeente of groep van

gemeenten wordt opgesteld.

11.5 Concept Plan van Aanpak

In deze paragraaf worden t.z.t. de eventuele eisen en/of wensen opgenomen voor het PvA, incl.

eventuele deelplannen en fasering, incl. wat van gemeente en van ketenpartners wordt verwacht.

Een generiek plan van aanpak is o.i. weinig zinvol (dan volgt enkel een standaardmethodiek), dus

zal vooral gevraagd worden naar de specifieke problemen en de gewenste situatie en fasering.

Omdat dit sterk afhangt van de specifieke situatie van de betreffende gemeente(n), kan e.e.a. pas

ingevuld worden op het moment dat het daadwerkelijke bestek ten behoeve van de aanbesteding

voor een gemeente of groep van gemeenten wordt opgesteld.

150

12 Bijlagen

12.1 Zaakgericht werken

Veel Gemeenten hebben tegenwoordig het zaakgericht werken als uitgangspunt bij de inrichting

van haar dienstverlening en van andere processen. Een zaaksysteem omvat - naast de

kernfunctionaliteiten rondom het registreren, beheren, bewaken en volgen van zaken - ook

functionaliteiten voor de daadwerkelijke behandeling daarvan. Hiertoe beschikt het zaaksysteem

over verschillende gebruikersinterfaces zoals een werklijst (zaakbak/werkvoorraad, doorgaans

samen met een KCS-achtige interface met zoekfunctionaliteit en dergelijke geaggregeerd tot een

soort medewerkersportaal), behandelschermen, etc.

In een zaaksysteem worden de verschillende zaaktypen incl. hun specifieke kenmerken (zoals

doorlooptijden en bewaartermijnen) d.m.v. zogeheten Zero Coding geconfigureerd en opgeslagen

in een soort centrale „bibliotheek‟, de Zaaktypencatalogus, bij voorkeur o.b.v. KING ZTC 2.0. Zie

daartoe www.kinggemeenten.nl/ztc/ztc-20

Die ZTC 2.0 speelt een centrale rol binnen het zaaksysteem. Hierin worden alle zaaktypen

geconfigureerd zonder dat daarbij handelingen verricht hoeven te worden die kennis van

programmeer-/scripttalen, flowcharting, scherm-/formulierontwerp, etc. vereisen (Zero Coding).

Doel hiervan is dat gemeenten zelf in korte tijd additionele zaaktypen kunnen configureren, zowel

voor externe als voor interne processen. Een specifieke zaaktypeconfiguratie in de ZTC 2.0

definieert onder meer de volgende aspecten:

- Zaaktype (omschrijving, versie, norm- en streefdoorlooptijden, bewaartermijn, etc).

- Statussen (incl. doorlooptijden, statusberichten, etc. per status).

- Autorisaties (rollen en rechten).

- (Behandel)schermen incl. checklist, per status en resultaattype.

- Al dan niet verplichte documenttypen en zaakattributen, per zaaktype en per status.

- Mogelijke deel- en vervolgzaaktypen, resultaat- en besluittypen, etc.

Bij complexere zaaktypen waarvoor het relatief eenvoudige „Dordtse model‟ - met een beperkt

aantal seriële statussen - niet toereikend is, is bovendien behoefte aan ondersteuning met

geavanceerde processturing binnen het zaaksysteem. Bijvoorbeeld met workflowmanagement of

soortgelijke functionaliteit zoals een geavanceerde hiërarchie van (hoofd- en deel)zaken. Dit geldt

bijvoorbeeld voor complexe processen als de omgevingsvergunning (WABO) en bestuurlijke

besluitvorming.

Belangrijk i.h.k.v. de 3D-Suite is dat dit niet betekent dat een zaak(type) een specifiek aantal

stappen / taken, of een starre volgorde daarbij dicteert. Binnen een beperkt aantal hoofdstatussen

kan een regisseur ad-hoc, runtime, voor een specifieke zaak aanvullende deelzaken toevoegen,

bijvoorbeeld een deelzaak per doel of taak van een uitvoeringsinstantie.

Steeds speelt zero coding een belangrijke rol, bij voorkeur op basis van de ZTC 2.0. Een tweede

belangrijk concept is overerving: wanneer informatie is vastgelegd voor de hoofdzaak, dan kan de

informatie worden overgeërfd door de deelzaken en vervolgens alle taken en documenten

daarbinnen.

Ook kan voor complexere zaaktypen kan - in aanvulling op zero coding van eenvoudige, seriële

(„Dordtse‟) processen via de ZTC 2.0 - zo nodig voorlopig nog een eigen, gebruikersvriendelijke

(d.w.z. grafische) ontwerpomgeving gebruikt worden. Op termijn dient deze functionaliteit echter

151

zoveel mogelijk geïntegreerd te worden met de ZTC 2.0. Ook als er voor

processturing workflowmanagement of soortgelijke functionaliteit gebruikt wordt, worden alle

overige aspecten van de zaaktypeconfiguratie (zoals zaakattributen, checklists, documenttypen,

etc.) bij voorkeur door middel van zero coding via de ZTC 2.0 geconfigureerd.

De bijbehorende documenten worden als één zaakdossier opgeslagen, ontsloten en t.z.t.

gearchiveerd of vernietigd. Dit kan gebeuren in de 3D-Suite zelf, of in een 3P DMS/RMA- of

zaaksysteem.

Overige (gestructureerde) „zaakgerelateerde‟ gegevens worden opgeslagen in het zakenmagazijn,

rechtstreeks of als een verwijzing naar (basis)gegevens in het gegevensmagazijn (zie verderop).

Het zakenmagazijn dient hiertoe te worden ingericht conform het RGBZ. Binnen het zaaksysteem

kan gewerkt worden met zaak- en andere relevante informatie in een geografische context

(kaartjes).

12.2 Overzicht gegevens in Digitaal Klantdossier / Suwinet

In de Suwiketen is de GeVS (Gezamenlijke elektronische Voorzieningen Suwi) ontwikkeld Via dit

knooppunt is informatie uit verschillende bronnen (zoals GBA, UWV, DUO, RDW, Kadaster)

ontsloten en wordt deze informatie beschikbaar gesteld aan de Suwiketenpartijen (SVB, UWV en

gemeenten). Met behulp van deze gegevens wordt het DKD (het DigitaalKlantDossier) gevormd en

via een webapplicatie getoond. Het DKD zelf is geen bron maar een virtueel dossier dat uit de

aangesloten bronnen wordt opgebouwd. Geautoriseerde afnemers kunnen ook rechtstreeks

aansluiten op de GeVS (via de component Suwinet-Inlezen) om de brongegevens zelf in „eigen‟

applicatie te verwerken.

Momenteel is o.a. de volgende informatie over personen aanwezig:

GBA-gegevens

- Actuele persoonsgegevens

- Actuele en historische adresgegevens

- Huwelijk / geregistreerde partnerschap

- Actuele persoonsgegevens ouder(s)

- Actuele persoonsgegevens kind(eren)

- Gezagsverhouding

- Actuele persoonsgegevens inwonenden (adresvraag)

UWV Polisadministratie

Actuele inkomsten- en uitkeringsgegevens / dienstverbanden

- Datum aanvang inkomstenverhouding

- Bruto/fiscaal inkomen

- Naam werkgever / uitkeringsinstantie

(Dit betreft niet inkomsten uit alimentatie, niet-fiscale inkomsten of inkomsten uit zelfstandige

werkzaamheden

Sociale verzekeringsbank

- Recht op kinderbijslag waaronder de indicatie uit- thuiswonend

- Recht en hoogte ANW

152

- Recht en hoogte waaronder indicatie toeslag AOW en percentage AOW

- Recht en hoogte AIO

UWV en re-integratie

- Recht en hoogte WAO

- Recht en hoogte WIA

- Recht en hoogte Wajong

- Recht en hoogte WAZ

- Recht en hoogte ZW

- Recht en hoogte WW

- Recht en hoogte TW

- Maatregelen en kortingspercentage op uitkeringen

- Gegevens met betrekking tot re-integratie (zowel vanuit UWV als vanuit gemeentelijke re-

integratieapplicatie)

- Inschrijving als werkzoekenden (datums)

Gemeentelijke Sociale Diensten

- Recht en hoogte WWB

- Recht en hoogte Ioaw

- Recht en hoogte Ioaz

- Recht en hoogte bijzondere bijstand

- Recht en hoogte Langdurigheidstoeslag

- Opgelegde maatregelen

- (Terug)vorderingen

Rijksdienst voor het Wegverkeer (Actuele voertuigen- en caravanbezit)

- Motorvoertuigen (soort, type, merk, kenteken en datum eerste inschrijving)

- Verzekeringsgegevens verzekering voertuig

- Aanhangwagens (soort, type, merk) waaronder caravans

Handelsregister

- Bedrijfs- en vestigingsgegevens

- Eigenaren

- Rechtspersonen

Dienst uitvoering onderwijs

DUO verstrekt gegevens met betrekking tot studiefinanciering WSF en WTOS.

- Informatie over studiefinanciering inclusief de indicatie thuiswonend/uitwonend

- Indicatie aanvullende studiefinanciering (bedrag)

- Indicatie lening (bedrag)

- Gegevens met betrekking tot opleiding en diploma‟s

Kadaster

- Informatie over het kadastraal object waaronder type, locatie, toestand, datum aankoop, be-

drag koopsom, eigenaren en de wijze van verkrijging.

153

De GeVS (Gezamenlijke elektronische voorzieningen Suwi) waar het DKD

gebruik van maakt, is bijv. v.w.b. GBA-gegevens gekoppeld aan de GBA-V. Op basis van een

persoonsvraag of adresvraag worden gegevens geleverd. Het agentschap BPR (bronhouder) heeft

op basis van de Suwitaken bepaald welke gegevens geleverd mogen worden. Dit zijn gegevens

zoals persoonsgegevens ingeschrevene, kinderen, ouders en voorgaande adressen. Ook “onder

curatelestelling” is beschikbaar. De brongegevens die via de GeVS worden opgevraagd worden

door de GeVS eerst vertaald naar een SuwiML-bericht.

De gegevens kunnen worden ingezien via Suwinet-inkijk, de webapplicatie voor het DKD of kan via

een gemeentelijke applicatie worden opgevraagd, dan wordt het bericht via Suwinet-inlezen

doorgestuurd naar de gemeente c.q. de 3D-Suite. Alle berichten die worden ontvangen van externe

bronhouders worden altijd vertaald naar een SuwiML bericht alvorens het aan de afnemer

beschikbaar gesteld wordt (hetzij via Suwinet-Inkijk, hetzij via Suwinet-Inlezen.

- www.bkwi.nl/producten/suwinet-services geeft een overzicht van de services die Suwinet biedt

waar primair Suwinet-Inlezen relevant zal zijn.

- www.bkwi.nl/producten/suwinet/suwinet-inlezen/matrices geeft een overzicht van wie momen-

teel toegang zou kunnen hebben tot welke gegevens.

- www.bkwi.nl/producten/suwinet/suwinet-standaarden/suwi-gegevens-register-sgr/sgr-suwiml

geeft een beschrijving van het Suwi Gegevensregister en van SuwiML.

12.3 Voorbeeldinrichting

Onderstaand volgt een voorbeeld van de gegevens die bij het gebruik van de 3D-Suite moeten

worden geregistreerd.

12.3.1 Functionele informatie-eenheden

Aanmelding

Aanmelding is het resultaat van de aanmeldingsfunctie. Een aanmelding kan op verschillende

manieren worden gebruikt, afhankelijk van wie de aanmeldingsfunctie uitvoert en afhankelijk van

het moment in het traject waarop de aanmelding plaatsvindt. Zo is er de melding van burger zelf.

Maar ook bijvoorbeeld een familielid of instantie (bijv. verslavingszorg) kan een cliënt aanmelden.

In al deze gevallen is sprake van een aanmelding, waarin de volgende informatie-elementen

voorkomen:

- Datum: de datum waarop de aanmelding wordt gedaan, de aanmeldingsdatum.

- Cliënt: de cliënt die aangemeld wordt.

- Aanmelder: de partij (instantie of persoon) die de aanmelding doet. Dit kan ook de cliënt zelf

zijn.

- Hoedanigheid Aanmelder: Aanduiding van de aard van de aanmelder, instantie, ouder, cliënt

zelf of politie.

- Ontvanger: de instantie waarbij aangemeld wordt, die dus moet handelen op de aanmelding.

- Verzoek: een indicatie van de soort handeling die de ontvanger van de aanmelding geacht

wordt te ondernemen d.m.v. een verwijzing naar een functie, bijv. Intake, Onderzoek, etc.

- Toelichting: korte beschrijving van het gesignaleerde probleem of de gerezen zorgen ter moti-

vatie van de aanmelding.

- Bijlagen: zo nodig kunnen additionele documenten als bijlage toegevoegd worden.

154

Intakeverslag

Intakeverslag is het resultaat van de intakefunctie. Dit verslag documenteert de bevindingen van

de intake. In veel gevallen wordt deze informatie-eenheid gecombineerd met een besluit over de te

nemen vervolgstappen.

De volgende informatie-elementen komen voor in het Intakeverslag.

- Datum: de datum waarop het Intakeverslag is samengesteld.

- Cliënt: de cliënt ten behoeve van wie de intake gedaan is.

- Intaker: een combinatie van instantie en persoon, die de intake heeft gedaan.

- Bevindingen: een document met daarin de uitkomsten van de intake.

- Bijlagen: zo nodig kunnen additionele documenten als bijlage toegevoegd worden.

Onderzoeksverslag

Een Onderzoeksverslag is het resultaat van de functie Onderzoek. Het Onderzoeksverslag

documenteert de conclusies van het Onderzoek, waarin beschreven wordt wat er precies aan de

hand is met een cliënt of binnen een klantsysteem. Is er een probleem, wat is dat probleem,

waardoor wordt het veroorzaakt of in stand gehouden en in hoeverre kan de cliënt op eigen kracht

verbetering bereiken in de situatie? Het Onderzoeksverslag voorziet in het zogenaamde integrale

„klantbeeld‟, een overzicht van wat er binnen het zorg- en welzijnsdomein bekend is over de cliënt.

De inhoud van het klantbeeld wordt niet gestandaardiseerd, maar het ligt voor de hand om dit, in

het kader van multi-problematiek voor zorg en welzijn, vorm te geven aan de hand van

leefdomeinen (bijv. Wonen, Werken, Onderwijs/scholing, Financiën/schulden, etc.). Het

Onderzoeksverslag bestaat uit een stuk vrije tekst waarin het onderzoeksresultaat kort wordt

samengevat, het klantbeeld en eventuele bijlagen (vragenlijsten, inventarisaties, specialistische

diagnoses, etc.) ter ondersteuning van die conclusie.

De volgende informatie-elementen komen voor in het Onderzoeksverslag.

- Datum: de datum waarop het Onderzoeksverslag is samengesteld.

- Cliënt: de cliënt ten behoeve van wie het onderzoek gedaan is.

- Onderzoeker: een combinatie van instantie en persoon, die het onderzoek heeft gedaan.

- Bevindingen: een document met daarin de uitkomsten van het onderzoek.

- Klantbeeld: een overzicht en samenvatting van wat er binnen het zorg- en welzijnsdomein be-

kend is over de cliënt.

- Bijlagen: zo nodig kunnen additionele documenten als bijlage toegevoegd worden.

Doelen

Doelen zijn het resultaat van de Doelstelling-functie. Daarin worden de doelen geformuleerd die

gesteld worden in een traject. Doelen moeten zowel met vrije tekst als volgens een

gestandaardiseerde doelenclassificatie gespecificeerd kunnen worden. De volgende informatie-

elementen komen daarin voor.

- Datum: de datum waarop de doelen zijn opgesteld.

- Cliënt: de cliënt op wie de doelen betrekking hebben.

- Doelsteller: een combinatie van instantie en persoon, die de doelen heeft opgesteld.

- Doelen: een of meer doelen ten aanzien van de te leveren ondersteuning.

155

Ondersteuningsarrangement

Het Ondersteuningsarrangement is het resultaat van de Maatregel-selectie-functie. Het

Ondersteuningsarrangement identificeert de ondersteuningsmaatregels die voor een cliënt

geselecteerd zijn, bijv. uitkering verstrekken, schuldhulpverlening en leefstijltraining.

De volgende informatie-elementen komen voor in het Ondersteuningsarrangement.

- Datum: de datum waarop deze informatie-eenheid samengesteld is.

- Cliënt: de cliënt die de beoogd ontvanger van het ondersteuningsarrangement is.

- Samensteller: een combinatie van instantie en persoon, die het ondersteuningsarrangement

samenstelt.

- Arrangement: één of meer geselecteerde ondersteuningsmaatregelen voor de cliënt.

Ondersteuningsplan

Het Ondersteuningsplan is het resultaat van de Planning-functie. Het Ondersteuningsplan bevat het

plan om de daadwerkelijke ondersteuning aan de cliënt te leveren.

De volgende informatie-elementen komen voor in het Ondersteuningsarrangement.

- Datum: de datum waarop het ondersteuningsplan is opgesteld.

- Cliënt: de cliënt waarop het ondersteuningsplan betrekking heeft.

- Opsteller: de combinatie van persoon en instantie die het ondersteuningsplan heeft opgesteld.

- Plan: een document waarin het plan beschreven staat.

- Instemming Cliënt: een indicatie of de cliënt met het plan heeft ingestemd en zo nodig de re-

actie van de cliënt op het plan.

Voortgangsrapportage

De Voortgangsrapportage is een uitkomst van de Ondersteuning-functie. De Voortgangsrapportage

wordt gebruikt om te rapporteren over de verleende ondersteuning in een ondersteuningstraject

traject.

De volgende informatie-elementen komen voor in de Voortgangsrapportage.

- Datum: de datum waarop de Voortgangsrapportage samengesteld is.

- Cliënt: de cliënt waarop de verleende ondersteuning betrekking heeft. Dit hoeft niet altijd de

daadwerkelijke ontvanger van de ondersteuning zijn. Bijvoorbeeld, de cliënt kan een kind zijn,

maar de verleende ondersteuning kan op de ouders ervan zijn gericht (bv. opvoedingsonder-

steuning). De ouders worden in dat geval opgenomen als „Ondersteuningontvangers‟.

- Ondersteuningontvangers: De pers(o)on(en) die de daadwerkelijke ondersteuning ont-

vang(t/en), indien anders dan de cliënt. Bijv. een ouder, broer of het hele gezin.

- Ondersteuner: de combinatie van de instantie en de (contact)persoon die de ondersteuning

heeft geleverd.

- Ondersteuningstraject: informatie over het geleverde ondersteuningstraject, zoals startda-

tum, einddatum en eventuele classificatie.

Evaluatieverslag

Het Evaluatieverslag is het resultaat van de Evaluatie-functie. Dit rapport documenteert de

inhoudelijke evaluatie van de uitkomsten van een ondersteuningstraject.

De volgende informatie-elementen komen voor in het Evaluatieverslag.

- Datum: de datum waarop het ondersteuningstraject is geëvalueerd, de evaluatiedatum.

- Traject: het traject waarop de evaluatie betrekking heeft.

156

- Evaluator: degene die de evaluatie met de cliënt heeft gedaan.

- Doelrealisatie: een indicatie van de mate waarin de doelen van het traject zijn behaald.

- Bijlagen: het evaluatieverslag zelf en eventuele andere lijsten en documenten.

Besluit

Een besluit is het resultaat van de secundaire functie Besluitvorming. Hierin kunnen zowel formele

(bijvoorbeeld gerechtelijke uitspraken in het kader van schulden) als informele besluiten worden

opgenomen. Er wordt rekening gehouden met eventuele toestemming die nodig zijn (bv.

toestemming van ouders indien het ondersteuningstraject een jongere betreft). Ook is er ruimte

voor beroep en bezwaar tegen een besluit. De volgende informatie-elementen komen voor in een

Besluit:

- Datum: de datum waarop dit besluit genomen is.

- Nummer: besluitnummer of een andere vorm van identificatie voor het genomen besluit.

- Soort: een indicatie van de (juridische) status van een besluit Bijvoorbeeld een indicatiebesluit,

gerechtelijk besluit (bijv. tot opleggen maatregel), een verwijzingsbesluit, etc.

- Uitspraken: een of meer bij dit besluit horende uitspraken waarin adviezen, rechten en plich-

ten worden afgegeven.

- Autoriteit: de instantie onder wiens verantwoordelijkheid het besluit is genomen. De personen

die het besluit genomen hebben, worden opgenomen onder toestemmingen.

- Ingangsdatum: de datum waarop het besluit en de daaruit voortvloeiende rechten en plichten

van kracht worden. Dit kan opengelaten worden indien dit nog niet bekend is.

- Toestemmingen: de verzameling van expliciete accorderingen voor het besluit.

- Bezwaren: de verzameling van expliciete bezwaren tegen het besluit.

- Status: de huidige status van het besluit. Is het voorgenomen, voorlopig, definitief, in behan-

deling?

12.3.2 Generieke informatie-elementen

In de specificatie van de functionele informatie-eenheden wordt gebruik gemaakt van meer

elementaire informatie-elementen. Hier specificeren we een aantal van de meer generieke

informatie-elementen nader. Dit zijn informatie-elementen die in meer dan een functionele

informatie-eenheid gebruikt worden. Het zijn de woorden of begrippen waaruit de functionele

informatie-eenheden zijn opgebouwd. Zij vormen het vocabulaire van de 3D-Suite.

Traject

Het idee achter deze schets van de 3D-Suite is dat er rondom een cliënt diverse

ondersteuningstrajecten kunnen lopen (mogelijk bij verschillende instellingen), en dat relevante

informatie over deze ondersteuningstrajecten kan worden uitgewisseld. Figuur 11 illustreert hoe,

op basis van trajecten, een regievoerder een overzicht kan krijgen over lopende

ondersteuningstrajecten bij diverse ondersteuners op basis van informatieuitwisseling.

Ondersteuningstrajecten kunnen elkaar daarbij overlappen in de tijd, en er kunnen meerdere

ondersteuningstrajecten binnen een klanttraject worden uitgevoerd.

157

Figuur 11 Illustratie van informatieuitwisseling tussen trajecten

Binnen ieder traject vinden de eerder genoemde primaire functies plaats, ondersteund door de

secundaire functies (zie par. 5.1.2). Een Traject bevat de volgende eigenschappen:

- Identificatie: een code aan de hand waarvan het traject geïdentificeerd kan worden.

- Soort: een indicatie van het soort traject volgens een gestandaardiseerde classificatie, bijv.

AWBZ-traject, Schuldsaneringtraject, Verslavingsbehandeling, Jeugdzorgtraject. Het soort tra-

ject wordt nader gespecificeerd door de doelen en componenten hieronder.

- Cliënt: de cliënt waar het traject over gaat.

- Verantwoordelijke: diegene (persoon en instantie) die verantwoordelijk is voor het beheer en

uitvoering van (dit deel van) het traject, bijv. een wijkcoach of case-manager.

- Periode: de periode waarin het traject actief is (geweest). Combinatie van start- en einddatum.

- Doelen: de op dit traject van toepassing zijnde doelen.

- Ondersteuningsarrangement: indien van toepassing, het voor dit traject geselecteerde On-

dersteuningsarrangement.

- Reden Beëindiging: optioneel een indicatie van de reden waarom het traject beëindigd is.

- Bovenliggend Traject: verwijzing naar bovenliggend traject, d.w.z. het traject waar dit traject

onderdeel van is, indien bekend.

- Deeltrajecten: verwijzing naar deeltrajecten van dit traject, indien bekend.

- Besluiten: de op dit traject van toepassing zijnde besluiten.

- Dossier: de verzameling van gegevens en besluiten die zijn vastgesteld tijdens dit traject, be-

staande uit documenten en uitgewisselde berichten. Trajecten kunnen verwijzen naar bovenlig-

gende of deeltrajecten, die op hun beurt ook weer een Dossier kunnen bevatten. Het is een im-

plementatiekeuze of hierin alleen documenten worden opgenomen die bij het gegeven traject

horen, of dat hierin ook documenten uit andere trajecten gedupliceerd mogen worden.

Gezin

Een Gezin bestaat uit Personen die wel of niet Cliënt zijn (zie hierna).

Cliënt

Een Cliënt is een Persoon (zie hierna), eventueel voorzien van een klantnummer of -kenmerk.

Ondersteuningstraject A.1 Ondersteuningstraject A.2

Ondersteuningstraject B.1

Ondersteuner A(bijv. Stadsbank)

Ondersteuner B(bijv. Tactus:

verslavingszorg)

Clienttraject

Info-

uitwisseling

Regievoerder

tijd

158

Persoon

Een Persoon is een individu, bijvoorbeeld een cliënt, een ondersteuner die werkzaam is bij een

instantie, of een familielid van de cliënt.

Een Persoon bezit de volgende eigenschappen.

- Identificatie: Een of meer (bij voorkeur meer) identificatiecodes voor de persoon. Denk aan

BSN, of een ander identificatienummer.

- Naam: alle naamsgerelateerde informatie van de persoon, zoals voornamen, achternaam, ini-

tialen, etc.

- Adres: een of meerdere bekende adressen van de persoon, zoals GBA-adres, verblijfsadres.

- Contactgegevens: telefoonnummers, e-mail adressen, etc.

- Geboorte: de geboortegegevens van de persoon, d.w.z. datum, plaats, geslacht, etc.

- Overlijden: eventueel de datum en plaats van overlijden.

- Nationaliteit: de nationaliteit van de persoon.

- Herkomst: een indicatie of de persoon autochtoon of allochtoon is.

- Verblijfsstatus: indicatie of de persoon legaal of illegaal in Nederland verblijft.

- Relaties: relaties die de persoon heeft met andere personen, bijv. familieleden. Hiermee kan

bijvoorbeeld het netwerk van een cliënt beschreven worden.

Niet alle eigenschappen zijn voor iedere persoon noodzakelijk.

Persoonsrelatie

Een Persoonsrelatie is een relatie die een persoon heeft met andere personen, bijv. familieleden.

Een Persoonsrelatie bevat de volgende eigenschappen:

- Soort Relatie: een code die aangeeft welke rol de gerelateerde persoon heeft. Bijv. vader,

moeder, voogd, partner, kennis.

- Vanaf Datum: datum vanaf wanneer de relatie bestaat.

- Tot en met Datum: datum tot wanneer de relatie bestond.

- Gerelateerde Persoon: de persoon met wie de relatie bestaat of bestond.

Instantie

Een Instantie is een instelling die een rol vervult in de ondersteuning. Voorbeelden zijn een

instelling die gespecialiseerd is in verslavingszorg (bijv. Tactus), een instelling die mensen helpt

financieel zelfredzaam te zijn (bv. Stadsbank), of een instelling die gespecialiseerd is in verpleging

en thuiszorg (bv. Livio). Vaak is het van belang om ook onderdelen, vestigingen of locaties van

instellingen te identificeren. Daarom biedt het informatiemodel de mogelijkheid om aan te geven of

een instantie onderdeel is van een andere instantie.

Van een instantie kunnen de volgende eigenschappen uitgewisseld worden.

- Identificatie: Code die een instantie of een onderdeel daarvan identificeert.

- Onderdeel van: Aanduiding van welke andere instantie een instantie deel uitmaakt.

- Soort Instantie Code: De aanduiding van de aard van de instantie (bijvoorbeeld een code

voor „thuiszorg‟ of „verslavingszorg‟).

- Naam: de naam van de instantie.

- Adres: het adres van de instantie

- Contactgegevens: telefoonnummers, etc. van de instantie.

159

Doel

Een doel is een beschrijving waarin een doelsteller de beoogde situatie ten aanzien van een cliënt

formuleert. Een doel kan gekoppeld worden aan een leefgebied. Daarmee wordt aangegeven dat

het doel betrekking heeft op een bepaald leefgebied. Een doel bevat de volgende eigenschappen:

- Doelbeschrijving: een beschrijving van het beoogde doel ten aanzien van de inzet van onder-

steuning.

- Doelclassificatie: een indicatie van het soort doel volgens een gegeven classificatie van doelen

(indien aanwezig).

- Leefgebied: een indicatie van het leefgebied, of leefgebieden, waarop het doel betrekking

heeft.

Leefgebied

Een leefgebied is een aanduiding van een probleemgebied waarvoor ondersteuning kan worden

aangeboden. Voorbeelden van de leefgebieden zoals die gehanteerd worden door de Enschedese

wijkzorgteams zijn (op dit moment): Wonen, Werk, Onderwijs/scholing, Financiën/schulden,

Gezondheid/welzijn, Relaties, Recreatie/vrije tijd, Zorg/hulpverlening, Politie/justitie/gedwongen

kader. Een leefgebied bevat de volgende eigenschappen:

- Leefgebiedcode: een unieke code voor het leefgebied volgens een vastgestelde classificatie.

- Leefgebied naam: de naam van het leefgebied, bijvoorbeeld „wonen‟ of „financiën‟

N.B.1: Het PvE schrijft niet voor welke leefgebieden er moeten zijn. Wel dát er leefgebineden zijn.

Bijvoorbeeld o.b.v. de ZRM

N.B.2: Verschillende organisaties kunnen een andere naam hanteren voor het begrip „leefgebied‟

(bijvoorbeeld „categorie‟).

N.B.3: Door leefgebieden te beschrijven aan de hand van een „Leefgebiedcode‟ ontstaat een uit-

breidbaar model – nieuwe, toekomstige, leefgebieden kunnen eenvoudig worden toegevoegd.

Klantbeeld

Het onderzoeksverslag verwijst naar een klantbeeld. Een klantbeeld is het resultaat van de

Onderzoeksfunctie. Een klantbeeld bevat een overzicht en samenvatting van wat er binnen het

zorg- en welzijnsdomein bekend is over de cliënt. Het klantbeeld bevat de volgende

eigenschappen:

- Cliënt: de cliënt waar het klantbeeld betrekking op heeft.

- Klantbeeldgegevens: De beschikbare gegevens van de cliënt, opgedeeld naar leefgebied of

categorie.

Klantbeeldgegeven

Klantbeeldgegevens zijn gegevens die binnen het klantbeeld worden opgenomen. Een

klantbeeldgegeven bevat de volgende eigenschappen:

- Naam: naam van het gegeven, bijvoorbeeld „werkgevershistorie‟

- Waarde: de waarde van het gegeven, bijvoorbeeld een tabel met werkgeverhistorie-informatie.

- Herkomst: de herkomst of bron waaruit het gegeven afkomstig is, bijvoorbeeld UWV

- Leefgebied: Het leefgebied waarbinnen dit gegeven wordt ontsloten, bijvoorbeeld „werk en in-

komen‟.

160

- Betekenis: een eventuele beschrijving waarin de betekenis van het

klantbeeldgegeven wordt toegelicht.

Ondersteuningsmaatregel

Ondersteuningsmaatregelen zijn onderdeel van het geselecteerde ondersteuningsarrangement.

Informatie over een ondersteuningsmaatregel wordt gebruikt om te rapporteren over de verleende,

of te verlenen, ondersteuning. Het informatie-element ondersteuning bevat de volgende

eigenschappen:

- Cliënt: een ondersteuningsmaatregel heeft altijd betrekking op een cliënt. Soms kan het voor-

komen dat de cliënt niet zelf de ontvanger van de ondersteuning is. In dat laatste geval wordt

bij de eigenschap ondersteuningsontvanger de daadwerkelijke ontvanger vermeld.

- Ondersteuningsontvanger: De pers(o)on(en) die de daadwerkelijke ondersteuning ont-

vang(t/en), indien anders dan de cliënt. Bijv. een ouder, broer of het hele gezin.

- Ondersteuner: de combinatie van de instantie en de (contact)persoon die de ondersteuning

heeft levert.

- Ondersteuningstraject: informatie over het te leveren, of geleverde, ondersteuningstraject,

zoals het soort traject, de periode waarin het traject wordt uitgevoerd, de doelen die bij het on-

dersteuningstraject horen, etc. (zie het informatie-element Traject).

161

12.4 Voorbeeld: elementen in een zelfred-zaamheidsmatrix

Onderstaande geeft een voorbeeld van de elementen in de zelfredzaamheidsmatrix, alsook van de

visualisatie van de beoordeling daarop.

Figuur 12 zelfredzaamheidsmatrix

In bovenstaande figuur is in 1 oogopslag te zien dat er bijvoorbeeld een accuut probleem is bij

Dagbesteding maar dit wel is verbeterd. V.w.b. Fysieke gezondheid is de persoon voldoende

zelfredzaam, maar de situatie is verslechterd.

Zie voor meer http://www.zelfredzaamheidmatrix.nl/

162

12.5 Voorbeeld: klantbeeld

Onderstaand formulier beschrijft de informatie-elementen die door wijkcoaches van de gemeente

Enschede worden gebruikt.

Algemene klantinformatie

Clientgegevens

o NAW, geboortedatum, contactgegevens

Gegevens partner

o NAW, geboortedatum, contactgegevens

Gegevens kinderen

o NAW, geboortedatum

Gegevens huisarts

o NAW, contactgegevens

Aanmelder / aanmeldende organisatie

o Contactgegevens

Datum van aanmelding

Reden van aanmelding

Additionele informatie per leefgebied

Informatie per leefgebied

o Wonen

Huursituatie, betalingsachterstanden, overlastproblematiek

o Werk

Werkverleden, uitkeringssitutatie

o Onderwijs/scholing

Opleidingsverleden

o Financiën/schulden

Schuldsituatie, betrokkenheid Stadsbank

o Gezondheid/welzijn

Gezondheidssituatie, betrokkenheid GGZ/Mediant

o Relaties

Netwerkrelaties (familie, vrienden, etc.)

o Recreatie/vrije tijd

Vrijetijdsbesteding, betrokkenheid Alifa, buurtcentra

o Zorg/hulpverlening

Zorgverleden, betrokkenheid huisarts, verslavingszorg, thuisbegeleiding, Jeugd-

zorg, etc.

o Politie/justitie/gedwongen kader

Meldingen bij politie, strafrechtelijk verleden, veiligheidshuis, …

163

12.6 Voorbeeld: hoofdprocessen Awbz, Wmo en Jeugdzorg

De benoemde functies: Aanmelding, Intake, Diagnose, Doelen, Maatregelselectie, Plan van Aanpak,

Ondersteuning, Evaluatie, Nazorg zijn te plaatsen in de Waardeketen in de zorg (CVZ, 2011)

Figuur 13. Waardeketen in de zorg

De hoofdprocessen van WMO, AWBZ en Jeugdzorg zullen niet (wezenlijk) veranderen. De 3D-Suite

zal dan ook deze hoofdprocessen moeten ondersteunen. Er wordt in dit Programma van Eisen niet

gevraagd om een vast, vooraf gedefinieerde procesinrichting en functies. Dat is voor de regisseur

ook niet nodig. Het accent zal vooralsnog liggen op de ondersteuning van de regisseur en niet op

het ondersteunen van de uitvoerder in de levering van de dienst/ het product. Voor die levering

zullen de specifieke backoffice-systemen ingezet blijven worden. Het informatie- c.q.

samenwerkingsplatform zou op termijn wellicht deze systemen deels of geheel kunnen vervangen.

Voor het beoogde platform ter ondersteuning van de regie en samenwerking zijn de genoemde

fasen en functies toereikend.

De overdracht van taken (en verantwoordelijkheid) op het sociale domein naar gemeenten

verandert veel in de wijze waarop die nu georganiseerd zijn. Inhoudelijk (zeker op de hoofdlijnen)

zijn de veranderingen minder ingrijpend. M.a.w. burgers zullen om ondersteuning vragen. Er zal

een intakegesprek en beoordeling plaats vinden, etc, etc. Welke organisatie voert welke

werkzaamheden uit en hoe doet ze dat en welke specifieke werkafspraken (criteria, doorlooptijden,

e.d.) worden gehanteerd? Met deze vragen zijn gemeenten volop bezig. Hierin zullen de

veranderingen liggen.

Als referentie worden hieronder de ketenprocessen van WMO, AWBZ en Jeugdzorg23, zoals die nu

vastgesteld zijn, kort geschetst. Ook de hoofdproces van Centra voor Jeugd en Gezin (CJG)24 is

onderzocht, maar hier verder niet opgenomen. Het bestaat uit vier processen: Informatie & advies,

Monitoring & signalering, Interventies, Verwijzing.

In de huidige ABWZ heeft men recht op zorg. Dus zodra men een indicatie heeft verkregen wordt

er (na toewijzing) geleverd. De extramurale zorg uit de AWBZ wordt overgeheveld naar de

23 De informatie van het ketenproces Awbz en Wmo is afkomstig van CVZ (zorgregistratie.nl), die van het ke-

tenproces Jeugdzorg van ‘Referentiewerkmodel Bureau Jeugdzorg’, vs 2.0, 2005 24 ‘Werkprocessen CJG’, Ieder Kind Wint, 2009

164

gemeenten. En die hanteren het compensatiebeginsel, d.w.z. ze beoordelen

of en zo ja, welke ondersteuning het beste past. Het ketenproces voor de extramurale zorg zal dan

ook verlopen volgens het onderstaand ketenproces WMO.

Figuur 14 Ketenproces AWBZ

Figuur 15 Ketenproces WMO

Figuur 16 Ketenproces jeugdzorg

165

Het ketenproces Jeugdzorg kan als een goede aanvulling gezien worden op

de twee eerder vermelde ketenprocessen. Het reageren op signalen van derde wordt als een

noodzakelijke functionaliteit gezien voor de 3D-Suite. Ook hier zijn (net als bij de Wmo) fasen

ingebouwd die gericht zijn op analyse, beoordeling, vaststellen van de zorg (in een

ondersteuningsplan). De fase „toeleiding‟ (uit Wmo) verdient een aparte plaats. De stappen 4-7 zijn

weliswaar apart vermeld, maar in de toelichting wordt deze fasen als een eenheid beschouwd en

als „casemanagement‟ aangeduid. Bij jeugdzorg is ook sprake van gedwongen trajecten in het

kader van (gezins)voogdij of jeugdreclassering. De start (1-3) heeft een andere invulling (1.

Aanwijzen gezinsvoogdijwerker, voogdijwerker resp. reclasseringswerker. 2. Plannen eerste

contact. 3. Versturen mededeling). Het casemanagement betreft hier de uitvoering van

(gezins)voogdij en jeugdreclassering. Er is een aantal bijzondere situaties met een afwijkende

procesgang (denk aan crisissituaties, bezwaar, e.d.)

Een ander referentiepunt is het Bedrijfsfunctiemodel van het IZO-project25 (Informatievoorziening

Zorg en Ondersteuning). Dit model biedt een grafische weergave en eenduidige definitie van de

bedrijfsfuncties voor de uitvoering van Awbz, Wmo en Zvw.

Figuur 17 Bedrijfsfunctiemodel Informatievoorziening Zorg en Ondersteuning

Het wordt gebruikt voor de realisatie van „Toekomstbeeld IZO 2016‟ en draagt bij aan de doelen:

- Uniformering en stroomlijning van bedrijfsprocessen

- Standaardisatie van proces- en gegevenskoppelingen

- Standaardisatie van gegevenssets en domeinoverstijgend gebruik van authentieke registraties.

De andere taakvelden (Jeugdzorg en Werk en Inkomen) worden helaas niet meegenomen, maar

ook voor die velden is het model relevant. Het model omvat alle primaire bedrijfsfuncties die nodig

zijn voor de volledige ketens voor de uitvoering.

De feitelijke zorgverlening is niet uitgewerkt. Collectieve voorzieningen en informele zorg vallen

buiten de scope vallen. Beide keuzes passen bij de opzet van het beoogde informatieplatform.

25 Presentatie Bedrijfsfunctiemodel Zorg en Ondersteuning, januari 2013. Toekomstbeeld 2016 In-

formatievoorziening Zorg en Ondersteuning, mei 2012

166

12.7 Voorbeeld: online communities en ‘markt-plaatsen’

De laatste jaren dienen zich veel initiatieven aan, die mensen/gezinnen ondersteunen en bij elkaar

brengen. Soms worden deze initiatieven gesteund door de overheid, maar (steeds vaker) nemen

mensen het heft in eigen hand. Een greep uit de voorbeelden:

WeHelpen.nl is opgezet als een marktplaats met slimme functies voor het vinden en

verbinden, organiseren en delen van hulp, aangevuld met gerichte informatie aan

hulpverleners en hulpbehoevenden.

Wikiwijk Tilburg is een internet platform waar u terecht kunt als u op zoek bent naar

informatie, om te communiceren met bekenden of om nieuwe contacten te leggen, om gebruik

te maken van diensten of producten te bestellen. Een handig alles-in-één platform dus, voor

iedereen in Tilburg.

BUUV is de buurtmarktplaats voor en door bewoners van Haarlem, waar vraag en aanbod

elkaar vinden. Bij BUUV gaat het om diensten die je als bewoners voor elkaar kan doen.

Zonder dat er direct iets tegenover staat. Dit kan van alles zijn: koken, gezelschap, het uitlaten

van de hond, een lift naar de dokter, een klusje in huis of hulp in de tuin.

Jeugdcloud. In 2015 heeft elk gezin zijn eigen cloud-omgeving. Je kunt al vanaf het eerste

contact op het consultatiebureau jouw kindgegevens beheren. Dit is het eigen dossier en de

toegangspoort voor alle hulpvragen. Van laagdrempelige opvoedondersteuning tot medische

uitdagingen. Als hulpverlener moet je vragen om toegang. Wanneer meerdere aanbieders hulp

verlenen kunnen ze via de cloud van de burger communiceren. Iets delen met vrienden of

hulpverleners is een kwestie van klikken.

Toegankelijk Enschede, een website die informatie biedt voor gehandicapte burgers over de

toegankelijkheid van publieke ruimten in het centrum.

Zorgsite (Helmond) Zorg je voor iemand, of zorgen andere mensen voor jou? Dan is de

Zorgsite een handig hulpmiddel om de taken te verdelen en iedereen die helpt op de hoogte te

houden van het laatste nieuws. Dat scheelt veel vragen, regelen en bellen en maakt het een

stuk makkelijker om meehelpen te combineren met het eigen gezin en/of werk

167

12.8 Afkortingenlijst

- ANW: Algemene nabestaandenwet

- API: Application programming interface

- ASP: Application service provider (zie ook SaaS)

- AWBZ: Algemene wet bijzondere ziektekosten

- AZR: Awbz-brede zorgregistratie

- BEP-model: Bedrijfsregels, EI-standaarden en processen

- BO: Backoffice

- BPR: Basisadministratie persoonsgegevens en reisdocumenten

- BSN: Burgerservicenummer

- CMS: (Web) content management systeem

- CRUD: Create, read, update, delete

- DBMS: Databasemanagementsysteem

- DJI: Dienst justitiële inrichtingen

- DKD: Digitaal klantdossier (i.h.k.v. de Suwiketen)

- DMS: Document management systeem

- DoS: Denial of Service-aanval

- DUO: Dienst uitvoering onderwijs

- ESB: Enterprise service bus

- FAQ: Frequently asked questions (veelgestelde vragen)

- FO: Frontoffice

- GBA: Gemeentelijke basisadministratie (Basisadministratie persoonsgegevens en reis-

documenten)

- GBA-V: GBA verstrekkingsvoorziening

- GEMMA: Gemeentelijke model architectuur

- GeVS: Gezamenlijke elektronische Voorzieningen Suwi

- HTTPS: Hypertext transfer protocol secure (versleutelde http-verbinding)

- IOAW: Inkomensvoorziening oudere en gedeeltelijk arbeidsongeschikte werkloze werk-

nemers

- IOAZ: Inkomensvoorziening oudere en gedeeltelijk arbeidsongeschikte gewezen zelf-

standigen

- IOW: Inkomensvoorziening voor oudere werklozen

- KCC: Klantcontactcentrum

- KCS: Klantcontactsysteem

- KING: Kwaliteitsinstituut Nederlandse gemeenten

- MO: Midoffice

- OTAPU: Ontwikkel-, test-, acceptatie- en uitwijkomgevingen

- OTC: Objecttypencatalogus

- PDC: Product-dienstencatalogus

- PGB: Persoonsgebonden budget

- PKI: Public key infrastructure

- PvA: Plan van aanpak

- PvE: Programma van eisen

- RDW: Rijksdienst voor het wegverkeer

- RGBZ: Referentiemodel gemeentelijke basisgegevens zaken

- RMA: Records management applicatie

- RSGB: Referentiemodel stelsel van gemeentelijke basisgegevens

- SaaS: Software as a service

- SAN: Storage area network (opslag)

168

- StUF: Standaard uitwisselformaat

- StUF-Zkn: Standaard uitwisselformaat-zaken

- Suwi: Wet structuur uitvoering werk en inkomen

- SVB: Sociale verzekeringsbank

- TAPU: Test-, acceptatie- en uitwijkomgevingen

- TW: Toeslagenwet

- UO: Uitvoeringsorganisatie

- UWV: Uitvoeringsinstituut werknemersverzekeringen

- VAC: Vraag-antwoord combinaties

- VIR: VerwijsIndex risicojongeren

- VNG: Vereniging van Nederlandse gemeenten

- Wajong: Werk en arbeidsondersteuning jonggehandicapten

- WAO: Wet arbeidsongeschiktheid

- WAZ: Wet arbeid en zorg

- WIA: Wet werk en inkomen

- WMO: Wet maatschappelijke ondersteuning

- WSF: Wet op de studiefinanciering

- WTOS: Wet tegemoetkoming onderwijsbijdrage en schoolkosten

- WW: Werkloosheidswet

- WWB: Wet werk en bijstand

- WYSIWYS: What you see is what you sign

- ZgW: Zaakgericht werken

- ZRM: Zelfredzaamheidsmatrix

- ZTC: Zaaktypecatalogus

- ZW: Ziektewet

KWALITEITSINSTITUUT NEDERLANDSE GEMEENTEN NASSAULAAN 12

2514 JS DEN HAAG POSTBUS 30435 2500 GK DEN HAAG T 070 373 80 08 F 070 363 56 82

INFO@KINGGEMEENTEN.NL WWW.KINGGEMEENTEN.NL