Tweede VNG-leveranciersbijeenkomst vernietigingsfunctionaliteit – naar centrale vernietiging

Op 9 december vond de tweede VNG-leveranciersbijeenkomst plaats over het onderwerp vernietiging, zie ook deze blog over de eerste bijeenkomst. Het volledige verslag kun je hier lezen. Onderwerp van gesprek was de positie van vernietiging binnen GEMMA-gegevenslandschap. Ivo Hendriks, architect bij VNG Realisatie, gaf daarover deze presentatie. In dit artikel lichten we enkele discussiepunten uit.

Centrale vernietigingsfunctionaliteit, hoe zou dat kunnen werken?
Omdat gemeenten een veelvoud aan informatiebronnen hebben, is er behoefte om vanuit een centraal punt meerdere bronnen te kunnen beheren. Er is een aantal manieren te bedenken om vanuit zo’n centraal punt te kunnen vernietigen. In theorie zou dit mogelijk zijn door rechtstreeks de bronnen te benaderen, het alternatief is om vanuit een centraal punt decentrale vernietigingsfunctionaliteit aan te roepen. Die laatste optie werd tijdens de bijeenkomst als meest haalbare scenario beschouwd. Dit houdt in dat een informatiebeheerder ogenschijnlijk vanuit één informatiebeheerapplicatie vernietiging uitvoert. Onder de motorkap, vraagt deze applicatie aan diverse andere applicaties of ze informatie hebben die voor vernietiging in aanmerking komt. Vanuit het centrale punt kunnen er vernietigingslijsten worden gemaakt, waar nodig informatieobjecten van vernietiging worden uitgezonderd en vervolgens een opdracht aan de onderliggende systemen worden verstrekt om daadwerkelijk te vernietigen. Vervolgens komt er een notificatie terug in het centrale informatiebeheersysteem dat de vernietiging succesvol is uitgevoerd.
Zie ook de conceptuele weergave in onderstaande afbeelding.

In een zuiver gegevenslandschap zou de de ‘informatiebeheerapplicatie’ (wat in feite een combinatie is van taakapplicatie in de bovenste twee lagen + een bijbehorende dienst, rode cirkel) direct de bronregisters en bijbehorende diensten (oranje cirkel) bevragen. Tijdens de transitie daarheen verwachten we echter dat applicaties die hele silo’s omspannen opgeslagen gegevens middels API’s aan andere applicaties beschikbaar gaan stellen.

Implicatie van nieuwe opzet gegevenslandschap
Binnen de principes van Common Ground worden gegevens verdeeld over verschillende registers. Elk register is een authentieke bron met soortgelijke gegevens. Zo is er een besluitenregister, een objectenregister en zo verder. Een element in een register kan door meerdere processen en applicaties gebruikt worden.

Hierbij treedt al snel spraakverwarring op. Een informatieobject is een op zichzelf staand geheel van gegevens met een eigen identiteit. Het ‘geheel’ bestaat in bovenstaande plaat uit een gegevensobject in combinatie met ‘DUTO-metadata’ (metadata die nodig zijn om het informatieobject te kunnen beheren, dus om de DUurzame TOegankelijkheid te regelen) en ‘Vorm- en domeinspecifieke metadata’ (inhoudelijke metadata). Dus één gegevensobject kan onderdeel zijn van meerdere informatieobjecten.

Dat betekent dat als de bewaartermijn van het ene dossier verlopen is, maar van het andere nog niet, het gegevenselement nog niet vernietigd kan worden. Als je gaat vernietigen, moeten deze relaties dus bekend zijn en dat roept de vraag op hoe dit het best geregeld kan worden. In de discussie werd de voorkeur uitgesproken om deze relaties in de bron, dus in de registers zelf, vast te leggen. Deze zouden onderdeel kunnen zijn van de ‘DUTO-metadata’. Als de verwijzing naar een specifieke toepassing wordt verwijderd, dan bestaat het informatieobject dus niet meer. Terwijl een deel daarvan technisch wel blijft bestaan.

