Omnichannel MijnZaken compleet

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.

Figuur 1: Actoren en rollen betrokken bij het verstrekken en ontvangen van MijnZaken-informatie (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv


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:

  1. 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.
  2. 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.
  3. 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.
De voorkeur die een klant heeft met betrekking tot de dienstverlening. Dit kan bijvoorbeeld gaan over het gewenste communicatiekanaal of een taalinstelling. (BusinessObject) klantvoorkeur De toestemming die een klant gegeven heeft aan een gemeente om klantgegevens in te zien of te verwerken. (BusinessObject) toestemming BusinessObject mijnzaken-informatie De machtiging die een klant aan een ander natuurlijk persoon heeft verstrekt. (BusinessObject) machtiging Een gepland klantcontact tussen een klant en de gemeente. (BusinessObject) afspraak Een samenhangende hoeveelheid werk met gedefinieerde aanleiding en een gedefinieerd eindresultaat waarvan kwaliteit en doorlooptijd bewaakt moeten worden (BusinessObject) zaak Een natuurlijk persoon of niet-natuurlijk persoon waar een product/dienst wordt geleverd (BusinessObject) klant een mens (BusinessObject) natuurlijk persoon een rechtspersoon of een samenwerkingsverband (BusinessObject) niet-natuurlijk persoon De vastlegging van een verwerking in een logregistratie om de verwerking van objectgegevens te kunnen duiden. (BusinessObject) verwerkingenlog een tastbaar goed of verzameling activiteiten die door de gemeente geleverd kunnen worden (BusinessObject) product/dienst Een contactmoment met een klant dat relevant is voor de dienstverlening (BusinessObject) klantcontact Een clustering van medewerkers binnen de lijnorganisatie met een duidelijk gedefinieerde specifieke taakstelling (BusinessObject) organisatie-eenheid 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. (BusinessObject) document een beslissing over het wel of niet toekennen van [product/dienst] (BusinessObject) besluit een [natuurlijk persoon] met een tijdelijk of vaste [dienstbetrekking] of met een inhuurcontract met de gemeente (BusinessObject) medewerker Een vraag, melding of aanvraag voor een product/dienst door een klant (BusinessObject) verzoek AggregationRelationship AggregationRelationship AggregationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AggregationRelationship AggregationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AggregationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship AssociationRelationship Deze svg is op 27-03-2024 14:57:21 CET gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 27-03-2024 14:57:21 CET

Figuur 2: Bedrijfsobjecten betrokken bij het verstrekken en ontvangen van MijnZaken-informatie (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv


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

BusinessRole Afnemer van MijnZaken-informatie BusinessProcess Statusinformatie opvragen BusinessEvent Statusmelding ontvangen BusinessRole Aanbieder van MijnZaken-informatie BusinessService Levering MijnZaken-informatie De vastlegging van een verwerking in een logregistratie om de verwerking van objectgegevens te kunnen duiden. (BusinessObject) verwerkingenlog De voorkeur die een klant heeft met betrekking tot de dienstverlening. Dit kan bijvoorbeeld gaan over het gewenste communicatiekanaal of een taalinstelling. (BusinessObject) klantvoorkeur BusinessInterface Interactiekanaal De machtiging die een klant aan een ander natuurlijk persoon heeft verstrekt. (BusinessObject) machtiging BusinessEvent Status gewijzigd Een vraag, melding of aanvraag voor een product/dienst door een klant (BusinessObject) verzoek BusinessObject mijnzaken-informatie Het op aanvraag leveren van gemeentelijke producten en diensten. (BusinessProcess) Verstrekken producten en diensten BusinessProcess Uitvoeren intake BusinessProcess Toetsen indieningsvereisten BusinessProcess Behandelen inhoudelijk BusinessProcess Besluiten aanvraag BusinessProcess Leveren besluit BusinessEvent Aanvraag ontvangen Een samenhangende hoeveelheid werk met gedefinieerde aanleiding en een gedefinieerd eindresultaat waarvan kwaliteit en doorlooptijd bewaakt moeten worden (BusinessObject) zaak De toestemming die een klant gegeven heeft aan een gemeente om klantgegevens in te zien of te verwerken. (BusinessObject) toestemming een tastbaar goed of verzameling activiteiten die door de gemeente geleverd kunnen worden (BusinessObject) product/dienst Een natuurlijk persoon of niet-natuurlijk persoon waar een product/dienst wordt geleverd (BusinessObject) klant BusinessProcess Verstrekken MijnZaken-informatie AssociationRelationship wordt bepaald door AssignmentRelationship ServingRelationship ServingRelationship AssociationRelationship AccessRelationship - W AccessRelationship - W ServingRelationship AssociationRelationship AggregationRelationship AggregationRelationship AggregationRelationship TriggeringRelationship TriggeringRelationship TriggeringRelationship TriggeringRelationship TriggeringRelationship TriggeringRelationship TriggeringRelationship TriggeringRelationship TriggeringRelationship TriggeringRelationship AssociationRelationship AssociationRelationship AccessRelationship R AccessRelationship - W AccessRelationship R AccessRelationship R AccessRelationship R RealizationRelationship Deze svg is op 27-03-2024 14:57:22 CET gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 27-03-2024 14:57:22 CET

Figuur 3: Generieke illustratie van bedrijfsprocessen en -diensten die een rol spelen bij de verstrekking van

PDS-informatie (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv


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

Figuur 4: levering naar aanleiding van veranderde status (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv


Figuur 5: levering op aanvraag van burger (of andere (eind)afnemer) (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv


Figuur 6: levering op initiatief van burger (of andere (eind)afnemer) via Klantcontactcentrum van overheidsorganisatie (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv


Figuur 7: levering naar aanleiding van veranderde status bij ketenpartner via tweede overheidsorganisatie aan

(eind)afnemer (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv




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:

  1. 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).
  2. 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.
BusinessService Levering MijnZaken-informatie BusinessProcess Verstrekken MijnZaken-informatie ArchiMateNote Laag 4 - Proceslogica ApplicationProcess (Vertegenwoordiger van) bedrijf of instelling authentiseren en machtiging 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. (ApplicationProcess) Burger authentiseren en machtiging toetsen Alle beschikbare informatie over de status van levering van een door een burger aangevraagd(e) product of dienst wordt opgehaald en getoond. (ApplicationProcess) Status verzoeken en zaken tonen Klantgegevens en -voorkeuren van de burger die de aanvraag heeft ingediend worden op basis van een uniek identificerend gegeven (in dit geval het BSN) opgehaald. Daartoe wordt eerst het GBA-administratiecomponent bevraagd. Op basis van hetzelfde uniek identificerend gegeven worden aanvullende klantgegevens en klantvoorkeuren (zoals voorkeurskanalen) opgehaald uit het Klantenregister. (ApplicationProcess) Aanvullende klantgegevens ophalen Er wordt gecontroleerd of, en zo ja in welke mate de initiërende burger toestemming heeft gegeven voor inzage van (persoons)gegevens voor dit doel (dit voor zover deze gegevens niet op basis van een andere grondslag aan de medewerker mogen worden getoond). (ApplicationProcess) Klanttoestemmingen controleren ApplicationProcess Basisgegevens ophalen 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. (ApplicationProcess) Medewerker authentiseren en autoriseren RealizationRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship Deze svg is op 28-03-2024 12:29:10 CET gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 28-03-2024 12:29:10 CET

Figuur 8: relatie tussen bedrijfsproces ‘Verstrekken MijnZaken-informatie’ en bedrijfsdienst ‘MijnZaken’ en applicatieprocessen uit interactiediagrammen (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv


DataObject klanten DataObject bedrijven DataObject ingeschreven personen DataObject accounts DataObject rollen DataObject rolproductautorisaties DataObject toestemmingen DataObject statustypen DataObject zaken DataObject statussen DataObject zaakverzoeken De toestemming die een klant gegeven heeft aan een gemeente om klantgegevens in te zien of te verwerken. (BusinessObject) toestemming Een natuurlijk persoon of niet-natuurlijk persoon waar een product/dienst wordt geleverd (BusinessObject) klant een mens (BusinessObject) natuurlijk persoon een rechtspersoon of een samenwerkingsverband (BusinessObject) niet-natuurlijk persoon Een clustering van medewerkers binnen de lijnorganisatie met een duidelijk gedefinieerde specifieke taakstelling (BusinessObject) organisatie-eenheid een [natuurlijk persoon] met een tijdelijk of vaste [dienstbetrekking] of met een inhuurcontract met de gemeente (BusinessObject) medewerker DataObject afdelingen Een samenhangende hoeveelheid werk met gedefinieerde aanleiding en een gedefinieerd eindresultaat waarvan kwaliteit en doorlooptijd bewaakt moeten worden (BusinessObject) zaak DataObject verzoekproducten DataObject verzoeken DataObject klantverzoeken Een vraag, melding of aanvraag voor een product/dienst door een klant (BusinessObject) verzoek DataObject producten een tastbaar goed of verzameling activiteiten die door de gemeente geleverd kunnen worden (BusinessObject) product/dienst De voorkeur die een klant heeft met betrekking tot de dienstverlening. Dit kan bijvoorbeeld gaan over het gewenste communicatiekanaal of een taalinstelling. (BusinessObject) klantvoorkeur De machtiging die een klant aan een ander natuurlijk persoon heeft verstrekt. (BusinessObject) machtiging De vastlegging van een verwerking in een logregistratie om de verwerking van objectgegevens te kunnen duiden. (BusinessObject) verwerkingenlog DataObject verwerkingsacties RealizationRelationship RealizationRelationship RealizationRelationship RealizationRelationship RealizationRelationship AssociationRelationship AssociationRelationship RealizationRelationship RealizationRelationship RealizationRelationship RealizationRelationship RealizationRelationship RealizationRelationship RealizationRelationship RealizationRelationship RealizationRelationship RealizationRelationship RealizationRelationship RealizationRelationship RealizationRelationship Deze svg is op 28-03-2024 12:29:12 CET gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 28-03-2024 12:29:12 CET

Figuur 9: relatie tussen bedrijfsobjecten en in interactiediagrammen geraadpleegde of gewijzigde gegevensobjecten (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv


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:

  1. 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’.
  2. 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’.
  3. 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’.
  4. Klantgegevens ophalen – beschrijft hoe contactgegevens en klantvoorkeuren (bijvoorbeeld een voorkeurskanaal) worden opgehaald.
  5. 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).
  6. 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.

ArchiMateNote Laag 2 - Diensten Applicatieservice voor het authenticeren van burgers (ApplicationService) DigiD authenticatieservice ApplicationService DigiD Machtigen ArchiMateNote Laag 3 - Integratie ArchiMateNote Laag 4 - Proceslogica 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. (ApplicationProcess) Burger authentiseren en machtiging toetsen ArchiMateNote Laag 5 - Interactie 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 medeweker 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 het Kanaalspecifiek aanvraagcomponent kunnen vervullen. (ApplicationComponent) Interactiecomponent voor het tonen van statusinformatie (abstracte component) ArchiMateNote Laag 1 - Gegevens ServingRelationship ServingRelationship ServingRelationship Deze svg is op 28-03-2024 12:29:12 CET gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 28-03-2024 12:29:12 CET

Figuur 10: Interactiediagram ‘burger authenticeren en machtigingen toetsen’ (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv


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.

Figuur 11: Interactiediagram ‘(Vertegenwoordiger van) bedrijf of instelling authenticeren en machtigingen

toetsen’ (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv


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.
ArchiMateNote Laag 1 - Gegevens Component voor de opslag en ontsluiting van identiteiten van gebruikers en de rechten die zij hebben. (ApplicationComponent) Gebruikersbeheercomponent DataObject accounts DataObject rollen DataObject rolproductautorisaties DataObject afdelingen ArchiMateNote Laag 2 - Diensten ApplicationInterface Gebruikersbeheer API ArchiMateNote Laag 3 - Integratie ArchiMateNote Laag 4 - Proceslogica 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. (ApplicationProcess) Medewerker authentiseren en autoriseren ArchiMateNote Laag 5 - Interactie 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 medeweker 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 het Kanaalspecifiek aanvraagcomponent kunnen vervullen. (ApplicationComponent) Interactiecomponent voor het tonen van statusinformatie (abstracte component) AccessRelationship R CompositionRelationship AccessRelationship R AccessRelationship R AccessRelationship R ServingRelationship ServingRelationship Deze svg is op 28-03-2024 03:37:07 CET gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 28-03-2024 03:37:07 CET

Figuur 12: Interactiediagram ‘Medewerker authenticeren en autoriseren’ (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv


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.
ArchiMateNote Laag 1 - Gegevens DataObject bedrijven DataObject ingeschreven personen ApplicationComponent Handelsregister Component voor uitvoering van de gemeentelijke taken rondom de registratie van persoonsgegevens. (ApplicationComponent) GBA- administratiecompon- ent Component voor opslag en ontsluiting van klantgegevens. (ApplicationComponent) Klantregistratiecomp- onent DataObject klanten ArchiMateNote Laag 2 - Diensten ApplicationInterface Handelsregister API De Klanten API standaardiseert het creëren, bijwerken, lezen en verwijderen van klantgegevens. (ApplicationInterface) Klanten API ApplicationInterface Bevraging Ingeschreven Persoon API ArchiMateNote Laag 3 - Integratie ArchiMateNote Laag 4 - Proceslogica ApplicationProcess Basisgegevens ophalen Klantgegevens en -voorkeuren van de burger die de aanvraag heeft ingediend worden op basis van een uniek identificerend gegeven (in dit geval het BSN) opgehaald. Daartoe wordt eerst het GBA-administratiecomponent bevraagd. Op basis van hetzelfde uniek identificerend gegeven worden aanvullende klantgegevens en klantvoorkeuren (zoals voorkeurskanalen) opgehaald uit het Klantenregister. (ApplicationProcess) Aanvullende klantgegevens ophalen ArchiMateNote Laag 5 - Interactie 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 medeweker 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 het Kanaalspecifiek aanvraagcomponent kunnen vervullen. (ApplicationComponent) Interactiecomponent voor het tonen van statusinformatie (abstracte component) CompositionRelationship AccessRelationship R AccessRelationship R CompositionRelationship AccessRelationship R CompositionRelationship ServingRelationship ServingRelationship ServingRelationship ServingRelationship TriggeringRelationship ServingRelationship Deze svg is op 28-03-2024 12:29:13 CET gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 28-03-2024 12:29:13 CET

Figuur 13: Interactiediagram ‘Klantgegevens ophalen’ (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv


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.

Figuur 14: Interactiediagram ‘Klanttoestemmingen controleren’ (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv


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).
ArchiMateNote Laag 1 - Gegevens DataObject statustypen DataObject zaken DataObject statussen DataObject producten Component voor het onderhouden van gegevens over producten en diensten en het (interactief) presenteren daarvan aan burgers en bedrijven. (ApplicationComponent) Producten-en- dienstencatalogusco- mponent Component voor opslag en ontsluiting van zaaktypegegevens. (ApplicationComponent) Zaaktypecatalogusco- mponent DataObject zaakverzoeken DataObject verzoekproducten DataObject verzoeken ApplicationComponent Verzoekenregister Component voor opslag en ontsluiting van zaakgegevens. (ApplicationComponent) Zaakregistratiecomponent DataObject klantverzoeken ArchiMateNote Laag 2 - Diensten De Zaken API standaardiseert het creëren, bijwerken, lezen en verwijderen van zaakgegevens. (ApplicationInterface) Zaken API De Verzoeken API standaardiseert het creëren, bijwerken, lezen en verwijderen van verzoekgegevens. (ApplicationInterface) Verzoeken API ApplicationInterface Catalogi API ApplicationInterface Producten en Diensten API ArchiMateNote Laag 3 - Integratie ArchiMateNote Laag 4 - Proceslogica Op basis van een relatie met klant 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 opgehaald (zoals een beschrijving en behandeltermijnen) en getoond. (ApplicationProcess) Verzoekgegevens 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 verzoeken 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. (ApplicationProcess) Zaakgegevens tonen Alle beschikbare informatie over de status van levering van een door een burger aangevraagd(e) product of dienst wordt opgehaald en getoond. (ApplicationProcess) Status verzoeken en zaken tonen ArchiMateNote Laag 5 - Interactie 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 medeweker 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 het Kanaalspecifiek aanvraagcomponent kunnen vervullen. (ApplicationComponent) Interactiecomponent voor het tonen van statusinformatie (abstracte component) AccessRelationship R CompositionRelationship AccessRelationship R CompositionRelationship AccessRelationship R CompositionRelationship AccessRelationship R AccessRelationship R CompositionRelationship AccessRelationship RW AccessRelationship R AccessRelationship R ServingRelationship ServingRelationship ServingRelationship ServingRelationship TriggeringRelationship AggregationRelationship ServingRelationship AggregationRelationship Deze svg is op 28-03-2024 12:29:14 CET gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 28-03-2024 12:29:14 CET

Figuur 15:Interactiediagram ‘Status lopende aanvragen en zaken tonen’ (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv


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:
    1. uw naam en contactgegevens;
    2. de naam en contactgegevens van partijen waarmee u gezamenlijke verwerkingsverantwoordelijke bent;
    3. 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.

Register voor het centraal vastleggen van gegevens over de activiteiten die gebruikers uitvoeren met vertrouwelijke gegevens. (ApplicationComponent) Verwerkingenloggingregister API voor het loggen, opvragen, wijzigingen en verwijderen van verwerkingsacties (ApplicationInterface) Verwerkingenlogging Bewerking API ApplicationComponent Gegevensregister Als een Gegevensregister gegevens bewerkt in opdracht van een Procesapplicatie, worden de waarden van de attributen uit de HTTP header van de aangeroepen API overgenomen en verwerkt in de payload van de Verwerkingenlogging Bewerrking API. Onderstaande attributen uit de HTTP header worden overgenomen in de attributen van de Verwerkingenlogging Bewerking API. * Het OIN in het attribuut Afnemer. * Het UUID van de verwerkingsactiviteit in het attribuut Verwerkingsactiviteit ID afnemer. * De URL van de verwerkingsactiviteit in het attribuut Verwerkingsactiviteit URL afnemer. * Het UUID van de verwerking in het attribuut Verwerking ID afnemer. * De vertrouwelijkheid en bewaartermijn in hun gelijknamige attributen. (ApplicationFunction) Vastleggen verwerkingsactie ApplicationProcess Opvragen doelbinding ApplicationProcess Vastleggen verwerkingsactiviteit ApplicationFunction Opvragen doelbinding ApplicationEvent Verzoek bewerken registergegevens ApplicationProcess Bewerken registergegevens DataObject Registergegevens ApplicationFunction Bewerken registergegevens ApplicationEvent Registergegevens bewerkt Aanname is dat de gemeente beschikt over een verwerkingsactiviteitenregister (VAR). In dit register zijn alle verwerkingsactiviteiten voorzien van een wereldwijd uniek nummer, een zogenaamde ‘Universal Unique Identifier’ afgekort UUID. Niet alle verwrkingsactiviteiten hoeven van belang te zijn voor de verwerking van persoonsgegevens in een specifieke procesapplicatie. Het ligt dan ook voor de hand dat een deel van het VAR wordt overgenomen naar de procesapplicatie. De verwerkingsactiviteten kunnen dan gekoppeld worden aan specifieke fionctionele uitvoeringstaken binnen de procesapplicatie. De combinatie van een specifieke verwerkingsactiviteit en een specifieke bewerkingsfunctionaliteit binnen de procesapplicatie wordt een doelbinding genoemd. Dit dataobject bevat de geregistreerde doelbindingen. (DataObject) Doelbinding Bij de provider wordt deze informatie bij verwerkingenlogging opgenomen in de volgende attributen: * Het OIN in het attribuut Afnemer. * Het UUID van de verwerkingsactiviteit in het attribuut Verwerkingsactiviteit ID afnemer. * De URL van de verwerkingsactiviteit in het attribuut Verwerkingsactiviteit URL afnemer. * Het UUID van de verwerking in het attribuut Verwerking ID afnemer. * De vertrouwelijkheid en bewaartermijn in hun gelijknamige attributen. (ApplicationFunction) Overnemen HTTP headers ApplicationInterface Gegevensregister API Als een consumer een provider gaat bevragen, moet de provider de eigen acties ook vastleggen in de Verwerkingenloggingcomponent. De verantwoording voor het uitvoeren van de actie door de provider wordt door de consumer meegegeven in de HTTP header van de aangeroepen Gegevensregister API . De waarden van die attributen worden dan later door de provider vastgelegd in de Verwerkingenloggingcomponent. Deze informatie wordt in de HTTP header van het bericht meegegeven en dus niet in de payload. De HTTP header omvat de volgende velden: * Het OIN van de consumer. * Het UUID van de verwerkingsactiviteit die bij de consumer de verwerking rechtvaardigt. * De URL van de verwerkingsactiviteit die bij de consumer de verwerking rechtvaardigt. * Het UUID van de verwerking die bij de consumer de reden is om de API aan te roepen. * De vertrouwelijkheid van de verwerking van de consumer. * De bewaartermijn van de verwerking van de consumer. (DataObject) HTTP header Verwerkingenlogging Abstract verzamelcomponent voor procesondersteunende systemen die zaakgericht zijn ingericht. (ApplicationComponent) Procesondersteunende component (abstract component) ApplicationEvent Bewerken gegevens ApplicationProcess Opvragen doelbinding ApplicationFunction Opvragen doelbinding Aanname is dat de gemeente beschikt over een verwerkingsactiviteitenregister (VAR). In dit register zijn alle verwerkingsactiviteiten voorzien van een wereldwijd uniek nummer, een zogenaamde ‘Universal Unique Identifier’ afgekort UUID. Niet alle verwrkingsactiviteiten hoeven van belang te zijn voor de verwerking van persoonsgegevens in een specifieke procesapplicatie. Het ligt dan ook voor de hand dat een deel van het VAR wordt overgenomen naar de procesapplicatie. De verwerkingsactiviteten kunnen dan gekoppeld worden aan specifieke fionctionele uitvoeringstaken binnen de procesapplicatie. De combinatie van een specifieke verwerkingsactiviteit en een specifieke bewerkingsfunctionaliteit binnen de procesapplicatie wordt een doelbinding genoemd. Dit dataobject bevat de geregistreerde doelbindingen. (DataObject) Doelbinding ApplicationProcess Vastleggen verwerkingsactiviteit ApplicationProcess Bewerken gegevens Als een Gegevensregister gegevens bewerkt in opdracht van een Procesapplicatie, worden de waarden van de attributen uit de HTTP header van de aangeroepen API overgenomen en verwerkt in de payload van de Verwerkingenlogging Bewerrking API. Onderstaande attributen uit de HTTP header worden overgenomen in de attributen van de Verwerkingenlogging Bewerking API. * Het OIN in het attribuut Afnemer. * Het UUID van de verwerkingsactiviteit in het attribuut Verwerkingsactiviteit ID afnemer. * De URL van de verwerkingsactiviteit in het attribuut Verwerkingsactiviteit URL afnemer. * Het UUID van de verwerking in het attribuut Verwerking ID afnemer. * De vertrouwelijkheid en bewaartermijn in hun gelijknamige attributen. (ApplicationFunction) Vastleggen verwerkingsactie Als een Procesapplicatie de Gegevensregister API van de Gegevensregister aanroept, wordt onderstaande informatie meegegeven in de HTTP header van het bericht: * Het OIN van de consumer. * Het UUID van de verwerkingsactiviteit die bij de consumer de verwerking rechtvaardigt. * De URL van de verwerkingsactiviteit die bij de consumer de verwerking rechtvaardigt. * Het UUID van de verwerking die bij de consumer de reden is om de API aan te roepen. * De vertrouwelijkheid van de verwerking van de consumer. * De bewaartermijn van de verwerking van de consumer. * Deze informatie wordt in de header van het bericht meegegeven en dus niet in de payload. (ApplicationFunction) Bewerken gegevens ApplicationEvent Gegevens bewerkt ServingRelationship ServingRelationship ServingRelationship TriggeringRelationship TriggeringRelationship ServingRelationship AccessRelationship R TriggeringRelationship TriggeringRelationship AccessRelationship RW ServingRelationship ServingRelationship ServingRelationship TriggeringRelationship TriggeringRelationship AccessRelationship R ServingRelationship TriggeringRelationship TriggeringRelationship ServingRelationship ServingRelationship AssociationRelationship Deze svg is op 19-04-2023 18:46:53 CEST gegenereerd door ArchiMedes™ © 2016-2023 ArchiXL. ArchiMedes 19-04-2023 18:46:53 CEST

Figuur 16:Interactiediagram waarbij een dienstenafnemer gegevens opvraagt bij een dienstenaanbieder (uit model: Logging en verwerkingen) - Toon SVG - Download als csv


Register voor het centraal vastleggen van gegevens over de activiteiten die gebruikers uitvoeren met vertrouwelijke gegevens. (ApplicationComponent) Verwerkingenloggingregister API voor het loggen, opvragen, wijzigingen en verwijderen van verwerkingsacties (ApplicationInterface) Verwerkingenlogging Bewerking API Abstract verzamelcomponent voor procesondersteunende systemen die zaakgericht zijn ingericht. (ApplicationComponent) Procesondersteunende component (abstract component) ApplicationProcess Opvragen doelbinding ApplicationFunction Opvragen doelbinding Aanname is dat de gemeente beschikt over een verwerkingsactiviteitenregister (VAR). In dit register zijn alle verwerkingsactiviteiten voorzien van een wereldwijd uniek nummer, een zogenaamde ‘Universal Unique Identifier’ afgekort UUID. Niet alle verwrkingsactiviteiten hoeven van belang te zijn voor de verwerking van persoonsgegevens in een specifieke procesapplicatie. Het ligt dan ook voor de hand dat een deel van het VAR wordt overgenomen naar de procesapplicatie. De verwerkingsactiviteten kunnen dan gekoppeld worden aan specifieke fionctionele uitvoeringstaken binnen de procesapplicatie. De combinatie van een specifieke verwerkingsactiviteit en een specifieke bewerkingsfunctionaliteit binnen de procesapplicatie wordt een doelbinding genoemd. Dit dataobject bevat de geregistreerde doelbindingen. (DataObject) Doelbinding ApplicationProcess Vastleggen verwerkingsactiviteit Als een Gegevensregister gegevens bewerkt in opdracht van een Procesapplicatie, worden de waarden van de attributen uit de HTTP header van de aangeroepen API overgenomen en verwerkt in de payload van de Verwerkingenlogging Bewerrking API. Onderstaande attributen uit de HTTP header worden overgenomen in de attributen van de Verwerkingenlogging Bewerking API. * Het OIN in het attribuut Afnemer. * Het UUID van de verwerkingsactiviteit in het attribuut Verwerkingsactiviteit ID afnemer. * De URL van de verwerkingsactiviteit in het attribuut Verwerkingsactiviteit URL afnemer. * Het UUID van de verwerking in het attribuut Verwerking ID afnemer. * De vertrouwelijkheid en bewaartermijn in hun gelijknamige attributen. (ApplicationFunction) Vastleggen verwerkingsactie ApplicationEvent Loggegevens opvragen ApplicationEvent Loggegevens opgevraagd ApplicationProcess Opvragen loggegevens ApplicationFunction Opvragen loggegevens Register voor het centraal vastleggen van gegevens over de activiteiten die gebruikers uitvoeren met vertrouwelijke gegevens. (ApplicationComponent) Verwerkingenloggingregister API voor het opvragen van verwerkingsacties (ApplicationInterface) Verwerkingenlogging Inzage API Deze functie is een verzameling van meerdere functies die betrekking hebben op het opvragen een verwerkingsacties. Afhankelijk van de gewenste set aan gegevens wordt een specifieke functie gebruikt. Bij de functies 'Opvragen Verwerkingsacties - Alle velden, niet vertrouwelijk', de functie 'Opvragen Verwerkingsacties - Alle velden, vertrouwelijk' en de functie 'Opvragen Verwerkingsacties - Alle velden, vertrouwelijkheid opgeheven' worden alle velden teruggeven. Alleen een bevoegde functionaris zoals bijvoorbeeld een behandelend ambtenaar of een Privacy Officer zou hiervoor geautoriseerd mogen worden. De ‘niet vertrouwelijke’ functie retourneert alleen verwerkingsacties over verwerkingen die niet vertrouwelijk zijn en die dit ook nooit geweest zijn. De ‘vertrouwelijkheid opgeheven’ functie retourneert ook verwerkingsacties die ooit vertrouwelijk geweest zijn. Verwerkingsacties acties die ooit vertrouwelijk waren, moet ook na het opheffen van die vertrouwelijkheid vaak gezien worden als ‘bijzondere persoonsgegevens’. Denk aan een fraudeonderzoek. Zelfs als een dergelijk onderzoek uiteindelijk niets opgeleverd heeft, kan het aantreffen van verwerkingsacties over een onderzoek leiden tot een vooroordeel. Ook deze functies mogen dus alleen door bevoegde functionarissen zoals Privacy Officers of door de betrokkenen zelf gebruikt worden. (ApplicationFunction) Opvragen verwerkingenlogging ApplicationProcess Controleren autorisatie ApplicationEvent Verzoek opvragen log ApplicationEvent Opvragen log gereed ApplicationProcess Opvragen log * De functie retourneert alle verwerkingsacties die over de opgegeven persoon gelogd zijn in de opgevraagde periode. * De functie retourneert alleen actuele verwerkingsacties. Er worden geen historische of vervallen verwerkingsacties geretourneerd. * Indien een verwerkingsactiviteit opgegeven is worden alleen verwerkingsacties geretourneerd die onder deze verwerkingsactiviteit gelogd zijn. * De functie retourneert ook verwerkingsacties die vertrouwelijk waren. * De attributen Systeem, Gebruiker en Gegevensbron worden niet geretourneerd. (ApplicationFunction) Opvragen Verwerkingsacties – Beperkte set velden, niet vertrouwelijk, vertrouwelijkheid opgeheven Bij de provider wordt deze informatie bij verwerkingenlogging opgenomen in de volgende attributen: * Het OIN in het attribuut Afnemer. * Het UUID van de verwerkingsactiviteit in het attribuut Verwerkingsactiviteit ID afnemer. * De URL van de verwerkingsactiviteit in het attribuut Verwerkingsactiviteit URL afnemer. * Het UUID van de verwerking in het attribuut Verwerking ID afnemer. * De vertrouwelijkheid en bewaartermijn in hun gelijknamige attributen. (ApplicationFunction) Overnemen HTTP headers ApplicationProcess Loggen verwerkingsactie Een verwerkingsactie is een operatie die wordt uitgevoerd door een geautomatiseerd systeem waarbij er (persoons)gegevens verwerkt worden. Een verwerkingsactie wordt uitgevoerd als onderdeel van (een handeling van) een verwerking. Het dataobject Verwerkingsacties bevast de registraties van de verwerkingsacties. (DataObject) Verwerkingacties Deze functie is een verzameling van meerdere functies die betrekking hebben op het vastleggen van een verwerkingsactie. Voor het vastleggen van verwerkingsacties die geen autorisatie vereisen, wordt de functie 'log verwerkingsactie' gebruikt. Voor verwerkingsacties die wel autorisatie vereisen, wordt de functie 'Log vertrouwelijke verwerkingsactie' gebruikt. (ApplicationFunction) Loggen verwerkingenlogging Als een consumer een provider gaat bevragen, moet de provider de eigen acties ook vastleggen in de Verwerkingenloggingcomponent. De verantwoording voor het uitvoeren van de actie door de provider wordt door de consumer meegegeven in de HTTP header van de aangeroepen Gegevensregister API . De waarden van die attributen worden dan later door de provider vastgelegd in de Verwerkingenloggingcomponent. Deze informatie wordt in de HTTP header van het bericht meegegeven en dus niet in de payload. De HTTP header omvat de volgende velden: * Het OIN van de consumer. * Het UUID van de verwerkingsactiviteit die bij de consumer de verwerking rechtvaardigt. * De URL van de verwerkingsactiviteit die bij de consumer de verwerking rechtvaardigt. * Het UUID van de verwerking die bij de consumer de reden is om de API aan te roepen. * De vertrouwelijkheid van de verwerking van de consumer. * De bewaartermijn van de verwerking van de consumer. (DataObject) HTTP header Verwerkingenlogging ServingRelationship TriggeringRelationship AccessRelationship R ServingRelationship TriggeringRelationship ServingRelationship TriggeringRelationship TriggeringRelationship ServingRelationship ServingRelationship TriggeringRelationship Niet geautoriseerd TriggeringRelationship Geautoriseerd TriggeringRelationship TriggeringRelationship ServingRelationship AccessRelationship R ServingRelationship TriggeringRelationship Verwerkingsa- ctie niet gelogd TriggeringRelationship Verwerkingsa- ctie gelogd ServingRelationship AssociationRelationship Deze svg is op 19-04-2023 18:46:54 CEST gegenereerd door ArchiMedes™ © 2016-2023 ArchiXL. ArchiMedes 19-04-2023 18:46:54 CEST

Interactiediagram waarbij loggegevens worden opgevraagd uit het verwerkingenloggingregister (uit model: Logging en verwerkingen) - Toon SVG - Download als csv




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:
  • actueel;
  • begrijpelijk, en
  • compleet.

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:
  1. als het bericht zonder nadere bewerking kan worden behandeld
  2. als het bericht een bezwaarschrift of een administratief beroepschrift is, of
  3. als voor het bericht in kwestie geen wijze van indiening was aangewezen (dan kan de burger niet worden verweten dat hij een fout heeft gemaakt).
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.

Generieke componenten binnen het Federatief berichtenstelsel

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.

ArchiMateNote Laag 4 - Proceslogica ApplicationComponent Processturingcompo- nent ArchiMateNote Laag 3 - Integratie Component voor het routeren, transformeren en eventueel orkestreren van berichten tussen applicaties. (ApplicationComponent) Servicebuscomponent Een toegangspunt voor API's dat verzoekverwerking uitvoert op basis van gedefinieerd beleid inclusief authenticatie, autorisatie, toegangscontrole, SSL/TLS-offloading, routering en load-balancing. (ApplicationComponent) API Gatewaycomponent ArchiMateNote Laag 2 - Diensten De Verzoeken API standaardiseert het creëren, bijwerken, lezen en verwijderen van verzoekgegevens. (ApplicationInterface) Verzoeken API De Zaken API standaardiseert het creëren, bijwerken, lezen en verwijderen van zaakgegevens. (ApplicationInterface) Zaken API De Besluiten API standaardiseert het creëren, bijwerken, lezen en verwijderen van besluitgegevens. (ApplicationInterface) Besluiten API De Contactmomenten API standaardiseert het creëren, bijwerken, lezen en verwijderen van gegevens die een contactmoment beschrijven. (ApplicationInterface) Contactmomenten API API voor het loggen, opvragen, wijzigingen en verwijderen van verwerkingsacties (ApplicationInterface) Verwerkingenlogging API ApplicationInterface Toestemmingen API ApplicationInterface Afspraken API ApplicationInterface Gebruikersbeheer API ApplicationInterface Producten en Diensten API ApplicationInterface Catalogi API De Documenten API standaardiseert het creëren, bijwerken, lezen en verwijderen van informatieobjecten en bijbehorende metagegevens. (ApplicationInterface) Documenten API De Klanten API standaardiseert het creëren, bijwerken, lezen en verwijderen van klantgegevens. (ApplicationInterface) Klanten API ApplicationInterface Bevraging Ingeschreven Persoon API ApplicationInterface Objecttypen API ArchiMateNote Laag 1 - Gegevens Component voor de opslag en ontsluiting van identiteiten van gebruikers en de rechten die zij hebben. (ApplicationComponent) Gebruikersbeheerco- mponent Component voor uitvoering van de gemeentelijke taken rondom de registratie van persoonsgegevens. (ApplicationComponent) GBA- administratiecompon- ent ApplicationComponent Verzoekenregister Component voor opslag en ontsluiting van zaakgegevens. (ApplicationComponent) Zaakregistratiecomp- onent Component voor opslag en ontsluiting van besluitgegevens. (ApplicationComponent) Besluitregistratiecom- ponent Component voor het maken van afspraken tussen burgers, bedrijven en ambtenaren. (ApplicationComponent) Afsprakenbeheercom- ponent ApplicationComponent Contactmomentenre- gister Component voor het centraal vastleggen van gegevens over de activiteiten die gebruikers uitvoeren met vertrouwelijke gegevens. (ApplicationComponent) Verwerkingenloggin- gcomponent ApplicationComponent Toestemmingenregis- ter Component voor het onderhouden van gegevens over producten en diensten en het (interactief) presenteren daarvan aan burgers en bedrijven. (ApplicationComponent) Producten-en- dienstencatalogusco- mponent Component voor opslag en ontsluiting van zaaktypegegevens. (ApplicationComponent) Zaaktypecatalogusco- mponent Component voor opslag en ontsluiting van documenten en daarbij behorende metadata. (ApplicationComponent) Documentregistratie- component Component voor opslag en ontsluiting van klantgegevens. (ApplicationComponent) Klantregistratiecomp- onent Component voor ontvangen van notificaties van bronsystemen en het routeren daarvan naar geabonneerde afnemers. (ApplicationComponent) Notificatierouteringc- omponent ApplicationComponent Objecttypenregister ArchiMateNote Laag 3 - Landelijke integratie ApplicationComponent Landelijke integratiecomponent ArchiMateNote Laag 2 - Landelijke diensten Applicatieservice voor het authenticeren van burgers (ApplicationService) DigiD authenticatieservice ApplicationService DigiD Machtigen Landelijk systeem voor authenticatie van bedrijven inclusief bijbehorend machtigingen register. (ApplicationService) eHerkenning authenticatie en machtigingenservice ArchiMateNote Laag 5 - Interactie Component voor het ontwikkelen, publiceren, laten invullen, indienen en bevestigen van elektronische formulieren. (ApplicationComponent) E-formulieren publicatie-en- beheercomponent 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 medeweker 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 het Kanaalspecifiek aanvraagcomponent kunnen vervullen. (ApplicationComponent) Interactiecomponent voor het tonen van statusinformatie (abstracte component) De kanaalspecifieke aanvraagcomponent ondersteunt het aanvragen van producten of diensten bij de gemeente via één of meerdere specifeke 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 het Kanaalspecifiek aanvraagcomponent kunnen vervullen. (ApplicationComponent) Kanaalspecifieke aanvraagcomponent (abstracte component) Component die via webtechnologie veilig toegang biedt tot persoonlijke informatie en gepersonaliseerde digitale dienstverlening. (ApplicationComponent) Mijngemeentecompo- nent ApplicationComponent Chatcomponent Component voor het ontvangen en versturen van berichten binnen sociale media waarbij met persoonlijke voorkeuren rekening wordt gehouden. (ApplicationComponent) Sociale mediacomponent Component voor het onderhouden van relaties met klanten of organisaties. (ApplicationComponent) Relatiebeheercompo- nent (CRM) ApplicationComponent Klantcontactcentrum- component ApplicationComponent E-mailcomponent Component voor het aanmaken van documenten waarbij vaste teksten/templates worden gecombineerd met gegevens. (ApplicationComponent) Documentcreatieco- mponent ApplicationComponent Specifiek procesafhandelcomp- onent Abstract verzamelcomponent voor procesondersteunende systemen die zaakgericht zijn ingericht. (ApplicationComponent) Zaakafhandelcompo- nent (abstract component) ArchiMateNote Laag 1 - Landelijke gegevens SpecializationRelationship SpecializationRelationship SpecializationRelationship SpecializationRelationship SpecializationRelationship SpecializationRelationship SpecializationRelationship SpecializationRelationship SpecializationRelationship SpecializationRelationship Deze svg is op 28-03-2024 04:39:06 CET gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 28-03-2024 04:39:06 CET

Figuur 18: Overzicht generieke componenten (uit model: Projectmodel Referentiearchitectuur Omnichannel) - Toon SVG - Download als csv


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
    • Afgeronde zaken
    • Lopende zaken inclusief inzage in status en behandelaar
    • Documenten bij een zaak
    • Besluiten genomen bij een zaak
  • 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
    • Afgeronde zaken
    • Lopende zaken inclusief inzage in status en behandelaar
    • Documenten bij een zaak
    • Besluiten genomen bij een zaak
  • 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)
    • Lopende zaken inclusief inzage in status en behandelaar
    • Documenten bij een zaak
    • Besluiten genomen bij een zaak



Deze pagina is het laatst bewerkt op 20 okt 2023 om 01:01.