Omnichannel MijnZaken compleet
Inhoud
Burgers, ondernemers en instellingen die contact hebben met de overheid doen dit via meer interactiekanalen. Denk aan het raadplegen van informatie via een website, mobiele app, online formulieren of een persoonlijk gesprek aan de balie.
Die veelheid aan kanalen heeft voordelen: gericht een bepaald kanaal inzetten voor een bepaalde dienst voor een bepaalde doelgroep. Daarmee wordt het contact effectiever en efficiënter. Tegelijkertijd zijn er uitdagingen. Zo kunnen burgers het gevoel krijgen ‘van het kastje naar de muur te worden gestuurd’ door de complexiteit en diversiteit van kanalen. Met de omnichannel aanpak is dit te voorkomen. Dit document beschrijft de referentiearchitectuur voor MijnZaken en is onderdeel van de referentiearchitectuur Omnichannel. De referentiearchitectuur MijnZaken moet een solide basis vormen om de komende jaren informatievoorzieningen te ontwikkelen en te implementeren die niet alleen bijdragen aan een betere dienstverlening aan burgers, ondernemers en instellingen maar ook ambtenaren zo optimaal mogelijk ondersteunt in die dienstverlening.
De referentiearchitectuur MijnZaken is in samenwerking met een aantal overheidsorganisaties uitgewerkt. De betrokkenheid van andere overheidsorganisaties naast gemeenten is van groot belang. Binnen één organisatie gegevens op gestandaardiseerde wijze delen neemt maar een deel van het ‘kastje naar de muur’-gevoel weg bij een burger. Maar als diezelfde gegevensverstrekking ook tussen verschillende overheidsorganisaties gestandaardiseerd is, ontstaat de mogelijkheid echt als één overheid op te treden. Organisaties kunnen immers (binnen de kaders van de wet- en regelgeving) gegevens van de andere organisatie direct aan de burger tonen, zonder dat de burger daarvoor naar een apart loket of ander kanaal moet worden doorgestuurd. Om dit doel te bereiken willen we deze referentiearchitectuur MijnZaken verder ontwikkelen en beproeven met overheidsorganisaties uit verschillende bestuurslagen.
Inhoud
De referentiearchitectuur MijnZaken is bedoeld voor architecten of informatiemanagers bij overheidsorganisaties die op basis van de referentiearchitectuur een eigen MijnZaken-implementatie willen voorbereiden.
- Hoofdstuk 1 beschrijft in het kort wat MijnZaken inhoudt en wat het oplevert;
- Hoofdstuk 2 beschrijft de Bedrijfsarchitectuur waarin de actoren, rollen en bedrijfsobjecten opgenomen zijn;
- Hoofdstuk 3 beschrijft de Informatiearchitectuur waarin referentiecomponenten in samenhang en in relatie met elkaar worden getoond;
- Hoofdstuk 4 beschrijft de Informatiebeveiliging en Privacy waaraan gedacht moet worden bij het toepassen van de referentiearchitectuur;
- Hoofdstuk 5 beschrijft de principes en kaders waaraan de architectuur en MijnZaken-implementaties moeten voldoen en schetst de context daarbij;
- Hoofdstuk 6 omvat de bijlagen, waarin onder andere de casussen die zijn gebruikt om deze referentiearchitectuur vorm te geven nader zijn beschreven.
De MijnZaken service is één van de services die in samenhang beschreven is in de referentiearchitecuur MijnServices.
Inleiding
Burgers en ondernemers hebben vaak contact met de overheid. Dit contact verloopt via steeds meer interactiekanalen. Veel van deze contacten gaan over de levering van een product of dienst door de overheid aan een burger of ondernemer.
Commerciële partijen als PostNL en Bol.com hebben de afgelopen jaren geoptimaliseerde klantportalen en ‘track & trace’-functionaliteit ontwikkeld waarmee bestellingen op ieder moment te volgen zijn. De overheid is op dit gebied minder ver. Reden om de referentiearchitectuur Omnichannel te verdiepen met een referentiearchitectuur ‘MijnZaken’. MijnZaken is een publieke variant op ‘track & trace’, aansluitend bij publieke waarden, en voldoend aan wet en regelgeving die voor de overheid geldt.
"MijnZaken omvat die informatie over de levering van producten en diensten door de overheid die voor burgers en bedrijven belangrijk is. Deze informatie wordt door de overheid proactief en via een kanaal naar keuze aan burgers en bedrijven aangeboden. MijnZaken werkt ketenbreed en uniform: burgers en bedrijven worden op eenduidige wijze geïnformeerd, ook als bij de levering van een product of dienst meerdere (overheids)organisaties betrokken zijn."
Wat heeft de burger eraan?[bewerken]
Burgers, bedrijven of instellingen die producten van de overheid afnemen, weten vaak niet (goed genoeg) wat de status van hun productaanvraag is of hoe lang het nog gaat duren voordat het product geleverd wordt. Het komt voor dat ze met meerdere organisaties contact moeten opnemen om dit te achterhalen – het bekende van het kastje naar de muur sturen. Met MijnZaken kunnen burgers en bedrijven de levering van producten en diensten volgen, ook als daarbij meerdere (overheids)organisaties betrokken zijn. Zij worden proactief en via een kanaal naar keuze geïnformeerd over die levering, onder voorbehoud dat het kanaal door de organisatie beschikbaar is gesteld.
Wat hebben de overheidsorganisaties eraan?[bewerken]
Maar MijnZaken helpt ook overheden: een goed geïnformeerde burger staat minder vaak aan de balie of maakt minder vaak contact middels een ander kanaal. En doordat overheidsorganisaties op een eenduidige manier informatie met elkaar delen, kunnen vragen worden beantwoord door een klantenservicemedewerker in plaats van de vakspecialist. Zij hebben daardoor meer tijd voor het leveren van goede dienstverlening en ondersteuning op maat. MijnZaken-informatie kan daarnaast worden gebruikt voor het bewaken van het verloop van (keten)processen en het bijsturen van de inrichting daarvan.
Bijdragen[bewerken]
Deze referentiearchitectuur is tot stand gekomen in samenwerking met onderstaande organisaties. De deelnemende organisaties hebben de conceptversies van review voorzien en hebben waardevolle input geleverd.
| Reviewer | Organisatie |
|---|---|
| Dhr. H. van Hees | gemeente Tilburg |
| Dhr. M. Groenestein | gemeente Helmond |
| Dhr. R. Meijer | gemeente Ooststellingwerf, Weststellingwerf en Opsterland |
| Dhr. V. van Beek | gemeente Den Haag |
| Dhr. J. Verbeek | gemeente Den Haag |
| Dhr. J. Zwart | Raad voor de Kinderbescherming |
| Dhr. R. Sjouwerman | Divosa |
| Dhr. L. Vermeer | ICTU |
Bedrijfsarchitectuur
Dit hoofdstuk beschrijft de actoren, bedrijfsobjecten en -processen en -diensten die bij het verstrekken en ontvangen van MijnZaken-informatie een rol spelen.
Actoren en rollen[bewerken]
Bij het verstrekken en ontvangen van MijnZaken-informatie kunnen drie actoren betrokken zijn.
- Burger: Iedere natuurlijke persoon die ingezetene is in Nederland (zoals opgenomen in de BRP), of is opgenomen in het Register Niet-Ingezetenen RNI.
- Private partij: een organisatie met of zonder winstoogmerk die tot doel heeft goederen en/of diensten te produceren en/of die te leveren aan andere organisaties of individuen.
- Overheidsorganisatie: een organisatie van de overheid die overheidstaken uitvoert of in opdracht van de overheid een wettelijke taak vervult (zoals zelfstandige bestuursorganen).
Bovengenoemde actoren kunnen drie rollen vervullen:
- Afnemer van MijnZaken-informatie: degene die MijnZaken-informatie gebruikt om inzicht te krijgen in de status van levering van een product of dienst. Dit kan zowel de indiener van een verzoek zijn, als een medewerker van een overheidsorganisatie
- Aanbieder van MijnZaken-informatie: degene die handelingen uitvoert die ervoor zorgen dat de status van levering van een product of dienst verandert.
De relaties in Figuur 1 hierboven laten zien dat een burger alleen kan optreden als afnemer van MijnZaken-informatie. Private partijen en overheidsorganisaties kunnen zowel de rol van afnemer als de rol van aanbieder daarvan vervullen.
Bedrijfsobjecten[bewerken]
Bij het verstrekken van MijnZaken-informatie is een aantal bedrijfsobjecten betrokken. Deze kunnen verdeeld worden in drie categorieën:
- Bedrijfsobjecten die informatie omvatten waaruit MijnZaken-informatie is opgebouwd. Dit geldt voor ‘verzoek’, ‘product/dienst’ en ‘zaak’. In Figuur 2 is deze relatie geïllustreerd door een aggregatierelatie tussen deze objecten en ‘MijnZaken-informatie’. Dit betekent dat MijnZaken-informatie geen nieuwe informatie is, maar informatie die al binnen de overheidsorganisatie beschikbaar is, zoals verzoek- en zaakstatussen, en statusbeschrijvingen en servicetermijnen die in een producten- en dienstencatalogus of zaaktypecatalogus beschreven zijn.
- Bedrijfsobjecten die informatie omvatten die bepaalt of, en zo ja hoe MijnZaken-informatie geleverd wordt. Het gaat dan bijvoorbeeld om klantvoorkeuren die bepalen welk kanaal voor levering van MijnZaken-informatie wordt gebruikt, en toestemming die bepaalt of, en zo ja in welke mate een medewerker die daarvoor geen andere grondslag heeft toegang heeft tot statusinformatie bij aanvragen van een inwoner of bedrijf. Deze objecten zijn Figuur 2 donkergeel gekleurd.
- Bedrijfsobjecten die een rol spelen tijdens het proces van aanvragen en leveren van producten en diensten, de referentiearchitectuur Omnichannel, en/of onderdeel uitmaken van een integraal klantbeeld, maar die bij het verstrekken van MijnZaken-informatie een secundaire, of überhaupt geen rol spelen. Deze objecten zijn in Figuur 2 lichtgeel gekleurd.
In de tabel hieronder zijn de definities voor de geïllustreerde bedrijfsobjecten opgenomen. Deze zijn voor zover daarin beschreven overgenomen uit de referentiearchitectuur Omnichannel of GEMMA-referentiearchitectuur.
| Bedrijfsobject | GEMMA-definitie |
|---|---|
| klantvoorkeur | De voorkeur die een klant heeft met betrekking tot de dienstverlening. Dit kan bijvoorbeeld gaan over het gewenste communicatiekanaal of een taalinstelling. |
| toestemming | De toestemming die een klant gegeven heeft aan een gemeente om klantgegevens in te zien of te verwerken. |
| machtiging | De machtiging die een klant aan een ander natuurlijk persoon heeft verstrekt. |
| klant | Een natuurlijk persoon of niet-natuurlijk persoon waar een product/dienst wordt geleverd. |
| natuurlijk persoon | Een mens. |
| niet-natuurlijk persoon | Een rechtspersoon of een samenwerkingsverband. |
| verzoek | Een vraag, melding of aanvraag voor een product/dienst door een klant. |
| product/dienst | Een tastbaar goed of verzameling activiteiten die door de gemeente geleverd kunnen worden. |
| contactmoment | Een aaneengesloten interactie tussen inwoner of (vertegenwoordiger van) een onderneming en de gemeente via een synchroon kanaal (telefoon, gesprek aan de balie) of een informatieverstrekking door de inwoner of (vertegenwoordiger van) een onderneming aan de gemeente of vice versa via een asynchroon kanaal (e-mail, contactformulier, chatbot) waarvan de inhoud relevant is voor de dienstverlening of verantwoording door de gemeente. |
| afspraak | Een gepland klantcontact tussen een klant en de gemeente. |
| medewerker | Een [natuurlijk persoon] met een tijdelijk of vaste [dienstbetrekking] of met een inhuurcontract met de gemeente. |
| organisatie-eenheid | Een clustering van medewerkers binnen de lijnorganisatie met een duidelijk gedefinieerde specifieke taakstelling. |
| zaak | Een samenhangende hoeveelheid werk met gedefinieerde aanleiding en een gedefinieerd eindresultaat waarvan kwaliteit en doorlooptijd bewaakt moeten worden. |
| mijnzaken-informatie | Informatie die inzicht geeft in het proces voor levering van een product of dienst, de huidige status van een specifieke verzoek binnen dat proces en een indicatie van de verwachtte resterende levertijd. |
| document | Een informatieobject met als generieke aanduiding 'document' kan van alles zijn, ongeacht aard en vorm: een tekstverwerkingsdocument, een papieren brief, een webpagina, een landkaart, een foto, een geluidsopname, een dataset, een blog, etc. |
| besluit | Een beslissing over het wel of niet toekennen van [product/dienst]. |
| verwerkingenlog | De vastlegging van een verwerking in een logregistratie om de verwerking van objectgegevens te kunnen duiden. |
Bedrijfsprocessen en -diensten[bewerken]
Figuur 3 laat zien hoe MijnZaken-informatie wordt verstrekt. De basis hiervoor is het bedrijfsproces ‘Verstrekken van producten en diensten’ dat de overheidsorganisatie naar aanleiding van een aanvraag voor een product of dienst door een burger of bedrijf of instelling is gestart. Deze aanvraag wordt zaakgericht behandeld. Tijdens de behandeling doorloopt de zaak verschillende fases. Hierbij ontstaan statuswijzigingen. Deze statuswijzigingen vormen de basis voor MijnZaken-informatie.
Het leveren van MijnZaken-informatie kent een eigen bedrijfsproces: ‘Verstrekken MijnZaken-informatie’. Tijdens het doorlopen van dit proces worden een aantal bedrijfsobjecten gelezen: ‘klantvoorkeur’ om MijnZaken-informatie te kunnen leveren via het voorkeurskanaal van de klant, en ‘machtigingen’ en ‘toestemmingen’ om te bepalen of de afnemer wel recht heeft op inzage in de te verstrekken gegevens. Daarnaast de uit ‘verzoek’-, ‘zaak’- en ‘product/dienst’-informatie samengestelde MijnZaken-informatie die aan de aanvrager verstrekt wordt. Het verstrekken van deze informatie wordt bovendien vastgelegd in een verwerkingenlog.
Interactie tussen de MijnZaken-afnemer en -aanbieder vindt plaats via de dienst ‘MijnZaken’ die de MijnZaken-aanbieder levert. Deze dienst kan worden aangeroepen via een daartoe door de MijnZaken-aanbieder ingericht 'Interactiekanaal’. Dit kanaal ondersteunt zowel het opvragen van statusinformatie door een MijnZaken-afnemer (pull-scenario, zie ook Figuur 5) als het ontvangen van statusinformatie op initiatief van de aanbieder verstrekte MijnZaken-informatie (push-scenario, zie ook Figuur 4).
Scenario’s voor levering van MijnZaken-informatie[bewerken]
MijnZaken-informatie kan op verschillende manieren aan afnemers geleverd worden. Factoren die de wijze van leveren beïnvloeden zijn:
- De aanleiding voor het leveren van MijnZaken-informatie. Een aanbieder van MijnZaken-informatie kan een statusupdate naar een afnemer ‘pushen’ naar aanleiding van een veranderde status bij een aanvraag of zaak (Figuur 4), maar een (eind)afnemer kan ook het zelf het initiatief nemen tot het opvragen (‘pullen’) van de laatste statusinformatie (Figuur 5).
- Het kanaal dat wordt gebruikt voor het opvragen van statusinformatie. Een (eind)afnemer kan inzicht in statusinformatie krijgen via geautomatiseerde, digitale kanalen (Figuur 4, Figuur 5 en Figuur 7), of door te bellen naar het klantcontactcentrum van de overheidsorganisatie die de aanvraag behandelt (Figuur 6). In het laatste geval kan niet alleen de Burger, maar ook de KCC-medewerker van de Overheidsorganisatie waarmee contact wordt gelegd gezien worden als afnemer van MijnZaken-informatie
- De betrokkenheid van meerdere organisaties. Als meerdere organisaties betrokken zijn bij de levering van een product of dienst aan een (eind)afnemer, dan geldt de overheidsorganisatie bij de wie de oorspronkelijke productaanvraag is ingediend niet alleen als aanbieder (aan de burger die geldt als (eind)afnemer)) van MijnZaken-informatie, maar ook als afnemer van door de ketenpartner aangeleverde MijnZaken-informatie (Figuur 7).
In onderstaande diagrammen treedt steeds een burger op als (eind)afnemer. Maar deze rol zou ook kunnen worden vervuld door een private partij of een (tweede) overheidsorganisatie.
De diagrammen sluiten aan bij de in hoofdstuk 8 beschreven casussen. Figuur 5 bij ‘MijnGemeente’, Figuur 6 bij ‘CRM’ en Figuur 7 bij ‘Statusuitwisseling tussen organisaties’.
Informatiearchitectuur
Dit hoofdstuk beschrijft de informatiearchitectuur voor MijnZaken. In de informatiearchitectuur worden interacties tussen relevante referentiecomponenten beschreven. Daarbij wordt ook een relatie gelegd naar de eerder besproken bedrijfsobjecten, -processen en -diensten om aan te geven welke informatie bij een interactie verwerkt wordt.
De informatiearchitectuur volgt het 5-lagen model van het GEMMA Gegevenslandschap en de informatiekundige visie Common Ground . Elementen uit de bedrijfsarchitectuur worden buiten deze 5 lagen geplaatst.
Laag 5 – Interactie[bewerken]
De componenten in deze laag verzorgen de interactie met de gebruikers. Voor de interactie met burgers kunnen dit websites, apps of chatbots zijn. Een medewerker van een organisatie maakt doorgaans gebruik van een interne (web)applicatie.
Laag 4 – Proceslogica[bewerken]
Het verloop van interacties waarbij gegevens opgehaald of verwerkt worden in de achterliggende registers wordt vormgegeven in deze laag. Door de logica los te koppelen van de interactie ontstaat een onafhankelijkheid in het gebruik van een interface of kanaal. Bijvoorbeeld, het opvragen van een status via een website verloopt daardoor op dezelfde manier als via een chatkanaal.
Laag 3 – Integratie[bewerken]
In deze laag bevinden zich de componenten die de dienstenafnemers (laag 4 en 5) verbinden met de dienstenaanbieders (laag 1 en 2). Denk hierbij aan een API-gateway of een Enterprise service bus (ESB). Omwille van de leesbaarheid van onderstaande diagrammen wordt deze laag niet gevuld met de benodigde componenten. De relaties tussen de proceslogica en de gebruikte diensten (API’s) zouden wegvallen waardoor niet duidelijk is welke processtap welke gegevens verwerkt.
Laag 2 – Diensten[bewerken]
Gegevens die verwerkt worden, worden ontsloten via API’s. Er kunnen meerdere API’s beschikbaar gesteld zijn voor het bewerken van gegevens. Bijvoorbeeld omdat dit vanwege de veiligheid beter te organiseren is. API’s kunnen ook gecombineerd worden, zodat een soort convenience API ontstaat waarbij gegevens uit meerdere bronnen gecombineerd worden teruggegeven aan de afnemer. Op die manier wordt voorkomen dat teveel gegevens opgehaald en getoond worden aan de gebruiker.
Laag 1 – Gegevens[bewerken]
De componenten bevatten de (bron)gegevens. Deze gegevens worden ontsloten via de bovenliggende API’s.
Interactiepatronen opvragen status[bewerken]
Deze paragraaf beschrijft hoe MijnZaken-informatie uit (bron)registraties wordt opgehaald en hoe voor verschillende doelgroepen en situaties kan worden voldaan aan voorwaarden (authenticatie, autorisatie, controleren machtigingen en toestemmingen) om die te mogen leveren.
Verbinding met de bedrijfsarchitectuur[bewerken]
In hoofdstuk 3 is de bedrijfsarchitectuur voor MijnZaken beschreven. In deze paragraaf beschrijven we als onderdeel van de informatiearchitectuur interactiepatronen. Deze hangen op twee manieren samen met de bedrijfsarchitectuur:
- De verschillende applicatieprocessen die de hieronder beschreven interactiepatronen ondersteunen samen het in het vorige hoofdstuk beschreven bedrijfsproces ‘Verstrekken MijnZaken-informatie en de bedrijfsdienst ‘MijnZaken’ (Figuur 8).
- Gegevensobjecten die in de hieronder beschreven interactiepatronen worden geraadpleegd of gewijzigd realiseren volgens de in Figuur 9 geïllustreerde structuur de in Figuur 2 beschreven bedrijfsobjecten.
Het hieronder beschreven interactiepatroon illustreert hoe informatie over de status van een aanvraag van een product of dienst aan een burger of medewerker wordt getoond. Zichtbaar wordt welke gegevensobjecten hiervoor nodig zijn, en via welke gegevenscomponenten en API-interfaces die beschikbaar worden gesteld.
Het patroon is beschreven in zes onderdelen:
- Burger authenticeren en machtigingen toetsen – beschrijft op welke manier de identiteit van een burger wordt gecontroleerd en diens machtigingen getoetst. Van de drie in de bijlagen beschreven casussen is dit deel alleen relevant voor de casus ‘MijnGemeente’.
- Bedrijf of instelling authenticeren en machtigingen toetsen – beschrijft op welke manier de identiteit van een vertegenwoordiger van een bedrijf of instelling wordt vastgesteld en diens machtigingen om namens bedrijf of instelling te handelen worden opgehaald en gecontroleerd. Van de drie in de bijlagen beschreven casussen is dit deel alleen relevant voor de casus ‘MijnGemeente’.
- Medewerker authenticeren en autoriseren en klanttoestemmingen controleren – beschrijft op welke manier de identiteit van een medewerker wordt vastgesteld, diens autorisaties worden opgehaald. Van de drie in de bijlagen beschreven casussen is dit deel alleen relevant voor de casus ‘CRM’.
- Klantgegevens ophalen – beschrijft hoe contactgegevens en klantvoorkeuren (bijvoorbeeld een voorkeurskanaal) worden opgehaald.
- Klanttoestemmingen controleren – beschrijft hoe wordt gecontroleerd of een afnemer toestemming heeft gegeven voor verwerking van (persoons)gegevens in het kader van verstrekking van MijnZaken-informatie (dit voor zover het gaat om gegevens die niet op basis van een andere grondslag mogen worden verwerkt).
- Status lopende aanvragen en zaken tonen – beschrijft op welke manier statusinformatie over de aanvraag van een product of dienst aan een burger, medewerker óf andere organisatie worden getoond. Dit deel van het interactiepatroon dus generiek en geldend voor alle casussen waarbinnen MijnZaken-informatie wordt geleverd.
Niet ieder van de bovengenoemde onderdelen is in iedere situatie nodig. Zo hoeft afhankelijk van de doelgroep (burgers, bedrijven en organisaties of medewerkers) waartoe de afnemer behoort maximaal eenmaal een autorisatie- en authenticatieproces doorlopen te worden. Maar in gevallen waar ‘openbare’ gegevens als MijnZaken-informatie worden geleverd (bijvoorbeeld statusinformatie naar aanleiding van een melding over een defecte lantaarnpaal) kunnen authenticatie en autorisatie wellicht überhaupt achterwege blijven.
Een ander voorbeeld is het controleren van toestemmingen. Als een afnemer zelf het initiatief neemt voor het inzien van MijnZaken-informatie hoeft niet door de aanbieder gecontroleerd te worden of hij of zij toestemming heeft gegeven voor het verwerken van persoonlijke gegevens voor dat doel – het initiatief ís dan immers de toestemming. Als een overheidsorganisatie aan de andere kant een afnemer geautomatiseerd van iedere statuswijziging op de hoogte wil stellen is zo’n controle weer wel nodig.
Een overzicht van generieke componenten en API’s die betrokken (kunnen) zijn bij het ontstaan of tonen van MijnZaken-informatie is te vinden in bijlage 6.1.
| Applicatieproces | Beschrijving |
|---|---|
| Burger authenticeren en machtigingen toetsen | De identiteit van de burger wordt vastgesteld middels een authenticatiemiddel met een betrouwbaarheid die aansluit bij de gevoeligheid van de als MijnZaken-informatie te leveren gegevens. Daarnaast wordt gecontroleerd welke machtigingen de burger heeft om producten aan te vragen namens iemand anders (bijvoorbeeld omdat die burger optreedt als bewindvoerder voor een andere burger) of welke machtigingen diegene heeft om MijnZaken-informatie namens iemand anders op te vragen. |
| Applicatieproces | Beschrijving |
|---|---|
| (Vertegenwoordiger van) bedrijf of instelling authenticeren en machtigingen toetsen | De gebruiker wordt geauthenticeerd om vast te stellen dat die het recht heeft om het bedrijf of de instelling te vertegenwoordigen. Daarnaast wordt gecontroleerd welke machtigingen de gebruiker heeft om namens het bedrijf of de instelling te handelen. |
| Applicatieproces | Beschrijving |
|---|---|
| Medewerker authenticeren en autoriseren | De identiteit van de medewerker wordt vastgesteld middels een authenticatiemiddel met een betrouwbaarheid die aansluit bij de gevoeligheid van de als MijnZaken-informatie te leveren gegevens. Daarnaast worden de rollen waaraan de medewerker is toegewezen opgehaald. Aan de hand van autorisatieprofielen die gekoppeld zijn aan producten of diensten wordt vastgesteld of de medewerker - via de aan hem of haar toegewezen rollen - de juiste autorisaties bezit om toegang te krijgen tot de gevraagde MijnZaken-informatie. |
| Applicatieproces | Beschrijving |
|---|---|
| Basisgegevens ophalen | Basisgegevens van de afnemer worden op basis van een uniek identificerend gegeven (afhankelijk van de doelgroep BSN, OIN of KvK-nummer) opgehaald. Daartoe wordt eerst de GBA-administratiecomponent (burger, BSN) of het Handelsregister (bedrijf of instelling, OIN of KvK-nummer) bevraagd. Deze stap is optioneel. |
| Klantgegevens ophalen | Op basis van (een combinatie van) (zeer waarschijnlijk) uniek identificerend(e) gegeven(s) worden aanvullende klantgegevens en klantvoorkeuren (zoals voorkeurskanalen) opgehaald uit het Klantenregister. Het uniek identificerende gegeven kan een BSN, OIN of KvK-nummer uit de vorige stap zijn, maar ook bijvoorbeeld een combinatie van zaaknummer en naam of e-mailadres. Op basis van het laatste mogen slechts beperkt gevoelige gegevens worden verstrekt. |
| Applicatieproces | Beschrijving |
|---|---|
| Klanttoestemmingen controleren | Er wordt gecontroleerd of, en zo ja in welke mate de afnemer toestemming heeft gegeven voor verwerking van (persoons)gegevens voor dit doel (dit voor zover het gaat om gegevens die niet op basis van een andere grondslag mogen worden verwerkt). |
| Applicatieproces | Beschrijving |
|---|---|
| Status aanvragen en zaken tonen | Alle beschikbare informatie over de status van levering van een door een afnemer aangevraagd(e) product of dienst wordt opgehaald en getoond. |
| Verzoekgegevens tonen | Op basis van een relatie tussen klanten in het Klantenregister en via het gegevensobject klantverzoeken in het Verzoekenregister worden de door de burger opgevraagde verzoekgegevens (o.a. moment van indienen en aangevraagd product) opgehaald en getoond. Op basis van een relatie met verzoeken via het gegevensobject verzoekproducten in het Verzoekenregister worden uit de Producten-en-dienstencataloguscomponent aanvullende gegevens over het aangevraagde product (zoals een beschrijving en behandeltermijnen) opgehaald en getoond. |
| Zaakgegevens tonen | Op basis van een relatie met verzoeken via het gegevensobject zaakverzoeken in het Zakenregister worden de zaak- en statusgegevens van de za(a)k(en) die naar aanleiding van de ingediende verzoek zijn gestart opgehaald en getoond. Op basis van de relatie van statussen naar statustypen in de Zaaktypecataloguscomponent worden op basis van het gegevensobject statustypen aanvullende gegevens over statussen (zoals de omschrijving daarvan) opgehaald en getoond. |
Informatiebeveiliging en privacy
Informatiebeveiliging en privacy zijn binnen de referentiearchitectuur MijnZaken belangrijke aandachtspunten. Daarbinnen worden immers (ook) gevoelige, persoonlijke gegevens verwerkt.
De inhoud van dit hoofdstuk omvat enkele beveiligings- en privacyprincipes, maar is een eerste, theoretische uitwerking. Uiteindelijk moet op basis van pilots een meer gedetailleerde risicoanalyse worden gemaakt. Bij het maken van die nadere risicoanalyse zal gebruikgemaakt worden van de IRPA tool van de IBD zodat de analyses vastgelegd en te hergebruiken zijn door gemeenten die met MijnZaken aan de slag gaan.
Uitgangspunten[bewerken]
De volgende uitgangspunten gelden in generieke zin bij de implementatie van MijnZaken:
- Burgers, bedrijven of instellingen zien alleen ‘eigen’ gegevens of gegevens waarvoor zij gemachtigd zijn;
- De privacy van de medewerkers van organisaties moet gewaarborgd zijn;
- Medewerkers van organisaties verwerken alleen die gegevens waarmee een doelbinding is;
- Alleen de juiste gegevens worden verwerkt en getoond.
Grootste risico’s van MijnZaken[bewerken]
Op basis van hetgeen in deze referentiearchitectuur is beschreven, is een ruwe schatting te maken van dreigingen en risico’s om rekening mee te houden. In willekeurige volgorde zijn dit:
- Er worden onjuiste gegevens verstrekt. Dit kunnen niet-integere gegevens (bronsysteem) zijn of door het gebruik van een verkeerde koppeling;
- Gegevens of informatie wordt aan verkeerde mensen verstrekt (burgers, ambtenaren en ketenpartijen). Bijvoorbeeld door onjuiste authenticatie of autorisatie;
- De informatiesystemen die de gegevens moeten verwerken/verstrekken zijn niet beschikbaar. Mogelijk raken dan andere kanalen overbelast;
- Er wordt te weinig informatie verstrekt waardoor alsnog aanvullende vragen worden gesteld;
- Er wordt teveel informatie verstrekt. Dit kan bijvoorbeeld gebeuren doordat:
- In het kader van doelbinding teveel gegevens aan medewerkers worden getoond;
- Informatie wordt niet goed gefilterd;
- In het geval van eHerkenning het niet kunnen loggen op persoon maar op organisatie, waardoor niet duidelijk is wie wat heeft ingezien;
- MijnZaken is door middel van een API gateway vanaf het internet direct beschikbaar. Er bestaat een risico is dat derden toegang krijgen tot gegevens waar ze niet bij mogen.
Maatregelen en componenten[bewerken]
De volgende maatregelen kunnen of moeten genomen worden om de risico’s weg te nemen of te minimaliseren:
- Autoriseren op zaakniveau / gegevens- en attribuutniveau / afnemer, onafhankelijk van kanaal;
- Zorgdragen dat op basis van autorisatie onderscheid kan worden gemaakt tussen inzage in “dat”- (inhoud) en “wat”- (procesverloop)-informatie;
- Er moeten beschikbaarheidsmaatregelen genomen worden zodat uitval van een informatiesysteem wordt beperkt;
- Er moet vastgelegd worden welke persoon welke gegevens op welk moment heeft ingezien;
- Het moet duidelijk gepubliceerd of gecommuniceerd zijn waar een burger, bedrijf of instelling terecht kan als er verstoringen bij het ophalen van gegevens worden geconstateerd;
- Veilig ontwikkelen/hanteren ontwikkelstandaarden;
- Tijdens en na het implementeren van (aanpassingen aan) de componenten worden testen uitgevoerd om de veiligheid en privacy te waarborgen (dit betreft ook pentesten);
- MijnZaken is internet facing middels een API gateway, dit betekent dat maatregelen goed ingeregeld moet worden om geen afbreuk te doen aan beveiliging;
- Er is gedegen documentatie beschikbaar waarin is beschreven hoe de informatievoorziening is geïmplementeerd en welke beveiligings- en privacymaatregelen getroffen zijn;
- Voor iedere MijnZaken-implementatie wordt een IRPA analyse uitgevoerd.
VNG Realisatie start eind 2021 met het uitwerken van een architectuur die beschrijft hoe IAM-functionaliteit er in een gegevenslandschap uit moet zien. De hieruit voortkomende principes en architectuur gaan in op het veilig ontsluiten van gegevens via API’s. Zodra deze uitwerking beschikbaar is, wordt een verwijzing hiernaar in deze referentiearchitectuur opgenomen.
Verwerkingsregister en verwerkingenlogging[bewerken]
Eén van de genoemde risico’s is het verstrekken van teveel gegevens aan een medewerker. Dit kan gebeuren als niet duidelijk is met welke doelbinding de gegevens opgevraagd mogen worden. Organisaties zijn volgens Artikel 30 lid 1 AVG verplicht om een verwerkingsregister bij te houden. In een verwerkingsregister is o.a. vastgelegd:
- contactgegevens, bestaande uit:
- uw naam en contactgegevens;
- de naam en contactgegevens van partijen waarmee u gezamenlijke verwerkingsverantwoordelijke bent;
- de contactgegevens van de functionaris voor gegevensbescherming (FG);
- de verwerkingsdoeleinden;
- de categorieën van betrokkenen en categorieën van persoonsgegevens;
- de categorieën van ontvangers;
- eventuele doorgiften van persoonsgegevens aan derde land of internationale organisatie;
- indien mogelijk, de bewaartermijnen;
- indien mogelijk, de beveiligingsmaatregelen.
De Informatiebeveiligingsdienst (IBD) heeft een handreiking geschreven hoe om te gaan met deze verplichting. Ook is er een vooringevuld verwerkingsregister beschikbaar gesteld.
Een aanvullende maatregel hierop is het vastleggen van de verwerkingsacties die op persoonsgegevens zijn uitgevoerd. Elke component die persoonsgegevens afneemt of aanbiedt, moet deze verwerkingsactie vastleggen. Het vastleggen gebeurt in een verwerkingenloggingregister. Door VNG Realisatie is de Verwerkingenlogging API-standaard ontwikkeld als onderdeel van de GEMMA referentiearchitectuur. Deze API-standaard biedt leveranciers van informatiesystemen gestandaardiseerde API-specificaties voor het vastleggen en ontsluiten van de logging van verwerkingen.
In deze referentiearchitectuur is daarom de referentiecomponent Verwerkingenloggingregister en bijhorende Verwerkingenlogging API opgenomen.
Onderstaande afbeeldingen zijn afkomstig uit de referentiearchitectuur Verwerkingenloggingregister en illustreren de relatie en afhankelijkheden tussen de relevante referentiecomponenten.
Principes, kaders en context
Dit hoofdstuk beschrijft de principes en kaders waaraan de architectuur en MijnZaken-implementaties moeten voldoen en schetst de context daarbij.
Principes[bewerken]
| MijnZaken-principe | 1. MijnZaken-informatie is aangepast op de behoefte van de ontvanger |
|---|---|
| Rationale | MijnZaken-informatie informeert de ontvanger zo goed mogelijk over de status van levering van een product of dienst. Dit vereist dat de getoonde informatie op de behoeften van die ontvanger is afgestemd. |
| Implicaties voor referentiearchitectuur MijnZaken | De referentiearchitectuur MijnZaken beschrijft het aanbieden van gegevens als MijnZaken-informatie voor verschillende doelgroepen. |
| Implicaties voor implementaties MijnZaken | Implementaties van MijnZaken worden zodanig ingericht dat inhoud, taalgebruik en presentatie van MijnZaken-informatie worden aangepast aan de ontvanger. Deze informatie is voor die ontvanger:
Dit betekent dat niet in alle gevallen dezelfde gegevens als MijnZaken-informatie worden aangeboden. Een burger zal bijvoorbeeld een ander(e) kennisniveau en informatiebehoefte hebben dan een klantenservicemedewerker van een overheidsorganisatie. |
| Bronprincipe(s) | Dit principe is afgeleid van:
|
| MijnZaken-principe | 2. MijnZaken-informatie kan via meerdere kanalen worden verkregen |
|---|---|
| Rationale | Niet iedere ontvanger wil op dezelfde manier MijnZaken-informatie ontvangen. MijnZaken-informatie kan daarom via meerdere kanalen worden aangeboden. |
| Implicaties voor referentiearchitectuur MijnZaken | De referentiearchitectuur MijnZaken beschrijft hoe MijnZaken-informatie kan worden aangeboden, ongeacht het kanaal dat daarvoor wordt gebruikt. |
| Implicaties voor implementaties MijnZaken | Implementaties van MijnZaken worden zodanig ingericht dat MijnZaken-informatie (op termijn) via meerdere kanalen kan worden aangeboden. |
| Bronprincipe(s) | Dit principe is afgeleid van: |
| MijnZaken-principe | 3. Voor het leveren van MijnZaken-informatie worden zo mogelijk bestaande componenten en standaarden (her)gebruikt |
|---|---|
| Rationale | De drempel om MijnZaken-informatie aan te bieden moet laag zijn. Daarom wordt gebruikgemaakt van componenten met helder gedefinieerde verantwoordelijkheden en reeds beschikbare open standaarden. MijnZaken kan zo ‘meegroeien’ met de ontwikkeling van standaarden en het beschikbaar komen van oplossingen van leveranciers die MijnZaken-informatie bijvoorbeeld via een nieuw kanaal beschikbaar maken. |
| Implicaties voor referentiearchitectuur MijnZaken | De referentiearchitectuur maakt waar mogelijk (her)gebruik van open standaarden die los installeerbare componenten verbinden. |
| Implicaties voor implementaties MijnZaken | Implementaties van MijnZaken gebruiken de in de referentiearchitectuur beschreven standaarden en componenten en maken bij de presentatie van MijnZaken-informatie gebruik van standaardoplossingen als NL Design System. |
| Bronprincipe(s) | Dit principe is afgeleid van:
|
| MijnZaken-principe | 4. MijnZaken-informatie komt uit de bron |
|---|---|
| Rationale | Het is belangrijk dat MijnZaken-informatie actueel en juist is. MijnZaken informatie wordt daarom (voor zover mogelijk) op aanvraag verstrekt en bij de bron verkregen. |
| Implicaties voor referentiearchitectuur MijnZaken | De referentiearchitectuur beschrijft interactiepatronen om op basis van notificaties over statusveranderingen gegevens die onderdeel (kunnen) zijn van MijnZaken-informatie vanuit de bijbehorende bronregistraties op te halen en aan de ontvanger aan te bieden. |
| Implicaties voor implementaties MijnZaken | Implementaties van MijnZaken volgen (voor zover mogelijk) de in de referentiearchitectuur beschreven interactiepatronen. |
| Bronprincipe(s) | Dit principe is afgeleid van:
|
| MijnZaken-principe | 5. MijnZaken-informatie wordt vertrouwelijk verwerkt |
|---|---|
| Rationale | MijnZaken-informatie omvat persoonsgegevens en mogelijk andere gevoelige data die bijvoorbeeld te maken hebben met de financiële situatie van de aanvrager. Deze gegevens worden vertrouwelijk, en in lijn met wet- en regelgeving behandeld. |
| Implicaties voor referentiearchitectuur MijnZaken | De referentiearchitectuur beschrijft hoe toegang tot gegevens wordt beperkt voor ontvangers die daartoe niet gerechtigd zijn, en licht toe hoe deze gegevens conform relevante wet- en regelgeving verwerkt moeten worden. |
| Implicaties voor implementaties MijnZaken | Implementaties van MijnZaken beperken de toegang tot MijnZaken-informatie, verwerken die volgens relevante wet- en regelgeving en bieden burgers inzage in het gebruik van MijnZaken-informatie door medewerkers van de gemeente. |
| Bronprincipe(s) | Dit principe is afgeleid van:
|
Wet- en regelgeving[bewerken]
| Nr. | Verplichting | Bron | Toelichting |
|---|---|---|---|
| 1 | Beperkt recht op inzage door burgers bij behandeling vertrouwelijke of gevoelige zaken. | Algemene Verordening Gegevensbescherming (AVG) en materie- wetgeving | Op basis van artikel 23 lid 1 onderdeel i van de AVG mag inzage door burgers in eigen persoonsgegevens geweigerd worden als die afbreuk zou doen aan ‘rechten en vrijheden van anderen’. Bovendien kennen verschillende ‘materiewetten’ (bijvoorbeeld artikel 7.3.11 lid 3 Jeugdwet, artikel 5.3.2 lid 4 Wmo 2015) bepalingen op basis waarvan inzage in gevoelige informatie door betrokkenen geweigerd kan worden. Dit betekent dat aan burgers geen statusinformatie verstrekt wordt over bijvoorbeeld een onderzoek naar fraude of een onderzoek naar aanleiding van een melding bij Veilig Thuis. |
| 2 | Medewerkers hebben alleen toegang tot informatie die nodig is om een burger of ondernemer te helpen | Algemene Verordening Gegevensbescherming (AVG) | Persoonsgegevens die worden verwerkt moeten toereikend en ter zake dienend zijn, en beperkt zijn tot wat noodzakelijk is voor de doeleinden. Daarbij gaat het om proportionaliteit en subsidiariteit, waardoor een minimum aan verwerking van persoonsgegevens wordt gerealiseerd (artikel 5, eerste lid, onder c, van de AVG). Er mogen niet meer gegevens dan nodig worden verwerkt en er moet goed worden bezien of het doel niet op een manier kan worden bereikt die minder inbreuk maakt op privacy. |
| 3 | Overheidsorganisaties moeten zich kunnen verantwoorden over verwerkte persoonsgegevens | Algemene Verordening Gegevensbescherming (AVG) | Overheidsorganisaties moeten kunnen aantonen dat een verwerking aan de belangrijkste beginselen van verwerking voldoet, zoals rechtmatigheid, transparantie, doelbinding en juistheid. Ook moet aangetoond kunnen worden dat de juiste technische en organisatorische maatregelen genomen zijn om de persoonsgegevens te beveiligen. |
| 4 | Overheidsinformatie is duurzaam toegankelijk en wordt (indien van toepassing) op het aangewezen moment vernietigd | Archiefwet | Overheidsorganisaties houden hun informatie (‘archiefbescheiden’) duurzaam toegankelijk, en/of die vernietigen die wanneer de bewaartermijn is verlopen. Dit is belangrijk omdat overheidsinformatie een rol speelt bij rechtsvinding en de (publieke) verantwoording door diezelfde overheid. Overheidsorganisaties moeten daarom aan burgers of derden verstrekte informatie archiveren, of die verstrekking op zodanige wijze vastleggen (loggen), dat onomstotelijk kan worden bewezen op welk moment aan wie welke gegevens geleverd zijn. |
| 5 | Verplicht aangewezen open standaarden worden gebruikt | Wet digitale overheid (nog niet in werking) | Overheidsorganisaties kunnen bij algemene maatregel van bestuur worden verplicht een open standaard toe te passen. Een standaard kan worden aangewezen als dat noodzakelijk en proportioneel is voor de werking, de veiligheid, de betrouwbaarheid, de duurzame toegankelijkheid of de doelmatigheid van het elektronische verkeer met of tussen overheidsorganisaties of als dat voortvloeit uit internationale verplichtingen. |
| 6 | Voor diensten een is een betrouwbaarheidsniveau vastgesteld | Wet digitale overheid (nog niet in werking) | Op basis van de (voorgestelde) Wet digitale overheid zullen overheidsorganisaties verplicht worden voor hun elektronische diensten waarvoor veilige toegang nodig is, het betrouwbaarheidsniveau substantieel of hoog te gebruiken. Bij het zullen dienstverleners zich moeten houden aan nader Uitvoeringsregelgeving zal kaders bieden voor het bepalen van het bij de dienstverlening passende betrouwbaarheidsniveau. |
| 7 | Goedgekeurde identificatie- en authenticatiemiddelen worden geaccepteerd | Wet digitale overheid (nog niet in werking) | Vanuit het belang van het faciliteren van burgers en bedrijven en het belang van een veilige en betrouwbare identificatie- en authenticatieketen, verplicht dit wetsvoorstel overheidsorganisaties om bij elektronische dienstverlening de toegelaten identificatiemiddelen, erkende middelen en de bij de Europese Commissie genotificeerde middelen te accepteren, voor zover die middelen minimaal het voor de af te nemen dienst vereiste betrouwbaarheidsniveau ondersteunen. |
| 8 | Indiener ontvangt ontvangstbevestiging na indienen | Wet modernisering elektronisch bestuurlijk verkeer | Wanneer een overheidsorganisatie via elektronische weg een formeel bericht ontvangt (zoals een aanvraag voor een product of dienst), verstuurt het een ontvangstbevestiging. Dit tenzij de verzender en het bestuursorgaan gebruikmaken van hetzelfde systeem van gegevensverwerking, en de verzender kan zien dat het bericht door de overheidsorganisatie ontvangen is. Bovendien hoeft geen ontvangstbevestiging te worden verzonden als de afzender geen elektronisch adres heeft opgegeven waarop hij te bereiken is. Het bestuursorgaan moet daar wel naar vragen in het formulier. |
| 9 | Inzage in ingevulde gegevens | Wet modernisering elektronisch bestuurlijk verkeer | De overheidsorganisatie maakt door de indiener ingevulde gegevens aan die indiener beschikbaar. Deze inzagemogelijkheid dient beveiligd te zijn op een manier die passend is bij de vertrouwelijkheid en gevoeligheid van de verstrekte gegevens. |
| 10 | Verantwoording bij verzending en ontvangst berichten | Wet modernisering elektronisch bestuurlijk verkeer | Indien overheidsorganisaties gebruik maken van een MijnOmgeving of ander systeem waarin de burger of ondernemer toegang heeft tot door de overheid verzonden berichten, moet de overheidsorganisatie kunnen aantonen dat via dit systeem beschikbaar gestelde informatie is verzonden en (eventueel) ontvangen. Dit is geen verplichting om alles te loggen. De overheidsorganisatie kan zelf bepalen met welke gegevens in de meeste gevallen aan een bewijsplicht kan worden voldaan en het loggen beperken tot die gegevens. |
| 11 | Correctiegelegenheid na onjuiste indiening | Wet modernisering elektronisch bestuurlijk verkeer | Na ontvangst van een niet via de aangegeven weg ingediend bericht kan worden volstaan met de mededeling dat het bericht onjuist is ingediend en het wijzen op de juiste manier van indienen. In drie gevallen volstaat zo’n mededeling echter niet: |
| 12 | Toegankelijkheid websites en apps | Tijdelijk besluit digitale toegankelijkheid overheid en Wet digitale overheid (nog niet in werking) | Websites en mobiele apps van Nederlandse overheidsinstanties moeten voldoen aan de toegankelijkheidseisen volgens de Europese norm 301 549. Hierover moet verantwoording worden afgelegd in een toegankelijkheidsverklaring. Deze eisen gelden voor websites van overheidsorganisaties en mobiele applicaties. |
Bouwblokken digitale overheid[bewerken]
Mijn Overheid lopende zaken en federatief berichtenstelsel[bewerken]
Mijn Overheid Lopende Zaken dient hetzelfde doel als MijnZaken: gebruikers de voortgang van een aanvraag stap voor stap laten volgen. Maar de techniek verschilt sterk: Mijn Overheid Lopende Zaken werkt op basis van StUF-zaakberichten. Deze moeten op basis van het Digikoppeling ebMS-koppelvak aangeleverd worden. Hierbij is beveiliging met dubbelzijdig TLS en een PKIoverheid-certificaat noodzakelijk.
Omdat het berichtenverkeer van MijnOverheid, de BerichtenBox app, MijnGegevens app en het (formele) berichtenverkeer aan inwoners en ondernemers gaat veranderen, is het waarschijnlijk beter om vooruit te kijken en te bepalen hoe MijnZaken kan aansluiten bij ontwikkelingen rondom het Federatief Berichtenstelsel (FBS). Dat heeft tot doel om de digitale dienstverlening te verbeteren, het beheer goedkoper te maken en de toepassingen uit te bereiden.
Het generieke deel van het Federatief berichtenstelsel bestaat uit een aantal componenten, die hieronder zijn geïllustreerd.
Notificatieservice[bewerken]
In het kader van het FBS kunnen bestuursorganen notificatieopdrachten geven aan de centrale notificatieservice aangaande de publicatie van berichten. De notificatieservice verstuurt de notificatie(s) naar de geadresseerde en eventuele vertegenwoordigers conform de ingestelde kanalen en voorkeuren in de notificatieprofielen van de ontvangers van de notificatie. De centrale notificatieservice is een generiek component en wordt breder ingezet dan de taken voor het FBS.
Notificatieprofielen[bewerken]
De gebruikers beheren hun persoonlijke notificatievoorkeuren in het centrale notificatieprofiel. Hiervoor wordt de notificatieprofielservice ontsloten aan de interactielaag zodat de gebruikers kun profiel kunnen beheren. Het profiel kan vervolgens worden gebruikt door afnemende services waaronder de notificatieservice.
Notifcatieservices en gebeurtenisgedreven werken[bewerken]
Bij het aanvragen van een product en bij het behandelen van een productaanvraag bereikt het proces steeds een andere status. Een burger, bedrijf of instelling kan deze status zelf opvragen via verschillende kanalen.
Een ander patroon ontstaat als er een notificatie gestuurd wordt op basis van een gebeurtenis. Deze gebeurtenissen worden naar een centraal notificatierouteringscomponent gestuurd. Informatiesystemen kunnen zich abonneren op bepaalde gebeurtenissen. Op het moment dat er een gebeurtenis is opgetreden die relevant kan zijn voor een informatiesysteem, onderneemt dit informatiesysteem (op basis van regels) actie.
In het kader van MijnZaken-informatie kan een specifiek interactiecomponent geabonneerd zijn op gebeurtenissen die te maken hebben met een productaanvraagstatus of zaakstatus. Zodra een status van een zaak door een processysteem wordt gewijzigd, wordt de interactiecomponent daarvan op de hoogte gesteld. Het interactiecomponent kan op basis van die notificatie de gewenste gegevens ophalen en tonen aan de gebruiker.
Door de projectgroep Notificatieservices wordt gewerkt aan een ‘Nederlandse Notificatie Strategie’ . Bij de ontwikkeling hiervan zijn overheidsorganisaties uit de verschillende bestuurslagen betrokken. Verder wordt nadrukkelijk aansluiting gezocht bij wereldwijd gebruikte standaarden, zoals de CloudEvents specificatie. Naar verwachting leidt dit tot een API standaard die functioneel beschreven is en overheidsbreed toegepast kan worden.
Het toepassen van deze nieuwe standaard (in ontwikkeling) kan een meerwaarde bieden in de dienstverlening naar burgers, bedrijven en instellingen. Door opname van de referentiecomponent Notificatierouteringscomponent en bijhorende Notificaties API in de referentiearchitectuur MijnZaken is reeds rekening gehouden met deze nieuwe standaard.
Bijlagen
Dit hoofdstuk omvat de bijlagen bij de referentiearchitectuur MijnZaken, waarin onder andere de casussen die zijn gebruikt om deze architectuur vorm te geven nader zijn beschreven.
Overzicht generieke MijnZaken-componenten[bewerken]
Onderstaande afbeelding toont de generieke componenten en API’s die betrokken (kunnen) zijn bij het ontstaan of tonen van MijnZaken-informatie. Het betreft hier een verzameling van de componenten die voor de verschillende casussen benodigd kunnen zijn.
Om generieke interactiepatronen te kunnen vormgeven, toont bovenstaand model drie abstracte componenten, die hieronder nader worden toegelicht. Een nadere beschrijving van de meeste andere opgenomen componenten is te vinden in het overzicht van referentiecomponenten].
| Component | Beschrijving |
|---|---|
| Interactiecomponent voor het tonen van statusinformatie | De interactiecomponent voor het tonen van statusinformatie wordt gebruikt om via een specifiek kanaal statusinformatie bij lopende aanvragen van producten of diensten aan een burger, (vertegenwoordiger van een) bedrijf of medewerker te tonen. De interactiecomponent voor het tonen van statusinformatie is een abstract component. Dat betekent dat verschillende concrete componenten (zoals een Mijngemeentecomponent) de functies die horen bij de interactiecomponent voor het tonen van statusinformatie kunnen vervullen. |
| Kanaalspecifieke aanvraagcomponent | De kanaalspecifieke aanvraagcomponent ondersteunt het aanvragen van producten of diensten bij de gemeente via één of meerdere specifieke kanalen. De kanaalspecifieke aanvraagcomponent is een abstract component. Dat betekent dat verschillende concrete componenten (zoals een E-formulieren publicatie-en-beheercomponent) de functies die horen bij de Kanaalspecifieke aanvraagcomponent kunnen vervullen. |
| Procesondersteunende component | Abstract verzamelcomponent voor procesondersteunende systemen die zaakgericht zijn ingericht. |
Casussen[bewerken]
Casus MijnGemeente[bewerken]
Deze casus is beschreven voor gemeenten.
Burgers, bedrijven of instellingen die producten van de overheid afnemen, weten vaak niet (goed genoeg) wat de status van hun verzoek is of hoe lang het nog gaat duren voordat het product geleverd wordt. Het komt voor dat ze met meerdere organisaties contact moeten opnemen om dit te achterhalen – het bekende van het kastje naar de muur sturen. Met MijnZaken kunnen burgers en bedrijven de levering van producten en diensten volgen, ook als daarbij meerdere overheidsorganisaties betrokken zijn. Zij worden proactief en via een kanaal naar keuze geïnformeerd over die levering.
Een aantal gemeenten gaat een MijnGemeente-omgeving implementeren ter ondersteuning van de dienstverlening aan burgers en bedrijven. De basis hiervoor is het Integraal Klantbeeld, waarvan MijnZaken-informatie een onderdeel is. De scope van deze casus is groot genoeg om aan te kunnen tonen dat de uitgewerkte architectuur toegepast kan worden om burgers en ondernemers via een webportaal te informeren, en klein genoeg om de benodigde software en processen middels een beperkt aantal componenten in beperkte tijd te implementeren.
Casusbeschrijving[bewerken]
Een inwoner wil op een persoonlijke pagina van een gemeente (MijnGemeente portaal) een overzicht van relevante klantgegevens in samenhang zien. Hierbij worden alleen die gegevens getoond waartoe de inwoner geautoriseerd is. Het opvragen van de gegevens wordt vastgelegd ter verantwoording aan de inwoner. Wij denken op dit moment dat hiervoor onderstaande gegevens nodig zijn.
Relevante gegevens[bewerken]
- Naam- en contactgegevens
- Klantvoorkeuren
- Aangevraagde en geleverde producten
- Geleverde producten
- Lopende aanvragen inclusief status
- Bij aanvragen geleverde documenten
- Zaken
- Contactmomenten
- Gevoerde contacten
- Toekomstige afspraken
- Verwerkingenlogging-gegevens
Casus CRM[bewerken]
Deze casus is beschreven voor gemeenten.
Een goed geïnformeerde burger staat minder vaak aan de balie. En doordat overheidsorganisaties op een eenduidige manier informatie met elkaar delen, kunnen vragen worden beantwoord door een klantenservicemedewerker in plaats van de vakspecialist. Zij hebben daardoor meer tijd voor het leveren van goede dienstverlening en ondersteuning op maat. MijnZaken-informatie kan daarnaast worden gebruikt voor het bewaken van het verloop van (keten)processen en het bijsturen van de inrichting daarvan.
Een aantal organisaties gaat een CRM-platform implementeren. De basis hiervoor is het Integraal Klantbeeld, waarvan MijnZaken-informatie een onderdeel is. De scope van deze casus is groot genoeg om aan te kunnen tonen dat de uitgewerkte architectuur toegepast kan worden om KCC-medewerkers te ondersteunen bij het informeren van burgers en ondernemers, en klein genoeg om de benodigde software en processen middels een beperkt aantal componenten in beperkte tijd te implementeren.
Casusbeschrijving[bewerken]
Een medewerker van de gemeente wil inwoners goed voor kunnen lichten. Daarvoor is het nodig dat het CRM-platform een overzicht van relevante klantgegevens in samenhang toont. Hierbij worden alleen die gegevens getoond waartoe de medewerker geautoriseerd is. Het opvragen van de gegevens wordt vastgelegd ter verantwoording aan de inwoner. Wij denken op dit moment dat hiervoor onderstaande gegevens nodig zijn.
Relevante gegevens[bewerken]
- Naam- en contactgegevens
- Klantvoorkeuren
- Aangevraagde en geleverde producten
- Geleverde producten
- Lopende aanvragen inclusief status
- Bij aanvragen geleverde documenten
- Zaken
- Contactmomenten
- Gevoerde contacten
- Toekomstige afspraken
Statusuitwisseling tussen organisaties[bewerken]
Behandelaars van zaken waarvan de behandeling (deels) is uitbesteed aan externe organisaties hebben inzicht nodig in de voortgang van die behandeling door die externe organisaties. Bovendien komt het voor dat burgers, bedrijven of instellingen met meerdere organisaties contact moeten opnemen om te achterhalen hoe het er met hun aanvraag van een product of dienst voorstaat – het bekende van het kastje naar de muur sturen. Met MijnZaken kunnen medewerkers van overheidsorganisaties, burgers en bedrijven de levering van producten en diensten volgen, ook als daarbij meerdere overheidsorganisaties betrokken zijn. Zij worden proactief en via een kanaal naar keuze geïnformeerd over die levering.
Een aantal organisaties gaat een beperkte omgeving implementeren. De basis hiervoor is het Integraal Klantbeeld, waarvan MijnZaken-informatie een onderdeel is. De scope van deze casus is groot genoeg om aan te kunnen tonen dat de uitgewerkte architectuur over meerdere organisaties heen toegepast kan worden, en klein genoeg om de benodigde software en processen middels een beperkt aantal componenten in beperkte tijd te implementeren.
Casusbeschrijving[bewerken]
Twee overheidsorganisaties zijn betrokken bij de levering van één product of dienst aan een burger of ondernemer. Bij de eerste organisatie (de leverancier) wordt door een burger een product aangevraagd waarvoor een deelproduct van een tweede organisatie (de onderaannemer) aan de leverancier geleverd wordt.
De leverancier bestelt dit deelproduct bij de tweede organisatie. De onderaannemer geeft een notificatie aan de eerste organisatie door als een behandelstatus voor het deelproduct is veranderd. Op basis daarvan kan de leverancier de status van de behandeling van het deelproduct bij de onderaannemer opvragen. Voor deze casus denken wij dat de tenminste onderstaande gegevens nodig zijn.
Relevante gegevens[bewerken]
- Producten
- Overzicht te leveren producten door organisaties aan elkaar
- Aangevraagde en geleverde producten
- Lopende aanvragen inclusief status
- Bij aanvragen geleverde documenten
- Zaken (gestart door de onderaannemer naar aanleiding van aanvraag door leverancier)