Katern GEMMA Verbinden

Hoofdstuk: GEMMA Patronen

Katern GEMMA Verbinden

Deze pagina is een onderdeel van Katern GEMMA Verbinden compleet: Hele document bekijken - Exporteren - Definitie

Bij het ondersteunen van gemeentelijke processen zijn generieke problemen te onderkennen waarvoor standaard oplossingen beschikbaar zijn. Deze standaard oplossingen worden binnen de GEMMA ‘patronen’ genoemd. Deze patronen maken gebruik van de in het voorgaande hoofdstuk beschreven referentiecomponenten en integratiestijlen. Dit hoofdstuk beschrijft deze generieke patronen en beschrijft de standaard wijze waarop de verschillende referentiecomponenten ingezet kunnen worden om de patronen te ondersteunen. Door VNG Realisatie worden overige architectuurproducten en standaarden gebaseerd op deze patronen.

Verbinden binnengemeentelijke componenten

Binnengemeentelijk worden componenten op allerlei vlakken met elkaar verbonden. Denk bijvoorbeeld aan een baliecomponent die voor het opvragen van persoonsgegevens gebruik maakt van een gegevensmagazijncomponent of een informatiesysteem wat documenten opslaat in een documentmanagementsysteem. Dergelijke integratie van systemen kan tot stand worden gebracht door directe integratie tussen de systemen (zogenaamde point-to-point verbindingen) koppelingen of via een verbindend servicebuscomponent. In beide varianten is het mogelijk om de integratie via standaard koppelvlakken of leverancier-specifieke koppelvlakken tot stand te brengen.

Het koppelen via point-to-point verbindingen leidt al snel tot een complex en onoverzichtelijk landschap waarover de gemeente niet meer in-control is. Potentieel leidt dit bij n applicaties tot (n*(n-1))/2 koppelingen. Point-to-point koppelingen zijn kwetsbaar doordat ze vaak niet goed gedocumenteerd zijn, of niet bekend zijn. Bij verstoringen is het oplossen van problemen daardoor vaak ingewikkeld. Om deze redenen wordt deze wijze van binnengemeentelijk integreren van informatiesystemen door VNG Realisatie afgeraden. Ook het integreren via leverancier-specifieke koppelvlakken wordt door VNG Realisatie afgeraden. Reden hiervoor is dat het implementeren van leverancier-specifieke koppelvlakken leidt tot specifieke koppelingen waarmee afhankelijkheid richting een specifieke leverancier in de hand wordt gewerkt. Het inzetten van gestandaardiseerde koppelvlakken heeft te allen tijde de voorkeur. Om redenen van flexibiliteit in de informatiearchitectuur en leveranciersonafhankelijkheid heeft het de voorkeur om te integreren via koppelvlakstandaarden.

Beschrijving GEMMA patroon

Aanbevolen wordt om voor het binnengemeentelijk integreren van informatiesystemen gebruik te maken van webservices, koppelvlakstandaarden en de diensten van een servicebuscomponent. De inzet van deze beide elementen garandeert flexibiliteit en overzicht in de informatiearchitectuur en draagt bij aan het in control zijn van de informatiearchitectuur.

Vanuit de GEMMA architectuur wordt aangeraden om servicekoppelingen tussen informatiesystemen uitsluitend via goed gedefinieerde eindpunten te laten verlopen. Een eindpunt levert een beschrijving die wordt gebruikt om een bericht naar te adresseren en wordt beschreven in een WSDL (Web Services Definition Language). Een WSDL-document is een XML-document dat het uiterlijk van een webservice beschrijft. Het beschrijft het de syntax en structuur van het bericht waarmee de webservice aangesproken kan worden en beschrijft het bericht dat de webservice als antwoord geeft. In het groter geheel wordt het WSDL document meegeleverd met de webservice wanneer deze zich inschrijft in een serviceregistercomponent, zodat de afnemers van de webservice weten hoe de service werkt.

Aanbeveling is om bij dit patroon altijd een servicebuscomponent in te zetten als intermediair tussen Informatiesysteem A en Informatiesysteem B. Inzet van een servicebuscomponent heeft een aantal voordelen:

