CONCEPT PROGRAMMA VAN EISEN. Informatievoorziening t.b.v. ondersteuning regie in het sociaal domein: 1-gezin 1-plan 1-regisseur

CONCEPT PROGRAMMA VAN EISEN Informatievoorziening t.b.v. ondersteuning regie in het sociaal domein: 1-gezin 1-plan 1-regisseur

1

Colofon Concept-Programma van Eisen Informatievoorziening t.b.v. ondersteuning regie in het sociale domein: 1-gezin 1-plan 1regisseur Opdrachtgevers

KING, Dimpact, GovUnited

Auteurs

Zie par. 1.3.

Eindredactie

Frank Kuiper

Versie

0.92

Datum

29 juli 2013

2

Inhoudsopgave 1

2

Inleiding

6

1.1

Voorwoord

6

1.2

Doel Programma van Eisen

1.3

Programma van Eisen

10

1.4

Terminologie

11

1.5

Leeswijzer

11

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

2.5 3

4

7

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

Regie op regie

30

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

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

4.4

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

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 3

4.5

4.6 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

Burgerportaal (zelfregie)

70

PvE: Specifieke inrichting

72

5.1

72

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

5.3.1

Niet-gepersonaliseerd burgerportaal (oriëntatie & informatie)

85

5.3.2

Gepersonaliseerd Burgerportaal

87

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

5.4.5

Procesbewaking/evaluatie/nazorg

97 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

9

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

131

8.6

Technische beveiliging en integriteit

132

8.7

Overig (beveiliging)

133

PvE: Architectuur

134

9.1

Inleiding

134

9.2

Functionele architectuur

134

4

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

5

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 en een eerdere versie van het programma van eisen zoals tot stand gekomen in samenwerking met Novay, gemeente Enschede, regiogemeenten en KING. 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

6

finale versie van het globale PvE versie 0.9 er om als toetssteen te dienen en in breder verband te presenteren. 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 [email protected].

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

7

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

8

Figuur 2 Informatiestromen 'rond de keukentafel' Er is echter hter niet enkel sprake van multiprobleemgezinnen waarbij ieder traject verschilt, maar ook eenvoudige, enkelvoudige, snelle ondersteuning of van multi-disciplinaire disciplinaire standaardondersteuning (standaard standaard ondersteuningsvormen, doch met meer betrokken partijen). 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) ondersteuni cties) 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).

9

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 10

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 verschillende termen gebruikt. Waar in dit document sprake is van bijv. een burger, kan ook bijvoorbeeld ‘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 synoniemen - Traject, case, zaak, ondersteuningsproces (de uitvoer van het ondersteuningsplan) zijn synoniemen - Zaakbak, werklijst, werkbak, trajectbak, etc. zijn synoniemen - Dienstenboek, productenlijst, PDC (product- en dienstencatalogus) zijn synoniemen - Medewerker, professional, hulpverlener, ondersteuner zijn synoniemen (voor zover de ondersteuner 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).

11

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.

12

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.

13

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.

14

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 belangrijke 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; ZelfredzaamheidMatrix 2013 Handleiding, GGD Amsterdam). V.w.b. burgerkracht: zie ook bijv. ‘Burgerkracht, de toekomst van het sociale werk in Nederland, RMO, 2011’ en ‘Een beroep op de burger, SCP, 2012’. 15

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 16

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 modellen

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 situatie 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: ( ron: gemeente Almere). Deze ‘basis’-modellen modellen beschrijven in de kern de wijze waarop de gemeente 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 modellen ontstaan. Echter E 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”(“light” versie van regie)

Regisseur als spin in het web

Regisseur als uitvoerder

Figuur 4 Vier vormen van regie

17

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 18

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.

19

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 uitvoeringsorganisaties 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 20

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 gemeente zijn, ondersteuners/zorgverleners, 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. derde We noemen dit “ad--hoc” autorisaties, i.t.t. de e autorisaties die door de functioneel beheerder worden ingericht.

21

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

22

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.

23

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 ondersteuningsplan

- organiseren en bevorderen van afstemming en samenwerking tussen verschillende hulpverleners - overzicht houden over welke hulpverleners bij het gezin betrokken zijn en welke hulp zij leveren; 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 24

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 25

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-isde-verwijsindex-risicojongeren-vir.html en http://wetten.overheid.nl/BWBR0027338/geldigheidsdatum_01-05-2013 (de Wet VIR); VIR werkt via een melding-respons systematiek 26

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

27

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 28

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.

29

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:

Resultaten Doelgroepen Kwaliteit zorg Efficiency Resultaat, €, wijkindex

Caseload, € (incl kosten van regie), uren, %klantcontact, resulKlantbeeld

taat

Opdracht+ budget € Resultaat Inkoopvoorwaarden, €, doorlooptijd, wachttijd/lijst, kwaliteit, resultaat

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 burgers hoger op zelfredzaamheidsmatrix te brengen. N.B. Deze kaders worden onderscheiden naast het primaire proces waar regisseur en wijkmanager in werken 30

- Externe 2e lijns professionals en gemeentelijke backoffice hebben contractuele 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 3Dsuite 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.

31

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

32

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

33

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

34

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 3DSuite 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 35

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

36

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 voorbehoud 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. schermafbeeldingen. Bij semi-gesloten wensen (S#) dient Inschrijver, tenzij expliciet anders geïnstrueerd, aan te geven in welke mate aan elk van de in de betreffende wens genoemde aspecten standaard [(‘offthe-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 deelwens 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 bestek. Dat wil zeggen dat alle in de offerte beschreven functionaliteiten en specificaties (beantwoording 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.

37

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.

38

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.

39

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 G1

Registreren klantcontacten en zaken

Zaakregistratie: algemeen

De 3D-Suite biedt functionaliteit m.b.t. het conform de betreffende zaaktypen registreren van zaken in de 3D-Suite door medewerkers zowel van de gemeente als van geautoriseerde ketenpartners. 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 uitvoeringsorganisatie (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 G2

Zaakbeheer

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 respectievelijke werklijsten, inclusief ten minste:

8

www.kinggemeenten.nl/ztc/ztc-20 40

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 dossiers 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, waarna 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 41

−

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 G5

Zaakbehandeling

Zaakbehandeling: standaardstatussen

G5.1 −

De 3D-Suite biedt functionaliteit m.b.t. processturing t.a.v. (de behandeling van) zaken zodanig dat deze door middel van een aantal opeenvolgende statussen naar een eindresultaat geleid worden. Dit omvat ten minste de volgende vier statussen: 1) ontvangen, 2) geaccepteerd, 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 teneinde 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 intakeverslag, standaardtaken, checklists, etc.) is in een zaaktypencatalogus (in de zaaktypeconfiguratie 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 anders dan het normale procesverloop zoals geconfigureerd in het betreffende zaaktype), ten minste: 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.

