Common Ground informatiearchitectuur

Category:Common Ground
__NOTOC__
De huidige gemeentelijke informatievoorziening biedt onvoldoende mogelijkheden biedt om de ambities van gemeenten op het vlak van het ondersteunen van burgers, bedrijven en de interne organisatie te realiseren (zie Aanleiding vernieuwing gemeentelijke informatievoorziening). Processen die gebruik maken van gegevens zijn slechts beperkt gestandaardiseerd, niet afzonderlijk en autonoom aan te spreken of uit te voeren en niet eenduidig en onweerlegbaar vastgelegd. Gegevens die worden gebruikt vanuit processen zijn daarnaast beperkt gestandaardiseerd waardoor de uitwisselbaarheid van gegevens beperkt is. Daarnaast vergt het voldoen aan onder andere privacy- en informatiebeveiliging wet- en regelgeving met huidige inrichting veel inspanning van gemeenten. Een andere inrichting van de informatievoorziening is nodig om gemeenten in staat te stellen om hun taken op een effectieve en efficiënte wijze uit te voeren. Belangrijke doelen die met de nieuwe inrichting worden nagestreefd zijn:
* Gemeenten de regie geven over de eigen gegevens;
* Verhogen van de uitwisselbaarheid van gegevens;
* Interne en externe transparantie over de verwerking van gegevens;
* De burger zeggenschap geven over de "eigen" gegevens;
* Eenvoudig kunnen voldoen aan vigerende wetgeving onder andere op het gebied van informatiebeveiliging en bescherming van de privacy;
* Stimuleren van innovatie van eindgebruikerstoepassingen.
Gemeenten moeten kunnen groeien naar een situatie waarin burgers effectief en efficiënt worden gefaciliteerd in hun rechten. Daarnaast moet de gemeente zowel voor interne als externe transparantie op eenvoudige, en liefst geautomatiseerde wijze, inzage kunnen geven welke medewerker of rol, op welk moment toegang heeft gehad tot vertrouwelijke gegevens of deze heeft bewerkt. Om dit te kunnen realiseren worden de onderstaande aantal principes nagestreefd.
* Werken met componenten die afgebakende functionaliteit kennen en via gestandaardiseerde interfaces communiceren. Een hierop gebaseerde informatievoorziening stelt gemeenten in staat om wendbaar en innovatief te opereren omdat wijziging of vervanging per component mogelijk wordt;
* Maximaal openstellen van gegevens voor hergebruik. Het delen en gebruiken van gegevens wordt slechts beperkt door wetgeving en niet door ideeën over het gebruik van gegevens. Door als overheid open te zijn waar dit kan, wordt de informatiepositie van klanten versterkt, wordt publiek/private samenwerking gefaciliteerd en neemt het vertrouwen in de overheid toe;
* Zorg dragen voor een goede beveiliging van gegevens en garanderen van de bescherming van de privacy. Om invulling te kunnen geven aan zowel verwachtingen van de burger als de wettelijke vereisten realiseren we een samenhangend geheel van technische, organisatorische, fysieke en procedurele maatregelen;
* Eenmalige inwinnen en vastlegging van gegevens en voorkomen van kopieën van brongegevens. Brongegevens worden alleen bewerkt bij de bron en komen via diensten beschikbaar voor processen die ze nodig hebben;
* Faciliteren van persoonlijk datamanagement voor partijen die daartoe gerechtigd zijn. Persoonlijk datamanagement draagt bij aan transparantie, inzage en correctie, digitale zelfbeschikking, privacy, dataminimalisatie, de kwaliteitsverbetering van gegevens en zelfredzaamheid van mensen;
* Standaardisatie op alle gebieden waar dit meerwaarde levert door het maken van afspraken en standaarden. Afspraken en standaarden zijn nodig om effectief, efficiënt en veilig samen te werken en informatie uit te wisselen. Ze zijn ook nodig om voldoende onafhankelijk te blijven en de juiste samenwerkingspartners te kunnen kiezen.
Toepassing van het bovenstaande krijgen gemeenten grip op de gegevenshuishouding waardoor ze wendbaarder kunnen opereren en daardoor effectievere dienstverlening kunnen leveren aan burgers en bedrijven. Verantwoording afleggen over de verwerking van gegevens en de redenen van verwerking zowel naar bestuur als naar afnemers wordt hierdoor eenvoudiger. Gemeenten worden daardoor in staat gesteld om op een eenvoudigere manier compliant aan wet- en regelgeving te werken.
== Organisatorisch werkingsgebied ==
De Common Ground informatie-architectuur is de doelarchitectuur die behoort bij de informatiekundige visie Common Ground. Het organisatorisch werkingsgebied voor de Common Ground informatie-architectuur is primair gemeenten en gemeentelijke samenwerkingsverbanden. Het model is echter ook bruikbaar voor andere overheidslagen en bevoegd gezagen.
== Functioneel werkingsgebied ==
De Common Ground informatie-architectuur is primair gericht op transactionele dienstverlening. Het is geen model voor bijvoorbeeld streaming datadiensten zoals VoiP of streaming sensordata. Voor ondersteuning van data-gedreven werken en business intelligence biedt het model aanknopingspunten, maar voor met name business intelligence en data-intensieve bewerkingen moet onderzocht worden in hoeverre de geschetste architectuur werkbaar is, en onder welke voorwaarden dit het geval is. 
== Scheiding van rollen ==
In de Common Ground informatie-architectuur worden processen gescheiden van de data die voor de uitvoering van processen nodig zijn. Daarvoor is een goede samenwerking nodig tussen partijen (bijvoorbeeld organisaties of applicaties) nodig waarbij zij verschillende rollen vervullen. Binnen de Common Ground informatie-architectuur gelden een aantal specifieke uitgangspunten en afspraken rondom rollen. Deze zijn beschreven binnen de toelichting op het Common Ground vijflaagsmodel opbouw en gebruik. 
== Bevraging bij de bron ==
Belangrijk uitgangspunt van de Common Ground informatie-architectuur is dat gegevens bij gebruik zoveel mogelijk uit de bron worden opgehaald. Gegevens worden bij voorkeur niet als kopie-gegevens opgeslagen in eigen lokale registers. Een afnemer verkrijgt gegevens voor gebruik binnen een proces via diensten die door een dienstenaanbieder worden geboden. 
 