Goede mogelijkheden voor het centraal monitoren van koppelingen;
Mogelijkheid voor toepassing van centrale authenticatie en autorisatie;
Mogelijkheden tot routering en orkestratie van serviceaanroepen;
Transformatie van gegevens.

Onderstaande figuur geeft de integratie van twee informatiesystemen via de gemeentelijke servicebus schematisch weer ^[1]. De relatie tussen de twee informatiesystemen wordt hierbij gelegd door een service die door de servicebuscomponent wordt geleverd.

GP05 Verbinden binnengemeentelijke componenten (uit model: GEMMA 2) - Toon SVG - Download als csv

Aandachtspunten

Aandachtspunt bij dit patroon is het feit dat de servicebuscomponent potentieel een single-point-of-failure in de informatievoorziening kan worden. Gevolg van de uitval van de servicebuscomponent zou uitval van een groot aantal koppelingen veroorzaken, en daarmee een risico vormen voor de continuïteit van de dienstverlening. Maatregelen dienen getroffen te worden om dit te voorkomen. Hierbij kan bijvoorbeeld gedacht worden aan het dubbel uitvoeren van de servicebuscomponent en het beschrijven van procedures die gevolgd moeten worden in geval van uitval van de servicebuscomponent.

Standaarden

Uitgangspunt bij het integreren van binnengemeentelijke informatiesystemen is dat deze integratie zoveel mogelijk gebaseerd is op via StUF gestandaardiseerde koppelvlakstandaarden. Voorbeelden hiervan zijn de GEMMA zaak-document services en e-formulier en RSGB bevragingen services. De servicebuscomponent dient deze verschillende koppelvlakstandaarden te ondersteunen.

↑ Modellering conform de Archimate best practices.

Verbinden met keten- en netwerkpartijen

Gemeenten maken door veranderende wetgeving en decentralisatie van taken deel uit van een groot aantal nieuwe ketens en netwerken. Het aantal publieke, maar ook private, partijen waarmee gemeenten gegevens uitwisselen neemt hierdoor in een rap tempo toe. Voorbeelden hiervan zijn de Werk en Inkomen keten waar de Suwi-partijen een rol spelen, de jeugdketen waarin diverse justitiële partijen en jeugdzorgaanbieders betrokken zijn en de zorgketen waarin onder andere de zorgaanbieders een belangrijke rol hebben.

Beschrijving GEMMA patroon

Het aansluiten van alle individuele gemeenten op de verschillende keten- en netwerkpartners zou leiden tot een onbeheersbare wirwar aan verbindingen tussen organisaties. Aanbevolen wordt om voor het integreren van gemeentelijke systemen met systemen van ketenpartners (zowel private en publieke partijen) zoveel mogelijk gebruik te maken van de diensten van een gemeentelijk knooppunt. Een knooppunt levert als intermediair of ontkoppelpunt de functionaliteit die op het gebied van het koppelen aan sectorale- en stelselvoorzieningen door gemeenten vereist is. Een knooppunt koppelt aan de verschillende ketens en sectorale voorzieningen en biedt gemeenten toegang tot deze ketens en voorzieningen via gestandaardiseerde koppelvlakken en connectiviteit. Een gemeentelijk knooppunt is een organisatie met een ingerichte governance, ketensturing en structurele financiering. Een knooppunt functioneert als intermediair tussen het gemeentelijk domein en andere domeinen en kent als afnemers gemeenten en samenwerkingsverbanden van gemeenten. Een gemeentelijk knooppunt biedt standaard diensten die generiek toepasbaar zijn en specifieke diensten voor een domein of thema.

Gemeenten sluiten aan op gemeentelijke knooppunten en gebruiken diensten van de knooppunten om te verbinden met ketenpartijen uit andere domeinen. Gemeenten worden hierdoor ontzorgd in hun informatievoorziening waardoor ruimte wordt gecreëerd voor lokale autonomie in de uitvoering van hun kerntaken.

