Als teamlid wil ik een duidelijke en gedetailleerde beschrijving van het archiveringproces

[hdksi]

...zodat ik de noodzakelijke functionaliteit voor vernietigen en overbrengen kan realiseren.

Bepaling prioriteit door PO

• [ ] verbreding of verdieping API's
• [ ] stimuleert gebruik door gemeenten
• [ ] stimuleert gebruik door leveranciers

... eventueel nog toelichting door PO

Definition of ready

• [x] Iedereen in het team begrijpt de user story
• [ ] de gewenste (aanvulling op de) functionaliteit van de API's duidelijk en beschreven is.
• [x] Is klein genoeg (maximaal 1/5 van sprint)
• [x] Product Owner akkoord en voorzien van prioriteit (mag alleen afgevinkt worden door PO)
• [x] Idee hebben van hoe deze user story kan worden gedemonstreerd.
• [x] Userstory is voorzien van een analyse (met daarin architectuur, IM, technische beslissingen afgestemd met team)
• [x] Vastgelegd in Github en geplaatst in kolom ready

Definition of done

• [ ] Er is een OAS 3.0 specificatie
• [ ] Er is een referentieimplementatie
• [ ] Er zijn tests aanwezig die de wijziging aantonen
• [ ] De technische specificatie (standaard.md) is gepubliceerd leesbaar

Acceptatiecriteria

• [ ] De DSO URI- en API-strategie worden gevolgd of afwijkingen zijn vastgelegd als ontwerp keuze
• [ ] Eventueel gemaakte ontwerp keuzes zijn gedocumenteerd
• [ ] Er zijn geen bekende GEMMA tegenstrijdigheden of afwijkingen zijn vastgelegd.

Taken

• [ ] Implementeren in referentie-implementatie [verantwoordelijke]
• [ ] Schrijven (unit) test voor referentie-implementatie [verantwoordelijke]
• [ ] Genereren/opstellen van OAS 3.0 [verantwoordelijke]
• [ ] Human Readable publiceren Open API Specificatie (v.3.0) [verantwoordelijke]

[joeribekker]

Even mijn eigen aantekeningen/interpretatie hierover (niet leidend of compleet) maar wellicht een aanhakingspunt:

Metadata bijhouden:

• Zaak archiefactietermijn en archiefnominatie velden zetten/wijzigen proces???
• We hebben een overzicht nodig van veldjes die effect hebben op andere veldjes t.b.v. archief. Voorbeeld (niet correct maar graag wel zo simpel): Zaaktype.archiefactietermijn + .... = Zaken.archiefactiedatum

Archiveren:

• Opvragen welke gearchiveerd moeten worden
• Zaken aanbieden om (in bulk) te markeren als "klaar voor archivering"
• Zaken filteren op "klaar voor archivering"
• Gefilterde zaken "exporteren" in e-depot formaat (inclusief specificatie) ?? Wanneer, hoe en hoe wordt dit aangegeven dat het hierna vernietigd mag worden.

Vernietigen:

• Opvragen welke vernietigd kunnen worden: bijv met filter: ?archiefactiedatum__lt=today
• Zaken aanbieden om (in bulk) markeren als "klaar voor vernietiging" ???
• Zaken aanbieden om (in bulk) te vernietigen
  • Antwoord met lijst van vernietigde zaken

[TCIMEddy]

Graag iedereen die hier op- en aanmerkingen bij heeft of een andere zinvolle bijdrage graag in user stories als opmerking toevoegen

[Hugo-ter-Doest]

Ik denk dat je met archiveren overbrengen bedoelt. De lijst met zaken die uiteindelijk wordt vernietigd, kan afwijken van de oorspronkelijk gemarkeerde lijst. Dan moet bij de overgebleven gemarkeerde zaken het vlaggetje worden weggehaald. Misschien moet je niet met een vlag werken maar met een unieke sleutel om te markeren. Hetzelfde geldt voor overbrengen, denk ik.

[MarcoKlerks]

Archivering is geen bedrijfsproces, maar een bedrijfsfunctie. Het betreft niet een achtereenvolgende reeks aan handelingen, maar betreft een competentie die een organisatie moet hebben om haar informatiehuishouding op orde te houden. Ik realiseer me dat dat nog vrij abstract is, daarom hieronder mijn standaard-riedeltje over waar het vak om draait.

Informatie is van waarde voor de organisatie. Zij heeft informatie nodig:

• om haar werk te kunnen doen (bijv. zaken behandelen),
• om verantwoording af te leggen (bijv. aan de gemeenteraad),
• om bewijs te leveren (bijv. aan de rechtbank), en
• om onderzoek te kunnen doen (bijv. business intelligence of historisch onderzoek)

Wil informatie deze waarde - of misschien beter gezegd: deze functie - kunnen vervullen, dan moet zij van voldoende kwaliteit zijn. Kwaliteit drukken we uit in termen als:

• Betrouwbaarheid,
• Volledigheid,
• Vindbaarheid,
• Bruikbaarheid,
• Vertrouwelijkheid,
• Et cetera

