Open Archiefbeheer

Invulling van Archiveren middels Open Archiefbeheer

Auteur: Joeri Bekker | Status: In voorbereiding

Introductie

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.

Functionaliteiten

Een applicatie voor archiefbeheer:

  1. wijzigt nooit zaaktypen, enkel zaken in het geval van uitzonderingen op de selectielijst

  2. werkt enkel met en op beschikbare gegevens uit registers

  3. voorziet in functionaliteiten die efficiënte archivering mogelijk maken

  4. bevat operationele monitoring op datakwaliteit

  5. geeft registers technisch de opdracht om te vernietigen

  6. houdt een audit trail bij van het proces rondom vernietigen

Architectuurpatronen (deel 1)

Hieronder staat een - niet volledig - overzicht van de relaties tussen allerlei verschillende objecten in een gedistribueerd landschap rondom zaakgericht werken.

In bovenstaande architectuur plaat kunnen we een aantal observaties maken:

  1. Alle informatie van het zaakdossier is terug te relateren aan de ZAAK

  2. Informatie in het zaakdossier buiten het zakenregister, is gekoppeld via een ZAAKOBJECT

  3. ZAAK en ZAAK (2) zijn beiden gekoppeld aan DOCUMENT (2)

  4. KLANTCONTACT (2) en BETROKKENE (2) zijn niet gekoppeld aan een ZAAK en ook geen onderdeel van een zaakdossier

In combinatie met de uitgangspunten, destilleren we de volgende patronen ten aanzien van vernietiging. Indien ZAAK moet worden vernietigd:

  1. Open Archiefbeheer volgt alle relaties vanuit de ZAAK naar ZAAKOBJECT. Op basis van het in het ZAAKOBJECT opgenomen objecttype, maakt Open Archiefbeheer verbinding met het betreffende registers. Vervolgens wordt het gerefereerde object vernietigd. In de architectuurplaat betreft dit:

    1. Wel: PRODUCT, VERZOEK, KLANTCONTACT, TAAK, DOCUMENT (zie uitgangspunt 3a en 4).

    2. Niet: PAND (zie uitgangspunt 6)

    3. Niet: DOCUMENT (2) (zie uitgangspunt 5)

  2. Pas als alle gerelateerde informatie is verwijderd, wordt de ZAAK zelf verwijderd (zie uitgangspunt 4)

  3. Het is aan het register zelf om, bij verwijdering van KLANTCONTACT, ook BETROKKENE te verwijderen (uitgangspunt 7)

  4. Open Archiefbeheer kan bij alle registers om niet zaak-gerelateerde informatie te vernietigen. Hiertoe houd Open Archiefbeheer een objecttype - selectielijst mapping bij, waarmee deze informatie volgens de selectielijst vernietigd kan worden. Bijvoorbeeld: KLANTCONTACT - Selectielijst 3.3 (zie uitgangspunt 3b).

Architectuurpatronen (deel 2)

t.b.v. registers en applicaties die niet door Open Archiefbeheer benaderd kunnen worden.

Oplossingsrichting: Vastleggen van extern bijgehouden gegevens. Notificaties sturen VOORDAT de zaak wordt vernietigd. Terugnotificeren zodra er is vernietigd. Vastleggen. Dan ZAAK gaan vernietigen.

TODO

Analyse (OUD)

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)

PreviousArchiverenNextIn sync houden TAP-straat

Last updated