42

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 zaaktypeconfiguratie van het zaaktype van de betreffende deelzaak voorkomen en niet anders zijn geconfigureerd. 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 regisseur 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 uitkering 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 gerelateerd kan worden. Eventuele relaties met andere zaken zijn zichtbaar bij het inzien van zaken, 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 verantwoordelijke voor de betreffende zaak. Dit is zowel in de beheerfase (ZTC2.0) door functioneel 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 geautomatiseerd een statusbericht gegenereerd kan worden ten behoeve van betrokken interne en externe medewerkers, ten minste via de webinterface en via e-mail.

G6.2 -

Statusberichten bevatten ten minste de betreffende zaakidentificatie (zaaknummer), een directe 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. processturing 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)

43

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, afgevinkte controlevragen (checklist), zaaktypen die als deel- en/of gerelateerde zaak voorkomen, 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 / status

-

▪

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 zelfstandig, 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 product/dienst en per zaaktype als standaardorganisatieonderdeel vast te leggen in de betreffende configuratie, te weten product-dienstenbeschrijving en zaaktypeconfiguratie. Ook is het bij aanmaken 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 medewerkersportaal hebben daarbij snel toegang (met één extra klik) tot de contactgegevens van de betreffende organisatie. S3.

Doorzetten van klantcontact/intake

Klantcontacten en ‘door te zenden intake’ (gescande post/e-mail die ten onrechte bij de Gemeente 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 geregistreerde toelichting/informatie van het klantcontact/intake, evenals de relevante digitale documenten (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 volautomatisch.

44

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 klantcontact 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 taken die bij uitvoeringsorganisaties zijn belegd, is standaard een termijn van toepassing waarbinnen de taak (=gerelateerde of deelzaak) dient te worden afgerond. Bij het naderen én bij het verstrijken 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 contactmomenten en terugbelverzoeken) t.b.v. uitvoeringsorganisaties én de registratie van het doorzenden 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 geregistreerd 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 vastgelegd 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 uitvoeringsorganisaties 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.

45

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 E2

Gegevensbeheer en -opslag

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

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 3DSuite worden beheerd en opgeslagen (v.w.b. domeinspecifieke gegevens bijvoorbeeld via koppeling 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 programmeerkennis nodig is (zero coding), in de 3D-Suite kunnen beheren na een cursus zoals beschreven 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 organisaties 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.

47

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 blijven). 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 aangemaakt als een burger in een (door gemeente bepaalde) tijd een (door gemeente bepaald) aantal eenvoudige/enkelvoudige aanvragen heeft ingediend; of wanneer sprake is van veiligheidsrisico’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, zoals 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.

48

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 uitvoeringsorganisaties / 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 gegevensregistratieschermen / formulieren te creëren en beheren, zowel qua inhoud (incl. logica en intelligentie) 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 gegevensregistratieschermen / -formulieren door medewerkers (medewerkerintake) t.b.v. zaakregistratie (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. 49

−

Of elementen (zoals registratie van specifieke gegevens, documenttypen en -attributen, controlevragen, etc.) daarbij verplicht zijn, is op 1 plaats (in een zaaktypecatalogus, objecttypecatalogus, 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 gegevensregistratieschermen / -formulieren zodat gebruikers (zowel burgers als medewerkers) gegevens kunnen 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 inzichtelijk is.

G10.2 −

Of elementen (zoals registratie van specifieke gegevens, documenttypen en -attributen, controlevragen, etc.) daarbij verplicht zijn, is in de zaaktypencatalogus (in de zaaktypeconfiguratie van het betreffende zaaktype) vastgelegd en kan door functioneel beheerders van gemeente 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 gegevenswaarden.

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

50

−

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 intelligentie) De 3D-Suite biedt functionaliteit m.b.t. gegevensregistratie (“data entry”) door middel van gegevensregistratieschermen / -formulieren zodat gebruikers gegevens kunnen registreren in de 3DSuite. 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 geldige 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 tussen (de geregistreerde “waarden” van) twee of meer elementen op gegevensregistratieschermen / -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 (blokkerend).

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 expert, 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 (wizardfunctionaliteit 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).

51

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, bijvoorbeeld 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 wijzigingen doorwerken in alle schermen / formulieren waarin elementen voorkomen) en functionaliteit 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) bedrijfsregel vanaf een bepaalde datum actief wordt), metadata, gebruik van templates en wizards, 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 volledig 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 functionaliteit 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

52

webformulier en het volledig geautomatiseerd kunnen versturen van een ontvangstbevestiging 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 3DSuite 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 E4

(Management)rapportages

(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 opgeslagen volledig, in samenhang met elkaar en incl. historie gestructureerd toegankelijk voor leesacties (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 dumptabellen 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):

53

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 standaardrapportages, 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 beheerders en gebruikers van Gemeente én bij voorkeur de gebruikers deze zelfstandig kunnen aanpassen.

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 BIview/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 E5

Basisfunctionaliteit

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

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 dienen uit te voeren.

-

Of aldus gegenereerde documenten / e-mails eerst nog als concept getoond worden, ter controle en eventuele handmatige aanpassing door gebruikers (incl. het gebruik van spellingcontrole).

-

Of aldus gegenereerde documenten / e-mails (m.u.v. uittreksels en afschriften) volledig geautomatiseerd (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 besturingssysteem. 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

55

één of meer bijlagen) behouden laten blijven. G13.3 −

Bij het toevoegen van een document aan een traject- of klantdossier dient alle daarbij verplichte 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. stylesheets).

-

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) dienaangaande, 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 zelfstandig, 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. documentcreatie als bedoeld in O13, v.w.b. de ‘mapping’ tussen velden in de 3D-Suite en de sjablonen. 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 zelfstandig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus).]

56

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 3DSuite 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 plaatsvinden). Maak daarbij onderscheid tussen de verschillende typen informatie die aldus ‘bevroren’ worden, waaronder ten minste gegevens, documenten in het betreffende zaakdossier en het logbestand van de zaak (wie heeft wanneer wat toegevoegd, ingezien, gewijzigd, verwijderd), 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 resultaattype 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 plaatsvinden, en zo ja op welke wijze (zoals o.b.v. documenttype). Maak daarbij steeds onderscheid tussen handmatige (gebruikers-) en geautomatiseerde (systeem)handelingen.

57

-

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 (systeem)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 zelfstandig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus).

58

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 zowel inkomende als uitgaande communicatie). Maak hierbij onderscheid tussen ‘klantcontacten’ als een zelfstandige entiteit (dus onafhankelijk van een specifieke zaak) en contactregistratie bij zaken. 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 reminder (incl. notitie) kan zetten op een bepaalde datum of na een bepaalde termijn waarbij het ‘afgaan’ van de reminder een notificatie veroorzaakt in de werkomgeving in de 3D-Suite. Beschrijf daarbij het bedieningsgemak en -snelheid van de betreffende functionaliteit (zowel registratie als afhandeling), incl. de mate waarin informatie automatisch kan worden ingevuld of gesuggereerd (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 inzien 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.

59

4.5.2

Filteren en sorteren

O17 Filteren en sorteren Beschrijf de functionaliteiten van de 3D-Suite met betrekking tot filteren en sorteren van signaleringen, 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, documenttype, etc.).