Onderstaande afbeelding geeft een sterk vereenvoudigd voorbeeld weer van een registratie. In dit voorbeeld een registratie van kleuren, waarin wordt weergegeven hoe de kleur ‘groen’ is vastgelegd in dit register. Dit is een object dat in meerdere zaken is betrokken. De weergegeven metadata zijn voorbeelden, in de praktijk kan (en zal) er natuurlijk meer metadata worden vastgelegd.

Bij de DUTO-metadata (in dit voorbeeld slechts gedeeltelijk ingevuld, hier zou bijvoorbeeld ook nog de bewaartermijn kunnen staan), is aangegeven in welke dossiers het gegevenselement ‘groen’ allemaal voorkomt. Een informatieobject is een geheel van gegevens. Dat betekent dat in bovenstaand voorbeeld drie informatieobjecten bestaan. Deze zijn als volgt opgebouwd:

Elk informatieobject bestaat uit drie onderdelen in onderlinge samenhang. In het onderste blokje zijn deze verwerkt tot informatie. Informatieobject 1 bestaat dus uit onderdelen A1, B1 en C1. Als onderdeel B1 wordt vernietigd, dan bestaat Informatieobject 1 niet meer. Tegelijkertijd moeten elementen A1 en C1 beschikbaar blijven omdat die tevens onderdeel zijn van Informatieobject 2 en Informatieobject 3. Gegevensobject A1 kan in dit voorbeeld dus pas worden vernietigd als ook Informatieobjecten 2 en 3 vernietigd zijn. Behalve als je ‘A1’ ziet als bijvoorbeeld een object in een basisregister dat ook op zichzelf, dus los van eventuele gerelateerde zaken relevant is.

Diverse uitdagingen
Om deze oplossingsrichting te kunnen laten werken, zijn er diverse uitdagingen. Zo zal de centrale informatiebeheertoepassing allerlei verschillende API's moeten ondersteunen om te kunnen communiceren met de decentrale applicaties: om besluiten duurzaam te kunnen bewaren/beheren de besluiten-API, om zaken duurzaam te kunnen bewaren/beheren de zaken-API, om informatieobjecten duurzaam te kunnen bewaren/beheren de informatieobjecten-API etc. Daarnaast moet het datamodel van een register op basis van standaarden worden ingericht en is er complexiteit op het gebied van ketensamenwerking. Ook zijn er meer organisatorische vragen die bijvoorbeeld gaan over te hanteren definities. Leveranciers geven met praktijkvoorbeelden aan dat overheden er verschillende interpretaties op nahouden van hoe om te gaan met de wettelijke vernietigplicht, daar is dus werk aan de winkel om met elkaar tot meer consensus te komen. Maar ook aan de kant van de leveranciers bestaan dergelijke verschillen. Zo liet een leverancier weten niet te willen deelnemen aan deze sessies omdat ze in hun oplossing alleen data opslaan en geen documenten, waardoor ze in hun ogen niet met de Archiefwet te maken hebben.

Een idee is om dit mechanisme eerst op kleine schaal uit te proberen, met eenvoudige processen. Het zal bovendien ingewikkeld worden om legacy-systemen aan te sluiten, maar als de aansluiteisen bekend zijn dan kunnen die bij vernieuwing wel worden meegenomen door ze als eisen op te nemen bij een aanbesteding. Op die manier zou het concept kunnen groeien.

Vervolgstappen
In februari staan twee bijeenkomsten gepland. De eerste is bedoeld voor gemeenten, de bedoeling is om dan use cases op te halen. Daarbij hopen we dat er een aantal gemeenten zich bereid zullen tonen om actief mee te werken aan de ontwikkeling. Een week later is er een derde bijeenkomst met leveranciers waar mede op basis van de verzamelde use cases de volgende stap in de concrete uitwerking van het model wordt gezet.

Tijdens de Themadag Vernietiging in een Digitale Wereld op 23 januari, zal er bovendien een break-outsessie over dit onderwerp worden verzorgd.