Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
1
CONCEPT PROGRAMMA VAN EISEN
Informatievoorziening t.b.v. ondersteuning
regie in het sociaal domein: 1-gezin 1-plan 1-regisseur
2
Colofon
Concept-Programma van Eisen
Informatievoorziening t.b.v. ondersteuning regie in het sociale domein: 1-gezin 1-plan 1-
regisseur
Opdrachtgevers KING, Dimpact, GovUnited
Auteurs Zie par. 1.3.
Eindredactie Frank Kuiper
Versie 0.92
Datum 29 juli 2013
3
Inhoudsopgave
1 Inleiding 6
1.1 Voorwoord 6
1.2 Doel Programma van Eisen 7
1.3 Programma van Eisen 10
1.4 Terminologie 11
1.5 Leeswijzer 11
2 Scope 13
2.1 Inleiding 13
2.2 Regiemodellen 17
2.3 Burgerportaal 20
2.3.1 Inleiding 20
2.3.2 Informatievoorziening en vraagverheldering 20
2.3.3 Inzage in eigen integraal klantbeeld (inclusief plan) 21
2.3.4 Communicatie 22
2.4 Regie 24
2.4.1 Integraal klantbeeld (incl. Inkijk) 24
2.4.2 Het ondersteuningsplan (1-plan) 26
2.4.3 Inkomende/uitgaande signalen en meldingen 27
2.4.4 Ongestructureerde communicatie en interactie 28
2.4.5 Gestructureerde ketenberichten 29
2.5 Regie op regie 30
3 Uitgangspunten PvE 32
3.1 Varianten en fasering 32
3.2 Plusfunctionaliteiten 33
3.3 Opties 34
3.4 Overige uitgangspunten 34
3.5 Eisen en wensen 36
3.6 Juridische en financiële eisen en wensen 37
4 PvE: Generieke functionaliteit 39
4.1 Inleiding (generieke functionaliteit) 39
4.2 Processen (regievoering en bewaking) 39
4.2.1 Inleiding 39
4.2.2 Registreren klantcontacten en zaken 40
4.2.3 Zaakbeheer 40
4.2.4 Zaakbehandeling 42
4.3 Gegevens en dossiers 46
4.3.1 Inleiding (gegevens) 46
4.3.2 Gegevensbeheer en -opslag 46
4.3.3 Gegevensregistratie en intake 49
4.3.4 (Management)rapportages 53
4.4 Documenten en sjablonen 54
4.4.1 Inleiding (documenten) 54
4.4.2 Basisfunctionaliteit 54
4.4.3 Documentcreatie en -opslag 55
4.4.4 [Archivering] 57
4
4.5 Medewerkerportaal en werkbak 59
4.5.1 Signaleringen en contacten 59
4.5.2 Filteren en sorteren 60
4.5.3 Beslisondersteuning en vraagverheldering 60
4.5.4 Dienstenboek (product- dienstencatalogus) 62
4.5.5 Zoeken 63
4.5.6 Kalenderfunctionaliteit 65
4.5.7 Financiën en overige regie op regie 67
4.5.8 Medewerkerportaal voor gebruikers buiten de gemeente 68
4.6 Burgerportaal (zelfregie) 70
5 PvE: Specifieke inrichting 72
5.1 Inleiding 72
5.1.1 Overzicht gebruik 72
5.1.2 Primaire en secundaire functies 3D-Suite 76
5.1.3 Specifieke wensen en eisen 81
5.2 Regie 83
5.3 Burgerportaal (zelfregie) 85
5.3.1 Niet-gepersonaliseerd burgerportaal (oriëntatie & informatie) 85
5.3.2 Gepersonaliseerd Burgerportaal 87
5.4 Het regieproces 91
5.4.1 Integraal klantbeeld 91
5.4.2 (Inkomende) signaleringen, meldingen en contacten 92
5.4.3 Intake, doelstelling, maatregelselectie en ondersteuningsplan 94
5.4.4 Taken/acties incl. signalen en ketenberichten 97
5.4.5 Procesbewaking/evaluatie/nazorg 101
5.5 Regie op regie (budget, contract, kwaliteit, etc.) 103
5.6 Standaardcontent 105
6 PvE: Gebruiksvriendelijkheid 107
7 PvE: Integratie 111
7.1 Inleiding 111
7.2 Interne integratie 112
7.3 Gemeentelijke basisadministraties en backofficesystemen 115
7.4 Integratie landelijke en regionale voorzieningen 118
7.5 Zaaksysteem en backofficesystemen van UO‟s 122
7.6 Integratie-tooling 123
8 PvE: Autorisatie, beveiliging en privacy 125
8.1 Inleiding 125
8.2 Wet- en regelgeving 125
8.3 Toegang tot informatie: doelbinding en privacy 127
8.4 Authenticatie en autorisatie 129
8.5 Auditing / logging 130
8.6 Technische beveiliging en integriteit 132
8.7 Overig (beveiliging) 133
9 PvE: Architectuur 134
9.1 Inleiding 134
9.2 Functionele architectuur 134
5
9.3 Softwarearchitectuur 135
9.4 Client- en serverside architectuur 136
9.5 Technische architectuur 137
9.6 Beschikbaarheid en performance 139
9.7 Beleid en (open) standaarden 140
9.8 Openheid systeem 142
10 PvE: Periodieke / doorlopende dienstverlening 143
10.1 Inleiding 143
10.2 Training 143
10.3 Documentatie 144
10.4 Onderhoud 145
10.5 Ondersteuning 146
10.6 Escrow 146
11 PvE: Eenmalige dienstverlening 148
11.1 Inleiding 148
11.2 Algemeen 148
11.3 Implementatie 148
11.4 Migratie 149
11.5 Concept Plan van Aanpak 149
12 Bijlagen 150
12.1 Zaakgericht werken 150
12.2 Overzicht gegevens in Digitaal Klantdossier / Suwinet 151
12.3 Voorbeeldinrichting 153
12.3.1 Functionele informatie-eenheden 153
12.3.2 Generieke informatie-elementen 156
12.4 Voorbeeld: elementen in een zelfredzaamheidsmatrix 161
12.5 Voorbeeld: klantbeeld 162
12.6 Voorbeeld: hoofdprocessen Awbz, Wmo en Jeugdzorg 163
12.7 Voorbeeld: online communities en „marktplaatsen‟ 166
12.8 Afkortingenlijst 167
6
1 Inleiding
1.1 Voorwoord
Met genoegen bieden wij u hierbij versie 0.9 aan van het programma van eisen (PvE)
„informatievoorziening ten behoeve van ondersteuning regie in het sociale domein: 1-gezin 1-plan
1-regisseur‟. Al met al een omvangrijk document dat de stand van zaken weergeeft per mei 2013.
Stand van zaken
Versie 0.9 van het PvE is tot stand gekomen als onderdeel van het project Verkenning
Informatievoorziening Sociaal Domein (VISD) dat door KING in opdracht van de VNG is uitgevoerd
van oktober 2012 tot en met juni 2013. Deze versie van het PvE omvat generieke eisen en wensen
m.b.t. een informatiesysteem voor regie in het Sociaal Domein en is daarom geen definitieve
versie. Een volledig aanbestedingsbestek omvat daarnaast ook een gedetailleerde beschrijving van
de aan te besteden opdracht, procedurele / juridische aspecten, etc. Ook worden de
organisatorische, juridische, en andere aspecten die de inrichting en het gebruik door de gemeente
zelf hier nog niet geadresseerd. Feitelijk gebruik en inrichting zal dan ook per gemeente
verschillen.
Het PvE kan als basis dienen voor een aanbestedingsbestek - of een aanzet geven tot een
functioneel ontwerp wanneer de gemeente eigen reeds aanwezige applicaties gaat inzetten. Voor
individuele gemeenten zal een en ander nog moeten worden herschreven naar de eigen specifieke
situatie.
Hoe nu verder?
Dit document is met veel inzet en enthousiasme van gemeenten tot stand gekomen. Zij hebben
zich daarbij ook laten inspireren door de markt. Wat kunnen gemeenten ermee? Een groot deel van
de gemeenten kan hiermee niet zonder meer aan de slag en zal eerst voorbereidende
werkzaamheden moeten verrichten.
Hoe ziet het beleid eruit? Wat voor sturingsmodel wordt gekozen door gemeenten in overleg met
hun partners? Wat betekent dit voor de organisatie-inrichting en hoe gaan de processen verlopen
al dan niet met sociale partners? Als deze vraagstukken zijn beantwoord, kun je vaststellen welke
ondersteuning op het gebied van informatievoorziening gewenst is.
Bij het vaststellen van de benodigde ondersteuning zal de gemeente ook onderzoeken wat men al
beschikbaar heeft aan informatievoorziening en zich de vraag stellen: „Hoe positioneer ik de nieuwe
functionaliteiten of voorzieningen voor ondersteuning van regie? Informatiemanagers hebben
behoefte aan handvatten bij de interpretatie en toepassing van het PvE.
KING zal deze vraagstukken en de hierbij te maken afwegingen de komende maanden verwoorden
in de vorm van een handreiking bij het PvE. Het kunnen beschikken over inspirerende
voorbeelden is hierbij ook erg belangrijk, hoe hebben andere gemeenten dit opgepakt en ingericht.
In een aantal bijeenkomsten zullen we het PvE en de handreiking ook toetsen aan de praktijk.
Daarnaast zal KING een leveranciersdag organiseren om leveranciers en de gemeenten de kans
te bieden om vrijblijvend van elkaars wensen en mogelijkheden kennis te laten nemen. Dan is de
finale versie van het globale PvE versie 0.9 er om als toetssteen te dienen en in breder verband te
presenteren.
7
Doorontwikkeling
Op basis van het PvE versie 0.92 zal doorontwikkeling plaatsvinden. KING wil hiervoor de regie op
zich nemen en zal hiertoe een proces van beheer en doorontwikkeling inrichten. Ook daarbij is het
vanzelfsprekend dat samen gewerkt gaat worden met gemeenten.
Verspreiding
Het PvE v0.9 en de handreiking worden opgeleverd als onderdeel van het eindadvies VISD in juli
2013. De documenten moeten voor een goed begrip in onderlinge samenhang worden gelezen. Tot
die tijd wordt verzocht de verspreiding waar mogelijk beperkt te houden.
In geval van vragen kan contact met KING worden opgenomen via [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 1-
regisseur‟. Dit in het kader van de decentralisaties in het sociale domein. De kerngedachte achter
de decentralisaties is de integrale aanpak en het versterken van de zelfredzaamheid van de burger.
Om dit te realiseren wordt de (regie-)rol/ verantwoordelijkheid van gemeenten als meest nabije
(en logische) overheid versterkt.
De rijksoverheid draagt grote taken op het gebied van Jeugdzorg, AWBZ en participatie over naar
de gemeenten. Ook de stelselwijziging Passend Onderwijs heeft invloed op het sociale domein.
Deze transitie wordt gevisualiseerd in figuur 1.
Figuur 1 decentralisaties
Deze decentralisaties maken het gemeenten noodzakelijk verbanden te leggen tussen de
Wmo/Awbz, jeugdzorg en werk en inkomen. Dit resulteert in „1 gezin, 1 plan, 1 regisseur‟, waarbij
de gemeente en de ketenpartners worden ondersteund door 1 informatievoorziening met een brede
8
blik over de verschillende werkvelden. Een platform dat de integrale
aanpak en de samenwerking faciliteert en aanvullend is op de eigen bedrijfsvoeringsystemen.
Veel gemeenten zijn al bezig met het vormgeven van een integrale aanpak op wijkniveau en er
moeten daarbij ook slagen gemaakt worden m.b.t. de informatievoorziening van professionals. Een
belangrijke gedachte bij de decentralisaties is de integrale aanpak en het versterken van de
zelfredzaamheid van de burger. Om dit te realiseren wordt de regierol en -verantwoordelijkheid
van gemeenten als meest nabije (en logische) overheid versterkt. Het versterken van de
zelfredzaamheid van de burger zelf is een belangrijk doel. Preventie kan immers zorgen voor lagere
kosten voor ondersteuning en regie. Hier is echter niet perse een nieuw informatiesysteem nodig,
want het bevorderen van zelfredzaamheid kan wellicht al vorm krijgen via bestaande systemen.
Het PvE heeft ook niet als uitgangspunt dat het nieuwe informatiesysteem de inhoudelijke
uitvoeringsprocessen van alle domeinen ondersteunt of dat alle nu in gebruik zijnde
backofficesystemen kunnen worden vervangen. Het doel van het PvE is niet het beschrijven van de
functionaliteiten die benodigd zijn voor de feitelijke uitvoering van ondersteuningsmaatregelen,
maar voor de regie daarover.
Dit PvE richt zich daarom primair op een informatievoorziening t.b.v. de regiefunctie in het sociale
domein. De gevraagde inrichting van een applicatie of set van applicaties wordt in dit document
aangeduid als „3D-Suite‟: een suite van applicaties t.b.v. ondersteuning van de regievoering over
het sociaal domein waar onder meer de 3 decentralisaties (3D) rond Jeugdzorg, AWBZ en
participatie binnen vallen.
Regie omvat hier de waarde die een professional toevoegt aan de ondersteuning van een gezin,
door zelf het gezin te ondersteunen maar ook door indien nodig de afstemming te organiseren
tussen andere ondersteuningsaanbieders (bijv. in geval van multiprobleemgezinnen). Een regisseur
kan dan „vanaf de keukentafel‟ van een burger of gezin regie voeren over verschillende
uitvoeringsorganisaties zoals een Bureau Jeugdzorg en verschillende organisatie-eenheden binnen
de gemeente. Het keukentafelgesprek (als metafoor voor een integrale intake en aanpak) is een
kern van dit PvE.
De informatiestromen rond een enkel gezin waar de regisseur rekening mee moet houden kunnen
schematisch als hieronder in figuur 2 worden weergegeven (bron: Hans Versteeg / VNG).
Figuur 2 Informatiestromen 'rond de keukentafel'
9
Er is echter niet enkel sprake van multiprobleemgezinnen waarbij ieder
traject verschilt, maar ook eenvoudige, enkelvoudige, snelle ondersteuning of van multi-
disciplinaire standaardondersteuning (standaard ondersteuningsvormen, doch met meer betrokken
partijen).
Bij enkelvoudige, maar vooral bij meervoudige hulpvragen is een integrale intake/ beoordeling en
een afgestemde uitvoering essentieel. Daarnaast kan de regie betrekking hebben op de bewaking
en verantwoording van budgetten en de resultaten van ondersteuning(-sancties) en sturing vanuit
management en beleid.
Daarnaast is het denkbaar dat er preventieve maatregelen worden genomen. Regievoering over
generieke brede preventieve maatregelen zoals een bewustzijncampagne of een speelplaats valt
echter buiten de scope van het onderhavig Programma van Eisen (PvE).
10
1.3 Programma van Eisen
Het concept-PvE is opgesteld in opdracht van KING, Dimpact, GovUnited en de gemeente Enschede
in het kader van het project “Verkenning Informatievoorziening Sociaal Domein” (VISD) dat door
KING wordt uitgevoerd in opdracht van de VNG 1. Dit PvE is geschreven door adviesbureau
M&I/Argitek i.s.m. een taskforce PvE van materiedeskundigen vanuit verschillende gemeenten en
vanuit KING:
- Anton van der Linden, gemeente Helmond - Lars Fehse, gemeente Enschede
- Berny Oude Kempers, gemeente Eindhoven - Martin de Bijl, Dimpact
- Frank Kuiper, M&I/Argitek (eindredactie) - Martin Putman, gemeente Rheden
- Frits Dreschler, gemeente Ede - Ronald de Zwart, KING
- Klaas Jan de Regt, gemeente Leeuwarden - Wouter Keller, M&I/Argitek (voorzitter)
De taskforce is t.b.v. domeinspecifieke inrichting aangevuld met een verdiepingsgroep:
- Jannie Holthuis, gemeente Emmen - Remco Groenendal, gemeente Gemert-Bakel
- Joop Kuiper, gemeente Almelo - Tom Uleman, gemeente Zaanstad
- Joost Broumels, KING (voorzitter) - Vanessa Timmer, gemeente Gilze en Rijen
- Marrie Hol, gemeente Zwolle - Vincent Weijers, gemeente Berkelland
- Pieter in 't Hout, gemeente Utrecht
De Stuurgroep specifiek voor het Programma van Eisen bestaat uit:
- Arjen Hof, GovUnited
- Dick Laan, gemeente Enschede (voorzitter)
- Joost Broumels, KING
- Rene Bal, Dimpact
- Wouter Keller, M&I/Argitek (projectleider)
Het PvE leidt voor gemeenten niet perse tot de aanschaf van een nieuw systeem. Het is denkbaar
dat bestaande, bij een gemeente aanwezige, pakketten en functionaliteiten gebruikt gaan worden,
maar ook dat nieuwe systemen worden aangeschaft. De gevraagde suite van applicatie(s) kan ook
bestaan uit een mix van reeds aanwezige en nog in te richten applicaties. Als alle applicaties al
aanwezig zijn en implementatiekosten onder de aanbestedingsgrenzen blijven, zal er geen sprake
hoeven te zijn van een aanbesteding. Termen als „Inschrijver‟ en „3D-Suite‟ dienen dan ook met
deze gedachten te worden gelezen.
Het document is beschreven vanuit een zaakgerichte visie. Om een eenduidige –en bij gemeenten
gangbare– terminologie aan te houden is zaakgericht werken gebruikt als kapstok v.w.b.
modellering, uitvoering en uitwisseling van de processen en dossiers. Echter wordt benadrukt dat
dit géén vooraf vastliggende processen impliceert. Flexibiliteit is noodzakelijk. Een en ander kan
bijvoorbeeld op basis van een al dan niet reeds aanwezig zaaksysteem worden ingericht, met
aanvullend meer ad-hoc flexibiliteit en enige 3D-speficieke functionaliteiten die later in het
programma van eisen zijn beschreven. Doch de gevraagde functionaliteiten kunnen ook op basis
van bijv. een case management of workflow/processysteem worden ingericht. Het gaat om de
functionaliteit.
1 VISD: zie ook https://new.kinggemeenten.nl/decentralisaties/project-visd
11
Als PvE omvat dit document „slechts‟ eisen en wensen m.b.t. het
informatiesysteem. Het is geen volledig aanbestedingsbestek, dat immers ook een gedetailleerde
beschrijving omvat van de aan te besteden opdracht, procedurele / juridische aspecten, etc. Ook
worden de organisatorische, juridische en andere aspecten die de inrichting en het gebruik door de
gemeente zelf hier nauwelijks geadresseerd. Feitelijk gebruik en inrichting zullen ook per gemeente
kunnen verschillen. Niet alle functionaliteiten zijn wellicht (op korte / middellange termijn)
gewenst. Gemeenten zullen eerst een goed beeld willen vormen van het eigen beleid en de
inrichting van hun eigen bedrijfsvoering. Het programma van Eisen kan daarna op het beleid en
bedrijfsvoering worden aangepast.
Het PvE kan als zodanig als basis dienen voor een aanbestedingsbestek - of een aanzet tot een
functioneel ontwerp wanneer de gemeente zelf reeds aanwezige applicaties gaat inzetten. Voor een
specifieke gemeente zal een en ander nog moeten worden herschreven naar de eigen specifieke
situatie. Ook is het PvE onder enige tijdsdruk (in ca. 3 maanden) geschreven en daardoor nog een
concept (versie 0.92) dat verder uitgewerkt kan worden.
1.4 Terminologie
In de verschillende domeinen die binnen de scope van onderhavige PvE liggen, worden soms ver-
schillende termen gebruikt. Waar in dit document sprake is van bijv. een burger, kan ook bijvoor-
beeld „klant‟ of „burger‟ worden gelezen. Dit geldt ook voor andere termen. Tenzij anders geduid in
de tekst kunnen deze termen als synoniemen worden gezien.
- Cliënt, klant, burger, patiënt, persoon zijn veelal synoniem. En alles dat voor een individuele
burger geldt, geldt ook voor een geheel gezin: bijv. 1 ondersteuningsplan voor een gezin is
v.w.b. de benodigde functionaliteiten veelal niet anders dan een plan voor een individu.
- Waar gezin staat, kan ook worden gelezen bijv. familie, samenwonende mensen met / zonder
kinderen, in voorkomende gevallen andere samenlevingsvormen, etc.
- 1-plan, ondersteuningsplan, plan van aanpak zijn synoniemen
- Klantdossier, cliëntdossier, burgerdossier (vormgegeven o.b.v. een zaakdossier) zijn synonie-
men
- Traject, case, zaak, ondersteuningsproces (de uitvoer van het ondersteuningsplan) zijn syno-
niemen
- Zaakbak, werklijst, werkbak, trajectbak, etc. zijn synoniemen
- Dienstenboek, productenlijst, PDC (product- en dienstencatalogus) zijn synoniemen
- Medewerker, professional, hulpverlener, ondersteuner zijn synoniemen (voor zover de onder-
steuner toegang heeft tot het systeem)
- Uitvoeringsorganisatie, ketenpartner zijn synoniemen
- Zorg, ondersteuning, hulp, etc. zijn synoniemen
- Etc.
Later in dit document zullen de verschillende termen worden uitgelegd.
1.5 Leeswijzer
Het onderhavige document bestaat, naast deze managementsamenvatting / leeswijzer, grofweg uit
een drietal onderdelen: een inleidende beschrijving van de scope/beoogd gebruik (hoofdstuk 2),
een aantal uitgangspunten en opmerkingen over de opzet van het PvE, het daadwerkelijke
Programma van Eisen (hoofdstuk 4- 11) en tenslotte de afsluitende bijlagen (hoofdstuk 12).
12
Het lezen van enkel de hoofdstukken 1 tot en met 3 geeft reeds een goed
beeld van het domein en de scope.
Het PvE maakt in de volgende hoofdstukken onderscheid in generieke en specifieke
functionaliteiten. Generieke functionaliteiten zouden ook voor andere domeinen kunnen worden
ingezet. Specifieke functionaliteiten worden met name uitgevraagd in hoofdstuk 5 en zijn gericht
op de 3D-domeinen en betreffen bij voorkeur een specifieke inrichting van de eerdergenoemde
generieke functionaliteiten.
Verschillende gemeenten hebben verschillende behoeften, bijvoorbeeld als het gaat om de invulling
van de regierol. Daarnaast zijn nog lang niet alle kabinetsplannen in detail uitgewerkt. Daarom is
flexibiliteit van het informatiesysteem van groot belang. Dat kan bereikt worden door de specifieke
functionaliteiten van hoofdstuk 5 zo veel mogelijk door middel van generieke functionaliteiten in te
richten. Deze configuratie kan bij voorkeur ook door de gemeente zelf en zonder programmering
(zero-coding) worden aangepast.
13
2 Scope
2.1 Inleiding
Financieel onvermijdelijk
Wat is de unieke functionaliteit die nodig is voor de ondersteuning van de drie decentralisaties? En
waarom is het noodzakelijk deze functionaliteiten nu al te beschrijven terwijl de wetsvoorstellen
nog niet in detail zijn uitgewerkt? Het antwoord daarop zijn de financiële consequenties van het
ongewijzigde beleid. De uitgaven aan de AWBZ stijgen met 4,3 procent per jaar, deze groei is veel
hoger dan de economische groei en daarmee zal het aandeel van het nationaal inkomen wat aan
de AWBZ wordt uitgegeven bij ongewijzigd beleid groeien tot een derde in 2040. Het huidige
kabinet heeft de benodigde bezuinigingen al ingeboekt en daarmee zijn de decentralisaties
onafwendbaar geworden. Mocht dit kabinet tussentijds ten val komen zal dat uiteindelijk alleen
maar vertraging betekenen, de bezuinigingen blijven echter noodzakelijk.
Ongeacht de samenstelling van het kabinet; de stijging van de uitgaven aan zorg/ondersteuning
zal moeten worden aangepakt. In de huidige plannen worden de taken overgedragen met een
korting van 20% tot 30% van het budget. Met de gedecentraliseerde taken zal het aandeel van de
uitgaven op het sociale domein voor sommige gemeenten richting de 50% gaan van de totale
begroting. Daarmee zijn de decentralisaties voor de gemeente een groot financieel risico. Gezien
de aanzienlijke kortingen op het budget en de financiële risico‟s voor de gemeente is het helder dat
de gemeente deze taken structureel anders moet uitvoeren dan het op dit moment door de
rijksoverheid wordt uitgevoerd. De twee centrale pijlers voor deze andere aanpak zijn eigen
kracht/burgerkracht en integrale aanpak/regie.
Mede vanwege de onzekerheden is flexibiliteit van een informatieplatform van groot belang.
Aanleiding PvE
Al enige jaren wordt vanuit de ministeries van Sociale Zaken, Veiligheid en Justitie en VWS een
aantal decentralisaties aangekondigd. Het gaat daarbij om de transitie van de taken (intramurale)
AWBZ, Jeugdzorg, Participatiewet en passend onderwijs (zie ook figuur 1 op blz. 7).
Sinds de bekendmaking door de ministeries zijn gemeenten druk aan de slag gegaan met
onderzoek naar hoe om te gaan met de transities en met de voorbereidingen om de transformaties
te laten plaatsvinden. Daarbij zijn er binnen gemeenten (of samenwerkingsverbanden) in eerste
instantie vaak per transitie (/decentralisatie) werkgroepen ingericht. Na verloop van tijd werd
duidelijk dat de decentralisaties enkel efficiënt opgepakt kunnen worden als de domeinen
ontkokerd worden en de verschillende decentralisaties over het hele sociale domein integraal
opgepakt worden. De vele taken van de verschillende domeinen moeten uitgevoerd worden met de
daarbij opgelegde significante bezuinigen. Daarmee verschoof de focus van de losse
implementaties per decentralisatie/domein naar de ondersteuning van de regierol over alle
ondersteuning in het sociale domein. Al snel werd duidelijk dat informatievoorziening daarvoor een
belangrijke randvoorwaarde wordt.
Dit is initieel vertaald in het architectuurmodel 3D‟s: zie figuur 3 “werkplaat van de gemeente
Enschede”. Hierin is een vertaling gemaakt en een verbinding gelegd tussen de beleidsmatig
ingestoken ondersteuningspiramide en benodigde functionaliteiten.
14
Figuur 3 Ondersteuningspiramide en informatievoorziening
Informatiekundig wordt dus niet het inhoudelijke uitvoeringsproces van de desbetreffende
decentralisaties ondersteund. Functioneel staat de regie op het sociale domein, inclusief een
integraal klantbeeld en integrale klantondersteuning, centraal.
Dit betekent ook iets voor de focus van dit stuk; waar eerst gesproken werd van een systeem ter
ondersteuning van de professionals rond 3D zijn de in dit document beschreven functionaliteiten
gericht op het ondersteunen van de regie. Dit heeft er ook toe geleid dat tijdens het denk- en
schrijfproces binnen de diverse werkgroepen een ander beeld van noodzakelijke functionaliteiten
gevormd is. Een goed voorbeeld is het burgerportaal dat aanvankelijk geen onderdeel van de scope
uit maakte maar nu toch vrij uitgebreid behandeld wordt. Zo zijn er meer kleinere of grotere
onderwerpen te benoemen die aanvankelijk wel of juist geen onderdeel van de scope zijn geweest
en nu terug komen in het uiteindelijke document.
Voor de lezer willen wij het advies mee geven dit stuk niet te lezen als de totaaloplossing voor de
transformatie i.v.m. de decentralisaties (incl. grote organisatorische, juridische, en andere
vraagstukken). Dit stuk is bedoeld om richting te geven aan de behoefte van de gemeente om
regie te voeren op het sociale domein. Hierbij willen wij ook de aanbeveling geven om de door ons
voorgestelde functionaliteiten, wensen en eisen niet zonder meer over te nemen. Zie ook hoofdstuk
3. Wij bevelen aan als organisatie zelf ook het proces te doorlopen en, vanuit de beleidsvisie en de
daaruit volgende proces- en uitvoeringskeuzes, de vertaling te maken naar dit document.
15
Eigen kracht/burgerkracht
Primair zal er moeten worden ingezet op het verbeteren en versterken van de eigen kracht van
burgers (verhogen van de zelfredzaamheid 2). Burgers die zich zelf kunnen redden doen geen
beroep op de overheid. Als een burger toch ondersteuning vraagt op een bepaald leefgebied zal in
kaart worden gebracht wat de eigen kracht is, wat kan de burger zelf en wat kunnen vrienden,
buren en familie betekenen voor de burger. Eventueel wordt er gekeken naar de financiële
draagkracht van de burger of de familie.
Integraal en regie
Daarnaast zullen de problemen van de burgers of het gezin integraal worden aangepakt, daar waar
sprake is van meervoudige problematiek. Dat betekent dat er niet meer vanuit de verschillende
kokers dure suboptimale tweedelijns oplossingen voor een deelprobleem van de burger
aangeboden gaan worden. De problematiek van de burger of het gezin gaat integraal onderzocht
worden en op de ondersteuning komt regie vanuit de gemeente. Bovendien kent de regisseur de
wijk of het dorp en de beschikbare voorzieningen en probeert daar ook ad-hoc passende
oplossingen voor te zoeken.
Deze aanpak lijkt het ei van Columbus, maar dat is het niet. Het integraal aanpakken van alle
problemen op alle leefgebieden kan pas gerealiseerd worden als er een vertrouwensband is
opgebouwd tussen de burger en de ondersteuner. Voor de opbouw van het vertrouwen is tijd en
contact nodig en dus is er geen sprake van een rechtlijnig proces van intake naar
ondersteuningsplan tot nazorg.
De financiële kaders en het gewenste beleid vormen kaders voor de bedrijfsvoering. Hiermee
blijven we in control op de uitgaven en de beschikbare budgetten lopende het jaar van uitvoering.
Bovendien kunnen vanuit beleid onwenselijke en wenselijke trends worden gesignaleerd. Regie op
bedrijfsvoering is dus ook nodig.
Burgerkracht en zelfregie gecombineerd
Daar waar mogelijk zal er door de overheid een beroep gedaan worden op de burger om zelf de rol
van regisseur te voeren. Daarmee worden de concepten burgerkracht en regie gecombineerd.
Daarin kunnen door de gemeenten verschillende keuzes gemaakt worden in welke mate men de
burger zelf de regie laat voeren. Het is mogelijk om de burger zelf te laten bepalen met welke
organisaties de beschikbare informatie gedeeld mag worden.
Functionaliteiten voor de decentralisaties
Om de decentralisaties voor de gemeenten succesvol uit te kunnen voeren moeten de gemeenten
straks over een aantal functionaliteiten beschikken. Preventie zal een belangrijk doel worden voor
de gemeenten omdat daarmee een beroep op ondersteuning kan worden voorkomen. Bovendien is
de burger hier zelf ook het meeste mee gebaat. Preventie kan op twee manieren. De eerste is
2 Zelfredzaamheid is het zelf realiseren van een acceptabel niveau van functioneren op de belang-
rijke domeinen van het dagelijks leven. Indien nodig door de juiste hulp te organiseren op het
moment dat een daling van je functioneringsniveau dreigt of plaatsvindt, die je niet zelf kan
voorkomen of verhelpen (bron; Zelfredzaamheid-Matrix 2013 Handleiding, GGD Amsterdam).
V.w.b. burgerkracht: zie ook bijv. „Burgerkracht, de toekomst van het sociale werk in Neder-
land, RMO, 2011‟ en „Een beroep op de burger, SCP, 2012‟.
16
versterking van de eigen kracht, de tweede is vroegsignalering waarmee
problemen in een vroeg stadium kunnen worden opgespoord en daarmee ernstigere problemen
kunnen worden voorkomen.
Voor het realiseren van de burgerkracht beschikt de burger over een burgerportaal. Met behulp van
dit burgerportaal kan de burger waar en wanneer mogelijk zelf regie voeren, anders kan een
mantelzorger door de burger gemachtigd worden van het burgerportaal gebruik te maken (denk
hierbij bijvoorbeeld aan zelf afspraken plannen & combineren en eigen budgetbeheer voeren). De
burger kan hier zien welke ondersteuning aan de burger wordt gegeven en welke informele
ondersteuning wordt georganiseerd door de sociale omgeving van hem/haar. De burger kan hier
ook zien welke informatie over hem/haar/het gezin gedeeld wordt tussen de gemeente en de
tweedelijns ondersteuners.
Voor de regierol van de gemeente is een totaaloverzicht van alle betrokken ondersteuners
(professionele én informele ondersteuning) nodig. Voor de regierol is het tevens noodzakelijk dat
de voortgang van de hulpverlening kan worden bewaakt en er met de diverse ondersteuners
(professioneel en informeel) en de burger kan worden gecommuniceerd. Deze communicatie kan
gestructureerd (verstrekking start dienstverlening, ketenbericht) of ongestructureerd (bijv. stellen
van een vraag) plaatsvinden.
Veiligheid, beveiliging en privacy
Privacy en beveiliging zijn zeer belangrijke uitgangspunten voor een 3D-Suite. Het gaat immers om
zeer vertrouwelijke informatie over een kwetsbare groep mensen.
Zoals voor alles binnen 3D geldt ook voor bijv. inkijkfunctionaliteit door de burger (inzage in het
eigen klantdossier) dat privacy voorop moet staan. Ongeoorloofde toegang door derden tot bijv.
het klantdossier (doordat men zich voordoet als de burger zelf) moet te allen tijden voorkomen
worden. Dit vraagt niet alleen om strenge beveiliging in de zin van autorisaties op en encryptie van
het dossier, doch met name aandacht voor de identificatie/authenticatie van de burger voor de
toegang tot het systeem. DigiD (zonder token) kan al snel onvoldoende zijn. Dit geldt a fortiori
natuurlijk ook voor de regisseur, professional en/of medewerker, zeker als die in het veld toegang
moeten hebben tot nog meer informatie dan de burger zelf.
De beschreven functionaliteiten gaan grotendeels uit van de “normale” situatie, voor zover er
sprake kan zijn van normaal. In de jeugdzorg maar ook in de andere domeinen kunnen er situaties
optreden waarin de veiligheid voor kinderen en/of volwassenen in het geding komen. De
gemeentelijke overheid zal de burger dan in het dwang- en drangzorgkader benaderen. Denk aan
kindermishandeling, voogdij, reclassering, etc. Het mag duidelijk zijn dat ondersteuning in dit
kader van heel andere spelregels uitgaat dan burgerkracht en eigen regie.
Ook het delen van informatie met de burger kan in dit kader heel goed ongewenst zijn
(bijvoorbeeld: waar de kinderen uit huis zijn geplaatst). Wanneer sprake is van risico‟s voor de
veiligheid (van de burger of anderszins), is het dus mogelijk dat de regisseur bepaalt dat de burger
niet alle informatie kan zien, ook zal bijv. wellicht geen toestemming hoeven te worden gevraagd
voor het, t.b.v. verbeteren van de veiligheid, delen van informatie met externe
uitvoeringsorganisaties. Sommige gegevens dienen altijd vertrouwelijk te blijven (denk
bijvoorbeeld aan opvang op een geheim adres ihkv huiselijk geweld).
Zowel v.w.b. regievoering als voor de informatiehuishouding zal rekening moeten worden
gehouden met zowel reguliere trajecten (uitgangspunt: de burger zelf kan veel inzien en kan zelf in
17
charge zijn), als trajecten waar sprake is van dwang (waar de burger veelal
zelf ook veel minder inzage zal hebben in het eigen dossier).
2.2 Regiemodellen
Regie is een breed begrip. In de context van dit PvE is het begrip regie te relateren aan de wens
van de gemeente om zicht te hebben en controle te hebben op de burgersituatie op het moment
dat er sprake is van verminderde zelfredzaamheid. Met andere woorden: het regisseren van de
ondersteuning van individuele burgers dan wel een gezin.
We onderkennen vier modellen voor het inrichten van de regisseursrol (bron: gemeente Almere).
Deze „basis‟-modellen beschrijven in de kern de wijze waarop de gemeente regie kan inrichten. We
noemen dit basismodellen, omdat elke gemeente in zijn eigen beleid en inrichting van de
operationele werkelijkheid vrij is om keuzes te maken. Waarschijnlijk zullen er daarom nog
subvarianten van de regiemodellen ontstaan. Echter deze vier basismodellen beschrijven feitelijk
de vier uitersten van de varianten die gekozen kunnen worden.
Geen gemeentelijke regie / zelfregie Regisseur als single point of contact (“light”-
versie van regie)
Regisseur als spin in het web Regisseur als uitvoerder
Figuur 4 Vier vormen van regie
18
Elke gemeente zal zijn eigen vorm van regie kiezen. Het is niet
onwaarschijnlijk dat gemeenten hierbij zelfs een vorm kiezen waarbij meerdere regiemodellen
gehanteerd worden. Dit al naar gelang de zwaarte van het vraagstuk. Naar mate de
zelfredzaamheid van de burger afneemt zal er naar verwachting meer behoefte aan een
intensievere vorm van regie zijn.
Bijvoorbeeld: er is sprake van een burger die verminderd zelfredzaam is (en aanspraak doet op
gemeentelijke voorzieningen) maar nog wel voldoende burgerkracht heeft om met volle verstand
zelf zaken te coördineren en organiseren. In deze vorm kan de gemeente kiezen voor het
regiemodel waarbij de burger zelf regie voert. De gemeente zal enkel op afstand acteren en
monitoren in hoeverre het proces goed verloopt.
Een tweede voorbeeld heeft betrekking op de situatie dat een burger helemaal niet meer
zelfredzaam is. In een dergelijk scenario zal de gemeente volledig regie (willen) voeren. Liefst in
het model waarbij de regievoerder mandaat heeft om zelf opdrachten richting de interne en
externe organisaties te geven. Dit om strak te sturen op het juiste oplossingsarrangement. Hierbij
geldt nog steeds: burgerkracht gaat voor. Wat door de burger zelf of in zijn omgeving opgelost kan
worden heeft voorrang. Pas daarna wordt professionele hulp ingeschakeld. Hierbij is het de
doelstelling om vanuit een ondersteuningsplan gecoördineerd de hulpverlening plaats te laten
vinden.
Welk model of welke modellen een gemeente ook kiest voor een specifiek ondersteuningstraject,
regie moet ondersteund worden door de 3D-Suite. Dat wil zeggen; het moet op verschillende
momenten van het proces mogelijk zijn om inzicht te krijgen in de burger- of gezinssituatie. Zowel
vanaf het eerste gesprek, het monitoren en bijhouden van de voortgang van het plan tot het
moment dat de regisseur „de regie‟ afsluit. Hierbij is het belangrijk dat onderscheid gemaakt kan
worden in het presenteren van “dat” en “wat” informatie. In de basis zijn de gebruikte gegevens
hetzelfde maar afhankelijk van (de rechten binnen) de taak of rol worden de meer detailgegevens
(het “wat”) gepresenteerd.
Om het integrale klantbeeld in al zijn facetten te kunnen presenteren is het dus van belang dat
zowel de registraties binnen de 3D-Suite ontstaan als ook het klantbeeld uit derde bronnen
gerelateerd zijn. Slechts dan is het mogelijk zowel tijdens het (regie)proces als in de
verantwoording een samenhangend beeld in de juiste context te creëren.
Een ander aandachtspunt betreft het kunnen omgaan met (inkomende) signalen/meldingen. Deze
signalen en meldingen kunnen op elk willekeurig moment in het proces binnen komen. Ze kunnen
gestructureerd zijn met een vastgesteld doel of het kan gaan om een ongestructureerd signaal
zonder een duidelijk doel (bijvoorbeeld een wijkagent die een mogelijk drankprobleem meldt3). Het
kan ook om een status melding gaan (bijvoorbeeld “burger in behandeling genomen”) die door een
uitvoerende instantie gemeld wordt. Deze meldingen en signalen die via diverse kanalen door
diverse actoren binnen komen moeten op een juiste wijze ondergebracht en gerelateerd kunnen
worden aan (regie over) lopende ondersteuningstrajecten en aan specifieke burgers / gezinnen.
Hierbij is het van belang de bovengenoemde uitgangspunten (integraal klantbeeld en
samenhangende registraties) in acht te nemen.
3 Gemeenten zijn in de toekomst verantwoordelijk voor toeleiding en daarmee het ontvangen en
afhandelen van zorgmeldingen politie
19
In alle gevallen wordt uitgegaan van 1-gezin 1-dossier 1-plan, per gezin of
burger één integraal plan met doelen en maatregelen om de doelen te bereiken, en 1 regisseur.
20
2.3 Burgerportaal
2.3.1 Inleiding
Het gevraagde regie- en samenwerkingsplatform richt zich primair op de ondersteuning van de
professionele regisseur. Eén van de uitgangspunten en doelen van de decentralisaties op het
sociaal domein is echter versterking van de zelfredzaamheid (zie inleiding). Door zelfregie (door de
burger zelf, of door zijn sociale omgeving) te versterken kan de burger ook zelf het initiatief nemen
om zijn zelfredzaamheid te versterken.
Voor de zelfregie moet de burger dus wel over de noodzakelijke informatie beschikken. Maar ook
bij de minder zelfredzame burger is het uitgangspunt dat de deze te allen tijde de beschikking
moet hebben over veel informatie die over hem is vastgelegd op het sociale domein. Echter zal niet
alle informatie kunnen worden gedeeld: niet de wat-informatie in de backoffices van uitvoerings-
organisaties of in de notities van hulpverleners, waar de privacy van andere betrokkenen zou
worden geschaad, of wellicht ook vanwege de risico‟s op schade wanneer op de account van de
burger wordt „ingebroken‟ (lees: wachtwoord heeft deze ergens op een briefje staan).
Voor de zelfregie zal de burger niet alleen over informatie moeten kunnen beschikken, ook is het
mogelijk dat de burger onder eigen regie de mogelijkheid krijgt gebruik te maken van (zelf)intake,
een ondersteuningsplan kan maken en zelfs (beperkt) maatregelselecties kan doen. Wanneer de
burger de beschikking heeft over een Persoonsgebonden budget zal inzet en uitputting daarvan
hier tevens kunnen worden bijgehouden en bewaakt. In de kern is dit dezelfde informatie en
functionaliteit die ook de regisseur nodig heeft met een aantal specifieke autorisatie- en
beveiligingsaandachtspunten
Een burgerportaal met algemene informatie en een klantspecifiek (gepersonaliseerd) deel kan veel
vragen/ contacten overbodig maken, want de burger kan zelf de informatie vinden. Dat kan als
bijeffect hebben dat dit de gemeentelijke organisatie ontlast.
Het is overigens denkbaar dat in eerste instantie het Burgerportaal niet alle functionaliteit bevat die
op termijn nodig of gewenst is. Op korte termijn verwachten we een focus op (ten minste) de
regierol van de gemeente, op langere termijn aangevuld met meer “selfservice”-mogelijkheden.
2.3.2 Informatievoorziening en vraagverheldering
Een zelfredzame burger die enkelvoudige ondersteuning nodig heeft kan met behulp van een
burgerportaal (vaak zonder inloggen) de mogelijkheden onderzoeken voor ondersteuning door
middel van een vraagverhelderingsmodule (ook wel vraaggeleiding genoemd). Met behulp van bijv.
de Eigen Kracht Wijzer 4 kan eigen kracht en mogelijkheden voor informele ondersteuning in kaart
worden gebracht. In het doorlopen van een vraaggeleiding wordt als het ware een klantprofiel (een
beeld van de zorgbehoefte) opgebouwd.
Idealiter zou deze functionaliteit deel uit kunnen maken van het bestaande digitaal loket van de
gemeente, mits de integratie tussen 3D-Suite en digitaal loket voldoende nauw is (enkelvoudige
inrichting en beheer). Voor burgers die op basis van de analyse in de vraagverhelderingsmodule
toch nog aanspraak willen maken op een individuele voorziening kunnen de opgevoerde gegevens
bewaard worden en input zijn voor een keukentafelgesprek waarbij de regisseur „aan de
keukentafel‟ de behoeften van de burger of het hele gezin bespreekt.
4 www.eigenkrachtwijzer.nl
21
Voor burgers die geen vraagverheldering nodig hebben en precies weten
waar ze behoefte aan hebben kan een sociale kaart waarin alle lokale voorzieningen staan een
hulpmiddel zijn. De vraag is echter of deze achter een burgerportaal zou moeten. Het zou van
toegevoegde waarde zijn als op basis van de informatie in het burgerportaal ook een vertaling naar
diensten en bijvoorbeeld kosten kan worden gemaakt. De sociale kaart kan ook een algemene
voorziening zijn binnen in de website van de gemeente.
2.3.3 Inzage in eigen integraal klantbeeld (inclusief plan)
De burger heeft in beginsel toegang tot zijn gegevens/ dossier en heeft daarbij diverse
functionaliteiten tot zijn beschikking. Hierdoor kan de burger in belangrijke mate actief „meedoen‟
in zijn of haar plan en de daarbij uitgezette trajecten. Zelfregie is mogelijk.
Zodra men een beroep moet doen op ondersteuning omdat men het met de eigen netwerken niet
redt, komen ook andere aspecten van het Burgerportaal in beeld. Een burger moet dan de
mogelijkheid krijgen om informatie in te zien en te beheren, een transactie te starten, etc. Kortom,
zelf regie te voeren. Het doel is om deze functionaliteiten te bundelen in een eenduidig, digitaal
Burgerportaal met een heldere toegang. Zie figuur 5, welke een samenvatting geeft van een
mogelijk Burgerportaal.
Figuur 5 Voorbeeldopzet burgerportaal
Het is van groot belang om nauwkeurig de toegang te kunnen regelen. De burger kan vaak (doch
niet altijd) in staat worden gesteld om zelfstandig te kunnen bepalen met wie delen van informatie
uit zijn dossier gedeeld wordt. Dit kunnen professionals van de gemeente zijn,
ondersteuners/zorgverleners, wijkwerkers, familieleden of overige personen. Ook de regisseur van
de gemeente kan deze autorisatiematrix gebruiken om binnen (wettelijke) kaders (delen van)
informatie uit het dossier te delen met collega‟s of derden. We noemen dit “ad-hoc” autorisaties,
i.t.t. de autorisaties die door de functioneel beheerder worden ingericht.
22
Zo kan een ondersteuningsplan gegevens en acties omvatten van/voor het
gezin, maar ook van/voor individuele leden uit het gezin en ook anderen (familieleden of anderen
uit het sociale netwerk) kunnen een rol spelen in het plan. Zo heeft ieder, afhankelijk van zijn rol,
toegang tot delen van het plan. Ook functionaliteiten zoals het toevoegen van notities of
documenten moeten zo ingericht zijn dat de output direct in de juiste context (aan de juiste actie
op het juiste niveau) met de gewenste signalering/ notificatie wordt geplaatst. Alles ten dienst van
een soepele afhandeling en communicatie.
Niet onbelangrijk is dat ook alle uitgevoerde mutaties, acties, registraties en toegang tot het
klantdossier gelogd moet worden. Dit logboek moet –samengevat tot begrijpelijke vormen–
inzichtelijk worden gemaakt voor daartoe geautoriseerde gebruikers, zodat burger (op hoofdlijnen:
bijv. wie heeft toegang) en professional (op meer detail, afhankelijk van de rol van de gebruiker)
kunnen zien wat er gebeurd is en daarmee gewaarborgd kan worden dat er volgens de
privacyregels is gehandeld en er alleen informatie is gedeeld met partijen die daar wettelijk
toegang tot hebben (doelbinding) dan wel daarvoor toestemming hebben van de burger.
Daarnaast, in het kader van het Antwoord©-concept, hebben gemeenten veel energie gestoken in
het verbeteren van de contacten met burgers en bedrijven: het klantcontactcentrum (KCC), een
vernieuwde website incl. een burgerportaal met persoonlijke informatie („Mijn gemeente‟),
accountmanagers, etc. Dit gaat over alle domeinen, waarop de gemeente actief is heen. Vanuit het
1 loket idee verdient de aansluiting/ integratie van het burgerportaal op het sociale domein op het
algemene gemeentelijke burgerportaal aandacht.
2.3.4 Communicatie
Er zijn twee manieren om te communiceren tussen de partijen, zoals regisseur, mantelzorgers en
tweedelijns professional. De gestructureerde wijze van communiceren, waarin een bericht een
vaste vorm en betekenis heeft, en er ook volgens een vast format berichten terug komen. Deze
zgn. ketenberichten (zie ook par. 2.4.5) staat ook de regisseur ter beschikking ter aansturing van
de tweedelijnszorgverlening.
Als er sprake is van zelfregie door de burger zelf of een mantelzorger is deze communicatie-
functionaliteit ook in het burgerportaal denkbaar (waar keuzes van de burger „onderwater‟
resulteren in ketenberichten). Dit geeft ook nieuwe mogelijkheden voor een tussenvorm van
Persoonsgebonden budget (PGB). De burger krijgt een budget, te besteden bij partners waarmee
de gemeente een contract heeft.
De tweede manier van communiceren is via de (v.w.b. berichtinhoud) ongestructureerde berichten.
Algemene vragen van de burger aan regisseur of aan tweedelijnsondersteuners, terugkoppeling
aan de regisseur over de ondersteuning van tweedelijnszorg of een van hen op de hoogte brengen
van de ontwikkelingen. Ook kan hier de communicatie plaatsvinden die nodig is voor de
afstemming tussen professionele en informele ondersteuning. Dergelijke communicatie kan
bestaan uit notities via het Burgerportaal, brieven, maar ook e-mails, chats, etc. Bij voorkeur
gebeurt de communicatie zoveel mogelijk via de 3D-Suite z.d.d. „wat‟-informatie niet wordt
gedeeld, en wordt de burger, mantelzorger of de professional waarbij de e-mail of sms op de
hoogte gesteld van het feit dat er berichten klaar staan.
Een belangrijk aspect bij ook berichtgeving is beveiliging, immers het betreft hier informatie over
„handelen‟ door betrokkenen en eventuele feedback daarop.
23
Multichanneling
De hierboven beschreven functionaliteit gaat uit van een digitaal burgerportaal als een van de
beschikbare kanalen voor de burger. Echter, de burger heeft de vrijheid zijn voorkeurskanaal te
kiezen. Het idee is dat een bericht met minimale handeling direct op de juiste plaats, bij de juiste
persoon (of team) onder de aandacht wordt gebracht en dat verdere follow-up kan worden
gegeven.
De diversiteit aan kanalen is groot en maakt multichannelingmanagement noodzakelijk. Balie, post,
telefoon zijn veelal goed ingebed. Dat is voor en internet (e-formulieren) en e-mails een stuk
minder, evenals voor andere nieuwe kanalen: chat, skype, video-overleg, social media, etc.
verdienen meer aandacht. Uitgewerkt zal moeten worden hoe deze kanalen aansluiten bij de
traditionele kanalen en hoe het geheel aan oplossingen wordt versterkt. Ook hier is beveiliging een
belangrijk aandachtspunt.
De 3D-Suite zal zoveel mogelijk kanalen moeten kunnen ondersteunen, doch de mate waarin de
informatie geautomatiseerd in de 3D-Suite wordt opgenomen kan verschillen. Sommige
communicatie zoals berichten uit social media kunnen bijvoorbeeld ook gekopieerd/geplakt worden
door de regisseur.
24
2.4 Regie
Voor een effectieve aanpak is dus een goede samenwerking tussen instellingen en hulpverleners
van belang, waarbij hulpverleners elkaar informeren, mogelijke risico‟s signaleren en hulpvragen
doorgeleiden naar de juiste hulpverlener. Er is sprake van één plan per gezin (of individuele
burger) en één hulpverlener is verantwoordelijk voor het gezin: de regisseur. De rol van de
regisseur is:
- contactpersoon voor het gezin / burger
- probleemverkenning en opstellen ondersteuningsplan (1-plan), samen met gezin:
o inventariseren van gezinssituatie, problematiek en mogelijke / gewenste ondersteuning
(integrale intake)
o zorgen voor een laagdrempelig “gekanteld” ondersteuningsarrangement. Dat wil zeggen
het liefst buiten de sfeer van betaalde voorzieningen.
o opstellen van het ondersteuningsplan, bewaken van de uitvoering van het ondersteu-
ningsplan
- organiseren en bevorderen van afstemming en samenwerking tussen verschillende hulpverle-
ners
- overzicht houden over welke hulpverleners bij het gezin betrokken zijn en welke hulp zij leve-
ren; organiseren dat op het juiste moment de juiste hulpverlening beschikbaar is
- organiseren van escalatie
- rekening houden met en bewaken van budgetten (persoonsgebonden budget van de betreffende
burger, maar ook andere budgetten)
- kwaliteitsbewaker (tijdens het traject, maar zeker aan het eind bij de evaluatie)
Hiermee is de rol van de regisseur aanvullend op die van de andere hulpverleners. De regisseur
kan puur vanwege de regie bij een gezin betrokken zijn. Maar het kan ook zijn dat één van de bij
het gezin betrokken hulpverleners de rol van regisseur op zich neemt (zie de eerder benoemde
vormen van regie). De regisseur kan als zodanig ook een medewerker van buiten de gemeente
zijn, incl. de burger zelf.
Vanwege de breedte van het sociale domein kan een gemeente te maken hebben met – en moet
regie voeren over - vele tientallen uitvoeringsorganisaties en nog veel meer individuele
hulpverleners. De regisseur houdt het overzicht over de verschillende hulpverleners en stemt waar
nodig met hen en met het gezin af. Hiervoor is het van belang dat de regisseur zicht heeft op zowel
de situatie van het gezin als op welke hulpverleners zijn betrokken en welke hulp zij leveren.
Binnen de regiefunctie is er sprake van drie vormen van informatieuitwisseling. Ten eerste is er
sprake van inkomende en uitgaande signalen en meldingen, ten tweede van (ongestructureerde)
sociale communicatie en interactie en ten derde van (gestructureerde) ketenberichten.
2.4.1 Integraal klantbeeld (incl. Inkijk)
In principe zal de burger / het gezin of de omgeving van de burger waar mogelijk zelf de regie
moeten voeren over de uitvoering van dit plan. In de situatie dat de burger zelf de regie niet kan
voeren en er ook in de sociale omgeving (netwerk) niemand beschikbaar is die de regierol kan
uitvoeren zal een professionele kracht de regierol overnemen. Het is deze regierol waarnaar we
verwijzen als we in dit stuk spreken over de regisseur. Het is de rol van de regisseur om samen
met de burger de keuzes te maken welke ondersteuning er wordt ingezet om de burger weer
zelfredzaam te maken. Vervolgens moet de regisseur erop toezien dat de ondersteuning die rond
de burger georganiseerd is op de afgesproken wijze verloopt. De ondersteuning van de burger kan
25
bestaan uit informele ondersteuning (ondersteuning van buren, vrienden en
familie), en professionele tweedelijns ondersteuning.
Voor het uitvoeren van de regierol zal de medewerker in één oogopslag moeten kunnen zien welke
ondersteuning er voor burger is georganiseerd en wat de status is van die ondersteuning. In de
kern is dat dezelfde informatie die de burger kan inzien door middel van het burgerportaal (doch
kan meer omvatten). Dat noemen we het integrale klantbeeld en dat moet in iedere fase van het
ondersteuningsproces beschikbaar zijn. Zelfs voor het eerste gesprek moet basisinformatie
beschikbaar zijn omdat het ook mogelijk is dat de burger zelf via andere kanalen enkelvoudige
ondersteuning heeft gekregen. Het is de keuze van de regisseur of het klantbeeld eerst wel of niet
wordt geraadpleegd voor het eerste gesprek.
De vastlegging van de informele ondersteuning zal in veel gevallen door de regisseur zelf gedaan
worden als uitwerking van de ondersteuning in overleg met de burger. De informatie over
bestaande tweedelijnszorg zal in de ideale situatie real time worden opgehaald uit de
informatiesystemen van de organisaties die de tweedelijnszorg uitvoeren (zoals men in de werk- en
inkomenketen de informatie uit de keten raadpleegt). De reden hiervoor is dat op deze wijze er
maar één realiteit is en de regisseur over de meest actuele informatie beschikt. Daarnaast is het de
meest efficiënte oplossing omdat de uitvoerder van de tweedelijnszorg maar op één plek de
informatie hoeft bij te houden en geen dubbele boekhouding hoeft te voeren. In de fasering van de
invoering van het 3D informatiesysteem kan eventueel eerst een webportaal beschikbaar zijn om
de handmatige bijwerking van deze informatie door de tweedelijnszorg te faciliteren. Dit omdat het
niet realistisch is te verwachten dat alle organisaties die tweedelijnszorg aanbieden al dan in staat
zijn deze informatie via koppelingen tussen systemen real time te realiseren. Enkele belangrijke
landelijke bronnen zullen wel direct ontsloten moeten worden.
Het totaaloverzicht van de ondersteuning is de kern van het integraal klantbeeld. Daarmee is het
integraal klantbeeld nog niet compleet. Om de regisseur in één oogopslag een overzicht te geven
van de stand van zaken is meer nodig. Te denken valt aan een samenvatting van de laatste meting
van de Zelfredzaamheidsmatrix, weergave van de laatste entries van het contactjournaal, een
overzicht van de eigen aantekeningen over de burger, een financieel overzicht van de gemaakte
kosten tot zover, etc. Wat het ideale klantbeeld zal zijn hangt af van de voorkeuren van de
gebruiker en de gemaakte beleids- en proceskeuzes van de betreffende gemeente. De kern zal
echter het totaaloverzicht van de informele en de eerste en tweedelijnszorg blijven.
Inkijk gaat in het algemeen over identificerende gegevens en 'buitenkant-informatie' (dus het “dat”
i.p.v. het “wat”), zoals o.a.:
- NAW over de betrokken persoon en het gezin
- Werk, inkomens- en uitkeringsverhoudingen
- Ontvangen ondersteuning, waaronder ook schulden en schuldhulpverlening
- Onderwijs en opleidingsgegevens, incl. leerplicht / RMC
- Evt. justitiële gegevens
Deze gegevens worden zoveel mogelijk uit bestaande systemen gehaald. Zo is in de Suwiketen5 de
GeVS (Gezamenlijke elektronische Voorzieningen Suwi) ontwikkeld Via dit knooppunt is informatie
uit verschillende bronnen (zoals GBA, UWV, DUO, RDW, Kadaster) ontsloten en wordt deze
informatie beschikbaar gesteld aan de Suwi-ketenpartijen (SVB, UWV en gemeenten). Met behulp
5 Suwi: de Wet structuur uitvoering werk en inkomen
26
van deze gegevens wordt het DKD (het DigitaalKlantDossier) gevormd en
via een webapplicatie getoond. Het DKD zelf is geen bron maar een virtueel dossier dat uit de
aangesloten bronnen wordt opgebouwd. Geautoriseerde afnemers kunnen ook rechtstreeks
aansluiten op de GeVS (via de component Suwinet-Inlezen) om de brongegevens zelf in „eigen‟
applicatie te verwerken.
In dit document spreken we verder van de GeVS, de officiële en wettelijke benaming voor dit
knooppunt. Zie bijlage 12.2 voor een kort overzicht van de informatie die via de GeVS inzichtelijk
is.
Informatie wordt tevens ontsloten uit de justitiële keten, uit de basisadministraties, en uit
verschillende backofficesystemen (zoals de onderwijsadministratie) van gemeente en
uitvoeringsorganisaties. Er ligt een koppeling met de VIR (VerwijsIndex Risicojongeren 6).
Afhankelijk van de situatie en de rechten moet het mogelijk zijn voor de regisseur om 'door te
prikken' naar meer achterliggende gegevens (het “wat”). In alle gevallen is van belang dat de
inzage transparant is (de betrokken burger kan zien wie welke gegevens heeft ingezien), dat de
inzage aan een doel is gerelateerd en dat een zorgvuldige afweging is gemaakt of de gevraagde
gegevens proportioneel zijn voor het doel (doelbinding). Degene die de inzage doet moet hierover
verantwoording kunnen afleggen.
De inzage is in beginsel alleen beschikbaar voor de regisseur en het gebruik is gebonden aan de
ondersteuning van multiprobleemgezinnen of aan een nader onderzoek op basis van een
(vroeg)signaal. Het gezin en de betrokken personen zelf moeten hun eigen gegevens ook kunnen
inzien, voor zover deze daar voor is geautoriseerd (bijv. niet-vertrouwelijke notities van een
individuele behandelaar, en ook niet wanneer dat vanwege veiligheid de informatie niet kan worden
gedeeld).
2.4.2 Het ondersteuningsplan (1-plan)
Het ondersteuningsplan (zie 1-gezin 1-plan) is het plan van aanpak waarin de afspraken tussen het
gezin en de hulpverleners is vastgelegd. Het is daarnaast de basis waarop de bewaking van de
voortgang van de afgesproken hulp plaatsvindt. Het plan bevat afspraken over de activiteiten die
de burger of het gezin zelf kan/wil/moet doen met de eigen sociale omgeving (in het kader van
versterking zelfredzaamheid, eigen verantwoordelijkheid en eigen kracht & samenkracht) en
afspraken over activiteiten die door professionele hulpverleners worden geleverd.
Het plan kan acties/maatregelen bevatten voor bijvoorbeeld het gehele gezin, maar ook voor
individuele leden van dat gezin. Gegevens, afspraken en documenten moeten aan het juiste
niveau/ onderdeel gekoppeld kunnen worden.
Het plan is in beginsel toegankelijk voor het gezin, de regisseur en - voor zover het hun eigen
dienstverlening betreft - de betrokken hulpverleners. Informatie in eigen dossiers en systemen van
hulpverleners is niet toegankelijk voor gezin en regisseur (hooguit „dat‟, niet „wat‟).
6 VIR: zie ook www.rijksoverheid.nl/onderwerpen/jeugdzorg/vraag-en-antwoord/wat-is-de-
verwijsindex-risicojongeren-vir.html en
http://wetten.overheid.nl/BWBR0027338/geldigheidsdatum_01-05-2013 (de Wet VIR); VIR
werkt via een melding-respons systematiek
27
Afhankelijk van de hoeveelheid en type ondersteuning en afhankelijk van of
er bijv. veiligheid in het geding is, kan de burger zelf (in overleg met de regisseur) de lijst
personen/organisaties met toegang stellen, ontzeggen en inzien. In voorkomende gevallen (bijv.
dwang) zal de regisseur de toegang zonder overleg bepalen.
2.4.3 Inkomende/uitgaande signalen en meldingen
Signalen en meldingen hebben betrekking op informatieuitwisseling omtrent de status van een
burger. Dit is de informatiestroom waar informatie over een burger gedeeld wordt die aanleiding
kan zijn om een burger in regie te nemen of een voorziening aan te bieden.
In situaties waar het misloopt in gezinnen blijkt vaak dat er al langer signalen waren, die daarop
wezen of waaruit de verslechtering van de situatie te voorspellen was. Signalen kunnen ontstaan
vanuit:
- Het gezin of burger zelf, of de omgeving van de burger/ het gezin (onderliggende problematiek,
buren, familie, een voetbaltrainer, overlast gedrag etc.)
- Professionele hulpverleners, incl. eigen waarneming van de regisseur/ wijkwerker
- Objectieve bronnen (zoals databases). Bijvoorbeeld, een signaal dat de maandhuur bij herhaling
niet betaald is bij de woningbouwcorporatie, een signaal dat er bovenmatig wordt gespijbeld,
stopzetten uitkering
Het ontvangen en op de juiste waarde schatten van (vroeg)signalen is belangrijk om te voorkomen
dat gezinnen zwaardere en/of langdurige vormen van ondersteuning nodig hebben of zelfs in een
multi probleemsituatie terecht komen. Vroegtijdig signaleren kan ook voorkomen dat de situatie in
een multiprobleemgezin verder escaleert.
In de huidige uitvoeringssituatie is (vroeg)signalering meestal georganiseerd via de verschillende
losse terreinen. De samenwerking / afstemming tussen de terreinen is beperkt. Zo is rondom
Algemeen Meldpunt Kindermishandeling en Steunpunten Huiselijk Geweld de signalering van
kindermishandeling en huiselijk geweld georganiseerd, in de Verwijsindex Risicojongeren (VIR) kan
jeugdproblematiek gemeld worden, en via Suwinet kunnen hulpverleners in de sector werk &
inkomen elkaar informeren. Terwijl er geregeld sprake is van overlap in gezinnen die binnen multi-
problematiek bekend zijn.
Een signaal kan meer of minder informatie bevatten, veelal met name „dat‟-informatie. Een
(vroeg)signaal bevat minimaal de volgende gegevens:
- Identificatie van de betreffende persoon, gezin
- Contactgegevens van de melder
- Relatie tussen melder en betrokken persoon / gezin
- De situatie die aanleiding gaf tot de melding
- De inhoud van de signalering (het “dat”)
In het verlengde van de definitie van multiprobleemgezinnen is het nodig dat signalen uit
verschillende probleemgebieden kunnen worden gecombineerd en geverifieerd. Daarnaast is het
van belang dat de signalen op één plek samen komen (bij voorkeur bij de regisseur).
Signalen kunnen op meerdere manieren (via verschillende kanalen) binnenkomen én uitgaan,
bijvoorbeeld via de mail, telefoon, via een geautomatiseerd systeem, of in een gesprek. In verband
28
met de transparantie is wel van belang dat elk signaal (goed beveiligd)
wordt vastgelegd. Niet alle (vroeg)signalen zullen leiden tot een melding, de afweging hierbij moet
kunnen worden vastgelegd.
Signalen moeten na enige tijd (een nader door gemeente te bepalen periode, aansluitend op
wettelijke bewaartermijn) uit het actieve systeem verdwijnen: 'het recht om vergeten te worden'.
Meldingen zijn alleen in te zien door de melder, de regisseur, en (in beginsel) het betrokken gezin /
persoon. Er is inzagerecht voor het gezin, maar geen wijzigingsrecht bij bepaalde (nader te
bepalen) signalen. Dit om schaduwregistraties bij professionals te voorkomen.
Vroegsignalering, en de daarbij behorende gegevensuitwisseling en aanpak, is ter voorkoming van
(escaleren van ) multiprobleemsituaties, en zal daarom juist ook van toepassing zijn voor gezinnen
waar nog geen sprake is van zware vormen van hulp en ondersteuning. Dit stelt eisen aan de
zorgvuldigheid, en vraagt een afweging wanneer wel of niet te melden. Vroegsignalering kan ook
leiden tot eenvoudige en enkelvoudige acties ter voorkoming van erger (bijv. begeleiding om
ontslag te voorkomen).
De Verwijsindex Jongeren (VIR) is een voorbeeld van het mechanisme van een signalering (incl.
register) en hoe het kan en wat er geregeld moet worden, al zullen de signaleringen van een VIR
vanwege de aard van de berichten vaker resulteren in dwang dan andersoortige signaleringen.
Het is mogelijk dat er meer landelijke / centrale registers komen. Immers, burgers zijn niet
honkvast en moeten in beeld blijven. En een gezin (of huishouden) kan zich over meerdere
gemeenten uitstrekken. Bijv. juist er sprake is van verhuizingen, is het van belang die informatie
goed en langer te bewaren en in te laten zien voor andere professionals.
In (ook) een landelijk signalenregister wordt dan bijgehouden welk signaal tot welke melding heeft
geleid. Het signalenregister krijgt hiermee een dubbelfunctie (signalen-/meldingenregister). Als en
wanneer sprake zou zijn van landelijke signalen-/meldingenregisters zal een 3D-Suite hierop
moeten aansluiten.
2.4.4 Ongestructureerde communicatie en interactie
Daarnaast zal er ook informatieuitwisseling plaatsvinden die betrekking heeft op interactie tussen
burger en hulpverleners. Hierbij valt te denken aan input van de burger op het ondersteuningsplan
(1-plan), digitale communicatie (gesprekken), notities, e-mails. Brieven, etc. tussen burger en
hulpverlener.
Veel contacten tussen hulpverleners, gezin en regisseur zijn free-format en dus niet in een (v.w.b.
berichtinhoud) gestructureerd format te vangen en zullen dus niet via gestandaardiseerde digitale
berichten tussen informatiesystemen plaatsvinden. Zie ook par. 2.4.3. Informatieuitwisseling
bestaat uit 1. inkomende en uitgaande signalen en meldingen, 2. (ongestructureerde) sociale
communicatie en interactie en 3. (gestructureerde) ketenberichten.
Het is –o.a. vanwege transparantie– wel wenselijk dat bijgehouden wordt welke gegevens en
documenten zijn uitgewisseld, door naast informatieuitwisseling binnen de 3D-Suite (bijv. een
notitieveld of een discussieplatform) ook uitwisselingen via mail en/of chat te laten in de 3D-Suite
op te slaan (bijv. in de context van een cliëntdossier). Omdat de inhoud vaak gevoelige
persoonsgegevens kan bevatten, is het wenselijk dat deze mail/chat in een aparte beveiligde
omgeving kan plaatsvinden, zo mogelijk niet via het reguliere internet. Communicatie vindt zoveel
29
mogelijk plaats via versleutelde en goed beveiligde verbindingen. Via
onversleutelde kanalen zou hooguit een verwijzing kunnen worden gegeven naar de informatie die
(na authenticatie) in de 3D-Suite beschikbaar is.
2.4.5 Gestructureerde ketenberichten
De regisseur zal gespecialiseerde ondersteuning niet zelf gaan leveren, daarvoor zal er in overleg
met de burger een gespecialiseerde tweedelijnshulpverlener worden ingeschakeld. Opdrachten aan
ketenpartners worden–bijv. als deelzaak- in de 3D Suite zelf geadministreerd incl. termijnen, zodat
de regisseur de follow-up kan volgen en bewaken.
Communicatie met externe tweedelijnshulpverleners kan –wanneer en voor zover hier standaarden
voor bestaan of worden ontwikkeld- bestaan uit een standaard set (gestructureerde, digitale)
berichten waarmee opdracht tot zorgverlening kan worden gestart7 en terugkoppeling over de
voortgang (status, resultaat en financieel) kan worden uitgewisseld en ook in de geautomatiseerde
systemen kunnen worden verwerkt.
Hiermee wordt dan het handmatig verwerken van dit soort berichten voorkomen, dat bespaart
fouten. Bovendien laat een geautomatiseerd bericht zijn spoor na in het informatiesysteem van de
regisseur en kan de regisseur ook zien wat de opvolging van het bericht is geweest.
Als voorbeeld van het principe van ketenberichten zou het AZR (Awbz-brede zorgregistratie)
kunnen dienen, niet om het AZR te kopiëren maar meer vanwege het idee en de uitwerking
daarvan.
7 Een VTO (verzoek tot onderzoek aan de Raad voor de Kinderbescherming) is een voorbeeld van
gestructureerd bericht aan tweedelijns partij.
30
2.5 Regie op regie
Onder regie op de regie, en „sturing‟ daarbij verstaan we hier het sturen op
1) doeltreffendheid
a) effectiviteit van handelen (best practices/ wijkaanpak, doelgroepaanpak) en
b) resultaat (gemaakte afspraken met externe partners, maar ook op de beweging van
intensieve naar eenvoudige ondersteuning naar zelf doen ) en
2) efficiency (budgetten/ realisatie).
Het betreft hier dus niet het regisseren van de ondersteuning van individuele burgers dan wel een
gezin. In onderstaand overzicht staat de informatie die in de verschillende „regelkringen‟ wordt
geregistreerd en die nodig is om regie op regie te kunnen voeren:
Figuur 6 regelkringen
Bij regie op regie zijn er verschillende „stakeholders‟ die (sturings)informatie nodig hebben om te
kunnen bijsturen:
- Wijkmanager krijgt van gemeente (beleidsmedewerker, directie en bestuurder) beleidsmatige
en budgettaire kaders en formatie om sociale index naar een bepaald niveau te brengen en bur-
gers hoger op zelfredzaamheidsmatrix te brengen. N.B. Deze kaders worden onderscheiden
naast het primaire proces waar regisseur en wijkmanager in werken
Caseload, € (incl kos-
ten van regie), uren,
%klantcontact, resul-
taat Klantbeeld
Opdracht+ budget
€
Resultaat, €, wij-
kindex
Inkoopvoorwaarden, €,
doorlooptijd, wachttijd/-
lijst, kwaliteit, resultaat
Resultaat
Resultaten
Doelgroepen
Kwaliteit zorg
Efficiency
31
- Externe 2e lijns professionals en gemeentelijke backoffice hebben con-
tractuele verplichtingen voor het leveren van collectieve of individuele voorzieningen. In een
contract/subsidiebeschikking staan de afspraken rondom diensten die gemeten moeten worden
(input, throughput, output, outcome). Externe 2e lijns professionals zullen moeten werken op
basis van een eenduidig format waardoor ze effectief de gegevens kunnen teruggeven aan de
gemeenten waarvoor ze werken (via een gemeenschappelijke voorziening). Daarnaast zijn de
gegevens onderling vergelijkbaar.
Al ten tijde van inkoop zal door de gemeente aandacht moeten worden besteed aan afspraken over
(1) financiële prikkels gericht op betere en eerdere hulp en ondersteuning, (2) outcome-gerichte
informatieuitwisseling van gegevens.
In bovenstaand figuur 6 zijn de relevante stakeholders („zij die sturen‟) centraal gezet. Voor de 3D-
suite is het belangrijk dat de juiste informatie voorhanden is om tijdig te kunnen ingrijpen bij
overschrijdingen, onwenselijke situaties en om nieuwe kaders te kunnen meegeven. Signaleringen,
handreikingen bij de intake, overzichten, etc. geven daarbij (financiële) grip.
Het kunnen sturen op de beschreven „regelkringen‟ vindt plaats op basis van informatie die
beschikbaar is of ontstaat in de processen/ bij de uitvoering. De voor regie op regie benodigde
gegevens worden zoveel mogelijk onttrokken aan het gestructureerde berichtenverkeer. En de
gegevens die „vanzelf‟ ontstaan vanuit de uitvoering. Overige stuurinformatie zal zoveel mogelijk
beperkt moet worden tot het hoogst noodzakelijke, omdat iedere informatiebehoefte die niet
automatisch ontstaat, extra registratieve handelingen vraagt van de regisseur of anderen.
Deze informatie zal ook in het kader van forecasting nodig kunnen zijn: wat komt er op korte /
middellange / lange termijn in geld en in workload op de regisseur en de professional af?
Het verkrijgen van de stuurinformatie zou ook moeten plaatsvinden voor de enkelvoudige
processen waar (financiële) gegevens in uitvoeringsorganisatie-eigen bronsystemen zullen worden
vastgelegd. Een informatieplatform zal deze (financiële) gegevens uit de bronsystemen moeten
kunnen ontsluiten c.q. kunnen ontvangen. Op termijn kan het uitzetten van opdrachten en
budgetten naar een gemeentelijke backoffice/ externe tweedelijns conform een
producten/dienstencatalogus. Dat is per 1-1-2015 wellicht niet haalbaar, doch later misschien wel.
32
3 Uitgangspunten PvE
3.1 Varianten en fasering
Gemeenten kunnen verschillende keuzes maken voor het niveau/de rol van de regiefunctie en
zullen vanaf 2014 hier invulling aan geven (in productie januari 2015?) Feitelijk gebruik en
inrichting van de informatievoorziening kan nu en in de toekomst per gemeente significant
verschillen. Een en ander is v.w.b. de prioritering, timing en fasering ook afhankelijk van het
zorgakkoord en andere landelijke beslissingen. Maar zelfs als het niet ondenkbaar is dat bepaalde
domeinen of taken uiteindelijk niet overgaan naar gemeentes, zal brede regie nodig zijn.
Individuele gemeenten kunnen onder meer verschillende keuzes maken over de vorm van de
ondersteuning aan de burger en de mate van uitbesteding aan / controle van
uitvoeringsorganisaties. Voor veel gemeenten zal concreet beleid dienaangaande nog vorm moeten
krijgen. Daarom wordt in dit PvE rekening gehouden met breder gebruik van de
informatievoorziening door andere organisaties dan gemeenten. Ook bij aanwezigheid van (of
aanschaf van) eenzelfde groep applicaties zal nog de feitelijke implementatie per gemeente kunnen
verschillen.
Idealiter wordt zoveel mogelijk de configuratie van het systeem / de systemen op basis van „zero
coding‟ gedaan, z.d.d. er geen kennis van programmeren nodig is. Idealiter zou een paar uur
cursus moeten voldoen voor de functioneel beheerders. Daarbij zouden sjablonen en
configuratiebestanden idealiter ook gedeeld kunnen worden en daarna aangepast door andere
gemeenten.
Tevens gaan we uit van een gefaseerde invoering van de informatievoorziening die de regisseur als
professional zoveel mogelijk ondersteunt in alle facetten van zijn regierol. Bij aanvang kan een
eenvoudig systeem overzicht bieden aan betrokkenen, nog zonder de meeste zware koppelingen
(wel: GeVS en VIR), beslissingsondersteuning, etc. De regie op de ondersteuning vindt eerst
primair handmatig plaats, automatisering van bepaalde taken kan later. We gaan initieel hierbij
dus uit van de taakvolwassenheid van de gebruikers – en van bestaande systemen los van de 3D-
Suite. Het groeipad v.w.b. de informatievoorziening zit hem dan in het modulair toevoegen van
verder gespecialiseerde functionaliteit, zoals specifieke modules, koppelingen met andere systemen
zoals het koppelpunt GeVS, etc.
Op korte termijn is het belangrijkste: de realisatie van 1 integraal klantbeeld en 1 plan. Bewaking
van de ondersteuning per burger/gezin gebeurt ten minste op hoofdlijnen. Hierbij is dan het
uitgangspunt dat individuele zorgprofessionals eigen (backoffice) systemen gebruiken. En dat ook
rapportages (uren, geld) wellicht nog elders worden verzorgd. Gemeenten krijgen forse budgetten
te beheren in het sociale domein. Om dit beheersbaar te houden zal er goede
verantwoordingsinformatie beschikbaar moeten zijn: horizontaal richting gemeenteraad en
samenleving en verticaal richting het Rijk. Deze ontwikkeling moet meegenomen worden in de
informatievoorziening. Op langere termijn zal de scope zoals die ondersteund zou moeten door de
informatievoorziening derhalve breder zijn. Dit betreft – naast „verdieping‟ van de eerdergenoemde
functionaliteiten – vooral ook ondersteuning voor secundaire functies. Financiële verantwoording
zal worden gevraagd en gegeven.
Fasering kan per gemeente verschillen. De ene gemeente wil bijvoorbeeld een uitgebreid
Burgerportaal „nu‟ en zal de burger zelf nauw betrokken zijn bij de mate waarin de gegevens
worden gedeeld met uitvoeringsorganisaties, in een andere gemeente heeft dit minder prioriteit
33
omdat er minder zelfregie wordt verwacht en / of er meer sprake is van
dwang. En waar de ene gemeente veel taken zoveel mogelijk per bijv. wijk zal uitbesteden, zal de
andere dit zelf doen of per taak uitbesteden zodat de vorm en detaillering van financiële
verantwoording significant kan verschillen. De mogelijkheden en wensen v.w.b. koppelingen zullen
ook verschillen per gemeente, zowel vanwege de beschikbaarheid van koppelvlakken als vanwege
functionele behoeften.
Bepaalde delen van de eisen en wensen zullen dus aan- of uit kunnen worden gezet voor een
individuele gemeente (of groep gemeenten).
Standaardfunctionaliteit
Daarnaast is het denkbaar dat niet alle functionaliteit mogelijk (en noodzakelijk!) is tijdens de
selectiefase van een pakket. Uitgangspunt is vooralsnog dat beantwoording van de eisen en
wensen plaatsvindt o.b.v. de functionaliteiten van de 3D-suite die direct, als
standaardfunctionaliteit („off-the-shelf‟), beschikbaar zijn en als zodanig ook in een Proof of
Concept (PoC) verifieerbaar zijn. Uitzondering hierop zijn de koppelingen; wanneer één of meer
koppelingen (nog) niet als „standaardsoftware‟ worden aangeboden, worden deze als zogeheten
generiek maatwerk (vgl. „nog niet ontwikkelde standaardfunctionaliteit‟) beschouwd.
3.2 Plusfunctionaliteiten
Het pallet aan mogelijke functionaliteiten t.b.v. ondersteuning van de gemeentelijke regievoerders
en van de uitvoerders van ondersteuning is breed. Op korte of middellange termijn zullen niet alle
functionaliteiten in een suite mogelijk zijn. Daarom wordt rekening gehouden met op korte en
middellange termijn ontbrekende functionaliteiten. Ook kunnen bepaalde, op het moment van de
aanbesteding nog niet (volledig) bekende specificaties later worden vervolmaakt als onderhoud van
de 3D-suite. Dit geldt bijvoorbeeld voor nog onbekende wetswijzigingen die gespecialiseerde
functionaliteit vereisen.
Al naar gelang het moment waarop de (eventuele) aanbesteding voor een specifieke gemeente of
groep gemeenten plaatsvindt, kan de inschatting daarom zijn dat het uitgangspunt van
standaardfunctionaliteit („off-the-shelf‟) nog niet (volledig) van toepassing is. In dat geval moet,
wanneer het bestek (aanbestedingsdocument incl. gedetailleerde opdrachtbeschrijving, procedurele
/ juridische aspecten, PvE, etc.) voor de aanbesteding wordt gemaakt, het PvE dienovereenkomstig
worden aangepast. In dit PvE is vooralsnog echter uitgegaan van beantwoording o.b.v.
standaardfunctionaliteit die wordt ingericht.
Wanneer later aanvullende functionaliteiten nodig zijn die nu nog niet „out of the box‟ leverbaar
zijn, kan de gemeente er voor kiezen dit te definiëren als plusfunctionaliteit. Plusfunctionaliteiten
zijn functionaliteit van de 3D-suite welke niet direct als standaardfunctionaliteit (dus niet out-of-
the-box) beschikbaar hoeven te zijn maar wel uiterlijk vanaf een bepaald moment na de acceptatie
(zo is een „plateauplanning‟ mogelijk: bij Acceptatie X, een jaar later X+Y, twee jaar later X+Y+Z).
Van belang is dan wel dat de gekozen leverancier (Contractant) ook daadwerkelijk levert. Als een
plusfunctionaliteit niet uiterlijk op dat moment als standaardfunctionaliteit beschikbaar is, wordt de
Contractant een boete opgelegd in de vorm van een korting op [[#afhankelijk van prijsmodellen
etc.#]]. Deze korting komt te vervallen vanaf het eerstvolgende jaar na het jaar waarin deze
plusfunctionaliteit als standaardfunctionaliteit beschikbaar komt.
34
Plusfunctionaliteit 1
[##Als en waar een gemeente dit wil: voorstel van functionaliteit, implementatie, timing én van
boetes bij niet nakomen #]
[Plusfunctionaliteit 2]
3.3 Opties
Opties zijn functionaliteiten waarvan het onzeker is of - en zo ja wanneer – Gemeente deze zal
afnemen. Daarom behoudt Gemeente zich het recht voor om één of meer van deze opties op enig
moment af te nemen van de Contractant (zij is daartoe echter niet verplicht). In dat geval wordt
gebruikgemaakt van een nadere offerteaanvraag (zie ###). Het betreft onderstaande
functionaliteiten.
Als een Inschrijver in zijn Offerte één of meer opties als standaardfunctionaliteit (out-of-the-box,
dus als onderdeel van (de prijsstelling van) de 3D-Suite en verifieerbaar in de PoC) aanbiedt, zal
deze daar een hogere beoordeling voor krijgen in termen van kwaliteitsscore
([beoordelingsmethoden niet opgenomen in dit PvE, dienen wel in een bestek te zijn opgenomen])
dan een Inschrijver waarbij dat niet het geval is. Ongeacht of een optie als standaardfunctionaliteit
(out-of-the-box, dus verifieerbaar in de PoC) of eventueel op een later moment (na een nadere
offerteaanvraag van Gemeente) wordt geleverd, committeert de Inschrijver zich eraan om de optie
voor Gemeente in de 3D-Suite op te nemen (vgl. Onderhoud, zie par. 10.4) zodat e.e.a. tevens
blijvend ondersteund wordt in alle volgende Nieuwe en Verbeterde Versies.
Indien een Inschrijver één of meer opties niet als standaardfunctionaliteit (out-of-the-box) levert,
vindt er t.z.t. bij de oplevering een acceptatietest plaats om te bepalen of de optie voldoet aan de
betreffende specificaties van de nadere offerte(aanvraag). Indien een Inschrijver één of meer
opties als standaardfunctionaliteit (dus out-of-the-box) levert, vindt acceptatie plaats bij de
Acceptatie. De implementatie van een optie is onderdeel van de Initiële Implementatie (na
definitieve gunning van de opdracht) resp. Vervolgimplementatie (later bij afname van de optie, zie
###) indien deze als standaardfunctionaliteit (out-of-the-box) wordt geleverd en onderdeel van de
Ondersteuning (zie ###) als deze later geleverd wordt.
[Optie 1]
Het is denkbaar dat de gemeente de functionaliteit als plug-in op een bestaand zaaksysteem zou
willen uitvragen.
[Optie 2]
3.4 Overige uitgangspunten
Webcontent
Voor wat betreft webcontent is als uitgangspunt gekozen voor een gekoppeld (3P) CMS. Een „eigen‟
(1P) webcontentmanagementsysteem van de 3D-suite t.b.v. redactie en publicatie van informatie
t.b.v. de burger wordt echter niet uitgesloten. Wel is getracht om, op plaatsten waar dit
onderscheid relevant is, in de vraagstelling een markering aan te brengen door middel van rechte
haken ([ en ]).
Wanneer het bestek (het aanbestedingsdocument incl. een gedetailleerde opdrachtbeschrijving,
procedurele / juridische aspecten, PvE, etc.) t.b.v. van een daadwerkelijke aanbesteding voor een
35
specifieke gemeente of groep van gemeenten wordt opgesteld, dient het
PvE dus eventueel aangepast te worden aan de specifieke voorkeur dienaangaande.
Documentopslag en documentgeneratie
Voor wat betreft documentopslag is als uitgangspunt gekozen voor een gekoppeld (3P)
zaaksysteem / DMS voor langetermijnopslag en archivering. Vanwege de zware
privacygevoeligheid verwachten we echter dat kortetermijnopslag en –ontsluiting binnen de 3D-
Suite plaatsvindt als een koppeling niet de juiste mate van beveiliging kan garanderen. Een „eigen‟
(1P) documentopslagfaciliteit (vgl. „DMS light‟) van de 3D-suite wordt dus niet uitgesloten. Wel is
getracht om, op plaatsten waar dit onderscheid relevant is, in de vraagstelling een markering aan
te brengen middels rechte haken ([ en ]).
Beveiliging, protocollering en auditing/logging mag niet „onderlangs‟ worden omzeilt (wanneer
mensen ten onrechte via het DMS toegang zouden krijgen tot vertrouwelijke documenten). Ook
v.w.b. archivering en vernietiging is van belang dat dit correct en in zowel 3D-Suite als DMS
gebeurt.
Wanneer het bestek (het aanbestedingsdocument incl. een gedetailleerde opdrachtbeschrijving,
procedurele / juridische aspecten, PvE, etc.) t.b.v. van een daadwerkelijke aanbesteding voor een
specifieke gemeente of groep van gemeenten wordt opgesteld, dient het PvE dus eventueel
aangepast te worden aan de specifieke voorkeur dienaangaande.
Hosting
Voor wat betreft het onderscheid tussen lokale installatie vs. afname van de 3D-suite op basis van
ASP / SaaS is vooralsnog besloten dat geen van beide varianten wordt uitgesloten. In het PvE
wordt primair uitgegaan van lokale installatie, of althans dat de hosting en het technisch beheer
van de 3D-suite niet „meegeleverd‟ hoeven te worden door de leverancier van de 3D-suite. Wel is
er getracht om, op die plaatsten waar dit onderscheid relevant is, in de vraagstelling een markering
aan te brengen door middel van rechte haken ([ en ]). Dit geldt echter niet voor par. 9.5
(technische architectuur); deze is primair opgesteld uitgaande van lokale installatie.
Wanneer het bestek (het aanbestedingsdocument incl. een gedetailleerde opdrachtbeschrijving,
procedurele / juridische aspecten, PvE, etc.) t.b.v. van een daadwerkelijke aanbesteding voor een
specifieke gemeente of groep van gemeenten wordt opgesteld, dient het PvE dus eventueel
aangepast te worden aan de specifieke voorkeur dienaangaande. Indien daarbij gekozen wordt
voor ASP / SaaS zijn daarbij mogelijk nog additionele aandachtspunten van toepassing die in het
onderhavige PvE in mindere mate of op andere wijze zijn onderkend, zoals m.b.t.
(randvoorwaarden rondom) beveiliging, beschikbaarheid en performance, back-up en uitwijk,
escrow, implementatie, migratie etc.
Variabelen
Ten aanzien van verschillende aspecten (zoals het aantal gebruikers, gewenste responsetijd, etc.)
is in het onderhavige PvE sprake van „variabelen‟ die op termijn - wanneer het bestek (het
aanbestedingsdocument incl. opdrachtbeschrijving, procedureel/juridische aspecten, PvE, etc.)
t.b.v. van een daadwerkelijke aanbesteding voor een specifieke gemeente of groep van gemeenten
wordt opgesteld - ingevuld dienen te worden conform de specifieke voorkeuren dienaangaande.
In het PvE is getracht om zo veel mogelijk, op die plaatsten waar sprake is van dergelijke
„variabelen‟, in de vraagstelling een markering aan te brengen door middel van rechte haken ([ en
36
]). Daarnaast zijn versienummers van standaarden en dergelijke op
soortgelijke wijze gemarkeerd, om t.z.t. het meest actuele versienummer te kunnen invullen.
Naast dergelijke „variabelen‟ zijn er mogelijk ook nog andere keuzen die, wanneer het bestek t.b.v.
van een daadwerkelijke aanbesteding wordt opgesteld, ingevuld kunnen worden al naar gelang de
specifieke voorkeuren dienaangaande en waarop in het onderhavige PvE in meer of mindere mate
reeds is „voorgesorteerd‟. Dit betreft bijvoorbeeld keuzen t.a.v. de training (zoals wel of geen train-
de-trainer), client- en serverside architectuur, implementatie en eventuele migratie, eventuele
levering van ondersteunende systeemsoftware (zoals web- en applicatieserver, DBMS, etc.),
eventuele additionele koppelingen en dergelijke.
Verder is het ook denkbaar dat sprake is van een gemeentelijke samenwerking (zoals een
gezamenlijke ambtelijke organisatie), hetgeen specifieke voorkeuren oplevert t.a.v. aspecten als
„multi-gemeente‟ en eventueel zelfs „multitenancy‟. Ook t.a.v. dergelijke aspecten zal het PvE in
dat geval, wanneer het bestek t.b.v. van een daadwerkelijke aanbesteding wordt opgesteld,
aangepast moeten worden al naar gelang de specifieke voorkeuren dienaangaande.
Los systeem of plug-in
Ten slotte is het denkbaar dat een 3D-Suite niet zelfstandig maar als plug-in op bijv. een reeds
aanwezig zaaksysteem wordt gerealiseerd. Veel van de generieke functionaliteiten zullen dan
vanzelfsprekend al aanwezig zijn, zoals de functionaliteiten m.b.t. procesbewaking, integratie en
gegevens en documenten. De focus van het gemeentespecifieke PvE/bestek kan dan liggen op de
evt. ontbrekende functionaliteiten zoals m.b.t. ongestructureerde processen en interactie met de
burger (incl. goede authenticatie en autorisatie). Tevens behoeft de samenhang tussen de
verschillende betrokken systemen en organisaties (leverancier zaaksysteem, leverancier plug-in,
gemeente) dan aandacht.
3.5 Eisen en wensen
In dit PvE wordt een onderscheid gemaakt tussen eisen (genummerd als E + volgnummer) en
wensen. Vooralsnog is ervoor gekozen om de eisen te beperken tot de minimaal noodzakelijke
„basisfunctionaliteit‟. Bij een uiteindelijke aanbesteding kan een gemeente desgewenst bepaalde
wensen tot eis maken (en vice versa). Ook kan dan een differentiatie aangebracht worden in de
weging van de wensen, welke in dit PvE vooralsnog in het midden is gelaten. Wanneer het bestek
voor een daadwerkelijke aanbesteding t.b.v. een specifieke gemeente of groep van gemeenten
wordt opgesteld, dient het PvE aangepast te worden conform de specifieke voorkeur
dienaangaande. Ten slotte dient vanzelfsprekend een beoordelingsmethodiek worden opgenomen
t.b.v. bepaling van de beste prijs/kwaliteit verhouding (over de gehele contractduur, incl.
eenmalige en jaarlijkse kosten en incl. een schatting van meerwerkkosten).
Eisen
Eisen zijn genummerd als E + een volgnummer.
Aan elke eis dient zonder voorbehoud en, voor zover die betrekking heeft op functionaliteit,
middels standaardfunctionaliteit („off-the-shelf‟, dus verifieerbaar in de PoC) voldaan te worden.
Enige uitzondering hierop zijn koppelingen; wanneer één of meer van de geëiste koppelingen
(nog) niet als standaardsoftware worden aangeboden, worden deze als zogeheten generiek
maatwerk (vgl. „nog niet ontwikkelde standaardfunctionaliteit‟) beschouwd.
37
Inschrijver dient hiertoe elke eis uitsluitend met „Ja.‟ te beantwoorden
en, indien daar bij de betreffende eis expliciet om gevraagd wordt, te voorzien van een bewijs.
Wanneer Inschrijver zich niet aldus expliciet akkoord verklaart met een eis, wordt dit als voor-
behoud opgevat en wordt de offerte terzijde gelegd.
Wensen
Bij wensen wordt een onderscheid gemaakt tussen open en gesloten wensen (genummerd als O
resp. S of G + een volgnummer).
Bij open wensen (O#) kan Inschrijver zo beknopt / uitgebreid beantwoorden als hij wil, mits „to
the point‟. Licht de beantwoording van alle open wensen zo mogelijk toe d.m.v. schermafbeel-
dingen.
Bij semi-gesloten wensen (S#) dient Inschrijver, tenzij expliciet anders geïnstrueerd, aan te ge-
ven in welke mate aan elk van de in de betreffende wens genoemde aspecten standaard [(„off-
the-shelf‟, dus verifieerbaar in de PoC)] wordt voldaan. Wanneer dit volledig het geval is, dient
te worden volstaan met het volgende antwoord: “Er wordt standaard („off-the-shelf‟) volledig
aan deze wens voldaan.”. Indien er niet volledig aan een wens wordt voldaan, dient Inschrijver
aan te geven aan welk(e) aspect(en) er niet standaard („off-the-shelf‟) voldaan wordt. Ook in
dat geval kan Inschrijver zo beknopt / uitgebreid antwoorden als hij wil (bij voorkeur incl.
schermafbeeldingen), mits „to the point‟.
Gesloten wensen (G#) zijn opgedeeld in verschillende deelwensen (G1.1, G1.2, …). Per deel-
wens dient met „Ja.‟ te worden geantwoord indien standaard [(„off-the-shelf‟, dus verifieerbaar
in de PoC)] wordt voldaan aan de in de betreffende wens genoemde aspecten, anders „Nee.‟.
Sommige eisen en wensen zijn voorzien van specifieke instructies en/of aandachtspunten ten
aanzien van de beantwoording. Bij zijn beantwoording dient Inschrijver rekening te houden met
dergelijke instructies en/of aandachtspunten.
3.6 Juridische en financiële eisen en wensen
In deze paragraaf worden de algemene (met name juridische en financiële) eisen opgenomen die
verband houden met de aanbesteding van de 3D-Suite. Omdat die eisen nauw verband houden
met de specifieke voorkeuren dienaangaande van de betreffende Gemeente, kan e.e.a. pas
ingevuld worden op het moment dat het daadwerkelijke bestek t.b.v. een aanbesteding voor een
specifieke gemeente of groep van gemeenten wordt opgesteld (waarbij in dat laatste geval
mogelijk nog additionele juridische en/of financiële eisen dienen te worden opgenomen). Het feit
dat deze sectie nog grotendeels leeg is gelaten, betekent overigens niet dat het onderwerp daarom
minder belangrijk zou zijn. Ook op deze onderwerpen dienen goede, veelal gemeentespecifieke,
afspraken te worden gemaakt! Onder andere betreft dit de (model)overeenkomst.
Onderstaande eis is echter zodanig generiek dat deze altijd opgenomen kan worden.
E1 Algemeen: match prijsopgave en functionaliteit
Alle geoffreerde prijzen van de aangeboden 3D-Suite zijn gebaseerd op de specificaties in dit be-
stek. Dat wil zeggen dat alle in de offerte beschreven functionaliteiten en specificaties (beant-
woording van eisen en wensen) onder het aanbod vallen en zijn inbegrepen bij de prijsopgave,
tenzij in de betreffende wens of eis expliciet sprake is van het tegendeel.
38
Indien er producten en/of dienstverlening worden / wordt aangeboden waar additionele kosten
mee gemoeid zijn, dient Inschrijver dit expliciet aan te geven. Bij het niet (volledig) specificeren
van de kosten van één of meer elementen van de aangeboden 3D-Suite impliceert Inschrijver
derhalve dat de niet gespecificeerde kosten nihil zijn.
39
4 PvE: Generieke functionaliteit
4.1 Inleiding (generieke functionaliteit)
Dit hoofdstuk 4 omvat de eisen en wensen m.b.t. de generieke functionaliteit van de 3D-suite. De
specifieke inrichting van de 3D-suite wordt bij voorkeur zoveel mogelijk door middel van
configuratie van (generieke) functionaliteit gerealiseerd, met name om de onderhoudskosten te
reduceren. In tegenstelling tot de specifieke functionaliteit zoals opgenomen in hoofdstuk 5 geldt
deze generieke functionaliteit van de 3D-suite niet uitsluitend voor het sociale domein; in theorie
zou dezelfde functionaliteit - wanneer de 3D-suite hiertoe geschikt zou zijn - geconfigureerd
kunnen worden om voor bijvoorbeeld vergunningverlening ingezet te worden.
Kenmerkend voor het 3D-domein zijn de gevraagde flexibiliteit bij bijv. de procesinrichting, de
communicatie en de autorisaties, waar ook op ad-hoc (runtime) basis inrichtingen moeten kunnen
worden aangepast (dus niet alleen in de beheerfase).
Voor wat betreft de regie is een en ander samen te vatten als: processen, gegevens en
documenten. Het document is vanuit een zaakgerichte visie beschreven, doch de gevraagde
functionaliteiten kunnen ook op basis van bijv. een case management of workflow/processysteem
worden ingericht. Ook is bijvoorbeeld een zaaksysteem is combinatie met waar nodig een
workflowsysteem denkbaar. Het gaat om de functionaliteit. Om een eenduidige –en bij gemeenten
gangbare– terminologie aan te houden is zaakgericht werken gebruikt als kapstok.
In par. 4.2 en verder zijn op basis van bovenstaande visies de wensen en eisen geformuleerd voor
de generieke functionaliteit van de 3D-Suite. Zoals in par. 3.5 beschreven wordt daarbij gebruik
gemaakt van Eisen (E#), Gesloten wensen (G#), Open wensen (O#) en Semigesloten wensen
(S#). Zoals gezegd heeft het de voorkeur (vanwege de gewenste flexibiliteit) dat de
domeinspecifieke functionaliteiten in hoofdstuk 5 zoveel mogelijk ingericht zijn op basis van de
generieke functionaliteiten uit onderhavige hoofdstuk.
4.2 Processen (regievoering en bewaking)
4.2.1 Inleiding
De belangrijkste (primaire) processen zijn die van signalering, intake tot en met nazorg (zie 2.8.1).
We zullen een dergelijk proces in dit hoofdstuk vaak aanduiden als een “zaak”. Waar termen als
“zaak” staan, kan bijv. ook ”(ondersteunings)traject” worden gelezen, of “taak”, “actie” of
“maatregel” i.p.v. deelzaak. Afhankelijk van de context kan in plaats van een deelzaak ook een
gerelateerde zaak worden gebruikt (zie ook de GEMMA ZTC 2.0), bijv. wanneer een
uitvoeringsorganisatie deze uitvoert.
Waar hier over zaken, zaakgericht werken, processen, etc. wordt gesproken, wordt benadrukt dat
hier veel verschillende trajecten (uitwerking van ondersteuningsplannen) mogelijk zijn. Dit zal
zowel per gemeente, per type ondersteuning, per groep gebruikers en óók per specifieke burger en
plan kunnen verschillen. Ook zijn ad-hoc processen of ad-hoc taken mogelijk.
Het ondersteuningsplan kan bestaan uit een mix van één of meer (deel)zaken die worden
behandeld door één of meer personen / organisaties. Zaken kunnen al dan niet met elkaar
gerelateerd zijn. Zaakprocessen hebben meestal een doorlooptijd van minimaal enkele dagen en
worden hier onderscheiden van kortlopende processen tijdens bijv. een intakeproces.
40
Bij voorkeur gebeurt de inrichting van de processen op basis van zoveel
mogelijk „zero coding‟ en o.b.v. de GEMMA Zaaktypecatalogus 2.0 8, door de leverancier en/of door
de gemeente zelf. Kenmerkend voor 3D is dat sommige inrichtingen ad-hoc mogelijk moeten zijn.
Dan is een „voorzet‟ ingericht door functioneel beheer, maar voor één specifieke zaak worden door
de regisseur of een andere medewerker runtime aanvullende deelzaken, taken (in de vorm van
extra statussen, of minder gestructureerd extra checklists, etc.) en/of autorisaties gezet.
Zaaktypeconfiguratie (zaaktypebeheer) en zaakbeheer (runtime) zijn in deze context dus nauw
verweven.
4.2.2 Registreren klantcontacten en zaken
G1 Zaakregistratie: algemeen
De 3D-Suite biedt functionaliteit m.b.t. het conform de betreffende zaaktypen registreren van za-
ken in de 3D-Suite door medewerkers zowel van de gemeente als van geautoriseerde ketenpart-
ners. Dit betreft ten minste:
G1.1
- Het o.b.v. de ingevulde gegevensregistratieschermen / -formulieren registreren van nieuwe
zaken, conform de betreffende zaaktypen, incl. het registreren van de betreffende gegevens in
de zaakattributen van de betreffende zaken.
G1.2
- Bij intake n.a.v. een signalering wordt gebruik gemaakt van „prefill‟ (d.w.z. dat wanneer ge-
bruikers de gegevensregistratie starten, alle gegevens automatisch worden overgenomen van
het signaal)
G1.3
- Het volledig geautomatiseerd opnemen van eventuele bijgevoegde documenten in het betref-
fende zaakdossier, alsmede een PDF/A- en/of XML-bestand van berichten / signalen die als
start van een zaak gelden.
S1. Registreren uitvoeringsorganisatie bij klantcontact/door te zenden intake
Bij het registreren van een klantcontact dat doorgezonden moet worden naar een uitvoeringsor-
ganisatie (informatievraag, terugbelnotitie) is vast te leggen op welke uitvoeringsorganisatie het
betrekking heeft, m.a.w. naar welke uitvoeringsorganisatie het bericht daarna doorgezonden
moet worden.
Indien het klantcontact betrekking heeft op een lopende zaak, wordt het klantcontact bij de zaak
geregistreerd. Indien het klantcontact geen betrekking heeft op een lopende zaak, dan kan de
medewerker direct en zeer eenvoudig (met 1 of 2 extra klikken) de juiste uitvoeringsorganisatie
selecteren. Daarbij wordt een nieuwe zaak gestart.
4.2.3 Zaakbeheer
G2 Zaakbeheer: werklijst
G2.1
De 3D-Suite biedt functionaliteit zodat aldus geregistreerde zaken zichtbaar zijn in een werklijst.
(Groepen) medewerkers kunnen, al naar gelang hun autorisaties, de zaken zien in hun respectie-
velijke werklijsten, inclusief ten minste:
8 www.kinggemeenten.nl/ztc/ztc-20
41
G2.2
- Zaaktypen, zaken incl. eventuele bijbehorende notities, contactmomenten en zaakrelaties
(hoofd-, deel- en gerelateerde zaken).
G2.3
- De betreffende betrokkenen, incl. relaties
G2.4
- Actuele status- en andere proces(voortgangs)informatie, waaronder ten minste actuele norm-
/streefdata en –termijnen en (resterende) doorlooptijden.
G2.5
- Actuele attendering om veranderingen in (de status en/of samenstelling van) zaken en dos-
siers kenbaar en inzichtelijk te maken middels visuele markeringen, waaronder ten minste
van:
▪ Nieuwe (hoofd-, deel- en gerelateerde) zaken, status/stappen / taken, etc.
▪ Statuswijzigingen
▪ Nieuwe informatie in zaak(dossier), zoals documenten, notities, contactmomenten, etc.
▪ (Dreigende) overschrijding van norm- / streefdata en -termijnen
▪ Notificaties n.a.v. het “afgaan” van reminders.
G3 Zaakbeheer: handelingen
De 3D-Suite biedt functionaliteit m.b.t. zaakbeheer waarmee op zaken ten minste de volgende
handelingen kunnen worden uitgevoerd:
G3.1
- Aanmaken
Het aanmaken van een nieuwe zaak, „from scratch‟ maar ook o.b.v. een signalering of melding
G3.2
- Accepteren en in behandeling nemen
Zolang zaken nog niet zijn geaccepteerd, kunnen ze door daartoe geautoriseerde gebruikers
worden geaccepteerd en in behandeling worden genomen.
G3.3
- Weigeren
Zolang zaken nog niet geaccepteerd zijn, kunnen ze door gebruikers worden geweigerd, waar-
na
ze als “uitval” worden aangemerkt en volledig geautomatiseerd naar een specifieke werklijst
voor “uitval” worden gerouteerd die inzichtelijk is voor ten minste regisseurs.
G4 Zaakbeheer: handmatig toewijzen
G4.1
De 3D-Suite biedt functionaliteit m.b.t. zaakbeheer v.w.b. handmatig toewijzen van zaken
aan bepaalde behandelaars en/of behandelgroepen (werklijsten).
G4.2
Ook na toewijzing van zaken blijven deze zichtbaar in de oorspronkelijke werklijst; hierdoor
ontstaat een virtuele hiërarchie van werklijsten zodat bijvoorbeeld coördinatoren zaken
kunnen (her)verdelen over andere (groeps- en/of persoonlijke) werklijsten, terwijl zij status
en voortgang kunnen blijven volgen.
G4.3
42
Daartoe geautoriseerde gebruikers (bijv. de regisseur) kunnen te allen tijde zaken van andere
gebruikers overnemen (“pull”, bijv. bij vakantie) of eigen zaken naar andere daartoe
geautoriseerde gebruikers doorzetten (“push”).
G4.4
Een regisseur kan op ieder moment deelzaken (ad-hoc) toevoegen en deze ad-hoc toewijzen
aan bestaande gebruikers in de 3D-Suite én nieuwe gebruikers (bijv. van een niet eerder
bekende uitvoeringsorganisatie).
4.2.4 Zaakbehandeling
G5 Zaakbehandeling: standaardstatussen
G5.1
De 3D-Suite biedt functionaliteit m.b.t. processturing t.a.v. (de behandeling van) zaken zoda-
nig dat deze door middel van een aantal opeenvolgende statussen naar een eindresultaat ge-
leid worden. Dit omvat ten minste de volgende vier statussen: 1) ontvangen, 2) geaccep-
teerd, 3) in behandeling en 4) afgehandeld.
G5.2
Bovendien biedt de 3D-Suite functionaliteit waarmee bij zaaktypen tussen de statussen “in
behandeling” en “afgehandeld” nog additionele statussen kunnen worden geconfigureerd ten-
einde de voortgang en kwaliteit van zaken te kunnen bewaken en/of een (deel)zaak bij een
ander uit te zetten.
G5.3
De standaardsamenstelling van zaaktypen (standaardstatussen, evt. documenttypen zoals in-
takeverslag, standaardtaken, checklists, etc.) is in een zaaktypencatalogus (in de zaaktype-
configuratie van het betreffende zaaktype) per zaaktype vastgelegd cf. GEMMA ZTC 2.0 en
kan door functioneel beheerders van Gemeenten volledig zelfstandig - zonder dat daarvoor
geavanceerde programmeerkennis nodig is (zero coding) - worden beheerd.
G6 Zaakbehandeling: ad-hoc behandeling en aanpassing
De 3D-Suite biedt functionaliteit voor het ad-hoc toevoegen van afwijkingen op een zaak (dus an-
ders dan het normale procesverloop zoals geconfigureerd in het betreffende zaaktype), ten min-
ste:
G5.1
- Het toevoegen van extra stappen/statussen (serieel) binnen een zaak en deelzaken (parallelle
afhandeling), zowel bij aanvang van een zaak als tijdens behandeling ervan.
G5.2
- Het ad-hoc toevoegen van betrokken gebruikers, incl. hun rol daarbij en de rechten (CRUD) op
de (deel)zaak, de hoofdzaak en het klantdossier.
G7 Zaakbehandeling: hoofd-, deel- en gerelateerde zaken
G7.1
- De 3D-Suite biedt functionaliteit dat bij zaken ten minste handmatig (door gebruikers) één of
meerdere in de zaaktypecatalogus gedefinieerde deelzaken (bijv.: „regelen uitkering„) kunnen
worden aangemaakt resp. ontstaan.
43
G7.2
- Deelzaken zijn verder precies hetzelfde als “gewone” (hoofd)zaken en nemen automatisch de
(zaak)attributen van de bijbehorende hoofdzaak over voor zover die attributen in de zaaktype-
configuratie van het zaaktype van de betreffende deelzaak voorkomen en niet anders zijn ge-
configureerd. Ieder zaaktype kan als deelzaak voorkomen.
G7.3
- Eventuele “onderliggende” (deel)zaken en “bovenliggende” (hoofd)zaken zijn zichtbaar bij het
inzien van zaken, waarbij gebruikers direct kunnen “doorklikken” naar iedere betreffende
hoofd- en/of deelzaak.
G7.4
- De regisseur van de hoofdzaak kan bepalen of behandelaars van deelzaken geautoriseerd zijn
tot alle informatie in de bijbehorende hoofdzaak (incl. de betreffende dossiers) en of de regis-
seur zelf inzicht heeft in de informatie van de deelzaken.
G7.5
- De regisseur van de hoofdzaak kan bepalen of behandelaars van deelzaken geautoriseerd zijn
tot door de regisseur te bepalen delen van de informatie in de bijbehorende hoofdzaak.
G7.6
- Bij deelzaken kan een afhankelijkheid in tijd en “en/of” combinaties worden gedefinieerd: eerst
moeten bijv. A,B, en C zijn afgerond voor Y of Z start (bijv.: eerst helpen afkicken en een uit-
kering regelen, dan pas werk of opleiding zoeken). Dit is zowel in de beheerfase (ZTC2.0) door
functioneel beheer te bepalen als bij runtime (ad-hoc) door de zaakbehandelaar/regisseur.
G7.7
- Daarnaast biedt de 3D-Suite functionaliteit dat elke zaak aan één of meer andere zaken gere-
lateerd kan worden. Eventuele relaties met andere zaken zijn zichtbaar bij het inzien van za-
ken, waarbij gebruikers direct kunnen “doorklikken” naar iedere betreffende gerelateerde zaak.
G7.8
- De 3D-Suite biedt functionaliteit dat bij een lopende zaak aanvullende statussen (bijv. een
aanvullende taak uitzetten en handmatig bewaken) kunnen worden toegevoegd door de ver-
antwoordelijke voor de betreffende zaak. Dit is zowel in de beheerfase (ZTC2.0) door functio-
neel beheer te bepalen als bij runtime (ad-hoc) door de zaakbehandelaar/regisseur.
G8 Zaakbehandeling: statusberichten
G6.1
- De 3D-Suite biedt functionaliteit dat bij elke statusovergang van een zaak volledig geautomati-
seerd een statusbericht gegenereerd kan worden ten behoeve van betrokken interne en exter-
ne medewerkers, ten minste via de webinterface en via e-mail.
G6.2
- Statusberichten bevatten ten minste de betreffende zaakidentificatie (zaaknummer), een di-
recte link (URL) en een bijbehorende toelichting en kunnen door gebruikers desgewenst nog
worden aangepast vóór het daadwerkelijk verzenden c.q. afdrukken ervan.
O1 Zaakbehandeling: processturing (beheer)
Beschrijf de functionaliteit van de 3D-Suite m.b.t. het beheren van de functionaliteit m.b.t. pro-
cessturing t.a.v. zaken. Ga daarbij ten minste in op (voor zover van toepassing):
- In welke mate en op welke wijze er per zaaktype - indien van toepassing per status(overgang)
44
en/of afhankelijk van het geselecteerde resultaattype - ingesteld kan worden:
▪ Welke statussen erbij kunnen/moeten voorkomen (en in welke volgorde)
▪ Welke soorten afhankelijkheid kunnen worden gedefinieerd, waarbij bijv. een type besluit,
aanwijzing, resultaat, of document het verder vervolg van een zaak als het ware dicteren
▪ Welke controlevragen er in de eventuele checklist bij een status of zaak worden gesteld
▪ Welke elementen verplicht „aanwezig‟ moeten zijn, zoals gegevens, documenttypen, afge-
vinkte controlevragen (checklist), zaaktypen die als deel- en/of gerelateerde zaak voorko-
men, etc.
▪ Welke werkinstructies en/of andere hulpmiddelen er beschikbaar zijn
▪ Welke (seriële) stappen / taken erbij kunnen/moeten voorkomen (en in welke volgorde),
bijv. o.b.v. checklists / velden binnen een status en o.b.v. extra statussen
▪ Welke autorisaties (rechten en rollen) er gelden, indien van toepassing per deelzaak / sta-
tus
▪ Hoe wordt bepaald wanneer naar een volgende status te gaan?
▪ Welke overige mogelijkheden voor processturing zijn beschikbaar?
- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in de
3D-Suite (zoals via configuratie van zaaktypen in een zaaktypencatalogus) én in welke mate
het ad-hoc (door de zaakbehandelaar/regisseur) kan worden gedaan.
- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-
standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen
beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus, liefst obv. ZTC2).
- Geef aan wat ad-hoc kan en in hoeverre dat eventueel voorbereid (als optie) kan worden in de
ZTC.
S2. Inzage in taakuitvoering
Het is voor elke wijk, elk gezin, elk product (een bepaalde ondersteuningsdienst) en elke zaak
vast te leggen bij welke organisatie, intern (afdeling) dan wel extern (uitvoeringsorganisatie), de
uitvoering/behandeling van het product/de zaak standaard belegd zal worden. Dit is per pro-
duct/dienst en per zaaktype als standaardorganisatieonderdeel vast te leggen in de betreffende
configuratie, te weten product-dienstenbeschrijving en zaaktypeconfiguratie. Ook is het bij aan-
maken en tijdens behandeling door de verantwoordelijke te overrulen.
Het is inzichtelijk in de gebruikersinterface wie (organisatie + afdeling + persoon) de uitvoering
verzorgt, ten minste bij de productinformatie en zaakdetails. Medewerkers in het medewerker-
sportaal hebben daarbij snel toegang (met één extra klik) tot de contactgegevens van de betref-
fende organisatie.
S3. Doorzetten van klantcontact/intake
Klantcontacten en „door te zenden intake‟ (gescande post/e-mail die ten onrechte bij de Gemeen-
te wordt afgeleverd i.p.v. direct bij de uitvoeringsorganisatie) die betrekking heeft op taken die bij
uitvoeringsorganisaties belegd zijn, kunnen door de 3D-Suite incl. e-mail-attendering worden
doorgezet naar de betreffende uitvoerende organisatie. Hierbij wordt enkel „dat‟ verstuurd, de ge-
registreerde toelichting/informatie van het klantcontact/intake, evenals de relevante digitale do-
cumenten (gescande post) zijn op te halen door in te loggen in de beveiligde 3D-Suite (of worden
via beveiligde kanalen als elektronisch bericht verstuurd).
Aangezien bij het klantcontact al de juiste uitvoeringsorganisatie is vastgelegd, is bij de 3D-Suite
bekend waar de e-mail naartoe gezonden moet worden. Het verzenden gebeurt dan ook volauto-
matisch.
45
Het doorzenden via e-mail vindt op de achtergrond plaats via een integratie met de mailserver
van de Gemeente [merk, type, versie]. Medewerkers hoeven t.b.v. het doorzetten van het klant-
contact de interface van de 3D-Suite niet te verlaten.
S4. Bewaken van klantcontact/intake
Op klantcontacten/intake die geïnitieerd zijn bij de Gemeente maar die betrekking hebben op ta-
ken die bij uitvoeringsorganisaties zijn belegd, is standaard een termijn van toepassing waarbin-
nen de taak (=gerelateerde of deelzaak) dient te worden afgerond. Bij het naderen én bij het ver-
strijken van de termijn vindt een notificatie plaats aan de regisseur. De termijn is door functioneel
beheer in het dienstenboek of zaaktypecatalogus ingesteld en door de regisseur te overrulen.
NB: Voorbeeld van gebruik van een dergelijke functie is bijvoorbeeld voor een terugbelverzoek,
maar ook om te zien of actie is ondernomen op doorgezonden intake.
O2 Registratie van klantcontact/’door te zenden intake’
Beschrijf de functionaliteit van de 3D-Suite m.b.t. de registratie van „klantcontact‟ (zoals contact-
momenten en terugbelverzoeken) t.b.v. uitvoeringsorganisaties én de registratie van het door-
zenden van intake (gescande post, e-mail met bijlagen).
Beschrijf of de registratie van dergelijk klantcontact afwijkt van registratie van klantcontact voor
intern gebruik. Geef aan hoe de betreffende uitvoeringsorganisatie bij het klantcontact geregi-
streerd wordt en hoe de termijnbewaking werkt. Ga op vergelijkbare wijze in op de registratie van
„door te zenden intake‟.
Ga tevens in op de wijze waarop door te zenden klantcontacten en intake in de 3D-Suite vastge-
legd worden.
O3 Casusoverleg en communicatie tussen medewerkers, burgers en overig
Beschrijf de functionaliteiten die de 3D-suite biedt om bij voorkeur per signalering, per burger én
per zaak een casusoverleg in te plannen en voor te bereiden en digitaal te voeren. Bij voorkeur
kan dit ten minste doordat de regisseur medewerkers van de gemeente en/of uitvoeringsorgani-
saties toegang geeft tot delen van de omgeving en uitnodigt voor het overleg.
Beschrijf tevens de mogelijkheden die de 3D-Suite biedt om anderszins te communiceren tussen
burger, regisseur, wijkteam, uitvoeringsorganisatie, etc. Denk aan ten minste beveiligde e-mail en
notitievelden, maar ook bijv. beveiligde chat en het beveiligd uitwisselen van documenten.
46
4.3 Gegevens en dossiers
4.3.1 Inleiding (gegevens)
Basisgegevens zijn de meest elementaire gegevens die voor een relatie worden bijgehouden.
Hieronder vallen naam, adres, woonplaats (NAW) en contactgegevens, zoals telefoonnummers en
e-mailadressen. Voor de structuur van deze basisgegevens is het van belang dat er zowel
gegevens van individuele burgers, van gezinnen in verschillende samenstellingen als van bedrijven
en andere organisaties worden bijgehouden. Voor organisaties - incl. gezinnen - moeten behalve
de gegevens van de persoon, ook de organisatiegegevens worden bijgehouden. Waar nodig
moeten ook historische of toekomstige gegevens (zoals adres voor of na verhuizing) worden
vastgelegd.
Organisaties kunnen verschillende adressen hebben voor post, voor de levering van goederen en
voor afspraken. Ook kunnen er bijv. verschillende factuuradressen zijn. Daarnaast kunnen grotere
organisaties uit structuren van kleinere bestaan. Bedrijven en bedrijfsonderdelen hebben
contactpersonen, soms meerdere die elk hun eigen verantwoordelijkheid hebben. Al deze gegevens
kunnen relevant zijn en het bijhouden ervan levert de basisinformatie om professioneel met de
betreffende organisatie te kunnen communiceren en handelen.
Tenslotte is er het netwerk rond een persoon en gezin dat uit zeer verschillende typen personen en
organisaties met verschillende rollen kan bestaan. Deze relaties kunnen formeel zijn, of informeel.
Formele relaties zijn bijv. leverancier van een dienst, huisarts, regisseur (casus-beheerder), of
diverse typen therapeuten. Informele relaties betreft met name het netwerk om een persoon of
gezin. Denk aan relaties binnen het gezin, een vriend, buurman, vader, moeder, pastoor, imam,
wijkagent, etc.
Deze relaties hebben impact op de opbouw en toegang9 tot een gezinsdossier (waarschijnlijk een
aantal individuen die samen een gezin vormen, echter nog uit te werken).
Webintake van gegevens omvat alle functionaliteit voor het ontwikkelen, publiceren, (doen)
invullen en verwerken van webformulieren, alsook voor het beheren daarvan. Dit betreft onder
meer formulierontwerp - zowel qua inhoud (incl. logica en intelligentie) als qua vormgeving /
opmaak - en -beheer (incl. versiebeheer en hergebruik van „veldblokken‟ als NAW). De
functionaliteit t.b.v. formulierontwerp is bij voorkeur zodanig dat de Gemeente op eenvoudige
wijze (liefst o.b.v. „what-you-see-is-what-you-get‟) zelf additionele formulieren kunnen ontwerpen,
zonder hulp van de Contractant. Webintake beperkt zich niet tot gegevensinvoer door burgers
(selfservice) doch ook gegevensinvoer door medewerkers (incl. regisseur, professional, etc.) wordt
bij voorkeur met dezelfde formulierfunctionaliteit ondersteund.
4.3.2 Gegevensbeheer en -opslag
E2 Gegevensbeheer en -opslag: basisfunctionaliteit klantdossiers
De 3D-Suite biedt functionaliteit m.b.t. gegevensbeheer en –opslag, waaronder ten minste:
- Beheer en opslag van gegevens m.b.t. burgers, gezinnen en organisaties, waarbij de betref-
fende gegevens worden beheerd door middel van en opgeslagen in de 3D-Suite (zoals als on-
9 De situatie bijvoorbeeld dat een kind verhuist van het gezin van de moeder naar het gezin van de
vader, levert vragen op ten aanzien van toegang, beheer en het bewaren van historie van de
gegevens.
47
derdeel van klantbeeld, klantdossier of zaakdossier)
- Beheer en opslag van gegevens m.b.t. zaken (inclusief documenten conform RGBZ)
- Beveiliging (zie hoofdstuk 8) m.b.t. bovenstaande, waaronder ten minste autorisaties (rechten
en rollen) en auditing / logging (incl. protocollering).
O4 Gegevensbeheer en -opslag: algemeen
Beschrijf de functionaliteit van de 3D-Suite m.b.t. gegevensbeheer en -opslag van respectievelijk:
- Gegevens m.b.t. burgers, gezinnen en organisaties (zie E2), inclusief documenten.
- Overige objectregistraties (zie O7).
- Gegevens t.a.v. zaken (zaak- en aanverwante gegevens, zie E2).
Ga daarbij ten minste in op (voor zover van toepassing):
- De precieze wijze en “locatie” waarop elk van deze gegevens in c.q. door middel van de 3D-
Suite worden beheerd en opgeslagen (v.w.b. domeinspecifieke gegevens bijvoorbeeld via kop-
peling met een 3P bronsysteem zoals een verwijsindex), incl. de mate waarin en de wijze
waarop daarbij van elk van die gegevens ook historie en relaties worden opgeslagen.
- In welke mate en op welke wijze bovenstaande middels configuratie is ingericht in de 3D-Suite
(zoals via configuratie van zaak-/objecttypen in een zaak-/objecttypencatalogus).
- In welke mate en op welke wijze functioneel beheerders van Gemeenten bovenstaande - incl.
het datamodel van de betreffende gegevens (voor zover toegestaan), zowel v.w.b. entiteiten
en attributen als relaties - volledig zelfstandig, zonder dat daarvoor geavanceerde program-
meerkennis nodig is (zero coding), in de 3D-Suite kunnen beheren na een cursus zoals be-
schreven in par. 10.2, zoals via configuratie van zaak-/objecttypen in een zaak-
/objecttypencatalogus.
Maak daarbij bovendien - voor zover van toepassing - steeds onderscheid tussen de betreffende
gegevens als objectregistratie enerzijds (met een levensduur langer dan 1 specifieke zaak) en in
de context van de uitvoering van zaken anderzijds.
S5. Delen van dossiers
Daartoe geautoriseerde medewerkers kunnen (gezins)dossiers delen met externe partijen die na
ad-hoc autorisatie webbased toegang krijgen tot enkel de aan hen toebedeelde delen van dossiers
en zaken.
O5 Beheer gegevens uitvoerende organisaties
Beschrijf de functionaliteit van de 3D-Suite met betrekking tot het beheren van (gegevens over)
uitvoeringsorganisaties door de Gemeente. Ga daarbij in op de mogelijkheid om alle relevante or-
ganisaties in de 3D-Suite vast te leggen/registreren, incl. algemene contactgegevens en gegevens
over contactpersonen.
Geef tenslotte aan in welke mate en op welke wijze dit middels configuratie door Contractant is
ingericht in de 3D-Suite en in welke mate en op welke wijze functioneel beheerders van
Gemeente e.e.a. volledig zelfstandig -zonder dat daarvoor geavanceerde programmeerkennis
nodig is (zero coding)- kunnen beheren.
NB: Licht uw beantwoording zo nodig toe met afbeeldingen, schematische weergaven, etc.
48
O6 Relatiebeheer burgers, gezinnen en overige betrokkenen
Een gezin of groep samenwonende personen kan vele vormen hebben. Beschrijf de functionaliteit
van de 3D-Suite met betrekking tot het definiëren van gegevens over burgers, gezinsstructuren,
contactpersonen en dergelijke (incl. de mate waarin relevante historische gegevens bewaard blij-
ven).
Beschrijf de mate van flexibiliteit van type en structuur van gegevens die geregistreerd kunnen
worden:
- In welke mate een functioneel beheerder (of zelfs een regisseur, voor een specifieke zaak) zelf
velden kan toevoegen, incl. veldtype (tekst, datum, getal, etc.)
- In welke mate een functioneel beheerder (of zelfs een regisseur, voor een specifieke zaak) zelf
simpele validaties kan toevoegen, zoals datum van-tot
- Is er een technische grens aan aantallen en type te registreren gegevens?
Geef tenslotte aan in welke mate en op welke wijze dit middels configuratie door Contractant is
ingericht in de 3D-Suite en in welke mate en op welke wijze functioneel beheerders van
Gemeente e.e.a. volledig zelfstandig -zonder dat daarvoor geavanceerde programmeerkennis
nodig is (zero coding)- kunnen beheren.
O7 Centrale bedrijfsregels (business rules)
Op diverse plaatsen worden bedrijfsregels gebruikt, bijvoorbeeld bij filtering (“wanneer is sprake
van een veiligheidsrisico en is direct behoefte aan aandacht van de regisseur”), bij het definiëren
van bepaalde velden (“wanneer is iemand volwassen”), bij zowel gegevensinvoer door burgers als
medewerkers, etc.
Een voorbeeld van een business rule betreft de situaties waarin wanneer een signaal wordt aan-
gemaakt als een burger in een (door gemeente bepaalde) tijd een (door gemeente bepaald) aan-
tal eenvoudige/enkelvoudige aanvragen heeft ingediend; of wanneer sprake is van veiligheidsrisi-
co‟s bij een signaal.
Geef aan in welke mate u een centraal ingerichte „business rule engine‟ of vergelijkbaar biedt, de
mate waarin de regels door de functioneel beheerder van de gemeende zijn aan te passen, en de
wijze waarop door de functioneel beheerder de regels zijn te gebruiken.
Maak waar nodig onderscheid tussen verschillende onderdelen van de delen van de 3D-Suite, zo-
als indien bedrijfsregels enkel zijn te gebruiken bij objectenregistraties, o.i.d.
O8 Overige objectregistraties
Beschrijf de functionaliteit van de 3D-Suite met betrekking tot het definiëren t.b.v. het vastleggen
van gegevens over andersoortige objecttypes zoals bijv. rolstoelen waarbij per objecttype (bijv.
rolstoel) gegevens van verschillende types worden vastgelegd (bijv. onderhoud, verwijzing naar
burger waar het is uitgeleend, etc.).
Beschrijf de mate van flexibiliteit van type en structuur van gegevens die geregistreerd kunnen
worden, de relaties die met andere objecten kunnen worden gelegd.
Geef tenslotte aan in welke mate en op welke wijze dit middels configuratie door Contractant is
ingericht in de 3D-Suite en in welke mate en op welke wijze functioneel beheerders van
Gemeente e.e.a. volledig zelfstandig -zonder dat daarvoor geavanceerde programmeerkennis
nodig is (zero coding)- kunnen beheren.
49
4.3.3 Gegevensregistratie en intake
In onderstaande sectie wordt geen onderscheid gemaakt tussen functionaliteit t.b.v. burgers en
t.b.v. medewerkers (binnen en buiten de gemeente). De functionaliteit is grotendeels gelijk, de
mate waarin een bepaalde rol bepaalde gegevens ziet en/of mag muteren verschilt. Waar sprake is
van gegevensregistratie, kan dus ook sprake zijn van zgn. webintake door burgers.
Benadrukt wordt dat de gegevensregistratie op álle momenten kan plaatsvinden, dus niet enkel bij
een eerste intakegesprek.
E3 Gegevensregistratie: basisfunctionaliteit
De 3D-Suite biedt functionaliteit m.b.t. gegevensregistratie en -bewerking, waaronder ten minste:
- Functionaliteit m.b.t. gegevensregistratie (“data entry”) middels gegevensregistratieschermen
/ -formulieren (zie o.a. G10) zodat gebruikers (medewerkers van gemeente en uitvoeringsor-
ganisaties / ketenpartners) gegevens kunnen registreren (CRUD 10, al naar gelang de autorisa-
ties) m.b.t. zaken en “objecten” in de 3D-Suite, incl. functionaliteit om dergelijke gegevensre-
gistratieschermen / formulieren te creëren en beheren, zowel qua inhoud (incl. logica en intel-
ligentie) als qua structuur / lay-out.
- Functionaliteit om gegevensregistratieformulieren (webformulieren) t.b.v. registratie aan te
bieden aan burgers en derden, incl. identificatie (v.w.b. burgers DigiD „middel‟ incl. DigiD
Machtigingen)
- Functionaliteit m.b.t. logica (ten minste single- en multifield bedrijfs-/meldingregels / valida-
ties, incl. meldingen aan burgers en medewerkers wanneer logica “overtreden” wordt) t.a.v.
gegevensregistratie, incl. functionaliteit om die logica te creëren en beheren.
- Functionaliteit m.b.t. intelligentie (d.w.z. dat gegevensregistratieschermen / -formulieren “dy-
namisch” worden aangepast o.b.v. door burgers en medewerkers ingevoerde gegevens) t.a.v.
gegevensregistratie, incl. functionaliteit om dergelijke intelligentie te creëren en beheren.
- Beveiliging dienaangaande (zie hoofdstuk 6), waaronder ten minste autorisaties (rechten en
rollen) en auditing / logging (incl. protocollering).
G9 Gegevensregistratie
G9.1
De 3D-Suite biedt functionaliteit m.b.t. gegevensregistratie (“data entry”) middels gegevens-
registratieschermen / -formulieren door medewerkers (medewerkerintake) t.b.v. zaakregi-
stratie (het registreren van zaken en bijbehorende objecten en documenten) in de 3D-Suite.
Hierbij is in een split screen een zogeheten “embedded preview” of master-detailscherm van
betrokken document(en) of signalen beschikbaar.
G9.2
Medewerkers worden hierbij ondersteund met zoekfuncties naar ten minste basisgegevens
(zoals personen en adressen) en zaaktypen en hebben bovendien de mogelijkheid om aldus
geregistreerde gegevens (het ingevulde gegevensregistratiescherm / -formulier) te printen
(o.a. ter ondertekening door burgers).
G9.3
10 CRUD: Create, Read, Update, Delete.
50
Of elementen (zoals registratie van specifieke gegevens, documenttypen en -attributen, con-
trolevragen, etc.) daarbij verplicht zijn, is op 1 plaats (in een zaaktypecatalogus, objecttype-
catalogus, of vergelijkbaar) vastgelegd en kan door functioneel beheerders van de gemeenten
volledig zelfstandig - zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero
coding) - per zaaktype worden beheerd.
G10 Gegevensregistratie: gegevensregistratieschermen / -formulieren (algemeen)
De 3D-Suite biedt functionaliteit m.b.t. gegevensregistratie (“data entry”) middels gegevensregi-
stratieschermen / -formulieren zodat gebruikers (zowel burgers als medewerkers) gegevens kun-
nen registreren in de 3D-Suite. Daarbij zijn zowel voor medewerkers als voor burgers ten minste
onderstaande functionaliteiten beschikbaar:
G10.1
Functionaliteit m.b.t. verplichte en optionele invoer / selectie bij gegevensregistratie, waarbij
het al dan niet verplicht zijn van de invoer / selectie voor gebruikers in één oogopslag inzich-
telijk is.
G10.2
Of elementen (zoals registratie van specifieke gegevens, documenttypen en -attributen, con-
trolevragen, etc.) daarbij verplicht zijn, is in de zaaktypencatalogus (in de zaaktypeconfigura-
tie van het betreffende zaaktype) vastgelegd en kan door functioneel beheerders van ge-
meente volledig zelfstandig - zonder dat daarvoor geavanceerde programmeerkennis nodig is
(zero coding) - per zaaktype voor elke status worden beheerd.
Functionaliteit m.b.t. verschillende door gemeente in te richten invoermethoden, waaronder
ten minste:
G10.3
“Vrije” tekst (alfanumeriek), radiobuttons, checkboxes, selectie van een datum(range), etc.
G10.4
Zogeheten snelkeuzelijsten om via een door gemeente in te richten dropdown- / picklist een
selectie te maken uit een (meer of minder beperkte) verzameling mogelijke gegevenswaar-
den.
G10.5
Daarbij is sprake van zogeheten auto-aanvullen (d.w.z. dat bij invoer van de eerste en alle
volgende letters automatisch naar de eerste betreffende mogelijkheid gesprongen wordt).
G10.6
Bij de selectie van een waarde uit een snelkeuzelijst wordt bovendien automatisch gecontro-
leerd of deze waarde nog valide is (d.w.z. actueel is t.o.v. de betreffende “bron”).
G10.7
Zogeheten ”master-/detailschermen”. Dat wil zeggen: één schermdeel (de “master”, bijv. ge-
zin) met een lijst / overzicht van bijvoorbeeld personen, zaken, objecten, etc. en een ander
schermdeel (het “detail”, bijv. gezinsleden) met details van het geselecteerde element uit de
“master” (zoals naam, adres, etc. van de geselecteerde persoon) welke vervolgens kunnen
worden gebruikt t.b.v. gegevensregistratie.
G10.8
Functionaliteit m.b.t. zogeheten prefill, zowel vanuit derde system zoals GBA/BRP als vanuit
de 3D-Suite zelf.
G10.9
51
Bij iedere burger, gezin, zaak, etc. zijn notities op te nemen.
G10.10
Notities zijn als vertrouwelijk te duiden.
G11 Gegevensregistratie: gegevensregistratieschermen / -formulieren (logica en intel-
ligentie)
De 3D-Suite biedt functionaliteit m.b.t. gegevensregistratie (“data entry”) door middel van gege-
vensregistratieschermen / -formulieren zodat gebruikers gegevens kunnen registreren in de 3D-
Suite. Daarbij zijn ten minste onderstaande functionaliteiten beschikbaar:
G11.1
- Functionaliteit m.b.t. logica, d.w.z. de controle van gegevensinvoer door middel van bedrijfs-
/meldingregels / validaties, waaronder ten minste:
▪ Singlefield bedrijfs-/meldingregels / validaties. Dit omvat ten minste ”maskers” (zoals gel-
dige datum, postcode, e-mailadres, BSN, etc. maar ook (alfa)numeriek, mini-/maximale
waarde, mini-/maximale lengte, etc.
G11.2
▪ Multifield bedrijfs-/meldingregels / validaties (d.w.z. dat sprake is van afhankelijkheid tus-
sen (de geregistreerde “waarden” van) twee of meer elementen op gegevensregistratie-
schermen / -formulieren).
G11.4
- Functionaliteit m.b.t. attendering aan gebruikers wanneer dergelijke logica “overtreden” wordt
- in voor gebruikers begrijpelijke taal, o.v.v. de element(en) waarop meldingen betrekking
hebben en de aard van de betreffende “overtreding(en)” - waaronder ten minste:
G11.5
▪ Attendering waarbij gebruikers niet verder kunnen tot de “overtreding” hersteld is (blokke-
rend).
G11.6
▪ Attendering waarbij gebruikers wel verder kunnen (deblokkerend; de attendering dient
slechts om aan te geven dat de geregistreerde gegevens onverwacht zijn).
G11.7
▪ Attendering waarbij gebruikers pas verder kunnen nadat zij daar expliciet voor gekozen
hebben (vereiste handeling zoals het afvinken van een checkbox, adviesaanvraag bij ex-
pert, etc.).
G11.8
Functionaliteit m.b.t. zogeheten intelligentie, d.w.z. dat gegevensregistratieschermen/-
formulieren a.h.w. “dynamisch” worden aangepast o.b.v. de geregistreerde gegevens (wizard-
functionaliteit zoals het overslaan/verbergen van veld(blokk)en, deelschermen / -formulieren,
vorige/volgende pagina, tabbladen, etc.).
G11.9
Burgers gebruiken dezelfde formulieren als medewerkers. Medewerkers kunnen dezelfde
webformulieren gebruiken bij andere kanalen (zoals telefoon, balie en post), inclusief de
mogelijkheid om DigiD-authenticatie over te kunnen slaan en te vervangen door zogeheten
„identificerend zoeken‟ (identificatie middels een aantal controlevragen zoals BSN en
geboortedatum/-plaats).
52
O9 Gegevensregistratie: gegevensregistratieschermen / -
formulieren (beheer)
Beschrijf de functionaliteit van de 3D-Suite m.b.t. het beheren van gegevensregistratieschermen /
-formulieren. Ga daarbij ten minste in op (voor zover van toepassing):
- De wijze waarop de structuur / lay-out - incl. de positionering van veld(blokk)en, “master-
/detailschermen”, etc. - en opmaak / huisstijl (zoals via stylesheets) worden gecreëerd, bij-
voorbeeld door middel van een integrated development engine (IDE) o.b.v. WYSIWYG, incl.
eventuele functionaliteit om van elk gegevensregistratiescherm / -formulier een printversie te
creëren (bijvoorbeeld voor postaanvragen).
- De wijze waarop eventuele logica en intelligentie, prefill, etc. worden aangebracht. Ga daarbij
ten minste in op (voor zover van toepassing):
▪ De wijze waarop logica, intelligentie en prefill worden gecreëerd (bijvoorbeeld via reguliere
expressies / scripting, m.b.v. wizards, etc.) en aangebracht, incl. het eventuele gebruik van
variabelen en de afhankelijkheid t.a.v. zaaktype, actuele status en/of andere condities.
▪ De mate waarin 3D-Suite-brede business rules kunnen worden gedefinieerd en beheerd
▪ De wijze waarop de meldingen bij het overtreden van logica vastgelegd worden, incl. het
bijbehorende onderscheid tussen de betreffende meldingtypen (zie G11).
- De wijze waarop snelkeuzelijsten (zie G10) worden beheerd en de verschillende bronnen die
hiertoe gebruikt kunnen worden, zoals: stam-/referentietabellen in de 3D-Suite, een externe
bron (bijv. BAG, het koppelpunt GeVS, etc.), “dynamische” lijst (bijvoorbeeld o.b.v. historie),
etc.
- Centrale vastlegging van elementen zoals veld(blokk)en (bijv. NAW), snelkeuzelijsten, etc.
voor gebruik in meerdere schermen / formulieren, incl. eventuele overerving (zodat wijzigin-
gen doorwerken in alle schermen / formulieren waarin elementen voorkomen) en functionali-
teit om inzichtelijk te maken op welke schermen / formulieren centraal vastgelegde elementen
gebruikt worden.
- Meegeleverde standaardcontent (uitputtende opsomming incl. beschrijving) in de vorm van
voorgedefinieerde (deel)schermen / -formulieren, veld(blokk)en, logica, snelkeuzelijsten, etc.
- Het beheer rondom dergelijke schermen / formulieren, incl. autorisaties (rechten en rollen)
dienaangaande, versiebeheer, agendering (zodat bijvoorbeeld een nieuwe (versie van een) be-
drijfsregel vanaf een bepaalde datum actief wordt), metadata, gebruik van templates en wi-
zards, etc.
- In welke mate en op welke wijze bovenstaande middels configuratie is ingericht in de 3D-Suite
(zoals via configuratie van zaak-/objecttypen in een zaak-/objecttypencatalogus).
- In welke mate en op welke wijze functioneel beheerders van Gemeenten bovenstaande volle-
dig zelfstandig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding),
in de 3D-Suite kunnen beheren, zoals via configuratie van zaak-/objecttypen in een zaak-
/objecttypencatalogus.
Maak daarbij voor zover van toepassing (dus indien verschillend) onderscheid tussen functionali-
teit voor medewerkers van Gemeenten enerzijds en overige gebruikers anderzijds. Indien de
functionaliteit hetzelfde is en/of gerealiseerd is met dezelfde technologie (bijvoorbeeld: hetzelfde
onderdeel van de 3D-Suite), dient dit expliciet vermeld te worden.
G12 Formulierverzending
G12.1
De 3D-Suite biedt functionaliteit voor het versturen van ingevulde webformulieren naar de
3D-Suite. Dit betreft ten minste de creatie van een PDF/A- en XML-bestand van het ingevulde
53
webformulier en het volledig geautomatiseerd kunnen versturen van een ontvangstbevesti-
ging aan de aanvrager. Indien het ingevulde webformulier niet kan worden afgeleverd aan
een broker / in een werkbak, wordt het ingevulde webformulier als PDF/A- en XML-bestand
naar een specifiek e-mailadres gestuurd.
G12.2
Een ingevuld formulier kan leiden tot N zaken.
O10 Overige functionaliteiten: gegevensregistratie
Beschrijf alle eventuele functionaliteiten op het gebied van gegevensregistratie (incl.
webformulieren) voor medewerkers en/of burgers die standaard onderdeel uitmaken van de 3D-
Suite en die naar uw mening in het kader van deze paragraaf relevant zijn, mede in het licht van
het beoogde gebruik van de 3D-Suite zoals beschreven in hoofdstuk 2. Denk in dat kader
bijvoorbeeld aan:
- Het gebruik van de webintakefunctionaliteit t.b.v. vraaggeleiding / beslisbomen.
- Formulierontwerp op basis van „What You See Is What You Get‟ (WYSIWYG).
- Het hergebruiken van reeds eerder ingediende formulieren.
- Geavanceerd formulierontwerp, zonder dat daarvoor programmeerkennis nodig is.
- Geavanceerd hergebruik van (delen van) webformulieren bij formulierontwerp.
- Geavanceerde validatiemogelijkheden (zoals look-up van achterliggende databases).
Geef tenslotte aan in welke mate en op welke wijze dit middels configuratie door Contractant is
ingericht in de 3D-Suite en in welke mate en op welke wijze functioneel beheerders van Gemeente
e.e.a. volledig zelfstandig -zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero
coding)- kunnen beheren.
4.3.4 (Management)rapportages
E4 (Management)rapportage: toegankelijkheid
T.b.v. ten minste (management)rapportage en selecties met behulp van 3P-toepassingen (zoals
BI tools) zijn alle gegevens die in c.q. door middel van de 3D-Suite worden beheerd en/of opge-
slagen volledig, in samenhang met elkaar en incl. historie gestructureerd toegankelijk voor lees-
acties (incl. exports), met inachtneming van de betreffende autorisaties (rechten en rollen).
S6. (Management)rapportage: exportmogelijkheden
Daartoe geautoriseerde gebruikers kunnen het resultaat van iedere zoekopdracht exporteren als
spreadsheet (csv of Excel), als pdf, en als print.
Tevens zijn door functioneel beheer van de gemeente aan te passen gedenormaliseerde dumpta-
bellen te exporteren als Excel-bestand.
O11 (Management)rapportage: algemeen (1P/2P)
Beschrijf de “eigen” (1P/2P) functionaliteit en grafische weergavemogelijkheden van de 3D-Suite
m.b.t. tot (management)rapportage. Ga daarbij ten minste in op (voor zover van toepassing):
54
Functionaliteit m.b.t. het creëren (ad hoc) en beheren van (management)rapportages en queries.
Ga daarbij bovendien ten minste in op de mogelijkheden ten aanzien van:
- Presentatiewijze (zoals taartdiagrammen, staafdiagram, tabellen, vrij te kiezen, etc.).
- Uitvoerwijzen zoals afdrukken, opslaan, exporteren (zoals CSV, XLS, XLSX), etc.
- Selecties en groepering per regio (buurt, stad)
- Selecties en groepering per type ondersteuning / dienst
- Overige selecties en groeperingen (per behandelaar, per uitvoeringsorganisatie, etc.)
- Periodiciteit (per dag, week, maand, kwartaal, jaar, vrij te kiezen, etc.)
- Het gebruik van functies zoals sorteringen, (sub)totalen, etc.
Beschrijf tevens de mate waarin gebruikers rapportages en queries zelfstandig kunnen creëren en
beheren, incl. de daartoe benodigde kennis (van programmeer-/scripttalen, SQL, etc.).
Beschrijf tenslotte (uitputtende opsomming) alle met de 3D-Suite meegeleverde standaardrappor-
tages, incl. een korte beschrijving (bijvoorbeeld: percentage gehaalde doelen per regio). Geef
daarbij aan of het realtime- en/of offline rapportages betreft en in hoeverre functioneel beheer-
ders en gebruikers van Gemeente én bij voorkeur de gebruikers deze zelfstandig kunnen aanpas-
sen.
O12 (Management)rapportage: algemeen (3P)
Zoals beschreven in E4 is databasetoegang mogelijk. Beschrijf of en zo ja welke ondersteuning u
daarbij biedt om betekenis te geven aan de gegevens: ten minste d.m.v. het bieden van correcte
en uptodate documentatie, doch bij misschien ook aanvullende opties zoals het bieden van BI-
view/universe/package/cube of vergelijkbaar voor Cognos, Crystal Reports, Business Objects, MS
SQL Reporting, oid.
4.4 Documenten en sjablonen
4.4.1 Inleiding (documenten)
Deze paragraaf bevat wensen en eisen t.a.v. de (generieke) functionaliteiten van de 3D-suite
m.b.t. opslag en beheer van documenten. Documentcreatie (par. 4.4.3) betreft functionaliteit om
documenten en e-mails te genereren o.b.v. sjablonen, m.b.v. zogeheten „samenvoegvelden‟.
Dossiervorming betreft functionaliteiten rondom het creëren en beheren van klantdossiers
bestaande uit zowel gegevens als documenten, incl. het registreren (CRUD) van documenten in
deze dossiers.
4.4.2 Basisfunctionaliteit
E5 Documenten: basisfunctionaliteit
De 3D-Suite biedt functionaliteit m.b.t. documenten, waaronder ten minste:
- Functionaliteit om [het zij via eigen (1P) functionaliteit, hetzij via een koppeling met de reeds
aanwezige sjabloontoepassing [merk, type]] documenten en e-mails te genereren o.b.v. voor-
55
gedefinieerde sjablonen, m.b.v. tags (samenvoegvelden, bijvoorbeeld %adres%).
- Functionaliteit m.b.t. dossiervorming en -beheer (zie par. 4.5.1), waaronder ten minste het
creëren en beheren (CRUD) van digitale documenten binnen het klantdossiers [in de eigen
(1P) documentopslagfaciliteit van de 3D-Suite / via een koppeling opgeslagen in het reeds
aanwezige zaaksysteem / DMS [merk, type, versie]] en documenten daarin (cf. RGBZ).
- [Functionaliteit m.b.t. archivering van zaken en bijbehorende zaakdossiers, incl. het uitoefenen
van het betreffende archiefregime daarop conform de betreffende archiefkenmerken.
/Functionaliteit om de juiste duiding te geven aan het RMA/archiefsysteem: zie par. 7.2]
- Beveiliging dienaangaande (zie hoofdstuk 6), waaronder ten minste autorisaties (rechten en
rollen) en auditing / logging (incl. protocollering) t.a.v. (handelingen m.b.t.) documenten en
zaak- en objectdossiers.
4.4.3 Documentcreatie en -opslag
O13 Documentcreatie (algemeen)
Beschrijf de functionaliteit van de 3D-Suite m.b.t. het genereren van documenten en e-mails [het
zij via eigen (1P) functionaliteit, hetzij via een koppeling met een 3P sjabloontoepassing (zie
G24)] op basis van voorgedefinieerde sjablonen m.b.v. zogeheten tags (samenvoegvelden zoals
%adres%). Ga daarbij ten minste in op (voor zover van toepassing):
- Hoe het genereren van documenten / e-mails o.b.v. sjablonen geschiedt door de tags ervan te
vullen met de overeenkomstige kenmerken uit de betreffende zaak / het betreffende object
(„parameters‟ t.b.v. documentcreatie) en/of eventuele andersoortige gegevens (zoals d.m.v.
vrije tekst en/of snelkeuzelijsten), incl. de eventuele handelingen die gebruikers daartoe die-
nen uit te voeren.
- Of aldus gegenereerde documenten / e-mails eerst nog als concept getoond worden, ter con-
trole en eventuele handmatige aanpassing door gebruikers (incl. het gebruik van spellingcon-
trole).
- Of aldus gegenereerde documenten / e-mails (m.u.v. uittreksels en afschriften) volledig geau-
tomatiseerd (en zo niet: welke handelingen gebruikers daartoe moeten uitvoeren) opgenomen
worden in het betreffende zaak-/objectdossier en in welk(e) bestandsforma(a)t(en).
- De mate waarin en de wijze waarop de betreffende documentkenmerken („metadata‟) volledig
geautomatiseerd - bijv. via overerving uit de betreffende context (zaak/object) - dan wel
(deels) handmatig worden vastgelegd, incl. eventuele handelingen die gebruikers daartoe
moeten uitvoeren.
G13 Documenten toevoegen
G13.1
De 3D-Suite biedt functionaliteit waarmee gebruikers via een knop „bladeren‟ handmatig één
of meer documenten kunnen toevoegen aan een reeds bestaande zaak (dossier). Dezelfde
functionaliteit is beschikbaar middels „drag & drop‟ vanuit de boomstructuur van het bestu-
ringssysteem. Op te voeren documenten kunnen zich in beide gevallen zowel op een centrale
schijf (netwerk) als op een eventuele lokale schijf (werkstation) schijf bevinden.
G13.2
Bovendien biedt de 3D-Suite functionaliteit welke, bij het toevoegen van documenten aan een
traject- of klantdossier, eventuele relaties tussen documenten (zoals een hoofddocument met
56
één of meer bijlagen) behouden laten blijven.
G13.3
Bij het toevoegen van een document aan een traject- of klantdossier dient alle daarbij ver-
plichte metadata (zoals documenttype en documentattributen, en de naam, rol en organisatie
van de persoon die het opvoert) te worden ingevoerd. Het eventuele verplichte karakter van
metadata is gedefinieerd in de zaaktypeconfiguratie van het betreffende zaaktype.
O14 Documentcreatie (beheer)
[Beschrijf de eigen (1P) functionaliteit van de 3D-Suite m.b.t. het beheren van de functionaliteit
t.a.v. documentcreatie als bedoeld in O13, incl. beheer (CRUD) van de sjablonen. Ga daarbij ten
minste in op (voor zover van toepassing):
- De wijze waarop de inhoud van sjablonen wordt gecreëerd, incl. het koppelen van de tags met
de overeenkomstige bronnen (attributen in het datamodel van de 3D-Suite).
- De wijze waarop de structuur en huisstijl van sjablonen wordt gecreëerd - bijvoorbeeld in een
integrated development engine (IDE) o.b.v. WYSIWYG - c.q. toegepast (zoals m.b.v. styles-
heets).
- De wijze waarop sjablonen worden gekoppeld aan de functionaliteit die ze aanroept (wanneer
welk sjabloon wordt aangeroepen en met welke parameters).
- Centrale vastlegging van elementen zoals veld(blokk)en (bijv. NAW) voor gebruik in meerdere
sjablonen, incl. eventuele overerving (zodat wijzigingen doorwerken in alle sjablonen waarin
het element voorkomt).
- Het beheer rondom sjablonen, incl. autorisaties (rechten en rollen, zie hoofdstuk 8) dienaan-
gaande, versiebeheer, metadata, gebruik van templates en wizards, etc.
- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in de
3D-Suite.
- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-
standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen
beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus).
Beschrijf bovendien de eventueel meegeleverde standaardcontent: een uitputtende opsomming
van voor het 3D-domein relevante voorgedefinieerde sjablonen, incl. toelichting of er updates van
worden verstrekt, of het sjabloon kan worden gebruikt voor het genereren van zowel documenten
als e-mails, etc.]
[Beschrijf de functionaliteit van de 3D-Suite m.b.t. het beheren van de functionaliteit t.a.v. docu-
mentcreatie als bedoeld in O13, v.w.b. de „mapping‟ tussen velden in de 3D-Suite en de sjablo-
nen. Ga daarbij ten minste in op (voor zover van toepassing):
- De wijze waarop de tags met de overeenkomstige bronnen (attributen in het datamodel van de
3D-Suite, zoals burgergegevens).
- De wijze waarop sjablonen worden gekoppeld aan de functionaliteit die ze aanroept (wanneer
welk sjabloon wordt aangeroepen en met welke parameters).
- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in de
3D-Suite.
- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-
standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen
beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus).]
57
4.4.4 [Archivering]
Documenten worden opgeslagen in de documentopslag, maar de regie daarop ligt v.w.b. metadata
en archiefkenmerken volledig bij de 3D-Suite. Deze documentopslag is v.w.b. gebruik en
functioneel volledig geïntegreerd in de 3D-Suite; gebruikers ervaren geen scheiding tussen de 3D-
Suite en de documentopslag. Als gevolg van deze integratie met het zaaksysteem maken
zaakdocumenten altijd deel uit van een (klant-/zaak)dossier en worden de metadata van een
document door het zaaksysteem bepaald (goeddeels via „overerving‟ uit het zaaktype en de zaak,
deels via het documenttype).
De archiefkenmerken (zoals bewaar- en vernietigingstermijn ten behoeve van archivering) worden
door middel van configuratie in de ZTC2.0+ per zaaktype bepaald. Hiermee is archivering en
ontsluiting van elektronische dossiers, documenten en processen mogelijk ten behoeve van een
digitaal archief conform de Archiefwet en de Archiefregeling, alsook de Wet Bescherming
Persoonsgegevens en overige privacy-wetgeving.
Een zaak krijgt bij ontstaan automatisch de archiefkenmerken van het betreffende zaaktype. Nadat
een zaak is afgehandeld wordt deze, conform deze archiefkenmerken, automatisch gearchiveerd
[in het reeds bestaande zaaksysteem]. Hierbij is het archiefregime van toepassing op zaakniveau.
Dit betekent dat zowel de gestructureerde (attributen, etc.) als ongestructureerde (documenten
incl. e-mails, aantekeningen, etc.) informatie van de zaak wordt meegenomen in de archivering.
Daarnaast krijgen alle gegevens van de zaak dezelfde bewaar- en vernietigingstermijn (een enkele
uitzondering daargelaten). Zaken kunnen uiteindelijk, voor langdurige opslag, worden
overgedragen aan het statische (digitale) archief / e-depot.
O15 Archivering
Beschrijf de functionaliteit van de 3D-Suite -systeem m.b.t. het archiveren van zaken, (zaak- en
object)dossiers en documenten daarin. Ga daarbij ten minste in op (voor zover van toepassing):
- Vernietigen van signalen, meldingen
- Bepalen vernietigtermijn per zaaktype, zaak en documenttype (kladjes mogen over jaar weg;
besluiten dienen langer te worden bewaard, etc.)
- Adequate beveiliging van opslag, ontsluiting en eventuele overdracht.
- De precieze wijze en „locatie‟ waarop zaken gearchiveerd worden (d.w.z. dat de zaak en alle
bijbehorende informatie wordt „bevroren‟ en er geen mutaties meer „in‟ de zaak kunnen plaats-
vinden). Maak daarbij onderscheid tussen de verschillende typen informatie die aldus „bevro-
ren‟ worden, waaronder ten minste gegevens, documenten in het betreffende zaakdossier en
het logbestand van de zaak (wie heeft wanneer wat toegevoegd, ingezien, gewijzigd, verwij-
derd), alsmede tussen handmatige (gebruikers-) en geautomatiseerde (systeem)handelingen.
Beschrijf tenslotte of daarna nog mutaties „op‟ zaken kunnen plaatsvinden (zoals registratie
van notities).
- De wijze waarop het archiefregime (bewaar- en vernietigingstermijnen) wordt uitgeoefend
o.b.v. de betreffende archiefkenmerken en de wijze waarop deze worden afgeleid, bijvoorbeeld
volgens de principes van de GEMMA ZTC 2.0 (incl. ingangsmoment, het geselecteerde resul-
taattype en de eventuele aanwezigheid van gerelateerde, deel- en/of vervolgzaken), uit het
documenttype, etc. Beschrijf daarbij ook of alle typen informatie (gegevens, documenten, etc.)
noodzakelijk dezelfde archiefkenmerken krijgen of dat er daarin differentiatie kan plaatsvin-
den, en zo ja op welke wijze (zoals o.b.v. documenttype). Maak daarbij steeds onderscheid
tussen handmatige (gebruikers-) en geautomatiseerde (systeem)handelingen.
58
- De wijze waarop daadwerkelijke vernietiging van zaken, objecten, documenten en (klant-,
zaak- en object)dossiers plaatsvindt, incl. of en zo ja hoe daarvan registratie plaatsvindt. Maak
daarbij onderscheid tussen handmatige (gebruikers-) en geautomatiseerde (sys-
teem)handelingen.
- Autorisaties (rechten en rollen, zie hoofdstuk 8) dienaangaande, ten minste t.a.v. (handelingen
m.b.t.) archiveren en vernietigen.
- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in de
3D-Suite (zoals via configuratie van zaaktypen in een zaaktypencatalogus).
- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-
standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen
beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus).
59
4.5 Medewerkerportaal en werkbak
4.5.1 Signaleringen en contacten
S7. Signalen en meldingen
In het medewerkerportaal is een overzicht van signalen en meldingen, inclusief
- Datum en tijdstip
- Betrokken organisaties (uitvoeringsorganisatie, ketenpartner, etc.)
- Betrokkenen (medewerkers, burgers, etc.)
- Inhoudelijke informatie
- Bron (nuldelijns / eerstelijns / tweedelijns én inwoner, arts, wijkverpleging, etc.)
- Duiding van prioriteit
- Duiding vertrouwelijkheid
- Functionaliteit om een signaal om te vormen naar een melding
- Functionaliteit om een groep signalen om te vormen naar een melding
O16 Contactmomentregistratie, notulen en reminders
Beschrijf de functionaliteit van (de medewerkerportaal van) de 3D-Suite m.b.t. de registratie van
„klantcontact‟ (zoals contactmomenten en terugbelverzoeken), ongeacht het kanaal (dus voor zo-
wel inkomende als uitgaande communicatie). Maak hierbij onderscheid tussen „klantcontacten‟ als
een zelfstandige entiteit (dus onafhankelijk van een specifieke zaak) en contactregistratie bij za-
ken. Beschrijf wat er daarbij (bij voorkeur cf. RGBZ) geregistreerd kan worden, zoals:
- Betrokken organisaties (uitvoeringsorganisatie, ketenpartner, etc.)
- Betrokkenen (medewerkers, burgers, etc.)
- Inhoudelijke informatie als vrije tekst
- Kanalen (bijv. of wordt gebeld, het een e-mail betreft, of anders)
- Datum en tijdstip
- Etc.
Ga bovendien in op de mate waarin en de wijze waarop klantcontacten die een actie vereisen
kunnen worden vastgelegd, bewaakt en behandeld/afgehandeld en hoe een gebruiker een remin-
der (incl. notitie) kan zetten op een bepaalde datum of na een bepaalde termijn waarbij het „af-
gaan‟ van de reminder een notificatie veroorzaakt in de werkomgeving in de 3D-Suite.
Beschrijf daarbij het bedieningsgemak en -snelheid van de betreffende functionaliteit (zowel regi-
stratie als afhandeling), incl. de mate waarin informatie automatisch kan worden ingevuld of ge-
suggereerd (zoals o.b.v. e-mailadres, BSN, context, etc.). Geef bovendien aan of, en zo ja hoe,
een medewerker dergelijke klantcontacten kan zoeken (zoals op burger, wijk, datum, etc.) en in-
zien en of en hoe een klantcontact dat via het gemeentelijke KCC binnenkomt wordt doorgegeven
aan de 3D-Suite.
Geef tenslotte aan in welke mate en op welke wijze dit middels configuratie door Contractant is
ingericht in de 3D-Suite en in welke mate en op welke wijze functioneel beheerders van
Gemeente e.e.a. volledig zelfstandig -zonder dat daarvoor geavanceerde programmeerkennis
nodig is (zero coding)- kunnen beheren. Bijvoorbeeld door een klantcontact als mini-zaak in te
richten.
60
4.5.2 Filteren en sorteren
O17 Filteren en sorteren
Beschrijf de functionaliteiten van de 3D-Suite met betrekking tot filteren en sorteren van signale-
ringen, burgers, zaken en documenten op (combinaties van) bepaalde waarden van velden /
metadata. Denk in dat kader bijvoorbeeld aan:
- Bij signaleringen: belang, bron, beschrijving, betrokkenen, etc.
- Bij burgers: gegevens zoals naam, adres, woonplaats, wijk, leeftijd, etc., maar bijvoorbeeld
ook of de persoon of het gezin betrokken is bij bepaalde zaken.
- Bij zaken: zaakattributen (zoals zaaktype, status, betrokkenen, etc.) maar bijvoorbeeld ook
aan zaken/taken met overschreden doorlooptijd, etc.
- Bij documenten: naam, maar ook documentattributen / metadata (zoals auteur, documentty-
pe, etc.).
Geef hierbij bovendien steeds aan binnen welke context deze functionaliteit kan worden aange-
sproken en de wijze waarop het resultaat wordt gepresenteerd.
Geef aan of het mogelijk is om op alle mogelijke velden te sorteren en te filteren. Geef ten slotte
ook of en zo ja op welke wijze(n) veelgebruikte filters, groeperingen en sorteringen kunnen wor-
den opgeslagen ten behoeve van hergebruik.
4.5.3 Beslisondersteuning en vraagverheldering
O18 Zelfredzaamheidsmatrix, participatieladder, en vergelijkbare hulpmiddelen
Beschrijf de functionaliteit die de 3D-Suite biedt om een Zelfredzaamheidsmatrix,
Participatieladder11 en/of vergelijkbare beslisondersteuning te gebruiken. Geef aan of hierbij ten
minste per domein een classificering (1-5, of vergelijkbaar) en een onderbouwing is te geven via
opmerkingen en documenteren, alsook of en hoe de verbetering of verslechtering in de tijd kan
worden weergegeven.
Geef daarbij aan of in aanvulling daarop een beslisboom kan worden ingericht en gebruikt ter
bepaling van de classificering en bespreek of en hoe het is uit te breiden, bijv. door het
Onderwijs-domein toe te voegen aan de Zelfredzaamheidsmatrix.
Geef tenslotte aan of en hoe de Zelfredzaamheidsmatrix-classificeringen (of vergelijkbaar)
gevisualiseerd kunnen worden bij een klantdossier en hoe een duiding kan worden gegeven van
verslechtering van de situatie van de burger (bijv. via een signalering).
O19 Beslisbomen
Beschrijf de functionaliteit van de 3D-Suite m.b.t. ondersteuning van gebruikers middels beslis-
bomen, incl. vraagverheldering. Ga daarbij ten minste in op (voor zover van toepassing):
- De wijze waarop beslisbomen gepresenteerd worden (binnen 3D-Suite en/of daarbuiten) aan
gebruikers en hoe zij die invullen, incl. de beschikbare vraagvormen (zoals radiobuttons, drop-
down-/picklists, etc.). Beschrijf ook of de uitkomst kan leiden tot geautomatiseerde acties van
3D-Suite (zoals het starten van processen met specifieke parameters, bijv. t.b.v. bieden van
bepaalde diensten / ondersteuning bij bepaalde ketenpartners).
11 www.zelfredzaamheidmatrix.nl resp. www.participatieladder.nl
61
- De wijze waarop beslisbomen worden gecreëerd en beheerd (CRUD). Ga daarbij ten minste in
op (voor zover van toepassing):
▪ De wijze waarop beslisbomen worden gecreëerd.
▪ De wijze waarop wordt aangegeven in welke context beslisbomen worden gebruikt.
▪ Centrale vastlegging van vragen / rules t.b.v. beslisbomen, zodat wijzigingen doorwerken in
alle beslisbomen waarin deze voorkomen.
▪ Het beheer rondom beslisbomen, incl. autorisaties (rechten en rollen), versiebeheer, etc.
▪ Meegeleverde standaardcontent (uitputtende opsomming incl. een beschrijving) in de vorm
van voorgedefinieerde (vragen / rules t.b.v.) beslisbomen.
- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in 3D-
Suite (zoals via configuratie van zaaktypen in een zaaktypencatalogus).
- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-
standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen
beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus).
O20 Checklists
Beschrijf de functionaliteit van de 3D-Suite m.b.t. ondersteuning van gebruikers door middel van
checklists cf. ZTC 2.0. Ga daarbij ten minste in op (voor zover van toepassing):
- De wijze waarop checklists gepresenteerd worden binnen de 3D-Suite aan gebruikers en hoe
zij die afvinken. Beschrijf ook of de uitkomst kan leiden tot geautomatiseerde acties van de
3D-Suite (zoals het genereren van documenten met specifieke parameters).
- De wijze waarop checklists worden gecreëerd en beheerd (CRUD). Ga daarbij ten minste in op
(voor zover van toepassing):
▪ De wijze waarop checklists worden gecreëerd.
▪ De wijze waarop wordt aangegeven in welke context checklists worden gebruikt en of deze
leiden tot geautomatiseerde acties van de 3D-Suite.
▪ Centrale vastlegging van vragen t.b.v. checklists, zodat wijzigingen doorwerken in alle
checklists waarin deze voorkomen.
▪ Het beheer rondom checklists, incl. autorisaties (rechten en rollen), versiebeheer, etc.
▪ Meegeleverde standaardcontent (uitputtende opsomming incl. een beschrijving) in de vorm
van voorgedefinieerde (vragen t.b.v.) checklists.
- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in de
3D-Suite.
- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-
standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen
beheren.
O21 [Externe informatie- / kennisbronnen]
Beschrijf de functionaliteit van de 3D-Suite m.b.t. ondersteuning van gebruikers door middel van
raadpleging van en eventuele interactie met in- en externe informatie- / kennisbronnen (binnen
resp. buiten Gemeente). Ga daarbij ten minste in op (voor zover van toepassing):
- Interne kennisbronnen van Gemeente, zoals:
Het extranet ([merk, type, versie], zie de betreffende specificaties in bijlage [XX]).
De gemeentelijke PDC ([merk, type, versie], zie de betreffende specificaties in bijlage
[XX]).
Eventuele overige informatie- / kennisbronnen waarmee een standaardkoppeling wordt
62
meegeleverd (dus inbegrepen bij de prijsopgave (zie ####) en als zodanig zonder additio-
nele kosten „off-the-shelf‟ beschikbaar), incl. toelichting (merk, type, versie(s), functionali-
teit, etc.).
- Externe kennisbronnen buiten Gemeente, zoals:
Naslagwerken / handleidingen m.b.t. toepassing van Nederlands en vreemd recht.
[…]
Eventuele overige externe informatie- / kennisbronnen waarmee een standaardkoppeling
wordt meegeleverd (dus inbegrepen bij de prijsopgave (zie ##) en als zodanig zonder addi-
tionele kosten „off-the-shelf‟ beschikbaar), incl. toelichting (merk, type, versie(s), functio-
naliteit, etc.). Denk bijv. aan informatie-/kennisbronnen van het Ministerie zoals ###.
Beschrijf daarbij steeds ten minste (voor zover van toepassing):
- Op welke manier een match gemaakt wordt met de burger (ten minste per gezinslid, waarbij
wordt gezocht op BSN)
- Binnen welke context de betreffende functionaliteit kan worden gebruikt, incl. eventuele „con-
textgevoeligheid‟ (zoals: wordt er gelinkt naar de homepage van een informatie-/kennisbron
(gebruikers moeten vervolgens verder zoeken) of naar een in de betreffende context relevant
element?).
- De wijze waarop de betreffende informatie-/kennisbron gepresenteerd wordt aan gebruikers
- Of en zo ja hoe daarbij sprake is van gegevensuitwisseling (incl. welke gegevens en of gebrui-
kers daartoe nog handelingen dienen te verrichten), dan wel of het slechts een URL-koppeling
betreft.
- Of er op de betreffende kennisbron nog apart ingelogd dient te worden (indien van toepassing)
of dat er sprake is van single sign-on (SSO).
- In welke mate de koppeling kan worden onderworpen aan autorisaties (rechten en rollen), zo-
als dat informatie alleen ingezien kan worden als de ingelogde gebruiker daar autorisatie toe
heeft.
- De flexibiliteit (mate van aanpasbaarheid) van de betreffende koppeling, incl. de mate waarin
dit door middel van configuratie (paramaters) kan worden gerealiseerd. Beschrijf daarbij te-
vens in welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig
zelfstandig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding),
kunnen beheren.
NB: Met „context‟ wordt hier gedoeld op de plaatsen / momenten waarop deze functionaliteit kan
worden gebruikt, zoals in de werklijst, detailschermen, etc.
4.5.4 Dienstenboek (product- dienstencatalogus)
Diensten kunnen allerhande diensten van derden betreffen: het UWV, schuldhulp maar ook oppas-
oma‟s. Diensten worden gezamenlijk door regisseur en burger gekozen, bijvoorbeeld met een
persoonsgebonden budget in het achterhoofd.
S8. Dienstenboek
De 3D-Suite bevat een product-dienstencatalogus / kennisbank met ten minste de volgende func-
tionaliteiten:
- Weergave en beheer van beschikbare producten en diensten, incl. levensgebied, vrije tekstvel-
den, URL, betrokken uitvoeringsorganisaties, kosten per voorziening (intern, extern), overige
63
aandachtspunten
- Weergave en beheer van per product en dienst ketenpartners die de dienst kunnen leveren.
De 3D-Suite biedt functionaliteit voor het aanbieden van een overzichtsweergave van beschikbare
producten en diensten, in meerdere varianten van groepering en sortering. Beschikbare weerga-
ven zijn ten minste op alfabet, op doelgroep en op thema.
Gebruik van rechten en rollen: een regisseur mag meer zien dan een uitvoeringsorganisatie (die
bijv. géén bedragen mag zien), die weer meer kan zien dan een burger (die overige nader te
bepalen velden niet kan zien).
S9. Contentbeheer dienstenboek
De 3D-Suite biedt functionaliteit voor het creëren, beheren en publiceren van informatie over pro-
ducten en diensten, inclusief versiebeheer, metadatering, opmaak (vormgeving) en structuur (na-
vigatie) van deze content.
Als de gemeente een abonnement heeft op standaard-content kan per dienst en per blok content
daarbinnen (bijv.: prijsinformatie) een update van de feed worden gebruikt, of kan de gemeente
er voor kiezen voor dat blok juist afwijkende content zelf op te nemen en te beheren.
S10. Integrale medewerkersportaal-inzage en zoeken in externe dienstenboeken, VAQ,
FAQ
De 3D-Suite biedt standaard koppelvlakken (batch, bijv. via ETL) waarmee diensteninformatie én
de kennisbank-informatie (VAC, FAQ, anderszins) van uitvoeringsorganisaties ingelezen kan wor-
den in de 3D-Suite zodat het medewerkersportaal de beschikking heeft over alle content, zowel
intern als van uitvoeringsorganisaties, volledig in de interface van de 3D-Suite (dus zonder alt-tab
en zonder (portlet/iframe-)interfaces van externe software.
Op deze wijze is integraal zoeken in content (dienstenboeken, FAQ en VAC) mogelijk, dus zonder
de zoekvraag in meerdere zoekboxen (per uitvoeringorganisatie) opnieuw te moeten ingeven.
O22 Medewerkersportaal: inzage en zoeken in externe dienstenboeken, VAQ, FAQ
Beschrijf de functionaliteit van de (koppelvlakken van de) 3D-Suite ten behoeve van het mede-
werkersportaal in het kader van content die door uitvoeringsorganisaties aangeboden wordt.
Indien de koppelvlakken alleen content overbrengen, beschrijf de wijze waarop dit gebeurt.
Indien de koppelvlakken werken op een andere wijze, beschrijf tevens hoe dit gebeurt, bijv. met
portlets of i-frames (dus middels de webbased grafische gebruikersinterface van de externe soft-
ware) en beschrijf de voorzieningen omtrent SSO om dit goed te laten werken. Ga tevens in of en
zo ja hoe integraal zoeken tot stand wordt gebracht, dus zonder de zoekvraag in meerdere zoek-
boxen (per uitvoeringorganisatie) opnieuw te moeten ingeven.
4.5.5 Zoeken
E6 Autorisaties bij zoeken
De 3D-Suite biedt functionaliteit waarmee bij zoeken en filteren in de 3D-Suite autorisaties geres-
64
pecteerd worden. Dat wil zeggen dat hierbij uitsluitend resultaten worden gepresenteerd waarvoor
de betreffende gebruiker in de 3D-Suite is geautoriseerd.
O23 Zoeken: algemeen
Beschrijf de functionaliteit van de 3D-Suite m.b.t. zoeken. Ga daarbij ten minste in op (voor zover
van toepassing):
- Welke bronnen (uitputtende opsomming) door middel van zoekopdrachten vanuit de 3D-Suite
doorzocht worden, zoals:
▪ Welke typen gegevens in de 3D-Suite zelf.
▪ Zowel de inhoud als de documentattributen (metadata) van documenten in de documentop-
slagfaciliteit [van het DMS/zaaksysteem.][Ga daarbij ook in op ondersteund bestandsforma-
ten, incl. indexatie- en zoekmethoden (zoals “full-text”).]
▪ Interne bronnen zoals GBA,
▪ Verwijsindices zoals VIR,
▪ Gegevens die beschikbaar zijn via het koppelpunt GeVS,
▪ etc.
- Welke van de aldus benoemde bronnen door middel van zoekopdrachten vanuit de 3D-Suite in
combinatie (dus met één en dezelfde zoekopdracht) doorzocht kunnen worden, al dan niet incl.
relaties tussen resp. binnen deze bronnen (zaken i.r.t. objecten, zaken resp. objecten onder-
ling, etc.).
- De mate waarin bij zoeken rekening gehouden wordt met autorisaties (rechten en rollen), zo-
dat alleen zoekresultaten worden getoond waarvoor de betreffende gebruiker is geautoriseerd.
- Functionaliteit die ervoor zorgt dat gebruikers bij zoeken een goede gebruiksvriendelijkheid
(zoals: een melding als bij zoeken op BSN een ongeldig BSN wordt ingegeven) en performance
ervaren.
G14 Zoeken: geavanceerd
G14.1
De 3D-Suite biedt functionaliteit m.b.t. zoeken waarbij gebruikers zowel vrije (d.m.v. eigen in-
voer) als gestructureerde (d.m.v. selecties uit één of meer dropdown-/picklists) zoekopdrachten
van één of meer “velden” (tekst, categorieën, datum, waarde / bereik, etc.) kunnen “samenstel-
len” om te zoeken in de 3D-Suite. Daarbij is bovendien ten minste onderstaande functionaliteit
beschikbaar:
G14.2
- Het gebruik van zowel enkelvoudige (bijvoorbeeld “Jansstraat”) als samengestelde (bijvoor-
beeld “klachten Jansstraat”) zoektermen.
G14.3
- Het gebruik van zogeheten booleaanse operatoren (ten minste EN, OF, NIET, etc.).
G14.4
- Het gebruik van zogeheten wildcards voor één of meer karakters.
G14.5
- (On)gevoeligheid t.a.v. hoofdletters en diakrieten (z.d.d. zoeken op bijv. Dhr. Sirac en siraç
dezelfde resultaten worden gegeven).
G14.6
- Auto-aanvullen / instant zoeken zodat bij het invoeren van de eerste letter van de zoekterm de
eerste zoekresultaten al getoond worden en er, naarmate er meer letters van de zoekterm
65
worden ingevoerd, steeds minder zoekresultaten overblijven.
G14.7
- Ondersteuning van fuzzy logic (gelijkende woorden, vgl. “bedoelde u …”).
G14.8
- Ondersteuning van synoniemen (gelijkende betekenissen).
G14.9
- De mogelijkheid om met een nieuwe zoekopdracht - incl. alle betreffende functionaliteiten -
verder te zoeken in de zoekresultaten (zoekresultaten verfijnen).
G14.10
- De mogelijkheid om (zowel enkelvoudige als en samengestelde) zoekopdrachten op te slaan
als zogeheten snelzoekopdracht (t.b.v. hergebruik).
G15 Zoeken: zoekresultaten
G15.1
De 3D-Suite biedt functionaliteit zodat zoekresultaten worden gepresenteerd op basis van zo-
geheten relevance ranking.
G15.2
Wanneer er sprake is van relaties tussen zoekresultaten, dan worden deze in samenhang (ge-
groepeerd) gepresenteerd (zoals gezinsleden, eerdere zaken van dezelfde burger, etc.).
G15.3
Zoekresultaten kunnen door gebruikers middels kolommen zowel op- als aflopend worden ge-
sorteerd op ten minste alfabet, datum en relevantie, waarbij gebruikers de kolommen van de
resultatenlijst voorafgaand aan de zoekopdracht zelf kunnen bepalen (aanpassen van de
standaardsamenstelling).
G15.4
Daarbij worden zoekresultaten gepresenteerd inclusief een samenvatting rondom de zoek-
term(en) waarop is gezocht (waarbij de zoekterm(en) is/zijn gemarkeerd) en een link naar de
gevonden zaken, documenten, objecten, personen, etc.
G15.5
Gebruikers kunnen via die link vanuit de zoekresultaten doorklikken naar de gevonden zaken,
documenten, objecten, personen, etc. waarbij documenten in een eigen, geïntegreerde viewer
binnen de 3D-Suite worden getoond.
4.5.6 Kalenderfunctionaliteit
O24 Inplannen afspraken
Beschrijf de mogelijkheden die de 3D-Suite heeft voor het inplannen van een afspraak tussen
burger en medewerker en de mate van flexibiliteit daarbij, incl. het sturen van een uitnodiging
aan de burger(s).
In welke mate wordt een regisseur bijvoorbeeld ondersteund bij het inplannen van periodieke
bezoeken (controles) bij een burger – en kunnen hier ad-hoc afwijkingen op worden ingericht?
Beschrijf tevens de mate van integratie met de kalender van de medewerker ([merk, type, ver-
sie]). Maak daarbij zo nodig onderscheid tussen registratie door interne medewerkers en externen
66
zoals bij een uitvoeringsorganisatie, of de burger zelf.
O25 [Inplannen cursussen]
Beschrijf de mogelijkheden die de 3D-Suite heeft voor het inplannen van cursussen ter onder-
steuning van (groepen van) burgers. Denk daarbij aan:
- Uitnodigen van burgers en groepen burgers
- Inschrijffunctionaliteit voor de burgers
- Aanwezigheidscontrole t.b.v. facturatie
- Wachtrijen voor volgende cursussen
- Etc.
G16 Inplannen afspraken casusoverleg (al dan niet online)
G16.1
- T.b.v. casusoverleg kunnen zowel reguliere als ad-hoc afspraken worden ingepland tussen
groepen medewerkers.
G16.2
- Daarbij worden uitnodigingen verstuurd aan betrokken partijen.
G16.3
- Er is agendafunctionaliteit aanwezig om te controleren of intern betrokkenen aanwezig kunnen
zijn. Voor overige personen wordt een uitnodiging gestuurd.
G16.4
- Er kunnen vaste periodieke tijdsblokken gebruikt worden voor regulier (casus)overleg voor be-
paalde groepen gebruikers zoals een wijkteam.
G16.5
- [Daarbij is sprake van éénwegsynchronisatie van de 3D-Suite naar de agenda van betrokken
interne medewerkers ([merk, type, versie])] / [Daarbij is sprake van tweewegsynchronisatie
met de agenda van betrokken interne medewerkers ([merk, type, versie])]
O26 Gerealiseerde uren [optie]
Het is denkbaar dat op termijn ook een registratie wordt bijgehouden van gerealiseerde uren.
Geef aan in hoeverre de 3D-Suite het (achteraf na een bezoek) registreren van de hoeveelheid
bestede tijd per burger en zaak ondersteunt.
Maak daarbij zo nodig onderscheid tussen registratie door interne medewerkers en externen zoals
bij een uitvoeringsorganisatie, of de burger zelf.
67
4.5.7 Financiën en overige regie op regie
G17 Vastleggen financiële afspraken
- Per ondersteuningsplan en per deelzaak (dienst/maatregel) worden ten minste geaggregeerde
bedragen bijgehouden (budget per plan), alsook de feitelijke realisatie
- Per ondersteuningsplan en per deelzaak (dienst/maatregel) wordt een tijdplan bijgehouden,
alsook de feitelijke realisatie
- Bewaking van persoonsgebonden budgetten is mogelijk (ten minste o.b.v. handmatig bij ge-
houden invulvelden)
O27 Verantwoording
Beschrijf de mate waarin door de 3D-Suite ondersteuning wordt geboden bij de financiële en in-
houdelijke verantwoording van geleverde ondersteuning, denk daarbij aan:
- Het verloop van een zaak / ondersteuningsplan: acties x doorlooptijd x doelen x kosten &
schatting
- Naast doorlooptijd ook doelbudget / deelbudget
- Per doel en maatregel (~deelzaak): geld en tijd
- Gebruik van KPI‟s, zowel automatisch uit systeem gegenereerd als handmatig verzameld.
Denk aan normtijden, behaalde resultaten (bijv. ZRM-scores per regio), caseloads, budgetten.
- Persoonsgebonden budget per periode (ten minste o.b.v. handmatig bijgewerkte vel-
den/notities doch bij voorkeur incl. kosten cf. dienstenboek)
- Uitputting persoonsgebonden budget, incl. bijhouden van bewijzen (scans van facturen) van
door de burger gemaakte kosten
- Wijk- of afdelingsbudget per jaar en de uitputting ervan (ten minste o.b.v. handmatig bijge-
werkte velden/notities), bij voorkeur incl. geschreven uren (zie vorige paragraaf).
Geef tevens of u nu of in een volgende release ondersteuning biedt voor financiële budgettering,
regie en monitoring – inclusief langetermijnplanning en –budgettering aanvullend op bestaande
3P financiële/ERP-functionaliteit.
O28 Overige functionaliteit voor regie op regie
Beschrijf de mate waarin de 3D-Suite ondersteuning biedt voor het vastleggen en bewaken van
financiële afspraken met uitvoeringsorganisaties en burgers.
Denk daarbij aan
- Registreren inhoudelijke en financiële afspraken (gerelateerd aan een specifieke zaak / taak) in
een document vastleggen tussen regisseur en UO. Deze communicatie is daarbij vanzelfspre-
kend enkel inzichtelijk voor de gemeentelijke regisseur en managers.
- (bij voorkeur door middel van een deelzaak) een fiat vragen / krijgen via een manager, wan-
neer nader te bepalen dure of afwijkende diensten een akkoord behoeven.
- Tijdens het samenstellen van een ondersteuningsplan een offerte met calculatie opvragen[ in-
cl. eventuele mogelijkheden om gebruik te maken van veilingen].
O29 Overige functionaliteit voor regie op regie
Geef eventuele overige standaard out of the box aanwezige functionaliteiten op het gebied van
regie-op-regie, mede in het licht van het beoogd gebruik zoals beschreven in hoofdstuk 2.
Denk daarbij aan bijvoorbeeld:
68
- Bewaking van budget, deelbudget, aantallen beschikbare rolstoelen/adviesuren/ etc. incl. visu-
alisatie en monitoring daarbij.
- Offertes met calculatie opvragen t.b.v. vulling van het dienstenboek
- Overige ondersteuning van inkoop van diensten, alsook monitoring van diensten en betalen
ervan.
- Eventueel gebruik van elektronische berichten daarbij, zoals AW-berichten.
- Etc.
4.5.8 Medewerkerportaal voor gebruikers buiten de gemeente
S11. Toegang t.b.v. zaken en klantinformatie voor de uitvoeringsorganisaties
De 3D-Suite bevat een portal of vergelijkbaar die de uitvoeringsorganisaties toegang geeft tot alle
klantcontacten, lopende en afgesloten zaken van de Gemeente die aan haar organisatie zijn ge-
koppeld/toegewezen, voor zover de betreffende persoon daartoe is geautoriseerd.
In deze portal kan de uitvoeringsorganisatie ten minste lopende (deel)zaken beheren, klantcon-
tacten hieraan koppelen, de status van klantcontacten en lopende zaken verzetten en een toelich-
ting bij deze statusverandering vastleggen.
Tevens zijn nader te bepalen delen van de klantinformatie inzichtelijk voor geautoriseerde gebrui-
kers bij de uitvoeringsorganisatie.
De portal is na authenticatie via internet toegankelijk in een browser.
S12. Documenten in de portal t.b.v. de uitvoeringsorganisaties
De genoemde portal (S11) biedt tevens de mogelijkheid om documenten toe te voegen aan de
lopende zaken die aan haar organisatie zijn gekoppeld.
In deze portal kan de uitvoeringsorganisatie de status van klantcontacten en zaken verzetten en
een toelichting bij deze statusverandering vastleggen.
O30 Portalfunctionaliteiten t.b.v. uitvoeringsorganisaties
Beschrijf de functionaliteit van de 3D-Suite m.b.t. de portal t.b.v. uitvoeringsorganisaties. Geef
aan welke informatie beschikbaar is en welke acties uitgevoerd kunnen worden.
Geef tevens aan of de portal een specifieke portaalpagina voor uitvoeringsorganisaties is, of dat
deze portal in feite dezelfde interface is als voor medewerkers van de Gemeente maar dan door
middel van rollen en rechten zodanig beperkt dat alle niet relevante functionaliteiten en content is
afgeschermd.
G18 Inzicht in klantbeeld gezin / burger voor medewerkers (incl. UO’s)
G18.1
Per gezin en per burger is voor zover daartoe geautoriseerd alle in de 3D-Suite opgenomen
informatie beschikbaar binnen 1 overzichtspagina, incl. verwijzing naar eventuele derde bron-
nen.
G18.2
69
Alle signalen, meldingen, trajecten, gegevens, dossiers, documenten, afspraken, plannen en
overige bekende informatie over eerdere hulpverlening, etc. over een persoon én een gezin
zijn inzichtelijk voor daartoe geautoriseerde gebruikers.
G18.3
Alle personen zijn in relatie tot het gezin en andere relaties weer te geven, de gebruiker kan
doorklikken naar het gezin en naar de gezinsleden.
G18.4
Bij een burger en een gezin kan de gebruiker doorklikken naar trajecten, deelzaken (master-
detailschermen of vergelijkbaar).
G18.5
Bij een burger en een gezin is realtime alle via het koppelpunt GeVS beschikbare informatie
inzichtelijk voor daartoe geautoriseerde gebruikers: afhankelijk van de rechten niets, DAT, of
WAT
G18.6
Bij een kind zijn realtime alle gegevens zichtbaar die in het leerplichtsysteem bekend inzichte-
lijk voor daartoe geautoriseerde gebruikers: afhankelijk van de rechten niets, DAT, of WAT
70
4.6 Burgerportaal (zelfregie)
Een burgerportaal heeft betrekking op een afgeschermd gedeelte binnen de gemeentelijke website.
Burgers kunnen hier gepersonaliseerde informatie inzien. Dit betreft naast status,
ondersteuningsplannen en dossiers ook onder meer contactmomenten en persoonlijke gegevens.
Via het portaal kan de burger communiceren met de gemeente, naast ook e-mail / telefoon /
fysiek. Idealiter wordt de burger tijdig op de hoogte gesteld van wijzigingen, waarbij de
berichtgeving ook in de zogeheten berichtenbox binnen de „Mijn Gemeente‟ pagina kan worden
ingezien. Dit kan als een aanvulling / uitbreiding gezien worden op „Mijn Overheid‟, waarbij men
door middel van een e-mailservice geïnformeerd. Ook het gebruik van mobiele devices is relevant
i.h.k.v. persoonlijke informatievoorziening.
Daarnaast kunnen klanten via hun „Mijn Gemeente‟ pagina ook informatie verstrekken aan
Gemeente, zoals het uploaden van ontbrekende documenten bij een aanvraag, het wijzigen van
een afspraak, etc. Via een elektronisch (contact)formulier kan eenvoudig informatie gevraagd
worden als bijvoorbeeld de gemeentelijke website of kennisbank van de 3D-Suite tekortschiet of de
afhandeling van een ondersteuningstraject vragen oproept. Burgers hebben aldus de mogelijkheid
om contact te leggen met hun regisseur. Voor authenticatie van personen maakt de persoonlijke
informatievoorziening gebruik van ten minste DigiD EI en Machtigingen.
G19 Aanbod: Persoonlijke informatievoorziening
De 3D-Suite bevat persoonlijke informatievoorziening (een „Mijn ondersteuning‟-pagina) met ten
minste de volgende functionaliteiten:
G19.1
- Toegang mogelijk via DigiD Eenmalig Inloggen (ten minste zekerheidsniveau midden) en DigiD
Machtigingen.
- [Bij deze niet-sterke authenticatie is géén toegang tot informatie die als zodanig is aangeduid.]
G19.2
- Inzage in gepersonaliseerde informatie
G19.3
- Inzage in persoonlijke gegevens en lopende en zaken
G19.4
- Informatieuitwisseling met de behandelaars
G19.5
- Inzage in eigen „lopende zaken‟ en het ondersteuningsplan
G19.6
- Gebruik van webintake-formulieren en beslisbomen o.b.v. dezelfde inrichting als werknemers,
zoals beschreven in par. 4.3 en 4.5.3
G19.7
- De 3D-Suite biedt functionaliteit om burgers op een „Mijn ondersteuning‟-pagina inzage te ge-
ven in hun eigen gegevens, waaronder ten minste e-mailadres en telefoonnummers. Hierbij
wordt bovendien de mogelijkheid geboden om deze gegevens zelf aan te vullen / te wijzigen
G19.8
- De 3D-Suite biedt functionaliteit om burgers op een „Mijn ondersteuning‟-pagina inzage te ge-
ven in de gegevens en zaken van minderjarige gezinsleden
G19.9
71
- De 3D-Suite biedt functionaliteit om burgers op een „Mijn ondersteuning‟-pagina inzage te ge-
ven in de gegevens en zaken van overige gezinsleden, indien daartoe geautoriseerd door de
regisseur
O31 Autorisatie van toegang tot gegevens
Geef aan of en hoe (ten minste door dit aantoonbaar aan de regisseur door te geven) de burger
zelf de autorisatie kan inzien én bepalen wie toegang heeft tot zijn/haar gegevens.
G20 Persoonlijke berichtenbox
G20.1
De 3D-Suite biedt burgers een persoonlijke berichtenbox. Hierin komt gepersonaliseerde in-
formatie van de Gemeente of een ketenpartner niet alleen binnen, maar wordt deze ook be-
waard. Melding van nieuwe persoonlijke berichten worden via het voorkeurskanaal van de
burger verstuurd.
G20.2
De 3D-Suite stuurt tevens een e-mail of SMS (naar wens van de burger) wanneer een bericht
klaar staat of een taak dient te worden volbracht (deelzaak).
G20.3
De burger kan tevens berichten sturen naar de regisseur en naar de uitvoerder van een zaak.
O32 De burger als mede-uitvoerder
Als een burger en/of een mantelzorger ook taken uit het ondersteuningsplan moeten uitvoeren
dan heeft die voor het systeem de rol van „ondersteuner‟/ „uitvoerder‟ en als zodanig grotendeels
dezelfde functionaliteit nodig als een medewerker van een uitvoeringsorganisatie.
Beschrijf de mate waarin via het burgerportaal de burger zelf alle functionaliteiten kan gebruiken
als een medewerker, voor zover daartoe geautoriseerd door de regisseur. Geef daarbij aan in wel-
ke mate en met welke granulariteit de regisseur ad-hoc rechten kan geven om bovenstaande
functionaliteiten en gegevens in te zien dan wel te beperken indien de burger een rol speelt in het
ondersteuningsplan.
O33 Overige functionaliteiten: persoonlijke informatievoorziening
Beschrijf alle eventuele functionaliteiten op het gebied van persoonlijke informatievoorziening die
standaard onderdeel uitmaken van de 3D-Suite en die naar uw mening in het kader van deze pa-
ragraaf relevant zijn. Denk in dat kader bijvoorbeeld aan:
- Inzage van eerdere ondersteuningsplannen.
- Inzage van correspondentie en andere documenten behorende bij een zaak.
- Netwerk rond de burger bijhouden
- Correctiemogelijkheden
72
5 PvE: Specifieke inrichting
5.1 Inleiding
De context / het werkveld van het beoogde gebruik is geschetst in hoofdstuk 2. De benodigde
functionaliteit wordt grotendeels ingevuld d.m.v. generieke functies, die flexibel (=
configureerbaar) zijn. In dit hoofdstuk worden een aantal voor het 3D-domein specifieke
functionaliteiten beschreven. Ook worden situaties aangeduid, die bijzondere eisen stellen aan de
configuratie van de generieke functionaliteiten.
Deze specifieke inrichting dient met name de aanpak zoals beschreven in 2.1 met de pijlers „eigen
kracht‟ en „integraal en regie‟ te ondersteunen. Een kanttekening hierbij is dat de scope van dit PvE
met name gericht is op de ondersteuning van specifieke burgers en professionals, m.a.w.
functionaliteit op het gebied van de anonieme zelfredzaamheid (denk aan een website) laten we
hier grotendeels buiten beschouwing.
Een relevante vraag is wel in hoeverre de burger inzage heeft in zijn plan/ dossier en zelf gegevens
en informatie kan toevoegen/ beheren en evt. een rol heeft in de uitvoering van het plan. Dit is
nog niet in detail uitgewerkt. Hierbij is het van belang situaties met en zonder dwang te
onderscheiden. Bij situaties zoals risicojongeren in de jeugdzorg is dwang soms onvermijdelijk en
zal bijv. inzage door de burger beperkter zijn dan wanneer er geen sprake is van dwang. Het
systeem moet beide situaties echter volledig ondersteunen.
Bijlage 12.3 geeft een voorbeeldinrichting met een voorzet van o.a. de geregistreerde gegevens.
5.1.1 Overzicht gebruik
Het model van “één professional” (die wordt ondersteund door diverse deskundigen of mensen uit
het netwerk van de burger) kan helpen om de informatiestromen in het sociale domein in beeld te
brengen. Het model is niet bedoeld als een sluitende afbakening van de manier waarop de
dienstverlening móet plaatsvinden. De specifieke inrichting zal per gemeente sterk kunnen
verschillen. Ook zal het gebruik bij een individuele gemeente mettertijd significant kunnen gaan
schuiven, bijvoorbeeld bij gewijzigde wetgeving. Kenmerk van de decentralisaties is juist dat er
vele werk- en organisatievormen zullen ontstaan.
73
De informatiestromen kunnen schematisch als hieronder in figuur 7 worden
weergegeven (bron: Hans Versteeg / VNG).
Figuur 7 Informatiestromen 'rond de keukentafel'
Het principe van ‘1-gezin 1-plan 1-regisseur 1-dossier’
Een of meer gesprekken tussen de eerstelijns professional en de burger vinden zijn weerslag in een
plan, dat de basis is voor de vervolgdienstverlening. Dit gebeurt volgens het principe van „1-gezin
1-plan 1-regisseur 1-dossier‟, waaraan ook toegevoegd kan worden „1 regisseur, 1-budget, 1-
informatievoorziening‟.
Het plan bevat zoals eerder aangegeven de afspraken tussen de overheid en de burger en
beschrijft welke acties van de burger en zijn sociale omgeving mogen worden verwacht, en welke
voorzieningen de overheid ter ondersteuning daarvan kan organiseren. Hierbij maakt het voor het
model of de denkwijze niet uit of het gaat om een enkelvoudige te leveren voorziening
(bijvoorbeeld in het kader van de Wmo), of een meervoudige casus of multiprobleemsituatie.
Het 1-plan (ondersteuningsplan) is de start van het 1-dossier (klantdossier). Het klantdossier (of
gezinsdossier) bevat naast het plan enkele essentiële gegevens over de burger, zijn omgeving en
zijn problematiek. Daarnaast biedt het dossier aan alle betrokkenen de mogelijkheid om de voort-
gang van de uitvoering van het plan te volgen. Het ene plan is echter niet in beton maar kan later
worden bijgesteld, bijv. wanneer blijkt dat bepaalde maatregelen niet meer nodig zijn of juist meer
tijd vereisen. De opbouw van het dossier is waarschijnlijk een aantal individuen dat samen een ge-
zin vormt, echter nog nader uit te werken).
Er kan onderscheid gemaakt worden tussen een integraal klantbeeld en integraal klantdossier. Een
klantbeeld is een aggregatie van klantinformatie uit met name verschillende externe bronnen. Een
klantdossier betreft alle gegevens en documenten incl. alle zaken die binnen de 3D-suite ontstaan
of zijn opgenomen: zeg maar het zaakdossier. Het klantbeeld is vaak het startpunt van een traject
en een hulpmiddel tijdens het traject, het klantdossier en het gevolg. In beide gevallen betreft het
gevoelige en vertrouwelijke informatie die enkel inzichtelijk of wijzigbaar is door daartoe
geautoriseerde organisatie(onderdelen) en personen.
74
Ondersteunende functionaliteiten
Ondersteunend voor het klantdossier zijn de volgende functionaliteiten en gegevensuitwisselingen
van belang. Zie ook de nadere beschrijvingen in hoofdstuk 2.
Het relatieve belang van een functionaliteit kan per domein (jeugd, ondersteuning, werk &
inkomen) verschillen:
Signalering / meldingen
Het dienstverleningsproces kan starten met een vorm van signalering (zie ook par. 2.4.4)
vanuit een professional, vanuit de burger zelf (bijv. een melding op het Werkplein, of een
aanvraag bij het Wmo-loket) of vanuit de omgeving van de burger (bijvoorbeeld een mel-
ding bij het Advies- en Meldpunt Kindermishandeling, of een buurvrouw). De vorm en wijze
van signalering en melding kunnen zeer divers zijn. Van belang is dat de signalering altijd
wordt geregistreerd én opgevolgd. Een signaal – in welke vorm dan ook – zal in het alge-
meen leiden tot een gesprek tussen een professional en de betrokken burger.
Als automatisch filteren mogelijk is, dan moet de professional wel in charge zijn: individue-
le regisseurs mogen geen signalen missen. De verantwoordelijkheid voor bundelen en filte-
ren, en het al of niet er iets mee doen ligt bij hen. Naast inkomende signaleringen kan een
medewerker of kan het 3D-systeem zelf o.b.v. vooraf gestelde regels zelf (uitgaande) sig-
nalen aanmaken. Deze kunnen intern worden opgepakt, of aan ketenpartners worden
doorgegeven.
Inkijk / klantbeeld
Om het gesprek te kunnen voeren en het plan op te kunnen stellen dient de eerstelijns pro-
fessional te kunnen beschikken over een beperkt deel van de gegevens over de burger uit
de systemen van de organisaties die betrokken zijn bij de ondersteuning van de burger. Bij
die organisaties is in het algemeen veel informatie bekend over de situatie van de burger
op een bepaald leefgebied en de al geleverde dienstverlening. Door tijdens het gesprek een
beperkt „klantbeeld‟ elektronisch beschikbaar te hebben kan de professional het gesprek ef-
fectiever voeren en kunnen professional en burger sneller bepalen welk aanbod passend is.
De burger zelf moet in beginsel akkoord geven op delen van de informatie aan derden, incl.
uitvoeringsorganisaties. De vorm verschilt per gemeente: van een intentieverklaring t/m
formeel contract en een vinkje incl. DigiD t/m papieren handtekening. Doch in uitzonde-
ringsgevallen (denk aan dwang zoals bij uithuisplaatsing waar de ouder het er niet mee
eens is) kan de goedkeuring ontbreken.
NB zowel klantbeeld als klantdossier (cf. 1-plan) geven veelal géén volledig beeld van een
burger. Veel vertrouwelijke gegevens zullen in diverse „backofficesystemen‟ van de ge-
meente of uitvoeringsorganisaties zijn geregistreerd. Van veel gegevens zal in de 3D-Suite
hooguit in het klantbeeld zijn weergegeven of in klantdossier zijn geregistreerd dat de ge-
gevens bekend zijn bij een bepaalde organisatie of in een bepaald systeem, niet wat die
gegevens zijn. Er zal binnen de 3D-Suite een klantbeeld moeten zijn dat volstaat voor het
voeren van regie en voor het verlenen van de ondersteuning.
Processturing
Op basis van het plan moet de professional in zijn rol als regisseur de processen of dien-
sten bij de diverse ondersteunende organisaties in gang kunnen zetten. Overigens kan de
burger of zijn/haar zaakwaarnemer ook regisseur zijn. Die moet (tenzij dwang) akkoord
75
geven op het ondersteuningsplan. Immers moet de burger zelf de-
len van het plan uitvoeren, en moet hij het doel zelf willen bereiken.
Onderdeel van de processturing is de toeleiding naar de ondersteuning. Dit is de manier
waarop de keuze voor (een) bepaalde tweedelijns ondersteunende organisatie / zorgaan-
bieder(s) wordt bepaald. Overigens kunnen voor de ondersteuning natuurlijk ook mantel-
zorgers e.d. uit het sociale netwerk van de burger zelf ingezet worden, en zal de burger
zelf taken en verantwoordelijkheden kunnen krijgen.
De ondersteuningstoewijzing bestaat uit twee stappen. In de eerste stap is er sprake van
een vorm van inkoop, via bijvoorbeeld een contract of een convenant, waarmee de relatie
tussen de gemeente en de aanbieder wordt bekrachtigd. Dit leidt tot een register of een
sociale kaart waarin inzichtelijk is welke partijen lokaal of regionaal beschikbaar zijn voor
welke diensten. De tweede stap vindt plaats naar aanleiding van het gesprek met de bur-
ger en het ondersteuningsplan en bestaat uit het daadwerkelijk selecteren van een of meer
aanbieders. Deze stap biedt volop mogelijkheden voor ICT-innovatie, bijvoorbeeld door het
inrichten van een online marktplaats voor aanbieders, het organiseren van online veilingen
voor begeleidingstrajecten e.d.
Benadrukt wordt dat niet alleen gemeenten onderling erg kunnen verschillen, ook binnen
de gemeente zal dat het geval zijn. Het is van groot belang dat een proces geen dwangbuis
is. Niet alleen zal een functioneel beheerder van de gemeente zelf standaardprocessen
moeten kunnen aanpassen, ook zal een individuele regisseur (een gebruikersrol) voor een
specifiek ondersteuningsplan ad-hoc zelf taken moeten kunnen toevoegen. Daarnaast zal
de regisseur ook ad-hoc rollen / rechten willen kunnen zetten. Het is bijvoorbeeld denkbaar
dat een ondersteuningsdienst nodig is van een organisatie die niet eerder bekend was bin-
nen de gemeente, of dat taken ook buiten een ondersteuningsplan om worden gezet: bijv.
„ik zie N signalen in jullie wijk, kunnen jullie uitzoeken hoe dat zit?‟
ICT-ondersteuning voor de burger
De Burger zal via het Burgerportaal inzicht kunnen hebben in het plan, het klantdossier,
zijn taken, etc.
Verwijsindex en casusoverleg
Om de samenwerking en samenhang van de betrokken organisaties te kunnen organiseren
en bewaken is in een aantal gevallen een verwijsindex en een ondersteuning voor een ca-
susoverleg nodig. Een verwijsindex bevat informatie over welke ondersteu-
ners/ondersteunende instanties bij een burger of een gezin betrokken zijn: „dat‟ ipv. „wat‟.
Een casusoverlegfunctie is een functie / deelsysteem waarmee geselecteerde en geautori-
seerde professionals een beperkt deel van de inhoudelijke wát-informatie met elkaar kun-
nen uitwisselen en daarover kunnen discussiëren.
Toezicht, verantwoording en beleidsinformatie (regie op regie)
Er is informatie nodig om toezicht te kunnen houden op de kwaliteit van de uitvoering en
om verantwoording te kunnen afleggen over de geleverde prestaties. De gegevens zijn bij
voorkeur zodanig opgeslagen dat ze in geaggregeerde vorm ook op landelijk beleidsniveau
zijn te gebruiken.
76
5.1.2 Primaire en secundaire functies 3D-Suite
We maken onderscheid tussen de primaire bedrijfsfuncties en de secundaire functies. De primaire
functies zijn onderdeel van het daadwerkelijke ondersteuningsproces. De secundaire functies zijn
daar ondersteunend aan of helpen mee om de primaire processen te sturen.
Primaire functies
De primaire functies zijn gevisualiseerd in figuur 8. Deze visualisatie wekt misschien de suggestie
dat het ondersteuningsproces loopt van Aanmelding naar Evaluatie en Nazorg. Dit is een logische
volgorde, maar niet de noodzakelijk volgorde. In een daadwerkelijke casus is het goed mogelijk dat
sommige functies overgeslagen worden en anderen een aantal malen herhaald.
Figuur 8 De primaire functies
De primaire functies zijn als volgt gedefinieerd:
1. Signalen en meldingen. De aanmeldingsfunctie is erop gericht een burger met een
potentiële ondersteuningsbehoefte bekend te maken. Er zijn meestal twee partijen (rollen)
betrokken bij deze functie: de aanmelder en de ontvanger van de aanmelding. De
aanmelder kan de burger zelf zijn, maar er kan ook een signaal of melding komen van een
derde instantie of van een medeburger. Het resultaat van deze functie is de registratie van
de aanmelding en, indien van toepassing, het in kennis stellen van de aangemelde
burger(s).
Het kan zijn dat de burger zichzelf aanmeldt via een digitaal of fysiek loket, via telefoon of
post, of dat de burger door een derde, zoals politie, of familielid, wordt aangemeld. Maar
het is ook denkbaar dat een geautomatiseerd signaleringssysteem op basis van bepaalde
regels een potentiële ondersteuningsbehoefte bij een burger identificeert, bijv. op basis van
meldingen in de verwijsindex risicojongeren (VIR).
Generieke functionaliteit t.b.v. deze functie betreft onder meer ontvangst, prioritering van
bewaking van de binnengekomen signalen.
77
2. Intake. De intakefunctie is erop gericht zoveel mogelijk relevante
informatie te verzamelen om een eerste beoordeling te kunnen doen over een aanmelding.
Het betreft een of meer gesprekken met de (potentiële) burger. Hierin worden vragen
beantwoord als: Wat is er aan de hand? Welke problematiek speelt er bij burger? Is nader
onderzoek nodig? Het resultaat van deze functie is een intakeverslag. Op basis van dit
intakeverslag moet een besluit kunnen worden genomen over het al dan niet starten van
een ondersteuningstraject of dat de burger wordt doorverwezen naar een ander domein.
Het genomen (acceptatie-, verwijzings-)besluit is een tweede resultaat van deze functie.
Generieke functionaliteit t.b.v. deze functie betreft onder meer de burgerintake en
documentgeneratie.
3. Onderzoek. De onderzoeksfunctie is erop gericht om een goed en zo compleet mogelijk
beeld te krijgen van de burger, zijn of haar omgeving, de problematiek, de
voorgeschiedenis en de afgeronde en lopende ondersteuningstrajecten. Hierbij zou een
opdeling naar leefgebieden (wonen, participatie / werk, onderwijs / scholing, financiën /
schulden, gezondheid / welzijn, relaties, zorg / hulpverlening, politie / justitie) kunnen
worden gebruikt. Als onderdeel van het onderzoek kunnen verschillende informatiebronnen
worden geraadpleegd of specialisten worden ingeschakeld om informatie te verzamelen.
Het resultaat van deze functie is een klantbeeld (ook wel: assessment / onderzoeksbeeld /
diagnostisch beeld genoemd).
Dit onderzoek kan deels alvorens (voorbereiden), en deels na (vervolmaken)
intakegesprekken plaatsvinden.
4. Doelstelling. De doelstellingsfunctie is erop gericht om op basis van de verzamelde
informatie voor een of meer leefgebieden ondersteuningsdoelen op te stellen in
samenspraak met de burger. Het resultaat van deze functie is een doel (of verzameling
doelen). Deze doelen worden gebruikt binnen de planningsfunctie (zie hierna) en in het
ondersteuningsplan.
5. Maatregelselectie. De maatregel selectiefunctie is erop gericht om maatregelen,
interventies, zorgvormen en andere middelen die nodig zijn te selecteren om de gestelde
doelen te kunnen bereiken. Het resultaat van deze functie is een lijst van geselecteerde
ondersteuningsmaatregelen. De maatregelen kunnen worden voorgesteld o.b.v. een
Dienstenboek, maar ook kunnen ad-hoc maatregelen worden opgenomen (oma gaat
helpen schoonmaken, of bijv. een dienst van een niet eerder bekende organisatie).
Tussen maatregelen / deelzaken zitten afhankelijkheden. Bijv. eerst A, D, E en H. Dan B en
C. En als het weer stabiel is in het gezin F en tenslotte G. Er zijn daarbij verschillende
soorten relaties mogelijk (begin na einde, niet eindigen voor einde enz.). Die moeten in het
plan vastgelegd worden. Dit mag handmatig, doch bij voorkeur geautomatiseerd.
6. Opstellen ondersteuningsplan. Binnen de planningsfunctie wordt een
ondersteuningsplan opgesteld. In dit ondersteuningsplan worden de doelen, geselecteerde
maatregelen en aanvullende afspraken vastgelegd. Daarnaast zorgt de planningsfunctie dat
de afgesproken vormen van ondersteuning en dienstverlening in gang gezet worden.
7. Ondersteuning. De ondersteuningsfunctie omvat alle (operationele) activiteiten waarin de
burger ondersteuning ontvangt, inclusief het voeren van de regie daarop. Het resultaat van
78
deze functie is de geleverde zorg, hulp of ondersteuning, waarvan
de voortgang wordt bewaakt in de 3D-Suite. De resultaten kunnen tevens worden gebruikt
om effectiviteit en efficiency te monitoren en t.b.v. externe en interne verantwoording.
Generieke functionaliteit t.b.v. deze functie betreft onder meer bewaking van uitgezette
taken en verantwoordelijkheden.
8. Evaluatie. Elk ondersteuningstraject wordt periodiek geëvalueerd. Er wordt zowel met de
burger als binnen het ondersteuningsteam geëvalueerd. Met name in de eindevaluatie
worden de resultaten van de ondersteuning getoetst aan de doelstellingen uit het
ondersteuningsplan. Ook kunnen hierin noodzakelijke nazorgactiviteiten worden
geïdentificeerd. Al deze activiteiten behoren tot de evaluatiefunctie. Het resultaat van deze
functie is een evaluatierapport. Op basis van het evaluatierapport kan worden beslist of de
ondersteuning wordt afgesloten en of er nog nazorg of een hernieuwde intake ingezet
wordt.
9. Nazorgverlening. Soms vindt er, nadat het ondersteuningstraject formeel is afgesloten,
nog een vorm van nazorg plaats. Bijvoorbeeld dat een wijkcoach na een maand nog eens
gaat kijken hoe het met de burger gaat. Anderen zullen misschien wel iedere paar
maanden of weken worden bezocht, afhankelijk van de inschatting van de betrokken
medewerkers.
Secundaire functies
De primaire taak van de gemeente het kader van de 3D-domeinen is regie: zorgen dat de burger
geholpen wordt. Naast de regie kan de gemeente ook een rol spelen in de uitvoering, maar dit is
afhankelijk van de beleidskeuzes die elke gemeente voor zich maakt. Bijdragen van andere partijen
in het verlenen van de ondersteuning beschouwen we ook als primaire taak. Een andere
belangrijke taak van de gemeente is de (financiële) verantwoording. Dit zien we als een secundaire
taak, maar daarmee niet minder belangrijk.
Primaire functies zijn de functies waarmee de benodigde ondersteuning kan worden verleend en
regie kan worden gevoerd, secundaire functies zijn ondersteunend hieraan zoals facturering,
managementinformatie en budgetbeheersing. Ook tijdsplanning beschouwen we hier als een
secundaire functie.
De secundaire functies zijn gevisualiseerd in figuur 9.
79
Figuur 9 Secundaire bedrijfsfuncties
Naast de primaire bedrijfsfuncties onderscheiden we de volgende secundaire bedrijfsfuncties:
1. Besluitvorming. Op verschillende punten in het hulpverleningsproces moeten besluiten
worden genomen en vastgelegd, bijv. over het accepteren van een nieuwe burger, over het
stellen van een indicatie, over het verwijzen naar een andere vorm van hulpverlening of
over het afsluiten van een traject. Het nemen en vastleggen van dergelijke besluiten is
onderdeel van de besluitvormingsfunctie. Het resultaat van deze functie is een besluit.
Bijvoorbeeld kan tooling m.b.t. de Zelfredzaamheidsmatrix 12 een belangrijk hulpmiddel
zijn bij ieder van de primaire functies. Een ander deel van deze functie is de eventueel
benodigde fiattering alvorens bepaalde ondersteuningsdiensten kunnen worden afgegeven
of alvorens een door de gemeente bepaald maximumbudget wordt overschreden.
2. Trajectbeheer & Dossiervorming. Het trajectbeheer omvat het registreren, vastleggen
en ontsluiten van informatie over burgers en ondersteuningstrajecten. Dit betreft zowel
historische informatie over de geschiedenis van burgers als actuele informatie over lopende
trajecten.
Enerzijds worden binnen trajectbeheer externe gebeurtenissen geregistreerd, zoals het
behalen van een diploma, het verliezen van een woning en het beëindigen van een
(tweedelijns) zorgtraject. Anderzijds wordt informatie vastgelegd die binnen de eerstelijns
hulpverlening zelf wordt geproduceerd, zoals een aanmelding, een intakeverslag, een
evaluatieverslag en een indicatiebesluit. Met deze functie kunnen trajectbeelden worden
ontsloten (een trajectbeeld bevat een beeld van een ondersteuningstraject). Een
contactenboek (overzicht van alle contacten met de burger of een betrokkene bij een
ondersteuningstraject) maakt ook onderdeel van deze bedrijfsfunctie.
3. Monitoren. Op basis van de gebeurtenissen en gegevens die zijn vastgelegd binnen
Trajectbeheer, waaronder aanmeldingen, meldingen aanvang en einde ondersteuning en
evaluatierapporten, heeft monitoren betrekking op het controleren van de voortgang en
kwaliteit van de ondersteuningstrajecten. Het resultaat van deze functie zijn indicatoren en
kengetallen over de lopende ondersteuningstrajecten, op basis waarvan besluiten kunnen
worden genomen over het bijsturen, uitbreiden, aanpassen of beëindigen van trajecten.
12 Zie ook www.zelfredzaamheidmatrix.nl
80
4. Verantwoording. De verantwoordingsfunctie heeft betrekking op
het opstellen van rapportages over de kosten en resultaten van de verleende
ondersteuning, de ingezette ondersteuningsmiddelen en andere procesindicatoren en -
kengetallen. In tegenstelling tot monitoren betreft het hierbij altijd geaggregeerde
informatie die niet terug te herleiden is tot individuele burgers, hulpverleners of
ondersteuningstrajecten. Het resultaat van deze functie zijn de rapportages. Deze dienen
als input voor beleidsmakers om de effectiviteit van hun beleid te kunnen evalueren en zo
nodig bij te stellen.
5. Betaling & Incasso. Met de inzet van ondersteuningsmiddelen en –diensten zijn ook
kosten gemoeid. Er wordt op een zeker moment afgerekend met externe hulpverleners en
leveranciers. Op basis van de afspraken gemaakt met deze partijen vindt financiële
afwikkeling plaats. Hier wordt geregistreerd, gecontroleerd en betaald. Tegelijkertijd kan
het nodig zijn om een deel van de kosten te verhalen op de burger (eigen bijdrage). Dit is
het incasso deel van deze functie. Het resultaat van deze functie zijn betalingen en
vorderingen.
6. Inkoop en Contractbeheer. Voor de ondersteuning zullen op allerlei wijzen derden
ingezet worden, zoals hulpverleners, zorgaanbieders, coaches en leveranciers van
ondersteuningsmiddelen. Met al deze partijen worden van te voren afspraken gemaakt
over dienstverlening, verantwoording en betaling. Deze afspraken worden vastgelegd in
een contract. De functie inkoop en contractbeheer omvat alle activiteiten met betrekking
tot het opstellen, afsluiten, monitoren en beëindigen van dergelijke contracten. Het
resultaat van deze functie is een contract.
7. Beroep en Bezwaar. Tegen elk besluit t.a.v. de ondersteuning moeten burgers bezwaar
kunnen aantekenen. Daarom is er een functie nodig die de afhandeling van dergelijke
bezwaren ondersteunt.
Overzicht rollen
De gemeente zal ondersteuning moeten kunnen bieden voor verschillende typen huishoudens. Een
individu, een gezin met kinderen, maar ook bijv. diverse samenwonende volwassenen. Het gezin is
uitgangspunt, doch verschillende domeinen en eventueel gekoppelde systemen hebben hier
verschillende definities. Een gezin kan in deze context worden gezien als een flexibel te definiëren
(vader, moeder, dochter, zoon, opa, inwonende vriend, …) groep van individuen. Bij koppelen met
ketenpartners en interne backofficesystemen dient rekening gehouden worden met verschillende
definities van een gezin of huishouden.
Een ondersteuningsplan kan een individu betreffen, maar ook kan een ondersteuningsplan taken
voor het gehele huishouden omvatten, alsook ondersteuning voor vader, moeder, oma en
kinderen. Waar in dit document wordt gesproken over een burger, kan dat ook een gehele
huishouden betreffen. Idealiter kunnen klantdossiers en ondersteuningsplannen zowel op gezins-
als persoonsniveau vorm krijgen, met relaties tussen beiden.
Waar wordt gesproken over medewerkers, kan dit zowel medewerkers van de gemeente betreffen,
van een uitvoeringsorganisatie of van een ketenpartner.
(Voorbeelden van) gebruikers van het systeem: binnen de gemeente of bij een ketenpartner:
Regievoerder / regisseur
81
Regievoerder. Veelal gemeentemedewerker, doch niet perse. De
regisseur is ook niet per se dé spin in het web, eventueel kan de functie verspreid zijn over
meer personen, bijv. een multidisciplinair team dat gezamenlijk de beslissing neemt.
(Wijk)team-manager
Aansturing en managen van team van regisseurs. Grotere gemeenten zullen wellicht de re-
gisseurs bijv. per wijk aansturen.
Professional
Feitelijke hulpverleners, onderzoekers, etc. Bijvoorbeeld een lid van een wijkteam. Veelal
géén medewerker van de gemeente maar zelfstandige of medewerker van een uitvoerings-
organisatie.
Overige uitvoerders
De burger zelf, of bijv. een familielid of mantelzorg kan tevens taken toebedeeld krijgen en
als zodanig wellicht (beperkte) toegang tot het systeem krijgen.
Aanmelder signaal
Veelal géén medewerker van de gemeente maar zelfstandige of medewerker van een uit-
voeringsorganisatie. (Een signaal kan ook komen van enige derde)
Secretariaat gemeente
Inzage in de agenda‟s, doorverbinden, etc.
Managers
Van gemeente, buiten gemeente. Dergelijke rollen kunnen nodig zijn t.b.v. fiattering. Ook
zijn ze gebruikers van managementinformatie.
Functioneel beheerder bij gemeente
Deze beheren op functioneel niveau de ICT-voorzieningen van de gemeente, zoals applica-
tieprogrammatuur en gegevensverzamelingen (en de bijbehorende documentatie). Ze laten
deze voorzieningen optimaal aansluiten op de bedrijfsprocessen en daarmee samenhan-
gende wensen van gebruikers en andere belanghebbenden. Dit omvat ten minste gege-
vensbeheer, procesbeheer en gebruikersbeheer.
Technisch beheerder bij gemeente
Technisch beheer omvat voornamelijk het operationeel houden van de – voor de 3D-Suite
benodigde – technische infrastructuur. Bijvoorbeeld: netwerkverbindingen, back-ups, en
beheer van de serverhardware en van ondersteunende software zoals databaseservers,
evenals het installeren en (v.w.b. technische aspecten) testen van nieuwe en verbeterde
versies van de 3D-Suite.
Burgers, burgers en betrokkenen
Burger (of ingezetene) Gezin (huishouden) en gezinslid Familielid, vriend, kennis, etc.
Huisarts, wijkagent, thuiszorg medewerker, etc. Onderwijzer/docent, sportleraar, pastoor/imam, etc.
5.1.3 Specifieke wensen en eisen
In par. 5.2 en verder zijn op basis van bovenstaande visies de wensen en eisen geformuleerd voor
de generieke functionaliteit van de 3D-Suite. Zoals in par. 3.5 beschreven wordt daarbij gebruik
82
gemaakt van Eisen (E#), Gesloten wensen (G#), Open wensen (O#) en
Semigesloten wensen (S#). Zoals gezegd heeft het de voorkeur (vanwege de gewenste flexibiliteit)
dat de specifieke functionaliteiten in dit hoofdstuk zoveel mogelijk ingericht zijn op basis van de
generieke functionaliteiten uit hoofdstuk 4.
83
5.2 Regie
Regie is een breed begrip. In de context van dit PvE is het begrip regie te relateren aan de wens
van de gemeente om zicht te hebben en controle hebben op de burgersituatie op het moment dat
er sprake is van verminderde zelfredzaamheid. Met andere woorden: het regisseren van de
ondersteuning van individuele burgers dan wel een gezin.
Zoals in paragraaf 2.2 reeds beschreven voorzien we vier hoofdmodellen regie, waar binnen een
gemeente deze vier regiemodellen én tussenvormen daarvan dienen te kunnen worden gebruikt.
Geen gemeentelijke regie / zelfregie Regisseur als single point of contact (“light”-versie
van regie)
Regisseur als spin in het web Regisseur als uitvoerder
Figuur 10 Vier vormen van regie
De regisseur wordt ondersteund door de in hoofdstuk 4 weergegeven functionaliteiten.
E7 Regievormen
Dit PvE gaat uit van vier regiemodellen (zie figuur 10): geen regie/zelfregie, regisseur als single
point of contact, regisseur als spin in het web, regisseur als uitvoerder. Het gaat hier om de regie
op de ondersteuning (van klantvraag t/m nazorg). Alle vormen –en tussenvormen ervan– worden
ondersteund door de 3D-Suite.
84
O34 Ondersteunen regie(vormen)
Beschrijf de wijze waarop de 3D-suite ondersteuning biedt aan de genoemde regievormen. En
neem daarbij ook mee dat de vormen gelijktijdig binnen één gemeente toegepast kunnen worden.
Betrek in het antwoord ook de volgende aspecten:
- Zelfregie door de burger
- Het onderscheid tussen “wat” en “dat” informatie
- Het actuele, integrale klantbeeld
- Het registreren en doorzetten van signalen/meldingen
O35 Regie en uitvoering
De regisseur kan puur vanwege de regie bij een gezin betrokken zijn. Maar het kan ook zijn, dat
één van de bij het gezin betrokken hulpverleners de rol van regisseur op zich neemt. In dat
laatste geval is er sprake van één functionaris met verschillende rollen (die van regisseur en die
van uitvoerder).
Beschrijf de wijze waarop deze combi-rol in de 3D-suite toegepast kan worden, beschrijf daarbij
tevens eventuele beperkingen van het systeem als de betreffende hulpverlener geen medewerker
is van de gemeente. Beschrijf tevens in welke mate het klantbeeld afhankelijk van de rechten en
de rol van de medewerker meer of minder informatie kan geven bij de uitvoering van de regie
(i.h.k.v. doelbinding).
85
5.3 Burgerportaal (zelfregie)
In par. 2.3 is het Burgerportaal belicht, waarbij een onderscheid is gemaakt tussen:
A. Informatievoorziening en vraagverheldering. Het gaat hier om op een gebruiksvriende-
lijke wijze toegang bieden tot actuele, complete informatie over (jeugd)zorg, ondersteu-
ning, werk, inkomen en onderwijs. Zie par. 5.3.1.
B. Inzage in eigen plan/dossier en het burgerportaal als communicatieplatform. Dit betreft
het gepersonaliseerd burgerportaal (Mijn „omgeving‟). Zie par. 5.3.2.
Waar nodig dient u in uw beantwoording onderscheid te maken tussen de functionaliteit en de
content. Bijvoorbeeld bevat een set vraag-antwoordcombinaties ter ondersteuning van een klant
enerzijds uit functionaliteit t.b.v. creëren, beheren en publiceren van de VAC door gemeente en
functionaliteit om er doorheen geleid te worden voor de burger. Anderzijds bevat het ook feitelijke
vragen/antwoorden die de gemeente of zelf moet aanmaken, of kan het van de Contractant een
standaardset krijgen die de gemeente vervolgens zelf aanpast.
[NB zie ook hoofdstuk 3 en 11 v.w.b. fasering.]
5.3.1 Niet-gepersonaliseerd burgerportaal (oriëntatie & infor-
matie)
Er komen steeds meer Online community- en „Marktplaats‟-oplossingen, waarmee burgers elkaar
ondersteunen op het brede veld van zorg en welzijn (zie bijlage 0). Daarnaast zijn er functionalitei-
ten, die vooral ingericht zijn en gebruikt worden door burgers, maar ook van belang zijn voor pro-
fessionals in hun werk. Deels betreft het algemene voorzieningen, maar ook voorzieningen, die
door de gemeente zelf worden aangeboden, zoals product- en dienstencatalogus, vraagverhelde-
ring, sociale kaarten.
O36 Online interactie
Beschrijf alle eventuele functionaliteiten op het gebied van online interactie tussen burger en
medewerkers die standaard onderdeel uitmaken van de 3D-Suite en die relevant zijn in het kader
van beoogd gebruik als beschreven in hoofdstuk 2. Geef hierbij vooral aan hoe de vastlegging is
geregeld.
O37 Informatievoorziening en vraagverheldering
Beschrijf alle eventuele functionaliteiten (incl. geboden standaardcontent) op het gebied van m.n.
niet-gepersonaliseerde informatievoorziening en vraagverheldering die standaard onderdeel
uitmaken van de 3D-Suite en die relevant zijn in het kader van beoogd gebruik als beschreven in
hoofdstuk 2. Denk hierbij aan:
- Webcontent management (CMS), zowel publicatie- als redactie-functionaliteit
- Product- en Diensten catalogus (PDC/ kennisbank) inclusief:
▪ functionaliteit voor het aanbieden van een overzichtsweergave van beschikbare producten
en diensten, in meerdere varianten van groepering en sortering.
▪ Onderscheid tussen externe en interne informatie, m.a.w. hoe kan productbeschrijving-
informatie toegevoegd worden, die alleen voor medewerkers beschikbaar is?
- Vraaggeleiding/beslisbomen om burgers en medewerkers door middel van vraaggeleiding / be-
slisbomen naar relevante (op de situatie/behoefte toegespitste) informatie. Dat kan een be-
86
schrijving zijn van een product of dienst, maar ook een antwoord op de vraag (FAQ of VAC) of
men voor een voorziening in aanmerking komt.
▪ In het doorlopen van een vraaggeleiding wordt als het ware een klantprofiel (een beeld van
de zorgbehoefte) opgebouwd. Deze informatie wordt dan bij voorkeur doorgegeven aan een
digitaal aanvraagformulier of een digitale afspraak (onderdeel van het gepersonaliseerde
klantportaal).
▪ Standaard content: door u te leveren content of integratie met andere content leveranciers
- Sociale kaart: een digitale gids met informatie over dienstverleners en instellingen (functionali-
teit en/of standaard content).
- Zoeken in (niet-gepersonaliseerde) content. De 3D-Suite biedt zoekfunctionaliteit. Speciale
aandacht verdient het zoeken in verschillende bronnen en een overzichtelijke weergave en het
geïntegreerd tonen van zoekresultaten. Bijvoorbeeld bij het zoeken naar een bepaald onder-
werp worden op een overzichtelijk wijze alle relevante productbeschrijvingen, beslisbomen, so-
ciale kaarten en „ook van belang‟ (bijvoorbeeld links naar externe sites, verwijzingen naar re-
gelgeving en beleidsinformatie) getoond.
Geef aan in welke mate dit wordt geconfigureerd o.b.v. de in voorgaande hoofdstuk beschreven
standaardfunctionaliteiten.
O38 Integratie met de gemeentelijke website/ digitaal loket
Veel gemeenten hebben de onder O37 genoemde functionaliteit al in huis via hun website, digitaal
loket en klantcontactsysteem. Beschrijf de mate van integratie tussen de 3D-Suite en de
genoemde systemen. Maak daarbij een onderscheid tussen de doelgroepen burger en
medewerker.
- Onze denkrichting is dat burgers en professionals bij hun vragen en activiteiten op het sociaal
domein werken vanuit één platform/interface. Burgers zullen zich op het Burgerportaal infor-
meren naar mogelijkheden in ondersteuning. Professionals kunnen diezelfde informatie gebrui-
ken in het (intake) gesprek aan de keukentafel of aan de telefoon in het klantcontactcentrum.
- Uitgangspunt hierbij is eenmalig vastleggen en meervoudig gebruik van content, maar ook
geen redundantie qua functionaliteit.
- Er moet bovendien rekening gehouden worden met diverse organisatievormen, m.a.w. de on-
dersteuning op het sociaal domein kan geheel buiten de gemeente geplaatst worden (regie op
afstand) of men kan kiezen voor een grote inzet in de regie en uitvoering door gemeente zelf.
O39 Online community en ‘Marktplaats’ oplossingen
Beschrijf alle eventuele functionaliteiten die standaard onderdeel uitmaken van de 3D-Suite en die
naar uw mening relevant zijn op het gebied van Online community en „Marktplaats‟ voor burgers
onderling (waar burgers elkaar onderling kunnen vinden en helpen, zie bijv. bijlage 12.7. Denk
hierbij o.a. aan:
- 1P functionaliteiten van de in bijlage 0 genoemde voorbeelden (We Helpen.nl, Wikiwijk Tilburg,
Buuv.nu, Jeugdcloud, Toegankelijk Enschede, Zorgsite (Helmond)).
- Integratie met 3P-oplossingen.
Het idee is dat een burger, indien hij ondersteuning bij de gemeente aanvraagt, zelf (een deel
van) zijn informele „community‟ beschikbaar kan stellen voor de regisseur/professional, zodat
informele en formele ondersteuning optimaal op elkaar afgestemd kunnen worden.
Geef aan in welke mate dit wordt geconfigureerd o.b.v. de in voorgaande hoofdstuk beschreven
87
standaardfunctionaliteiten.
5.3.2 Gepersonaliseerd Burgerportaal
Dit omvat het deel van de 3D-suite waarop de burger toegang heeft tot zijn gegevens/ dossier en
diverse functionaliteiten tot zijn beschikking heeft. Hierdoor kan de burger in belangrijke mate ac-
tief „meedoen‟ in de uitgezette trajecten. Zelfregie is mogelijk.
O40 Zelfdiagnose
Hoewel het ondersteuningsplan (zie ook S14) als een gezamenlijk (van regisseur en burger/gezin)
actieplan gezien kan worden weerspiegelt de bovengenoemde functionaliteit een reactieve burger.
Het is zaak om de burger juist in de intake c.q. bij het opstellen van het ondersteuningsplan zelf
het initiatief/ de regie te laten nemen. Inzicht in de eigen situatie en zelf aan de slag gaan met
voorgestelde acties is een belangrijk gegeven.
Geef aan welke functionaliteit de 3D-Suite biedt om burgers een zelfdiagnose uit te laten voeren.
Op basis van bij voorkeur het (zelf aangevulde) klantbeeld en een zelf ingevulde
zelfredzaamheidmatrix evt. met inzet van andere instrumenten verkrijgt de burger:
- Relevante (regionale) informatie
- Waar mogelijke voorstellen om zelf actie te ondernemen
- Overzicht naar juiste hulpverleners met de nadruk op collectieve voorzieningen en de informele
sector/ het eigen netwerk.
Beschrijf uw functionaliteit in deze. Geef tenslotte aan in welke mate dit wordt geconfigureerd
o.b.v. de in voorgaande hoofdstuk beschreven standaardfunctionaliteiten.
S13. Persoonlijke gegevens inzien en aanpassen (basis)
De 3D-Suite biedt functionaliteit om burgers inzage te geven in eigen gegevens, waaronder ten
minste:
- de eigen algemene persoonsgegevens uit het GBA
- e-mailadres en telefoonnummers. Hierbij wordt bovendien de mogelijkheid geboden om het e-
mailadres en de telefoonnummers zelf in/aan te vullen / te wijzigen
- de eigen gegevens uit het DKD, Digitaal Klant Dossier – mits daartoe geautoriseerd
O41 Persoonlijke gegevens inzien en aanpassen (aanvullend)
Geef aan welke functionaliteit de 3D-Suite biedt om burgers inzage te geven in hun eigen
klantprofiel dat wordt opgebouwd aan de hand van scores op o.a.:
- De zelfredzaamheidmatrix
- De participatieladder
De 3D-Suite biedt functionaliteit om burgers in een Burgerportaal het eigen klantbeeld te verrijken
(aanpassen) en te beheren. Men kan daarbij denken aan:
- Gegevens qua opleiding, werkervaring
- Eigenschappen, competenties, voorkeuren (evt. aangevuld door anderen)
88
Beschrijf uw functionaliteit in deze. Geef aan in welke mate dit wordt geconfigureerd o.b.v. de in
voorgaande hoofdstuk beschreven standaardfunctionaliteiten.
S14. Mijn ondersteuningsplan (basis)
De 3D-Suite biedt functionaliteit om burgers inzage te geven in:
- Het ondersteuningsplan
- Lopende zaken (de afgesproken acties) en lopende contacten. Hierbij wordt ten minste de ac-
tuele statusinformatie (incl. toelichting) getoond.
Er is ook functionaliteit om te reageren op de lopende zaken en de eigen zaken te beheren.
Daarbij kan gedacht worden aan:
- Online toevoegen van informatie (vragen, opmerkingen) aan het ondersteuningsplan en/of lo-
pende zaken/ contacten
- Beheren van de eigen (aan de burger zelf toegewezen) acties uit het ondersteuningsplan
O42 Mijn ondersteuningsplan
Beschrijf de mate waarin de burger ondersteund wordt om zo gebruiksvriendelijk mogelijk de
functionaliteiten kan gebruiken als beschreven in voorgaande wens.
Geef tevens aan in welke mate dit wordt geconfigureerd o.b.v. de in voorgaande hoofdstuk be-
schreven standaardfunctionaliteiten.
S15. Mijn dossiers
De 3D-Suite biedt functionaliteit om burgers:
- inzage te geven in de documenten die hij heeft ingediend en in andere documenten waar hij
toe is geautoriseerd (bijv. documenten in deelzaken waar hij zelf verantwoordelijk voor is)
- reacties op documenten online toe te voegen
- zelf documenten toe te voegen
G21 Notificatie en persoonlijke berichtenbox
G21.1 De 3D-Suite biedt functionaliteit om burgers voorkeuren voor gepersonaliseerde informatie
in het Burgerportaal op te laten geven. Aan de hand van het ingegeven interesseprofiel krijgt de
burger een e-mail-notificatie, waarin een korte omschrijving met een link naar het nieuwsbericht
is opgenomen. Dit omvat ten minste
- Statuswijziging van ondersteuningsplan en/of acties
- Wijzigingen aangaande de contactpersoon/regisseur
- Uitnodiging om afspraak te maken en/of reminder vlak voor een geplande afspraak
- Reminder voor het indienen van gevraagde informatie
- Toegevoegde informatie (brochures e.d.) door de regisseur aan „Algemene informatie‟ (of ge-
lijkwaardig)
G21.2 De berichten worden afgeleverd en bewaard in een persoonlijke berichtenbox.
S16. Mijn contactpersoon
De 3D-Suite biedt functionaliteit om burgers snel contact te leggen met hun regisseur/
contactpersoon. De contactgegevens en bereikbaarheid van de contactpersoon en/of team zijn
89
beschikbaar. Daarbij is ook functionaliteit opgenomen om direct een bericht aan de
contactpersoon online in te dienen.
S17. Mijn Agenda
De 3D-Suite biedt functionaliteit om burgers met betrokken hulpverleners en andere daartoe
geautoriseerde personen (zoals familieleden of mantelzorg) een gezamenlijke agenda te voeren.
Dit betreft ten minste:
- Het toevoegen van afspraken door burgers
- Het plaatsen van uitnodigingen voor overleg door de regisseur en andere professionals
- Het opnemen van mijlpalen van het ondersteuningsplan. Hierdoor is het mogelijk om een be-
knopt overzicht (in grafische vorm) van de mijlpalen en voortgang van het ondersteuningsplan
apart toe te voegen. Dat overzicht kan bij de agenda, maar ook op de pagina van het onder-
steuningsplan geplaatst worden.
S18. Algemene informatie
- De 3D-Suite biedt functionaliteit om burgers in een „Mijn Omgeving‟ snel toegang te geven tot
(voor hun situatie c.q. ondersteuningsplan) relevante algemene niet-gepersonaliseerde infor-
matie zoals brochures etc.
- Burgers kunnen zelf het onderdeel beheren, maar ook de regisseur/ professionals kunnen al-
gemene informatie aanbieden.
- Via het interesseprofiel kan de burger hiervoor toestemming geven. Via notificatie krijgt de
burger bericht als er nieuwe informatie toegevoegd is.
O43 Digitale aanvragen
Beschrijf de mate waarin de 3D-Suite functionaliteit biedt om burgers digitale aanvragen te laten
indienen. Hierbij moet men denken aan:
- Het indienen van een aanvraag via een e-formulier incl. voorinvulling (prefill) van reeds be-
kende gegevens
- Digitale aanvragen kunnen een nieuw (nog op te starten) ondersteuningsplan betreffen
- Digitale aanvragen kunnen vanuit een lopend ondersteuningsplan gestart worden. De aanvraag
heeft dan ook de kenmerken van (is gekoppeld aan) het ondersteuningsplan.
- Opslaan van gedeeltelijk ingevulde e-formulieren, die later weer opgepakt kunnen worden voor
verdere invulling
- Hergebruik van vorige (de laatst ingediende) aanvraag als basis voor de nieuwe aanvraag. Dit
is handig als er frequent (jaarlijks) een nieuwe aanvraag ingediend moet worden en de situatie
vrijwel ongewijzigd is
- Een betaalmodule. In een traject, waarin betaling aan de orde is een stap ingebouwd waar een
specificatie incl. factuur wordt opgesteld en aan „Mijn Omgeving‟ wordt aangeboden. Daar kan
de burger met online betaling (iDEAL) de betaling regelen. Gemak voor de burger, efficiëntie
voor de gemeente/ondersteuner en snelheid voor beide partijen.
- Etc.
NB dit betreft het gebruik door burgers (vaak met verminderde zelfredzaamheid). Het inrichten en
beheren van de formulieren is gevraagd in par. 4.3.
90
S19. Koppeling met de landelijke voorziening ‘MijnOverheid’
De 3D-Suite biedt bij voorkeur functionaliteit voor directe aansluiting op de landelijke voorziening
MijnOverheid.nl, zodat per zaak ten minste actuele statusinformatie en de zaakdocumenten uit
het zaakdossier - rekening houdend met autorisaties – onder „lopende zaken‟ in de landelijke
voorziening MijnOverheid.nl worden getoond.
Daarnaast worden gepersonaliseerde berichten getoond in de „berichtenbox‟ van MijnOverheid.nl.
Dit betreft ten minste: ontvangstberichten, verzoeken om nadere informatie, besluiten,
attenderingen, betaalspecificaties, oproepen, etc.
O44 Visie op zelfregie
Natuurlijk beogen we het „zelf doen‟ te stimuleren, maar de hoofdrol ligt bij de professionele
regisseur. De 3D-Suite dient vooral die regisseur te ondersteunen. Geef uw visie – en de mate
waarop dit nu en in de toekomst wordt ondersteund met uw 3D-Suite - hoe u met de ontwikkeling
van uw oplossing aankijkt tegen zelfregie.
91
5.4 Het regieproces
Het gaat hier om het regieproces. In par. 2.4 is de rol incl. taken van de regisseur beschreven. Om
die rol mogelijk te maken is in par. 5.1.2 een aantal uitgangspunten benoemd, waarbij vooral de
primaire functies relevant zijn. In par. 5.4 worden functionaliteiten beschreven, die betrekking
hebben op componenten, die in het gehele regieproces relevant zijn. Denk daarbij bijvoorbeeld aan
het integrale klantbeeld (inkijk). Daarnaast zullen ook andere functionaliteiten beschreven worden,
die inhoud geven aan een primaire functie. Voor de duidelijkheid: steeds als aanvulling op de gene-
rieke functionaliteit.
5.4.1 Integraal klantbeeld
O45 Integraal klantbeeld (basis)
Het integrale klantbeeld (zie ook par. 2.4.1) bestaat uit gegevens van de burger, zoals NAW, in-
komen, schulden, opleidingen, die zoveel mogelijk uit andere systemen worden betrokken. Ook
indicaties van ontvangen voorzieningen voor jeugdhulp, zorg of ondersteuning vormen een on-
derdeel.
Beschrijf alle functionaliteiten op het gebied van basisgegevens die standaard onderdeel uitmaken
van de 3D-suite en die relevant zijn in het kader van beoogd gebruik als beschreven in hoofdstuk
2. Denk hierbij aan:
- NAW over de betrokken persoon en het gezin
- Werk, inkomens- en uitkeringsverhoudingen
- Ontvangen ondersteuning, waaronder ook schulden en schuldhulpverlening
- Onderwijs en opleidingsgegevens, incl. leerplicht / RMC
- Evt. justitiële gegevens
Geef aan welke bronnen hierbij gebruikt worden c.q. vanuit de 3D-suite bevraagd worden (zie ook
bijlage 12.2 v.w.b. de informatie die via de GeVS kan worden geleverd).
Denk ook aan
- indicaties van ontvangen voorzieningen voor jeugdhulp, zorg of ondersteuning
Deze indicaties kunnen vanuit diverse registratiesystemen komen, zoals gemeentelijke backoffice-
systemen.
Geef aan in welke mate bij / voor weergave rekening wordt gehouden met de autorisatie en rol
van de persoon die informatie wil zien (doelbinding).
O46 Toegevoegde gegevens door burger
Via het Burgerportaal kan de burger bij voorkeur zelf gegevens en documenten toevoegen en die
vrijgegeven voor gebruik (zie ook O40 op blz. 87). Beschrijf de mate waarin de burger hierbij
wordt ondersteund en de wijze waarop deze gegevens kunnen worden toegevoegd en als inte-
graal onderdeel van het klantbeeld kunnen worden gepresenteerd .
O47 Het sociaal netwerk van de burger
Beschrijf de mate waarin en de wijze waarop het sociale netwerk van de burger geregistreerd en
toegevoegd kan worden aan het Klantbeeld (familieleden, vrienden, buren, …). Geef aan of en op
welke wijze hier een onderscheid gemaakt kan worden tussen het „algemene‟ netwerk en het net-
werk dat relevant is voor een specifiek behandelplan.
92
Beschrijf de wijze waarop het netwerk rondom de burger in één oogopslag inzichtelijk is. Voor-
beeld om een relatienetwerk in beeld te brengen is een sociogram.
De burger kan (al dan niet samen met de regisseur) wellicht ook zijn sociale netwerk betrekken
bij het uitvoeren van het ondersteuningsplan. Geef aan of en in welke mate specifieke delen van
een behandelplan inzichtelijk kunnen gemaakt voor die derde burgers – zonder dat de privacy van
de burger in gevaar komt.
O48 Overzicht van informele ondersteuning
Een burger kan (als mede-uitvoerder) participeren in het behandelplan en de 3D-suite gebruiken
als informatie- en communicatieplatform. De burger kan (daarnaast) ook zaken regelen, die niet
geregistreerd worden in de 3D-suite, maar die wel relevant zijn voor het behandelplan. Dat zal
ook gelden voor personen uit zijn netwerk.
Beschrijf de mate waarin de informele omgeving van de klant verbonden kan worden met de 3D-
suite (of uw visie daarop). Denk bijv. aan het verbinden van „online community‟ en „marktplaats‟
oplossingen (zie par. 5.3.1) met de 3D-suite en/of de functionaliteit van de 3D-suite te verbreden
en de toegang laagdrempelig te maken m.b.v. bijvoorbeeld mobiele toepassingen, apps, e.d. –
voor zover dit de privacy en beveiliging niet kan schaden.
O49 Klantprofiel
Er zijn diverse methodes om de situatie van de klant te meten/ kwalificeren in een klantprofiel.
Eén van bekende methodes is de „Zelfredzaamheidsmatrix‟. Op het domein van werk en inkomen
is de Participatieladder een veel toegepast instrument. De score op de Zelfredzaamheidsmatrix
geeft een indruk/beeld van de zelfredzaamheid en waar ondersteuning nodig is. Dit instrument
kan bij de intake ingezet worden (als nulmeting), maar ook als monitorinstrument tijdens en aan
het eind van het behandeltraject. De actuele score kan als het ware als een foto van de situatie
van de klant aan het klantbeeld toegevoegd worden.
Beschrijf de mate waarin de 3D-Suite functionaliteit biedt en de wijze waarop de Zelfredzaam-
heidsmatrix en/of de Participatieladder toegepast kan worden c.q. integraal onderdeel uitmaakt
van de 3D-suite om een zo volledig mogelijk klantbeeld te vormen.
O50 Klantbeeld (overig)
Beschrijf alle eventuele additionele functionaliteiten inzake het klantbeeld die standaard onderdeel
uitmaken van de 3D-suite en die relevant zijn in het kader van beoogd gebruik als beschreven in
hoofdstuk 2. Denk hierbij aan:
- weergave van de laatste entries van het contactjournaal
- overzicht van de eigen aantekeningen over de burger
- financieel overzicht van de gemaakte kosten tot zover
- etc.
5.4.2 (Inkomende) signaleringen, meldingen en contacten
Het gaat hier om inkomende signaleringen, meldingen en contacten. De interne signalering wordt
beschreven in par. 5.4.4. Signalen en meldingen hebben betrekking op de situatie van een burger /
gezin. Er wordt iets (opmerkelijks) onder de aandacht gebracht. Daarnaast is er sprake van inter-
actie (contacten) tussen burger en hulpverleners. Hierbij valt te denken aan input van de burger op
het behandelplan, digitale communicatie tussen burger en hulpverlener.
93
S20. Inkomende signaleringen en meldingen (basis)
- Op basis van een bericht uit ieder kanaal (een webformulier, e-mail, een telefoongesprek, een
gesprek, maar ook een geautomatiseerd systeem) kan een signaal worden vastgelegd.
- Signaleringen kunnen zowel handmatig als geautomatiseerd worden ingevoerd.
- Een filtermechanisme zorgt ervoor dat het signaal eerst wordt getoetst aan de hand van door
de gemeente ingestelde en aanpasbare business rules, waarbij informatie uit andere bijvoor-
beeld bronsystemen worden opgehaald voordat het signaal wordt omgezet in een melding en
deze melding ook wordt doorgezet.
- Signalen kunnen automatisch én handmatig een prioriteit krijgen. Bijvoorbeeld: signaleringen
inzake veiligheid krijgen standaard een hoge urgentie
- De gemeente heeft de mogelijkheid om deze prioritering en de business rules zelf te configure-
ren.
- Een signaal bevat minimaal de volgende gegevens:
▪ Identificatie van de betreffende persoon, gezin
▪ Contactgegevens van de melder
▪ Relatie tussen melder en betrokken persoon / gezin
▪ De situatie die aanleiding gaf tot de melding
▪ De inhoud van de signalering
- Signalen verdwijnen (op basis van door Gemeente in te stellen bewaartermijnen) uit het actie-
ve systeem: 'het recht om vergeten te worden'
- De toegang tot vastgelegde signalen wordt op basis van autorisatie geregeld
O51 Inkomende signaleringen en meldingen (additioneel)
Beschrijf alle eventuele additionele functionaliteiten inzake signaleringen / meldingen die stan-
daard onderdeel uitmaken van de 3D-suite en die relevant zijn in het kader van beoogd gebruik
als beschreven in hoofdstuk 2. Denk hierbij aan:
- Handmatig en geautomatiseerd invoeren van een signalering / melding, m.a.w. de wijze waar-
op de 3D-suite de mogelijkheid biedt om signaleringen direct in te voeren (bijvoorbeeld aan de
hand van een e-formulier).
- De mate waarin signaleringen / meldingen gestructureerd worden vastgelegd en dat vastleg-
gen gegevens verplicht gesteld worden
- Signalering / melding koppelen aan een burger/gezin (automatisch, bijv. o.b.v. BSN, of hand-
matig) en/of (lopend) behandelplan
- Doorvoeren van een signalering / melding voor follow-up. Dat kan een terugbelnotitie zijn, een
notitie/reminder, of een deelzaak. Uiteraard kan bij voorkeur aan een vervolgactie ook een
termijn incl. (interne) signalering / melding gekoppeld worden.
- De mate waarin bij het invoeren/vastleggen van een signaal in de 3D-suite de (meta)gegevens
op een efficiënte, gebruiksvriendelijke wijze kunnen worden vastgelegd t.b.v. zowel manage-
mentinformatie (t.b.v. sturing op een hoger niveau zoals inzake beleid of afspraken tussen or-
ganisaties) en de informatie voor de uitvoering.
- De mate waarin door de gemeente aanpasbare business rules worden toegepast t.b.v. priorite-
ring en gefilterd doorsturen, incl. hoe de regisseur de prioritering/filtering handmatig kan over-
rulen.
- De wijzen waarop een indiener een automatische bevestiging van zijn melding kan krijgen.
Er zijn landelijk steunpunten/systemen, die op deelterreinen (vroeg)signalering regelen. Zo is
94
rondom Algemeen Meldpunt Kindermishandeling en Steunpunten Huiselijk Geweld de signalering
van kindermishandeling en huiselijk geweld georganiseerd. In de Verwijsindex Risicojongeren
(VIR) kan jeugdproblematiek gemeld worden en via Suwinet kunnen hulpverleners in de sector
werk & inkomen elkaar informeren. Via de justitiële keten zullen de volgende signalen ontvangen
worden: „informering over maatregel jeugdbescherming en/of - reclassering‟, „melding onderzoek
gestart VTO‟, „melding ambtshalve onderzoek‟, „beslissing opleggen maatregel‟. De interactie tus-
sen gemeenten, gecertificeerde instellingen en VenJ uitvoeringsorganisaties zal verlopen via de
Collectieve Opdracht Routeer Voorziening13, conform de beschrijving in de Project Start Architec-
tuur van deze voorziening. Dit betekent ondermeer dat gebruik gemaakt moet worden van digi-
koppeling melding ebMS en gestandaardiseerde berichten. CORV zorgt voor een goede routering
en vertaling van berichten tussen het justitiedomein en het gemeentelijk domein.
O52 Contacten
Veel contacten tussen hulpverleners, gezin/burger en regisseur zijn niet in een standaardformaat
te vangen. Daarnaast zijn burgers vrij in het kiezen van het communicatiekanaal. Deze ogen-
schijnlijk ongestructureerde wijze van contact kan wel gestroomlijnd worden. Want meer struc-
tuur is nodig, zodat ook deze informatie toegankelijk en beschikbaar is. Bovendien wordt veel be-
lang gehecht aan een veilige manier van communicatie.
Beschrijf de mate waarin u het beoogd gebruik ondersteunt t.b.v. contacten, voor zover deze die
standaard onderdeel uitmaken van de 3D-suite en die naar uw mening relevant zijn. Denk hierbij
aan:
- De inzet van het burgerportaal, waarin de burger na te zijn ingelogd via een contactformulier
snel en eenvoudig vragen kan stellen aan de regisseur of anderen, en de hulpverlener de bur-
ger kan bereiken
- Gebruik van KCC-functionaliteit om telefonische contacten vast te leggen en evt. van follow-up
te voorzien.
- Door koppeling aan „Mijn Overheid‟ statusberichten (via „Lopende zaken‟) en ander berichten
(via de „Berichtenbox‟) beveiligd verzenden aan burgers.
5.4.3 Intake, doelstelling, maatregelselectie en ondersteu-
ningsplan
Dit omvat de fases/functies van intake, onderzoek, doelstelling, maatregelselectie en behandel
(ondersteunings)plan (zie par. 5.1.2). Het betekent niet dat in alle gevallen alle functies ingezet
worden noch impliceert het dat er sprake is van een vaste volgorde. In het behandelplan zijn de
afspraken tussen de burger/ het gezin en de regisseur vastgelegd. Het vormt het de basis, waarop
de ondersteuning wordt geleverd.
13 De desbetreffende PSA Keteninformatie is formeel vastgesteld in het opdrachtgeversoverleg stelselherziening
Jeugd (VNG, VWS en VenJ) op 25 juni 2013. Er zal (1) gegevens uitwisseling tussen gemeente, jeugdstraf-
rechtketen en jeugdbeschermingsketen gaan plaatsvinden, bijvoorbeeld een gestandaardiseerd Verzoek tot On-
derzoek (VTO) als startmoment voor de jeugdbeschermingsketen; ook zullen de gemeenten allerlei gestan-
daardiseerde berichten uit de justitiële jeugdketens ontvangen en (2) beleidsinformatie richting V&J. VWS, VenJ
en enkele gemeenten gaan hiervoor een proeftuin inrichten.
95
Er is sprake van één ondersteuningsplan, dat alle doelen bevat incl. de
maatregelen / taken / acties van zowel de burger zelf, zijn netwerk, gemeentelijke medewerkers,
als de betrokken uitvoeringsorganisaties.
Alle situaties (eenvoudig, complex, enkelvoudig, multi-probleem, vrijwillig en onder dwang) passen
in dit stramien. Juist omdat het flexibel is.
O53 Intake & onderzoek
T.b.v. intake en onderzoek kan een zo compleet mogelijk (binnen de kaders van wetgeving / pri-
vacy) overzicht van alle geleverde ondersteuning richtinggevend zijn voor het op te starten tra-
ject: betreft het een geheel nieuwe burger? Is er sprake van herhaling, terugval wellicht? Is er op
andere terreinen recent ondersteuning gevraagd en toegewezen? Etc.
Beschrijf alle functionaliteiten inzake Intake & onderzoek die standaard onderdeel uitmaken van
de 3D-suite en die naar uw mening relevant zijn. Denk hierbij aan:
- Het complete klantbeeld (zie ook par. 5.4.1)
- Direct, on line inzicht in de ingediende (aan)vraag
- Direct, on line inzicht in de resultaten van de vraagverheldering, indien de burger die evt.
voorafgaand aan de ingediende aanvraag of afspraak heeft ingevuld.
- Direct, online inzicht in afgesloten trajecten.
- Functionaliteit voor een casusoverleg t.b.v. bespreking van de situatie van de burger (casus) in
een team van professionals.
De intake hoeft niet één regisseur en één burger (of gezin) te betreffen. Ook mantelzorgers
kunnen een rol spelen, net als andere professionals. Beschrijf de mate waarin een een regisseur
ondersteunt wordt om ad-hoc rollen en taken te toebedelen.
O54 Ondersteuning tijdens intakegesprekken
Beschrijf tevens de ondersteuning v.w.b. diagnose en zelfdiagnose: welke mogelijkheden zijn er
voor de regisseur én de burger om de intake en diagnose bijvoorbeeld aan de hand van een
beslisboom zelf uit te voeren. Zie ook het voorbeeld in bijlage 0.
Beschrijf ook de wijze waarop de Zelfredzaamheidsmatrix en de Participatieladder (en evt.
vergelijkbare instrumenten) door de medewerker en de burger zelf zijn in te zetten. Geef daarbij
aan op welke wijze dergelijke instrumenten geïntegreerd zijn in de 3D-suite. Is er bijvoorbeeld
sprake van een intake-vragenlijst op basis van de Zelfredzaamheidsmatrix? Op welke wijze is de
Zelfredzaamheidsmatrix gekoppeld aan de doelstellingen en de maatregelen?
Er is vaak sprake van overleg bij de burger thuis. Ook dan zal de 3D-suite beschikbaar moeten
zijn, zowel om gegevens/ documenten te raadplegen als ook gegevens/ documenten toe te
voegen/ te wijzigen. Beschrijf de wijze waarop dat mogelijk is, bijvoorbeeld door –beveiligd- een
subset van data mee te nemen, of door een versie van de applicatie te bieden die bruikbaar is
i.c.m. mobiele toegang.
G22 Het plan (doelstelling, maatregelselectie en opstellen plan) (basis)
In toenemende mate zal een mix van professionele en informele ondersteuning de oplossing bie-
den. Handwerk van de regisseur blijft nodig, maar een voorstel van het systeem kan hem daarbij
zeker helpen. Zowel het voorstel als de uiteindelijke keuze van de regisseur (en burger) worden
96
vastgelegd, zodat later op basis van nadere analyses de regisseur betere keuzes kan maken en
het systeem beter ingeregeld kan worden.
De functionaliteiten inzake intake & onderzoek die standaard onderdeel uitmaken van de 3D-suite
omvatten ten minste:
G22.1
- Gestructureerd vastleggen van doelen per gezin. Er zijn per gezin meerdere doelen mogelijk
waarbij het te bereiken doel verschilt per leefdomein. Doelen kunnen ook aan specifieke ge-
zinsleden gekoppeld worden.
- Relaties/ afhankelijkheden tussen de doelen vastleggen.
G22.2
- Vastleggen van met de klant afgestemde de termijnen waarop doelen gehaald worden.
G22.3
- Vastleggen van evaluatiemomenten waarop geëvalueerd wordt of de doelen bereikt zijn
G22.4
- De mogelijkheid om vast te leggen in hoeverre de doelen bereikt zijn op een evaluatiemoment,
ten minste o.b.v. tekstvelden.
G22.5
- De mogelijkheid om één of meer maatregelen (taken/acties, zie paragraaf 5.4.4) te selecteren
en te koppelen aan de vastgestelde doelen z.d.d. maatregelen aan doelen zijn te matchen.
G22.6
- Vastleggen van de termijnen waarop de taken uitgevoerd dienen te zijn (gerelateerd aan de
ter-mijnen van de doelen)
G22.7
- Vastleggen van de kosten van de geselecteerd acties (mogelijkheid om bij acties standaard-
kosten op te nemen), ten minste o.b.v. tekstvelden
G22.8
- Vastleggen van de uitvoerder of uitvoerders van de acties (gezin, omgeving, en/of professione-
le ondersteuners)
G22.9
- Verschaffen van actuele totaaloverzichten per plan incl. doelen, taken, kosten, termijnen, ge-
kozen ondersteuners, etc.
O55 Het plan (doelstelling, maatregelselectie en opstellen plan)
Beschrijf alle aanvullende functionaliteiten inzake intake & onderzoek die standaard onderdeel
uitmaken van de 3D-suite en die naar uw mening relevant zijn bij het opstellen – en tijdens uit-
voering zonodig aanpassen – van een ondersteuningsplan. Denk hierbij aan de mate waarop de
regisseur, burger en ondersteuner worden ondersteund bij het vastleggen van de in voorgaande
wens gevraagde aspecten en:
- Gestructureerd vastleggen van doelen per gezin bij voorkeur o.b.v. een instrument / methode
als de Zelfredzaamheidsmatrix
- De wijze waarop afhankelijkheden tussen doelen worden vastgelegd (eerst doel 1 en 2, als dat
97
gereed is doel 3 en tenslotte doel 4).
- De mogelijkheid om de realisatie van doelen vast te leggen in kwantitatieve en kwalitatieve zin
(bijv. zelfredzaamheid inkomen was 1 en groeit in 3 jaar naar 4, met een beschrijving van de
eindsituatie)
- De mogelijkheid om vast te leggen in hoeverre de doelen bereikt zijn op een evaluatiemoment
(zelfredzaamheid „inkomen‟ is nu 3 en verbeterd, en 60% is gerealiseerd).
- De mogelijkheid om één of meer maatregelen (taken/acties, zie paragraaf 5.4.4) te selecteren
en te koppelen aan de vastgestelde doelen z.d.d. maatregelen bij voorkeur door de 3D-Suite
aan doelen zijn te matchen.
- Taken selecteren o.b.v. standaardlijsten (bijv. dienstenboek) maar ook ad-hoc acties opnemen
(oma gaat helpen schoonmaken, of bijv. een dienst van een niet eerder bekende organisatie).
- Vastleggen van relaties tussen de taken (bijv. o.b.v. gerelateerde zaken)
- Vastleggen van de kosten van de geselecteerd acties (mogelijkheid om bij acties standaard-
kosten op te nemen), ten minste o.b.v. tekstvelden doch bij voorkeur ook gestructureerde vel-
den i.r.t. voornoemde standaardlijsten (bijv. dienstenboek)
- Aanvullende informatie over bijvoorbeeld „best practices‟ (een succesvolle aanpak in een ver-
gelijkbare situatie).
- Verschaffen van actuele informatie over de ondersteuner zoals wachttijden.
- Informatie over collectieve voorzieningen en informele ondersteuning
- Ondertekenen van het behandelplan. Hierbij kan gedacht worden aan de inzet van digitale
handtekening
- Actuele totaaloverzichten per plan incl. doelen, taken, kosten, termijnen, gekozen ondersteu-
ners, etc. zijn bij voorkeur realtime / dynamisch (zodra het plan wordt aangepast worden de
overzichten automatisch aangepast).
- Etc.
5.4.4 Taken/acties incl. signalen en ketenberichten
Het ondersteuningsplan is vastgesteld. Vervolgens gaat het om een effectieve, samenhangende
uitvoering van de acties uit het plan. Op hoofdlijnen omvat dit:
- Uitzetten van de acties
- Bewaken van de acties (verloopt het conform de afspraken?)
- Bewaken en evt. bijstellen van het ondersteuningsplan
- Evalueren van het ondersteuningsplan (zijn de resultaten, doelen bereikt?)
- Nazorg
De regisseur bewaakt de voortgang en kwaliteit van het totale ondersteuningsplan, maar is niet
noodzakelijkerwijs verantwoordelijk voor de uitvoering van de afzonderlijke acties. Dat is het
domein van de tweedelijns professionals/ondersteuners.
Het ondersteuningsplan is dynamisch. Dat wil zeggen, tijdens de uitvoering kan het plan bij
voorkeur eenvoudig aangepast worden op alle onderdelen ervan (doelen, termijnen, acties, de
volgorde van doelen en acties, uitvoerders). Het systeem laat bij voorkeur ook zien wat de
gevolgen zijn van die aanpassingen (in kosten, doorlooptijden etc.). Het draait dus om flexibiliteit
(ad-hoc en snel doorvoeren van aanpassingen), integrale aanpak en samenhang.
In Bijlage 0 is als referentie een aantal van huidige hoofdprocessen van Awbz, Wmo en Jeugdzorg
opgenomen. De 3D-Suite moet bij deze indelingen passen.
98
Hier worden de functionaliteit gevraagd, die aanvullend is op de generieke
functies, zoals genoemd in hoofdstuk 4. Daar is veelal uitgegaan van de zaakgericht werken-
concepten. Het proces rond de regie op het ondersteuningsplan (het ondersteuningstraject) vormt
dan bijvoorbeeld de hoofdzaak, met waar nodig losse maatregelen als verschillende deelzaken
(taken die zijn uitgezet bij verschillende hulpverleners). Binnen iedere zaak (incl. de hoofdzaak)
kunnen dan zowel aanvullende statussen worden toegevoegd, als aanvullende deelzaken.
O56 Inrichting processen / zaken
Beschrijf de wijze waarop u de standaard procesinrichting modelleert o.b.v. de in hoofdstuk 4
gevraagde / aangeboden functionaliteiten. Denk daarbij aan o.a.
- Inrichten van ondersteuning (hoofdzaak per ondersteuningsplan + deelzaken met maatregel?)
- Zowel de mogelijkheden tot modelleren door functioneel beheer als ad-hoc aanpassing
- Het op ten minste op hoofdlijnen modelleren van (deel)zaaktypen als „aanvraag subsidie‟) en
daar naar verwijzen vanuit dienstenboek.
- Hoe onverwachte of anderszins niet gemodelleerde maatregelen („oma past op‟) ad-hoc zijn in
te richten én bewaken, bijv. middels een standaard zaaktype met enkele statussen die regis-
seur zelf zet en enkele generieke velden met afgesproken resultaten en tijden
- Per status een aantal standaardvelden en taken / vinkjes
- Etc.
O57 Uitzetten van taken
Beschrijf alle functionaliteiten op het gebied van uitzetten/verdelen van taken (in de vorm van
een deelzaak of evt. een los mailtje), die standaard onderdeel uitmaken van de 3D-Suite. Denk
hierbij aan:
Het meegeven van voor uitvoering van de taak noodzakelijke informatie. Het gaat hier om
(delen van) gegevens en het dossier (documenten). Dat betreft zowel informatie over het on-
dersteuningsplan als geheel, zodat voor iedere professional de context duidelijk is (integraal
werken), als informatie over de taak/taken.
Het meegeven van informatie over de uitvoering. M.a.w. de regisseur kan instruc-
ties/verzoeken/aandachtspunten meegeven over de afhandeling. Dat kan zowel gebaseerd
zijn op vooraf vastgestelde (contract) afspraken als op afspraken, die specifiek voor de case
gelden.
Het uitzetten van taken naar:
- de (professionele) ketenpartners
- de individuele burger
- het gezin
- relaties in het netwerk van de burger/ het gezin
Het uitzetten van taken op basis van relaties/afhankelijkheden, zoals vastgelegd in het On-
dersteuningsplan.
De mate waarin de 3D-Suite de mogelijkheid biedt om handmatig en bij voorkeur ook auto-
matisch een (vervolg)taak weg te zetten, zodra aan de voorwaarde is voldaan (bijvoorbeeld:
eerst moet een onderzoekstaak uitgevoerd worden, voordat een behandeltaak kan starten).
Dit kan ingeregeld worden, zodat het automatisch wordt uitgevoerd, maar de regisseur kan
ook kiezen voor een attendering (signaal), waarop hij zelf (handmatig) de behandeltaak door-
zet.
De wijze waarop taken worden uitgezet: bij voorkeur zowel via deelzaken (die parallel worden
uitgevoerd en separaat worden bewaakt) als in de vorm van een aparte status (seriële uit-
99
voer) binnen een zaak of deelzaak.
Het uitzetten van taken valt grotendeels samen met het geven van een opdracht om een indivi-
duele voorziening te leveren. Ook de fase „Toeleiding‟ uit het Bedrijfsfunctiemodel van IZO (zie
bijlage 1) valt hiermee min of meer samen. In de (huidige) praktijk selecteert de regisseur (sa-
men met de burger) de ondersteuner en die krijgt de opdracht/ de taak om de ondersteuning te
leveren volgens de voorwaarden uit het contract. Er dienen zich ook andere toewijzingsmethodes
aan. Eén van die methodes is het „Veilingmodel‟. Via aanbesteding worden vooraf alle mogelijke
ondersteuners via een raamcontract gecontracteerd. De individuele zorgvraag wordt anoniem ge-
publiceerd (op de veiling aangeboden), waarna de aangesloten ondersteuners een passende on-
dersteuning kunnen aanbieden. De beste ondersteuner mag de ondersteuning leveren. Er wordt
naast het algemene raamcontract per individu/ gezin een contract gesloten.
Beschrijf alle functionaliteiten op het gebied van uitzetten/verdelen van taken en geef daarbij aan
welke toewijzingsmethodes ondersteund worden. Ga daarbij expliciet in op de boven vermelde
„veilingmethode‟.
O58 Uitvoeren van taken
De uitvoering van taken vindt plaats in de eigen systemen van de uitvoerder. Het betreft dan een
deelzaak. Waar mogelijk worden gegevens/documenten uit die systemen automatisch doorgezet
naar de 3D-Suite. Het gaat om informatie, die bijdraagt het actueel en compleet houden van het
klantbeeld, die nodig is voor de regisseur in zijn regietaak en voor andere uitvoerende professio-
nals
Beschrijf alle functionaliteiten op het gebied van uitvoeren van taken, die standaard onderdeel
uitmaken van de 3D-Suite. Denk hierbij aan:
Toevoegen van gegevens over de deelzaak, zoals gewijzigde status, het resultaat, het besluit
Toevoegen van gegevens aan het klantbeeld/ -profiel. Voorbeeld: de uitvoering leidt tot ver-
betering van de situatie van de burger en (dus) tot een hogere score op de zelfredzaamheid-
matrix. Die „doorvertaling‟ zowel handmatig als geautomatiseerd uitgevoerd worden.
Toevoegen van documenten, waarbij tevens de autorisatie (voor wie toegankelijk) is geregeld
Toevoegen van notities, waarbij tevens de autorisatie (voor wie toegankelijk) is geregeld.
Hierbij kan men ook denken aan losse bevindingen c.q. kladnotities, die later verwerkt worden
in bijvoorbeeld rapportages.
Toevoegen van contact(notities). De 3D-Suite biedt functionaliteit voor het vastleggen van
notities n.a.v. telefonische c.q. fysieke contacten
Verzenden van berichten incl. notificatie.
Voorbeeld: in de uitvoering blijkt dat er extra gegevens van de burger nodig zijn. De professional
kan vanuit de taak direct een e-mail (brief) daaromtrent versturen of kan een attendering verstu-
ren. De burger kan dan via „Mijn omgeving‟ het verzoek/bericht inzien, waarna de burger bijvoor-
beeld aan de hand van een (deels vooringevuld) formulier de ontbrekende gegevens kan indie-
nen.
De genoemde functionaliteiten zullen gebruikt worden op het niveau van de taak, maar dienen op
het niveau van het Ondersteuningsplan of op het niveau van het individu of samenstel van indivi-
duen (gezin) beschikbaar te zijn. De essentie is dat informatie op het juiste niveau wordt gekop-
peld/opgeslagen.
100
O59 Signalering en bewaking
Bij het uitvoeren van de taak gaat het vooral om de inhoud. Er worden handelingen uitgevoerd,
die de burger verder (meer zelfredzaam) moeten brengen. Het gaat om kwaliteit (wordt het be-
oogde resultaat behaald volgens de gemaakte afspraken?) Goede afstemming en communicatie is
een vereiste. Naast kwaliteit speelt tijd een belangrijke rol. Beide moeten bewaakt worden, zowel
op taak- als op het ondersteuningsplan-niveau.
Beschrijf alle functionaliteiten op het gebied van bewaking en signalering, die standaard onderdeel
uitmaken van de 3D-Suite. Denk hierbij aan:
- Het automatisch vastleggen van alle acties incl. tijdstip tijdens de uitvoering van de deelzaak
- Het vastleggen van informatie op het juiste niveau (betreft het de burger, een specifiek be-
handeltraject / zaak, een maatregel / subzaak, etc). Het betreft de voortgang van het totale
ondersteuningsplan, maar ook de voortgang van een specifieke taak/actie voor een burger als
ook een gecombineerde set van acties voor een burger als ook acties voor een gezin. Kortom,
een ondersteuningsplan kan veel acties voor veel betrokkenen bevatten. Die acties (en het to-
tale ondersteuningsplan) dienen in verschillende combinaties bewaakt te kunnen worden.
- De mogelijkheid om percentage-gereed vast te leggen voor de realisatie van de acties (som-
mige acties lopende gedurende en aantal maanden en dan is soms zinvol te weten welke % de
actie gereed is).
- Signaleringen: ten minste van statuswijzigingen, nieuwe informatie / documenten en (dreigen-
de) overschrijding van norm- en streefdata en –termijnen.
▪ Beschrijf ook welke additionele informatie/ functionaliteit beschikbaar is. Bijvoorbeeld: indi-
catie met kleuren of anderszins. Standaard aanduiding/ presentatie van urgentie c.q. be-
lang.
▪ Beschrijf de functionaliteit voor het instellen wanneer een signaal moet worden afgegeven.
- Doorlooptijden (norm- en streefdata en –termijnen). De 3D-Suite biedt functionaliteit voor
termijnbewaking. Hierbij worden ten minste de volgende termijnen bewaakt: normtermijn.
Streeftermijn. Dat kan het gehele ondersteuningsplan betreffen of een actie of een individu of
een samenstel van individuen (een gezin) of een samenstel van acties.
- Reminders. De 3D-Suite biedt functionaliteit om een reminder te kunnen zetten. Daarbij kan
het „afgaan‟ van de reminder gezet worden op een bepaalde datum of na een bepaalde ter-
mijn. Het „afgaan‟ van de reminder veroorzaakt een notificatie. De reminder kan ook een korte
notitie bevatten, waardoor de regisseur/uitvoerder niet alleen tijdig wordt gesignaleerd, maar
ook input meekrijgt voor de te volgen actie.
- Bewaking op besluiten en resultaten. Zeker in multi-probleemsituaties en complexe trajecten
worden vele besluiten genomen en resultaten geboekt. Voor de regisseur, maar ook voor an-
dere professionals is het handig indien de besluiten en resultaten in samengevatte (liefst grafi-
sche) vorm toegankelijk zijn, Vanuit deze „samenvatting‟ kan dan worden doorgeklikt naar de
achterliggende informatie/stukken. Als denkrichting is hieronder een „Besluitenlijn‟ weergege-
ven.
101
- Het systeem dient de regisseur hierbij zo goed mogelijk te ondersteunen, bij voorkeur door per
doel te laten zien welke acties gereed zijn en in hoeverre de afgesproken (wellicht bijgestelde)
doelen gerealiseerd zijn (bijv. „zelfredzaamheid inkomen is op het afgesproken niveau‟).
- Kwaliteit betreft enerzijds de kwaliteit van het proces, m.a.w. is de afhandeling volgens de
procedures verlopen. Voor overheidsorganisaties is de rechtmatigheid een belangrijk aspect in
de kwaliteit. Anderzijds staat de vraag centraal of de resultaten behaald zijn en de doelen be-
reikt. Beschrijf de functionaliteit die de kwaliteitsbewaking van zowel het proces als van de
outcome ondersteunt.
- Acties (Meldingen kunnen als ad hoc acties gezien worden. Bijvoorbeeld: een regisseur kan
vanuit zijn (frequente) contact met de burger een melding doorzetten naar één van de profes-
sionals om bijvoorbeeld de taakuitvoering op te schorten vanwege gewijzigde omstandighe-
den)
O60 Ketenberichten
In de keten van de uitvoering (van plan t/m nazorg) vinden veel berichten plaats. Taken worden
uitgezet. Statusberichten worden handmatig of automatisch uit backofficesystemen naar de 3D-
suite teruggekoppeld. Ook het terugkoppelen van resultaten en financiële gegevens is gewenst.
Beschrijf de wijze waarop ketenberichtenverkeer plaatsvindt en de mate waarop dit geautomati-
seerd plaatsvindt. Ga daarbij vooral in op de automatische uitwisseling (via lees- en/of schrijfkop-
pelingen) tussen de 3D-suite en backofficesystemen van ondersteuners, aanvullend aan mogelijk-
heden voor uitvoeringsorganisaties om (ook) handmatig statussen en %-gereed te zetten.
Beschrijf ook welke standaarden in berichtenverkeer ondersteund wordt. Bijvoorbeeld: StUF-
zaken, AZR, e.d. Zie ook hoofdstuk 7.
5.4.5 Procesbewaking/evaluatie/nazorg
O61 Evaluatie
Evaluatie kan ook als een vorm van kwaliteitsbewaking gezien worden. Het is een eindcontrole op
het totale Ondersteuningsplan, waarin een aantal aspecten gemonitord worden. Beschrijf alle
functionaliteiten op het gebied van evaluatie, die standaard onderdeel uitmaken van de 3D-Suite.
Denk hierbij aan:
- De inzet van de zelfredzaamheidmatrix (incl. doorvertaling naar het klantprofiel)
- Inzet van klanttevredenheidsonderzoek. Hierbij kan ook sprake zijn van onderzoeken (vragen-
102
lijsten) van externe partijen. De uitkomsten van onderzoeken dienen (rekening houdend met
autorisatie en privacy) toegevoegd worden aan het Ondersteuningsplan.
- Input van de ondersteuners en andere betrokkenen
- Gespreksverslagen
- Gestructureerd vastleggen van informatie. De kern is een goede afronding van het individuele
Ondersteuningsplan. Door een juiste opzet en waar mogelijk gebruik te maken van gestructu-
reerde informatie wordt een goede basis voor managementinformatie gelegd.
Adequate en gerichte informatie kan opgedaan worden door meer continu te monitoren. Al de
metingen en meningen bij elkaar opgeteld geven een beter beeld van het totale proces, de (kwali-
teit van) afzonderlijke taken, acties, contacten en communicatie.
Beschrijf alle functionaliteiten op het gebied van continue monitoring, die standaard onderdeel
uitmaken van de 3D-Suite.
O62 Nazorg
Beschrijf alle functionaliteiten op het gebied van nazorg, die standaard onderdeel uitmaken van
de 3D-Suite. Denk hierbij aan:
De relatie met het afgeronde ondersteuningsplan
Latere signaleringen relateren aan eerdere ondersteuningsplannen
Op door de regisseur te bepalen intervallen een bezoek door regisseur of wijkteam inplannen
Etc.
103
5.5 Regie op regie (budget, contract, kwali-teit, etc.)
Onder „Regie op regie‟ verstaan we hier het sturen op doeltreffendheid met als twee subdoelen: het
sturen op effectiviteit van handelen (best practices/ wijkaanpak, doelgroepaanpak) en het sturen
op resultaat (gemaakte afspraken met externe partners, maar ook op de beweging van intensieve
naar eenvoudige ondersteuning naar zelf doen). Daarnaast gaat het om sturen op efficiency (bud-
getten/ realisatie). Het betreft hier dus niet het regisseren van de ondersteuning van individuele
burgers dan wel een gezin. Zie ook par. 2.5.
Sturingsinformatie is van belang voor de regisseur maar ook voor beleidsmedewerkers.
Hieronder is een aantal voorbeeld opgenomen van het soort sturingsinformatie dat geleverd moet
worden. [Deze opsomming is niet limitatief en zal nader met de opdrachtgever uitgewerkt moeten
worden, bij voorkeur zo veel mogelijk vóór aanvang van een selectietraject. Waar dit later gebeurt,
zullen de deliverables helder moeten zijn, teneinde de hoeveelheid meerwerkkosten te minimalise-
ren.]
De informatie die zoveel mogelijk grafisch weergegeven zou moeten worden:
- Overzichten per straat, buurt, wijk, dorp, gemeente van:
o Ondersteuningsvragen
o Ingezette ondersteuningsacties
o % gerealiseerde doelen per gezin
o Zelfredzaaamheid per domein
o Wijzigingen op zelfredzaaamheid per domein
- Effectiviteit per leverancier
o Per leverancier % gerealiseerde doelen,
o Per leverancier % doelen gereed binnen termijn
o % activiteiten gerealiseerd binnen termijn
- Trends in de tijd (maand, kwartaal, jaar) per wijk, leverancier, etc., op:
o Soorten ondersteuningsvragen van klanten
o Ingezette soort ondersteuning
o Gerealiseerde kosten
- Financiële rapportages
o Gerealiseerde kosten per straat, buurt, wijk, dorp, gemeente. Per periode (maand,
kwartaal, jaar)
o Gerealiseerde kosten per periode per leverancier
o Kosten per gezin per periode
o Kosten per type doelstelling (gerelateerd aan Zelfredzaamheidsmatrix)
o Kosten per type ondersteuningvraag
O63 Sturingsinformatie
Beschrijf op welke wijze de 3D-suite basisgegevens aandraagt voor de bovengenoemde sturings-
informatie.
Schenk daarbij vooral aandacht aan de mate waarin het merendeel van de gegevens tot stand
komen in de uitvoering, m.a.w. er behoeft niet/nauwelijks apart gegevens toegevoegd te worden
t.b.v. de sturing op tactische of strategisch niveau.
Maak onderscheid tussen:
104
- een door de gemeente aanpasbare/parameteriseerbare basisset van relevante rapportages,
geef een lijst van rapportages die u gegeven het in par. 2.5 geschetste gebruik aanbiedt
- de mate waarin tevens meer ad-hoc vragen worden ondersteund, zoals informatie t.b.v. ge-
meenteraad of tweede kamer: gebeurt dat binnen uw suite of via een BI-tool?
O64 Aansturing teams
Beschrijf op welke wijze de 3D-suite ondersteuning biedt voor operationele en/of strategische
aansturing en regie van/over wijkteams of andere groepen regisseurs (bijv. door een
wijkmanager), aanvullend aan de casusoverleggen als beschreven in O3 op blz. 45.
Denk daarbij aan aanvullende teamoverleg- en sturingsfunctionaliteit maar ook aan (bij voorkeur
interactieve) rapportages zoals
- (Wijk)budget in Euro en uitputting daarvan over de tijd
- (Wijk)budget in besteedbare uren en uitputting daarvan over de tijd
- Bewaken resultaten per wijk, per gemeente: zowel financieel als inhoudelijk (gehaalde doelen,
etc.)
- Kosten (in euro en uren) van regie
- Bewaken caseloads per regisseur, per groep, etc.
Beschrijf tevens in welke mate de 3D-suite ondersteuning biedt aan forecasting, zowel v.w.b.
budgetten als workloads . Wat valt de komende tijd te verwachten, waar dient de regisseur reke-
ning mee te houden?
105
5.6 Standaardcontent
Voor standaardcontent zou er idealiter landelijk beheerde content moeten komen zoals nu
bijvoorbeeld door Stichting opvoeden.nl wordt opgesteld. Voor het hele sociale domein zou
dergelijke content moeten komen in een format welke in elke gemeentelijke website is in te lezen.
Te denken valt aan informatie over mantelzorg, ouders van licht verstandelijk gehandicapten,
psychogeriatrie, jeugd GGZ, etc. Deze aanpak is financieel aantrekkelijk voor de gemeenten omdat
de content maar op een plek ontwikkeld en actueel gehouden hoeft te worden (vergelijk de
gemeentelijke PDC-contentabonnementen nu). Tevens is er het voordeel dat het niet uitmaakt
waar de burger ook zoekt, iedere keer de burger bij de zelfde informatie uitkomt (ongeacht
gemeente en/of kanaal). Daarmee waarborgt de gemeente de betrouwbaarheid van de informatie
die ze aan de burger beschikbaar stelt.
O65 Standaardcontent
Geef aan of de 3D-Suite geleverd worden met standaardcontent en - zo ja - beschrijf deze. Geef
daarbij steeds duidelijk aan welke informatie beschikbaar is en in welke mate deze aanpasbaar is.
Denk in dat kader bijvoorbeeld aan:
- Standaard zaaktypen, processen: zowel v.w.b. primaire functies (ondersteuningsplan, uitzetten
vak taken, etc.) als secundaire functies zoals mandatering
- Meegeleverde vraaggeleiding / beslisbomen
- Meegeleverde informatie over producten / diensten (zoals wanneer en voor wie van toepas-
sing, procedurebeschrijvingen, eventuele benodigde informatie en/of bescheiden, van toepas-
sing zijnde wet- en regelgeving, relevante termijnen en dergelijke)
- Meegeleverde veelgestelde vragen (FAQ‟s)
- Meegeleverde sociale kaart(en)
Maak daarbij onderscheid tussen door Contractant in eigen beheer ontwikkelde en onderhouden
content, en het standaard mee kunnen leveren van eventuele landelijk ontwikkelde en beheerde
content op het gebied van 3D.
O66 Gebruik van de facto content
Geef aan of de 3D-Suite gebruik maakt van/ een integratie/ koppeling heeft met standaardcontent
van content leveranciers, zoals bijv:
- Content van Regelhulp
- Thesaurus zorg en welzijn
- Of andere bronnen, die in het sociale domein veelvuldig gebruikt worden.
Geef tevens aan in welke mate gemeenten deze content op fijnmazige onderdelen aan kan passen
zonder dat nieuwe versies van de content leverancier deze aanpassingen overschrijven.
O67 Import en export van klantendossiers
Wanneer een burger naar de gemeente verhuist is het denkbaar dat –wetgeving, privacy en
beveiliging in acht nemende– delen van klantdossiers van de andere gemeente geïmporteerd
106
kunnen worden. Beschrijf daartoe in welke mate (en o.b.v. welke standaarden: bijvoorkeur StUF-
Zaken en/of de Zaak-DMS-services 14) gestructureerde en ongestructureerde gegevens en
documenten kunnen worden geïmporteerd door een functioneel beheerder of regisseur.
Geef tevens aan in welke mate een regisseur wordt ondersteund bij het maken van een export
van een klantdossier, incl. selectie van privacygevoelige informatie, anonimiseren waar nodig of
mogelijk, en het evt. vervangen van „wat‟-informatie door „dat‟.
14 Zie ook https://new.kinggemeenten.nl/gemma/stuf/koppelvlakken/zs-dms
107
6 PvE: Gebruiksvriendelijkheid
Deze en de volgende hoofdstukken met eisen en wensen betreffen het geheel van generieke
functionaliteit (hoofdstuk 4) inclusief specifieke inrichting daarvan (hoofdstuk 5).
E8 Gebruiksvriendelijkheid: Nederlandstalig
Alle gebruikersinterfaces (incl. schermen, foutboodschappen, helpteksten, etc.) van de 3D-Suite
voor eindgebruikers en functioneel beheerders zijn volledig Nederlandstalig.
NB: De term „eindgebruiker‟ heeft hier betrekking op medewerkers van Gemeente (uitgezonderd
functioneel beheerders) en van daartoe geautoriseerde derden bij uitvoeringsorganisaties / ke-
tenpartners.
O68 Gebruiksvriendelijkheid: burgers
Beschrijf (incl. schermafbeeldingen) de gebruiksvriendelijkheid van alle browser- en eventuele
overige grafische interfaces van de 3D-Suite t.b.v. burgers voor wat betreft:
- Intuïtiviteit en consistentie van (de structuur van) de user interface (incl. de mate waarin tab-
volgorde consequent is doorgevoerd), navigatie, (context)menu‟s, toetsenbordgebruik, datum-
notatie, verplichte elementen, look & feel, etc. Beschrijf daarbij tevens in welke mate scher-
men als (proces)stappen met een logische bundeling/opeenvolging van handelingen worden
gepresenteerd, incl. de mogelijkheid om de functionaliteiten zoals beschreven in de verschil-
lende keten use cases te combineren resp. sequentieel uit te voeren.
- Schermindeling, inclusief minimale en maximale schermgrootte en resolutie.
- Helpfuncties en -teksten (on-/offline, contextgevoelig, taal, beschikbaarheid van mouse-overs,
etc.), incl. de wijze waarop foutboodschappen worden weergegeven (zoals: al dan niet voor-
zien van datum / tijd en het onderdeel waarop ze betrekking hebben, indicaties m.b.t. de ernst
van de fout, een - ook voor niet technisch onderlegde mensen begrijpelijke - inhoudelijke be-
schrijving, etc.).
- Het ongedaan maken (undo) van handelingen, incl. voor hoeveel en welke handelingen dit
kan.
- Inzicht in autorisatierestricties (zoals het verbergen/”uitgrijzen” van knoppen, tabs, menu‟s,
etc.).
- Het markeren van verplichten velden / handelingen (zoals met kleuren, symbolen, etc.).
- De mate waarin ze voldoen aan de Webrichtlijnen (v2.0), Drempels Weg, de W3C Richtlijnen
Toegankelijkheid (WCAG 2.0), etc.
▪ Mogelijkheden m.b.t. personalisatie (aanpasbaarheid van look & feel van interfaces), zoals:
▪ Huisstijl, stylesheets, logo‟s en dergelijke.
▪ Kleurgebruik, fontgrootte, contrast, resolutie en dergelijke.
▪ Indeling (navigatie, menu‟s, knoppen, tabbladen, vensters, etc.).
▪ Snelkoppelingen (vgl. „favorieten‟) en soortgelijke functies.
▪ Help- en andere teksten.
Beschrijf daarbij ook op welke wijze e.e.a. generiek (voor alle burgers) en/of specifiek (door indi-
viduele burgers) aanpasbaar is, alsmede of aanpassingen intact blijven na uit-/inloggen en bij
Nieuwe en Verbeterde Versies van de 3D-Suite.
Beschrijf (incl. schermafbeeldingen) ten slotte de mate waarin de 3D-Suite de burger ondersteunt
t.a.v. gegevensregistratie, behandeling van eigen taken/zaken, beslisbomen en controlelijsten,
informatie-/kennisbronnen, etc.
108
NB: De term “burger” heeft hier betrekking op zowel cliënten, als bewindvoerders, familieleden en
anderen die eventueel toegang hebben tot de 3D-Suite.
O69 Gebruiksvriendelijkheid: medewerkers
Beschrijf (incl. schermafbeeldingen) de gebruiksvriendelijkheid van alle browser- en eventuele
overige grafische interfaces van de 3D-Suite t.b.v. gebruikers voor wat betreft:
- Intuïtiviteit en consistentie van (de structuur van) de user interface (incl. de mate waarin tab-
volgorde consequent is doorgevoerd), navigatie, (context)menu‟s, toetsenbordgebruik, datum-
notatie, verplichte elementen, look & feel, etc. Beschrijf daarbij tevens in welke mate scher-
men als (proces)stappen met een logische bundeling/opeenvolging van handelingen worden
gepresenteerd, incl. de mogelijkheid om de functionaliteiten zoals beschreven in de verschil-
lende keten use cases te combineren resp. sequentieel uit te voeren.
- Schermindeling, inclusief minimale en maximale schermgrootte en resolutie.
- Toetsenbordgebruik (zoals control- en altfuncties, shortcuts, tabgebruik, functietoetsen, etc.),
incl. de mate waarin de 3D-Suite desgewenst geheel met het toetsenbord bediend kan worden.
- Helpfuncties en -teksten (on-/offline, contextgevoelig, taal, beschikbaarheid van mouse-overs,
etc.), incl. de wijze waarop foutboodschappen worden weergegevens (zoals: al dan niet voor-
zien van datum / tijd en het onderdeel waarop ze betrekking hebben, indicaties m.b.t. de ernst
van de fout, een - ook voor niet technisch onderlegde mensen begrijpelijke - inhoudelijke be-
schrijving, etc.).
- Het ongedaan maken (undo) van handelingen, incl. voor hoeveel en welke handelingen dit
kan.
- Inzicht in autorisatierestricties (zoals het verbergen/”uitgrijzen” van knoppen, tabs, menu‟s,
etc.).
- Het markeren van verplichten velden / handelingen (zoals met kleuren, symbolen, etc.).
- De mate waarin ze voldoen aan de Webrichtlijnen (v2.0), Drempels Weg, de W3C Richtlijnen
Toegankelijkheid (WCAG 2.0), etc.
▪ Mogelijkheden m.b.t. personalisatie (aanpasbaarheid van look & feel van interfaces), zoals:
▪ Huisstijl, stylesheets, logo‟s en dergelijke.
▪ Kleurgebruik, fontgrootte, contrast, resolutie en dergelijke.
▪ Indeling (navigatie, menu‟s, knoppen, tabbladen, vensters, etc.).
▪ Snelkoppelingen (vgl. „favorieten‟) en soortgelijke functies.
▪ Help- en andere teksten.
Beschrijf daarbij ook op welke wijze e.e.a. generiek (voor alle gebruikers) en/of specifiek (door
individuele gebruikers) aanpasbaar is, alsmede of aanpassingen intact blijven na uit-/inloggen en
bij Nieuwe en Verbeterde Versies van de 3D-Suite.
Beschrijf (incl. schermafbeeldingen) tenslotte de mate waarin de 3D-Suite de gebruikers
ondersteunt t.a.v. gegevensregistratie, zaakbeheer en –behandeling, documentcreatie,
(management)rapportage, beslisbomen en controlelijsten, informatie-/kennisbronnen, etc.
NB: De term “gebruiker” heeft hier betrekking op medewerkers van Gemeenten en ketenpartners
(uitgezonderd functioneel en technisch beheerders).
O70 Gebruiksvriendelijkheid: functioneel beheerders
Beschrijf (incl. schermafbeeldingen) de gebruiksvriendelijkheid van alle browser-, grafische en
109
command line interfaces van de 3D-Suite t.b.v. functioneel beheerders voor wat betreft:
- Intuïtiviteit en consistentie van (de structuur van) de user interface (incl. de mate waarin tab-
volgorde consequent is doorgevoerd), navigatie, (context)menu‟s, toetsenbordgebruik, datum-
notatie, verplichte elementen, look & feel, etc. Beschrijf daarbij tevens in welke mate scher-
men als (proces)stappen met een logische bundeling/opeenvolging van handelingen worden
gepresenteerd, incl. de mogelijkheid om de functionaliteiten zoals beschreven in de verschil-
lende keten use cases te combineren resp. sequentieel uit te voeren.
- Schermindeling, inclusief minimale en maximale schermgrootte en resolutie.
- Toetsenbordgebruik (zoals control- en altfuncties, shortcuts, tabgebruik, functietoetsen, etc.),
incl. de mate waarin de 3D-Suite desgewenst geheel met het toetsenbord bediend kan worden.
- Helpfuncties en -teksten (on-/offline, contextgevoelig, taal, beschikbaarheid van mouse-overs,
etc.), incl. de wijze waarop foutboodschappen worden weergegeven (zoals: al dan niet voor-
zien van datum / tijd en het onderdeel waarop ze betrekking hebben, indicaties m.b.t. de ernst
van de fout, een - ook voor niet technisch onderlegde mensen begrijpelijke - inhoudelijke be-
schrijving, etc.).
- Het ongedaan maken (undo) van handelingen, incl. voor hoeveel en welke handelingen dit
kan.
- Inzicht in autorisatierestricties (zoals het verbergen/”uitgrijzen” van knoppen, tabs, menu‟s,
etc.).
- Het markeren van verplichten velden / handelingen (zoals met kleuren, symbolen, etc.).
- De mate waarin ze voldoen aan de Webrichtlijnen (versie 1.3 / 2.0), Drempels Weg, de W3C
Richtlijnen Toegankelijkheid (WCAG 2.0), etc.
▪ Mogelijkheden m.b.t. personalisatie (aanpasbaarheid van look & feel van interfaces), zoals:
▪ Huisstijl, stylesheets, logo‟s en dergelijke.
▪ Kleurgebruik, fontgrootte, contrast, resolutie en dergelijke.
▪ Indeling (navigatie, menu‟s, knoppen, tabbladen, vensters, etc.).
▪ Snelkoppelingen (vgl. „favorieten‟) en soortgelijke functies.
▪ Help- en andere teksten.
Beschrijf daarbij ook op welke wijze e.e.a. generiek (voor alle gebruikers) en/of specifiek (door
individuele gebruikers) aanpasbaar is, alsmede of aanpassingen intact blijven na uit-/inloggen en
bij Nieuwe en Verbeterde Versies van de 3D-Suite.
Beschrijf (incl. schermafbeeldingen) tenslotte - aan de hand van concrete voorbeelden - de mate
waarin de 3D-Suite functioneel beheerders ondersteunt t.a.v. de functionele beheeraspecten zoals
gevraagd in dit document.
O71 [Gebruiksvriendelijkheid: technisch beheerders]
Beschrijf (incl. schermafbeeldingen) de gebruiksvriendelijkheid van alle browser-, grafische en
command line interfaces van de 3D-Suite t.b.v. technisch beheerders voor wat betreft:
- Intuïtiviteit en consistentie van (de structuur van) de user interface (incl. de mate waarin tab-
volgorde consequent is doorgevoerd), navigatie, (context)menu‟s, toetsenbordgebruik, datum-
notatie, verplichte elementen, look & feel, etc. Beschrijf daarbij tevens in welke mate scher-
men als (proces)stappen met een logische bundeling/opeenvolging van handelingen worden
gepresenteerd, incl. de mogelijkheid om de functionaliteiten zoals beschreven in de verschil-
lende keten use cases te combineren resp. sequentieel uit te voeren.
110
- Schermindeling, inclusief minimale en maximale schermgrootte en resolutie.
- Toetsenbordgebruik (zoals control- en altfuncties, shortcuts, tabgebruik, functietoetsen, etc.),
incl. de mate waarin de 3D-Suite desgewenst geheel met het toetsenbord bediend kan worden.
- Helpfuncties en -teksten (on-/offline, contextgevoelig, taal, beschikbaarheid van mouse-overs,
etc.), incl. de wijze waarop foutboodschappen worden weergegeven (zoals: al dan niet voor-
zien van datum / tijd en het onderdeel waarop ze betrekking hebben, indicaties m.b.t. de ernst
van de fout, een - ook voor niet technisch onderlegde mensen begrijpelijke - inhoudelijke be-
schrijving, etc.).
- Het ongedaan maken („undo‟) van handelingen, incl. voor hoeveel en welke handelingen dit
kan.
- Inzicht in autorisatierestricties (zoals het verbergen/”uitgrijzen” van knoppen, tabs, menu‟s,
etc.).
- Het markeren van verplichten velden / handelingen (zoals met kleuren, symbolen, etc.).
Beschrijf (incl. schermafbeeldingen) tenslotte - aan de hand van concrete voorbeelden - de mate
waarin de 3D-Suite technisch beheerders ondersteunt t.a.v. de technische beheeraspecten.
O72 Gebruik van tablets en mobile devices
Beschrijf de mate waarin er beperkingen en/of juist aanvullende functionaliteiten zijn in gebruik
van het systeem via mobiele devices (tablets / smartphones). Denk bijvoorbeeld aan het gebruik
van responsive design (waarbij weergave en functionaliteit aangepast worden aan het device),
het wel of niet downloaden en toevoegen van documenten, afhankelijkheden van 3G / mobiele
ontvangst (en de consequenties van het wegvallen van de verbinding), etc.
Beschrijf tevens de eventuele impact op beveiliging bij gebruik via mobiele apparaten, zoals
v.w.b. encryptie en verlies van apparatuur.
Maak waar nodig onderscheid per rol (burger, regisseur, etc.).
O73 Visie op minimalisering administratieve lasten
We realiseren ons dat we veel functionaliteiten uitvragen. Het gebruiksgemak voor de burger,
maar ook de professional is zeer belangrijk. De administratieve lastenverlichting voor de regisseur
is daarbij ook van groot belang. Deze zal bij voorkeur zo weinig mogelijk registreren „om het
registreren‟, zoveel mogelijk t.b.v. regie-op-regie of anderszins benodigde informatie wordt vanuit
het proces gevormd. Er zal zodoende een afweging tussen functionaliteit (bijv.: veel informatie
uitvragen t.b.v. rijke managementinformatie) en gebruiksgemak gemaakt kunnen worden.
Geef in dat kader uw visie op de wijze waarop en de mate waarin uw 3D-Suite de administratieve
lasten voor regisseur, wijkteam, overige medewerkers en voor de burger kan minimaliseren -
terwijl wel de ondersteuning kan worden geleverd en de horizontale en verticale verantwoording
(rapportages aan o.a. gemeenteraad resp. ministeries) kan worden gegeven.
111
7 PvE: Integratie
7.1 Inleiding
Bij koppelingen tussen systemen dient onderscheid gemaakt te worden tussen schrijven (van 3D-
Suite naar derde applicatie, of andersom) en lezen van bronnen naar de 3D-Suite. Bij voorkeur
wordt voor koppelingen gebruik gemaakt van open standaarden i.c.m. reeds aanwezige API‟s 15
van de betreffende te koppelen systemen. We spreken van een “betonnen vrouwtje” als de
specificaties van het externe koppelvlak een gegeven zijn, zoals bv bij landelijke voorzieningen.
Echter bestaat niet in alle gevallen een dergelijk „mooi‟ koppelvlak en soms moeten koppelvlakken
met systemen nog gedefinieerd worden. V.w.b. leeskoppelingen, kan dan worden volstaan met het
uitlezen van de database, rekening houdend met evt. autorisaties.
Bij schrijfkoppelingen dient altijd een API te worden gebruikt i.v.m. de business rules van het
ontvangende systeem. Waar dat niet mogelijk is, zal moeten worden “gekloppeld”: overtypen van
informatie, bijv. n.a.v. een attenderingsmailtje aan de gebruiker van het te koppelen systeem.
Voordat een concrete implementatie wordt voorbereid, kan voor een specifieke gemeente worden
onderzocht welke koppelvlakken wel/niet aanwezig zijn en welke informatie nodig én beschikbaar
is. Dit betreft zowel koppelen binnen de gemeentelijke firewall, als bijv. met ketenpartners.
Er zal bijv. onderzocht moeten worden in welke mate het koppelen met basisregistraties mogelijk is
i.r.t doelbinding: bijv. bij een WMO-aanvraag is er geen wettelijke basis om Suwinet te bevragen.
Dan is alsnog een koppeling met de GBA/burgerzakenmodule nodig, nog steeds incl. bewaking van
de doelbinding. Een gemeente wil wellicht ook koppelen met gemeentelijke belastingen
(openstaande betalingen), de basisadministratie adressen en gebouwen (“we zien 12 mensen op
50 m2”), etc.
Er komen daarnaast mettertijd wellicht meer landelijke knooppunten die kunnen worden gebruikt
om het aantal koppelvlakken te minimaliseren, doch daar is nu nog niets over te zeggen v.w.b.
inhoud, timing, of techniek.
Er wordt vaak verwezen naar een [bijlage XX] of vergelijkbaar. Iedere gemeente heeft eigen
applicaties met elk andere koppelmogelijkheden. Het is van belang dat bij een eventuele
aanbesteding helder en correct wordt omschreven welke API‟s en welke berichten mogelijk zijn, om
te voorkomen dat de verschillende betrokken partijen (leverancier van “mannetje”, leverancier van
“vrouwtje” en de gemeente) allen naar elkaar gaan wijzen.
In alle gevallen is het bijwerken van de koppelvlakken in de tijd onderdeel van het geleverde
Onderhoud.
[[Verzoek aan gemeenten: maak bij voorkeur gebruik van de KING softwarecatalogus. Hierin kun-
nen gemeenten per referentie componenten aangeven met welke software ze deze invullen en zien
welke standaarden daarmee ondersteund worden. Indien er dan in de praktijk problemen komen
kunnen leveranciers via het convenant van operatie nup er op aangesproken worden alsnog te vol-
doen aan de betreffende standaarden.]]
15 API: Application Progamming Interface, koppelvlak waarmee kan worden gekoppeld met de be-
treffende applicatie.
112
7.2 Interne integratie
Deze paragraaf betreft de koppeling tussen de 3D-Suite en een reeds aanwezig (3P) generiek
zaaksysteem / documentmanagementsysteem (DMS) t.b.v. documentopslag (zogeheten
documentenkoppeling). E.e.a. dient nadrukkelijk als voorbeeld en zal t.z.t aangepast (of
weggelaten) moeten worden al naar gelang de betreffende specifieke voorkeuren en
mogelijkheden.
[NB Er wordt veelal bewust in het midden gelaten of, en zo ja hoe, gegevens al dan niet naar het
gegevensmagazijn van de 3D-Suite gerepliceerd worden dan wel op het moment dat ze nodig zijn
uit het gekoppelde systeem worden “opgehaald” (voor zover de betreffende bron dit toelaat),
bijvoorbeeld via een rechtstreekse koppeling of via het gegevensdistributiesysteem. Een en ander
hangt o.a. af van de mogelijkheden van de te koppelen applicatie.]
G23 [Koppeling met [zaaksysteem/DMS]: documentenkoppeling (basisfunctionaliteit)]
De 3D-Suite integreert v.w.b. documentopslag op dusdanige wijze met het [zaaksysteem/DMS]
van Gemeente ([merk, type, versie]) dat alle functionaliteiten en berichten als beschreven in de
specificaties van het betreffende „vrouwtje‟ in bijlage [XX] volledig worden ondersteund (voor zo-
ver van toepassing realtime (i.t.t. batch) en zowel lezen als schrijven).
Hierbij wordt het ZK-DMS koppelvlak ondersteund.16
O74 [Koppeling met [zaaksysteem/DMS]: documentenkoppeling (beheer)]
Bij voorkeur is het [DMS/Zaaksysteem] gebruikt als een „domme opslagdoos‟ waarbij inrichting en
beheer volledig vanuit de 3D-Suite plaatsvinden, incl. bijbehorende autorisaties.
Beschrijf de mate van integratie m.b.t. het beheer van de 3D-Suite en het [zaaksysteem/DMS]
van Gemeente t.a.v. (de inrichting van) documentopslag, gezien vanuit de functioneel beheerder.
Geef tevens aan in welke mate het ZK-DMS koppelvlak wordt ondersteund.
Ga expliciet in op de wijze waarop veilige opslag en beheer wordt gegarandeerd, incl. authentica-
tie/autorisaties/beveiliging per persoon die een document via de 3D-Suite of direct via het DMS
opvraagt of aanpast.
Beschrijf daarnaast ten minste in hoeverre en op welke wijze sprake is van volledig enkelvoudig
beheer van de 3D-Suite en het [zaaksysteem/DMS] d.m.v. de beheeromgeving van de 3D-Suite,
incl. de inrichting van documentopslag in het [zaaksysteem/DMS]. Beschrijf in dat kader expliciet
wat er daartoe in de 3D-Suite resp. het [zaaksysteem/DMS] dient te worden ingericht, incl. de
(on)mogelijkheid om buiten de beheeromgeving van de 3D-Suite om de inrichting van het [zaak-
systeem/DMS] v.w.b. documentopslag aan te passen.
Indien geen sprake is van volledig enkelvoudig beheer, beschrijf hoe de inrichting van beide sys-
temen gelijk wordt getrokken en welke beheertaken dubbel moeten worden uitgevoerd. Ga daar-
bij ten minste in op de synchronisatie tussen de beheeromgeving van de 3D-Suite en (de ZTC /
het DSP van) het [zaaksysteem/DMS], incl. alle metadata (zoals „zaaktypekenmerken‟ en bijbeho-
rende zaak-, dossier- en proceskenmerken), incl. bijbehorende autorisaties (rechten en rollen) en
bewaar- en vernietigingstermijnen.
Beschrijf voor elk van beide gevallen ten minste wat er precies wanneer en hoe wordt uitgewis-
16 Dit koppelvlak is ontwikkeld in samenwerking met operatie NUP. Zie ook htt-
ps://new.kinggemeenten.nl/gemma/stuf/koppelvlakken/zs-dms
113
seld tussen de 3D-Suite en het [zaaksysteem/DMS]. Beschrijf daarbij ook of veranderingen in (de
configuratie van) de 3D-Suite realtime doorwerken in het [zaaksysteem / DMS] en vice versa, in-
cl. of daarbij validaties (van het de 3D-Suite resp. het [zaaksysteem/DMS]) t.b.v. de integriteit
van configuraties en andere inrichtingen actief zijn en zo ja welke.
G24 Koppeling met sjabloontoepassing (basisfunctionaliteit)
G24.1
De 3D-Suite integreert op dusdanige wijze met de sjabloontoepassing van Gemeente ([merk, ty-
pe, versie]) dat alle functionaliteiten en berichten als beschreven in de specificaties van het be-
treffende „vrouwtje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing real-
time (i.t.t. batch) en zowel lezen als schrijven).
G24.2
Dit geldt zowel vanaf locatie van Gemeente, als daarbuiten. [[afhankelijk van de mogelijkheden
van de sjablonentool, als dit niet volledig webbased is dan wil je misschien géén sjablonentool ge-
bruiken]]
G24.3
[D.w.z. dat ten minste (doch niet noodzakelijkerwijs uitsluitend) [voor zover van toepassing real-
time en volledig geautomatiseerd] [aandachtspunten o.b.v. de specificaties van het betreffende
„vrouwtje‟ in bijlage [XX]]].
S21. Koppeling met agendasysteem (basisfunctionaliteit) ([lezen] [en] [schrijven])
De 3D-Suite integreert op dusdanige wijze met het agendasysteem van Gemeente ([merk, type,
versie]) dat afspraken kunnen worden gemaakt in de 3D-Suite [én door de clientside applicatie
[naam, versie] (er wordt dus direct gecommuniceerd met de server van de Gemeente en niet de
clientside applicatie)] / [die inzichtelijk zijn in de clientside applicatie [naam, versie]].
G25 Koppeling met financieel systeem (basisfunctionaliteit) (lezen en schrijven)
G25.1
De 3D-Suite integreert op dusdanige wijze met het financiële systeem van Gemeente ([merk, ty-
pe, versie]) dat alle functionaliteiten en berichten als beschreven in de specificaties van het be-
treffende „vrouwtje‟ in bijlage [XX enkel relevante berichten opgeven! Bijv. journaalposten XX]
volledig worden ondersteund (voor zover van toepassing realtime en zowel lezen als schrijven).
G25.2
Het recht op betalingen kan vastgelegd worden met besluiten. Voor het genereren van een over-
zicht van aan te maken boekingen kan het financiële systeem via live databasetoegang met lees-
rechten de benodigde gegevens uitvragen.
G25.3
D.w.z. dat ten minste (doch niet noodzakelijkerwijs uitsluitend) [voor zover van toepassing real-
time en volledig geautomatiseerd] [aandachtspunten o.b.v. de specificaties van het betreffende
„vrouwtje‟ in bijlage [XX]].
S22. Koppeling met directory server (basisfunctionaliteit) (lezen)
De 3D-Suite integreert op dusdanige wijze met de directory server van Gemeente ([merk, type,
114
versie]) dat alle functionaliteiten en berichten als beschreven in de specificaties van het betref-
fende „vrouwtje‟ in bijlage [XX] volledig worden ondersteund (realtime en zowel lezen als schrij-
ven).
De 3D-Suite integreert met de directory server van de Gemeente zodanig dat alle gebrui-
kers/wachtwoorden van interne medewerkers van de Gemeente worden geverifieerd door de Di-
rectory server en dat alle rollen die binnen de 3D-Suite worden gebruikt voor authenticatie en au-
torisatie gekoppeld kunnen worden aan één of meer groepen uit de centrale directory server van
de Gemeente.
G26 [Koppeling met Klantcontactsysteem] [[Alternatief is dat het KCC direct de 3D-
Suite gebruikt]] (lezen en schrijven)
De 3D-Suite integreert op dusdanige wijze met het klantcontactsysteem van de Gemeente
([merk, type, versie]) dat alle functionaliteiten en berichten als beschreven in de specificaties van
het betreffende „vrouwtje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing
realtime en zowel lezen als schrijven).
[D.w.z. dat ten minste (doch niet noodzakelijkerwijs uitsluitend) [voor zover van toepassing real-
time en volledig geautomatiseerd]
- signaleringen die bij het KCS binnenkomen kunnen worden doorgegeven aan de 3D-Suite
(schrijven)
- klantcontacten (telefoon, e-mails, anders) die bij het KCS binnenkomen kunnen worden door-
gegeven aan de 3D-Suite (schrijven)
- het KCS de contactgegevens kan inzien van de regisseurs (lezen)
- [aandachtspunten o.b.v. de specificaties van het betreffende „vrouwtje‟ in bijlage [XX]]].
115
7.3 Gemeentelijke basisadministraties en backofficesystemen
S23. Gemeentelijke basisadministratiesysteem (GBA) (lezen)
De 3D-Suite integreert op dusdanige wijze met het gemeentelijke basisadministratiesysteem van
de Gemeente ([merk, type, versie]) zodat de 3D-Suite beschikt over persoonsgegevens in de be-
treffende basisadministratie.
[Alle functionaliteiten en berichten als beschreven in de specificaties van het betreffende „vrouw-
tje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing realtime lezen).]
O75 GBA-V
Beschrijf óf en zo ja op welke wijze de 3D-Suite geïntegreerd kan worden met [GBA-V applicatie,
merk, type, versie] zodat de 3D-Suite beschikt over persoonsgegevens van niet-inwoners van de
Gemeente.
Beschrijf op welke manier eventuele gegevensmagazijnen/databases van de 3D-Suite en de ma-
gazij-nen/caches van het aanwezige datadistributiesysteem hierbij een rol hebben.
Beschrijf tevens hoe gezorgd kan worden dat de gegevens actueel zijn/blijven. Licht toe of dit vol-
ledig automatisch „onderwater‟ plaatsvindt m.b.v. afnemersindicaties of dat hiervoor een handma-
tige actie is vereist via de gebruikersinterface van de 3D-Suite. Geef ten slotte aan hoe in de ge-
bruikersinterface van de 3D-Suite zichtbaar is of een persoon wel of geen inwoner van de Ge-
meente is.
S24. Basisregistratie Adressen en Gebouwen (BAG) (lezen)
De 3D-Suite integreert op zodanige met het Basisregistratie Adressen en Gebouwen (BAG-
systeem, [merk, type, versie] dat alle functionaliteiten en berichten zoals beschreven in de speci-
ficaties van het betreffende vrouwtjes ([bijlage X]) volledig worden ondersteund (voor zover van
toepassing realtime lezen).
S25. Status doorgeven aan Zaaksysteem (schrijven)
De 3D-Suite integreert op dusdanige wijze met het zaaksysteem van de Gemeente ([merk, type,
versie]) dat de 3D-Suite van alle in de 3D-Suite geregistreerde zaken deelzaken de status kan
worden doorgegeven aan het gemeentelijk zaaksysteem.
[Alle functionaliteiten en berichten als beschreven in de specificaties van StUF-Zkn en/of het ZK-
DMS koppelvlak worden – zover van toepassing – voor het betreffende „vrouwtje‟ in bijlage [XX]
volledig worden ondersteund (voor zover van toepassing realtime en zowel lezen als schrijven).]
S26. Zaaksysteem als bron van zaakdossiers (lezen)
De 3D-Suite integreert op dusdanige wijze met het zaaksysteem van de Gemeente ([merk, type,
versie]) dat de 3D-Suite van alle zaken deelzaken de status kan opvragen.
[Alle functionaliteiten en berichten als beschreven in de specificaties van StUF-Zkn en/of het ZK-
DMS koppelvlak worden – zover van toepassing – voor het betreffende „vrouwtje‟ in bijlage [XX]
volledig worden ondersteund (voor zover van toepassing realtime en zowel lezen als schrijven).]
S27. [Schuldhulpverlening] (lezen)
De 3D-Suite integreert op dusdanige wijze met het schuldhulpverleningsysteem van de Gemeente
116
([merk, type, versie: bijv. Allegro, Suite4Zorg, Key2Schuldhulpverlening]) dat daartoe geautori-
seerde gebruikers informatie over de burger en zijn / haar lopende schuldhulpverleningstra-
ject(en) kunnen opvragen dat is geregistreerd in het te koppelen systeem.
[Alle functionaliteiten en berichten als beschreven in de specificaties van het betreffende „vrouw-
tje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing realtime le-
zen).][Hierbij wordt de database van het te koppelen systeem uitgelezen].
S28. [Uitkeringenverstrekking] (lezen)
De 3D-Suite integreert op dusdanige wijze met het uitkeringenverstrekkingsysteem van de Ge-
meente ([merk, type, versie: bijv. Suite4Inkomen]) dat daartoe geautoriseerde gebruikers infor-
matie over de burger en zijn / haar lopende uitkering(en) kunnen opvragen dat is geregistreerd in
het te koppelen systeem.
[Alle functionaliteiten en berichten als beschreven in de specificaties van StUF-Zkn en van het
betreffende „vrouwtje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing re-
altime lezen).][Hierbij wordt de database van het uitkeringenverstrekkingsysteem uitgelezen.]
S29. [Re-integratie] (lezen)
De 3D-Suite integreert op dusdanige wijze met het reïntegratiesysteem van de Gemeente ([merk,
type, versie: bijv. Civision WIZ]) dat daartoe geautoriseerde gebruikers informatie over de burger
en zijn / haar lopende schuldhulpverleningstraject(en) kunnen opvragen dat is geregistreerd in
het te koppelen systeem.
[Alle functionaliteiten en berichten als beschreven in de specificaties van het betreffende „vrouw-
tje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing realtime le-
zen).][Hierbij wordt de database van het te koppelen systeem uitgelezen].
S30. [Leerlingadministratie / leerplichtverzuim] (lezen)
De 3D-Suite integreert op dusdanige wijze met het leerlingadministratiesysteem van de Gemeen-
te ([merk, type, versie: bijv. Suite4Onderwijs/LLA4all/Key2Onderwijs/Key2Jongerenmonitor]) dat
daartoe geautoriseerde gebruikers informatie over de burger en zijn / haar lopende schuldhulp-
verleningstraject(en) kunnen opvragen dat is geregistreerd in het te koppelen systeem.
[Alle functionaliteiten en berichten als beschreven in de specificaties van het betreffende „vrouw-
tje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing realtime le-
zen).][Hierbij wordt de database van het te koppelen systeem uitgelezen].
S31. [Overige indicaties van ontvangen voorzieningen] (lezen)
De 3D-Suite integreert op dusdanige wijze met het bijv. overige applicaties voor jeugdhulp, zorg
of ondersteuning] van de Gemeente ([merk, type, versie: bijv. Civision WIZ]) dat daartoe geauto-
riseerde gebruikers informatie over de burger en zijn / haar ontvangen voorzieningen kunnen op-
vragen dat is geregistreerd in het te koppelen systeem.
[Alle functionaliteiten en berichten als beschreven in de specificaties van het betreffende „vrouw-
tje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing realtime le-
zen).][Hierbij wordt de database van het te koppelen systeem uitgelezen].
117
118
7.4 Integratie landelijke en regionale voor-zieningen
E9 Koppeling met VIR (lezen en schrijven)
De 3D-Suite integreert op zodanige wijze met de Verwijsindex Jongeren dat alle functionaliteiten
en berichten als beschreven in de specificaties van het betreffende vrouwtje volledig worden on-
dersteund (voor zover van toepassing realtime en zowel lezen als schrijven).
D.w.z. dat ten minste (doch niet noodzakelijkerwijs uitsluitend) het mogelijk is
- signalering ontvangen, incl. metadata
- signalering versturen, incl. metadata
Toelichting: de Verwijsindex Risicojongeren (VIR) is een landelijk informatiesysteem dat bedoeld
is om hulpverleners binnen verschillende organisaties inzicht te geven in elkaars betrokkenheid bij
een jongere.
S32. Signaalwerking: inkomend
De 3D-Suite biedt een gedocumenteerde API waarbij daartoe geautoriseerde systemen signalerin-
gen kunnen indienen bij de 3D-Suite.
O76 Signaalwerking
Beschrijf de mogelijkheden die de voorgaand gevraagde API van de 3D-Suite biedt, voor wat be-
treft
- identificatie en autorisatie van betrokken organisaties (bijv. een inkomend signaal van een
arts)
- identificatie van de betrokken burgers (burger, gezin)
- gestructureerde en ongestructureerde gegevens m.b.t. de signalering
- vertrouwelijkheid van de melding
Beschrijf tevens welke functionaliteiten de 3D-Suite biedt om uitgaande signaleringen te sturen
aan overige systemen.
E10 Koppeling met de GeVS: SUWInet-Inlezen (lezen)
De 3D-Suite integreert op zodanige wijze met Suwinet-Inlezen dat alle functionaliteiten en berich-
ten als beschreven in de specificaties van het betreffende vrouwtje volledig worden ondersteund
(voor zover van toepassing realtime).
D.w.z. dat ten minste (doch niet noodzakelijkerwijs uitsluitend)
- het mogelijk is informatie op te vragen van de burger, t.b.v. het klantbeeld
- informatie wordt enkel getoond indien er voldoende autorisatie is voor de betreffende persoon
(dus niet iedere gebruiker)
Bijlage 12.2 geeft een overzicht van de beschikbare gegevens. Enkel voor daartoe geautoriseerde
personen is alle informatie inzichtelijk
119
Koppeling met CORV
De 3D-suite integreert op zondanige wijze met de Collectieve Opdracht Routeer Voorziening17, zo-
als beschreven in de desbetreffende Project Start Architectuur. Dit betekent ondermeer dat ge-
bruik gemaakt moet worden van digikoppeling melding ebMS en gestandaardiseerde berichten.
CORV zorgt voor een goede routering en vertaling van berichten tussen het justitiedomein en het
gemeentelijk domein. Deze voorziening moet voor 1 januari 2015 operationeel zijn.
S33. Dienst Justitiële Inrichtingen (lezen en schrijven)
De 3D-Suite integreert op zodanige wijze met het DJI dat ten minste t.b.v.:
- infoverstrekking van DJI: signaleringen dat een persoon is gedetineerd (en er o.a. geen recht
is op een bijstandsuitkering) worden verwerkt door de 3D-Suite
- In het kader van de nazorg van volwassen (ex-)gedetineerde burgers is er ten minste een
verwijzing naar het samenwerkingsmodel tussen gemeenten en justitie: Digitaal Platform Aan-
sluiting Nazorg
- Infoverstrekking aan DJI: het DJI kan inzicht krijgen in wat de gemeente weet (ten minste
DAT) van een gedetineerde.
S34. Veiligheidshuizen (schrijven en lezen)
De 3D-Suite integreert op zodanige wijze met het Casus ondersteunend systeem voor
Veiligheidshuizen (GCOS) dat
- Burgers kunnen worden aangemeld, en
- De voortgang van een burger kan worden gemonitord
S35. Regionaal Meld- en Coördinatiepunt (lezen)
De 3D-Suite integreert op zodanige wijze met het Regionaal Meld- en Coördinatiepunt (RMC) dat
- vroegtijdige schoolverlaters binnen de gemeente automatisch als signalering de 3D-Suite bin-
nen komen, en
- in het integrale klantbeeld voor leerplichtige kinderen een aanduiding is dat het een vroegtijdi-
ge schoolverlater betreft
S36. Overige adapters met landelijke systemen
De 3D-Suite integreert op zodanige wijze met onderstaande systemen dat alle functionaliteiten en
berichten als beschreven in de specificaties van het betreffende vrouwtje volledig worden
ondersteund (voor zover van toepassing realtime en lezen en schrijven).
17 De desbetreffende PSA Keteninformatie is formeel vastgesteld in het opdrachtgeversoverleg stelselherziening
Jeugd (VNG, VWS en VenJ) op 25 juni 2013. Er zal (1) gegevens uitwisseling tussen gemeente, jeugdstraf-
rechtketen en jeugdbeschermingsketen gaan plaatsvinden, bijvoorbeeld een gestandaardiseerd Verzoek tot On-
derzoek (VTO) als startmoment voor de jeugdbeschermingsketen; ook zullen de gemeenten allerlei gestan-
daardiseerde berichten uit de justitiële jeugdketens ontvangen en (2) beleidsinformatie richting V&J. VWS, VenJ
en enkele gemeenten gaan hiervoor een proeftuin inrichten.
120
- Adapter t.b.v. landelijke voorziening „Mijn Overheid‟, o.a. verzenden van berichten aan burgers
- Adapter t.b.v. betalingskassa, o.a. verzenden van berichten aan burgers
- Adapter t.b.v. authenticatiesysteem DigiD EI en DigiD Machtigingen
O77 Koppelingen: overig
Geef een uitputtende opsomming van alle eventuele overige koppelingen met specifieke landelijke
voorzieningen waarmee standaardkoppelingen met de 3D-Suite worden meegeleverd en desge-
wenst geïmplementeerd bij Gemeenten (inbegrepen bij de prijsopgave en als zodanig zonder ad-
ditionele kosten “out-of-the-box” beschikbaar en verifieerbaar in de PoC).
Besteed daarbij expliciet aandacht aan privacy en beveiliging, incl. doelbinding, en geef aan of het
lezen of schrijven van berichten betreft.
Denk aan
- Justitie (zie ook http://justid.nl/ebv/ en gegevenswoordenboeken van justitie)
- Externe politiebroker
- Vecozo t.b.v. declaraties
- Awbz-brede zorgregistratie (AZR), zorgkantoren
- Overige systemen en organisaties, bijv. i.h.k.v. AWBZ/Wmo
- Etc.
O78 Koppelingen: toelichting
Beschrijf de functionaliteit van elk van de koppelingen tussen het 3D-systeem en de onderstaande
landelijke voorzieningen:
- VIR
- GeVS
- DJI
- Eventuele overige koppelingen met landelijke en regionale voorzieningen.
Beschrijf bovendien de functionaliteit van elk van de koppelingen tussen de 3D-Suite en de be-
treffende gemeentelijke voorzieningen in het kader van:
- Documentopslag
- Documentcreatie en gebruik van sjablonentools
- Eventuele overige koppelingen met gemeentelijke voorzieningen.
Beschrijf daarbij voor elke koppeling, dus zowel koppelingen met landelijke voorzieningen als met
gemeentelijke voorzieningen, steeds ten minste (voor zover van toepassing):
- De functionaliteiten van de betreffende koppeling, onder vermelding van de betreffende ver-
sie(s) van de betreffende te koppelen voorziening / het betreffende vrouwtje waarvoor deze
gelden. Beschrijf daarbij steeds ten minste of en zo ja hoe er bij de betreffende koppeling - in-
dien het betreffende vrouwtje dit ondersteunt - daadwerkelijk sprake is van gegevensuitwisse-
ling, incl. welke gegevens het betreft en of gebruikers daartoe nog handelingen dienen te ver-
richten (en zo ja welke, zoals: wordt bij een URL-koppeling gelinkt naar de betreffende “home-
page” en moeten gebruikers daar verder zoeken of naar een in de betreffende context relevant
element). Maak daarbij indien van toepassing steeds onderscheid tussen lezen uit en schrijven
in de betreffende voorziening (incl. het meegeven van parameters in URL‟s), alsook tussen re-
altime en batchgewijs.
- Autorisatie op applicatie-niveau (bijv. d.m.v. certificaten en encryptie), incl. de mate waarin
beveiliging en privacy worden gewaarborgd.
121
- Of en zo ja hoe de betreffende koppeling - indien het betreffende vrouwtje dit ondersteunt - is
onderworpen aan autorisaties per persoon (rechten en rollen, bijvoorbeeld dat de koppeling al-
leen “actief” is als de ingelogde gebruiker daar autorisatie toe heeft), incl. doelbinding. Be-
schrijf daarbij bovendien of bij de betreffende voorziening nog ingelogd dient te worden (indien
van toepassing) dan wel dat er sprake is van SSO en geef aan of de koppeling (incl. eventuele
SSO) ook functioneert vanaf een device dat zich niet in het gemeentenetwerk bevindt (thuis-
werkplek, mobiel device, etc.).
- De flexibiliteit (mate van aanpasbaarheid) van de betreffende koppeling, incl. de mate waarin
dit door middel van configuratie (“paramaters”) kan worden gerealiseerd (indien het betreffen-
de vrouwtje dit ondersteunt). Beschrijf daarbij tevens in welke mate en op welke wijze functio-
neel resp. technisch beheerders van Gemeenten de betreffende koppeling volledig zelfstandig,
voor zover mogelijk zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero co-
ding), functioneel resp. technisch kunnen beheren.
122
7.5 Zaaksysteem en backofficesystemen van UO’s
O79 Jeugdzorg (lezen en schrijven)
Er zijn verschillende lokale oplossingen voor gegevensuitwisseling tussen gemeente en Bureaus
Jeugdzorg en tussen gemeente en Jeugd & Opvoedhulp-organisaties. Het is denkbaar dat op korte
termijn hier nieuwe applicaties worden ingericht, waardoor de beschikbare koppelvlakken kunnen
gaan afwijken. De bureaus jeugdzorg investeren momenteel in de noodzakelijke herziening van
de verouderde ICT-systemen IJ/Kits. Het systeem zal aansluiten op de keteninformatiesystemen
justitiële jeugdketens en de Collectieve Routerings Voorziening (CORV).
Beschrijf de mogelijkheden die u (binnen de geoffreerde prijzen) biedt om een koppelvlak te ont-
wikkelen op de „vrouwtjes‟ van Jeugdzorg-systemen v.w.b. uitwisseling van gegevens over perso-
nen, (indicatie)besluiten en te verlenen ondersteuning uit te wisselen en welke koppelingen u
reeds heeft gerealiseerd.
Indien u niet binnen de geoffreerde prijzen koppelvlakken biedt, geef aan op welke wijze (binnen
de geoffreerde prijzen) informatieuitwisseling plaatsvindt.
S37. [Top-N uitvoeringsorganisaties: status en informatie uitwisselen (lezen en schrij-
ven)]
De 3D-Suite integreert op dusdanige wijze met het zaaksysteem van de volgende uitvoeringsor-
ganisaties dat de 3D-Suite van alle in de 3D-Suite geregistreerde zaken / deelzaken de status kan
worden doorgegeven aan het gemeentelijk zaaksysteem.
Alle functionaliteiten en berichten als beschreven in de specificaties van StUF-Zkn en van het be-
treffende „vrouwtje‟ in bijlage [XX] volledig worden ondersteund (voor zover van toepassing real-
time en zowel lezen als schrijven).
- Schuldhulpverleningsbedrijven [A, B] cf. standaard [X1] en API als beschreven op [Y1]
- Re-integratiebedrijven [C, D] cf. standaard [X2] en API als beschreven op [Y2]
- etc.
[[NB Zie ook wens S11 voor de gevallen waar nog géén systeem-systeemkoppeling mogelijk is,
dan kunnen derde partijen gebruik maken van een „portal‟]]
123
7.6 Integratie-tooling
O80 Overige functionaliteiten: adapters
Beschrijf alle eventuele additionele functionaliteiten op het gebied van adapters (koppelingen) die
standaard onderdeel uitmaken van de 3D-Suite en die naar uw mening relevant zijn, mede in het
licht van het beoogde gebruik van de 3D-Suite zoals beschreven in hoofdstuk 2. Denk in dat kader
bijvoorbeeld aan:
- Beschikbare generieke webservices / API‟s t.b.v. gebruik van derde applicaties door de 3D-Suite.
- Beschikbare generieke webservices / API‟s t.b.v. gebruik door derde applicaties van functionali-
teiten en gegevens in de 3D-Suite.
- Beschikbare generieke import/export mogelijkheden van metadata en/of documenten, die zelf-
standig in te richten en geautomatiseerd te schedulen is (bij voorkeur o.b.v. StUF-Zkn en/of ZS-
DMS koppelvlak.
- Met welke andere landelijke en/of sectorale voorzieningen de 3D-Suite over een gestandaardi-
seerde koppeling beschikt voor de bi-directionele uitwisseling van gestructureerde en/of onge-
structureerde gegevens (incl. toelichting, zoals of daarbij gebruikgemaakt wordt van Digikoppe-
ling, welke producten / processen ermee worden ondersteund, etc.) en of deze onderdeel is/zijn
van de aanbieding.
- Beschikbare generieke (technologie)adapters zoals CMIS, XML, SMTP, HTTP, WUS, ebMS, COM+,
JMS, databasekoppelingen, etc. of documentkoppelingen
NB: Benoem uitsluitend functionaliteiten welke zijn inbegrepen bij de prijsopgave en die als zoda-
nig zonder (additionele) kosten direct beschikbaar zijn.
O81 Procesbewaking en -beheer (A2A)
Beschrijf de functionaliteiten van de 3D-Suite met betrekking tot het real-time bewaken van lo-
pende A2A processen (oftewel „applicatie workflow‟). Denk in dat kader bijvoorbeeld aan:
- Gebruik en bewaking van adapters.
- Logging (incl. foutregistratie), audit trails, etc.
- Het onderscheid tussen real-time en offline rapportages.
- Notificatie en bij excepties.
- Optimalisatie (incl. load balancing).
- Aspecten rondom integriteit, zoals „transactional integrity‟, roll-back, het gebruik van „compensa-
ting transactions‟, etc. Maak hierbij - indien van toepassing - onderscheid tussen synchroon en
asynchroon berichtenverkeer.
- Beveiliging en autorisatie.
- Etc.
Beschrijf bovendien de functionaliteiten van de 3D-Suite met betrekking tot het beheer van A2A
processen (oftewel „applicatie workflow‟) en de autorisaties (rollen en rechten) daar omheen.
Denk in dat kader bijvoorbeeld aan:
- Het wijzigen van standaardprocessen.
- Versiebeheer rondom A2A processen (incl. de eventuele consequenties van wijzigingen voor
reeds lopende processen).
- Etc.
Geef daarbij tevens aan welke mogelijkheden er zijn met betrekking tot het genereren van docu-
mentatie / handleidingen over processen en processtappen, de procesgang, etc.
124
O82 Overige functionaliteiten: Broker/ESB
Beschrijf alle eventuele additionele functionaliteiten op het gebied van de broker/ESB die stan-
daard onderdeel uitmaken van de 3D-Suite en die naar uw mening relevant zijn, mede in het licht
van het beoogde gebruik van de 3D-Suite zoals beschreven in hoofdstuk 2. Denk in dat kader bij-
voorbeeld aan:
- Of er in de 3D-Suite sprake is van een centrale broker- of een decentrale ESB-architectuur.
- Specifieke mogelijkheden m.b.t. translatie en transformatie, zoals of hierbij validatie mogelijk is
en de wijze waarop „mapping‟ mogelijk is (visueel d.m.v. drag-and-drop, door middel van scrip-
ting, etc.).
- Mogelijkheden m.b.t. het uitwisselen van processen met andere gemeenten zoals import-
/exportfunctionaliteit, bijbehorende bestandsformaten.
- Aspecten rondom beveiliging zoals encryptie, authenticatie en certificaten maar ook het gebruik
van secure messaging en dergelijke.
- Ondersteunde webservice- en andere standaarden, zoals StUF, SuwiML en de gegevenstandaar-
den jeugd.
- Ondersteunde webservice- en andere standaarden, zoals XML, WSI, SOAP en WSDL, WS Adress-
ing, WS Security, WS Reliable Messaging, XSD-authoring, XSLT, Xpath, MIME (voor attach-
ments), etc.
NB: Benoem uitsluitend functionaliteiten welke zijn inbegrepen bij de prijsopgave (zie ##) en die
als zodanig zonder (additionele) kosten direct beschikbaar zijn.
125
8 PvE: Autorisatie, beveiliging en
privacy
8.1 Inleiding
De 3D-Suite bevat zeer vertrouwelijke informatie over burgers in kwetsbare posities. Door middel
van de Inkijk-functionaliteit (integraal klantbeeld) kan toegang worden verschaft tot nog meer
vertrouwelijke gegevens, soms met medische of justitiële achtergrond. De beveiliging van deze
gegevens en de bescherming van de privacy van de betrokkenen is daarom van het grootste
belang.
Aan de andere kant kan het niet zo zijn dat er omwille van de privacybescherming géén enkele
uitwisseling van gegevens mogelijk is. Het WRR-rapport iOverheid18 adviseert dat er in de
ontwikkeling van nieuwe wetgeving en nieuw beleid juist een goede balans moet zijn tussen de
mogelijkheden van ICT, en de benodigde bescherming van de privacy. De beginselen van de Wet
Bescherming Persoonsgegevens en andere relevante wetgeving zijn echter van groot belang,
gegeven de zeer vertrouwelijke informatie. Er wordt enkel informatie uitgewisseld als de betrokken
burger daar toestemming voor heeft gegeven, of als er in de wet een grondslag (inclusief
doelbinding) voor is gecreëerd.
De burger zelf moet akkoord geven voor het delen van de informatie aan derden, incl. uitvoerings-
organisaties. De vorm van dit akkoord kan per gemeente verschillen: v.w.b. de inhoud van een
intentieverklaring t/m formeel contract, en v.w.b. de vorm van een vinkje (na DigiD-autorisatie)
t/m papieren handtekening. Doch in uitzonderingsgevallen (denk aan een uithuisplaatsing waar de
ouder het er niet mee eens is) kan de goedkeuring van de klant ontbreken.
8.2 Wet- en regelgeving
E11 Beveiliging: wet- en regelgeving
De 3D-Suite functioneert v.w.b. aspecten van beveiliging en privacy volledig conform alle betref-
fende wet- en regelgeving.
Contractant verleent medewerking aan eventuele beveiligingstests/-audits (ten minste eenmaal
per jaar is deze medewerking kosteloos), door één of meer daartoe gespecialiseerde onafhankelij-
ke derde partijen. Eventuele vergoedingen aan dergelijke derde partijen in dat kader worden door
Gemeente gedragen. Deze beveiligingstests/-audits kunnen naast de wettelijk vereiste audits on-
der meer hackerstests en tests m.b.t. de beveiliging van de onderdelen van de 3D-Suite waar
burgers mee in aanraking komen (zoals m.b.t. cross-site scripting en serverside scripts) omvat-
ten, alsmede data- en communicatiebeveiliging (incl. encryptie, certificaten, etc.), autorisatiemo-
dellen, logging, en dergelijke.
Eventuele gebleken tekortkomingen m.b.t. beveiliging n.a.v. dergelijke beveiligingstest/-audits
dienen te worden meegenomen bij de doorontwikkeling van de 3D-Suite (als onderdeel van het
onderhoud) en zonodig op de kortst mogelijke termijn te worden gepatcht. Eventuele kosten die
gemoeid zijn met het verhelpen van dergelijke tekortkomingen, zijn voor rekening van
Contractant (als onderdeel van de onderhoudskosten).
Contractant garandeert bovendien de toekomstige (door)ontwikkeling van de 3D-Suite gedurende
18 www.ioverheid.nu
126
de looptijd van de overeenkomst (incl. eventuele verlenging, binnen de jaarlijkse prijzen) zodanig
dat de 3D-Suite „meegroeit‟ met alle ontwikkelingen op het gebied van de betreffende wet- en
regelgeving. D.w.z. zeggen dat Contractant garandeert dat de 3D-Suite v.w.b. aspecten van
beveiliging volledig i.o.m. alle betreffende wet- en regelgeving blijft functioneren en zich eraan
conformeert om de 3D-Suite binnen [XX weken] dienovereenkomstig aan te passen (door middel
van een nieuwe of verbeterde versie van de 3D-Suite) zodra de betreffende wet- en regelgeving
verandert.
E12 Beveiliging: basisfunctionaliteit
De 3D-Suite biedt m.b.t. beveiliging ten minste (doch, indien noodzakelijk om te voldoen aan
E11, niet uitsluitend) afdoende functionaliteit met betrekking tot:
- Authenticatie en autorisatie
▪ De 3D-Suite biedt zodanige functionaliteit m.b.t. authenticatie en autorisatie, zowel voor
gebruikers als voor applicaties, dat alle functionaliteiten van en gegevens in (c.q. te bena-
deren via) de 3D-Suite zodanig aan autorisaties onderworpen zijn dat ten minste kan wor-
den voldaan aan E11.
- Auditing/logging (incl. protocollering)
▪ De 3D-Suite biedt zodanige functionaliteit m.b.t. auditing/logging (incl. protocollering) dat
van alle relevante handelingen en pogingen daartoe - door zowel door gebruikers als appli-
caties - d.m.v. logging een historie wordt vastgelegd (van welke handelingen en pogingen
daartoe, wanneer en door wie zijn uitgevoerd) dat ten minste kan worden voldaan aan E11.
- Technische beveiliging (incl. integriteit, back-up & herstel, uitwijk, etc.)
▪ De 3D-Suite biedt zodanige functionaliteit m.b.t. technische beveiliging (waaronder ten
minste integriteit, back-up & herstel en uitwijk) dat de continuïteit en integriteit van (de
gegevens in c.q. te benaderen via) de 3D-Suite zodanig gewaarborgd is dat ten minste kan
worden voldaan aan E11.
Dit betreft in alle gevallen zowel aanmaken, lezen, aanpassen als verwijderen (Create, Read,
Update, Delete, CRUD) op attribuutniveau.
G27 Verklaring van getrouwheid
De infrastructuur en organisatie van de Inschrijver [incl. rekencentra (incl. back-up)] zijn
adequaat beveiligd volgens ISO/IEC 27001 en ISO/IEC 27002 of vergelijkbaar.
Inschrijver is bereid op eigen kosten jaarlijks (de eerste voor Acceptatie van de 3D-Suite) een
verklaring van getrouwheid (of vergelijkbaar) te verkrijgen via een onafhankelijke derde partij,
om aan te tonen dat zij als Contractant veilig om gaat met vertrouwelijke informatie.
127
8.3 Toegang tot informatie: doelbinding en privacy
G28 Informatieuitwisseling en -verschaffing
- Er wordt enkel informatie uitgewisseld als er in de wet een grondslag (inclusief doelbinding)
voor is gecreëerd, of als de betrokken burger daar toestemming voor heeft gegeven. Wanneer
sprake is van een burger jonger dan een door wetgeving bepaalde leeftijd (nu: zestien jaar)
moet deze toestemming door de ouders worden afgegeven.
- Voor alle registraties en gegevensuitwisselingen geldt dat de systemen alleen op basis van ge-
autoriseerde toegang kunnen worden gebruikt.
- Bij iedere module of gegevensstroom is bekend welke persoonsgegevens zij omvat en per ge-
gevenselement wat de risicoklasse daarvan is en wat de verwerkingsgrond is.
- Binnen het klantdossier is informatie te ontsluiten aan specifieke personen (i.h.k.v. doelbin-
ding).
- Alle gebruik wordt gelogd, zowel bij handmatige toegang als via koppelvlakken en zowel lezen,
wijzigen, verwijderen en schrijven (CRUD).
- Gegevensuitwisseling vindt versleuteld plaats, via onversleutelde kanalen gaat enkel niet-
gevoelige informatie zoals een attenderings-mail.
- Het ondersteuningsplan is v.w.b. door de functioneel beheerder of regisseur vrijgegeven in-
formatie toegankelijk voor de burger / daartoe geautoriseerde personen in het gezin, de regis-
seur en - voor zover het hun eigen dienstverlening betreft - de betrokken hulpverleners.
- Het klantdossier is v.w.b. door de functioneel beheerder of regisseur vrijgegeven informatie
toegankelijk voor de burger / daartoe geautoriseerde personen in het gezin, de regisseur en -
voor zover het hun eigen dienstverlening betreft - de betrokken hulpverleners.
- Het klantbeeld is v.w.b. door de functioneel beheerder of regisseur vrijgegeven informatie toe-
gankelijk voor de burger/ daartoe geautoriseerde personen in het gezin, de regisseur en - voor
zover het hun eigen dienstverlening betreft - de betrokken hulpverleners.
- De betrokken burger heeft een correctie- en inzagerecht met betrekking tot de geregistreerde
gegevens, en heeft het recht om te weten aan welke personen /organisaties zijn of haar gege-
vens zijn verstrekt. Voor wat betreft toegang tot klantinformatie voorziet de gemeente een vier
ogen-principe: regisseur en burger bepalen samen wie toegang heeft.
- In uitzonderingsgevallen (bijv. bij gevaar of dwang) kan de regisseur er voor kiezen géén toe-
stemming te vragen en / of géén inzage voor de burger / het gezin te verschaffen. De regis-
seur dient dan op te geven welke wettelijke grondslag daarvoor is.
NB deze toestemming en het inzicht zijn niet verplicht realtime en via het Burgerportaal. Dit
kan ook bijv. via de regisseur en een papieren rapportage gebeuren.
O83 Informatieuitwisseling (aanvullend)
De wát-informatie over burgers blijft zoveel mogelijk binnen de separate informatiesystemen van
de verschillende betrokken backoffices en uitvoeringsorganisaties / ketenpartners. Er worden niet
meer gegevens uitgewisseld dan strikt noodzakelijk: bij de uitwisseling tussen organisaties en
domeinen wordt zoveel mogelijk alleen dát-informatie uitgewisseld.
Geef aan in welke mate de 3D-Suite out-of-the-box ondersteuning om de uitwisseling van wat-
informatie te minimaliseren zonder dat dat de efficiency en/of de beveiliging van de betreffende
burgers beperkt.
128
O84 Toegang verschaffen tot informatie
Informatie die via de GeVS wordt bevraagd kan enkel getoond worden aan daartoe
geautoriseerde personen. Ook kan bepaalde informatie in een klantdossier vertrouwelijk zijn. Geef
aan hoe en waar wordt bepaald in welke situatie informatie wordt getoond: in welke mate wordt
dit vooraf door Contractant bepaald, vooraf door functioneel beheer of juist ad-hoc door de
regisseur en /of de klant zelf?
Geef tevens aan hoe de 3D-Suite de beveiliging en privacy bewaakt wanneer de professional „aan
de keukentafel‟ de 3D-Suite gebruikt.
Beschrijf de mate waarin de gemeente de burger zelf eigenaar en regisseur van de eigen
gegevens kan laten zijn, o.a. door de burger zelf te laten bepalen welke informatie in het
klantdossier terecht komt, en welke partijen daar toegang toe krijgen. Geef daarbij aan of en hoe
de burger vanuit het Burgerportaal inzicht heeft, of dat dit via de regisseur gaat (bijv. wanneer de
gemeente een fysiek document met „natte handtekening‟ van de burger vraagt v.w.b. de
toestemming.
Geef tenslotte aan hoe de gemeente voor eigen beheerdoelen én om tegemoet te komen aan
verzoeken van betrokkenen (en bijv. WOB-verzoeken) een geautomatiseerd overzicht kan krijgen
van de gegevens die op klantniveau zijn verwerkt (lezen, schrijven).
S38. Vernietigen van informatie
- De burger heeft het recht vergeten te worden. Als een dergelijk verzoek komt, wordt – behalve
als de veiligheid in het geding is – alle informatie over de burger verwijderd (incl. alle lopende
ondersteuning).
- Alle signaleringen worden na een door de gemeente te bepalen periode verwijderd.
- Klantdossiers worden tevens na een door de gemeente te bepalen periode verwijderd.
- Vernietiging van een dossier, signaal of anderszins te vernietigen informatie kan worden opge-
schort als en zo lang functioneel beheer daar aanleiding toe ziet (bijv. als er een rechtszaak
loopt). Toegangslogs (CRUD) worden niet vernietigd.
- De gemeente kan er t.b.v. rapportages en analyse tevens voor kiezen anonieme (gestructu-
reerde) gegevens te bewaren. De 3D-Suite ondersteunt dit anonimiseren.
O85 Privacy by design
Bij voorkeur was reeds bij de ontwikkeling van de applicatie aandacht voor privacy-verhogende
maatregelen (“privacy enhancing technologies”), zodat wordt voldaan aan de “privacy by design”
principes als verwoord in artikel 23 van de concept Verordening Bescherming Persoonsgegevens 19.
Beschrijf derhalve in welke mate dit het geval is – voor álle door Inschrijver aangeboden
applicaties die deel uitmaken van de 3D-Suite. Geef tevens aan in welke mate privacy by design
een uitgangspunt is bij door ontwikkeling.
Denk hierbij aan o.a.:
19 http://ec.europa.eu/justice/data-protection/document/review2012/com_2012_11_nl.pdf
129
- Gegevensminimalisatie:
▪ waar mogelijk anonimiseren van gegevens;
▪ enkel tonen van identiteit van personen en van andere informatie wanneer nodig voor de
betreffende rol
▪ verwijderen van gegevens zodra dit kan
- Registratie van de voor het klantdossier verantwoordelijke organisatie en medewerker(s)
- Technische beveiliging van de databases
▪ Encrypted dataopslag en backup
▪ Toegang enkel na autorisatie en authenticatie
▪ Gescheiden opslag van persoonsgegevens en overige gegevens.
▪ Passende instrumenten om datalekken te detecteren en de omvang daarvan te bepalen om
daarvan melding te kunnen maken.
- Scheiding binnen de database tussen persoonlijke bevindingen en meningen van de professio-
nal, en de overige gegevens (met het oog op verstrekking persoonsgegevens, Wob-verzoeken
en publicatie)
8.4 Authenticatie en autorisatie
E13 Authenticatie burgers
De 3D-Suite biedt functionaliteit om burgers te authenticeren via DigiD EI en DigiD Machtigingen.
DigiD EI en DigiD Machtigingen gebruiken niveau midden (loginnaam, wachtwoord én SMS),
wanneer beschikbaar tevens niveau hoog (t.z.t. o.b.v. elektronische Nederlandse Identiteitskaart
of vergelijkbaar).
G29 Authenticatie medewerkers
Authenticatie van medewerkers van Gemeente t.b.v. de 3D-Suite verloopt binnen de firewall van
Gemeente via de directory server van Gemeente [merk, type, versie].
Via andere netwerken is inloggen mogelijk voor daartoe geautoriseerde personen o.b.v. tweefac-
tor-authenticatie (gebruikersnaam+wachtwoord én verificatie via SMS). Na authenticatie via deze
directory server hebben medewerkers van Gemeente via single sign-on (SSO) toegang tot alle
onderdelen van de 3D-Suite (voor zover zij daartoe geautoriseerd zijn).
Authenticatie van medewerkers van buiten de Gemeente t.b.v. de 3D-Suite verloopt via login-
naam/paswoord in combinatie met verificatie via SMS (tweefactor-authenticatie). Gemeente kan
vereisen dat een fysiek token wordt gebruikt.
S39. Autorisatiestructuur
De autorisaties van gebruikers t.b.v. de 3D-Suite worden binnen de 3D-Suite vastgelegd. Hiertoe
worden alle rechten (CRUD) in de 3D-Suite gekoppeld aan rollen in de 3D-Suite. Rollen in de 3D-
Suite zijn door functioneel beheerders van Gemeente geheel zelfstandig, zonder dat daarvoor ge-
avanceerde programmeerkennis nodig is (zero coding), vrij te definiëren en kunnen gekoppeld
worden aan één of meer groepen in de directory server van Gemeente, die hiertoe realtime inge-
lezen worden in de 3D-Suite.
130
Naast door functioneel beheer vooraf gedefinieerde rollen zijn tevens ad-hoc rechten uit te geven
door daartoe voor de betreffende dossier / burger / zaak geautoriseerde personen (zoals regis-
seurs).
O86 Autorisatiemodel
Beschrijf het autorisatiemodel van de 3D-Suite. Ga daarbij ten minste in op (voor zover van toe-
passing):
- Het ad-hoc uitdelen van rollen en rechten door de burger en door de regisseur.
- De „granulariteit‟ (fijnmazigheid) waarmee autorisaties kunnen worden beheerd (CRUD) en de
wijze waarop dit geschiedt. Ga daarbij ten minste in op (voor zover van toepassing):
Het toekennen van verschillende typen rechten (CRUD).
Het toekennen van rechten aan rollen [(incl. de rol „burger‟)], groepen, individuen, applica-
ties, etc. Ga daarbij ook in op de eventuele mogelijkheid tot het „clusteren‟ van rechten in
„profielen‟ (vgl. „clusteren‟ van individuen in rollen/groepen) die op soortgelijke wijze kun-
nen worden toegekend, alsmede op het „afleiden‟ van autorisaties uit aanvullende geregi-
streerde gegevens bij gebruikers (zoals kennis van specifieke onderwerpen).
Het toekennen van rechten op het niveau van zaken / deelzaken, maar bijvoorbeeld ook op
registraties, entiteiten, attributen / velden („rubrieken‟), etc. en hun onderlinge relaties en
op individuele cliënten, dossiers, documenten, etc.
De eventuele afhankelijkheid van dergelijke autorisaties t.a.v. aspecten zoals het betreffen-
de zaaktype, de actuele status / stap / taak (zie par. 4.2.4), de van toepassing zijnde be-
drijfs-/meldingregels, behandel-/archieffase, etc.
Beschrijf ook in welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a.
volledig zelfstandig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero co-
ding), kunnen beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus).
- De wijze waarop door middel van autorisaties en/of eventuele andere soortgelijke maatregelen
invulling gegeven wordt aan wettelijke voorschriften zoals doelbinding, functiescheiding, etc.
- Of en zo ja hoe wordt afgedwongen dat bij autorisatiewijzigingen de betreffende gebruiker(s),
vanaf het moment waarop deze worden doorgevoerd, geen handelingen meer kunnen verrich-
ten die zij dan niet meer mogen (c.q. juist wel), bijvoorbeeld door opnieuw inloggen te „force-
ren‟.
O87 Visie en mogelijkheden autorisatie
Beschrijf uw visie op – en de mate waarin dit ondersteund wordt door de 3D-Suite – autorisatie
en authenticatie van burgers, medewerkers binnen de gemeente, etc.
Bespreek daarbij zowel het gebruiksgemak, als de privacy en het beperken van de gevaren voor
veiligheid en privacy wanneer onverhoopt iemand ten onrechte toegang verschaft tot de 3D-Suite
(als burger of als medewerker).
8.5 Auditing / logging
O88 Auditing / logging
Beschrijf de functionaliteit van de 3D-Suite m.b.t. auditing / logging. Ga daarbij ten minste in op
131
(voor zover van toepassing):
- De verschillende handelingen en pogingen daartoe waarvan logging plaatsvindt, zoals opvra-
gen (incl. zoeken), inzien (incl. printen), creëren / toevoegen, muteren, verwijderen, archive-
ren, etc. van gegeven, maar ook het in- / uitloggen op het netwerk, in de 3D-Suite, etc.
- De verschillende elementen waarop dergelijke handelingen worden gelogd, zoals registraties,
entiteiten, attributen / velden („rubrieken‟), etc. maar bijvoorbeeld ook zaken en zaakattribu-
ten, documenten en documentattributen, notities, statuswijzigingen, het afvinken van check-
lists, etc.
- Wat er precies wordt vastgelegd, zoals wie de handeling of poging daartoe heeft uitgevoerd
(personen resp. applicaties, zo mogelijk incl. de „achterliggende‟ personen), wanneer (datum /
tijd) dit geschiedde, etc.
- De wijze waarop gegevensuitwisseling via koppelvlakken wordt gelogd en geaudit (incl. wie,
wanneer, wat)
- Hoe lang de logs bewaard blijven, incl. de flexibiliteit dienaangaande (zoals mogelijkheden om
ad hoc af te wijken en (delen van) logging (tijdelijk) uit te zetten) en hoe dit wordt geautori-
seerd. Beschrijf ook hoe en op welke wijze niveaus (objecten, attributen, gebruikers, etc.) de
logs geraadpleegd kunnen worden in de 3D-Suite en hoe dit wordt geautoriseerd. Geef tenslot-
te aan of van de eventuele vernietiging van logs voldoende informatie beschikbaar blijft om dit
te traceren.
- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in de
3D-Suite (zoals via configuratie van zaaktypen in een zaaktypencatalogus).
- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-
standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen
beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus).
O89 Protocollering
Beschrijf de wijze waarop door middel van auditing / logging en/of eventuele soortgelijke maatre-
gelen invulling gegeven wordt protocollering. Ga daarbij ten minste in op (voor zover van toepas-
sing):
- Of daarbij ten minste daartoe alle noodzakelijke gegevens (identificatie zoals een BSN, datum,
behandelende ambtenaar, gebruikte procedure, verstrekte gegeven worden geregistreerd.
- Of daarbij zowel alle verplicht als optioneel te protocolleren handelingen worden geprotocol-
leerd (bij voorkeur wel), zoals inzage d.m.v. geautoriseerde toegang, herleidbare verstrekkin-
gen d.m.v. geautoriseerde toegang (systematisch, spontaan en selecties), etc. Beschrijf tevens
hoe voorkomen wordt dat verplicht niet te protocolleren handelingen geprotocolleerd worden.
- Het eventuele onderscheid tussen interne (binnen Gemeente) en externe verstrekkingen resp.
automatisch en handmatig protocolleren, of dat in alle gevallen van dezelfde handelingen de-
zelfde gegevens worden geregistreerd.
- De wijze waarop het „archiefregime‟ (bewaren / vernietigen) van de betreffende logging is in-
geregeld en kan worden beheerd.
- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in de
3D-Suite (zoals via configuratie van zaak-/objecttypen in een zaak-/objecttypencatalogus).
- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-
standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen
beheren (zoals via configuratie van zaak-/objecttypen in een zaak-/objecttypencatalogus).
132
O90 Inzichtelijkheid audit logs
Beschrijf de functionaliteit van de 3D-Suite m.b.t. weergave van auditing / logging. Ga daarbij ten
minste in op (voor zover van toepassing):
-
- In welke mate en op welke wijze dit middels configuratie door Contractant is ingericht in de
3D-Suite (zoals via configuratie van zaaktypen in een zaaktypencatalogus).
- In welke mate en op welke wijze functioneel beheerders van Gemeente e.e.a. volledig zelf-
standig, zonder dat daarvoor geavanceerde programmeerkennis nodig is (zero coding), kunnen
beheren (zoals via configuratie van zaaktypen in een zaaktypencatalogus).
8.6 Technische beveiliging en integriteit
O91 Technische beveiliging en integriteit
Beschrijf welke maatregelen er door wie (Contractant, Gemeente [resp. de partij die de hosting
van de 3D-Suite verzorgt]) getroffen dienen te worden, alsmede welke functionaliteit de 3D-Suite
daartoe biedt, om:
- Een adequate (informatie)beveiliging in technische zin te garanderen, alsmede welke functio-
naliteit de 3D-Suite daartoe biedt. Ga daarbij tenminste in op (voor zover van toepassing):
Data- en communicatiebeveiliging (zoals SSL, HTTPS, WS-Security, SAML 1/2, XCAML,
etc.).
Netwerkbeveiliging (zoals firewalls).
Integriteit, authenticiteit, vertrouwelijkheid, onweerlegbaarheid, etc.
De wijze waarop de beveiliging van koppelvlakken in technische zin gegarandeerd is, zoda-
nig dat uitsluitend daartoe geautoriseerde systemen met de 3D-Suite kunnen „interacteren‟.
Denk in dat kader bijvoorbeeld aan het gebruik van:
Encryptie (zowel t.a.v. gegevens als t.a.v. communicatie).
PKI- en andere certificaten, elektronische handtekeningen, WYSIWYS, etc.
Het gebruik van protective markings, timestamps, etc.
Het rollen- en rechtenmodel (zie par. 8.4).
Websitebeveiliging (zoals m.b.t. serverside en cross-site scripting), hackerstests (zoals
i.v.m. SQL-injects en dergelijke), etc.
- De integriteit van gegevens (incl. documenten) te waarborgen, bijvoorbeeld indien (delen van)
de 3D-Suite, externe applicaties (incl. bij ketenpartners en/of landelijke voorzieningen), etc.
niet beschikbaar zijn. Ga daarbij ten minste in op (voor zover van toepassing):
Hoe omgegaan wordt met vastgelopen / afgebroken transacties (zowel batch als realtime).
Roll-back, incl. toelichting van het roll-back mechanisme o.v.v. de minimale en maximale
omvang van roll-backs (hoeveel/welke gegevens daarbij betrokken zijn).
Back-up & herstel (zonder downtime), incl. herstelprocedure m.b.t. berichtenverkeer.
Record locking.
Uitwijk t.b.v. calamiteiten (met maximale beperking van downtime en dataverlies).
Maatregelen die het wijzigen van gegevens (incl. documenten) buiten (de webinterface van)
de 3D-Suite om voorkomen (zoals bij koppelingen).
133
8.7 Overig (beveiliging)
O92 Beveiliging: overige functionaliteiten
Beschrijf alle eventuele additionele standaardfunctionaliteit van de 3D-Suite m.b.t. beveiliging die
naar uw mening i.h.k.v. hoofdstuk 8 relevant is. Denk in dat kader bijvoorbeeld aan:
- (Functionele en/of technische) „maatregelen‟ die voorkomen dat auditing / logging en (automa-
tische) protocollering merkbaar ten koste gaan van de performance van de 3D-Suite.
- Functionaliteiten m.b.t. (randvoorwaarden aan) wachtwoorden, zoals de verplichting tot sterke
wachtwoorden, de verplichting om wachtwoorden periodiek te veranderen, of accounts worden
geblokkeerd na een instelbaar aantal mislukte inlogpogingen, etc.
- Functionaliteit m.b.t. signalering / logging van (dreigend) misbruik, incl. beveiliging tegen ex-
terne DoS- en andere aanvallen, virussen, malware, etc.
- Functionaliteit m.b.t. het monitoren remote access.
NB: Benoem uitsluitend functionaliteit die is inbegrepen bij de prijsopgave en als zodanig zonder
(additionele) kosten direct „off-the-shelf‟ beschikbaar is. Licht de beantwoording zo mogelijk toe
d.m.v. schermafbeeldingen.
134
9 PvE: Architectuur
9.1 Inleiding
Dit hoofdstuk 9 bevat wensen en eisen t.a.v. de architectuur van de 3D-Suite. Hierbij wordt een
indeling gehanteerd naar verschillende typen architectuur: functionele architectuur (par. 9.2),
softwarearchitectuur (par. 9.3), client- en serverside architectuur (par. 9.4) en technische
architectuur (par. 9.5), aangevuld met de onderwerpen beschikbaarheid en performance (par. 9.6)
en beleid en (open) standaarden (par. 9.7). Tenslotte volgen
9.2 Functionele architectuur
O93 Functionele architectuur: algemeen
Geef een uitputtende opsomming van alle bij de beantwoording van de wensen en eisen in dit PvE
gebruikte applicatie(module)s, incl. alle eventuele add-ons, (configuratie)tools, etc. Benoem
daarbij tevens alle applicatie(module)s, add-ons, (configuratie)tools, etc. van de 3D-Suite voor
zover:
- het intellectueel eigendomsrecht daarvan berust bij verschillende (niet: meerdere) partijen -
hoofdaannemer, onderaannemer, deelnemers aan de combinatie, toeleveranciers (incl. OEM),
etc. - en/of
- die ontwikkeld en/of onderhouden worden door verschillende (niet: meerdere) partijen -
hoofdaannemer, onderaannemer, deelnemers aan de combinatie, toeleveranciers (incl. OEM),
etc. - en/of
- die middels een (interne) koppeling geïntegreerd worden, en/of
- die ontwikkeld zijn m.b.v. verschillende (niet: meerdere) technologieën - zoals C#, C++,
Delphi, Java, Perl, php, PL/SQL, Progress, Ruby, VB .NET, etc.) - en/of
- daarbij sprake is van een verschillende (niet: meerdere) „codebase‟, en/of
- daarbij sprake een verschillende (niet: meerdere) gebruikers- en/of beheerinterface.
Vermeld bij alle aldus benoemde elementen steeds de eventuele versie- en andere relevante aan-
duidingen (zoals „enterprise‟, „basic‟, „community‟, etc.), alsmede of deze open source zijn. Indien
er afhankelijkheden bestaan tussen aldus benoemde elementen, dient dit te worden aan te geven
(bijv. als deze technisch en/of functioneel niet gescheiden kunnen worden).
Beschrijf ten slotte de functionele (software)architectuur van de 3D-Suite, incl. architectuur-
schets; deze dient alle aldus benoemde (applicatie(module)s, add-ons, (configuratie)tools, etc.) te
bevatten. Beschrijf daarbij hoe de verschillende functionele elementen van de 3D-Suite samen-
hangen c.q. zich tot elkaar verhouden, incl. in hoeverre de 3D-Suite modulair van opzet is en of
sprake is van gedeelde repositories, beheer-, configuratie- en/of andere tools en/of -interfaces,
etc. Beschrijf daarbij ook in hoeverre de architectuur van de 3D-Suite „open‟ is en voldoet aan
(architectuur)standaarden zoals GEMMA, NORA, etc.
E14 Functionele architectuur: (configuratie)tools
Voor alle eventuele (configuratie)tools die nodig zijn voor implementatie, gebruik en/of (functio-
neel en/of technisch) beheer van de 3D-Suite geldt dat deze of deel uit maken van de levering
en/of commercieel vrij verkrijgbaar zijn.
O94 Releasebeleid
Beschrijf het releasebeleid van de 3D-Suite met betrekking tot Nieuwe en Verbeterde Versies zo-
als (major- en minor)releases, patches, updates, etc. Voeg tevens een releaseplanning / roadmap
135
bij met alle geplande (major- en minor)releases, updates, etc. van de komende 2 jaar. Vermeld
daarbij ook de eventuele uitfasering, vervanging, etc. van (onderdelen van) applicaties.
Geef tevens per onderdeel van de 3D-Suite aan in hoeverre het is toegestaan dat de Gemeente
nog ten minste 2 jaar na een nieuwe major release nog op de vorige major release blijft. Beschrijf
ten slotte in hoeverre updates van de 3D-Suite door de Gemeente zelf zijn uit te voeren.
NB: Deze wens heeft betrekking op de volledige 3D-Suite. Indien uw 3D-Suite uit meerdere appli-
caties bestaat, ga bij uw beantwoording dan in op elke applicatie afzonderlijk.
O95 Multi-tenancy
Geef aan of, en zo ja welke, functionaliteiten de 3D-Suite biedt met betrekking tot multi-tenancy.
Dat wil zeggen dat verschillende gemeenten - ook in technische zin - gebruikmaken van één 3D-
Suite (één codebase, bijv. o.b.v. SaaS), met logisch gescheiden „compartimenten‟ voor de
configuratie per gemeente („tenants‟) doch met gescheiden databases, waarbij elke gemeente
gebruik maakt van dezelfde versie van de 3D-Suite.
Maak bij uw beantwoording (per niveau) indien van toepassing steeds ten minste onderscheid
tussen de onderstaande onderdelen van de 3D-Suite. Besteed tevens aandacht aan de mate
waarin privacy en beveiliging gegarandeerd kunnen worden.
O96 Toekomstvisie
Beschrijf uw visie op het sociale domein voor gemeenten in het algemeen en voor Gemeente in
het bijzonder - voor zowel de korte (binnen 2 jaar) als de langere termijn (2-10 jaar) - incl. hoe
deze visie zich verhoudt tot de huidige functionaliteit van de 3D-Suite en de releaseplanning. Ga
daarbij ook in op de “toekomstvastheid” van de 3D-Suite t.a.v. relevante ontwikkelingen m.b.t. de
e-overheid, zoals de verschillende andere basisregistraties en het toenemende belang van “self-
service” door burgers (elektronische dienstverlening via het web).
9.3 Softwarearchitectuur
O97 Softwarearchitectuur: algemeen
Beschrijf de wijze waarop de software van (de verschillende elementen van) de 3D-Suite wordt
(door)ontwikkeld, incl. het eventuele gebruik van (meer of minder geformaliseerde) methoden en
best-practices (zoals agile / scrum, prototyping / RAD, RUP, waterval / SDM, etc.) en de wijze
waarop daarbij invulling wordt gegeven aan quality assurance.
Ga daarbij v.w.b. softwareontwikkeling ten minste in op de wijze waarop daarbij rekening gehou-
den wordt met aspecten als integriteit, onderhoudbaarheid, portabiliteit, betrouwbaarheid,
schaalbaarheid, beveiliging, efficiency, performance en andere aspecten als beschreven in de ex-
tended ISO 9126 norm, incl. de wijze waarop het ontwikkelproces wordt gedocumenteerd.
Ga daarbij v.w.b. quality assurance ten minste in op de wijze waarop invulling wordt gegeven aan
testen (incl. de daartoe gehanteerde meer of minder geformaliseerde methoden en best-
practices), incl. aard, omvang en frequentie van de verschillende tests (zoals unit-, integratie- en
systeemtests) en de wijze waarop het testproces wordt gedocumenteerd.
Relateer e.e.a. daarnaast aan privacy by design zoals gevraagd in O85 op blz. 128.
Beschrijf tenslotte waar - in Nederland, near-shore, off-shore - en door wie (organisatie) de soft-
136
ware (door)ontwikkeld wordt en met welke tooling. Beschrijf daarbij ook de (omvang en specifie-
ke expertise van) ontwikkel- en testteam(s), incl. eventuele relevante certificeringen t.a.v. soft-
wareontwikkeling - incl. tooling en beheerkennis - en quality assurance, v.w.b. zowel organisaties
als personen.
9.4 Client- en serverside architectuur
E15 Clientside architectuur: webbased
- Burgers en eindgebruikers: Alle gebruikersinterfaces van de 3D-Suite voor burgers (incl.
gezinnen) zijn „volledig webbased‟; d.w.z. dat clientside plug-ins (zoals Java, Flash, ActiveX,
SilverLight, etc.) niet zijn toegestaan (NB: Javascript is wel toegestaan).
- Functioneel beheerders en managementrapportages: Alle gebruikersinterfaces van de
3D-Suite voor eindgebruikers zijn „webbased‟, waarbij clientside plug-ins (zoals Java, Flash,
ActiveX, SilverLight, etc.) wel zijn toegestaan
- [Technisch beheerders: Gebruikersinterfaces voor technisch beheerders hoeven niet nood-
zakelijkerwijs „webbased‟ te zijn.]
NB: volledig webbased wil hier bovendien zeggen dat deze gebruikersinterfaces ten minste bena-
derbaar zijn met browsers MS Internet Explorer (versies [XX] en hoger), Mozilla Firefox (versie
[XX] en hoger) en Google Chrome (versie [XX] en hoger), v.w.b. álle gevraagde en geboden func-
tionaliteit zonder enige beperking voor wat betreft weergave en functionaliteit.
NB: De term „eindgebruiker‟ heeft hier betrekking op medewerkers van Gemeente (uitgezonderd
functioneel [en technisch] beheerders), maar ook van alle ketenpartners.
E16 Clientside architectuur: communicatie o.b.v. HTTPS
Alle communicatie tussen clients en de 3D-Suite geschiedt volledig op basis van HTTPS, voor alle
gebruikersinterfaces (dus t.b.v. zowel eindgebruikers als functioneel [en technisch] beheerders).
NB: De term „eindgebruiker‟ heeft hier betrekking op medewerkers van Gemeente (uitgezonderd
functioneel [en technisch] beheerders) [alsook op burgers (voor zover van toepassing)].
O98 Clientside architectuur: algemeen
Beschrijf welke clientside technologieën de 3D-Suite ondersteunt, incl. besturingssystemen (Win-
dows, Linux, etc.) en browsers (Internet Explorer, FireFox, Opera, Safari, Chrome, etc.). Geef
daarbij steeds aan welk(e) versienummer(s) het betreft, incl. het beleid t.a.v. op- en neerwaartse
compatibiliteit m.b.t. versies van de betreffende browser.
Beschrijf bovendien voor elke clientside technologie de mogelijkheden, randvoorwaarden en even-
tuele beperkingen m.b.t. Javascript en overige clientside scripting, alsmede m.b.t. Java, Flash,
ActiveX, SilverLight en overige plug-ins (plug-ins zijn bij voorkeur niet nodig). Beschrijf bovendien
of - en zo ja welke - er specifieke (beveiligings)instellingen op de client nodig zijn voor het correct
functioneren van de 3D-Suite.
Beschrijf tevens alle randvoorwaarden (minimale en eventuele specifieke requirements) m.b.t.
clientside hardware voor zowel werkplekken als mobiele devices (tablets, smartphones, etc.) voor
het correct functioneren van de 3D-Suite. Ga daarbij ten minste in op (voor zover van toepassing)
minimale en maximale schermresolutie, benodigde processorsnelheid/geheugen/bandbreedte en
eventuele beperkingen bij gebruik van een „hosted desktop‟ (Citrix en vergelijkbaar).
NB: Maak bij de beantwoording steeds onderscheid tussen de rollen eindgebruiker en functioneel
137
[en technisch] beheerder.
O99 Serverside architectuur: algemeen
Beschrijf de serverside architectuur van de 3D-Suite, incl. architectuurschets (schema met appli-
catie-, web- en databaseservers, etc.). Deze beschrijving dient alle applicatie(module)s, add-ons,
(configuratie)tools, etc. van de 3D-Suite te bevatten (zie O93 op blz. 134), waarbij de nadruk bij
de beschrijving dient te liggen op de technische aspecten van de softwarecomponenten. Beschrijf
daarbij ook hoe deze componenten samenhangen c.q. zich tot elkaar verhouden. Ga daarbij ten
minste in op (voor zover van toepassing):
- De verdeling over web-, applicatie- en databaseservers en de mogelijkheden van de software-
componenten dienaangaande, gegeven de gewenste performance, beschikbaarheid en beveili-
ging.
- Virtualisatie, clustering, load balancing, caching, fail-over, etc. en de mogelijkheden van de
softwarecomponenten dienaangaande, gegeven de gewenste beveiliging, beschikbaarheid en
performance.
- De N-tier architectuur en de mogelijkheden van de softwarecomponenten dienaangaande.
Beschrijf ten slotte hoe de verschillende applicatie(module)s, add-ons, (configuratie)tools, etc.
zoals benoemd in beantwoording van O93 op blz. 134 samenhangen c.q. zich tot elkaar verhou-
den, v.w.b. serverside platforms (Linux, Windows, etc.), componentmodellen (.NET, Java, etc.) en
programmeer- en scripttalen (C#, C++, Delphi, Java, Perl, php, PL/SQL, Progress, Ruby, VB .NET,
etc.).
NB: Maak bij de beantwoording steeds onderscheid tussen T, A, P en U.
9.5 Technische architectuur
In onderhavige paragraaf wordt van uit gegaan dat hosting en technisch beheer van de 3D-Suite
niet meegeleverd worden door de leverancier van de 3D-Suite, maar wordt gedaan door de
Gemeente zelf of door een derde partij. Als het bestek voor een daadwerkelijke aanbesteding t.b.v.
een specifieke gemeente of groep van gemeenten wordt opgesteld, dient e.e.a. dan ook mogelijk
aangepast te worden conform de specifieke voorkeuren dienaangaande. Daarnaast kunnen
gemeentespecifieke omstandigheden aanleiding zijn tot additionele eisen / wensen, zoals m.b.t.
eventuele complicaties in een Citrix- of soortgelijke omgeving en andere randvoorwaarden t.a.v. de
technische infrastructuur (zoals server- en DBMS-platforms).
E17 Technische architectuur: compatibiliteit
[Evt. eisen en randvoorwaarden t.a.v. compatibiliteit met bestaande technische infrastructuur.]
O100 Technische architectuur: schaalbaarheid
Beschrijf de technische en functionele infrastructuur van de 3D-Suite die nodig is t.b.v. schaal-
baarheid, gegeven het beoogde aantal gebruikers (ca. [XX]) en de gewenste performance, be-
schikbaarheid en beveiliging. Voeg hiertoe een architectuurschets bij en beschrijf de verschillende
mogelijke „maatregelen‟ en technieken om zowel de horizontale (zoals extra servers, load balan-
cers, etc.) als verticale schaalbaarheid (zoals zwaardere servers) van de 3D-Suite verder uit te
bouwen. Ga daarbij ten minste in op (voor zover van toepassing): caching, clustering, load balan-
cing, fail-over, virtualisatie, etc. en beschrijf welke merkbare gevolgen het verhogen van de hori-
zontale resp. verticale schaalbaarheid heeft voor eindgebruikers [(incl. burgers)], functioneel [en
138
technisch] beheerders, etc.
Beschrijf tenslotte de (technische en/of functionele) grenzen t.a.v. het aantal openstaande en af-
gesloten zaken / processen, (zaak-/object)documenten en -dossiers, etc. alsmede t.a.v. reële
maxima m.b.t. de omvang van attachments, (zaak-/object)documenten en -dossiers, etc. in de
3D-Suite.
NB: Maak bij de beantwoording steeds onderscheid tussen T, A, P en U.
O101 Technische architectuur: algemeen
Beschrijf de verschillende mogelijkheden en randvoorwaarden (minimale en eventuele specifieke
requirements, incl. benodigde aantallen) v.w.b. de technische infrastructuur (incl. alle servers,
SAN‟s, domein-/netwerkstructuur, plaatsing van firewalls, etc.) van de 3D-Suite in termen van:
- Virtualisatie-architectuur van web-, applicatie en database-servers en/of opslag.
- Sizing en redundantie van de verschillende elementen (zoals servers, hubs, SAN‟s, etc.) incl.
aantallen CPU‟s, geheugen, opslag, etc.
- Serverside platforms (zoals typen besturingssystemen, web- en applicatieservers, databa-
se(server)s, bestandssystemen, SAN‟s, etc.).
- De mate waarin sprake is van gedeelde servers, communicatie (hubs etc.) en databa-
ses/SAN‟s.
- Eventuele andere technische / infrastructurele aspecten (zoals netwerk, bandbreedte, opslag-
capaciteit, hubs, firewalls, etc.).
- Communicatie tussen de verschillende elementen (zoals netwerk, protocollen en poortnum-
mers, beveiliging, autorisaties, etc.).
- Koppelingen met internet en landelijke voorzieningen, gemeentelijke systemen en dergelijke
(incl. bandbreedte en redundancy).
Beschrijf daarbij wat nodig is om de 3D-Suite correct te laten functioneren, gegeven de gewenste
performance, beschikbaarheid en beveiliging en het beoogde aantal medewerkers (ca. [XX]), uit-
gesplitst naar T-, A-, P- en U (ten minste [XX] separate omgevingen, bijvoorbeeld [XX]. Geef
daarbij bovendien aan welke merken / typen / versies systeemsoftware (besturingssystemen, da-
tabases, web-/applicatieservers, etc.) verplicht zijn en welke alternatieven mogelijk zijn.
Beschrijf tenslotte het transitieproces tussen T, A, P en U i.h.k.v. nieuwe en verbeterde versies
van (elementen van) de 3D-Suite aan de hand van een voorbeeld (incl. schematische weergave).
Beschrijf daarbij ook de eventuele consequenties van wijzigingen in de implementatie-inrichting /
configuratie van (elementen van) de 3D-Suite, incl. de voor het functioneren van de 3D-Suite be-
nodigde systeemsoftware.
NB: Maak bij de beantwoording steeds onderscheid tussen T, A, P en U.
O102 Technische architectuur: technisch beheer
Beschrijf de functionaliteit en beschikbare hulpmiddelen van de 3D-Suite m.b.t. het technisch be-
heer van de 3D-Suite. Ga daarbij ten minste in op:
- Eigen (1P) beheer-, rapportage-, monitoring- en analysetools - incl. de betreffende beheerin-
terface(s) - incl. toelichting.
- Alle eventuele met de 3D-Suite meegeleverde standaardkoppelingen met beheer-, rapportage-
, monitoring- en analysetools van derden (3P), incl. toelichting per standaardkoppeling.
- Scripting.
Beschrijf bovendien hoeveel FTE Gemeente structureel nodig heeft om de 3D-Suite technisch te
139
beheren, o.v.v. de specifieke expertise, kennis, vaardigheden, etc. die hiertoe aanwezig veronder-
steld wordt bij technisch beheerders. Doe dit zowel voor de volledige 3D-Suiteals geheel als voor
elk van de afzonderlijke elementen daarvan (indien van toepassing).
[Beschrijf tenslotte of - en zo ja en onder welke voorwaarden - nieuwe en verbeterde versies, up-
dates, (beveiligings)patches, etc. van de 3D-Suite door medewerkers van de partij die de hosting
van de 3D-Suite gaat verzorgen geheel zelfstandig zijn uit te voeren, o.b.v. expliciete (gedocu-
menteerde) installatie-instructies, -scripts, etc. die daartoe door Contractant worden verstrekt.]
O103 Technische architectuur: ASP / SaaS
Beschrijf de mogelijkheden om de 3D-Suite geheel of gedeeltelijk „in de cloud‟ te plaatsen. Ga
daarbij ten minste in op de mate waarin de 3D-Suite in technische zin geschikt is om op afstand
te benaderen en geef aan welke eisen en randvoorwaarden dit stelt aan bandbreedte, beveili-
gingsaspecten, etc. gegeven de gewenste beveiliging, beschikbaarheid en performance. Beschrijf
daarbij ook mogelijkheden m.b.t. de bijbehorende dienstverlening, zoals i.h.k.v. technisch beheer.
9.6 Beschikbaarheid en performance
E18 Beschikbaarheid
De 3D-Suite wordt ingericht zodanig dat, uitgaande van een beschikbaarheid van de technische
infrastructuur van 100%, de beschikbaarheid van productieomgeving van de 3D-Suite op [Werk-
dagen van 07:00 tot 21:00] uur voor ten minste [99,9%] gegarandeerd wordt en voor de overige
uren van de week (incl. weekenden) voor ten minste [99,0%] gegarandeerd wordt.
De beschikbaarheid van test-, acceptatie- en uitwijkomgevingen van de 3D-Suite wordt op
[Werkdagen van 07:00 tot 19:00] uur voor ten minste [98,0%] gegarandeerd.
De beschikbaarheid wordt daarbij gemeten over een periode van een kwartaal.
G30 Beschikbaarheid (additioneel)
De 3D-Suite wordt ingericht zodanig dat, uitgaande van een beschikbaarheid van de infrastruc-
tuur van 100%, de beschikbaarheid van de productieomgeving van de 3D-Suite op werkdagen
van [XX] tot [XX] uur voor ten minste [XX]% is gegarandeerd en in de overige uren van de week
(incl. weekenden) voor ten minste [XX]% is gegarandeerd.
De beschikbaarheid wordt daarbij gemeten over een periode van [XX].
E19 Performance
De 3D-Suite is in staat om de medewerkers en de burgers met een acceptabele performance te
bedienen, gegeven voldoende doch realistische lokale hardware. Dat wil zeggen dat:
- In de productieomgevingen van de 3D-Suite alle interactieve gebruikersinterfaces voor rollen
eindgebruikers en functioneel beheerders in ten minste 90,0% van de gevallen binnen #2# se-
conden worden getoond.
- In de test-, acceptatie- en uitwijkomgevingen van de 3D-Suite alle interactieve gebruikersin-
terfaces van de 2D-Suite voor rollen eindgebruikers en functioneel beheerders in ten minste
90,0% van de gevallen binnen #2# seconden worden getoond.
140
G31 Performance (additioneel)
De 3D-Suite is in staat om de [XX] gebruikers van Gemeente (zie de toelichting in bijlage [XX])
met afdoende performance te bedienen, gegeven voldoende doch realistische hardware.
Dat wil zeggen dat in de productieomgeving van de 3D-Suite alle interactieve gebruikersinterfaces
van de 3D-Suite voor de rollen eindgebruikers en functioneel beheerders in ten minste [XX]% van
de gevallen binnen [XX] seconden worden getoond en de responstijd voor batchverwerkingen in
ten minste [XX]% van de gevallen maximaal [XX] seconden bedraagt.
Dit geldt zowel bij een reguliere belasting van [XX] transacties / zaken / documenten per [perio-
de] als bij een piekbelasting van [XX] transacties / zaken / documenten per [periode]. De 3D-
Suite is hiertoe ook in staat wanneer het een archief van [XX] jaar bevat dat kan worden door-
zocht (op basis van gemiddeld [XX] burgers en bijbehorende dossiers per jaar).
9.7 Beleid en (open) standaarden
E20 Beleid: open source software
Contractant conformeert zich gedurende de looptijd van de overeenkomst (incl. eventuele verlen-
ging) aan het beleid van Gemeente met betrekking tot open source software. Dit beleid is con-
form het kabinetsbeleid als vastgelegd in het actieplan Nederland Open in Verbinding (NOiV).
E21 Beleid: open standaarden (conformiteit)
Contractant conformeert zich gedurende de looptijd van de overeenkomst (incl. eventuele verlen-
ging) aan alle (open) standaarden zoals vastgelegd in het actieplan Nederland Open in Verbinding
(NOiV). Dit betreft ten minste de voor de opdracht relevante standaarden die door het Forum
Standaardisatie op de „lijst met veelgebruikte open standaarden‟ of de „lijst met open standaarden
voor pas-toe-of-leg-uit‟ zijn geplaatst (peildatum [XX]).
Contractant conformeert zich aan deze open standaarden [o.b.v. het principe van „pas-toe-of-leg-
uit‟]. Dit geldt tevens voor eventuele toekomstige nieuwe releases van deze open standaarden,
d.m.v. de eventuele toepassing daarvan (binnen [XX]) in nieuwe versies van de 3D-Suite. Daar-
naast garandeert Contractant een neerwaartse compatibiliteit van de 3D-Suite met ten minste
[XX] major versie[s] ten aanzien van deze open standaarden.
O104 Verhouding tot KING Basisgemeente
Beschrijf de mate waarin de functionele architectuur van de 3D-Suite conform KING
basisgemeente en/of GEMMA is opgezet en wordt doorontwikkeld.
S40. Beleid: open standaarden (leveranciersmanifest)
Inschrijver heeft het conformeren aan de open standaarden die door het Forum Standaardisatie
zijn aangewezen formeel vastgelegd, door het ondertekenen van het leveranciersmanifest „open
standaarden‟ van NOiV en het ondertekenen van het convenant van Operatie NUP 20.
G32 (Open) standaarden: RGBZ [versie]
Daar waar binnen de 3D-Suite zaakgegevens worden geconfigureerd, geregistreerd of in welke
20 https://new.kinggemeenten.nl/operatie-nup
141
vorm dan ook worden gebruikt of verwerkt, geschiedt dit conform het RGBZ [versie].
Het (datamodel van het) zakenmagazijn is opgezet conform het RGBZ [versie] en ondersteunt
daarmee alle objecttypen en hun respectievelijke attributen in het RGBZ, inclusief hun onderlinge
relaties.
NB: Deze wens heeft betrekking op de volledige 3D-Suite.
S41. (Open) standaarden: RSGB [versie]
Daar waar binnen de 3D-Suite gemeentelijke basisgegevens worden geregistreerd die in het RS-
GB zijn gemodelleerd of in welke vorm dan ook worden gebruikt, verwerkt of uitgewisseld, ge-
schiedt dit conform het RSGB [versie].
Het (datamodel van het) gegevensmagazijn of vergelijkbaar is opgezet conform RSGB [versie] en
ondersteunt daarmee alle objecttypen en hun respectievelijke attributen in het RSGB, inclusief
hun onderlinge relaties.
NB: Deze wens heeft betrekking op de volledige 3D-Suite.
S42. (Open) standaarden: GEMMA ZTC 2.0
Daar waar binnen de 3D-Suite zaaktypen en de bijbehorende aspecten geconfigureerd of in welke
vorm dan ook gebruikt worden, geschiedt dit - tenzij nadrukkelijk anders voorgeschreven in dit
PvE - ten minste (d.w.z. dat uitbreiding is toegestaan) conform de kenmerken zoals deze voor-
komen in de GEMMA ZTC 2.0.
S43. (Open) standaarden: StUF-ZKN
Overal waar binnen de 3D-Suite en/of tussen de 3D-Suite en externe systemen (zoals gemeente-
brede systemen, landelijke voorzieningen, etc.) zaak- en documentgegevens worden uitgewisseld,
geschiedt dit - tenzij nadrukkelijk anders voorgeschreven in dit PvE - ten minste (d.w.z. dat uit-
breiding is toegestaan) conform StUF versie [XX] met sectormodel StUF-ZKN versie [XX] (en dus
niet op een subset daarvan) of het daarvan afgeleide Zaak-DMS-koppelvlak.
Bovendien is het zakenmagazijn van de 3D-Suite o.b.v. StUF-ZKN versie [XX] en het Zaak-DMS-
koppelvlak volledig toegankelijk voor leesacties, met inachtneming van de betreffende autorisa-
ties.
O105 (Open) standaarden: Landelijke Standaard Informatieverkeer Jeugdzorg
De 3D-Suite ondersteunt de standaarden in het jeugddomein. Deze standaarden in het jeugd-
domein zijn een gegeven voor de gemeenten bij het aansluiten op de jeugdketen. De stan-
daarden zijn weergegeven in het document “ Uitgangspunten gegevensstandaarden jeugd”Dit
document is door de VNG, VWS en VEnJ vastgesteld en biedt een compleet overzicht van de
standaarden die in het jeugddomein van belang zijn. Dit betekent dat voor uitwisseling van
gegevens betreffende de jeugdzorg, -bescherming, en -straf de semantiek van de vigerende
standaarden gevolgd wordt. (jzXML resp. EBV).
G33 (Open) standaarden: MO-standaard
De 3D-Suite ondersteunt informatieuitwisseling o.b.v. het BEP-model WMO volledig 21.
21 https://www.zorgregistratie.nl/bep/wmo10/html/aa_reportstart.html
142
G34 [(Open) standaarden: overig domeinspecifiek]
[..]
O106 (Open) standaarden: overig
Beschrijf uw visie en (release)beleid - inclusief roadmap - ten aanzien van (de functionaliteiten
van de 3D-Suite op het gebied van) de ondersteuning van (open) standaarden in het algemeen en
de in deze paragraaf 9.7 genoemde (open) standaarden in het bijzonder.
Geef daarbij bovendien aan welke andere - al dan niet open - (overheids)standaarden de 3D-
Suite ondersteunt en op welke wijze, alsmede in hoeverre de ondersteuning van welke (open)
standaarden door de 3D-Suite is „bewezen‟ (bijvoorbeeld door middel van formele certificering,
positieve testresultaten op testen zoals het StUF-testplatform22, etc.) en voeg eventuele certifica-
ten, testrapporten, verwijzing naar opname in de GEMMA softwarecatalogus, etc. dienaangaande
bij.
9.8 Openheid systeem
G35 Open source tooling
Bij voorkeur wordt gebruik gemaakt van zoveel mogelijk open source tooling. Beschrijf de mate
waarin de 3D-Suite bestaat uit open source componenten (database, configuratietools, etc.) en de
mate waarin de Suite zelf open source wordt aangeboden.
O107 Delen van configuratie met andere gemeenten
Export is mogelijk, excl. vertrouwelijke gegevens, z.d.d. een import mogelijk is dat i.c.m. een ba-
sisimplementatie een werkend systeem oplevert.
Import is mogelijk, z.d.d. een import mogelijk is dat i.c.m. een basisimplementatie een werkend
systeem oplevert. Daarna is de inrichting.
22 Zie www.stuftestplatform.nl
143
10 PvE: Periodieke / doorlopende
dienstverlening
10.1 Inleiding
Dit hoofdstuk 10 bevat wensen en eisen t.a.v. de periodieke / doorlopende dienstverlening m.b.t.
de 3D-suite. Hierbij wordt een indeling gehanteerd naar verschillende typen periodieke /
doorlopende dienstverlening: training (par. 10.2), documentatie (par. 10.3), onderhoud (par.
10.4), ondersteuning (par. 10.5) en escrow (par. 10.6).
10.2 Training
E22 Training: algemeen
Contractant dient eindgebruikers en functioneel [en technisch] beheerders van Gemeente op dus-
danige wijze te trainen en van (trainings)documentatie en eventuele andere hulpmiddelen te
voorzien dat:
- Eindgebruikers geheel zelfstandig met de 3D-Suite hun werkzaamheden uit kunnen voeren.
- Functioneel [resp. technisch] beheerders geheel zelfstandig de 3D-Suite functioneel [resp.
technisch] kunnen configureren en beheren.
O108 Training: eindgebruikers en beheerders
Beschrijf de beschikbare trainingen voor (de verschillende elementen van) de 3D-Suite. Maak
daarbij ten minste onderscheid tussen de onderstaande rollen:
- Regisseur, incl. add-hoc gebruikers-/autorisatie
- Medewerkers bij uitvoeringsorganisaties
- Managers, incl. regie-op-regie
- Functioneel beheerders: Functioneel beheerders zijn verantwoordelijk voor de (functionele)
beheertaken i.h.k.v. het dagelijkse gebruik van de 3D-Suite, zoals functionele applicatie-
instellingen (incl. koppelingen, op functioneel niveau). De training van deze groep dient dan
ook met name hierop betrekking te hebben.
- [Technisch beheerders]: Technisch beheerders zijn verantwoordelijk voor de (technische) be-
heertaken i.h.k.v. de technische infrastructuur „onder‟ de 3D-Suite, incl. de installatie van
nieuwe en verbeterde versies, patches, etc., en technische applicatie-instellingen (incl. koppe-
lingen, op technisch niveau). De training van deze groep dient dan ook met name hierop be-
trekking te hebben.
Vermeld bij de beschrijving van iedere training bovendien ten minste:
- De duur (aantal dagen en sessies, incl. eventueel benodigde voorbereiding), opzet en inhoud.
- Het verondersteld kennisniveau en de mogelijkheden m.b.t. certificering.
- Het maximumaantal deelnemers (groepsgrootte).
- De mogelijkheden m.b.t. on-site training (bij Gemeente) en train-de-trainer.
- De prijs (per deelnemer en/of groep).
NB de burger dient volledig zonder training gebruik te kunnen maken van het systeem!
144
10.3 Documentatie
E23 Documentatie: taal en bestandsformaat
Alle Documentatie voor de gebruikers (medewerkers van Gemeenten) en functioneel beheerders
van de 3D-Suite is volledig Nederlandstalig en bovendien in zodanig “begrijpelijke” taal gesteld
dat ook mensen die wat minder technisch onderlegd zijn e.e.a. kunnen begrijpen. Systeem- en
andere (technische) Documentatie voor technisch beheerders van de 3D-Suite is volledig Neder-
lands- en/of Engelstalig. Alle Documentatie van de 3D-Suite wordt door Contractant aan Gemeen-
te (ook) beschikbaar gesteld in aanpasbare bestandsformaten (dus niet (alleen) als PDF en derge-
lijke).
E24 Documentatie: datamodel(len)
Een volledig gedocumenteerd, integraal datamodel van de 3D-Suite is onderdeel van de levering,
evenals volledig gedocumenteerde individuele datamodellen van de verschillende onderdelen van
de 3D-Suite(voor zover van toepassing). Deze Documentatie wordt gedurende de looptijd van de
Overeenkomst (incl. eventuele verlenging) door Contractant actueel gehouden en voor iedere
Nieuwe en Verbeterde versie van de 3D-Suite aan Gemeente opgeleverd.
E25 Documentatie: API’s
Alle API‟s waarover de 3D-Suite beschikt, worden meegeleverd en zijn gedocumenteerd.
E26 Documentatie: duplicatie
Gemeente heeft het recht om alle Documentatie van de 3D-Suite te dupliceren en te distribueren
voor intern gebruik, alsmede aan uitvoeringsorganisaties en andere partijen die voor c.q. namens
Gemeente werkzaamheden verrichten.
E27 Documentatie: eventuele toekomstige aanbesteding / migratie
T.b.v. een eventuele toekomstige aanbesteding en/of migratie (bijvoorbeeld na de beëindiging
van de Overeenkomst) verklaart Contractant zich bereid tot het verstrekken (aan Gemeente) van
alle voor het betreffende doel (migratie) relevante (aanvullende) Documentatie van de gehele 3D-
Suite, incl. alle functionele ontwerpen en beschrijvingen met inbegrip van (logische) datamodellen
en technische ontwerpen van alle relevante koppelingen. Daarnaast verklaart Contractant zich ak-
koord met de verstrekking daarvan - onder toezegging van vertrouwelijkheid - aan eventuele be-
langhebbenden in dat kader (zoals potentiële deelnemers aan een dergelijke aanbesteding, partij-
en die diensten leveren aan Gemeente op het gebied van migratie, etc.).
O109 Documentatie: algemeen
Beschrijf de beschikbare Documentatie voor de 3D-Suite. Maak daarbij (indien van toepassing)
onderscheid tussen de verschillende rollen waaronder ten minste de verschillende typen gebrui-
kers en functioneel en technisch beheerders. Vermeld bij de beschrijving van deze Documentatie
ten minste:
- Of deze generiek en/of specifiek (voor Gemeente) is en in welke taal en vorm (online, elektro-
nisch, hardcopy, etc.) deze beschikbaar is.
- De beschikbaarheid van zoekfuncties (incl. de contextgevoeligheid daarvan), wizards, etc.
- Of bij Nieuwe en verbeterde Versies van (het betreffende onderdeel van) de 3D-Suite de be-
treffende Documentatie wordt geüpdatet, incl. een begeleidende samenvatting (“what‟s new”).
145
- De mogelijkheid om elektronische Documentatie (incl. helpschermen) te wijzigen en/of aan te
vullen, incl. in welke mate dit door Gemeente zelf kan worden gedaan, alsmede of dergelijke
wijzigingen/aanvullingen intact blijven bij Nieuwe en Verbeterde Versies van de 3D-Suite.
10.4 Onderhoud
E28 Onderhoud: algemeen
Contractant garandeert de toekomstige (door)ontwikkeling en Ondersteuning van de gehele 3D-
Suite - dus incl. koppelingen etc. - gedurende de looptijd (incl. eventuele verlening) van de Over-
eenkomst, zonder additionele kosten. D.w.z. dat Contractant gedurende de looptijd (incl. even-
tuele verlenging) van de Overeenkomst verantwoordelijk is voor het correct en probleemloos
(blijven) functioneren en kunnen (blijven) gebruiken en beheren van de gehele 3D-Suite, alsmede
voor het installeren (door middel van expliciete (gedocumenteerde) installatie-instructies, -
scripts, etc.) en configureren van Nieuwe en Verbeterde versies van de gehele 3D-Suite, waaron-
der major- en minorreleases, (beveiligings)patches, updates, etc.
Als zodanig is ten minste vereist dat de gehele 3D-Suite “meegroeit” met alle ontwikkelingen op
het gebied van de betreffende wet- en regelgeving, wijzigingen in onderliggende technologieën en
platforms (zoals besturingssystemen, server- en DBMS-platforms, etc.), wijzigingen in de vrouw-
tjes van koppelingen, etc.
Contractant is tevens verantwoordelijke voor het afsluiten van alle eventuele contracten met Toe-
leveranciers voor alle Onderhoud en Ondersteuning die nodig zijn voor het correct en probleem-
loos (blijven) functioneren en kunnen (blijven) gebruiken en beheren van de gehele 3D-Suite.
De volledige bovenstaande garantie is van toepassing op alle voor het correct en probleemloos
(blijven) functioneren en kunnen (blijven) gebruiken en beheren van de gehele 3D-Suite benodig-
de software en is onafhankelijk van de wijze waarop softwareleveranciers in de aanbieding parti-
ciperen.
O110 Onderhoud: domeinkennis
Beschrijf hoe Contractant invulling geeft aan het garanderen van Onderhoud en toekomstige
(door)ontwikkeling van de 3D-Suite, zodanig dat dit “meegroeit” met alle ontwikkelingen op het
gebied van de betreffende wet- en regelgeving (zie o.a. E11), incl. geleverde content.
Geef daarbij aan welke activiteiten daartoe door welke partij(en) - Hoofdaannemer en/of kennis-
partner(s) zoals Onderaannemer(s) en/of Toeleverancier(s) - worden ondernomen, incl. de wijze
waarop wet- en regelgeving en andere relevante ontwikkelingen m.b.t. het sociale domein “ge-
monitord” worden en door wie en hoe deze domeinkennis binnen de betreffende organisatie(s)
geborgd is.
Indien er sprake is van één of meer van dergelijke (kennis)partners: beschrijf op welke wijze de
bestendigheid van de relatie met deze partij(en) is geborgd - met name in het kader van het On-
derhoud m.b.t. wet- en regelgeving - zowel in juridische als in commerciële zin. Beschrijf in dat
geval tevens op welke wijze van de relatie met deze partij(en) is geborgd in functionele en techni-
sche zin (t.a.v. de “interoperabiliteit” van de software van elk van de betreffende partijen, incl. ).
Indien één of meer van de applicatie(module)s, add-ons, (configuratie)tools, etc. van de 3D-Suite
open source zijn: beschrijf - indien van toepassing - welke commerciële partij(en) betrokken is /
zijn bij (door)ontwikkeling, Onderhoud en Ondersteuning daarvan. Ga daarbij tevens in op de wij-
146
ze waarop de “regie” daarop geregeld is en hoe de continuïteit van de betreffende software gega-
randeerd is.
10.5 Ondersteuning
G36 Ondersteuning: kennisbank
G36.1
Voor de Ondersteuning van functioneel (applicatie)beheerders bij Gemeente stelt Contractant een
online kennisbank beschikbaar met veelgestelde vragen (FAQ‟s).
G36.2
De antwoorden op vragen die meer dan één keer gesteld zijn bij de Helpdesk (door Gemeeen/nte
of andere klanten), worden door Contractant in deze kennisbank opgenomen.
G36.3
Wanneer een vraag vervolgens nog steeds gesteld wordt bij de Helpdesk, worden de betreffende
antwoordtekst en de bijbehorende zoekingangen verbeterd.
G36.4
In de kennisbank zijn ook “work-arounds” voor bekende problemen met de 3D-Suiteopgenomen,
alsook de wijzigingen (releases en andere vormen) die beschikbaar zijn om deze problemen te
verhelpen.
G36.5
Bovendien worden in deze kennisbank “tips & trucs” in bijgehouden - op basis van ervaringen van
gebruikers - en biedt deze kennisbank op gestructureerde wijze toegang tot de Documentatie en
instructiemateriaal.
10.6 Escrow
E29 Escrow
Escrow omvat het bij dezelfde partij als de 3D-Suite in depot geven en actueel houden (ten min-
ste voor elke major release) van alle Code en Documentatie van de 3D-Suite van Contractant en
eventuele Onderaannemers, met het oog op de nakoming van de verplichtingen op grond van de
Overeenkomst (zoals Onderhoud). Dit teneinde de continuïteit van de Gemeentelijke Dienstverle-
ning te garanderen ook in het geval van bijvoorbeeld een faillissement.
Contractant draagt de verantwoordelijkheid dat alle Code van de 3D-Suite, incl. eventuele aan-
vullende software die daartoe benodigd is, o.b.v. gedeponeerde gedetailleerde instructies van
Contractant één maal per jaar wordt gecompileerd en geverifieerd door voornoemde partij (op
een locatie van deze partij), waarbij alle bevindingen en resultaten van de compilatie en verifica-
tie aan Gemeente worden gerapporteerd. Contractant is verantwoordelijk voor een positief resul-
taat van de compilatie en verificatie.
Voordat de compilatie- en verificatieprocedure begint, wordt er gecontroleerd of alle Code en an-
dere materialen (incl. Documentatie) in het depot aanwezig zijn. T.b.v. van de compilatie en veri-
ficatie wordt vervolgens alle benodigde Systeemsoftware geïnstalleerd en worden de gedeponeer-
de materialen, incl. eventuele aanvullende software die daartoe benodigd is, gecompileerd op ba-
sis van de gedeponeerde gedetailleerde instructies. Voor onderdelen van de 3D-Suite die geleverd
worden door Toeleveranciers, waarvan de Code dus niet bij voornoemde partij gedeponeerd is,
verschaft Contractant zo nodig de betreffende software incl. Licenties voor de duur van de compi-
latie- en verificatieprocedure. Het behoort in dit kader bovendien nadrukkelijk tot de verantwoor-
147
delijkheden van Contractant dat eventuele Toeleveranciers, met het oog op continuïteit, de Code
van hun software gedeponeerd hebben bij een onafhankelijke partij.
Code omvat alle broncode van de 3D-Suitevan Contractant en eventuele Onderaannemers, bij-
voorbeeld geschreven in een programmeer- of scripttaal, incl. beschrijvingen/documentatie van
de benodigde inrichting (van gegevens, processen, logica en dergelijke) waaronder de inrichting
van RDBMS‟en, inclusief alle benodigde leesbare en binaire bestanden (met inbegrip van afbeel-
dingen). Daarnaast omvat Code alle tools en scripts (incl. beschrijvingen/documentatie hiervan)
die nodig zijn om deze broncode te onderhouden en te executeren.
148
11 PvE: Eenmalige dienstverlening
11.1 Inleiding
Dit hoofdstuk bevat wensen en eisen t.a.v. de eenmalige dienstverlening m.b.t. (de implementatie
van) de 3D-suite. Hierbij wordt een indeling gehanteerd naar de verschillende aspecten
dienaangaande.
NB: Zoals uiteengezet in de inleiding van dit document is het onderhavige Programma van Eisen
geen volledig bestek voor de verwerving van een 3D-Suite, dat bevat immers onder meer een
gedetailleerde beschrijving van (de scope van) de aan te besteden opdracht omvat. In een
dergelijke opdrachtomschrijving dienen begrippen als (de verschillende onderdelen van de)
implementatie, migratie, etc. nader gedefinieerd te worden, al naar gelang de specifieke
voorkeuren dienaangaande van de betreffende Gemeente.
Ook kan de gemeente desgewenst een fasering / plateauplaning eisen / vragen, zie ook hoofdstuk
3.
11.2 Algemeen
E30 Algemeen: Nederlandstalig
Alle aan Contractant (incl. eventuele Onderaannemers) gerelateerde personen, die betrokken zijn
bij contacten met Gemeente (zoals projectmanagers, projectleiders, functionele / technische ont-
werpers, functionele / technische architecten, docenten, etc.), spreken en schrijven Nederlands op
ten minste taalniveau B1.
E31 Algemeen: vervanging van Personeel
Terzake van de uitvoering van de Overeenkomst wordt door Contractant (incl. eventuele Onder-
aannemers) steeds het in het Projectplan genoemde Personeel ingezet. Behoudens uitdiensttre-
ding of langdurige ziekte van het genoemde Personeel, kan vervanging van het genoemde Perso-
neel op initiatief van Contractant slechts bij hoge uitzondering plaatsvinden.
Bij vervanging op initiatief van Contractant (incl. uitdiensttreding, excl. langdurige ziekte) van een
personeelslid dat korter dan één (1) jaar werkzaamheden in het kader van de Overeenkomst
heeft verricht, verbeurt Contractant een Boete van ###. Heeft het betreffende personeelslid tus-
sen de één (1) en twee (2) jaar werkzaamheden in het kader van de Overeenkomst verricht, dan
verbeurt Contractant een Boete van ###.
E32 Algemeen: continuïteit maatwerk
Eventueel Generiek Maatwerk dient - zonder extra kosten - opgenomen te worden in de 3D-Suite
en dient als zodanig blijvend te worden ondersteund in alle volgende Nieuwe en Verbeterde Ver-
sies - waaronder (major- en minor)releases - van (de betreffende onderdelen van) de 3D-Suite.
Hiermee wordt al het eventuele Generiek Maatwerk derhalve beschouwd als “nog niet ontwikkelde
standaardfunctionaliteit” van de 3D-Suite.
11.3 Implementatie
In deze paragraaf worden t.z.t. de eventuele eisen en/of wensen opgenomen rond de
implementatiefasering, een grove implementatiebeschrijving, en met name ook acceptatie, etc.
Omdat dit sterk afhangt van de specifieke situatie van de betreffende gemeente(n), kan e.e.a. pas
149
ingevuld worden op het moment dat het daadwerkelijke bestek ten
behoeve van de aanbesteding voor een gemeente of groep van gemeenten wordt opgesteld.
11.4 Migratie
In deze paragraaf worden t.z.t. de eventuele eisen en/of wensen opgenomen voor de eventuele
migratie van gegevens uit de huidige syste(e)m(en) van Gemeente en misschien zelfs van
bestaande ketenpartners naar de 3D-Suite. Omdat dit sterk afhangt van de specifieke situatie van
de betreffende gemeente(n), kan e.e.a. pas ingevuld worden op het moment dat het
daadwerkelijke bestek ten behoeve van de aanbesteding voor een gemeente of groep van
gemeenten wordt opgesteld.
11.5 Concept Plan van Aanpak
In deze paragraaf worden t.z.t. de eventuele eisen en/of wensen opgenomen voor het PvA, incl.
eventuele deelplannen en fasering, incl. wat van gemeente en van ketenpartners wordt verwacht.
Een generiek plan van aanpak is o.i. weinig zinvol (dan volgt enkel een standaardmethodiek), dus
zal vooral gevraagd worden naar de specifieke problemen en de gewenste situatie en fasering.
Omdat dit sterk afhangt van de specifieke situatie van de betreffende gemeente(n), kan e.e.a. pas
ingevuld worden op het moment dat het daadwerkelijke bestek ten behoeve van de aanbesteding
voor een gemeente of groep van gemeenten wordt opgesteld.
150
12 Bijlagen
12.1 Zaakgericht werken
Veel Gemeenten hebben tegenwoordig het zaakgericht werken als uitgangspunt bij de inrichting
van haar dienstverlening en van andere processen. Een zaaksysteem omvat - naast de
kernfunctionaliteiten rondom het registreren, beheren, bewaken en volgen van zaken - ook
functionaliteiten voor de daadwerkelijke behandeling daarvan. Hiertoe beschikt het zaaksysteem
over verschillende gebruikersinterfaces zoals een werklijst (zaakbak/werkvoorraad, doorgaans
samen met een KCS-achtige interface met zoekfunctionaliteit en dergelijke geaggregeerd tot een
soort medewerkersportaal), behandelschermen, etc.
In een zaaksysteem worden de verschillende zaaktypen incl. hun specifieke kenmerken (zoals
doorlooptijden en bewaartermijnen) d.m.v. zogeheten Zero Coding geconfigureerd en opgeslagen
in een soort centrale „bibliotheek‟, de Zaaktypencatalogus, bij voorkeur o.b.v. KING ZTC 2.0. Zie
daartoe www.kinggemeenten.nl/ztc/ztc-20
Die ZTC 2.0 speelt een centrale rol binnen het zaaksysteem. Hierin worden alle zaaktypen
geconfigureerd zonder dat daarbij handelingen verricht hoeven te worden die kennis van
programmeer-/scripttalen, flowcharting, scherm-/formulierontwerp, etc. vereisen (Zero Coding).
Doel hiervan is dat gemeenten zelf in korte tijd additionele zaaktypen kunnen configureren, zowel
voor externe als voor interne processen. Een specifieke zaaktypeconfiguratie in de ZTC 2.0
definieert onder meer de volgende aspecten:
- Zaaktype (omschrijving, versie, norm- en streefdoorlooptijden, bewaartermijn, etc).
- Statussen (incl. doorlooptijden, statusberichten, etc. per status).
- Autorisaties (rollen en rechten).
- (Behandel)schermen incl. checklist, per status en resultaattype.
- Al dan niet verplichte documenttypen en zaakattributen, per zaaktype en per status.
- Mogelijke deel- en vervolgzaaktypen, resultaat- en besluittypen, etc.
Bij complexere zaaktypen waarvoor het relatief eenvoudige „Dordtse model‟ - met een beperkt
aantal seriële statussen - niet toereikend is, is bovendien behoefte aan ondersteuning met
geavanceerde processturing binnen het zaaksysteem. Bijvoorbeeld met workflowmanagement of
soortgelijke functionaliteit zoals een geavanceerde hiërarchie van (hoofd- en deel)zaken. Dit geldt
bijvoorbeeld voor complexe processen als de omgevingsvergunning (WABO) en bestuurlijke
besluitvorming.
Belangrijk i.h.k.v. de 3D-Suite is dat dit niet betekent dat een zaak(type) een specifiek aantal
stappen / taken, of een starre volgorde daarbij dicteert. Binnen een beperkt aantal hoofdstatussen
kan een regisseur ad-hoc, runtime, voor een specifieke zaak aanvullende deelzaken toevoegen,
bijvoorbeeld een deelzaak per doel of taak van een uitvoeringsinstantie.
Steeds speelt zero coding een belangrijke rol, bij voorkeur op basis van de ZTC 2.0. Een tweede
belangrijk concept is overerving: wanneer informatie is vastgelegd voor de hoofdzaak, dan kan de
informatie worden overgeërfd door de deelzaken en vervolgens alle taken en documenten
daarbinnen.
Ook kan voor complexere zaaktypen kan - in aanvulling op zero coding van eenvoudige, seriële
(„Dordtse‟) processen via de ZTC 2.0 - zo nodig voorlopig nog een eigen, gebruikersvriendelijke
(d.w.z. grafische) ontwerpomgeving gebruikt worden. Op termijn dient deze functionaliteit echter
151
zoveel mogelijk geïntegreerd te worden met de ZTC 2.0. Ook als er voor
processturing workflowmanagement of soortgelijke functionaliteit gebruikt wordt, worden alle
overige aspecten van de zaaktypeconfiguratie (zoals zaakattributen, checklists, documenttypen,
etc.) bij voorkeur door middel van zero coding via de ZTC 2.0 geconfigureerd.
De bijbehorende documenten worden als één zaakdossier opgeslagen, ontsloten en t.z.t.
gearchiveerd of vernietigd. Dit kan gebeuren in de 3D-Suite zelf, of in een 3P DMS/RMA- of
zaaksysteem.
Overige (gestructureerde) „zaakgerelateerde‟ gegevens worden opgeslagen in het zakenmagazijn,
rechtstreeks of als een verwijzing naar (basis)gegevens in het gegevensmagazijn (zie verderop).
Het zakenmagazijn dient hiertoe te worden ingericht conform het RGBZ. Binnen het zaaksysteem
kan gewerkt worden met zaak- en andere relevante informatie in een geografische context
(kaartjes).
12.2 Overzicht gegevens in Digitaal Klantdossier / Suwinet
In de Suwiketen is de GeVS (Gezamenlijke elektronische Voorzieningen Suwi) ontwikkeld Via dit
knooppunt is informatie uit verschillende bronnen (zoals GBA, UWV, DUO, RDW, Kadaster)
ontsloten en wordt deze informatie beschikbaar gesteld aan de Suwiketenpartijen (SVB, UWV en
gemeenten). Met behulp van deze gegevens wordt het DKD (het DigitaalKlantDossier) gevormd en
via een webapplicatie getoond. Het DKD zelf is geen bron maar een virtueel dossier dat uit de
aangesloten bronnen wordt opgebouwd. Geautoriseerde afnemers kunnen ook rechtstreeks
aansluiten op de GeVS (via de component Suwinet-Inlezen) om de brongegevens zelf in „eigen‟
applicatie te verwerken.
Momenteel is o.a. de volgende informatie over personen aanwezig:
GBA-gegevens
- Actuele persoonsgegevens
- Actuele en historische adresgegevens
- Huwelijk / geregistreerde partnerschap
- Actuele persoonsgegevens ouder(s)
- Actuele persoonsgegevens kind(eren)
- Gezagsverhouding
- Actuele persoonsgegevens inwonenden (adresvraag)
UWV Polisadministratie
Actuele inkomsten- en uitkeringsgegevens / dienstverbanden
- Datum aanvang inkomstenverhouding
- Bruto/fiscaal inkomen
- Naam werkgever / uitkeringsinstantie
(Dit betreft niet inkomsten uit alimentatie, niet-fiscale inkomsten of inkomsten uit zelfstandige
werkzaamheden
Sociale verzekeringsbank
- Recht op kinderbijslag waaronder de indicatie uit- thuiswonend
- Recht en hoogte ANW
152
- Recht en hoogte waaronder indicatie toeslag AOW en percentage AOW
- Recht en hoogte AIO
UWV en re-integratie
- Recht en hoogte WAO
- Recht en hoogte WIA
- Recht en hoogte Wajong
- Recht en hoogte WAZ
- Recht en hoogte ZW
- Recht en hoogte WW
- Recht en hoogte TW
- Maatregelen en kortingspercentage op uitkeringen
- Gegevens met betrekking tot re-integratie (zowel vanuit UWV als vanuit gemeentelijke re-
integratieapplicatie)
- Inschrijving als werkzoekenden (datums)
Gemeentelijke Sociale Diensten
- Recht en hoogte WWB
- Recht en hoogte Ioaw
- Recht en hoogte Ioaz
- Recht en hoogte bijzondere bijstand
- Recht en hoogte Langdurigheidstoeslag
- Opgelegde maatregelen
- (Terug)vorderingen
Rijksdienst voor het Wegverkeer (Actuele voertuigen- en caravanbezit)
- Motorvoertuigen (soort, type, merk, kenteken en datum eerste inschrijving)
- Verzekeringsgegevens verzekering voertuig
- Aanhangwagens (soort, type, merk) waaronder caravans
Handelsregister
- Bedrijfs- en vestigingsgegevens
- Eigenaren
- Rechtspersonen
Dienst uitvoering onderwijs
DUO verstrekt gegevens met betrekking tot studiefinanciering WSF en WTOS.
- Informatie over studiefinanciering inclusief de indicatie thuiswonend/uitwonend
- Indicatie aanvullende studiefinanciering (bedrag)
- Indicatie lening (bedrag)
- Gegevens met betrekking tot opleiding en diploma‟s
Kadaster
- Informatie over het kadastraal object waaronder type, locatie, toestand, datum aankoop, be-
drag koopsom, eigenaren en de wijze van verkrijging.
153
De GeVS (Gezamenlijke elektronische voorzieningen Suwi) waar het DKD
gebruik van maakt, is bijv. v.w.b. GBA-gegevens gekoppeld aan de GBA-V. Op basis van een
persoonsvraag of adresvraag worden gegevens geleverd. Het agentschap BPR (bronhouder) heeft
op basis van de Suwitaken bepaald welke gegevens geleverd mogen worden. Dit zijn gegevens
zoals persoonsgegevens ingeschrevene, kinderen, ouders en voorgaande adressen. Ook “onder
curatelestelling” is beschikbaar. De brongegevens die via de GeVS worden opgevraagd worden
door de GeVS eerst vertaald naar een SuwiML-bericht.
De gegevens kunnen worden ingezien via Suwinet-inkijk, de webapplicatie voor het DKD of kan via
een gemeentelijke applicatie worden opgevraagd, dan wordt het bericht via Suwinet-inlezen
doorgestuurd naar de gemeente c.q. de 3D-Suite. Alle berichten die worden ontvangen van externe
bronhouders worden altijd vertaald naar een SuwiML bericht alvorens het aan de afnemer
beschikbaar gesteld wordt (hetzij via Suwinet-Inkijk, hetzij via Suwinet-Inlezen.
- www.bkwi.nl/producten/suwinet-services geeft een overzicht van de services die Suwinet biedt
waar primair Suwinet-Inlezen relevant zal zijn.
- www.bkwi.nl/producten/suwinet/suwinet-inlezen/matrices geeft een overzicht van wie momen-
teel toegang zou kunnen hebben tot welke gegevens.
- www.bkwi.nl/producten/suwinet/suwinet-standaarden/suwi-gegevens-register-sgr/sgr-suwiml
geeft een beschrijving van het Suwi Gegevensregister en van SuwiML.
12.3 Voorbeeldinrichting
Onderstaand volgt een voorbeeld van de gegevens die bij het gebruik van de 3D-Suite moeten
worden geregistreerd.
12.3.1 Functionele informatie-eenheden
Aanmelding
Aanmelding is het resultaat van de aanmeldingsfunctie. Een aanmelding kan op verschillende
manieren worden gebruikt, afhankelijk van wie de aanmeldingsfunctie uitvoert en afhankelijk van
het moment in het traject waarop de aanmelding plaatsvindt. Zo is er de melding van burger zelf.
Maar ook bijvoorbeeld een familielid of instantie (bijv. verslavingszorg) kan een cliënt aanmelden.
In al deze gevallen is sprake van een aanmelding, waarin de volgende informatie-elementen
voorkomen:
- Datum: de datum waarop de aanmelding wordt gedaan, de aanmeldingsdatum.
- Cliënt: de cliënt die aangemeld wordt.
- Aanmelder: de partij (instantie of persoon) die de aanmelding doet. Dit kan ook de cliënt zelf
zijn.
- Hoedanigheid Aanmelder: Aanduiding van de aard van de aanmelder, instantie, ouder, cliënt
zelf of politie.
- Ontvanger: de instantie waarbij aangemeld wordt, die dus moet handelen op de aanmelding.
- Verzoek: een indicatie van de soort handeling die de ontvanger van de aanmelding geacht
wordt te ondernemen d.m.v. een verwijzing naar een functie, bijv. Intake, Onderzoek, etc.
- Toelichting: korte beschrijving van het gesignaleerde probleem of de gerezen zorgen ter moti-
vatie van de aanmelding.
- Bijlagen: zo nodig kunnen additionele documenten als bijlage toegevoegd worden.
154
Intakeverslag
Intakeverslag is het resultaat van de intakefunctie. Dit verslag documenteert de bevindingen van
de intake. In veel gevallen wordt deze informatie-eenheid gecombineerd met een besluit over de te
nemen vervolgstappen.
De volgende informatie-elementen komen voor in het Intakeverslag.
- Datum: de datum waarop het Intakeverslag is samengesteld.
- Cliënt: de cliënt ten behoeve van wie de intake gedaan is.
- Intaker: een combinatie van instantie en persoon, die de intake heeft gedaan.
- Bevindingen: een document met daarin de uitkomsten van de intake.
- Bijlagen: zo nodig kunnen additionele documenten als bijlage toegevoegd worden.
Onderzoeksverslag
Een Onderzoeksverslag is het resultaat van de functie Onderzoek. Het Onderzoeksverslag
documenteert de conclusies van het Onderzoek, waarin beschreven wordt wat er precies aan de
hand is met een cliënt of binnen een klantsysteem. Is er een probleem, wat is dat probleem,
waardoor wordt het veroorzaakt of in stand gehouden en in hoeverre kan de cliënt op eigen kracht
verbetering bereiken in de situatie? Het Onderzoeksverslag voorziet in het zogenaamde integrale
„klantbeeld‟, een overzicht van wat er binnen het zorg- en welzijnsdomein bekend is over de cliënt.
De inhoud van het klantbeeld wordt niet gestandaardiseerd, maar het ligt voor de hand om dit, in
het kader van multi-problematiek voor zorg en welzijn, vorm te geven aan de hand van
leefdomeinen (bijv. Wonen, Werken, Onderwijs/scholing, Financiën/schulden, etc.). Het
Onderzoeksverslag bestaat uit een stuk vrije tekst waarin het onderzoeksresultaat kort wordt
samengevat, het klantbeeld en eventuele bijlagen (vragenlijsten, inventarisaties, specialistische
diagnoses, etc.) ter ondersteuning van die conclusie.
De volgende informatie-elementen komen voor in het Onderzoeksverslag.
- Datum: de datum waarop het Onderzoeksverslag is samengesteld.
- Cliënt: de cliënt ten behoeve van wie het onderzoek gedaan is.
- Onderzoeker: een combinatie van instantie en persoon, die het onderzoek heeft gedaan.
- Bevindingen: een document met daarin de uitkomsten van het onderzoek.
- Klantbeeld: een overzicht en samenvatting van wat er binnen het zorg- en welzijnsdomein be-
kend is over de cliënt.
- Bijlagen: zo nodig kunnen additionele documenten als bijlage toegevoegd worden.
Doelen
Doelen zijn het resultaat van de Doelstelling-functie. Daarin worden de doelen geformuleerd die
gesteld worden in een traject. Doelen moeten zowel met vrije tekst als volgens een
gestandaardiseerde doelenclassificatie gespecificeerd kunnen worden. De volgende informatie-
elementen komen daarin voor.
- Datum: de datum waarop de doelen zijn opgesteld.
- Cliënt: de cliënt op wie de doelen betrekking hebben.
- Doelsteller: een combinatie van instantie en persoon, die de doelen heeft opgesteld.
- Doelen: een of meer doelen ten aanzien van de te leveren ondersteuning.
155
Ondersteuningsarrangement
Het Ondersteuningsarrangement is het resultaat van de Maatregel-selectie-functie. Het
Ondersteuningsarrangement identificeert de ondersteuningsmaatregels die voor een cliënt
geselecteerd zijn, bijv. uitkering verstrekken, schuldhulpverlening en leefstijltraining.
De volgende informatie-elementen komen voor in het Ondersteuningsarrangement.
- Datum: de datum waarop deze informatie-eenheid samengesteld is.
- Cliënt: de cliënt die de beoogd ontvanger van het ondersteuningsarrangement is.
- Samensteller: een combinatie van instantie en persoon, die het ondersteuningsarrangement
samenstelt.
- Arrangement: één of meer geselecteerde ondersteuningsmaatregelen voor de cliënt.
Ondersteuningsplan
Het Ondersteuningsplan is het resultaat van de Planning-functie. Het Ondersteuningsplan bevat het
plan om de daadwerkelijke ondersteuning aan de cliënt te leveren.
De volgende informatie-elementen komen voor in het Ondersteuningsarrangement.
- Datum: de datum waarop het ondersteuningsplan is opgesteld.
- Cliënt: de cliënt waarop het ondersteuningsplan betrekking heeft.
- Opsteller: de combinatie van persoon en instantie die het ondersteuningsplan heeft opgesteld.
- Plan: een document waarin het plan beschreven staat.
- Instemming Cliënt: een indicatie of de cliënt met het plan heeft ingestemd en zo nodig de re-
actie van de cliënt op het plan.
Voortgangsrapportage
De Voortgangsrapportage is een uitkomst van de Ondersteuning-functie. De Voortgangsrapportage
wordt gebruikt om te rapporteren over de verleende ondersteuning in een ondersteuningstraject
traject.
De volgende informatie-elementen komen voor in de Voortgangsrapportage.
- Datum: de datum waarop de Voortgangsrapportage samengesteld is.
- Cliënt: de cliënt waarop de verleende ondersteuning betrekking heeft. Dit hoeft niet altijd de
daadwerkelijke ontvanger van de ondersteuning zijn. Bijvoorbeeld, de cliënt kan een kind zijn,
maar de verleende ondersteuning kan op de ouders ervan zijn gericht (bv. opvoedingsonder-
steuning). De ouders worden in dat geval opgenomen als „Ondersteuningontvangers‟.
- Ondersteuningontvangers: De pers(o)on(en) die de daadwerkelijke ondersteuning ont-
vang(t/en), indien anders dan de cliënt. Bijv. een ouder, broer of het hele gezin.
- Ondersteuner: de combinatie van de instantie en de (contact)persoon die de ondersteuning
heeft geleverd.
- Ondersteuningstraject: informatie over het geleverde ondersteuningstraject, zoals startda-
tum, einddatum en eventuele classificatie.
Evaluatieverslag
Het Evaluatieverslag is het resultaat van de Evaluatie-functie. Dit rapport documenteert de
inhoudelijke evaluatie van de uitkomsten van een ondersteuningstraject.
De volgende informatie-elementen komen voor in het Evaluatieverslag.
- Datum: de datum waarop het ondersteuningstraject is geëvalueerd, de evaluatiedatum.
- Traject: het traject waarop de evaluatie betrekking heeft.
156
- Evaluator: degene die de evaluatie met de cliënt heeft gedaan.
- Doelrealisatie: een indicatie van de mate waarin de doelen van het traject zijn behaald.
- Bijlagen: het evaluatieverslag zelf en eventuele andere lijsten en documenten.
Besluit
Een besluit is het resultaat van de secundaire functie Besluitvorming. Hierin kunnen zowel formele
(bijvoorbeeld gerechtelijke uitspraken in het kader van schulden) als informele besluiten worden
opgenomen. Er wordt rekening gehouden met eventuele toestemming die nodig zijn (bv.
toestemming van ouders indien het ondersteuningstraject een jongere betreft). Ook is er ruimte
voor beroep en bezwaar tegen een besluit. De volgende informatie-elementen komen voor in een
Besluit:
- Datum: de datum waarop dit besluit genomen is.
- Nummer: besluitnummer of een andere vorm van identificatie voor het genomen besluit.
- Soort: een indicatie van de (juridische) status van een besluit Bijvoorbeeld een indicatiebesluit,
gerechtelijk besluit (bijv. tot opleggen maatregel), een verwijzingsbesluit, etc.
- Uitspraken: een of meer bij dit besluit horende uitspraken waarin adviezen, rechten en plich-
ten worden afgegeven.
- Autoriteit: de instantie onder wiens verantwoordelijkheid het besluit is genomen. De personen
die het besluit genomen hebben, worden opgenomen onder toestemmingen.
- Ingangsdatum: de datum waarop het besluit en de daaruit voortvloeiende rechten en plichten
van kracht worden. Dit kan opengelaten worden indien dit nog niet bekend is.
- Toestemmingen: de verzameling van expliciete accorderingen voor het besluit.
- Bezwaren: de verzameling van expliciete bezwaren tegen het besluit.
- Status: de huidige status van het besluit. Is het voorgenomen, voorlopig, definitief, in behan-
deling?
12.3.2 Generieke informatie-elementen
In de specificatie van de functionele informatie-eenheden wordt gebruik gemaakt van meer
elementaire informatie-elementen. Hier specificeren we een aantal van de meer generieke
informatie-elementen nader. Dit zijn informatie-elementen die in meer dan een functionele
informatie-eenheid gebruikt worden. Het zijn de woorden of begrippen waaruit de functionele
informatie-eenheden zijn opgebouwd. Zij vormen het vocabulaire van de 3D-Suite.
Traject
Het idee achter deze schets van de 3D-Suite is dat er rondom een cliënt diverse
ondersteuningstrajecten kunnen lopen (mogelijk bij verschillende instellingen), en dat relevante
informatie over deze ondersteuningstrajecten kan worden uitgewisseld. Figuur 11 illustreert hoe,
op basis van trajecten, een regievoerder een overzicht kan krijgen over lopende
ondersteuningstrajecten bij diverse ondersteuners op basis van informatieuitwisseling.
Ondersteuningstrajecten kunnen elkaar daarbij overlappen in de tijd, en er kunnen meerdere
ondersteuningstrajecten binnen een klanttraject worden uitgevoerd.
157
Figuur 11 Illustratie van informatieuitwisseling tussen trajecten
Binnen ieder traject vinden de eerder genoemde primaire functies plaats, ondersteund door de
secundaire functies (zie par. 5.1.2). Een Traject bevat de volgende eigenschappen:
- Identificatie: een code aan de hand waarvan het traject geïdentificeerd kan worden.
- Soort: een indicatie van het soort traject volgens een gestandaardiseerde classificatie, bijv.
AWBZ-traject, Schuldsaneringtraject, Verslavingsbehandeling, Jeugdzorgtraject. Het soort tra-
ject wordt nader gespecificeerd door de doelen en componenten hieronder.
- Cliënt: de cliënt waar het traject over gaat.
- Verantwoordelijke: diegene (persoon en instantie) die verantwoordelijk is voor het beheer en
uitvoering van (dit deel van) het traject, bijv. een wijkcoach of case-manager.
- Periode: de periode waarin het traject actief is (geweest). Combinatie van start- en einddatum.
- Doelen: de op dit traject van toepassing zijnde doelen.
- Ondersteuningsarrangement: indien van toepassing, het voor dit traject geselecteerde On-
dersteuningsarrangement.
- Reden Beëindiging: optioneel een indicatie van de reden waarom het traject beëindigd is.
- Bovenliggend Traject: verwijzing naar bovenliggend traject, d.w.z. het traject waar dit traject
onderdeel van is, indien bekend.
- Deeltrajecten: verwijzing naar deeltrajecten van dit traject, indien bekend.
- Besluiten: de op dit traject van toepassing zijnde besluiten.
- Dossier: de verzameling van gegevens en besluiten die zijn vastgesteld tijdens dit traject, be-
staande uit documenten en uitgewisselde berichten. Trajecten kunnen verwijzen naar bovenlig-
gende of deeltrajecten, die op hun beurt ook weer een Dossier kunnen bevatten. Het is een im-
plementatiekeuze of hierin alleen documenten worden opgenomen die bij het gegeven traject
horen, of dat hierin ook documenten uit andere trajecten gedupliceerd mogen worden.
Gezin
Een Gezin bestaat uit Personen die wel of niet Cliënt zijn (zie hierna).
Cliënt
Een Cliënt is een Persoon (zie hierna), eventueel voorzien van een klantnummer of -kenmerk.
Ondersteuningstraject A.1 Ondersteuningstraject A.2
Ondersteuningstraject B.1
Ondersteuner A(bijv. Stadsbank)
Ondersteuner B(bijv. Tactus:
verslavingszorg)
Clienttraject
Info-
uitwisseling
Regievoerder
tijd
158
Persoon
Een Persoon is een individu, bijvoorbeeld een cliënt, een ondersteuner die werkzaam is bij een
instantie, of een familielid van de cliënt.
Een Persoon bezit de volgende eigenschappen.
- Identificatie: Een of meer (bij voorkeur meer) identificatiecodes voor de persoon. Denk aan
BSN, of een ander identificatienummer.
- Naam: alle naamsgerelateerde informatie van de persoon, zoals voornamen, achternaam, ini-
tialen, etc.
- Adres: een of meerdere bekende adressen van de persoon, zoals GBA-adres, verblijfsadres.
- Contactgegevens: telefoonnummers, e-mail adressen, etc.
- Geboorte: de geboortegegevens van de persoon, d.w.z. datum, plaats, geslacht, etc.
- Overlijden: eventueel de datum en plaats van overlijden.
- Nationaliteit: de nationaliteit van de persoon.
- Herkomst: een indicatie of de persoon autochtoon of allochtoon is.
- Verblijfsstatus: indicatie of de persoon legaal of illegaal in Nederland verblijft.
- Relaties: relaties die de persoon heeft met andere personen, bijv. familieleden. Hiermee kan
bijvoorbeeld het netwerk van een cliënt beschreven worden.
Niet alle eigenschappen zijn voor iedere persoon noodzakelijk.
Persoonsrelatie
Een Persoonsrelatie is een relatie die een persoon heeft met andere personen, bijv. familieleden.
Een Persoonsrelatie bevat de volgende eigenschappen:
- Soort Relatie: een code die aangeeft welke rol de gerelateerde persoon heeft. Bijv. vader,
moeder, voogd, partner, kennis.
- Vanaf Datum: datum vanaf wanneer de relatie bestaat.
- Tot en met Datum: datum tot wanneer de relatie bestond.
- Gerelateerde Persoon: de persoon met wie de relatie bestaat of bestond.
Instantie
Een Instantie is een instelling die een rol vervult in de ondersteuning. Voorbeelden zijn een
instelling die gespecialiseerd is in verslavingszorg (bijv. Tactus), een instelling die mensen helpt
financieel zelfredzaam te zijn (bv. Stadsbank), of een instelling die gespecialiseerd is in verpleging
en thuiszorg (bv. Livio). Vaak is het van belang om ook onderdelen, vestigingen of locaties van
instellingen te identificeren. Daarom biedt het informatiemodel de mogelijkheid om aan te geven of
een instantie onderdeel is van een andere instantie.
Van een instantie kunnen de volgende eigenschappen uitgewisseld worden.
- Identificatie: Code die een instantie of een onderdeel daarvan identificeert.
- Onderdeel van: Aanduiding van welke andere instantie een instantie deel uitmaakt.
- Soort Instantie Code: De aanduiding van de aard van de instantie (bijvoorbeeld een code
voor „thuiszorg‟ of „verslavingszorg‟).
- Naam: de naam van de instantie.
- Adres: het adres van de instantie
- Contactgegevens: telefoonnummers, etc. van de instantie.
159
Doel
Een doel is een beschrijving waarin een doelsteller de beoogde situatie ten aanzien van een cliënt
formuleert. Een doel kan gekoppeld worden aan een leefgebied. Daarmee wordt aangegeven dat
het doel betrekking heeft op een bepaald leefgebied. Een doel bevat de volgende eigenschappen:
- Doelbeschrijving: een beschrijving van het beoogde doel ten aanzien van de inzet van onder-
steuning.
- Doelclassificatie: een indicatie van het soort doel volgens een gegeven classificatie van doelen
(indien aanwezig).
- Leefgebied: een indicatie van het leefgebied, of leefgebieden, waarop het doel betrekking
heeft.
Leefgebied
Een leefgebied is een aanduiding van een probleemgebied waarvoor ondersteuning kan worden
aangeboden. Voorbeelden van de leefgebieden zoals die gehanteerd worden door de Enschedese
wijkzorgteams zijn (op dit moment): Wonen, Werk, Onderwijs/scholing, Financiën/schulden,
Gezondheid/welzijn, Relaties, Recreatie/vrije tijd, Zorg/hulpverlening, Politie/justitie/gedwongen
kader. Een leefgebied bevat de volgende eigenschappen:
- Leefgebiedcode: een unieke code voor het leefgebied volgens een vastgestelde classificatie.
- Leefgebied naam: de naam van het leefgebied, bijvoorbeeld „wonen‟ of „financiën‟
N.B.1: Het PvE schrijft niet voor welke leefgebieden er moeten zijn. Wel dát er leefgebineden zijn.
Bijvoorbeeld o.b.v. de ZRM
N.B.2: Verschillende organisaties kunnen een andere naam hanteren voor het begrip „leefgebied‟
(bijvoorbeeld „categorie‟).
N.B.3: Door leefgebieden te beschrijven aan de hand van een „Leefgebiedcode‟ ontstaat een uit-
breidbaar model – nieuwe, toekomstige, leefgebieden kunnen eenvoudig worden toegevoegd.
Klantbeeld
Het onderzoeksverslag verwijst naar een klantbeeld. Een klantbeeld is het resultaat van de
Onderzoeksfunctie. Een klantbeeld bevat een overzicht en samenvatting van wat er binnen het
zorg- en welzijnsdomein bekend is over de cliënt. Het klantbeeld bevat de volgende
eigenschappen:
- Cliënt: de cliënt waar het klantbeeld betrekking op heeft.
- Klantbeeldgegevens: De beschikbare gegevens van de cliënt, opgedeeld naar leefgebied of
categorie.
Klantbeeldgegeven
Klantbeeldgegevens zijn gegevens die binnen het klantbeeld worden opgenomen. Een
klantbeeldgegeven bevat de volgende eigenschappen:
- Naam: naam van het gegeven, bijvoorbeeld „werkgevershistorie‟
- Waarde: de waarde van het gegeven, bijvoorbeeld een tabel met werkgeverhistorie-informatie.
- Herkomst: de herkomst of bron waaruit het gegeven afkomstig is, bijvoorbeeld UWV
- Leefgebied: Het leefgebied waarbinnen dit gegeven wordt ontsloten, bijvoorbeeld „werk en in-
komen‟.
160
- Betekenis: een eventuele beschrijving waarin de betekenis van het
klantbeeldgegeven wordt toegelicht.
Ondersteuningsmaatregel
Ondersteuningsmaatregelen zijn onderdeel van het geselecteerde ondersteuningsarrangement.
Informatie over een ondersteuningsmaatregel wordt gebruikt om te rapporteren over de verleende,
of te verlenen, ondersteuning. Het informatie-element ondersteuning bevat de volgende
eigenschappen:
- Cliënt: een ondersteuningsmaatregel heeft altijd betrekking op een cliënt. Soms kan het voor-
komen dat de cliënt niet zelf de ontvanger van de ondersteuning is. In dat laatste geval wordt
bij de eigenschap ondersteuningsontvanger de daadwerkelijke ontvanger vermeld.
- Ondersteuningsontvanger: De pers(o)on(en) die de daadwerkelijke ondersteuning ont-
vang(t/en), indien anders dan de cliënt. Bijv. een ouder, broer of het hele gezin.
- Ondersteuner: de combinatie van de instantie en de (contact)persoon die de ondersteuning
heeft levert.
- Ondersteuningstraject: informatie over het te leveren, of geleverde, ondersteuningstraject,
zoals het soort traject, de periode waarin het traject wordt uitgevoerd, de doelen die bij het on-
dersteuningstraject horen, etc. (zie het informatie-element Traject).
161
12.4 Voorbeeld: elementen in een zelfred-zaamheidsmatrix
Onderstaande geeft een voorbeeld van de elementen in de zelfredzaamheidsmatrix, alsook van de
visualisatie van de beoordeling daarop.
Figuur 12 zelfredzaamheidsmatrix
In bovenstaande figuur is in 1 oogopslag te zien dat er bijvoorbeeld een accuut probleem is bij
Dagbesteding maar dit wel is verbeterd. V.w.b. Fysieke gezondheid is de persoon voldoende
zelfredzaam, maar de situatie is verslechterd.
Zie voor meer http://www.zelfredzaamheidmatrix.nl/
162
12.5 Voorbeeld: klantbeeld
Onderstaand formulier beschrijft de informatie-elementen die door wijkcoaches van de gemeente
Enschede worden gebruikt.
Algemene klantinformatie
Clientgegevens
o NAW, geboortedatum, contactgegevens
Gegevens partner
o NAW, geboortedatum, contactgegevens
Gegevens kinderen
o NAW, geboortedatum
Gegevens huisarts
o NAW, contactgegevens
Aanmelder / aanmeldende organisatie
o Contactgegevens
Datum van aanmelding
Reden van aanmelding
Additionele informatie per leefgebied
Informatie per leefgebied
o Wonen
Huursituatie, betalingsachterstanden, overlastproblematiek
o Werk
Werkverleden, uitkeringssitutatie
o Onderwijs/scholing
Opleidingsverleden
o Financiën/schulden
Schuldsituatie, betrokkenheid Stadsbank
o Gezondheid/welzijn
Gezondheidssituatie, betrokkenheid GGZ/Mediant
o Relaties
Netwerkrelaties (familie, vrienden, etc.)
o Recreatie/vrije tijd
Vrijetijdsbesteding, betrokkenheid Alifa, buurtcentra
o Zorg/hulpverlening
Zorgverleden, betrokkenheid huisarts, verslavingszorg, thuisbegeleiding, Jeugd-
zorg, etc.
o Politie/justitie/gedwongen kader
Meldingen bij politie, strafrechtelijk verleden, veiligheidshuis, …
163
12.6 Voorbeeld: hoofdprocessen Awbz, Wmo en Jeugdzorg
De benoemde functies: Aanmelding, Intake, Diagnose, Doelen, Maatregelselectie, Plan van Aanpak,
Ondersteuning, Evaluatie, Nazorg zijn te plaatsen in de Waardeketen in de zorg (CVZ, 2011)
Figuur 13. Waardeketen in de zorg
De hoofdprocessen van WMO, AWBZ en Jeugdzorg zullen niet (wezenlijk) veranderen. De 3D-Suite
zal dan ook deze hoofdprocessen moeten ondersteunen. Er wordt in dit Programma van Eisen niet
gevraagd om een vast, vooraf gedefinieerde procesinrichting en functies. Dat is voor de regisseur
ook niet nodig. Het accent zal vooralsnog liggen op de ondersteuning van de regisseur en niet op
het ondersteunen van de uitvoerder in de levering van de dienst/ het product. Voor die levering
zullen de specifieke backoffice-systemen ingezet blijven worden. Het informatie- c.q.
samenwerkingsplatform zou op termijn wellicht deze systemen deels of geheel kunnen vervangen.
Voor het beoogde platform ter ondersteuning van de regie en samenwerking zijn de genoemde
fasen en functies toereikend.
De overdracht van taken (en verantwoordelijkheid) op het sociale domein naar gemeenten
verandert veel in de wijze waarop die nu georganiseerd zijn. Inhoudelijk (zeker op de hoofdlijnen)
zijn de veranderingen minder ingrijpend. M.a.w. burgers zullen om ondersteuning vragen. Er zal
een intakegesprek en beoordeling plaats vinden, etc, etc. Welke organisatie voert welke
werkzaamheden uit en hoe doet ze dat en welke specifieke werkafspraken (criteria, doorlooptijden,
e.d.) worden gehanteerd? Met deze vragen zijn gemeenten volop bezig. Hierin zullen de
veranderingen liggen.
Als referentie worden hieronder de ketenprocessen van WMO, AWBZ en Jeugdzorg23, zoals die nu
vastgesteld zijn, kort geschetst. Ook de hoofdproces van Centra voor Jeugd en Gezin (CJG)24 is
onderzocht, maar hier verder niet opgenomen. Het bestaat uit vier processen: Informatie & advies,
Monitoring & signalering, Interventies, Verwijzing.
In de huidige ABWZ heeft men recht op zorg. Dus zodra men een indicatie heeft verkregen wordt
er (na toewijzing) geleverd. De extramurale zorg uit de AWBZ wordt overgeheveld naar de
23 De informatie van het ketenproces Awbz en Wmo is afkomstig van CVZ (zorgregistratie.nl), die van het ke-
tenproces Jeugdzorg van ‘Referentiewerkmodel Bureau Jeugdzorg’, vs 2.0, 2005 24 ‘Werkprocessen CJG’, Ieder Kind Wint, 2009
164
gemeenten. En die hanteren het compensatiebeginsel, d.w.z. ze beoordelen
of en zo ja, welke ondersteuning het beste past. Het ketenproces voor de extramurale zorg zal dan
ook verlopen volgens het onderstaand ketenproces WMO.
Figuur 14 Ketenproces AWBZ
Figuur 15 Ketenproces WMO
Figuur 16 Ketenproces jeugdzorg
165
Het ketenproces Jeugdzorg kan als een goede aanvulling gezien worden op
de twee eerder vermelde ketenprocessen. Het reageren op signalen van derde wordt als een
noodzakelijke functionaliteit gezien voor de 3D-Suite. Ook hier zijn (net als bij de Wmo) fasen
ingebouwd die gericht zijn op analyse, beoordeling, vaststellen van de zorg (in een
ondersteuningsplan). De fase „toeleiding‟ (uit Wmo) verdient een aparte plaats. De stappen 4-7 zijn
weliswaar apart vermeld, maar in de toelichting wordt deze fasen als een eenheid beschouwd en
als „casemanagement‟ aangeduid. Bij jeugdzorg is ook sprake van gedwongen trajecten in het
kader van (gezins)voogdij of jeugdreclassering. De start (1-3) heeft een andere invulling (1.
Aanwijzen gezinsvoogdijwerker, voogdijwerker resp. reclasseringswerker. 2. Plannen eerste
contact. 3. Versturen mededeling). Het casemanagement betreft hier de uitvoering van
(gezins)voogdij en jeugdreclassering. Er is een aantal bijzondere situaties met een afwijkende
procesgang (denk aan crisissituaties, bezwaar, e.d.)
Een ander referentiepunt is het Bedrijfsfunctiemodel van het IZO-project25 (Informatievoorziening
Zorg en Ondersteuning). Dit model biedt een grafische weergave en eenduidige definitie van de
bedrijfsfuncties voor de uitvoering van Awbz, Wmo en Zvw.
Figuur 17 Bedrijfsfunctiemodel Informatievoorziening Zorg en Ondersteuning
Het wordt gebruikt voor de realisatie van „Toekomstbeeld IZO 2016‟ en draagt bij aan de doelen:
- Uniformering en stroomlijning van bedrijfsprocessen
- Standaardisatie van proces- en gegevenskoppelingen
- Standaardisatie van gegevenssets en domeinoverstijgend gebruik van authentieke registraties.
De andere taakvelden (Jeugdzorg en Werk en Inkomen) worden helaas niet meegenomen, maar
ook voor die velden is het model relevant. Het model omvat alle primaire bedrijfsfuncties die nodig
zijn voor de volledige ketens voor de uitvoering.
De feitelijke zorgverlening is niet uitgewerkt. Collectieve voorzieningen en informele zorg vallen
buiten de scope vallen. Beide keuzes passen bij de opzet van het beoogde informatieplatform.
25 Presentatie Bedrijfsfunctiemodel Zorg en Ondersteuning, januari 2013. Toekomstbeeld 2016 In-
formatievoorziening Zorg en Ondersteuning, mei 2012
166
12.7 Voorbeeld: online communities en ‘markt-plaatsen’
De laatste jaren dienen zich veel initiatieven aan, die mensen/gezinnen ondersteunen en bij elkaar
brengen. Soms worden deze initiatieven gesteund door de overheid, maar (steeds vaker) nemen
mensen het heft in eigen hand. Een greep uit de voorbeelden:
WeHelpen.nl is opgezet als een marktplaats met slimme functies voor het vinden en
verbinden, organiseren en delen van hulp, aangevuld met gerichte informatie aan
hulpverleners en hulpbehoevenden.
Wikiwijk Tilburg is een internet platform waar u terecht kunt als u op zoek bent naar
informatie, om te communiceren met bekenden of om nieuwe contacten te leggen, om gebruik
te maken van diensten of producten te bestellen. Een handig alles-in-één platform dus, voor
iedereen in Tilburg.
BUUV is de buurtmarktplaats voor en door bewoners van Haarlem, waar vraag en aanbod
elkaar vinden. Bij BUUV gaat het om diensten die je als bewoners voor elkaar kan doen.
Zonder dat er direct iets tegenover staat. Dit kan van alles zijn: koken, gezelschap, het uitlaten
van de hond, een lift naar de dokter, een klusje in huis of hulp in de tuin.
Jeugdcloud. In 2015 heeft elk gezin zijn eigen cloud-omgeving. Je kunt al vanaf het eerste
contact op het consultatiebureau jouw kindgegevens beheren. Dit is het eigen dossier en de
toegangspoort voor alle hulpvragen. Van laagdrempelige opvoedondersteuning tot medische
uitdagingen. Als hulpverlener moet je vragen om toegang. Wanneer meerdere aanbieders hulp
verlenen kunnen ze via de cloud van de burger communiceren. Iets delen met vrienden of
hulpverleners is een kwestie van klikken.
Toegankelijk Enschede, een website die informatie biedt voor gehandicapte burgers over de
toegankelijkheid van publieke ruimten in het centrum.
Zorgsite (Helmond) Zorg je voor iemand, of zorgen andere mensen voor jou? Dan is de
Zorgsite een handig hulpmiddel om de taken te verdelen en iedereen die helpt op de hoogte te
houden van het laatste nieuws. Dat scheelt veel vragen, regelen en bellen en maakt het een
stuk makkelijker om meehelpen te combineren met het eigen gezin en/of werk
167
12.8 Afkortingenlijst
- ANW: Algemene nabestaandenwet
- API: Application programming interface
- ASP: Application service provider (zie ook SaaS)
- AWBZ: Algemene wet bijzondere ziektekosten
- AZR: Awbz-brede zorgregistratie
- BEP-model: Bedrijfsregels, EI-standaarden en processen
- BO: Backoffice
- BPR: Basisadministratie persoonsgegevens en reisdocumenten
- BSN: Burgerservicenummer
- CMS: (Web) content management systeem
- CRUD: Create, read, update, delete
- DBMS: Databasemanagementsysteem
- DJI: Dienst justitiële inrichtingen
- DKD: Digitaal klantdossier (i.h.k.v. de Suwiketen)
- DMS: Document management systeem
- DoS: Denial of Service-aanval
- DUO: Dienst uitvoering onderwijs
- ESB: Enterprise service bus
- FAQ: Frequently asked questions (veelgestelde vragen)
- FO: Frontoffice
- GBA: Gemeentelijke basisadministratie (Basisadministratie persoonsgegevens en reis-
documenten)
- GBA-V: GBA verstrekkingsvoorziening
- GEMMA: Gemeentelijke model architectuur
- GeVS: Gezamenlijke elektronische Voorzieningen Suwi
- HTTPS: Hypertext transfer protocol secure (versleutelde http-verbinding)
- IOAW: Inkomensvoorziening oudere en gedeeltelijk arbeidsongeschikte werkloze werk-
nemers
- IOAZ: Inkomensvoorziening oudere en gedeeltelijk arbeidsongeschikte gewezen zelf-
standigen
- IOW: Inkomensvoorziening voor oudere werklozen
- KCC: Klantcontactcentrum
- KCS: Klantcontactsysteem
- KING: Kwaliteitsinstituut Nederlandse gemeenten
- MO: Midoffice
- OTAPU: Ontwikkel-, test-, acceptatie- en uitwijkomgevingen
- OTC: Objecttypencatalogus
- PDC: Product-dienstencatalogus
- PGB: Persoonsgebonden budget
- PKI: Public key infrastructure
- PvA: Plan van aanpak
- PvE: Programma van eisen
- RDW: Rijksdienst voor het wegverkeer
- RGBZ: Referentiemodel gemeentelijke basisgegevens zaken
- RMA: Records management applicatie
- RSGB: Referentiemodel stelsel van gemeentelijke basisgegevens
- SaaS: Software as a service
- SAN: Storage area network (opslag)
168
- StUF: Standaard uitwisselformaat
- StUF-Zkn: Standaard uitwisselformaat-zaken
- Suwi: Wet structuur uitvoering werk en inkomen
- SVB: Sociale verzekeringsbank
- TAPU: Test-, acceptatie- en uitwijkomgevingen
- TW: Toeslagenwet
- UO: Uitvoeringsorganisatie
- UWV: Uitvoeringsinstituut werknemersverzekeringen
- VAC: Vraag-antwoord combinaties
- VIR: VerwijsIndex risicojongeren
- VNG: Vereniging van Nederlandse gemeenten
- Wajong: Werk en arbeidsondersteuning jonggehandicapten
- WAO: Wet arbeidsongeschiktheid
- WAZ: Wet arbeid en zorg
- WIA: Wet werk en inkomen
- WMO: Wet maatschappelijke ondersteuning
- WSF: Wet op de studiefinanciering
- WTOS: Wet tegemoetkoming onderwijsbijdrage en schoolkosten
- WW: Werkloosheidswet
- WWB: Wet werk en bijstand
- WYSIWYS: What you see is what you sign
- ZgW: Zaakgericht werken
- ZRM: Zelfredzaamheidsmatrix
- ZTC: Zaaktypecatalogus
- ZW: Ziektewet
KWALITEITSINSTITUUT NEDERLANDSE GEMEENTEN NASSAULAAN 12
2514 JS DEN HAAG POSTBUS 30435 2500 GK DEN HAAG T 070 373 80 08 F 070 363 56 82
[email protected] WWW.KINGGEMEENTEN.NL