Om ervoor te zorgen dat informatie voldoende kwaliteit heeft, treffen wij maatregelen. Deze maatregelen treffen wij op het niveau van:

• Organisatie (verantwoordelijkheden, beleid, etc.),
• Mensen (training, bewustwording, etc.),
• Processen (ondersteunende beheerprocessen, maar ook activiteiten in het primaire proces), en
• Middelen (ICT, kantoorartikelen, financiën, etc.)

Dat is kort samengevat en in (hopelijk) begrijpelijke taal waar de NEN-ISO 15489 over gaat. We archiveren niet omdat we informatie willen overbrengen of vernietigen. Dat zijn slechts twee maatregelen op procesniveau:

• Van oudsher vernietigen we informatie, omdat dit de vindbaarheid van andere, wel-nog-waardevolle informatie verbetert. Een kleinere hooiberg om de speld in te zoeken. Ook helpt vernietiging bij de vertrouwelijkheid. Wat je niet meer hebt, kan ook niet meer lekken.
• Van oudsher brengen we informatie over naar archiefbewaarplaatsen, omdat de informatie daar ook toegankelijk is voor en dus gebruikt kan worden door het brede publiek. Ook zijn of waren zij beter in het op lange termijn vindbaar en bruikbaar houden van informatie.

De vraag die je stelt is dus veel te breed. Je vraagt naar kennis waarvoor je een hele opleiding zou moeten volgen. ;-)

Als ik je een advies mag geven? Ga eerst eens op zoek naar een antwoord op de vraag: Hoe bepaal ik de archiefactiedatum? Als je die vraag goed weet te beantwoorden, zijn archiefvernietiging en overbrenging vervolgens peanuts om te regelen.

[hdksi]

👍 voor alle bijdragen, aanvullingen en toevoegingen. Deze US kwam last-minute voort uit de sprintplanningsessie van afgelopen donderdag en verdient enige verduidelijking.

@MarcoKlerks: archiveringsproces is inderdaad een onzorgvuldig gekozen term. Meer precies is het doel de 'life cycle' (tussen aanhalingstekens vanwege de canonieke betekenis van deze term in het archiveringsdomein) van informatieobjecten te beschrijven, nadrukkelijk gericht op het leveren van concrete richtlijnen voor de ZDS-ontwikkelaars om zo inzicht te geven in welke acties in welke fases van de 'life cycle' zijn toegestaan. @joeribekker heeft daarvan een aantal voorbeelden genoemd; denk in meer natuurlijke taal aan vragen als 'mag een informatieobject nog gemuteerd worden nadat dat informatieobject is voorgekomen op een vernietigings-/overbrengingslijst?' (Antwoord naar verwachting 'nee').

@Hugo-ter-Doest: bovenstaande betekent ook dat de scope breder is dan overbrengen alleen. Vergelijkbare vragen kunnen worden gesteld voor vernietiging of eerdere fases in de 'life cycle', en gezien Joeri's aanvullingen zijn die vragen er ook daadwerkelijk.

[hdksi]

Geen lichte kost, maar ik denk dat dit document een beter antwoord geeft op de vragen bij ontwikkelaars dan ik zelf zou kunnen geven. Uitgelegd wordt de relatie tussen de Gemeentelijke Selectielijst (2017) en ImZTC en RGBZ en de aanpassingen die in die informatiemodellen moeten worden gedaan om in voorkomende gevallen de benodigde metadata te kunnen vastleggen. De in dit document voorgestelde wijzigingen zijn voor zover ik kan beoordelen reeds opgenomen in (concept-)versie 2.0.2 van het RGBZ.

Ik raad in het bijzonder @joeribekker aan hiernaar te kijken in het kader van #758. Vragen over de inhoud van het document beantwoord ik (evt. na ruggespraak met de auteur) graag. Mogelijk dat ook @Remkodehaas eventueel e.e.a. kan toelichten.

ImZTC RGBZ Wijzigingsvoorstel Selectielijst 20170921w CONCEPT.pdf

[joeribekker]

Dank @hdksi

Het geeft ongeveer hetzelfde weer als mijn samenvatting (gelukkig) en is al veel duidelijker dan andere docs die ik heb gezien. Er wordt echter geen antwoord gegeven op enkele vragen die ik heb. Het is een document op IM niveau waar een flinke interpretatie slag op gemaakt moet worden in techniek. Ik zal deze vragen straks uitschrijven.

Graag heb ik ook dat je mijn PR leest bij updates om te verifiëren juist of aannames goed zijn gemaakt.

[joeribekker]

Vragen op dit moment:

1. Controle of voor alle cases de brondatum op de juiste datum herleid wordt.
2. Controle of de berekening voor archiefactiedatum correct is.
3. Wat gebeurt er als een zaak vernietigd wordt (status=vernietigd)? Is de zaak dan leeg?
4. Wat gebeurt er als een zaak "gearchiveerd" is? Is deze nog wijzigbaar?
5. Wat gebeurt er als een zaak "overgebracht is"? Is deze dan weg? Leeg?