Geef hierbij bovendien steeds aan binnen welke context deze functionaliteit kan worden aangesproken 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 worden 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 beslisbomen, 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, dropdown-/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 60

-

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 3DSuite (zoals via configuratie van zaaktypen in een zaaktypencatalogus).

-

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 (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 zelfstandig, 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

61

meegeleverd (dus inbegrepen bij de prijsopgave (zie ####) en als zodanig zonder additionele kosten ‘off-the-shelf’ beschikbaar), incl. toelichting (merk, type, versie(s), functionaliteit, 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 additionele kosten ‘off-the-shelf’ beschikbaar), incl. toelichting (merk, type, versie(s), functionaliteit, 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 ‘contextgevoeligheid’ (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 gebruikers 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), zoals 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 tevens 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 oppasoma’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 functionaliteiten: -

Weergave en beheer van beschikbare producten en diensten, incl. levensgebied, vrije tekstvelden, URL, betrokken uitvoeringsorganisaties, kosten per voorziening (intern, extern), overige 62

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 weergaven 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 producten en diensten, inclusief versiebeheer, metadatering, opmaak (vormgeving) en structuur (navigatie) 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 worden 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 medewerkersportaal 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 software) 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 zoekboxen (per uitvoeringorganisatie) opnieuw te moeten ingeven.

4.5.5 E6

Zoeken

Autorisaties bij zoeken

De 3D-Suite biedt functionaliteit waarmee bij zoeken en filteren in de 3D-Suite autorisaties geres63

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 documentopslagfaciliteit [van het DMS/zaaksysteem.][Ga daarbij ook in op ondersteund bestandsformaten, 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 onderling, etc.).

-

De mate waarin bij zoeken rekening gehouden wordt met autorisaties (rechten en rollen), zodat 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 invoer) 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 “samenstellen” 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 (bijvoorbeeld “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 64

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 zogeheten relevance ranking.

G15.2 −

Wanneer er sprake is van relaties tussen zoekresultaten, dan worden deze in samenhang (gegroepeerd) gepresenteerd (zoals gezinsleden, eerdere zaken van dezelfde burger, etc.).

G15.3 −

Zoekresultaten kunnen door gebruikers middels kolommen zowel op- als aflopend worden gesorteerd 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 zoekterm(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, versie]). Maak daarbij zo nodig onderscheid tussen registratie door interne medewerkers en externen 65

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

66

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 gehouden invulvelden)

O27 Verantwoording Beschrijf de mate waarin door de 3D-Suite ondersteuning wordt geboden bij de financiële en inhoudelijke 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 velden/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 bijgewerkte 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 vanzelfsprekend enkel inzichtelijk voor de gemeentelijke regisseur en managers.

-

(bij voorkeur door middel van een deelzaak) een fiat vragen / krijgen via een manager, wanneer nader te bepalen dure of afwijkende diensten een akkoord behoeven.

-