Onderstaande figuur geeft schematisch het stelsel voor gegevensuitwisseling gebruik makend van knooppunten weer.

Figuur - Het generieke stelsel voor gegevensuitwisseling

In bovenstaand figuur zijn aan de linkerkant een drietal gemeentelijke knooppunten weergegeven. Elk van deze gemeentelijke knooppunten biedt eigen knooppuntvoorzieningen en op een gemeentelijk knooppunt kunnen meerdere gemeenten aangesloten zijn. Gemeentelijke knooppunten verzorgen:

Toegang tot gemeentelijke knooppuntdiensten,
Toegang tot de voorzieningen van de GDI,
Verbinding met knooppunten van andere sectoren,
Vertaling van stelsel of ketenstandaarden naar gemeentelijke standaarden.

Bij de uitwisseling van gegevens met keten- en netwerkpartijen zijn privacy en beveiliging, en verantwoording en transparantie aspecten waar bijzondere aandacht aan gegeven moet worden. De uitwisseling van gegevens en informatie met ketenpartijen moet op een veilige en herleidbare wijze plaatsvinden. Daar waar gevoelige (persoon)gegevens worden uitgewisseld dienen specifieke maatregelen genomen te worden om de vertrouwelijkheid van deze gegevens te borgen. De uitwisseling van gegevens met ketenpartijen moet op een transparante wijze plaatsvinden. Te allen tijde moet duidelijk zijn welke (categorieën van) gegevens zijn uitgewisseld. Deze transparantie is vereist om hierover verantwoording af te kunnen leggen. Gemeentelijke knooppunten geven invulling aan de eisen die vanuit de gemeentelijke organisatie gesteld worden aan beveiliging en transparantie. Vanuit een groot aantal domeinen wordt door gemeenten samengewerkt in ketens en netwerken. Denk bijvoorbeeld aan het sociaal domein waar vanuit de uitvoering van de Wmo 2015, de Jeugdwet en de Wet Werk en Inkomen met een groot aantal private en publieke partijen gegevens worden uitgewisseld.

Aandachtpunten

Niet voor alle ketens zijn gemeentelijke knooppunten beschikbaar. Daar waar geen knooppunt beschikbaar is kan door de gemeente direct worden aangesloten op de diensten van keten- en netwerkpartners.

Standaarden

Uitgangspunt bij het integreren van gemeentelijke informatiesystemen met informatiesystemen van keten- of netwerkpartners via knooppunten is dat dit zoveel mogelijk gebaseerd is op standaard koppelvlakken en berichtstandaarden. Indien integratie plaatsvindt over verschillende partijen heen wordt de voorkeur gegeven aan ketenstandaarden. Dergelijke standaarden kunnen gebaseerd zijn op StUF maar ook op andere standaarden. Voorbeelden van ketenstandaarden zijn StUF-CORV in de Jeugdhulp keten, SuwiML in de Werk en Inkomen keten en iWmo en iJw in de Wmo- en Jeugdketen. Vertaling van ketenstandaarden naar gemeentelijke standaarden is gewenst indien de berichten uit de ketenstandaard binnengemeentelijk meervoudig worden gebruikt. Indien verwerking van de berichten beperkt is tot specifieke taak-specifieke applicaties is vertaling niet nodig. Voorbeelden van standaarden die om deze redenen niet naar de gemeentelijke StUF-berichtstandaarden vertaald worden zijn SuwiML in de Werk en Inkomen keten, iWmo in de Maatschappelijke Ondersteuning keten en iJw in de Jeugdzorgketen.

Inwinnen en routeren van notificaties

