Archiveren

Auteur: Joeri Bekker | Status: In voorbereiding

Inleiding

Om goed te archiveren is een goede informatiehuishouding noodzakelijk. De Gemeentelijke Selectielijst biedt een belangrijke basis om te bepalen na hoeveel tijd archiefbescheiden (ofwel, procesgebonden informatie) moeten worden vernietigd danwel blijvend worden bewaard door overbrenging naar een e-depot. We limiteren in dit document de scope tot het vernietigen van digitale archiefbescheiden maar het proces om tot vernietigen te komen is gelijk aan die voor overbrengen / blijvend bewaren.

Doel

Het doel is om zoveel mogelijk digitale archiefbescheiden geautomatiseerd te vernietigen in het ICT-landschap zoals Platform Dienstverlening en Common Ground dat voor ogen hebben.

Om dit doel te bereiken, moet opnieuw gekeken worden naar alle mogelijke scenario's die spelen bij het bepalen van de archiefactiedatum: De datum waarop informatie moet worden vernietigd. Maar ook moet gekeken worden naar welke gerelateerde informatie eventueel mee moet worden vernietigd.

Bepalen wanneer te vernietigen

In veel gevallen staat een ZAAK centraal in het bepalen van de archiefactiedatum, vaak gecombineerd met het procesobject: Het object waar de uitvoering van het proces op van toepassing is (bijv. een financiële voorziening zoals een subsidie of schuldhulpverlening).

Het bepalen van de archiefactiedatum is echter niet altijd triviaal en er zijn veel verschillende scenario's die met name worden veroorzaakt door de procestermijn, die niet altijd van te voren bekend is (wanneer stopt bijv. de schuldhulpverlening, nadat schuldhulpverlening is toegewezen?).

De duur van de procestermijn is ingedeeld in verschillende categorieën:

  1. Nihil Er is geen aparte procestermijn, de bewaartermijn start direct.

  2. De bestaans- of geldigheidsduur van het procesobject De lengte van de procestermijn is afhankelijk van het procesobject. Nadat het procesobject haar geldigheid heeft verloren of niet meer bestaat, gaat de bewaartermijn lopen.

  3. De ingeschatte maximale bestaans- of geldigheidsduur van het procesobject Er wordt een inschatting gemaakt van de maximale bestaans- of geldigheidsduur van het procesobject, ongeacht de daadwerkelijke duur. Dit kan bijvoorbeeld al vastgelegd worden in het zaaktype, zodat proces- en bewaartermijn samen een bewaartermijn vormen die gaat lopen vanaf het moment van afsluiten van de zaak.

  4. De tijdens het proces vast te leggen datum waarop de geldigheid van het procesobject komt te vervallen Tijdens de procesuitvoering wordt de datum bepaald wanneer het procesobject haar geldigheid zal verliezen. Tot dat moment loopt de procestermijn.

  5. Procestermijn samengevoegd met bewaartermijn De proces- en bewaartermijn zijn samengevoegd als totaalwaarde bij de bewaartermijn. De datum waarop deze termijn moet gaan lopen is benoemd in de toelichting bij de categorie en kan in het verleden liggen.

De relatie tussen ZAAKTYPEN en de Selectielijst

Elk ZAAKTYPE is gekoppeld aan een Procestype uit de Selectielijst en geeft ook aan wat het (globale) procesobject is. Elk RESULTAATTYPE is gekoppeld aan een Resultaat uit de Selectielijst en zo'n resultaat bepaald weer de procestermijn categorie en tevens de bewaartermijn.

Bepalen wat te vernietigen

Niet alle informatie is even sterk verbonden aan een ZAAK of zelfs helemaal niet verbonden aan een ZAAK. We onderscheiden 4 soorten informatie:

  • Het vernietigen van directe zaak-informatie (zaken, informatieobjecten en besluiten)

  • Zaak-objecten: Zaak-gerelateerde informatie die een integraal onderdeel vormt van de ZAAK (klantcontacten, zaakdetails, producten, etc.)

  • Zaak-gerelateerde informatie die geen integraal onderdeel vormt van de ZAAK (personen, geo-objecten, etc.)

  • Niet-zaak-gerelateerde informatie

Open Archiefbeheer

Open Archiefbeheer wordt gepositioneerd als het centrale component voor archivering. Er komen steeds meer registers waarmee Open Archiefbeheer gekoppeld moet worden om (zaak-gerelateerde) informatie te verwijderen. Open Archiefbeheer hanteert daarvoor de in dit document opgenomen patronen.

Voorbeeld

Zaak-gerelateerde dingen

Een ZAAK kan aan allerlei "dingen" gerelateerd worden, om allerlei redenen. De term "ding" wordt hier gebruikt om niet de indruk te wekken dat het enkel om OBJECTEN in de Objecten API gaat. Ter illustratie:

Er komt een VERZOEK binnen om een BOOM te verwijderen omdat deze is omgevallen op een PAND. Er wordt ook een foto toegevoegd als ENKELVOUDIG INFORMATIEOBJECT. Het VERZOEK, BOOM, PAND worden aan een ZAAK gekoppeld die is gecreëerd n.a.v. het VERZOEK. Later is over deze ZAAK nog contact geweest met de initiator en vastgelegd in een KLANTCONTACT. Er zijn daarnaast nog wat ZAAKDETAILS vastgelegd die niet binnen de ZAAK konden worden vastgelegd.

Schematische weergave:

  • ZAAK (in Zaken API)

    • ZAAK-INFORMATIEOBJECT

      • ENKELVOUDIG INFORMATIEOBJECT (in Documenten API)

    • ZAAKOBJECT (overige)

      • VERZOEK (in Verzoeken API * in wording)

    • ZAAKOBJECT (overige)

      • BOOM (in Objecten API)

    • ZAAKOBJECT (standaard)

      • PAND (in de BAG)

    • ZAAKOBJECT (overige)

      • ZAAKDETAILS (in Objecten API)

  • KLANTCONTACT (in Klantinteracties API)

    • ONDERWERPOBJECT

      • ZAAK (in Zaken API)

Wat moet er gebeuren?

Wat moet er verwijderd worden als de ZAAK vernietigd wordt?

  1. Het ENKELVOUDIG INFORMATIEOBJECT (de foto) moet vernietigd worden.

  2. Het VERZOEK was de reden om de ZAAK te starten en moet vernietigd worden.

  3. De BOOM zit in de Objecten API. Als de BOOM onderdeel is van een soort register van BOMEN, dan mag deze niet vernietigd worden. De BOOM bestaat immers nog. Als de BOOM enkel is aangemaakt t.b.v. deze ZAAK dan moet deze wel vernietigd worden.

  4. Het PAND zit in een (andere) basisregistratie en zal niet vernietigd moeten worden. Het pand bestaat immers nog.

  5. De ZAAKDETAILS horen bij de ZAAK en moeten vernietigd worden.

Analyse

Hoe stellen we programmatisch vast dat een "ding" gekoppeld een ZAAK vernietigd moet worden of niet? Voor een INFORMATIEOBJECT bestaat al een werkend patroon, en gaat uit van "altijd mee-archiveren tenzij elders gebruikt". We laten verder het KLANTCONTACT even buiten scope door de omgekeerde relatie.

Blijft over, ZAAKOBJECTEN. Er zijn 2 soorten ZAAKOBJECTEN:

  1. ZAAKOBJECT vanuit de vast lijst met (RSGB) objecttypen, zoals een PAND.

  2. ZAAKOBJECT met een overig objecttype, typisch een verwijzing naar een object in de Objecten API.

Oplossingsrichtingen ZAAKOBJECTEN

Er zijn 5 mogelijke oplossingsrichtingen:

  1. (applicatie in de lead) Op ZAAKOBJECT wordt een nieuw attribuut geïntroduceerd: meeArchiveren (boolean) . Dit attribuut geeft aan of gepoogd moet worden om het gekoppelde ding te vernietigen zodat de ZAAK vernietigd wordt.

  2. (applicatie wordt geholpen) Hetzelfde als (1) maar daarnaast leggen we op ZAAKTYPE ook vast welke gekoppelde ZAAKOBJECT-OBJECTTYPEN bij een ZAAKTYPE kunnen horen en alvast een default waarde voor meeArchiveren opgeven. Je kan dit op ZAAK niveau nog steeds overrulen.

  3. (automagisch) Alle ZAAKOBJECTEN met een RSGB objecttype, worden standaard niet gepoogd te vernietigen. ZAAKOBJECTEN met een overig objecttype worden wel gepoogd te vernietigen. Dit zou bij de BOOM fout kunnen gaan, tenzij we afspraken maken dat die niet gekoppeld had moeten worden maar of dat correct is...

  4. (opgenomen zonder checks) In de Zaken API wordt een resource toegevoegd voor "dingen" die mee gearchiveerd moeten worden. Dit kan een eenvoudig attribuut zijn die een JSON-object toestaat. We verliezen hiermee echter de voordelen van een contract: Je weet niet van te voren wat er in zo'n ZAAK allemaal aan JSON-objecten zit. Herbruikbaarheid is ook laag.

  5. (opgenomen met checks) Hetzelfde als (4) maar dan gevalideerd tegen een JSON schema, wat is opgenomen in het ZAAKTYPE als ZAAKOBJECTTYPE of iets dergelijks. In principe wordt de Objecten/Objecttypen API hiermee een soort onderdeel van de ZGW APIs.

Oplossingsrichtingen omgekeerde relaties

  1. Relatie veranderen zodat deze loopt vanuit de ZAAK

  2. Relatie spiegelen zoals bij INFORMATIEOBJECTEN

  3. Separate afspraken maken over archiveren van KLANTCONTACTEN (en andere registraties die omgekeerde relaties leggen)

Last updated