Tijdens het samenstellen van een ondersteuningsplan een offerte met calculatie opvragen[ incl. 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:

67

-

Bewaking van budget, deelbudget, aantallen beschikbare rolstoelen/adviesuren/ etc. incl. visualisatie 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 gekoppeld/toegewezen, voor zover de betreffende persoon daartoe is geautoriseerd. In deze portal kan de uitvoeringsorganisatie ten minste lopende (deel)zaken beheren, klantcontacten hieraan koppelen, de status van klantcontacten en lopende zaken verzetten en een toelichting bij deze statusverandering vastleggen. Tevens zijn nader te bepalen delen van de klantinformatie inzichtelijk voor geautoriseerde gebruikers 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 bronnen.

G18.2

68

−

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 (masterdetailschermen 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 inzichtelijk voor daartoe geautoriseerde gebruikers: afhankelijk van de rechten niets, DAT, of WAT

69

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 geven 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 geven in de gegevens en zaken van minderjarige gezinsleden

G19.9

70

-

De 3D-Suite biedt functionaliteit om burgers op een ‘Mijn ondersteuning’-pagina inzage te geven 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 informatie van de Gemeente of een ketenpartner niet alleen binnen, maar wordt deze ook bewaard. 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 welke 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 paragraaf 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

71

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.

72

De informatiestromen atiestromen 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 plan 1-regisseur 1-dossier’ Een en of meer gesprekken tussen de eerstelijns professional en de burger vinden zijn weerslag in een plan, dat de basis is voor de vervolgdienstverlening. vervolg Dit gebeurt volgens het principe van ‘1-gezin 1-plan 1-regisseur 1-dossier’, dossier’, waaraan ook toegevoegd kan worden ‘1 regisseur, 1-budget, 1 1informatievoorziening’. 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 enkel te leveren en 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 essentiële gegevens over de burger, zijn omgeving en zijn problematiek. Daarnaast biedt het dossier aan alle betrokkenen de mogelijkheid om de voortvoor 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 gezin 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 3D ontstaan of zijn opgenomen: zeg maar het zaakdossier. zaakdossier Het klantbeeld is vaak het startpunt van een traject en een hulpmiddel tijdens het traject, 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.

73

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 melding 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 algemeen leiden tot een gesprek tussen een professional en de betrokken burger. Als automatisch filteren mogelijk is, dan moet de professional wel in charge zijn: individuele regisseurs mogen geen signalen missen. De verantwoordelijkheid voor bundelen en filteren, 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) signalen 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 professional 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 effectiever 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 uitzonderingsgevallen (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 gemeente 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 gegevens 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 diensten 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 74

geven op het ondersteuningsplan. Immers moet de burger zelf delen 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 / zorgaanbieder(s) wordt bepaald. Overigens kunnen voor de ondersteuning natuurlijk ook mantelzorgers 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 burger 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 binnen 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 casusoverleg nodig. Een verwijsindex bevat informatie over welke ondersteuners/ondersteunende instanties bij een burger of een gezin betrokken zijn: ‘dat’ ipv. ‘wat’. Een casusoverlegfunctie is een functie / deelsysteem waarmee geselecteerde en geautoriseerde professionals een beperkt deel van de inhoudelijke wát-informatie met elkaar kunnen 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.

75

5.1.2

Primaire en secundaire functies 3D-Suite12

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

12

Brondocument hiervoor is het rapport “Een persoon/huishouden, een plan, een professional, een informatiehuishouding” opgesteld door Novay, in opdracht van de gemeente Enschede, in samenwerking regiogemeenten, zorgpartijen en KING (Novay, 7 december 2012) 76

Generieke functionaliteit t.b.v. deze functie betreft onder meer ontvangst, prioritering van bewaking van de binnengekomen signalen. 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

77

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

78

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

13

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.

13

Zie ook www.zelfredzaamheidmatrix.nl 79

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

80

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

•

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 uitvoeringsorganisatie. (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 applicatieprogrammatuur en gegevensverzamelingen (en de bijbehorende documentatie). Ze laten deze voorzieningen optimaal aansluiten op de bedrijfsprocessen en daarmee samenhangende wensen van gebruikers en andere belanghebbenden. Dit omvat ten minste gegevensbeheer, 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 • • • • •

5.1.3

Burger (of ingezetene) Gezin (huishouden) en gezinslid Familielid, vriend, kennis, etc. Huisarts, wijkagent, thuiszorg medewerker, etc. Onderwijzer/docent, sportleraar, pastoor/imam, etc.

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 81

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.

82

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.

83

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

84

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 gebruiksvriendelijke wijze toegang bieden tot actuele, complete informatie over (jeugd)zorg, ondersteuning, 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 & informatie)

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 functionaliteiten, die vooral ingericht zijn en gebruikt worden door burgers, maar ook van belang zijn voor professionals in hun werk. Deels betreft het algemene voorzieningen, maar ook voorzieningen, die door de gemeente zelf worden aangeboden, zoals product- en dienstencatalogus, vraagverheldering, 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 productbeschrijvinginformatie toegevoegd worden, die alleen voor medewerkers beschikbaar is?

-

Vraaggeleiding/beslisbomen om burgers en medewerkers door middel van vraaggeleiding / beslisbomen naar relevante (op de situatie/behoefte toegespitste) informatie. Dat kan een be-

85

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 (functionaliteit 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 onderwerp worden op een overzichtelijk wijze alle relevante productbeschrijvingen, beslisbomen, sociale kaarten en ‘ook van belang’ (bijvoorbeeld links naar externe sites, verwijzingen naar regelgeving 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 informeren naar mogelijkheden in ondersteuning. Professionals kunnen diezelfde informatie gebruiken 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 ondersteuning 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 86

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 actief ‘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 emailadres 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)

87

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 actuele 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 lopende 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 beschreven 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

-

reacties op documenten online toe te voegen

-

zelf documenten toe te voegen

toe is geautoriseerd (bijv. documenten in deelzaken waar hij zelf verantwoordelijk voor is)

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

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

88

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 beknopt 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 ondersteuningsplan 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 informatie zoals brochures etc.

-

Burgers kunnen zelf het onderdeel beheren, maar ook de regisseur/ professionals kunnen algemene 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 bekende 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.

89

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.

90

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 generieke 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, inkomen, schulden, opleidingen, die zoveel mogelijk uit andere systemen worden betrokken. Ook indicaties van ontvangen voorzieningen voor jeugdhulp, zorg of ondersteuning vormen een onderdeel. 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 backofficesystemen. 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 integraal 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 netwerk dat relevant is voor een specifiek behandelplan. 91

Beschrijf de wijze waarop het netwerk rondom de burger in één oogopslag inzichtelijk is. Voorbeeld 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 3Dsuite (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 Zelfredzaamheidsmatrix 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 interactie (contacten) tussen burger en hulpverleners. Hierbij valt te denken aan input van de burger op het behandelplan, digitale communicatie tussen burger en hulpverlener. 92

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

-

-

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

Handmatig en geautomatiseerd invoeren van een signalering / melding, m.a.w. de wijze waarop 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 vastleggen gegevens verplicht gesteld worden

-

Signalering / melding koppelen aan een burger/gezin (automatisch, bijv. o.b.v. BSN, of handmatig) 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 managementinformatie (t.b.v. sturing op een hoger niveau zoals inzake beleid of afspraken tussen organisaties) en de informatie voor de uitvoering.

-

De mate waarin door de gemeente aanpasbare business rules worden toegepast t.b.v. prioritering en gefilterd doorsturen, incl. hoe de regisseur de prioritering/filtering handmatig kan overrulen.

-

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

93

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 tussen gemeenten, gecertificeerde instellingen en VenJ uitvoeringsorganisaties zal verlopen via de Collectieve Opdracht Routeer Voorziening14, conform de beschrijving in de Project Start Architectuur van deze voorziening. Dit betekent ondermeer dat gebruik 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.

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 ogenschijnlijk ongestructureerde wijze van contact kan wel gestroomlijnd worden. Want meer structuur is nodig, zodat ook deze informatie toegankelijk en beschikbaar is. Bovendien wordt veel belang 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 burger 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 ondersteuningsplan

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.

14

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, jeugdstrafrechtketen en jeugdbeschermingsketen gaan plaatsvinden, bijvoorbeeld een gestandaardiseerd Verzoek tot Onderzoek (VTO) als startmoment voor de jeugdbeschermingsketen; ook zullen de gemeenten allerlei gestandaardiseerde berichten uit de justitiële jeugdketens ontvangen en (2) beleidsinformatie richting V&J. VWS, VenJ en enkele gemeenten gaan hiervoor een proeftuin inrichten. 94

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 / privacy) overzicht van alle geleverde ondersteuning richtinggevend zijn voor het op te starten traject: 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 bieden. 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

95

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 gezinsleden 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 standaardkosten op te nemen), ten minste o.b.v. tekstvelden

G22.8 -

Vastleggen van de uitvoerder of uitvoerders van de acties (gezin, omgeving, en/of professionele ondersteuners)

G22.9 -

Verschaffen van actuele totaaloverzichten per plan incl. doelen, taken, kosten, termijnen, gekozen 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 uitvoering 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

-

De wijze waarop afhankelijkheden tussen doelen worden vastgelegd (eerst doel 1 en 2, als dat

als de Zelfredzaamheidsmatrix

96

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 standaardkosten op te nemen), ten minste o.b.v. tekstvelden doch bij voorkeur ook gestructureerde velden i.r.t. voornoemde standaardlijsten (bijv. dienstenboek)

-

Aanvullende informatie over bijvoorbeeld ‘best practices’ (een succesvolle aanpak in een vergelijkbare 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 ondersteuners, 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. 97

Hier worden de functionaliteit gevraagd, die aanvullend is op de generieke functies, zoals genoemd in hoofdstuk 4. Daar is veelal uitgegaan van de zaakgericht werkenconcepten. 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 regisseur 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 ondersteuningsplan 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 instructies/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 Ondersteuningsplan.

−

De mate waarin de 3D-Suite de mogelijkheid biedt om handmatig en bij voorkeur ook automatisch 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 doorzet.

−

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-

98

voer) binnen een zaak of deelzaak. Het uitzetten van taken valt grotendeels samen met het geven van een opdracht om een individuele 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 (samen 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 gepubliceerd (op de veiling aangeboden), waarna de aangesloten ondersteuners een passende ondersteuning 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 professionals 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 verbetering van de situatie van de burger en (dus) tot een hogere score op de zelfredzaamheidmatrix. 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 versturen. De burger kan dan via ‘Mijn omgeving’ het verzoek/bericht inzien, waarna de burger bijvoorbeeld aan de hand van een (deels vooringevuld) formulier de ontbrekende gegevens kan indienen. 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 individuen (gezin) beschikbaar te zijn. De essentie is dat informatie op het juiste niveau wordt gekoppeld/opgeslagen.

99

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 beoogde 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 behandeltraject / 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 totale ondersteuningsplan) dienen in verschillende combinaties bewaakt te kunnen worden.

-

De mogelijkheid om percentage-gereed vast te leggen voor de realisatie van de acties (sommige 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 (dreigende) overschrijding van norm- en streefdata en –termijnen. ▪

Beschrijf ook welke additionele informatie/ functionaliteit beschikbaar is. Bijvoorbeeld: indicatie met kleuren of anderszins. Standaard aanduiding/ presentatie van urgentie c.q. belang.

▪ -

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 termijn. 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 andere professionals is het handig indien de besluiten en resultaten in samengevatte (liefst grafische) vorm toegankelijk zijn, Vanuit deze ‘samenvatting’ kan dan worden doorgeklikt naar de achterliggende informatie/stukken. Als denkrichting is hieronder een ‘Besluitenlijn’ weergegeven.

100

-

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 (wellicht bijgestelde) doelen gerealiseerd zijn (bijv. v. ‘zelfredzaamheid zelfredzaamheid inkomen is op het afgesproken niveau’). niv

-

Kwaliteit betreft enerzijds de kwaliteit van het proces, m.a.w. is de afhandeling volgens de procedures verlopen. Voor overheidsorganisaties is de de rechtmatigheid een belangrijk aspect in de kwaliteit. Anderzijds staat de vraag centraal of de resultaten behaald zijn en de doelen beb 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 profesprofe sionals om bijvoorbeeld de taakuitvoering op te schorten vanwege gewijzigde omstandigheomst 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 3D3D suite teruggekoppeld. Ook het terugkoppelen van resultaten en financiële gegevens is gewenst. Beschrijf de wijze waarop ketenberichtenverkeer plaatsvindt en de mate waarop dit geautomatigeautomat seerd plaatsvindt. Ga daarbij vooral in op de automatische uitwisseling (via leeslees en/of schrijfkoppelingen) tussen de 3D-suite suite en backofficesystemen van ondersteuners,, aanvullend aan mogelijkheden voor uitvoeringsorganisaties om (ook) handmatig statussen en %-gereed % gereed te zetten. zetten Beschrijf ook welke standaarden in berichtenverkeer ondersteund wordt. Bijvoorbeeld: voorbeeld: StUFStUF zaken, AZR, e.d. Zie e ook hoofdstuk 7.

5.4.5

Procesbewaking/evaluatie/nazorg

O61 Evaluatie Evaluatie kan ook als een vorm van kwaliteitsbewaking 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) profiel)

-

Inzet van klanttevredenheidsonderzoek. tevredenheidsonderzoek. Hierbij kan ook sprake zijn van onderzoeken (vragen(vrage

101

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 gestructureerde 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 (kwaliteit 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.

102

5.5

Regie op regie (budget, contract, kwaliteit, 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 (budgetten/ 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 minimaliseren.] 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 sturingsinformatie. 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:

103

-

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. gemeenteraad 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 rekening mee te houden?

104

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 toepassing, procedurebeschrijvingen, eventuele benodigde informatie en/of bescheiden, van toepassing 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

105

kunnen worden. Beschrijf daartoe in welke mate (en o.b.v. welke standaarden: bijvoorkeur StUFZaken en/of de Zaak-DMS-services

15

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

15

Zie ook https://new.kinggemeenten.nl/gemma/stuf/koppelvlakken/zs-dms 106

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

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 tabvolgorde consequent is doorgevoerd), navigatie, (context)menu’s, toetsenbordgebruik, datumnotatie, verplichte elementen, look & feel, etc. Beschrijf daarbij tevens in welke mate schermen als (proces)stappen met een logische bundeling/opeenvolging van handelingen worden gepresenteerd, incl. de mogelijkheid om de functionaliteiten zoals beschreven in de verschillende 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 voorzien 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 beschrijving, 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 individuele 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.

107

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 tabvolgorde consequent is doorgevoerd), navigatie, (context)menu’s, toetsenbordgebruik, datumnotatie, verplichte elementen, look & feel, etc. Beschrijf daarbij tevens in welke mate schermen als (proces)stappen met een logische bundeling/opeenvolging van handelingen worden gepresenteerd, incl. de mogelijkheid om de functionaliteiten zoals beschreven in de verschillende 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 voorzien 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 beschrijving, 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

108

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 tabvolgorde consequent is doorgevoerd), navigatie, (context)menu’s, toetsenbordgebruik, datumnotatie, verplichte elementen, look & feel, etc. Beschrijf daarbij tevens in welke mate schermen als (proces)stappen met een logische bundeling/opeenvolging van handelingen worden gepresenteerd, incl. de mogelijkheid om de functionaliteiten zoals beschreven in de verschillende 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 voorzien 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 beschrijving, 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 tabvolgorde consequent is doorgevoerd), navigatie, (context)menu’s, toetsenbordgebruik, datumnotatie, verplichte elementen, look & feel, etc. Beschrijf daarbij tevens in welke mate schermen als (proces)stappen met een logische bundeling/opeenvolging van handelingen worden gepresenteerd, incl. de mogelijkheid om de functionaliteiten zoals beschreven in de verschillende keten use cases te combineren resp. sequentieel uit te voeren.

109

-

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 voorzien 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 beschrijving, 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.

110

7

PvE: Integratie

7.1

Inleiding

Bij koppelingen tussen systemen dient onderscheid gemaakt te worden tussen schrijven (van 3DSuite 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

16

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 kunnen 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 voldoen aan de betreffende standaarden.]]

16

API: Application Progamming Interface, koppelvlak waarmee kan worden gekoppeld met de betreffende applicatie. 111

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 zover van toepassing realtime (i.t.t. batch) en zowel lezen als schrijven). Hierbij wordt het ZK-DMS koppelvlak ondersteund.17

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. authenticatie/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 [zaaksysteem/DMS] v.w.b. documentopslag aan te passen. Indien geen sprake is van volledig enkelvoudig beheer, beschrijf hoe de inrichting van beide systemen gelijk wordt getrokken en welke beheertaken dubbel moeten worden uitgevoerd. Ga daarbij 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 bijbehorende 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-