Informatiesystemen hebben de mogelijkheid om op het moment dat er een bepaalde gebeurtenis plaatsvindt een melding hiervan te maken ten behoeve van andere processen en systemen. Hierbij kan bijvoorbeeld gedacht worden aan een melding dat een burger een bepaalde dienst heeft afgenomen of dat een proces een bepaalde status bereikt heeft. Voorbeelden hiervan zijn de verhuizing van een klant, het overleiden van een persoon of het op naam zetten van een voertuig. Deze gebeurtenissen kunnen er toe leiden dat lopende processen gestopt of aangepast moeten worden of dat nieuwe processen opgestart moeten worden. Een voorbeeld hiervan is een notificatie die vanuit de Basisregistratie voertuigen (BRV) verzonden wordt over het op naam zetten van een voertuig door een persoon. Niet alle systemen en basisregistraties bieden de mogelijkheid om notificaties te verzenden. Met name de basisregistraties zouden dit vanuit het perspectief van de gemeenten eigenlijk wel moeten doen. Deze notificatie kan interessant zijn voor sociale dienst indien de persoon die het voertuig op naam heeft gezet gebruik maakt van gemeentelijke uitkeringen of toeslagen. In dat geval zou de notificatie een aanleiding kunnen zijn op een onderzoek te starten naar het vermogen van de betreffende persoon. Voertuigbezit valt immers onder persoonlijk vermogen en het vermogen kan bepalend zijn voor hoogte van, en op recht op bepaalde toeslagen en uitkeringen.

Beschrijving GEMMA patroon

Het patroon voor implementatie van de inwinning en routering van notificaties maakt gebruik van de servicebuscomponent, de notificatierouteringcomponent en het loggingcomponent.

De notificatierouteringcomponent heeft als taak het inwinnen, loggen en routeren van notificaties. Onderstaande figuur geeft weer hoe het patroon vorm gegeven kan worden. Informatiesystemen die notificaties willen publiceren doen dat door zich als bron van notificaties te registreren bij de notificatierouteringcomponent. Hierbij worden de verschillende soorten notificaties (context) via de notificatierouteringcomponent beschikbaar gesteld aan geabonneerde systemen. De systemen die notificaties willen ontvangen maken zich kenbaar bij de notificatierouteringcomponent als afnemer, en stellen per notificatie die zij willen ontvangen een abonnement in. De notificaties waarop een abonnement is in te stellen zijn de notificaties die door de verschillende aanleverende systemen worden geleverd aan de notificatierouteringcomponent.

De koppeling tussen bronnen van notificaties en de notificatierouteringcomponent wordt gelegd via implementatie van de externe applicatiefunctionaliteit aanroep integratiestijl. Bronnen leveren dus via een service van de servicebuscomponent notificaties aan. De servicebuscomponent routeert de ontvangen notificaties naar de notificatierouteringcomponent. Deze component routeert de ontvangen notificaties op basis van ingestelde abonnementen door naar afnemers. De routering bestaat uit het aanroepen van een service van het afnemende systeem. Het betreft hier dus een push-koppeling vanuit de notificatierouteringcomponent naar de afnemer. Afnemers nemen afhankelijk van eigen bedrijfsregels actie op een ontvangen notificatie.

Alle componenten die betrokken zijn in aanmaak, routering en afhandeling van notificaties loggen de verwerkingen ten aanzien van de notificaties via de loggingcomponent.

GP04 Inwinnen en routeren van notificaties view (uit model: GEMMA 2) - Toon SVG - Download als csv

Aandachtpunten

Ten behoeve van de processen vanuit het Werk en Inkomen domein is vanuit het Inlichtingenbureau een dienst beschikbaar die doorlopend controleert of er omstandigheden zijn te melden die van invloed kunnen zijn op het recht op bijstand van cliënten. Het resultaat van deze controle levert het Inlichtingenbureau in de vorm van samenloopsignalen aan gemeenten. Deze samenloopsignalen zouden gezien kunnen worden als notificaties. Indien de gemeente al gebruik maakt van deze dienst dat is deze naar verwachting direct op de gemeentelijke backoffice aangesloten.

Standaarden

Vanuit de GDI is Digilevering gepositioneerd als voorziening voor het verzenden van, en abonneren op notificaties van basisregistraties. Deze voorziening is niet voor alle basisregistraties operationeel. De BRP kent een eigen voorziening voor het leveren van notificaties, en een aantal basisregistraties kennen het systeem van notificaties niet. Standaardisatie op het gebied van notificaties op landelijk niveau ontbreekt dus vooralsnog. Vanuit de Zaak – Regieservices koppelvlakstandaard zijn notificaties beschreven die uitgewisseld worden tussen zaaksystemen en regiesystemen.