In de Common Ground informatie-architectuur wordt met een bronregister een gegevensbron bedoeld die beheerd wordt door de bronhouder. Een voorbeeld: gemeenten zijn bronhouder van de persoonsgegevens van hun inwoners. Deze gegevens van inwoners worden door gemeenten opgeslagen in de Basisregistratie Personen (BRP). Er zijn in Nederland dus net zoveel BRP’s als dat er gemeenten zijn. Alle gegevens uit de gemeentelijke BRP’s worden samengebracht in een landelijke afslag: de GBA-V. Dat betekent niet dat de GBA-V niet als een bron voor persoonsgegevens kan worden gebruikt. Het gebruik van een dergelijke voorziening is een oplossing als het raadplegen van het bronregister (de gemeentelijke BRP) niet mogelijk of niet praktisch is. In het geval van de gemeentelijke BRP’s zou het bijvoorbeeld zo moeten zijn dat al deze bronregisters van gemeenten 24x7 bevraagbaar zouden moeten zijn voor externe partijen. Dat is in de praktijk op dit moment niet zo, waardoor het bevragen van de gemeentelijke BRP geen praktische optie is. In dit geval biedt bevraging van de landelijke voorziening GBA-V een acceptabel alternatief voor bevraging van de gemeentelijke BRP’s. In de visie van de Common Ground informatie-architectuur zijn dergelijke landelijke voorzieningen in principe tijdelijke voorzieningen. Indien het technisch en organisatorisch mogelijk is om de bronhouders te bevragen heeft dat de voorkeur.
Het is de bedoeling om redundante opslag van gegevens te voorkomen en gegevens te bevragen bij de bron. Het is echter mogelijk dat er redenen zijn om binnengemeentelijk toch informatiesystemen te hanteren die geen gebruik maken van dit architectuurpatroon. Dit kan bijvoorbeeld het geval zijn bij systemen die breder worden gebruikt dan enkel de gemeentelijke markt. Denk hierbij bijvoorbeeld aan een financieel- of HR-systeem of document managementsysteem wat ook in de private sector wordt toegepast. Een dergelijk systeem zal bijvoorbeeld persoonsgegevens redundant opslaan aangezien die systemen bij inzet in de private sector geen toegang krijgen tot de basisregistratie personen. De gemeente heeft in dat geval geen andere keuze dan accepteren dat er gegevens redundant worden opgenomen.
De gemeente dient wel maatregelen te nemen om de kwaliteit en de toegang tot en gebruik van redundante gegevens te borgen. Een andere reden om gegevens redundant op te slaan kan zijn dat een bron niet kan voldoen aan de gewenste SLA, bijvoorbeeld doordat de bron de gewenste responsetijden niet haalt, geen historie bijhoudt of niet 24x7 beschikbaar is. Als een bron wel voldoet aan alle eisen die gesteld worden aan de bron, dan is het wel de bedoeling dat de bron ook direct bevraagd wordt en de gegevens niet meer redundant opgeslagen worden.
== Authenticatie, autorisatie en open en gesloten data ==
Voor veel diensten geldt dat de identiteit van een dienstenafnemer met voldoende zekerheid moet worden vastgesteld. Onder andere om daarna op basis van autorisatieregels vast te kunnen stellen of de afnemer het recht heeft om van de dienst gebruik te maken. Een uitzondering zijn diensten die data verstrekken met een openbaar karakter (zie Wat is open data) omdat daarbij vaak beperkte of geen authenticatie-eisen gelden.  
Binnen de Common Ground informatie-architectuur gelden een aantal specifieke uitgangspunten rondom authenticatie en autorisatie. Deze zijn beschreven in de generieke functies 'Authenticeren van dienstenafnemers', 'Autoriseren van dienstenafnemers' binnen Common Ground generieke functies.
== Doelbinding voor gegevensverwerking ==
Voor de verwerking van persoonsgegevens is conform privacywetgeving een doel en een verwerkingsgrondslag vereist. De grondslag kan bijvoorbeeld bestaan uit een wettelijke verplichting, of toestemming die een persoon heeft afgegeven ten aanzien van de verwerking van zijn of haar gegevens. Het doel geeft aan waarvoor de gegevens verwerkt worden. In dit document noemen we de combinatie van doel en grondslag de doelbinding. Uitgangspunt binnen de Common Ground informatie-architectuur is dat afnemers bij ieder verzoek om gegevens, ongeacht of dit persoonsgegevens zijn, de doelbindingsclaim aangeven voor de verwerking. Indien vanuit een eindgebruikersfunctie gegevens worden verwerkt dan wordt door deze functie de doelbindingsclaim voor de verwerking vastgelegd. Deze doelbindingsclaim is een verklaring van de afnemer over doel en grondslag van de verwerking. Deze claim wordt bij elke verwerking ten behoeve van transparantie en verantwoordingsdoeleinden vastgelegd. In deze vastlegging worden onder andere de gebruikte dienst, de eindgebruiker en de doelbindingsclaim meegenomen. De weerslag van de vastlegging kan achteraf worden gebruikt om een overzicht samen te stellen waarmee achteraf bepaald kan worden of de verwerking van gegevens rechtmatig is geweest.
EU-AVG artikel 4: "verwerking": een bewerking of een geheel van bewerkingen met betrekking tot persoonsgegevens of een geheel van persoonsgegevens, al dan niet uitgevoerd via geautomatiseerde procedés, zoals het verzamelen, vastleggen, ordenen, structureren, opslaan, bijwerken of wijzigen, opvragen, raadplegen, gebruiken, verstrekken door middel van doorzending, verspreiden of op andere wijze ter beschikking stellen, aligneren of combineren, afschermen, wissen of vernietigen van gegevens
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. Door deze standaardisatie wordt gewaarborgd dat de verwerkingsgronden tussen gemeenten onderling vergelijkbaar, en juridisch gevalideerd zijn.
Verwerkingen die door een dienstenafnemer of dienstenaanbieder worden uitgevoerd worden. Bij de vastlegging wordt opgenomen wat de doelbindingsclaim voor de verwerking is zodat zowel naar de burger als bestuur verantwoording kan worden afgelegd over gegevensverwerkingen. Zowel de dienstenafnemer als de dienstenaanbieder legt verwerkingen vast. De partij die de verwerking initieert stelt een uniek transactie-id samen wat door alle partijen binnen de transactie wordt gebruikt bij de vastlegging. Via dit logtransactie-id zijn vastleggingen van dienstenaanbieders en -afnemers aan elkaar te relateren waardoor een keten van verwerkingen kan worden opgebouwd.
== Privacy en security ==
Een van de uitgangspunten van de Common Ground informatie-architectuur is zorg dragen voor een goede beveiliging van data en garanderen van de bescherming van privacy. Om invulling te kunnen geven aan zowel verwachtingen van de burger als aan de wettelijke vereisten is een samenhangend geheel van technische, organisatorische, fysieke en procedurele maatregelen nodig. Verschillende uitgangspunten binnen de Common Ground architectuur dragen bij aan privacyborging, zoals:
* Eenmalige vastlegging en wijziging van brondata en meervoudig gebruik daarvan. Hierdoor wordt de kans op datalekken en onbevoegde verwerkingen van data verkleind. 
* Diensten worden "smal" gehouden en zijn leveren proportioneel data voor een specifiek doel.
* Toegang tot diensten is alleen mogelijk bij aantoonbare doelbinding van de afnemer.
* Alle activiteiten waar men vanuit wetgeving of beveiligingsdoelen toe verplicht is worden vastgelegd waardoor controle op de rechtmatigheid van plaatsgevonden verwerking mogelijk is.
De thema-architectuur Privacy en Informatiebeveiliging werkt het onderwerp privacy meer in detail uit.
== Standaardisatie via informatiemodellen ==
Gemeenten nemen, met ondersteuning van VNG Realisatie, de regie over de standaardisatie van de gemeentelijke gegevens. Daar waar anno 2018 slechts een klein deel van de gemeentelijke gegevens via informatiemodellen is gestandaardiseerd (RSGB, RGBZ, ImZTC, ImGeo en Raadsinformatie), worden in de nieuwe inrichting op termijn ook gemeentelijke kernregistraties en sectorale registraties gestandaardiseerd via informatiemodellen. Dit betekent dat nieuwe informatiemodellen ontwikkeld worden voor bijvoorbeeld het sociaal- en het belastingen domein en dat aansluiting gezocht wordt bij bestaande informatiemodellen zoals het IMBOR voor de openbare ruimte. Het is mogelijk dat binnen omvangrijke domeinen een opsplitsing naar sub-domeinen of thema’s wordt gemaakt en daardoor binnen een domein meerdere informatiemodellen ontstaan. Denk hierbij bijvoorbeeld aan het sociaal domein. Dit domein omvat een groot aantal taken, waardoor opsplitsing in kleinere delen voor de hand ligt. Te denken valt dan bijvoorbeeld aan aparte informatiemodellen voor de taken die gemeenten hebben ten aanzien van de jeugdzorg, maatschappelijke ondersteuning en werk en inkomen.
Door het standaardiseren van informatiemodellen is standaardisatie van de toegang tot gegevens via diensten mogelijk. Op het moment dat vanuit dienstverlening een door gemeenten breed gedeelde behoefte aan gegevens ontstaat, kan er een standaardisatietraject starten. In dit traject wordt samen met gemeenten en marktpartijen de behoefte aan gegevens voor de betreffende processen geïnventariseerd, waarna vanuit deze behoefte een informatiemodel wordt ontwikkeld. VNG Realisatie kan regie voeren over de totstandkoming en de inhoud van de modellen. Onderdeel van het regie voeren over informatiemodellen is ook het governance model wat gehanteerd wordt. Per informatiemodel moet worden bepaald wat de meest voor de hand liggende standaardisatiepartij en bijbehorende governancestructuur is.
== Standaardisatie van gegevensontsluiting ==
Dienstenaanbieders maken gegevens beschikbaar via diensten. Diensten doen dit bij voorkeur via een applicatie interface, ofwel Application Programming Interface (API). Een applicatie-interface is een toegangspunt waar applicatieservices beschikbaar worden gesteld. Binnen de overheid zijn afspraken gemaakt ten aanzien van de technische- en gebruiksaspecten van APIs. Deze afspraken beogen te bereiken dat binnen de overheid APIs op vergelijkbare wijze werken en beveiligd worden.
De ontwikkeling van APIs wordt afgestemd op vragen die vanuit de dienstverlening en processen worden gesteld. Hierdoor wordt geborgd dat APIs aansluiten op de behoefte die vanuit afnemers leeft. De gegevens die door de APIs worden ontsloten conformeren zich aan de gestandaardiseerde informatiemodellen. Hierdoor wordt de uitwisselbaarheid van gegevens bevorderd, en is voor alle partijen duidelijk wat de syntax, samenhang en betekenis (semantiek) van de gegevens is. Bij de ontwikkeling van diensten worden marktpartijen in een vroeg stadium betrokken, aangezien zij uiteindelijk de partijen zijn die de diensten realiseren en leveren.
Een API wordt niet ontworpen en gebouwd voor een machine, maar voor een gebruiker: een mens! Om een goede gebruikerservaring te bieden is het belangrijk om te weten voor wie ontworpen en gebouwd wordt. Vanuit de landelijke API-strategie worden een aantal aanbevelingen gedaan ten aanzien van de ontwikkeling van APIs.
== Standaardisatie van processen ==
Door standaardisatie van processen is potentieel veel winst te halen voor gemeenten. Op het moment dat gemeenten op hoofdlijn dezelfde processen hanteren, wordt het standaardiseren van de ondersteunende informatiesystemen eenvoudiger dan het nu is, en wordt samenwerking tussen gemeenten en de onderlinge uitwisseling van gegevens (portabiliteit) eenvoudiger en kan gemeentelijke dienstverlening naar inwoners en bedrijven eenduidiger plaats gaan vinden. Standaardisatie van processen leidt daarnaast tot standaardisatie van de vraag om gegevens vanuit de processen. Dit vereenvoudigt, en versnelt, de ontwikkeling van informatiemodellen en daarop gebaseerde APIs.
== Relatie met de GEMMA informatiearchitectuur ==
De GEMMA is de referentiearchitectuur voor gemeenten. Passend bij een referentiearchitectuur hebben gebruikers zoals gemeenten en leveranciers een bepaalde mate van vrijheid om bij implementatie binnen hun context passende keuzes te maken. Dit geldt ook bij inrichting van de informatievoorziening gebaseerd op de GEMMA-informatiearchitectuur (onderdeel van de GEMMA basisarchitectuur). De thema-architectuur Common Ground gaat verder en beschrijft niet alleen 'wat' er nodig is binnen de informatiearchitectuur maar geeft ook vaak aan 'hoe' iets moet gebeuren.
Uitwerkingen binnen de thema-architectuur Common Ground kunnen uiteraard leiden tot aanpassingen binnen de GEMMA Basisarchitectuur. Een Common Ground uitgangspunt zoals het 'scheiden van data en processen' kan bijvoorbeeld leiden tot opslitsing van binnen de GEMMA-informatiearchitectuur benoemde GEMMA-referentiecomponenten in een proces- en een registratieve component.
Omdat zo'n verandering veel impact heeft op zowel de GEMMA Informatiearchitectuur als op de daaraan gekoppelde Softwarecatalogus worden dit type wijzigingen alleen doorgevoerd als er registers beschikbaar komen die via een gestandaardiseerd informatiemodel en daarop gebaseerde services ontsloten wordt. 
== Common Ground vijflaagsmodel en generieke functies ==
Voor beschrijving van de Common Ground informatiearchitectuur wordt intensief gebruik gemaakt van het Common Ground vijflaagsmodel. Dat model toont laagsgewijs de generieke functies ('capability's') die afnemers en aanbieders van diensten moeten realiseren om hun informatievoorziening in lijn met de Informatiekundige Visie Common Ground in te richten. In Common Ground generieke functies worden de benoemde generieke functies meer in detail uitgewerkt.