17

Dit koppelvlak is ontwikkeld in samenwerking met operatie NUP. Zie ook https://new.kinggemeenten.nl/gemma/stuf/koppelvlakken/zs-dms 112

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, incl. 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, 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 (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 gebruiken]] G24.3 [D.w.z. dat ten minste (doch niet noodzakelijkerwijs uitsluitend) [voor zover van toepassing realtime 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, type, versie]) dat alle functionaliteiten en berichten als beschreven in de specificaties van het betreffende ‘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 overzicht van aan te maken boekingen kan het financiële systeem via live databasetoegang met leesrechten de benodigde gegevens uitvragen. G25.3 D.w.z. dat ten minste (doch niet noodzakelijkerwijs uitsluitend) [voor zover van toepassing realtime 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,

113

versie]) dat alle functionaliteiten en berichten als beschreven in de specificaties van het betreffende ‘vrouwtje’ in bijlage [XX] volledig worden ondersteund (realtime en zowel lezen als schrijven). De 3D-Suite integreert met de directory server van de Gemeente zodanig dat alle gebruikers/wachtwoorden van interne medewerkers van de Gemeente worden geverifieerd door de Directory server en dat alle rollen die binnen de 3D-Suite worden gebruikt voor authenticatie en autorisatie 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 3DSuite 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 realtime 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 doorgegeven 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]]].