Binnengemeentelijk beschikbaar stellen basis- en kerngegevens

Vanuit diverse processen is er tijdens de uitvoering van de processen behoefte aan gegevens uit basis- en kernregistraties. Deze gegevens kunnen door de processen worden opgehaald bij de bron op het moment dat de gegevens binnen een proces nodig zijn maar er kan ook voor gekozen worden om kopieën van de gegevens bij te houden binnen de administratie van de component die het proces automatiseert. De kopiegegevens worden in dat geval actueel en synchroon gehouden met de bron door een distributiemechanisme ^[1]. We spreken hierbij over zogenaamde ‘push’ en ‘pull’ mechanismes.

Pullmechanisme – Bij een pullmechanisme haalt een afnemer de gegevens die nodig zijn bij de uitvoering van een proces op bij de bron. De afnemer houdt zelf geen kopieën van deze gegevens bij. De implementatie van een pullmechanisme heeft de voorkeur boven een pushmechanisme aangezien bij een pullmechanisme gegevens niet onnodig door het systeemlandschap gedistribueerd worden. Een pullmechanisme wordt vaak in combinatie met de Inwinnen en routeren van notificaties integratiestijl gebruikt. Gebeurtenissen worden dan door bronnen via notificaties aan afnemers kenbaar gemaakt en de afnemers halen op basis van deze gebeurtenissen de bij de gebeurtenis behorende gegevens op.

Pushmechanisme - Bij een pushmechanisme worden kopieën van gegevens in een administratie actueel gehouden via een distributiemechanisme en bij een pullmechanisme worden gegevens uit de bron gelezen op het moment dat ze nodig zijn. De keuze voor implementatie van een pull- of een push-mechanisme is mede afhankelijk van de beschikbaarheid van bronnen. Op het moment dat de serviceniveaus van bronnen niet aansluiten bij de gewenste serviceniveaus vanuit processen wordt veelal een push-mechanisme gebruikt. De reden hiervoor is dat bij gebruik van een push-mechanisme de afnemer altijd beschikt over near-realtime gegevens en bevraging van de bron daardoor onnodig is. Dit systeem wordt ook wel datareplicatie genoemd. Bij datareplicatie worden gegevens van een bronsysteem door andere informatiesystemen opgeslagen binnen hun eigen opslag en near real-time bijgehouden.

In dit patroon wordt beschreven op welke manier basis- en kerngegevens via een pushmechanisme beschikbaar kunnen worden worden gesteld gebruik makend van de GEMMA referentiecomponenten.

Beschrijving GEMMA patroon

In dit patroon zijn een aantal keuzes gemaakt ten aanzien van de wijze waarop gegevens beschikbaar worden gesteld aan afnemers en de manier waarop afnemers gerede twijfel aan de juistheid van gegevens kunnen melden.

Basisgegevens - De keuze is gemaakt om voor het binnengemeentelijk beschikbaar stellen van basisgegevens gebruik te maken van een pushmechanisme via de berichtuitwisseling integratiestijl. Er wordt ten aanzien van de gegevens uit basisregistraties dus gekozen voor datareplicatie. De reden voor deze keuze is het feit dat niet alle basisregistraties op een efficiënte en effectieve wijze bevraagbaar zijn via een pull-mechanisme en niet de serviceniveaus bieden die door gemeenten gewenst zijn. De keuze voor datareplicatie betekent dat basisregistraties mutaties van basisgegevens doorgeven aan gemeenten en gemeenten de verdere distributie van deze mutaties regelen via een gegevensdistributie-component;

