Katern GEMMA Verbinden
Let op: deze pagina is gearchiveerd
Hoofdstuk: Referentiecomponenten voor integratie
- Inleiding
- Principes en richtlijnen
- Ontsluiting en actualiteit van gegevens
- Verbinden met klanten
- Verbinden in ketens en netwerken
- Referentiecomponenten voor integratie
- GEMMA Patronen
- Bijlage: Integratiestijlen en functies
Deze pagina is een onderdeel van Katern GEMMA Verbinden compleet: Hele document bekijken - Exporteren - Definitie
Bij het uitvoeren van processen worden services en gebruikersfuncties (diensten) gebruikt die door informatiesystemen worden geboden. Bij de uitvoering van de diensten zijn over het algemeen meerdere informatiesystemen betrokken. Denk hierbij aan een informatiesysteem dat als dienst een gebruikersscherm aanbiedt om personen mee te zoeken op basis van een BSN. Het systeem dat de dienst aanbiedt toont de gebruikersinterface. Voor de uitvoering van de zoekopdracht is waarschijnlijk een aantal componenten verantwoordelijk. Te denken valt aan de servicebuscomponent, de gegevensmagazijncomponent, de landelijke GBA-V en wellicht ook sectorale informatiesystemen. Bij de uitvoering van de dienst is dus een aantal verschillende informatiesystemen betrokken. Het laten samenwerken van verschillende informatiesystemen wordt ook wel het ‘integreren’ van informatiesystemen genoemd.
Bij Integratiestijlen en functies zijn de verschillende uit de literatuur beschreven standaard integratiestijlen en integratiefuncties beschreven. Hier zijn de verschillende referentiecomponenten die in de verbindingsfunctie binnengemeentelijk, met klanten en met ketens een belangrijke rol spelen beschreven. Onderstaande figuur toont deze verschillende referentiecomponenten.
De referentiecomponenten die een rol spelen in de verbindingsfunctie geven allen invulling aan een aantal integratiefuncties [1]. Onderstaande tabel toont dit overzicht.
| Orkestreren | Routeren | Transformeren | Abonneren | Monitoren | Loggen | Beveiligen | |
|---|---|---|---|---|---|---|---|
| Servicebuscomponent | X | X | X | X | X | X | |
| Gegevensdistributiecomponent | X | X | X | X | X | ||
| Notificatierouteringcomponent | X | X | X | X | X | ||
| Gegevensmagazijncomponent | X | X | |||||
| Data-warehousecomponent | X | X | X | ||||
| Zaakregistratiecomponent | X | X | |||||
| Verwerkingenloggingcomponent | X | X | |||||
| Open-data-portaalcomponent | X | X | |||||
| Ketenpartner-portaalcomponent | X | X | |||||
| Mijngemeentecomponent | X | X |
Hieronder worden de bovenstaande referentiecomponenten nader beschreven. Gezien de centrale rol die deze componenten in de informatievoorziening spelen wordt aanbevolen er naar te streven om van deze componenten slechts één voorkomen in de gemeentelijke informatiearchitectuur op te nemen. Meervoudig laten voorkomen van deze componenten leidt tot hogere complexiteit en daarmee hogere (beheer)kosten.
Generieke (integratie)functies voor referentiecomponenten
Zoals in de bovenstaande tabel is te zien zijn de integratiefuncties 'Loggen' en 'Beveiligen' functies waaraan door alle referentiecomponenten die bij verbinden worden gebruikt invulling wordt gegeven. Deze functies zijn niet allen voor de in de tabel genoemde, maar voor alle referentiecomponenten die 'closed data' verwerken van belang. Alle deze componenten dienen immers opslag, toegang en gebruik van de gegevens te beveiligen en zullenin het kader van de transparantie en verantwoording de verwerking hiervan loggen. Deze functies zijn dus niet puur integratiefuncties, maar generieke functies die door alle referentiecomponenten die closed data verwerken verplicht ingevuld moeten worden.
Servicebuscomponent
De gemeentelijke servicebus speelt een actieve rol binnen het merendeel van de integratiestijlen. Deze component routeert berichten, orkestreert afhandeling van berichten, transformeert desgewenst berichten en biedt daarnaast monitoring- en beveiligingsfuncties.
De gemeentelijke servicebus is in de basis een Enterprise Service Bus (ESB) waarmee gemeente specifieke koppelingen worden gerealiseerd. Belangrijkste taak van de servicebus is het bieden van functionaliteit voor het versturen en beheren van elektronische berichten. De servicebuscomponent biedt voor het verbinden aan landelijke voorzieningen en basisregistraties ondersteuning voor de door deze voorzieningen gehanteerde communicatiestandaarden. Een voorbeeld van een dergelijke standaard die door de servicebus wordt ondersteund is de Digikoppeling standaard. De servicebus is de component waarmee koppelingen tussen informatiesystemen gelegd worden, zowel tussen informatiesystemen binnengemeentelijk als buitengemeentelijk. Deze koppeling wordt in de meeste gevallen tot stand gebracht via de externe functionaliteit aanroep integratiestijl[2].
Gegevensdistributiecomponent
De gegevensdistributiecomponent is binnen de gemeentelijke informatiearchitectuur verantwoordelijk voor de distributie van mutaties van basisgegevens naar geabonneerde afnemers. De gegevens die door de gegevensdistributiecomponent gedistribueerd worden zijn de gegevens die via de StUF-BG standaard, gebaseerd op het RSGB, uitgewisseld kunnen worden. Deze gegevens omvatten de gegevens uit basisregistraties aangevuld met een aantal extra gegevens. De gegevensdistributiecomponent kan daarnaast optioneel ook andere gegevens distribueren. Implementatie hiervan is leverancier afhankelijk. De gegevensdistributiecomponent wordt ten aanzien van RSGB-gegevens door bronsystemen gevoed via StUF kennisgevingen. De gegevensdistributiecomponent biedt functionaliteit waarmee afnemers abonnementen kunnen afsluiten op mutaties van deze gegevens. Afnemers kunnen via distributieregels per soort gegeven instellen van welke wijzigingen ze op de hoogte worden gesteld door de gegevensdistributiecomponent.
De gegevensdistributiecomponent wordt gebruikt om de berichtuitwisseling integratiestijl[3] op basis van kennisgevingen mee te implementeren. Dit houdt in dat mutaties (context en inhoudelijke gegevens) van bronsystemen worden gedistribueerd naar geabonneerde afnemers.
Functies van de gegevensdistributiebuscomponent
Gegevensdistributiecomponent versus de servicebuscomponent
De functionaliteit van de gegevensdistributiecomponent wordt vaak verward met de functionaliteit van de servicebuscomponent. De servicebuscomponent is een component die berichten ontvangt, desgewenst transformeert en daarna routeert naar de bestemming. Deze component heeft geen weet van de functionele betekenis van berichten. De gegevensdistributiecomponent echter handelt berichten af op basis van de functionele betekenis en inhoud van berichten. De gegevensdistributiecomponent ontvangt mutaties van bronsystemen (de actuele bronwaarden), slaat deze bronwaarden intern op en distribueert de gegevens naar binnengemeentelijke afnemers op basis van afnemerindicaties en distributieregels. Het opslaan van de actuele bron- en afnemerwaarden binnen de distributiecomponent wordt gedaan voor synchronisatiedoeleinden van de gegevensdistributiecomponent met afnemers en bronhouders. Door de gegevensdistributiecomponent wordt onder andere de timestamp van de laatste mutatie in de bron bijgehouden. Door deze timestamp te vergelijken met de laatste timestamp in de bron is eenvoudig te bepalen of de bron en de door de gegevensdistributiecomponent geregistreerde actuele bronwaarden nog synchroon zijn. Voor het routeren van mutaties vanuit de gegevensdistributiecomponent naar de afnemers kan de gegevensdistributiecomponent gebruik maken van de routeringsfunctie van de servicebuscomponent.
Een leverancier mag in een servicebussysteem zowel een servicebuscomponent als gegevensdistributiecomponent implementeren. Op te merken valt dat vanuit het oogpunt van gegevensbeveiliging het combineren van beide componenten in één systeem is af te raden. Een eventuele kwetsbaarheid in de servicebus zou dan immers potentieel de gegevens die voor de distributiefunctie kunnen lekken aan partijen die aangesloten zijn op de servicebus. Potentieel gaat het dan om alle basisgegevens van de burgers waarmee de gemeente een relatie mee heeft (alle inwoners en ook een aantal buitengemeentelijke personen).
Gegevensdistributiecomponent versus de gegevensmagazijncomponent
De gegevensdistributiecomponent moet niet verward worden met de functionaliteit van een gegevensmagazijncomponent, ofschoon er veel overeenkomsten zijn. Belangrijke verschillen hierbij zijn de wijze van autorisatie van afnemers van de gegevens en koppelvlakken naar afnemers. De gegevensmagazijncomponent autoriseert de toegang tot gegevens op het niveau van eindgebruikers terwijl de gegevensdistributiecomponent deze toegang autoriseert op het niveau van de afnemer. In het geval van een gegevensdistributiecomponent wordt de autorisatie dus op het niveau van informatiesysteem geregeld in plaats van op individu. Ook de ontsluiting van de gegevens naar afnemers is verschillend. Daar waar de gegevensmagazijncomponent gegevens ontsluit volgens de verschillende StUF-bevragingskoppelvlakken wordt de gegevensdistributiecomponent ontsloten via synchronisatie en kennisgevingskoppelvlakken.
Mening van VNG Realisatie over nut en noodzaak van een gegevensdistributiecomponent
Over nut en noodzaak van gegevensdistributiecomponenten is veel discussie bij gemeenten en leveranciers. Leveranciers die geen gegevensdistributiecomponent leveren zijn vaak van mening dat de functionaliteit van een gegevensdistributiecomponent vanuit de implementatie van een servicebuscomponent geleverd kan worden. Leveranciers die wel een gegevensdistributiecomponent in hun softwareportfolio aanbieden hebben delen dat beeld niet. Het standpunt van VNG Realisatie is dat een gegevensdistributiecomponent binnen de gemeentelijke informatiearchitectuur vereist is zolang niet nog niet alle basisregistraties:
- Notificaties van mutaties inclusief de gebeurtenis die geleid heeft tot de mutatie leveren;
- Ad-hoc bevraagbaar zijn;
- Voldoen aan de door gemeenten gestelde serviceniveaus.
Op het moment dat de basisregistraties voldoen aan de bovenstaande eisen is het mogelijk om de gegevensdistributiecomponent uit te faseren. Afnemers kunnen dan op basis van de context van notificaties die door de bronsystemen verstuurd bepalen of de betreffende mutatie van belang is. Indien dat zo is kunnen de afnemers real-time de gegevens bij de bronregistratie ophalen. Zolang dit nog niet kan zullen gemeenten basisgegevens ‘rond moeten pompen’ binnen de gemeentelijke informatiearchitectuur. Het kunnen synchroniseren van gegevens tussen bronnen en afnemers is daarbij van essentieel belang.
Notificatierouteringcomponent
Systemen en processen hebben de mogelijkheid om op het moment dat een bepaalde gebeurtenis plaatsvindt hiervan melding 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. Dergelijke signalen worden binnen de GEMMA ‘notificaties’ genoemd. De notificatierouteringcomponent is de component binnen de gemeentelijke informatiearchitectuur die wordt gebruikt om de berichtuitwisseling integratiestijl op basis van notificaties (ook genoemd: signalen) mee te implementeren. De notificatierouteringcomponent ontvangt notificaties van bronsystemen en routeert deze notificaties naar geabonneerde afnemers.
Functies van de notificatierouteringcomponent
Via notificaties worden de context van een gebeurtenis en relevante sleutelgegevens uitgewisseld. De context geeft aan wat de inhoudelijke duiding van de gebeurtenis is en de sleutelgegevens geven aan op welk object de notificatie van toepassing is. Bij een gebeurtenis die gerelateerd is aan een persoon kan hierbij gedacht worden aan een BSN en bij een bedrijf aan een KvK-nummer. Notificaties kunnen zowel voortkomen uit interne- als externe bronnen. Voorbeelden van externe bronnen zijn basisregistraties, landelijke voorzieningen en sectorale knooppunten. Interne bronnen zijn bijvoorbeeld de zaakregistratiecomponent die statussen van zaken via notificaties publiceert.
Het besluit of op basis van een notificatie actie ondernomen moete worden kan mensenwerk zijn, maar het kan ook op basis van bedrijfsregels worden geautomatiseerd. Input voor deze afweging zijn de context van de notificatie, de sleutelgegevens en gegevens en lopende processen in de eigen applicatie.
Gegevensmagazijncomponent
De gegevensmagazijncomponent slaat gegevens uit verschillende basisregistraties in samenhang met elkaar op. In de gegevensmagazijncomponent worden zowel de gegevens opgeslagen van basisregistraties waar de gemeenten bronhouder van is als diegene waar de gemeente enkel afnemer van is. Implementaties van gegevensmagazijncomponenten volgen inhoudelijk de modellering van gegevens die in het Referentiestelsel Gemeentelijke Basisgegevens (RSGB) gedefinieerd zijn. Aanlevering van gegevens aan de gegevensmagazijncomponent vindt bij voorkeur plaats via StUF-kennisgevingsberichten. Bron van de kennisgevingsberichten kan het bronsysteem of een gegevensdistributiesysteem zijn. Het vullen van het gegevensmagazijn via kennisgevingen heeft de voorkeur aangezien op die manier de gegevensmagazijncomponent near-realtime gegevens bevat.
Het gegevensmagazijncomponent bevat een kopie van brongegevens. De component is zelf nooit bronsysteem van gegevens. De gegevensmagazijncomponent kent geen functionaliteit om gegevens te muteren. Indien gegevens in het gegevensmagazijn gewijzigd moeten worden dient dit plaats te vinden via de bronsystemen van deze gegevens; de basisregistraties. Deze bronsystemen werken vervolgens via StUF-kennisgevingen de gegevensmagazijncomponent bij. Als een gebruiker van het gegevensmagazijn vermoed dat de gegevens in de gegevensmagazijncomponent onjuist zijn dan kan de gebruiker dit via een terugmelding doorgegeven aan de betreffende bronhouder.
De gegevensmagazijncomponent kan technisch beschouwd worden als een Operational Data Store (ODS).
Functies van de gegevensmagazijncomponent
Gebruiksdoelen van gegevensmagazijnsystemen zijn het inzage geven aan geautoriseerde gebruikers in (gecombineerde) gegevens en het via webservices bieden van bevragingsmogelijkheden. De gegevensmagazijncomponent is geoptimaliseerd voor het ontsluiten van gegevens die gerelateerd zijn aan één object. Voor het uitvoeren van selecties, analyses en complexe bevragingen is de gegevensmagazijncomponent minder geschikt. Hiervoor wordt het data-warehousecomponent gebruikt. De gegevensmagazijncomponent speelt een zeer belangrijke rol in de informatievoorziening naar burgers en bedrijven. De gegevensmagazijncomponent wordt gebruikt voor het ontsluiten van de (persoons)gegevens naar burgers en bedrijven. Deze component dient hiermee als buffer tussen de gemeentelijke processen en bronsystemen en de burger. Zie voor een nadere toelichting over deze inzet van het gegevensmagazijncomponent ook Informatievoorziening voor dienstverleningsprocessen
Er kleven nadelen aan de redundante opslag van gegevens van basis- en kerngegevens. De gegevens van de gegevensmagazijncomponent moeten synchroon worden gehouden met de bronregistratie om te voorkomen dat verkeerde gegevens worden gebruikt in processen. Deze synchronisatie moet secuur uitgevoerd en gemonitord worden. Dit kost menskracht en middelen.
Data-warehousecomponent
Net als bij de gegevensmagazijncomponent worden ook in de data-warehousecomponent verschillende actuele gegevens samengebracht. Beide componenten worden gebruikt voor de opslag van gegevens en de ontsluiting van deze gegevens naar afnemers. In tegenstelling tot een gegevensmagazijncomponent wordt de data-warehousecomponent echter niet via mutatieberichten maar via ETL-processen gevoed. Ook bevat de data-warehousecomponent meer gegevens dan enkel de RSGB-gegevens. De data-warehousecomponent bevat naast de basisgegevens ook gegevens uit sectorale informatiesystemen en kernregistraties. Binnen de data-warehousecomponent worden deze gegevens onderling in verband gebracht. De data-warehousecomponent wordt typisch gevuld via ETL processen die met een bepaalde frequentie, bijvoorbeeld één keer per week, uitgevoerd worden. De actualiteit van gegevens in de data-warehousecomponent is daarmee (veel) lager dan die van een gegevensmagazijncomponent. Data-warehousesystemen zijn geoptimaliseerd voor het snel kunnen verwerken van grote hoeveelheden gegevens en bieden toegang tot de gegevens via een ‘datamart’. Een datamart bevat een deel van de gegevens uit het data-warehousecomponent en is meestal geoptimaliseerd op het efficiënt beantwoorden van vragen van een specifiek domein of thema. Data-warehousesystemen worden voornamelijk gebruikt voor het uitvoeren van data analyses en rapportages.
Functies van de data-warehousecomponent
Data-warehousesystemen bieden, net als een gegevensmagazijn, geen functionaliteit voor het muteren van gegevens in de data-warehouse. Indien gegevens gewijzigd moeten worden dan dient dit plaats te vinden via de aanleverende bronsystemen of via de in de verschillende ETL-processen vastgelegde regels. Afnemers van gegevens uit een data-warehousecomponent zijn onder andere managementinformatiecomponenten.
Zaakregistratiecomponent
De zaakregistratiecomponent is de component die gegevens over zaken opslaat en ter beschikking stelt aan geautoriseerde afnemers. De zaakregistratiecomponent krijgt gegevens aangeleverd vanuit één of meer referentiecomponenten die het afhandelen van zaken/processen ondersteunen. Dergelijke componenten zijn bijvoorbeeld de zakenafhandelcomponent en taakspecifieke componenten zoals een Vergunningencomponent of een WOZ-administratiecomponent.
Implementaties van de zaakregistratiecomponent implementeren minimaal de opslag van de gegevens die in het Referentiemodel Gemeentelijke Basisgegevens Zaken (RGBZ) gedefinieerd zijn. De zaakregistratiecomponent wordt via de StUF zaakservices van de meest actuele gegevens voorzien.
Functies van de zaakregistratiecomponent
Loggingcomponent
De loggingcomponent is de component binnen de informatiearchitectuur die centraal de bewerkingen die gebruikers uitvoeren vastgelegd. Hetzelfde geldt voor andere relevante gebeurtenissen, zoals pogingen om ongeautoriseerd toegang te krijgen tot gegevens en verstoringen die kunnen leiden tot verminking of verlies van gegevens. De verschillende gemeentelijke referentiecomponenten maken gebruik van diensten die door de loggingcomponent worden geboden om logentries aan te leveren.
De gegevens die door de loggingcomponent worden bijgehouden kunnen door gemeenten worden gebruikt bij de beantwoording van Wob-verzoeken, beantwoording van inzageverzoeken van burgers, verantwoording van het gebruik van gegevens en ze kunnen door de functionaris voor de gegevensbescherming worden gebruikt bij het toetsen of gegevens conform gemaakte afspraken zijn verwerkt.
De loggingcomponent houdt onder andere de volgende gegevens bij:
- Identificerende sleutel;
- Identificatie van de gebruiker die de gegevens verwerkt heeft;
- Doel van de verwerking door de gebruiker;
- Datum en tijd van verwerking;
- Categorieën van attributen die verwerkt zijn.
Via de logging kan door geautoriseerde gebruikers bepaald worden wie, waarom, welke persoonsgegevens heeft verwerkt. De logging kan gebruikt worden voor het afleggen van over de verwerking van gegevens en kan gebruikt worden bij het bepalen of conform de gemeentelijke protocollen ten aanzien van de verwerking van persoonsgegevens gewerkt is. Het lijkt in het kader van de transparantie naar de burger ten aanzien van de verwerking van persoonsgegevens logisch om de door de loggingcomponent geregistreerde logging te ontsluiten via het MijnGemeente component. Hierbij moet worden opgemerkt dat in de loggingcomponent verwerkingen van (persoons)gegevens worden vastgelegd die niet geschikt zijn voor real-time transparantie. Denk hierbij bijvoorbeeld aan gegevens die in het kader van een fraude- of handhavingsonderzoek worden vastgelegd. Zolang dergelijke onderzoeken lopen is het bieden van transparantie hierover niet in het belang van het onderzoek. Dergelijke gegevens kunnen pas na afloop van het onderzoek met de burger gedeeld worden. De registratie van de loggingcomponent kan dus niet zonder nadere (handmatige) filtering aan de burger worden aangeboden.
Functies van de loggingcomponent
Bepaalde gegevens in de logbestanden zijn gekoppeld aan het BSN als identificerende sleutel en zijn dus herleidbaar tot personen. Er is daarmee sprake van een verwerking van persoonsgegevens in de zin van de Wbp. Een aandachtspunt voor gemeenten hierbij is dat indien de gemeentelijke systemen die personeelsgegevens verwerken gekoppeld zijn aan de loggingcomponent kan er sprake zijn van een personeelsvolgsysteem in de zin van artikel 27 lid 1 van de Wet op de ondernemingsraden (WOR), waarvoor instemming van de ondernemingsraad is vereist.
Het loggingcomponent wordt in 2017 in samenwerking met gemeenten en leveranciers functioneel en technisch uitgewerkt.
Open-data-portaalcomponent
De open-data-portaalcomponent is binnen de GEMMA architectuur de component waarmee gestructureerde publieke gegevens worden verzameld en beschikbaar gesteld aan afnemers. Via deze component wordt zowel aan interne als externe afnemers toegang geboden tot de publieke gegevens (open data) die door de verschillende informatiesystemen van de gemeente worden gegenereerd. Het portaal ordent de gegevens, transformeert deze desgewenst en biedt de gegevens aan op een manier dat deze downloadbaar is voor eindgebruikers en direct bruikbaar is voor gebruik binnen toepassingen. Vanuit (combinaties van) dit soort open gegevens kunnen veel nieuwe soorten diensten en apps ontwikkeld worden. Vaak zal dit in de vorm van apps voor smartphones en tablets zijn, maar ook voor pc-gebruik of andere apparaten zijn toepassingen goed mogelijk.
Functies van de open-data-portaalcomponent
Mijngemeentecomponent
Deze component biedt klanten toegang tot gepersonaliseerde digitale dienstverlening van de gemeente. Om toegang te krijgen tot de diensten van de mijngemeentecomponent authenticeren klanten zich via DigiD of eHerkenning. Na succesvolle authenticatie worden de digitale diensten beschikbaar voor de klant. Deze diensten kunnen bestaan uit het tonen van de over de klant geregistreerde gegevens, het tonen van de status van lopende zaken en mogelijkheden voor de klant om de eigen gegevens bij te houden.
Deze component speelt een belangrijke rol in de stimulering van de zelfredzaamheid van de klant en de bijbehorende verbetering van de informatiepositie van de klant. De component is de verbinding tussen klant en gemeente op het gebied van gepersonaliseerde digitale dienstverlening.
Functies van de mijngemeententecomponent
Via de generieke digitale infrastructuur van de overheid (GDI) wordt het MijnGemeente component aangeboden. Dit component biedt burgers inzage in de gegevens die de verschillende overheidsinstanties bijhouden. Via MijnOverheid wordt onder andere inzage gegeven in de gegevens die in bij de BRP, RDW en WOZ-administratie zijn vastgelegd. MijnOverheid en het MijnGemeentecomponent vertonen overlap van functionaliteit. Als de door MijnOverheid geboden functionaliteit aansluit bij de ambitie van de gemeente ten aanzien van transparantie naar de burger dan kan de gemeente er voor kiezen om het MijnGemeentecomponent lokaal niet in te vullen maar alleen aan te sluiten op MijnOverheid. Indien de gemeente andere, of meer, gegevens naar de burger wil ontsluiten dan door MijnOverheid ondersteund worden dan zal de gemeente dit via een MijnGemeentecomponent kunnen realiseren.
Ketenpartner-portaalcomponent
Via dit component wordt aan geautoriseerde ketenpartners toegang gegeven tot voor hen bestemde diensten. De ketenpartnerportaal-component authenticeert een ketenpartner en geeft daarna aan de ketenpartner toegang tot geautoriseerde diensten. Diensten die door gemeenten aan ketenpartners ter beschikking worden gesteld kunnen variëren in diensten die ketenpartners kunnen gebruiken voor het aanleveren van statistische- of verantwoordingsinformatie of diensten waarmee ketenpartners de voortgang melden van zaken die zij in opdracht, of onder regie van, de gemeente uitvoeren. De manier waarop de ketenpartners gegevens kunnen aanleveren of aangeleverd krijgen kan variëren van up- en downloadportalen tot webservices.
Het staat gemeenten vrij om zelf een authenticatiemiddel te kiezen om de diensten die geboden worden mee te beveiligen. Het meest voor de hand liggende middel bij diensten die via gebruikersschermen van de ketenpartner-portaalcomponent worden aangeboden is eHerkenning. Bij webservice georiënteerde diensten is een PKI(O) certificaat een logische keuze.
Functies van de ketenportaalcomponent