114

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 betreffende basisadministratie. [Alle functionaliteiten en berichten als beschreven in de specificaties van het betreffende ‘vrouwtje’ 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 magazij-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 volledig automatisch ‘onderwater’ plaatsvindt m.b.v. afnemersindicaties of dat hiervoor een handmatige actie is vereist via de gebruikersinterface van de 3D-Suite. Geef ten slotte aan hoe in de gebruikersinterface van de 3D-Suite zichtbaar is of een persoon wel of geen inwoner van de Gemeente is. S24. Basisregistratie Adressen en Gebouwen (BAG) (lezen) De 3D-Suite integreert op zodanige met het Basisregistratie Adressen en Gebouwen (BAGsysteem, [merk, type, versie] dat alle functionaliteiten en berichten zoals beschreven in de specificaties 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 ZKDMS 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 ZKDMS 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 115

([merk, type, versie: bijv. Allegro, Suite4Zorg, Key2Schuldhulpverlening]) 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 ‘vrouwtje’ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing realtime lezen).][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 Gemeente ([merk, type, versie: bijv. Suite4Inkomen]) dat daartoe geautoriseerde gebruikers informatie 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 realtime 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 ‘vrouwtje’ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing realtime lezen).][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 Gemeente ([merk, type, versie: bijv. Suite4Onderwijs/LLA4all/Key2Onderwijs/Key2Jongerenmonitor]) 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 ‘vrouwtje’ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing realtime lezen).][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 geautoriseerde gebruikers informatie over de burger en zijn / haar ontvangen voorzieningen kunnen opvragen dat is geregistreerd in het te koppelen systeem. [Alle functionaliteiten en berichten als beschreven in de specificaties van het betreffende ‘vrouwtje’ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing realtime lezen).][Hierbij wordt de database van het te koppelen systeem uitgelezen].

116

117

7.4 E9

Integratie landelijke en regionale voorzieningen 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 ondersteund (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 signaleringen kunnen indienen bij de 3D-Suite.

O76 Signaalwerking Beschrijf de mogelijkheden die de voorgaand gevraagde API van de 3D-Suite biedt, voor wat betreft -

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

118

Koppeling met CORV De 3D-suite integreert op zondanige wijze met de Collectieve Opdracht Routeer Voorziening18, zoals beschreven in de desbetreffende Project Start Architectuur. Dit betekent ondermeer dat gebruik 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 Aansluiting 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 binnen komen, en

-

in het integrale klantbeeld voor leerplichtige kinderen een aanduiding is dat het een vroegtijdige 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).

18

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, jeugdstrafrechtketen en jeugdbeschermingsketen gaan plaatsvinden, bijvoorbeeld een gestandaardiseerd Verzoek tot Onderzoek (VTO) als startmoment voor de jeugdbeschermingsketen; ook zullen de gemeenten allerlei gestandaardiseerde berichten uit de justitiële jeugdketens ontvangen en (2) beleidsinformatie richting V&J. VWS, VenJ en enkele gemeenten gaan hiervoor een proeftuin inrichten. 119

-

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 desgewenst geïmplementeerd bij Gemeenten (inbegrepen bij de prijsopgave en als zodanig zonder additionele 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 betreffende 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 versie(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 - indien het betreffende vrouwtje dit ondersteunt - daadwerkelijk sprake is van gegevensuitwisseling, incl. welke gegevens het betreft en of gebruikers daartoe nog handelingen dienen te verrichten (en zo ja welke, zoals: wordt bij een URL-koppeling gelinkt naar de betreffende “homepage” 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 realtime en batchgewijs.

-

Autorisatie op applicatie-niveau (bijv. d.m.v. certificaten en encryptie), incl. de mate waarin beveiliging en privacy worden gewaarborgd. 120

-

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 alleen “actief” is als de ingelogde gebruiker daar autorisatie toe heeft), incl. doelbinding. Beschrijf 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 (thuiswerkplek, 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 betreffende vrouwtje dit ondersteunt). Beschrijf daarbij tevens in welke mate en op welke wijze functioneel resp. technisch beheerders van Gemeenten de betreffende koppeling volledig zelfstandig, voor zover mogelijk zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), functioneel resp. technisch kunnen beheren.

121

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 ontwikkelen op de ‘vrouwtjes’ van Jeugdzorg-systemen v.w.b. uitwisseling van gegevens over personen, (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 schrijven)] De 3D-Suite integreert op dusdanige wijze met het zaaksysteem van de volgende uitvoeringsorganisaties 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 betreffende ‘vrouwtje’ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing realtime 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’]]

122

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 functionaliteiten en gegevens in de 3D-Suite. - Beschikbare generieke import/export mogelijkheden van metadata en/of documenten, die zelfstandig in te richten en geautomatiseerd te schedulen is (bij voorkeur o.b.v. StUF-Zkn en/of ZSDMS koppelvlak. - Met welke andere landelijke en/of sectorale voorzieningen de 3D-Suite over een gestandaardiseerde koppeling beschikt voor de bi-directionele uitwisseling van gestructureerde en/of ongestructureerde gegevens (incl. toelichting, zoals of daarbij gebruikgemaakt wordt van Digikoppeling, 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 zodanig 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 lopende 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 ‘compensating 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 documentatie / handleidingen over processen en processtappen, de procesgang, etc.

123

O82 Overige functionaliteiten: Broker/ESB Beschrijf alle eventuele additionele functionaliteiten op het gebied van de broker/ESB 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: - 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 scripting, 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 gegevenstandaarden jeugd. - Ondersteunde webservice- en andere standaarden, zoals XML, WSI, SOAP en WSDL, WS Adressing, WS Security, WS Reliable Messaging, XSD-authoring, XSLT, Xpath, MIME (voor attachments), etc. NB: Benoem uitsluitend functionaliteiten welke zijn inbegrepen bij de prijsopgave (zie ##) en die als zodanig zonder (additionele) kosten direct beschikbaar zijn.

124

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 iOverheid19 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. uitvoeringsorganisaties. 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 betreffende 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 onafhankelijke derde partijen. Eventuele vergoedingen aan dergelijke derde partijen in dat kader worden door Gemeente gedragen. Deze beveiligingstests/-audits kunnen naast de wettelijk vereiste audits onder 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) omvatten, alsmede data- en communicatiebeveiliging (incl. encryptie, certificaten, etc.), autorisatiemodellen, 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

19

www.ioverheid.nu 125

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 benaderen via) de 3D-Suite zodanig aan autorisaties onderworpen zijn dat ten minste kan worden 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 applicaties - 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.

126

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 geautoriseerde toegang kunnen worden gebruikt.

-

Bij iedere module of gegevensstroom is bekend welke persoonsgegevens zij omvat en per gegevenselement wat de risicoklasse daarvan is en wat de verwerkingsgrond is.

-

Binnen het klantdossier is informatie te ontsluiten aan specifieke personen (i.h.k.v. doelbinding).

-

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 nietgevoelige informatie zoals een attenderings-mail.

-

Het ondersteuningsplan 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 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 toegankelijk 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 gegevens 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 toestemming te vragen en / of géén inzage voor de burger / het gezin te verschaffen. De regisseur 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 watinformatie te minimaliseren zonder dat dat de efficiency en/of de beveiliging van de betreffende burgers beperkt.

127

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 20

.

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.

20

http://ec.europa.eu/justice/dataprotection/document/review2012/com_2012_11_nl.pdf 128

Denk hierbij aan o.a.: -

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 professional, 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. tweefactor-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 loginnaam/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 3DSuite zijn door functioneel beheerders van Gemeente geheel zelfstandig, zonder dat daarvoor geavanceerde 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 inge129

lezen worden in de 3D-Suite. 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 regisseurs).