Kernregistratiegegevens - De keuze is gemaakt om voor het binnengemeentelijk beschikbaar stellen van gegevens uit kernregistraties, zoals de kernregistratie medewerkers, via een pull-mechanisme te verlopen. De reden voor deze keuze is dat de gemeente zelf in-control is van serviceniveaus die geboden worden door kernregistraties. Het intern afstemmen van deze serviceniveaus op de door processen gewenste serviceniveaus is daardoor mogelijk en replicatie van de kerngegevens binnen taakspecifieke componenten is hiermee overbodig. De kerngegevens kunnen immers door processen direct uit de bron betrokken worden. Dit doet recht aan de principes van eenmalige vastlegging en meervoudig gebruik;

Terugmelding van gerede twijfel aan de juistheid van gegevens wordt door taakspecifieke componenten gemeld via de terugmeldingenregistratiecomponent. Deze component biedt functionaliteit om terugmeldingen van gerede twijfel te ontvangen en te routeren naar hetzij een basis- hetzij een kernregistratie.

Onderstaande figuur geeft schematisch de binnengemeentelijke levering en gebruik van gegevens uit basis- en kernregistraties weer.

GP02 Binnengemeentelijk beschikbaar stellen basis- en kerngegeven view (uit model: GEMMA 2) - Toon SVG - Download als csv

Aandachtspunten

De keuze voor datareplicatie bij basisgegevens via een gegevensmagazijncomponent is ingegeven door het feit dat er geen alternatieven zijn. Redenen hiervoor zijn de door basisregistraties geboden serviceniveaus en restricties op de afname van gegevens door afnemers bij basisregistraties. Datareplicatie is in de visie van VNG Realisatie een tijdelijke oplossing. Zodra de basisregistraties geschikt zijn voor directe bevraging kan worden overgestapt op een pull-mechanisme.

Standaarden

Ten aanzien van de distributie van basisgegevens dient binnengemeentelijk gebruik gemaakt te worden van StUF-BG berichten. Aanlevering van mutaties door basisregistraties verloopt via diverse (StUF) berichtsoorten. De BRP levert mutaties via StUF-BG, de NHR levert StUF-HR, de BRK levert BRK-Leveringen en de BAG levert StUF-BAG.

↑ zie ook Integratiestijlen en functies.

Beschikbaar stellen managementinformatie

Managementinformatie bestaat uit de gegevens die nodig zijn voor de besturing en beheersing van de organisatie alsmede de gegevens die nodig zijn om horizontale en verticale verantwoording over het functioneren van de organisatie af te leggen. In het kort gaat het dus om stuur- en verantwoordingsinformatie. In dit patroon wordt beschreven op welke manier het beschikbaar stellen van managementinformatie ingericht kan worden gebruik makend van de GEMMA referentiecomponenten.

Beschrijving GEMMA patroon

Aan het patroon voor het beschikbaar stellen van managementinformatie wordt invulling gegeven door de data-warehousecomponent en de managementinformatiecomponent. Gegevens worden aan de data-warehousecomponent aangeleverd door basisregistraties, kernregistraties, taakspecifieke informatiesystemen en eventuele andere bronnen. Deze aanleverende bronnen gebruiken hiervoor meestal een techniek die op de bestandsuitwisseling integratiestijl gebaseerd is. Denk hierbij aan ETL-processen die periodiek worden uitgevoerd. Aangeleverde gegevens worden door de data-warehousecomponent ingelezen, getransformeerd en opgeslagen in het de eigen gegevensopslag. Via datamarts geeft de managementinformatiecomponent toegang tot een deelverzameling van de gegevens binnen de data-warehousecomponent. Datamarts zijn meestal specifiek voor een bepaald domein of thema.

Het is het uitdrukkelijke advies om nooit managementrapportages te genereren vanuit bronsystemen gezien de potentiële impact die deze rapportages heeft op performance en beveiligingsproblemen van die bronsystemen.

GP01 Beschikbaar stellen managementinformatie view (uit model: GEMMA 2) - Toon SVG - Download als csv

Aandachtpunten

