Common Ground generieke functies
Het Common Ground vijflaagsmodel bevat een aantal laagsgewijs gegroepeerde generieke functies. Een generieke functies beschrijft een bepaalde 'bekwaamheid' (in Archimate-termen 'capability') die nodig is om de gemeentelijke informatievoorziening in te richten conform de Informatiekundige visie Common Ground. Bij het realiseren van een generieke functie kunnen zowel bedrijfsmatige, informatiekundige als technologische aspecten een rol spelen. Vaak is daarbij sprake van een combinatie van afspraken, standaarden en voorzieningen.
Deze pagina beschrijft voor ieder van de 5 lagen de aanwezige generieke functies. De thema-architectuur Common Ground bevat ook Informatie over het vijflaagsmodel in hoofdlijnen en opbouw en gebruik van het model.
Functies in het Common Ground vijflaagsmodel (uit model: GEMMA 2) - Toon SVG - Download als csv
Laag Interactie[bewerken]
De interactielaag beschrijft de generieke functies die nodig zijn voor het verantwoord leveren van gebruikersinterfaces aan burgers, bedrijven en gemeentelijke medewerkers.
Interactielaag van het Common Ground vijflaagsmodel (uit model: GEMMA 2) - Toon SVG - Download als csv
Bieden van 'regie op gegevens' aan burgers en bedrijven[bewerken]
Burgers moeten in staat worden gesteld om regie te voeren op de eigen gegevens. Hiervoor moet de gemeente de volgende functionaliteiten realiseren:
- Inzage geven in de "eigen" gegevens: burgers moeten kunnen raadplegen welke gegevens een gemeente over hen bijhoudt.
- Inzage in het gebruik van gegevens: burgers moeten kunnen raadplegen welke gegevens door de gemeente zijn gebruikt of zijn uitgewisseld met keten- en netwerkpartijen en wat het doel daarvan was.
- Correctie van incorrecte gegevens: Burgers en bedrijven moeten een verzoek kunnen indienen om in hun optiek foutieve gegevens te corrigeren.
- Toestemming voor uitwisseling van gegevens: Burgers moeten voor bovenwettelijke gegevensuitwisselingen kunnen aangeven met welke partijen de gemeente wel en niet data mag delen.
Bovenstaande functies dragen bij aan transparantie, inzage en correctie, digitale zelfbeschikking en zelfredzaamheid, privacy, dataminimalisatie en kwaliteitsverbetering. Realiseren van deze functies vereist op elkaar afgestemde bedrijfsmatige en informatiekundige maatregelen. Bijvoorbeeld door een verwerkingenregister te maken waarin staat welke persoonsgegevens waarom worden gebruikt en door voorzieningen zoals een Persoonlijke Internet Pagina aan te bieden waarmee burgers zelf kunnen zien welke gegevens de gemeente over hen heeft en wat zij er mee doet.
Binnen het overheidsbrede programma Regie op Gegevens is een referentiearchitectuur gemaakt waarin de generieke functies zijn beschreven die nodig zijn om regie op gegevens door burgers mogelijk te maken.
Melden en doen van aanvragen door burgers en bedrijven[bewerken]
Inwoners en ondernemers moeten in staat worden gesteld om via verschillende kanalen bij de gemeente meldingen te doen en producten en diensten aan te vragen. Denk hierbij bijvoorbeeld aan het melden van een niet-werkende lantarenpaal via een melding openbare ruimte (MOR) of het aanvragen van een uittreksel uit de gemeentelijke basisregistratie personen. Gebruikers kunnen hiervoor gebruik maken van verschillende soorten interactievoorzieningen zoals formulieren op de gemeentelijke website of van speciale apps voor de smartphone of tablet.
Inwoners en ondernemers moeten ook online berichten met de gemeente kunnen uitwisselen. Bijvoorbeeld na ontvangst van een bericht of over een lopende zaak naar aanleiding van een ingediend verzoek. Afhankelijk van de vertrouwelijkheid van een bericht kan daarvoor van bepaalde kanalen gebruik worden gemaakt. Het project Omnichannel heeft uitgewerkt hoe gemeenten regie kunnen voeren op interactie via verschillende kanalen.
Authenticeren van eindgebruikers[bewerken]
De gemeente moet waar nodig gebruikers authenticeren om te weten met wie er wordt gecommuniceerd. Per dienst moet worden bepaald of, en zo ja met welk betrouwbaarheidsniveau, authenticatie nodig is. Voor een melding openbare ruimte of het maken van een afspraak bij de gemeente is authenticatie bijvoorbeeld niet noodzakelijk en voldoet het om de burger zelf identificerende gegevens in te laten voeren (of zelfs om de melding anoniem te laten doen). Voor andere soorten diensten, bijvoorbeeld als er persoonlijke gegevens bij zijn betrokken, is altijd een vorm van authenticatie nodig. Het Forum Standaardisatie biedt een handreiking om het betrouwbaarheidsniveau van diensten te bepalen.
Passend bij het betrouwbaarheidsniveau van een dienst moet een geschikt authenticatiemiddel worden gebruikt. De beschikbare authenticatiemiddelen voor burgers zijn vastgesteld in de Wet digitale overheid (Wdo). Het gaat hierbij om door de overheid verschafte authenticatiemiddelen op verschillende betrouwbaarheidsniveaus (laag, substantieel en hoog) en één of meer door marktpartijen aangeboden (private) middelen op de niveaus substantieel en hoog.
Voor authenticatie van burgers verschaft de overheid de DigiD-middelen. Daarnaast werkt het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (BZK) aan een raamwerk voor toelating van private middelen voor het BSN-domein. Voor medewerkers van bedrijven en overheidsorganisaties kan gebruik worden gemaakt van een eHerkenningsmiddel (met verschillende betrouwbaarheidsniveaus). Voor authenticatie van gemeentelijke medewerkers kan een eigen authenticatiesysteem worden ingericht. Om de kans op ongeautoriseerde toegang tot accounts te minimaliseren wordt steeds vaker gebruik gemaakt van een extra controle via twee-factor-authenticatie.
Autoriseren van eindgebruikers[bewerken]
Nadat via authenticatie met voldoende zekerheid is vastgesteld wie om toegang tot een dienst vraagt moet worden bepaald of de eindgebruiker over voldoende rechten beschikt om toegang te krijgen. Daarbij kunnen verschillende factoren een rol spelen zoals de functie van de betreffende actor, het doel waarvoor toegang wordt gezocht en de locatie en het tijdstip waarop om toegang wordt gevraagd.
Binnen de huidige praktijk situatie worden bedrijfsregels waarop autorisatie zich baseert vaak versnipperd en onvoldoende gedetailleerd vastgelegd. Bekende mechanismen waarbij eindgebruikers rechten krijgen via rollen ('Role Based Access') voldoen steeds minder om aan alle vereisten rondom autorisatie te kunnen voldoen. Mechanismen waarbij diverse soorten bedrijfsregels meer centraal worden vastgelegd en beheerd ('Policy Based Access') zijn hier meer geschikt voor maar vereisen veranderingen in zowel bedrijfsvoering als informatiearchitectuur. De GEMMA thema-architectuur Werken met APIs beschrijft hoe autorisatie op een adequate manier kan plaatsvinden en wat dit aan eisen stelt qua informatiearchitectuur.
De IBD levert een Handreiking Beleid logische toegangsbeveiliging BIO die beschrijft welke processen een gemeente moet inrichten voor authenticatie en autorisatie van gebruikers. Via vastgesteld beleid en organisatorische, procedurele en technische beheersingsmaatregelen moeten de juiste personen gebruik kunnen maken van verschillend geclassificeerde informatie, wordt dit gecontroleerd en is gebruik te verantwoorden.
Bieden van gebruikers interfaces[bewerken]
Burgers, medewerkers van bedrijven en gemeentelijke medewerkers moeten kunnen beschikken over interfaces om van gemeentelijke diensten gebruik te maken. Bijvoorbeeld via een webbrowser of een app op de smartphone.
De Common Ground visie stimuleert het werken met componenten die zich beperken tot het leveren van alleen de gebruikersinterface. Het doorlopen van een proces bij gebruik van de interface wordt idealiter aangestuurd door componenten waarmee bedrijfs- en procesregels zijn vastgelegd (in het Common Ground vijflaagsmodel gepositioneerd in de laag 'Procesinrichting'). Bij een proces behorende data is afkomstig uit bronregistraties en wordt ontsloten via gestandaardiseerde diensten. Door deze modulaire opbouw, waarbij in een taak gespecialiseerde componenten samenwerken, wordt het relatief eenvoudig om nieuwe interfaces te ontwikkelen. Bijvoorbeeld om verschillende doelgroepen te bedienen (bijvoorbeeld burgers en gemeentelijke medewerkers) of om functionaliteit via verschillende kanalen aan te bieden (bijvoorbeeld via de gemeentelijke website of via een smartphone-app).
Voor alle interfaces geldt dat ze digitaal toegankelijk moeten zijn overeenkomstig het tijdelijk besluit digitale toegankelijkheid overheid.
Laag Procesinrichting[bewerken]
De laag Procesinrichting beschrijft de functies die nodig zijn voor het conform wet- en regelgeving inrichten en uitvoeren van processen.
Procesinrichtinglaag van het Common Ground vijflaagsmodel (uit model: GEMMA 2) - Toon SVG - Download als csv
Inrichten en uitvoeren van processen[bewerken]
Om eindgebruikers op de juiste manier acties te laten uitvoeren moeten via de interactielaag de juiste schermen met daarop de juiste data worden getoond. Op basis van ingevoerde of opgehaalde data wordt een beslissing genomen óf en wélke volgende handeling moet worden uitgevoerd. Dit kan een handeling van een eindgebruiker zijn maar bijvoorbeeld ook het automatisch ophalen van data uit een bronregistratie en op basis daarvan uitvoeren van een volgende processtap. Om processtappen in de juiste volgorde te laten uitvoeren worden processen met behulp van specialistische componenten beschreven (bijvoorbeeld workflow- en Business Proces Management componenten).
De Informatiekundige visie Common Ground streeft naar het scheiden van functionaliteit voor het bieden van gebruikersinterfaces en functionaliteit voor het inrichten en uitvoeren van processen. In de praktijk combineren veel applicaties beide vormen van functionaliteit nog en is het niet eenvoudig om beide soorten functionaliteit consequent van elkaar te scheiden. Voor het inrichten van processen kan gebruik worden gemaakt van daarvoor ontwikkelde applicatiecomponenten zoals een workflow- of BPM-component. Via communicatie tussen zo'n ingerichte component en een interactiecomponent kan de laatste gebruikers de juiste proces-stappen laten doorlopen.
De GEMMA Procesarchitectuur ondersteunt het inrichten van gemeentelijke processen. Het onderdeel GEMMA Basisprocessen beschrijft een aantal principes voor het inrichten van processen om geautomatiseerd processtappen af te handelen en om gebruikersinteractie aan te sturen.
Bijhouden en toepassen van bedrijfsregels[bewerken]
Bij het uitvoeren van gemeentelijke processen spelen verschillende soorten bedrijfsregels een rol. Sommige bedrijfsregels komen voort uit geldende wet- en regelgeving, andere volgen uit gemeentelijk beleid of binnen afdelingen genomen beslissingen over hoe processen moeten worden uitgevoerd.
Bedrijfsregels zijn vaak ingebed in de software die zorgt voor de uitvoering van processen. Common Ground wil bedrijfsregels bevrijden uit die software en ze als zelfstandige objecten kunnen beheren. De gemeente krijgt daarmee een beter overzicht van regels en kan ze waar nodig zelf aanpassen. Dit biedt onder andere grote voordelen bij kennis- en regel-intensieve processen die vaak veranderen. Het leidt ook tot mogelijkheden voor meervoudig gebruik. Bijvoorbeeld door centraal vastgelegde autorisatieregels op meerdere plaatsen te gebruiken.
Voor het vastleggen van bedrijfsregels los van de procesinrichting en uitvoering is gebruik te maken van een Business Rule Management Systeem (BRMS). Daamee zijn bedrijfsregels vast te leggen, te muteren en classificeren en kan op consistentie tussen regels worden gecontroleerd.
Autoriseren van dienstengebruik[bewerken]
In lijn met de Informatiekundige visie Common Ground gaan afnemers steeds vaker gebruik maken van, ook buiten de eigen organisatie, aangeboden datadiensten. Voordat aanroep van een datadienst plaatsvindt moet worden gecontroleerd of de combinatie van gebruiker en applicatie over de benodigde rechten daarvoor beschikt. Alleen als dit het geval is mag de datadienst worden aangeroepen en mogen via de dienst verkregen data worden gebruikt.
Voor het controleren op de aanwezigheid van voldoende rechten is het, ook hier, wenselijk dat bedrijfsregels als zelfstandige objecten worden vastgelegd en beheerd. De thema-architectuur Werken met API's beschrijft wat er nodig is om gebruik van diensten via de aanroep van API's goed te kunnen autoriseren.
Wanneer een website of webapplicatie via een REST API persoonlijke data namens een gebruiker wil ophalen moet gebruik worden gemaakt van de NL GOV Assurance profile for OAuth 2.0 standaard.
Controleren van doel en grondslag dienstengebruik[bewerken]
Tijdens de interactie met eindgebruikers zijn vaak gegevens uit meerdere bronnen nodig. Denk bijvoorbeeld aan het bijwerken van persoonsgegevens in de basisregistratie personen of aan het ophalen van kadastrale perceelgegeven om gemeentelijke belastingen te kunnen heffen. Bij veel datadiensten geldt dat er een goede reden moet zijn om er gebruik van te mogen maken. Voor de verwerking van persoonsgegevens geldt het AVG-uitgangspunt dat gegevens alleen mogen worden verwerkt en verzameld voor 'een welbepaald, uitdrukkelijk omschreven en gerechtvaardigd doel'. 'Welbepaald en uitdrukkelijk omschreven' betekent dat voorafgaand aan het verzamelen van gegevens de verantwoordelijke het doel zodanig heeft omschreven dat is te bepalen of de gegevens nodig zijn voor dat doel. 'Gerechtvaardigd' betekent dat er een wettelijke grondslag of expliciete toestemming van de betrokkene moet zijn. In dit laatste geval moet de gemeente onomstotelijk kunnen aantonen dat deze expliciete toestemming voor gegevensverwerking ten tijde van de verwerking is verleend. Via de generieke functie 'Bieden van regie op gegevens aan burgers en bedrijven' moet de burger in staat worden gesteld om verleende toestemmingen te beheren (en dus ook te verwijderen).
Bij het gebruik van applicaties moet per functie worden aangegeven voor welk doel en met welke grondslag er gebruik van wordt gemaakt. De combinatie van doel en grondslag duiden we aan met de term 'doelbindingsclaim’. Het is de verantwoordelijkheid van de gemeente om te zorgen dat alleen daartoe bevoegde medewerkers gebruik kunnen maken van bepaalde functies.. Mede voor dit doel houdt de gemeente een Verwerkingsregister met informatie over de persoonsgegevens die worden verwerkt. De IBD biedt voor gemeenten een leeg verwerkingsregister en een voor-ingevuld verwerkingsregister.
Doelbindingsclaims voor gemeenten worden, zover dat mogelijk is, gestandaardiseerd. Dit betreft zowel de verwerkingsgronden voor privaat- als publiekrechtelijke taken met een wettelijke grondslag of voortkomend uit een lokale verordening als de doelbindingen die op basis van een toestemming van een burger verleend kunnen worden. Standaardisatie zorgt ervoor dat verwerkingsgronden tussen gemeenten onderling vergelijkbaar worden en maakt juridische validatie eenvoudiger.
Vastleggen van dienstgebruik[bewerken]
Gemeenten moeten kunnen verantwoorden welke gegevens zij waarom hebben gebruikt. Uitgangspunt is dat alle verwerkingen van gegevens op het moment van verwerking worden vastgelegd (zie Logging van verwerking van gegevens). Vastgelegde verwerkingsgegevens kunnen worden gebruikt om burgers en bedrijven inzage te geven in het gebruik van hun gegevens en om bijvoorbeeld een auditor te laten bepalen of gegevens rechtmatig zijn verwerkt. Daartoe worden voor iedere verwerking een aantal metagegevens vastgelegd waaronder datum en tijd van verwerking, betrokken eindgebruiker, gehanteerde doelbindingsclaim en (categorieën van) gegevens die zijn verwerkt.
De plicht om verwerkingen vast te leggen geldt zowel voor organisaties in de rol van dienstenafnemer als dienstenaanbieder. De integriteit van de vastlegging is gezien de rol die zij spelen bij het aantonen van rechtmatig handelen van cruciaal belang en moet dus bewaakt worden. Bijvoorbeeld door het verhinderen van van wijziging van vastgelegde data en het duurzaam toegankelijk houden van data (zie Handreiking Aanwijzing Logging (IBD)).
Het project Logging en verwerkingsactiviteiten werkt aan een landelijke API-standaard om invulling te gegeven aan de AVG-verplichting om verwerkingen van persoonsgegevens vast te leggen en verantwoording af te kunnen leggen over plaatsgevonden verwerkingen.
Laag Connectiviteit[bewerken]
De laag Connectiviteit beschrijft hoe dienstenaanbieders en dienstenafnemers (binnen en buiten de eigen organisatie) veilig verbinding met elkaar maken om data uit te wisselen. Denk hierbij aan generieke functies voor het vindbaar maken van diensten, fysieke netwerken voor het maken van verbinding, beveiliging en monitoring van netwerkverbindingen en het veilig via netwerken uitwisselen van data.
Connectiviteitfuncties van het Common Ground vijflaagsmodel (uit model: GEMMA 2) - Toon SVG - Download als csv
Bieden en gebruiken van communicatie-netwerken[bewerken]
Diensten worden naar burgers en bedrijven en gemeenten en ketenpartners ontsloten via openbare of private netwerkinfrastructuur. Burgers en bedrijven maken meestal gebruik van internet. Gemeenten en ketenpartners kunnen ook gebruik maken van gesloten netwerken. De keuze voor een netwerk is mede afhankelijk van het vereiste betrouwbaarheidsniveau van de betreffende dienst. De gevoeligheid en integriteit van de data die via de dienst worden verwerkt spelen daarbij een belangrijke rol.
Diensten die gesloten data verwerken kennen veelal een betrouwbaarheidsniveau dat uitwisseling via een besloten netwerk met eigen netwerkverbindingen en IP-adressen waarop alleen bepaalde typen organisaties kunnen aansluiten. Gemeenten en ketenpartners kunnen daarvoor gebruik maken van GGI-Netwerk dat als koppelnetwerk onderdeel uitmaakt van het overheidsbreed bruikbare Diginetwerk.
Diensten die open data verwerken kennen vaker een laag betrouwbaarheidsniveau en kunnen aan afnemers beschikbaar worden gesteld via een open netwerk zoals internet. Als een afnemer echter hoge eisen stelt aan de integriteit van de open gegevens en zeker wil weten dat gegevens tijdens transport niet wijzigen dan kan gekozen worden voor transport via een veiliger netwerk.
Beveiligen van communicatie-netwerken[bewerken]
Het beveiligen van communicatie-netwerken is onderdeel van informatiebeveiliging. Informatiebeveiliging omvat het geheel van preventieve, detectieve, repressieve en correctieve maatregelen alsmede procedures en processen die de beschikbaarheid, exclusiviteit of vertrouwelijkheid en integriteit van alle vormen van informatie binnen een organisatie of een maatschappij garanderen. Doelstelling is om de continuïteit van de informatie en de informatievoorziening te waarborgen en eventuele gevolgen van beveiligingsincidenten tot een acceptabel, vooraf bepaald niveau te beperken.
Om de digitale infrastructuur effectief te beveiligen is het inzetten van alleen 'klassieke' preventieve middelen zoals firewalls, antivirus, mail-filtering en indringer detectiesystemen niet meer voldoende. Geldende wet- en regelgeving maken aanvullende maatregelen zoals continue monitoring, analyse en signalering van dataverkeer nodig om voldoende weerbaar te zijn tegen dreigende inbreuken op de informatieveiligheid. De IBD besteedt in meerdere handreikingen aandacht aan manieren om communicatie-netwerken te beveiligen (bijvoorbeeld via netwerksegmentering).
Door als gemeenten samen te werken wordt het gemakkelijker om stapsgewijs de eigen digitale weerbaarheid te verhogen. GGI-Veilig bestaat uit een portfolio van producten en diensten voor operationele informatiebeveiliging voor gemeenten.
Verbinden van afnemers en aanbieders[bewerken]
Dienstenafnemers moeten met behulp van overeengekomen afspraken, standaarden en voorzieningen op een voldoende veilige manier verbinding kunnen maken met diensten van dienstenaanbieders. Afnemers moeten daarvoor informatie over aangeboden diensten krijgen en er moet een veilige verbinding tussen aanbieder en afnemer kunnen worden gemaakt. Het fysieke transport van uitgewisselde data verloopt via communicatie-netwerken.
Wanneer beveiliging van transport nodig is wordt meestal gebruik gemaakt van Transport Layer Security (TLS). TLS is een beveiligingsprotocol om de privacy en de integriteit van via een netwerk verzonden data te waarborgen. Het heeft onder andere als functie om vast te kunnen stellen of daadwerkelijk met de beoogde partij wordt gecommuniceerd en om uitgewisselde data te versleutelen en integriteit daarvan te waarborgen. Naast 1-weg TLS-verificatie, waarbij de afnemer kan vaststellen wie de aanbieder is, kan in situaties waar de identiteit van beide partijen bekend moet zijn ook gebruik worden gemaakt van 2-weg TLS-verificatie. Dit is bijvoorbeeld nodig bij gebruik van een API waarbij privacygevoelige data wordt verstrekt. Voor veel toepassingen is het gebruik van TLS verplicht om te kunnen voldoen aan privacyregelgeving zoals de Algemene Verordening Gegevensbescherming (AVG).
VNG Realisatie ontwikkelt momenteel de Federatieve Service Connectiviteit standaard (FSC). Het doel van deze standaard is om te zorgen dat dienstenafnemers op een gestandaardiseerde en geautomatiseerde manier via HTTP verbinding kunnen maken met dienstenaanbieders. Gebruik van API's wordt daardoor eenvoudiger, beheerslasten worden lager en er ontstaan nieuwe innovatiemogelijkheden. FSC biedt onder andere 'gedelegeerde toegang'. Dit maakt het niet langer nodig dat een gemeente certificaten moet verstrekken aan partijen waar zij SAAS-diensten afnemen die daarmee namens een gemeente diensten bij een derde partij kunnen afnemen. De FSC-standaard is toepasbaar bij gebruik van bestaande API-gateway producten en wordt op termijn mogelijk onderdeel van de Digikoppeling-standaarden.
Publiceren en gebruiken van informatie over datadiensten[bewerken]
Dienstenafnemers moeten in online catalogi kunnen opvragen welke diensten door dienstenaanbieders worden aangeboden. Naast algemene kenmerken zoals aanbiedende organisatie en gebruiksdoelen zijn met name de specificaties van beschikbare API's van belang. In lijn met de Nederlandse API strategie is het wenselijk dat extern toegankelijke API's worden geregistreerd in een centraal vindbare openbare catalogus (tenzij dit om beveiligingsredenen niet gewenst is).
Een dienstencatalogus biedt aan ontwikkelaars :
- Een overzicht van beschikbare diensten en APIs ('wat is er allemaal?)
- API life-cycle informatie ('hoe ziet het versiebeheer er uit?')
- Criteria voor gebruik ('is een API key of PKI-certificaat nodig?')
- API-specificatie ('welke operaties kent een API precies en hoe kan ik er gebruik van maken?')
- API-informatie ('wat moet ik weten om de API op een juiste manier te gebruiken?'
Een dienstencatalogus heeft enkel design-time een functie. Op run-time-niveau, tijdens de uitvoering van processen, wordt de dienstencatalogus niet gebruikt en vormt dus geen "single point of failure" voor communicatie tussen dienstenafnemers en dienstenaanbieders. De website developer.overheid.nl biedt een overzicht van door Nederlandse (semi-)overheidsorganisaties aangeboden API's, inclusief bijbehorende specificatie en aanvullende informatie om gebruik er van te vergemakkelijken.
Om afnemers kennis van een dienst te laten vergroten kan eventueel ook een test- of uitprobeer-faciliteit worden aangeboden. Afnemers kunnen daarmee op een relatief eenvoudige manier in een testomgeving gebruik maken van een dienst. Op basis van opgedane ervaringen kan dan bijvoorbeeld besloten worden of er gebruik gemaakt gaat worden van de dienst of om in de eigen omgeving voorbereidingen te treffen voor toekomstig gebruik van de dienst.
Het Common Ground programma heeft, net als veel andere overheidsprogramma's, een voorkeur voor API's die werken volgens de REST-architectuurstijl. Voor dit type API's moet de API-specificatie voldoen aan de OpenAPI Specification standaard.
Laag Diensten[bewerken]
De Informatiekundige visie Common Ground streeft naar een gemeentelijke informatievoorziening waarbij uitvoerende processen maximaal gebruik maken van data die is vastgelegd in bronregistraties. Gebruik wordt mogelijk gemaakt via diensten die aanbieders leveren. Bijvoorbeeld diensten voor het authenticeren en autoriseren van afnemers, voor het ontsluiten van bronregistraties en voor vastleggen van welke diensten voor welk doel door wie zijn gebruikt.
Naast het onderscheid in het type functionaliteit dat diensten leveren is ook onderscheid te maken naar de aard van een dienst. In lijn met de Nederlandse API strategie worden 3 type diensten (of API's die als toegangspunt tot een dienst fungeren) onderscheiden:
- Systeem Dit type dienst werkt op het niveau van de databron en is gericht zijn op het ontsluiten en bijwerken van de brongegevens. Bijvoorbeeld het opvragen van vastgelegde entiteiten of het toevoegen van een nieuwe zaak aan een zakenregistratie. Hiervoor volstaat vaak de zogenaamde CRUD-functionaliteit waarmee data is aan te maken, lezen, wijzigen en verwijderen.
- Proces Dit type dienst gebruikt bestaande systeemdiensten om een nieuwe wenselijke dienst te maken. Bijvoorbeeld door data uit meerdere bronnen te combineren en gebundeld te verstrekken of door data zodanig te transformeren dat ze voor afnemers beter bruikbaar zijn.
- Convenience Dit type dienst, dat gebruik maakt van onderliggende proces- en systeemdiensten, biedt functionaliteit ten behoeve van specifieke gebruikersbehoeften. Bijvoorbeeld om op te vragen of een bepaalde persoon ouder is dan 18 jaar of om data te ontvangen in een formaat dat geschikt is voor mobiele devices.
Systeemdiensten zijn altijd nodig om toegang te krijgen tot brondata. Proces- en/of convenience-diensten zijn optioneel. Soms volstaan data-gerichte systeemdiensten die elementaire operaties bieden om data op te vragen of te bewerken. In andere gevallen is het wenselijk dat diensten 'gedraggedreven' zijn en aansluiten op specifieke behoeften van bedrijfsprocessen of front-end applicaties van dienstenafnemers. In die situaties zijn proces- en/of convenience-diensten nodig.
Dienstenlaag van het Common Ground vijflaagsmodel (uit model: GEMMA 2) - Toon SVG - Download als csv
Authenticeren van dienstenafnemers[bewerken]
Voor veel diensten moet voorafgaand aan gebruik de identiteit van een dienstenafnemer met voldoende zekerheid worden vastgesteld. Onder andere om daarna op basis van autorisatieregels te kunnen vaststellen of de afnemer het recht heeft om van de dienst gebruik te maken. Leveren van een dienst aan een niet-gerechtigde dienstenafnemer kan leiden tot een datalek, misbruik van data en schade voor burgers, bedrijven of gemeente.
Het betrouwbaarheidsniveau van een dienst is afhankelijk van de data die de dienst verwerkt en moet per dienst worden vastgesteld (zie Betrouwbaarheidsniveaus digitale dienstverlening). Het authenticatiemiddel dat wordt gebruikt moet hetzelfde of een hoger niveau hebben dan het betrouwbaarheidsniveau van de dienst. Voor gebruik van een dienst die geclassificeerd is op betrouwbaarheidsniveau 'substantieel' is dus minimaal een authenticatiemiddel op niveau 'substantieel' vereist.
Dienstenaanbieders zijn verantwoordelijk voor het vaststellen van het betrouwbaarheidsniveau van diensten en het in lijn daarmee bepalen van toegangsregels. Binnen de Common Ground informatie-architectuur wordt het principe van 'gedelegeerde autorisatie' toegepast. Dit betekent dat dienstenaanbieders autorisatie uitvoeren op het niveau van de aanroepende organisatie en niet op het niveau van de betrokken eindgebruiker of applicatie. Daarbij geldt de afspraak dat dienstenafnemers zelf verantwoordelijk zijn voor authenticatie en autorisatie binnen de eigen organisatie. Hierbij is sprake van de aggregatie van identiteiten van een specifiek naar een generiek niveau. Als de betrokken eindgebruiker een burger of gemeentelijke medewerker is wordt bij aanroep van een dienst de identiteit van de betreffende gemeente leidend.
Bij aanroep van een dienst wordt naast de identiteit van de aanroepende partij ook de doelbindingsclaim voor de gevraagde verwerking doorgegeven. De dienstenaanbieder kan beide metagegevens vastleggen om plaatsgevonden gebruik van diensten te verantwoorden. Er is hierbij sprake van een "vertrouwen vooraf, controle achteraf" werkwijze. Deze leidt tot een beheersbare en overzichtelijke inrichting van toegangsbeheer waarbij achteraf is te bepalen of partijen rechtmatig hebben gehandeld. Een voorbeeld van deze werkwijze is:
Om te kunnen bepalen of iemand recht heeft op een gemeentelijke parkeervergunning raadpleegt een parkeerapplicatie de GBA-V. Bij de aanroep van de GBA-V wordt door gemeente de identiteit van de gemeentelijke professional omgezet naar “gemeente xxx”. Door de GBA-V wordt vervolgens geautoriseerd op niveau “gemeente xxx mag inwoners muteren en de rest van Nederland raadplegen”. Door de gemeente wordt vastgelegd welke gemeentelijke professional de persoonsgegevens heeft geraadpleegd in het kader van het afgeven van een gemeentelijke parkeervergunning en door de GBA-V wordt vastgelegd dat de gemeente xxx een raadpleging van een persoon heeft gedaan in het kader van het afgeven van een gemeentelijke parkeervergunning.
Binnen de overheid wordt voor de identificatie van organisaties gebruik gemaakt van PKIoverheid-certificaten: computerbestanden die werken als een digitaal paspoort. Een persoonsgebonden PKI-overheid certificaat is bruikbaar om een bepaalde persoon veilig elektronische (internet-)transacties uit te laten voeren. een PKI-overheid servicescertificaat is gebonden aan een organisatie en wordt uitgegeven aan apparaten, servers of groepen individuen. Binnen de Common Ground informatiearchitectuur maken zowel aanbieders als afnemers voor data-uitwisseling gebruik van PKI-overheid services-certificaten.
Wanneer diensten data verstrekken die een openbaar karakter heeft (zie Wat is open data) gelden vaak beperkte of geen authenticatie-eisen. Desalniettemin kan een gemeente er voor kiezen om gebruik te maken van een private verbinding zoals GGI-Netwerk en tweezijdig TLS (bijvoorbeeld om te garanderen dat data tijdens het transport niet worden gemanipuleerd). De AVG en de BIO bevatten richtlijnen welke maatregelen bij bepaalde type diensten nodig zijn.
Autoriseren van dienstenafnemers[bewerken]
Dienstaanbieders moeten bij aanroep van een dienst bepalen of de betreffende dienstenafnemer beschikt over de benodigde rechten om van de dienst gebruik te maken. Bij voorkeur wordt voor autorisatie gebruik gemaakt van generieke voorzieningen die autorisatiegegevens overzichtelijk, inzichtelijk en goed beheersbaar vastleggen.
Bij 'Authenticeren van dienstenafnemers' is toegelicht hoe het principe van gedelegeerde autorisatie wordt toegepast. Dit heeft als consequentie dat voor een volledige beoordeling of gebruik van een dienst rechtmatig heeft plaatsgevonden zowel informatie bij de dienstenafnemer als de dienstenaanbieder moet worden ingewonnen. Het relateren van op beide plaatsen vastgelegde gebruiksdata is mogelijk door bij aanroep van de dienst een uniek kenmerk ('correlatie-id') mee te geven dat zowel bij afnemer als aanbieder wordt vastgelegd.
Toegang tot diensten is onderdeel van de set aan afspraken tussen dienstenaanbieder en dienstenafnemer, ook wel gegevensleveringsovereenkomsten (GLO) genoemd. De GEMMA thema-architectuur Data beschrijft in algemene zin benodigde afspraken over rollen en verantwoordelijkheden. De dienstenaanbieder moet afspraken vertalen naar concrete toegangsregels die bepalen onder welke voorwaarden toegang tot een dienst is toegestaan. Daarbij kunnen verschillende soorten attributen een rol spelen (bijvoorbeeld organisatietype, doelbindingsclaim, tijdstip waarop toegang wordt gevraagd).
De keuze voor hoe toegangscontrole precies wordt ingericht hangt af van de specifieke vereisten en context. De GEMMA thema-architectuur Werken met API's beschrijft een aantal benaderingen voor het inrichten en beheren van toegangscontrole (bijvoorbeeld Rol- Attribute- en Policy-Based Access Control).
Vastleggen en verstrekken van data[bewerken]
De Informatiekundige visie Common Ground kent als uitgangspunt dat processen maximaal gebruik maken van data uit bronregistraties. Bij voorkeur worden daarbij geen lokale kopieën van brondata gebruikt. Om dit te kunnen realiseren moeten dienstenafnemers toegang krijgen tot brondata via door dienstenaanbieders geleverde diensten. We duiden dit type data-georiënteerde diensten aan met de term 'datadiensten'.
Datadiensten moeten dienstenafnemers in staat stellen om, waar toegestaan, brongegevens op te vragen, creëren, bewerken en verwijderen. In termen van het acroniem 'CRUD' zijn 'Create', 'Read', 'Update' en 'Delete' de fundamentele functies voor gebruik van brondata. Voor uitvoering van iedere operatie geldt dat voorafgaand aan uitvoering:
- altijd moet worden gecontroleerd of de afnemer beschikt over de benodigde rechten. De GEMMA thema-architectuur Werken met APIs beschrijft een aantal methodieken en inzetbare voorzieningen om dit op een beheersbare manier te laten plaatsvinden.
- altijd informatie over het verzoek moet worden vastgelegd (los van of het verzoek wordt ingewilligd). Het project Logging en verwerkingsactiviteiten ontwikkelt een API-standaard om invulling te gegeven aan de AVG-verplichting om verwerkingen van persoonsgegevens vast te leggen en om verantwoording af te kunnen leggen naar de burger over plaatsgevonden verwerkingen.
Binnen Common Ground geldt dat vastleggen en verstrekken van data bij voorkeur gebeurt door middel van API's die werken conform de REST-stijl en het lichtgewicht dataformaat JSON. Voor het ontwerp van zo'n API geldt de REST-API Design Rules standaard. Het project API-referentiearchitectuur werkt uit welke uitgangspunten en principes ontwerpers van API-standaarden het beste kunnen gebruiken.
Terugmelden van mogelijke datafouten[bewerken]
Bronhouders moeten afnemers van data in staat stellen om twijfels over de correctheid van brondata door te geven ('terugmelden'). Aan de hand daarvan kunnen fouten in brondata na onderzoek waar nodig worden hersteld. Dit bevordert de kwaliteit en actualiteit van vastgelegde data en, in het geval van burgers, wordt voldaan aan de (AVG-)verplichting om hen in staat te stellen de 'eigen gegevens' te (laten) corrigeren.
Hoewel het wettelijke recht op terugmelden vanuit de AVG ('correctierecht') alleen geldt voor persoonsgegevens en gegevens die naar een persoon herleidbaar zijn, geldt vanuit het oogpunt van betere datakwaliteit voor iedere bronregistratie dat terugmelding moet worden ondersteund. Voor de landelijke basisregistraties geldt voor afnemers een wettelijke plicht om bij gerede twijfel mogelijk onjuiste gegevens te melden aan de bronhouder.
Functionaliteit voor terugmelden kan door dienstenaanbieders worden gerealiseerd door een combinatie van diensten, zoals:
- Een API waar geautomatiseerd een terugmelding kan worden doorgegeven.
- Een notificatiefunctie om de indiener van een terugmelding op de hoogte te stellen van de afhandelstatus.
- Een bevragingsdienst waar de indiener de status en het resultaat van afhandeling kan opvragen.
Het is wenselijk dat, net zoals bij de basisregistraties het geval is, een terugmeldstandaard voor andere bronregistraties beschikbaar komt.
Abonneren op en notificeren van gebeurtenissen[bewerken]
Een uitgangspunt binnen de Informatiekundige visie Common Ground is dat maximaal gebruik wordt gemaakt van data uit bronregistraties. Om onnodige kopieën van brondata te voorkomen is het wenselijk dat afnemers brondata opvragen op het moment dat ze nodig zijn. Hiermee is echter niet gegarandeerd dat eerder opgevraagde brondata op een later moment nog actueel zijn. Bij processen waarbij het belangrijk is dat er met actuele en betrouwbare (bron)data wordt gewerkt moeten afnemers worden geïnformeerd als zich gebeurtenissen hebben voorgedaan die tot wijziging in brondata hebben geleid.
Basisregistraties leveren voor dit doel nog vaak "was-wordt-mutatiebestanden" aan afnemers. Verstrekte data wordt dan verwerkt in gemeentelijke registraties waarbij vaak uit mutaties moet worden afgeleid welke gebeurtenissen hebben geleid tot datamutaties. Deze werkwijze is niet wenselijk omdat actualiteit en betrouwbaarheid van data niet optimaal zijn en omdat er zo lokale kopieën van brondata ontstaan.
Dienstenaanbieders moeten dienstenafnemers in staat te stellen zich te abonneren op voor hen relevante gebeurtenissen. Wanneer een gebeurtenis van een bepaald type heeft plaatsgevonden notificeert de dienstenaanbieder alle daarop geabonneerde dienstenafnemers zodat zij op de hoogte zijn van het feit dat er een bepaalde gebeurtenis heeft plaatsgevonden en dat als gevolg daarvan bepaalde brondata is gewijzigd.
Notificeren van afnemers kan plaatsvinden via informatie-arme of informatie-rijke notificatieberichten. Een informatie-arm bericht bevat een minimale set aan sleutel- en contextdata. De berichtontvanger daarvan kan op basis daarvan alleen bepalen of bepaalde interne processen moeten worden opgestart. Met de ontvangen sleuteldata zal hij in veel gevallen nog een dienst moeten aanroepen om aanvullende inhoudelijke data op te vragen. Bij een informatie-rijk notificatiebericht worden naast sleutelgegevens ook een aantal inhoudelijke gegevens verstrekt. De berichtontvanger ontvangt dan direct alle benodigde data en hoeft normaal gesproken geen aanvullende data meer op te vragen. Informatie-arm en informatie-rijk notificeren kennen beide voor- en nadelen in gebruik. Het is context-afhankelijk welke vorm het meest geschikt is.
Een voorbeeld van abonneren en notificeren is de situatie waarin een afnemer een abonnement afsluit op wijzigingen in de persoonlijke gegevens van een bepaald persoon. Op het moment dat in de persoonsregistratie een wijziging optreedt, bijvoorbeeld als de persoon is verhuisd, wordt een notificatie over deze wijziging gestuurd naar alle geabonneerde afnemers. Een afnemer kan in het notificatiebericht zien dat er een verhuizing heeft plaatsgevonden als gevolg waarvan de persoonsgegevens van de bij het abonneren opgegeven persoon zijn gewijzigd. De afnemer kan op basis van deze informatie besluiten om wel of geen actie te ondernemen.
Event-driven architecture (EDA) is een architectuurstijl die de nadruk legt op het gebruik van gebeurtenissen ('events') om veranderingen en acties binnen een systeem te activeren en te communiceren. Bij EDA worden systemen ontworpen om zelf plaatsgevonden gebeurtenissen te publiceren en om te reageren op door andere systemen gepubliceerde gebeurtenissen. In 2021 is in opdracht van het Ministerie van Binnenlandse Zaken het project Notificatieservices uitgevoerd met als doel om als overheid beter en vaker event-driven te kunnen werken en daarvoor om een standaard te ontwikkelen voor geautomatiseerd notificeren. De projectdocumentatie bevat een aantal achtergronddocumenten en handreikingen over event-driven werken en notificeren. Sinds 2022 is de ontwikkelde NLGOV profile for CloudEvents standaard in beheer bij Logius.
Vastleggen van dienstgebruik[bewerken]
Zowel dienstenafnemers als dienstenaanbieders moeten data over het (gevraagd) gebruik van diensten vastleggen ('loggen'). Daarbij worden een aantal attributen vastgelegd zoals de datum en tijd van de aanroep en de identificatie van de organisatie die de dienst heeft aangeroepen. Om vastgelegde gegevens bij afnemer en aanbieder aan elkaar te kunnen koppelen voor een totaalbeeld moet een uniek identificerend attribuut worden gecommuniceerd en vastgelegd ('correlatie-iD').
Organisaties die persoonsgegevens verwerken zijn conform de Algemene Verordening Gegevensbescherming (AVG) en de Uitvoeringswet AVG verplicht om aan te kunnen tonen dat een verwerking van persoonsgegevens voldoet aan de belangrijkste beginselen van verwerking zoals rechtmatigheid, transparantie, doelbinding en juistheid.
Om vastlegging verantwoord en gestandaardiseerd te laten plaatsvinden moet aan een aantal voorwaarden zijn voldaan. Het project Logging en verwerkingsactiviteiten beschrijft randvoorwaarden waar de gemeentelijke architectuur aan moet voldoen. Bijvoorbeeld het inrichten van een gemeentelijk verwerkingsregister met doelen en wettelijke grondslagen voor verwerkingsactiviteiten en het gebruik van interactiepatronen waarbij componenten en registers samenwerken.
Standaardisatie van de vastlegging van verwerkingen is nodig om de eenduidigheid en toegankelijkheid van logging-gegevens te verbeteren en beter bruikbaar te maken. VNG-Realisatie heeft de Verwerkingenlogging API-standaard ontwikkeld als onderdeel van de uitwerking van de Informatiekundige visie Common Ground. Deze API-standaard biedt leveranciers van informatiesystemen API-specificaties om metagegevens over vastgelegde (gelogde) verwerkingen vast te leggen en te ontsluiten. Het ministerie van Binnenlandse Zaken heeft deze standaard geadopteerd en ontwikkelt die verder tot overheidsbreed geldende standaard.
Transformeren van data[bewerken]
Bij het leveren van datadiensten kan het nodig zijn om data om te zetten in een andere structuur of vorm voordat ze aan afnemers worden geleverd. Bijvoorbeeld om te zorgen dat verstrekte data goed bruikbaar zijn voor afnemers. Het kan daarbij gaan om eenvoudige transformaties zoals het omzetten van een datumformaat 'yyyymmdd' naar 'dd-mm-yyyy' of om meer complexe transformaties zoals het converteren van coördinaten naar een ander geodetisch coördinatensysteem.
Transformatie maakt het lastiger om de bron en de oorspronkelijke betekenis van gegevens te bepalen. Bij voorkeur kennen bronregisters op elkaar afgestemde informatiemodellen zodat zo min mogelijk transformatie nodig is. Gemeenten hebben nu echter te maken met partijen die eigen afspraken en standaarden kennen dus zal data-transformatie soms nodig zijn.
Integreren van data[bewerken]
Om een goed bruikbare datadienst te kunnen leveren moeten soms data uit verschillende bronnen worden gecombineerd tot een enkele consistente weergave van data. Bijvoorbeeld om te voorkomen dat alle afnemers meerdere opvragingen moeten doen en ontvangen resultaten zelf moeten combineren. Wanneer een aanbieder data integreert binnen 1 dataset worden afnemers ontzorgt en ontvangen zij allemaal dezelfde gecombineerde data.
Een voorbeeld is een datadienst die antwoord geeft op de vraag: “Wat is het volledige adres bij deze postcode?”. Hiervoor zal de datadienst bij de Basisregistratie Adressen en Gebouwen (BAG) meerdere zoekvragen stellen en vervolgens de verkregen 'Openbare Ruimte naam’, 'Nummeraanduiding' en 'Woonplaats' gecombineerd binnen 1 antwoord aan een afnemer verstrekken.
Eerder is binnen diensten onderscheid gemaakt in systeem-, proces- en convenience-diensten. Een proces-dienst maakt gebruik van een of meer systeem-diensten om data uit bronregistraties te ontsluiten en vervolgens te transformeren en/of integreren tot een dataset.
Pseudonimiseren van data[bewerken]
Bij het pseudonimiseren van data worden persoonlijke gegevens verwerkt tot een vorm waarbij de identiteit van de betrokken personen zonder aanvullende informatie niet is vast te stellen. Identificerende data, zoals een BSN of een persoonsnaam, worden via een algoritme vervangen door versleutelde data (het pseudoniem). Omdat het algoritme voor een persoon altijd hetzelfde pseudoniem produceert is het mogelijk om data over 1 persoon uit verschillende bronnen te combineren. Als wordt beschikt over de juiste aanvullende informatie zijn gepseudonimeerde data te herleiden naar een persoon.
Pseudonimiseren is een beveiligingsmaatregel die het privacyrisico van de betrokkenen vermindert en het bewerkingsrisico voor organisaties verkleint. Het maakt het bijvoorbeeld mogelijk om persoonlijke data te analyseren en daarbij te voldoen aan relevante wetgeving. Pseudonimiseren is een verwerking van persoonsgegevens dus is de AVG van toepassing. Gepseudonimiseerde gegevens moeten bijvoorbeeld goed worden beveiligd.
Bij anonimiseren worden persoonlijke gegevens zodanig gewijzigd dat de identiteit van de betrokken personen niet meer kan worden vastgesteld. Geanonimiseerde data zijn daarom geen persoonsgegevens en de AVG is daarop dan ook niet van toepassing. Aandachtspunten daarbij zijn dat álle herleidbare persoonsgegevens moeten worden geanonimiseerd en dat het anonimiseren geautomatiseerd gebeurt of door wordt uitgevoerd door medewerkers die geautoriseerd zijn om de betrokken persoonsgegevens in te zien.
Bij transactionele processen, waar bij Common Ground de nadruk op ligt, kan pseudonimeren in bepaalde situaties wenselijk of zelfs verplicht zijn. Anonimiseren is hierbij normaal gesproken niet van toepassing.
Laag Databronnen[bewerken]
De laag Databronnen beschrijft de functies die nodig zijn om data in overeenstemming met de geldende wet- en regelgeving vast te leggen en via diensten bij te houden en ontsluiten.
Databronnen van het Common Ground vijflaagsmodel (uit model: GEMMA 2) - Toon SVG - Download als csv
Gestandaardiseerd vastleggen van data[bewerken]
In lijn met de Informatiekundige visie Common Ground worden bronregistraties gestandaardiseerd. Onderdeel hiervan is het beschrijven van de syntax en samenhang van data in een informatiemodel. Daarin wordt een domein beschreven met behulp van objecten, attributen, relaties en andere belangrijke informatie. Om informatiemodellen beter op elkaar aan te laten sluiten hebben VNG Realisatie, Kadaster en Geonovum het Metamodel voor Informatiemodellen (MIM) ontwikkeld. Het MIM bevat afspraken over specificaties op verschillende niveaus (begrippenmodel, conceptueel informatiemodel, logisch informatie- of gegevensmodel, fysiek of technisch gegevens- of datamodel). Informatiemodellen fungeren als basis voor het ontwerp van fysieke data-opslag en het ontwerpen van diensten voor data-ontsluiting.
Daar waar eerder slechts een klein deel van de gemeentelijke data via informatiemodellen is gestandaardiseerd (RSGB, RGBZ, ImZTC, ImGeo en Raadsinformatie), is de ambitie nu om meer gemeentelijke kernregistraties en sectorale registraties te standaardiseren. Dit betekent dat nieuwe informatiemodellen ontwikkeld worden voor bijvoorbeeld het sociaal- en het belastingen-domein waarbij aangesloten wordt op bestaande landelijke of sectorale informatiemodellen. Mogelijk wordt binnen omvangrijke domeinen een opsplitsing naar sub-domeinen of thema’s gemaakt, waardoor binnen een domein meerdere informatiemodellen ontstaan. Het sociaal domein kent bijvoorbeeld een groot aantal taken, waardoor opsplitsing in kleinere delen een optie is (bijvoorbeeld jeugdzorg, maatschappelijke ondersteuning en werk en inkomen).
Uitgangspunt daarbij is dat als er landelijk vastgestelde data-specificaties zijn die worden gevolgd. Voorbeeld hiervan zijn het Suwi gegevensregister (SGR) en IMBOR voor de openbare ruimte. Voor gemeentelijke data geldt dat standaardisatie altijd onder regie van gemeenten plaatsvindt. Waarbij het om verschillende soorten data kan gaan, zoals data over:
- generieke objecten zoals 'zaken' en 'documenten'. Een voorbeeld is het project Verwerkingenlogging dat standaardisatie beoogd van vast te leggen metagegevens van verwerkingen. Op basis van opgestelde infomatiemodellen is op basis daarvan een API-standaard ontwikkeld.
- domeinspecifieke objecten zoals 'paspoort' of 'parkeervergunning'. Een voorbeeld van standaardisatie binnen het sociaal domein is een ontwikkelde ontologie voor het Inkomensdomein met daarin onder andere begrippen ('concepten') en modellen per onderwerp ('subject areas').
- kerndata zoals lokale organisatiedata (bijvoorbeeld 'afdelingen' en 'medewerkers') en data over geleverde 'producten' en 'diensten'. Een voorbeeld van overheisbrede standaardisatie is de Uniforme Productnamenlijst (UPL) met daarin de namen van alle door de overheid aan burgers en bedrijven geleverde producten en diensten. De samenhang tussen de UPL met de gemeentelijke producten en diensten catalogus (PDC), de zaaktypecatalogus (ZTC) en het verwerkingsregister wordt hier beschreven.
Het Gemeentelijk Gegevensmodel (GGM) is een logisch gegevensmodel met daarin alle beleidsterreinen van de gemeente. Via het GGM wordt data ten behoeve van informatiegestuurd werken gestandaardiseerd. Meer informatie over de relatie tussen het GGM en de GEMMA is te vinden binnen de GEMMA thema-architectuur Data.
Vastleggen van metadata[bewerken]
Overheidsinformatie moet duurzaam toegankelijkheid zijn. (Ook) bronregistraties moeten voldoen aan de DUTO-eisen om te garanderen dat brondata vindbaar, beschikbaar, leesbaar (en bruikbaar), interpreteerbaar en betrouwbaar (authentiek en integer) is. Afhankelijk van het type data kunnen ook andere eisen gelden (bijvoorbeeld wettelijke eisen). Om aan geldende eisen te kunnen voldoen moeten data worden voorzien van relevante, volledige en actuele metadata die de karakteristieken van data-objecten beschrijven (bijvoorbeeld de naam en het moment van creatie), de context waarbinnen data-objecten zijn ontstaan en wat er daarna mee is gebeurd.
Goed vastleggen van metadata vereist voorzieningen die die 'by-design' hierop zijn voorbereid. Metadata wordt waar mogelijk automatisch gecreëerd en geüpdatete naar aanleiding van gebruik in processen en/of diensten. Metadata dragen bij aan het waarborgen van transparantie, verantwoording en duurzame toegankelijkheid van overheidsgegevens en maken het mogelijk om te voldoen aan de eisen vanuit wetten zoals de Archiefwet, AVG, Wet Openbaarheid van Bestuur (WOB), Wet hergebruik van overheidsinformatie (Who) en de Wet open overheid (Woo).
Vastleggen van historie[bewerken]
Vastleggen van historie binnen bronregistraties is nodig om de betrouwbaarheid, traceerbaarheid, verantwoording en bruikbaarheid van data te waarborgen, om te voldoen aan wetgeving en om bijvoorbeeld trends te kunnen analyseren. De Informatiekundige visie Common Ground streeft naar maximaal gebruik van brondata door afnemers en het zoveel mogelijk voorkomen van lokale kopieën. Afnemers hebben daardoor niet voldoende aan het kunnen opvragen van actuele data maar moeten ook kunnen bevragen wat de situatie in het verleden was ('tijdreizen'). Bronregistraties moeten daarom relevante toestandsveranderingen van data zodanig bewaren dat historie van data opvraagbaar is. Bij voorkeur inclusief de aanleiding en aard van plaatsgevonden veranderingen.
Bij het beschrijven van historie is onderscheid te maken in materiële historie en formele historie. Met materiële historie wordt de situatie in de werkelijkheid bedoeld (bijvoorbeeld wanneer een verhuizing plaatsvond). Met formele historie de situatie in de registratie (bijvoorbeeld wanneer de verhuizing is geregistreerd). Voor afnemers kunnen beide soorten historie van belang zijn. Bronregistraties moeten data daarom zodanig vastleggen dat beide soorten informatie opvraagbaar is.
Het vastleggen en voor afnemers beschikbaar stellen van historie is niet eenvoudig. Bijvoorbeeld omdat context en perspectief van partijen kan verschillen en omdat zich bijzondere soorten gebeurtenissen kunnen voordoen (bijvoorbeeld correcties, data die 'in onderzoek' worden gezet en wijzigingen met terugwerkende kracht). Onderstaande pagina's zijn voorbeelden van hoe nu binnen de overheid wordt omgegaan met tijdreizen en historie:
- De StUF-standaarden en gebruik van materiële en formele historie.
- De Standaard Officiële Publicaties en ondersteuning van tijdreizen.
- De BAG implementatie van historie.
Voor gemeenten zijn zowel in- als externe bronregistraties van belang. Bij voorkeur vindt standaardisatie op dit vlak dan ook overheidsbreed plaats. Er zijn meerdere overheidsprogramma's waarbij historie een punt van aandacht is (bijvoorbeeld binnen de Interbestuurlijke Datastrategie).
Protocolleren van datavastlegging[bewerken]
Voor veel typen data geldt dat het vastleggen ervan plaatsvindt volgens een bepaalde set regels, richtlijnen of protocollen ('protocollering'). Het doel hiervan is om een gedetailleerde en gestructureerde registratie te creëren van wat er is gebeurd en tot welke data-wijzigingen dit heeft geleid. Op basis hiervan is verantwoording af te leggen over uitgevoerde administratieve handelingen, zijn privacy- of beveiligingsincidenten traceerbaar en kan transparantie richting betrokken personen worden geboden. Afhankelijk van de specifieke context en de vereisten kan de vorm waarin protocollering plaatsvindt variëren. Bij voorkeur worden relevante gebeurtenissen automatisch vastgelegd.
De reikwijdte van het begrip protocollering is oorspronkelijk beperkt tot de Wet Basisregistratie Personen die voorschrijft dat alle handelingen van een systeem dat de Wet implementeert in beginsel door het systeem zelf moeten worden vastgelegd. In de protocollering is onder meer vastgelegd welke data uit de registratie wanneer, door wie, over wie en aan wie zijn verstrekt. Het vormt hiermee een belangrijk bestanddeel in het BRP-stelsel om de persoonlijke levenssfeer van burgers te beschermen en om achteraf te kunnen bepalen of verstrekking van data rechtmatig was. Binnen de Informatiekundige visie Common Ground geldt voor iedere bronregistratie dat er protocollering moet plaatsvinden.