O86 Autorisatiemodel Beschrijf het autorisatiemodel van de 3D-Suite. Ga daarbij ten minste in op (voor zover van toepassing): -

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, applicaties, 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 kunnen worden toegekend, alsmede op het ‘afleiden’ van autorisaties uit aanvullende geregistreerde 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 betreffende zaaktype, de actuele status / stap / taak (zie par. 4.2.4), de van toepassing zijnde bedrijfs-/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 coding), kunnen beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus). -

De wijze waarop door middel van autorisaties en/of eventuele andere soortgelijke maatregelen

-

Of en zo ja hoe wordt afgedwongen dat bij autorisatiewijzigingen de betreffende gebruiker(s),

invulling gegeven wordt aan wettelijke voorschriften zoals doelbinding, functiescheiding, etc. vanaf het moment waarop deze worden doorgevoerd, geen handelingen meer kunnen verrichten die zij dan niet meer mogen (c.q. juist wel), bijvoorbeeld door opnieuw inloggen te ‘forceren’.

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

130

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 (voor zover van toepassing): -

De verschillende handelingen en pogingen daartoe waarvan logging plaatsvindt, zoals opvragen (incl. zoeken), inzien (incl. printen), creëren / toevoegen, muteren, verwijderen, archiveren, 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 zaakattributen, documenten en documentattributen, notities, statuswijzigingen, het afvinken van checklists, 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 geautoriseerd. 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 tenslotte 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 zelfstandig, 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 maatregelen invulling gegeven wordt protocollering. Ga daarbij ten minste in op (voor zover van toepassing): -

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 geprotocolleerd (bij voorkeur wel), zoals inzage d.m.v. geautoriseerde toegang, herleidbare verstrekkingen 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 dezelfde gegevens worden geregistreerd.

-

De wijze waarop het ‘archiefregime’ (bewaren / vernietigen) van de betreffende logging is ingeregeld 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-

131

standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen beheren (zoals via configuratie van zaak-/objecttypen in een zaak-/objecttypencatalogus).

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 zelfstandig, 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 functionaliteit 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, zodanig 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).

132




Maatregelen die het wijzigen van gegevens (incl. documenten) buiten (de webinterface van) de 3D-Suite om voorkomen (zoals bij koppelingen).

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 (automatische) 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 externe 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.

133

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 aanduidingen (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. architectuurschets; 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 samenhangen 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 (functioneel 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 zoals (major- en minor)releases, patches, updates, etc. Voeg tevens een releaseplanning / roadmap

134

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 applicaties 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 3DSuite (éé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 “selfservice” 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 gehouden wordt met aspecten als integriteit, onderhoudbaarheid, portabiliteit, betrouwbaarheid, schaalbaarheid, beveiliging, efficiency, performance en andere aspecten als beschreven in de extended 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 bestpractices), 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 soft135

ware (door)ontwikkeld wordt en met welke tooling. Beschrijf daarbij ook de (omvang en specifieke expertise van) ontwikkel- en testteam(s), incl. eventuele relevante certificeringen t.a.v. softwareontwikkeling - 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 noodzakelijkerwijs ‘webbased’ te zijn.]

NB: volledig webbased wil hier bovendien zeggen dat deze gebruikersinterfaces ten minste benaderbaar 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 functionaliteit 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 (Windows, 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 eventuele 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

136

[en technisch] beheerder.

O99 Serverside architectuur: algemeen Beschrijf de serverside architectuur van de 3D-Suite, incl. architectuurschets (schema met applicatie-, 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 softwarecomponenten dienaangaande, gegeven de gewenste performance, beschikbaarheid en beveiliging.

-

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 verhouden, 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. schaalbaarheid, gegeven het beoogde aantal gebruikers (ca. [XX]) en de gewenste performance, beschikbaarheid en beveiliging. Voeg hiertoe een architectuurschets bij en beschrijf de verschillende mogelijke ‘maatregelen’ en technieken om zowel de horizontale (zoals extra servers, load balancers, 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 balancing, fail-over, virtualisatie, etc. en beschrijf welke merkbare gevolgen het verhogen van de horizontale resp. verticale schaalbaarheid heeft voor eindgebruikers [(incl. burgers)], functioneel [en

137

technisch] beheerders, etc. Beschrijf tenslotte de (technische en/of functionele) grenzen t.a.v. het aantal openstaande en afgesloten 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, database(server)s, bestandssystemen, SAN’s, etc.).

-

De mate waarin sprake is van gedeelde servers, communicatie (hubs etc.) en databases/SAN’s.

-

Eventuele andere technische / infrastructurele aspecten (zoals netwerk, bandbreedte, opslagcapaciteit, hubs, firewalls, etc.).

-

Communicatie tussen de verschillende elementen (zoals netwerk, protocollen en poortnummers, 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]), uitgesplitst naar T-, A-, P- en U (ten minste [XX] separate omgevingen, bijvoorbeeld [XX]. Geef daarbij bovendien aan welke merken / typen / versies systeemsoftware (besturingssystemen, databases, 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 benodigde 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 beheer van de 3D-Suite. Ga daarbij ten minste in op: -

Eigen (1P) beheer-, rapportage-, monitoring- en analysetools - incl. de betreffende beheerinterface(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 138

beheren, o.v.v. de specifieke expertise, kennis, vaardigheden, etc. die hiertoe aanwezig verondersteld 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, updates, (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 (gedocumenteerde) 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, beveiligingsaspecten, 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 [Werkdagen 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 infrastructuur 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# seconden worden getoond.

-

In de test-, acceptatie- en uitwijkomgevingen van de 3D-Suite alle interactieve gebruikersinterfaces van de 2D-Suite voor rollen eindgebruikers en functioneel beheerders in ten minste 90,0% van de gevallen binnen #2# seconden worden getoond.

139

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 [periode] als bij een piekbelasting van [XX] transacties / zaken / documenten per [periode]. De 3DSuite is hiertoe ook in staat wanneer het een archief van [XX] jaar bevat dat kan worden doorzocht (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 verlenging) aan het beleid van Gemeente met betrekking tot open source software. Dit beleid is conform 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 verlenging) 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-leguit’]. 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. Daarnaast 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

21

.

G32 (Open) standaarden: RGBZ [versie] Daar waar binnen de 3D-Suite zaakgegevens worden geconfigureerd, geregistreerd of in welke

21

https://new.kinggemeenten.nl/operatie-nup 140

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 RSGB zijn gemodelleerd of in welke vorm dan ook worden gebruikt, verwerkt of uitgewisseld, geschiedt 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 voorkomen 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 gemeentebrede systemen, landelijke voorzieningen, etc.) zaak- en documentgegevens worden uitgewisseld, geschiedt dit - tenzij nadrukkelijk anders voorgeschreven in dit PvE - ten minste (d.w.z. dat uitbreiding 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-DMSkoppelvlak volledig toegankelijk voor leesacties, met inachtneming van de betreffende autorisaties.

O105 (Open) standaarden: Landelijke Standaard Informatieverkeer Jeugdzorg De 3D-Suite ondersteunt de standaarden in het jeugddomein. Deze standaarden in het jeugddomein zijn een gegeven voor de gemeenten bij het aansluiten op de jeugdketen. De standaarden 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

22

22

.

https://www.zorgregistratie.nl/bep/wmo10/html/aa_reportstart.html 141

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 3DSuite 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-testplatform23, etc.) en voeg eventuele certificaten, 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 basisimplementatie 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.

23

Zie www.stuftestplatform.nl 142

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 dusdanige 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 applicatieinstellingen (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) beheertaken 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. koppelingen, op technisch niveau). De training van deze groep dient dan ook met name hierop betrekking 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!

143

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 Nederlands- en/of Engelstalig. Alle Documentatie van de 3D-Suite wordt door Contractant aan Gemeente (ook) beschikbaar gesteld in aanpasbare bestandsformaten (dus niet (alleen) als PDF en dergelijke).

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 3DSuite, incl. alle functionele ontwerpen en beschrijvingen met inbegrip van (logische) datamodellen en technische ontwerpen van alle relevante koppelingen. Daarnaast verklaart Contractant zich akkoord met de verstrekking daarvan - onder toezegging van vertrouwelijkheid - aan eventuele belanghebbenden in dat kader (zoals potentiële deelnemers aan een dergelijke aanbesteding, partijen 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 gebruikers 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, elektronisch, 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 betreffende Documentatie wordt geüpdatet, incl. een begeleidende samenvatting (“what’s new”).

144

-

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 3DSuite - dus incl. koppelingen etc. - gedurende de looptijd (incl. eventuele verlening) van de Overeenkomst, zonder additionele kosten. D.w.z. dat Contractant gedurende de looptijd (incl. eventuele 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, waaronder 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 vrouwtjes van koppelingen, etc. Contractant is tevens verantwoordelijke voor het afsluiten van alle eventuele contracten met Toeleveranciers voor alle Onderhoud en Ondersteuning die nodig zijn voor het correct en probleemloos (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 benodigde software en is onafhankelijk van de wijze waarop softwareleveranciers in de aanbieding participeren.

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 kennispartner(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 “gemonitord” 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 Onderhoud 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 technische 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-

145

ze waarop de “regie” daarop geregeld is en hoe de continuïteit van de betreffende software gegarandeerd 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 minste 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 Dienstverlening te garanderen ook in het geval van bijvoorbeeld een faillissement. Contractant draagt de verantwoordelijkheid dat alle Code van de 3D-Suite, incl. eventuele aanvullende 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 verificatie aan Gemeente worden gerapporteerd. Contractant is verantwoordelijk voor een positief resultaat van de compilatie en verificatie. Voordat de compilatie- en verificatieprocedure begint, wordt er gecontroleerd of alle Code en andere materialen (incl. Documentatie) in het depot aanwezig zijn. T.b.v. van de compilatie en verificatie wordt vervolgens alle benodigde Systeemsoftware geïnstalleerd en worden de gedeponeerde materialen, incl. eventuele aanvullende software die daartoe benodigd is, gecompileerd op basis 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 compilatie- en verificatieprocedure. Het behoort in dit kader bovendien nadrukkelijk tot de verantwoor146

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, bijvoorbeeld 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 afbeeldingen). Daarnaast omvat Code alle tools en scripts (incl. beschrijvingen/documentatie hiervan) die nodig zijn om deze broncode te onderhouden en te executeren.

147

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 ontwerpers, 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 Onderaannemers) steeds het in het Projectplan genoemde Personeel ingezet. Behoudens uitdiensttreding of langdurige ziekte van het genoemde Personeel, kan vervanging van het genoemde Personeel 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 tussen 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 Versies - 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 148

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.

149

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 150

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 151

- 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 reintegratieapplicatie) - 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, bedrag koopsom, eigenaren en de wijze van verkrijging.

152

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 momenteel 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 motivatie van de aanmelding. - Bijlagen: zo nodig kunnen additionele documenten als bijlage toegevoegd worden.

153

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

154

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 reactie 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. opvoedingsondersteuning). De ouders worden in dat geval opgenomen als ‘Ondersteuningontvangers’. - Ondersteuningontvangers: De pers(o)on(en) die de daadwerkelijke ondersteuning ontvang(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 startdatum, 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.

155

- 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 plichten 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 behandeling?

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.

156

Ondersteuner A (bijv.Stadsbank)

Infouitwisseling

Clienttraject

Regievoerder

Ondersteuningstraject A.1

Ondersteuner B (bijv. Tactus: verslavingszorg)

Ondersteuningstraject A.2

Ondersteuningstraject B.1

tijd 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 traject 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 Ondersteuningsarrangement. - 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, bestaande uit documenten en uitgewisselde berichten. Trajecten kunnen verwijzen naar bovenliggende of deeltrajecten, die op hun beurt ook weer een Dossier kunnen bevatten. Het is een implementatiekeuze 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.

157

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

158

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 ondersteuning. - 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 uitbreidbaar 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 inkomen’.

159

- 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 voorkomen 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 ontvang(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 ondersteuningstraject horen, etc. (zie het informatie-element Traject).

160

12.4

Voorbeeld: elementen in een zelfredzaamheidsmatrix

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/

161

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, Jeugdzorg, etc. o Politie/justitie/gedwongen kader
Meldingen bij politie, strafrechtelijk verleden, veiligheidshuis, …

162

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 Jeugdzorg24, zoals die nu vastgesteld zijn, kort geschetst. Ook de hoofdproces van Centra voor Jeugd en Gezin (CJG)25 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

24

25

De informatie van het ketenproces Awbz en Wmo is afkomstig van CVZ (zorgregistratie.nl), die van het ketenproces Jeugdzorg van ‘Referentiewerkmodel Bureau Jeugdzorg’, vs 2.0, 2005 ‘Werkprocessen CJG’, Ieder Kind Wint, 2009 163

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 164

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

26

Presentatie Bedrijfsfunctiemodel Zorg en Ondersteuning, januari 2013. Toekomstbeeld 2016 Informatievoorziening Zorg en Ondersteuning, mei 2012 165

12.7

Voorbeeld: online communities en ‘marktplaatsen’

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

166

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

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

- IOAZ:

Inkomensvoorziening oudere en gedeeltelijk arbeidsongeschikte gewezen zelfstandigen

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

- 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

168

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 [email protected] WWW.KINGGEMEENTEN.NL