Gegevens worden in de regel via ETL-processen aan een data-warehousecomponent aangeleverd door de verschillende bronnen. Deze processen worden periodiek uitgevoerd. De gegevens in de data-warehousecomponent kunnen daardoor gedateerd zijn. Per managementinformatierapportage moet bepaald worden of de gegevens in de data-warehousecomponent voldoen aan de kwaliteitseisen die vanuit de rapportage vereist zijn. Indien niet aan de gestelde eisen voldaan kan worden zullen de aanleverprocessen, of de periodiciteit waarmee gegevens aangeleverd worden aangepast moeten worden. De data-warehousecomponent bevat enkel kopieën van gegevens. Eventuele inhoudelijke aanpassing van gegevens dient plaats te vinden in de broncomponent en niet in de data-warehousecomponent.

Standaarden

Op het gebied van de inrichting van een data-warehousecomponenten, en wijze waarop gegevens aangeleverd worden aan data-warehousecomponenten, zijn geen gemeentelijke standaarden gedefinieerd.

Dienstverlening naar klanten

Het gemeentelijke digitale kanaal is in de dienstverlening een steeds belangrijker kanaal voor gemeenten. Klanten kunnen via het digitale kanaal worden voorzien van informatie en klanten kunnen dit kanaal gebruiken om diensten en producten mee af te nemen. Gemeenten bieden klanten hiertoe publiek beschikbare informatie via de gemeentelijke website en gepersonaliseerde gegevens en diensten via een beveiligde persoonlijke internet pagina. Via de gemeentelijke website publiceert de gemeente openingstijden, geplande evenementen, bouwprojecten, beschikbare producten en diensten, et cetera. Via een persoonlijke internet pagina kunnen klanten hun persoonlijke gegevens mee in te zien en gemeentelijke producten en diensten aanvragen. Het is ook mogelijk om de klant zijn eigen gegevens te laten muteren. Door de burger directe controle te geven over zijn gegevens zal de burger in toenemende mate zelfredzaam worden. Het muteren van de gegevens door de klant is uiteraard alleen mogelijk daar waar de wettelijke kaders daar ruimte toe bieden.

Het operationaliseren van de informatievoorziening voor het digitale loket is geen sinecure. Klanten hebben verwachtingen en eisen ten aanzien van beschikbaarheid van de diensten, beveiliging van gegevens en bescherming van de privacy. Daarnaast is de betrouwbaarheid, correctheid en accuraatheid van de gegevens die in het digitale kanaal gebruikt worden voor de kwaliteit van de dienstverlening van cruciaal belang. Dit alles stelt eisen aan de inrichting van de ondersteunende gemeentelijke informatievoorziening.

Beschrijving GEMMA patroon

Dit patroon gaat uit van een inrichting van de informatiearchitectuur waarmee de beschikbaarheid van gegevens ten behoeve van de digitale dienstverlening aan de klanten geborgd kan worden. In dit patroon zijn de volgende uitgangspunten gehanteerd:

Gebruik van de servicebuscomponent voor het verbinden van componenten conform het ‘Verbinden binnengemeentelijke componenten’ patroon;
Ontsluiting van publieke ongestructureerde gegevens via de websitecomponent. Deze component heeft hierbij een dubbelfunctie. Enerzijds is dit component de ontsluiting naar de klanten (de website) en anderzijds heeft deze component de verantwoordelijkheid om content van verschillende systemen te combineren en te publiceren. Voorbeeld van een content aanleverende component is de Bestuur- en Raadsinformatiecomponent;
Ontsluiting van publieke gestructureerde gegevens via opendataportaalcomponent. Deze component ontvangt de publieke gestructureerde gegevens van taakspecifieke componenten. Het is de verantwoordelijkheid van aanleverende componenten om te bepalen welke gegevens in aanmerking komen om gepubliceerd te worden als publieke gegevens (open data);
Toegang tot privacygevoelige gegevens via de per klantsoort (burger/bedrijf/instelling) beschikbare authenticatiemiddelen^[1].;
Gebruik van de gegevensmagazijncomponent en landelijke voorzieningen als bronnen voor het voorinvullen van e-formulieren en product specifieke aanvragen. Uitgangspunt hierbij is toepassing van het ‘Binnengemeentelijk beschikbaar stellen basis- en kerngegevens’ patroon voor het vullen, en actueel houden van de gegevensmagazijncomponent. Of voor de voorinvulling van formulieren ten behoeve van product of dienstaanvragen de gegevensmagazijncomponent of een landelijke voorziening wordt gebruikt is een gemeentelijke keuze. Deze keuze is mede afhankelijk van de eisen die de gemeente vanuit het oogpunt van dienstverlening stelt aan de beschikbaarheid van systemen waar de dienstverlening van afhankelijk is. De gemeente heeft invloed op de beschikbaarheid van een gegevensmagazijncomponent terwijl dat bij de landelijke voorzieningen niet zo is. Het kan voor gemeenten in verband met de vereiste serviceniveaus een valide keuze zijn om de voorinvulling van e-formulieren via de gegevensmagazijncomponent te laten verlopen. Op die manier kan geborgd worden dat klanten producten en diensten aan kunnen vragen ook als de landelijke voorzieningen niet beschikbaar zijn;
Aanvraag van producten en diensten via een e-Formulierencomponent of een Product aanvraagcomponent. Deze componenten verzorgen het voorinvullen van al bekende (basis)gegevens en stellen klanten in staat om producten en diensten aan te vragen. Afhandeling van aanvragen wordt gedaan door hetzij de zaakbeheercomponent hetzij een taakspecifieke component;
Aanlevering van statusgegevens ten aanzien van de voortgang van de afhandeling van zaken door Taakspecifieke componenten en de Zaakbeheercomponent aan de Zaakregistratiecomponent;
Toegang van de burger tot persoonlijke gegevens via een Mijngemeentecomponent. Via deze component wordt inzage gegeven in de gegevens die de gemeente van de klant vastgelegd heeft en tevens wordt een overzicht gegeven van de zaken die er rondom deze klant spelen. Het overzicht van lopende zaken wordt geleverd door de Zaakregistratiecomponent. Inzage in persoonlijke gegevens worden geleverd door de Gegevensmagazijncomponent en Taakspecifieke componenten.

Uitgaande van de uitgangspunten ontstaat de onderstaande referentie inrichting van componenten ten behoeve van de digitale dienstverlening aan klanten.

GP03 Dienstverlening naar klanten view (uit model: GEMMA 2) - Toon SVG - Download als csv

In bovenstaande plaat wordt onder andere weergegeven op welke wijze de klant via een besloten kanaal diensten en producten kan aanvragen. Diensten en producten die worden aangevraagd via hetzij een generiek e-formulierencomponent of een specifiek productaanvraagcomponent worden via de servicebuscomponent ontvangen en worden doorgeleid naar het zakenregistratiecomponent. Door dit component wordt de aanvraag als een zaak geregistreerd en wordt een notificatie verzonden naar het afhandelende informatiesysteem. De wijze waarop deze notificatie wordt verzonden is beschreven in het 'Inwinnen en routeren van notificaties' patroon. Het informatiesysteem wat de notificatie ontvangt zal vervolgens de aangemaakte zaak afhandelen.

↑ zie ook Verbinden met klanten.

Voetnoten

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

[1] Modellering conform de Archimate best practices.

[2] zie ook Integratiestijlen en functies.

[3] zie ook Verbinden met klanten.

[1]

[1]

[1]

Katern GEMMA Verbinden

Hoofdstuk: GEMMA Patronen

Verbinden binnengemeentelijke componenten

Beschrijving GEMMA patroon

Aandachtspunten

Standaarden

Verbinden met keten- en netwerkpartijen

Beschrijving GEMMA patroon

Aandachtpunten

Standaarden

Inwinnen en routeren van notificaties

Beschrijving GEMMA patroon

Aandachtpunten

Standaarden

Binnengemeentelijk beschikbaar stellen basis- en kerngegevens

Beschrijving GEMMA patroon

Aandachtspunten

Standaarden

Beschikbaar stellen managementinformatie

Beschrijving GEMMA patroon

Aandachtpunten

Standaarden

Dienstverlening naar klanten

Beschrijving GEMMA patroon

Voetnoten

Nieuws

Contact[bewerken]

Bezoekadres[bewerken]

Postadres[bewerken]