[joeribekker]

Antwoorden van Ben de Jong, via mail, via Constantijn, via Slack nu ook op Github:

1. Zie in de bijlage het commentaardocument van mijn kant (laatste kolom) per trigger waarop de bewaartermijn kan starten in mijn beoordeling met de kennis van de selectielijst 2017.
2. De archiefactietermijn (zie definitie volgens ZTC 2.0= De termijn in maanden waarna het zaakdossier (de ZAAK met alle bijbehorende DOCUMENTen) van een ZAAK met een resultaat van dit RESULTAATTYPE vernietigd of overgebracht (naar een archiefbewaarplaats) moet worden. De datum waarop deze termijn start, is afhankelijk van de waarde van Brondatum archiefprocedure. ) is volgens mij wel correct afhankelijk van af de definitie goed wordt toegepast (termijn is in maanden etc.). We zouden exacter moeten kijken om het zeker te weten.
3. In zijn geheel verwijderen – dus niet leegmaken o.i.d. Het enige dat je overhoudt is een blijvend te bewaren, wij noemend dat een ‘opgerolde’ vernietigingslijst, die ter verantwoording wordt gebruikt zodat we weten dat de zaken X t/m Y van type Z in termijn T zijn vernietigd. Zonder specificatie van iedere zaak want voordat de zaken vernietigd worden heeft al een toets plaatsgehad (door de RM-er en de archivaris) dat er toevallig niet iets tussen zat dat blijvend bewaard moest worden (o.a. toets op ‘hotspots’ e.d.).
4. De status gearchiveerd kennen we niet. Of een zaak is vernietigd of de zaak is of wordt overgebracht naar de bewaarplaats. Aangezien archivering (by design) al begint bij de start (archivering bij de bron) spraken we in Utrecht van afgesloten (= op slot). De zaak mag alleen nog geopend worden door daartoe geautoriseerde functionarissen maar heropenen is eigenlijk uit den boze. Wel kun je na afhandeling een tijd (stel: x weken) het alsnog toevoegen van informatie over een al afgehandelde zaak toestaan met permissie van de zaakeigenaar, maar daarna moet het ook echt ‘schluss’ zijn en moet desnoods een nieuwe zaak gestart worden over hetzelfde zaakobject en als voortzetting binnen hetzelfde ’dossier’.
5. Hier ligt een fundamentele vraag en wat zich in Utrecht heeft vertaald naar het criterium ‘interoperabiliteit’. Je wilt niet dat de zaak echt weg is maar wel dat de zaak formeel is overgebracht naar de archiefbewaarplaats, in Utrecht in beheer bij HUA, maar wel zo dat je die zaken nog steeds kunt terugvinden voor de eeuwigheid waar dat aan de orde is, alles wat dus niet tussentijds vernietigd wordt. De rol van HUA is echter ingegeven in Utrecht via de gemeenschappelijke regeling Gemeente Utrecht vs. HUA. Vele gemeenten willen een e-depot volledig in eigen beheer houden en dus interoperabiliteit afdwingen (zie o.a. aanbesteding gemeente Breda) binnen de eigen architectuur. Vergelijk het alsof we daarmee HUA als verlengstuk zien van de Utrechtse architectuur- zie de uitkomst van de pilot uit 2015 (traject Huibert).

Inhoudelijk: letterlijk is er sprake van een statusverandering vanuit de WOB (regime 1) naar de archiefwet (regime 2) . De openbaarheidsbepalingen van informatie (volgens WOB en Archiefwet) moeten daarom volgens mij ook deel uitmaken van het ontwerp (idem voor beperkingen op openbaarheid zoals geheimhouding, auteursrecht e.d.). Kortom: zie het juridische begrip ‘overbrengen’ als functie van openbaarheid en dan hebben we de goede discussie te pakken. Idem: zo speelt ook privacy een rol bij het eventuele anonimiseren van persoonsgegevens tijdens het gehele proces, tot en met overbrenging aan toe. Komen deze elementen (openbaarheid en privacy voldoende aan bod of is dat niet jullie opzet?)

brondatum commentaar Ben de Jong.docx

[joeribekker]

Uit Ben de Jong's document:

termijn: De termijn start een vast aantal jaren na de datum waarop de zaak is afgehandeld (ZAAK.Einddatum in het RGBZ).

Deze gevallen ken ik niet volgens de selectielijst 2017. Deze zou ik schrappen want kan goed worden ondervangen met een andere categorie (bv. Eigenschap).

Toch niet mee eens. Uit de selectielijst (8.1.6) zie ik een procestermijn: 30 jaar, De ingeschatte maximale bestaansduur van het procesobject.

Hierbij moet de afleidingswijze "termijn" zijn, zodat de procestermijn wordt gebruikt bij het berekenen van de brondatum (Zaak.einddatum + 30 jaar in dit geval).

@CMasselink Toch?

[joeribekker]

Volgens mij is het meeste nu wel getackled. Zie PR #772