> For the complete documentation index, see [llms.txt](https://dienstverleningsplatform.gitbook.io/platform-generieke-dienstverlening-public/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dienstverleningsplatform.gitbook.io/platform-generieke-dienstverlening-public/onderzoeken/archiveren/open-archiefbeheer.md).

# 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.

{% @mermaid/diagram content="
flowchart TD
subgraph s1\["Klantinteracties API"]
n7\["KLANTCONTACT"]
n13\["BETROKKENE"]
n14\["PARTIJ"]
n20\["BETROKKENE (2)"]
n21\["KLANTCONTACT (2)"]
end
subgraph s2\["Taken API"]
n8\["TAAK"]
end
subgraph s3\["Documenten API"]
n9\["DOCUMENT"]
n18\["DOCUMENT (2)"]
end
subgraph s4\["BAG API"]
n10\["PAND"]
end
subgraph s5\["Verzoeken API"]
n12\["VERZOEK"]
end
subgraph s6\["Producten API"]
n16\["PRODUCT"]
end
A(\["Selectielijst proces"]) --- ZAAKTYPE\["ZAAKTYPE"]
B(\["Selectielijst resultaat"]) --- RESULTAATTYPE\["RESULTAATTYPE"]
ZAAKTYPE --- n1\["ZAAK"]
RESULTAATTYPE --- n2\["RESULTAAT"]
n2 --- n1
n1 --- n3\["ZAAKOBJECT"] & n4\["ZAAKOBJECT"] & n5\["ZAAKOBJECT"] & n6\["ZAAKOBJECT"] & n11\["ZAAKOBJECT"] & n17\["ZAAKOBJECT"] & n15\["ZAAKOBJECT"]
n3 --- n7
n4 --- n8
n5 --- n9
n6 --- n10
n11 --- n12
n7 --- n13
n13 --- n14
n15 --- n16
n17 --- n18
n18 --- n19\["ZAAK (2)"]
n21 --- n20
" %}

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.
6. [Het KLANTCONTACT zit omgekeerd gekoppeld aan de ZAAK maar moet ook vernietigd worden.](#user-content-fn-1)[^1]

#### 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)

[^1]: