Omnichannel MijnZaken 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 29-05-2024 14:51:51 CEST gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 29-05-2024 14:51:51 CEST
Figuur 8: relatie tussen bedrijfsproces ‘Verstrekken MijnZaken-informatie’ en bedrijfsdienst ‘MijnZaken’ en applicatieprocessen uit interactiediagrammen (open view in nieuw venster)
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 29-05-2024 14:51:52 CEST gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 29-05-2024 14:51:52 CEST
Figuur 9: relatie tussen bedrijfsobjecten en in interactiediagrammen geraadpleegde of gewijzigde gegevensobjecten (open view in nieuw venster)

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 29-05-2024 14:51:52 CEST gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 29-05-2024 14:51:52 CEST
Figuur 10: Interactiediagram ‘burger authenticeren en machtigingen toetsen’ (open view in nieuw venster)
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’ (open view in nieuw venster)
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 29-05-2024 14:51:53 CEST gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 29-05-2024 14:51:53 CEST
Figuur 12: Interactiediagram ‘Medewerker authenticeren en autoriseren’ (open view in nieuw venster)
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 29-05-2024 12:41:42 CEST gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 29-05-2024 12:41:42 CEST
Figuur 13: Interactiediagram ‘Klantgegevens ophalen’ (open view in nieuw venster)
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’ (open view in nieuw venster)
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 29-05-2024 14:06:45 CEST gegenereerd door ArchiMedes™ © 2016-2024 ArchiXL. ArchiMedes 29-05-2024 14:06:45 CEST
Figuur 15:Interactiediagram ‘Status lopende aanvragen en zaken tonen’ (open view in nieuw venster)
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.
Deze pagina is voor het laatst bewerkt op 21 mei 2024 om 15:43.