NEN2082: verschil tussen versies

Uit ZaaksysteemWiki
Ga naar: navigatie, zoeken
k (hernoemde NEN2082 naar TEMP NEN2082)
(hernoemde NEN2082 naar TEMP NEN2082)
Regel 1: Regel 1:
__TOC__
+
#DOORVERWIJZING [[TEMP NEN2082]]
 
 
Deze norm heeft tot doel een minimale verzameling aan functionele eisen voor informatie- en archiefmanagement in programmatuur te bieden die organisaties kunnen gebruiken bij aanbesteding van bouw, aanschaf of vervanging van applicaties. Daarnaast biedt deze norm een basis voor auditing en certificering van programmatuur. De norm is ontwikkeld op basis van bestaande reeksen van functionele eisen voor recordsmanagementprogrammatuur, zoals MoReq (2001), ReMANO 2004, DoD 5015.2 (versies 1997 en 2002) en het Kernmodel van Interlab versie 1, 2003.
 
Tevens is gekeken naar ontwikkelingen in de Verenigde Staten waar de National Archives and Records Administration (NARA) werkt aan zogenoemde Records Management Services (RMS). De NARA onderscheidt zeven functies van archivering: opnemen, vastleggen van de herkomst (context), klasseren, behoud van authenticiteit, bestanddeelvorming (ordenen), verwijderen en beschikbaar stellen. Deze functies zijn in de voorliggende norm herkenbaar.
 
 
 
== NEN2082 ==
 
 
 
 
 
 
 
 
 
 
 
=== Identificeren en registreren ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Invulling
 
 
 
|-
 
|1
 
|Bij implementatie van de programmatuur moet de vastgestelde structuur van het
 
identificatiekenmerk kunnen worden ingesteld. De structuur moet worden gedocumenteerd en kunnen worden gevalideerd.
 
|Het unieke identificatiekenmerk binnen het zaaksysteem is een zaaknummer. Een zaaknummer is doorlopend nummeriek strekkend nummer van de database, bijvoorbeeld 14553.
 
 
 
|-
 
|2
 
|Bij opname moet aan elk archiefstuk, archiefbestanddeel en ander aggregatieniveau een uniek en
 
persistent identificatiekenmerk kunnen worden toegekend:
 
— hetzij automatisch gegenereerd op basis van een identificatiesysteem, waarbij gebruikers geen
 
unieke kenmerken handmatig kunnen toevoegen en muteren;
 
— hetzij door de gebruikers toegekend waarbij automatisch wordt gecontroleerd of het kenmerk
 
uniek is binnen het vastgestelde domein, voordat het wordt weggeschreven.
 
|Zaakdossiers hebben een eigen nummer. Alle documenten binnen een zaakdossier krijgen (onder water) een eigen nummer met een MD5-hash. Documenten die worden gewijzigd, worden als een nieuw document gezien. De nummers worden automatisch gegenereerd. Deze gegevens kunnen niet handmatig worden gewijzigd.
 
 
 
|-
 
|3
 
|Afhankelijk van de eisen die een organisatie stelt, moet ieder toegekend identificatiekenmerk uniek
 
zijn binnen de organisatie.
 
OPMERKING Uniciteit kan op verschillende manieren worden bereikt, bijv. door het toekennen van unieke
 
kenmerken binnen het bedrijfsproces dat het archiefstuk genereerde, voorafgegaan door een unieke
 
identificatie van het bedrijfsproces, door toekennen van unieke kenmerken binnen de applicatie waarmee het
 
archiefstuk is gemaakt of waarin het is ontvangen, voorafgegaan door een identificatie van de applicatie, of
 
door toekennen van een uniek kenmerk binnen het organisatie-onderdeel dat het creëerde, voorafgegaan door
 
een identificatie van dat onderdeel.
 
|De ZTC is het vastegestelde Het metadataschema binnen het zaaksysteem. Hiervoor wordt de ZTC van GEMMA als basis gehanteerd in het systeem. De basisattributen staan vast en zijn niet door de organisatie te wijzigen. Het schema is op zaaktypeniveau aan te vullen met kenmerken die wel zelf kunnen worden beheerd door de organisatie.
 
 
 
|}
 
 
 
 
 
 
 
 
 
 
 
=== Vastleggen van contextuele metadata ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|4
 
|Op basis van het metadataschema moeten de contextuele metadata worden vastgelegd.
 
|De samenhang tussen zaken is vastgelegd in de verschillende zaaktypen. Zaaktypen zitten in de Zaaktypecatalogus. Ook wanneer de naam wijzigt van een zaaktype, is de metadata te zien dmv een zoekopdracht.
 
 
 
|-
 
|5
 
|De samenhang tussen de archiefstukken onderling en tussen de archiefstukken en hun context moet
 
worden vastgelegd in metadata.
 
|Zaaksysteem.nl werkt met een API. Daardoor is het mogelijk om verschillende koppelingen te realiseren in verschillende formaten. Voorbeelden hiervan zijn koppelingen met GBA, BAG, BAG (Kadaster) en Mutatiebestanden van de KvK. Daarnaast is het ook mogelijk om zelf kenmerken te maken in de zaaktypecatalogus.
 
 
 
|-
 
|6
 
|Bij registratie moeten contextuele metadata kunnen worden verkregen uit andere bronnen.
 
OPMERKING Dit kan gebeuren door automatische extractie of door handmatige invoer binnen een
 
bepaalde rol.
 
|Gegegevens die GBA, BAG, koppeling AD en KvK
 
Dit kan dmv CSV import of op basis van een Stuf-koppeling
 
 
 
|-
 
|7
 
|Het moet mogelijk zijn te specificeren welke metadata automatisch worden geëxtraheerd.
 
|Zie Databasemodel Gegevensmagazijn
 
 
 
|-
 
|8
 
|De structuur en inhoud van de metadata moeten bij of na registratie kunnen worden gevalideerd.
 
De ingevulde waarde van een metadata-element moet kunnen worden gecontroleerd aan de hand
 
van
 
— een vastgesteld bestandsformaat;
 
— reeks- en termijnwaarden;
 
— een lijst van toegelaten waarden (gecontroleerde vocabulaires).
 
|Validatie van automatisch geimporteerd gegevens vindt plaats voordat ze worden opgenomen in het zaaksysteem. Validatie van handmatige invoer gebeurt via een selectie van het juiste invoertype (bijvoorbeeld dropdown of datumveld). Gecontroleerde vocubbulaires kunnen ook dmv invoertypen worden gerealiseerd.
 
 
 
|-
 
|9
 
|De volledigheid van de vereiste contextuele metadata moet kunnen worden gecontroleerd en
 
gevalideerd.
 
|Het zaaksysteem werkt met verplichte en niet-verplichte invoer. Wanneer een bepaald kenmerk verplicht is, dan kun je dit verplicht instellen tijdens de configuratie van een fase.
 
 
 
Een tweede optie voor een controle op velden is het opnemen van checklistitems. Er worden checklistitems opgenomen waarbij de behandelaar aangeeft of de velden volledig en/of juist zijn ingevuld.
 
 
 
Een derde optie is het gebruiken van regels. Wanneer het bij een bepaald zaaktype van belang is dat er bij ‘Niet ontvankelijk’ een reden wordt opgegeven door het invullen van een (verplicht) kenmerk.
 
 
 
|}
 
 
 
 
 
 
 
 
 
 
 
=== Technische controle van op te nemen digitale bestanden ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|10
 
|Het moet mogelijk zijn metadata te extraheren of migreren uit de ‘file header’, incl. het
 
bestandsformaat, van de digitale bestanden waaruit het archiefstuk bestaat.
 
|Bij het toevoegen (of wijzigen) van een documenten wordt diverse data uit het bestand opgeslagen binnen het zaakdossier. Deze informatie is op te vragen door op het I-coontje te klikken bij een document.
 
 
 
|-
 
|11
 
|Digitale bestanden moeten kunnen worden gecontroleerd op het bestandsformaat en de
 
leesbaarheid.
 
|Wanneer een document wordt toegevoegd dan controleert het zaaksysteem of het bestandsformaat een breed gebruikt formaat is. Als het bestand wordt herkent, dan krijgt het een icoontje. Zo niet, dan is het een relatief onbekend document.
 
 
 
Een tweede functionaliteit is de preview. Voor bekende bestandsformaten is het mogelijk om een preview op te vragen. Hier kan dan de leesbaarheid worden beoordeeld.
 
 
 
|-
 
|12
 
|De integriteit van digitale bestanden moet kunnen worden vastgesteld, gecontroleerd en
 
gedocumenteerd.
 
OPMERKING Het gaat hier met name om controle op virussen, wormen en andere vormen van schadelijke
 
programma’s die de integriteit van archiefstukken doorbreken.
 
|Alle bestanden krijgen een MD5-hash. Hiermee wordt de integriteit van bestanden vastgesteld. Het is mogelijk om tijdens de behandeling van een zaak de integriteit te controleren. Dit gebeurt automatisch bij het afhandelen van een zaak. Indien de integriteit niet akkoord is, kan een zaak niet worden afgehandeld. Het resultaat wordt opgeslagen in de logfile.
 
 
 
|-
 
|13
 
|Digitale bestanden die zijn voorzien van een integriteitskenmerk (via ‘hash totals’, ‘check sums’ of
 
andere vormen van integriteitscontrole) moeten daarop kunnen worden gecontroleerd bij opname.
 
|De integriteit van externe bestanden met een MD5 hash kan worden gecontroleerd door een handmatige controle. Hierbij wordt gebruik gemaakt van een externe tool of website
 
 
 
|-
 
|14
 
|Digitale bestanden behoren te kunnen worden voorzien van een integriteitskenmerk, indien zij dit
 
nog niet hebben.
 
|Elk bestand wordt wordt toegevoegd, krijgt een MD5-hash
 
 
 
|-
 
|15
 
|Indien de technische kwaliteit van een digitaal bestand en/of het bestandsformaat niet
 
voldoet/voldoen aan de door de organisatie gestelde eisen, moet één van de volgende acties
 
kunnen worden genomen (afhankelijk van implementatie):
 
— afwijzen (met een melding aan de afzender);
 
— corrigeren.
 
|Dit kan door middel van de in 13 vastgestelde organisatorische procedure
 
Dit proces is hier te downloaden
 
 
 
|}
 
 
 
 
 
 
 
 
 
 
 
=== Kwaliteitscontrole archiefstukken ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|16
 
|Van alle typen archiefstukken moeten de voor authenticiteit, betrouwbaarheid, integriteit en
 
bruikbaarheid essentiële kenmerken kunnen worden vastgelegd m.b.t. ten minste de
 
verschijningsvorm, de structuur, de inhoud en (indien nodig) het gedrag.
 
|Verplichte of belangrijke documenten kunnen als kenmerken worden aangemaakt binnen een zaaktype. Voor de juistheid en volledigheid van de ontvangen documenten kan gebruik worden gemaakt van specifieke kenmerken en/of checklistitems binnen een zaaktype.
 
 
 
|-
 
|17
 
|Alle archiefstukken moeten op authenticiteit, betrouwbaarheid, integriteit en bruikbaarheid kunnen
 
worden getoetst, voordat ze worden opgeslagen:
 
— via de metadata bij registratie, op een adequate invulling van verplichte velden zoals vastgesteld
 
en gedocumenteerd in het metadataschema;
 
— via de door de organisatie dan wel door het werkproces gestelde criteria.
 
|Zie toelichting vraag 17. Het ‘voordat ze worden opgeslagen’ wordt ingevuld door gebruik te maken van een documentenwachtrij.
 
 
 
Een zaak wordt gearchiveerd als deze is afgehandeld.
 
 
 
|}
 
 
 
 
 
 
 
 
 
 
 
=== Inhoudelijke controle archiefstukken ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|18
 
|Met betrekking tot de archiefstukken moet het volgende kunnen worden gecontroleerd:
 
— Zijn alle archiefstukken aanwezig?
 
— Zijn alle bijbehorende contextuele metadata aanwezig?
 
In het geval van samengestelde archiefstukken:
 
— Zijn alle samenstellende delen aanwezig, bijvoorbeeld alle bijlagen?
 
|Dit kan door verschillende wijzen worden gerealiseerd. Verplichte documenten en informatie kan door middel van het verplicht stellen van een kenmerk.
 
 
 
Daarnaast wordt er geadviseerd
 
 
 
|-
 
|19
 
|Indien archiefstukken niet compleet zijn moet één van de volgende acties kunnen worden uitgevoerd
 
(afhankelijk van implementatie):
 
— afwijzen (met een melding aan de afzender);
 
— corrigeren;
 
— accepteren zoals het is (door een daartoe bevoegde functionaris).
 
|Een
 
 
 
|}
 
 
 
 
 
 
 
 
 
 
 
=== Opslaan ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|20
 
|De digitale bestanden waaruit een informatieobject bestaat, moeten worden opgeslagen in een door
 
de organisatie vastgesteld bestandsformaat.
 
|Het zaaksysteem maakt waar mogelijk gebruik van sjablonen. Hiervoor wordt gebruik gemaakt van ODT bestanden.
 
 
 
|-
 
|21
 
|De digitale bestanden waaruit een informatieobject bestaat, moeten zo worden opgeslagen dat ze
 
niet ongeautoriseerd kunnen worden veranderd of verwijderd.
 
|Het zaaaksysteem maakt gebruik van een OpenLDAP. Hierin wordt gewerkt met RBS. Op zaaktypeniveau worden er rechten verleend aan alle zaken die van dat zaaktype worden aangevraagd.
 
 
 
Om te mogen vernietigen moet je de zaakbeheerder of zaaksysteembeheerder hebben. Anders is het niet mogelijk om te vernietigen
 
 
 
|-
 
|22
 
|De koppeling tussen een archiefbestanddeel (op elk aggregatieniveau) en de daarbij behorende
 
metadata moet tot het moment van verwijdering onverbrekelijk zijn.
 
|Volgens het databasemodel is er sprake van referetiele integriteit. Dit alle objecten zijn gerelateerd aan een specifiek zaaknummer welke niet kan worden verwijderd. Een zaak en alle objecten is dus een geheel. Zie databasemodellen.
 
 
 
|-
 
|23
 
|Bij het opnemen moet een archiefstuk worden toegevoegd aan:
 
— een bestaand archiefbestanddeel;
 
— een nieuw gevormd archiefbestanddeel.
 
|Een document wat binnenkomt wordt toegevoegd aan een bestaande zaak of er wordt een nieuwe zaak voor geregistreerd.
 
 
 
|-
 
|24
 
|Een archiefstuk moet slechts één keer in een archiefbestanddeel kunnen worden opgenomen.
 
|Een document kan maar 1 documentnummer hebben. Het kan wel in meerdere zaken voorkomen. Zaaknummer.Documentnummer, Bijvoorbeeld:
 
 
 
30001234
 
40011234
 
 
 
|}
 
 
 
 
 
 
 
 
 
 
 
=== Ordenen en klasseren ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|25
 
|Aan een archiefbestanddeel moet een classificatiekenmerk worden toegekend.
 
|Dit kan door gebruik te maken van de Generieke Categorieen van de Gemma of door het implementeren van een eigen Classificatie, bijvoorbeeld een Processenkaart.
 
 
 
|-
 
|26
 
|Het archiefstuk moet automatisch hetzelfde classificatiekenmerk krijgen als het archiefbestanddeel
 
waaraan het is toegevoegd.
 
|Wanneer je een zaak opent, is direct te zien wat het zaaknummer is en aan welke zaaktype het is gerelateerd. Deze informatie wordt autmatisch gegenereerd.
 
 
 
|-
 
|27
 
|Een archiefbestanddeel moet binnen een bepaald classificatieschema slechts één
 
classificatiekenmerk toegekend krijgen.
 
|Een zaak kan maar bij een zaaktype horen. Het is niet mogelijk dat een zaak bij meerdere zaaktypen hoort.
 
 
 
|-
 
|28
 
|Een archiefbestanddeel behoort onder meer dan één classificatieschema te kunnen vallen.
 
|Is niet van toepassing
 
 
 
|}
 
 
 
 
 
 
 
 
 
 
 
=== Beschrijven ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|29
 
|Op elk aggregatieniveau moeten aan archiefstukken en archiefbestanddelen beschrijvende
 
metadata kunnen worden toegevoegd.
 
|Voor een gedeelte wordt dit in het metadataschema opgevangen. Voor een ander gedeelte wordt dit opgelost door kenmerken.
 
 
 
|-
 
|30
 
|Alleen die beschrijvende metadata moeten kunnen worden toegevoegd die in het metadataschema
 
zijn vastgelegd.
 
|Je kan bij een zaak alleen die kenmerken invullen die vanuit het zaaktype worden geleverd. Het is niet mogelijk om kenmerken uit andere zaaktypen te gebruiken als deze niet in het zaaktype voorkomen.
 
 
 
|-
 
|31
 
|Contextuele metadata mogen alleen worden gemuteerd in geval van correctie van onjuistheden bij
 
eerste registratie of als aanvulling.
 
|Kenmerken kunnen alleen gewijzigd worden wanneer een zaak in behandeling is. Zodra een zaak is afgehandeld, kunnen er geen kenmerken meer worden gewijzigd.
 
 
 
De enige uitzondering is het wijzigen van een resultaat bij zaken waarbij dit relevant is. Bijvoorbeeld bij het intrekken van een vergunning.
 
 
 
|}
 
 
 
 
 
 
 
 
 
 
 
=== Beheren en onderhouden ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|32
 
|De integriteit van een digitaal bestand dan wel van een archiefbestanddeel en de bijbehorende
 
metadata moet kunnen worden geborgd, onder andere tegen ongeautoriseerde wijzigingen en
 
beschadigingen.
 
|Wanneer je geen rechten hebt binnen een zaaktype, dan kun je geen wijzigingen aanbrengen binnen een zaak.
 
 
 
Om beschadiging te voorkomen wordt gebruik gemaakt van een backup-plan en een redundante omgeving.
 
 
 
Op verzoek worden er toegang verleend
 
 
 
[https://www.box.com/s/67d3e0203b04188a4bc7 ISO27001-Certificaten in PDF inzien]
 
 
 
|-
 
|33
 
|Er moet kunnen worden aangegeven welke (versies van) bestandsformaten acceptabel zijn,
 
bijvoorbeeld via een te onderhouden validatietabel.
 
|De bestandsformaten die door het zaaksysteem worden geaccpeteerd zijn:
 
 
 
-  Word (.doc)
 
-  Word (.dox)
 
-  Etc..
 
-  MKV voor video?
 
-  MP3 voor audio?
 
 
 
|-
 
|34
 
|Controle op en/of validatie van een bestandsformaat moet(en) kunnen worden uitgevoerd.
 
OPMERKING Dit kan met behulp van externe diensten en registers voor bestandsformaten.
 
|Het zaaksysteem controleert een bepaald bestand op basis van mime/types.
 
 
 
|-
 
|35
 
|Van digitale bestanden moet een overzicht kunnen worden gemaakt dat de volgende elementen
 
moet kunnen bevatten:
 
— het bestandsformaat;
 
— het tijdstip waarop de digitale bestanden in dit bestandsformaat zijn gecreëerd;
 
— de versie van dit bestandsformaat;
 
— de reden van keuze voor dit bestandsformaat (bijvoorbeeld bij het opnemen of na het
 
converteren/migreren);
 
— de status van dit bestandsformaat op basis van de toegelaten (versies van) bestandsformaten.
 
|Dit kan met een speciale actie voor beheerders
 
 
 
|-
 
|36
 
|Er moet functionaliteit zijn om digitale bestanden te kunnen converteren en migreren met behoud
 
van de authenticiteit, betrouwbaarheid, integriteit en bruikbaarheid van de archiefstukken.
 
|Er wordt gebruik gemaakt van Headless OpenOffice. Dit pakket kan nageboeg alle benodigde converties uitvoeren.OpenOffice kan de alle bestanden in de vastgestelde lijst converteren.
 
 
 
Video en audio moet op basis van open standaarden
 
 
 
|-
 
|37
 
|In geval van samengestelde archiefstukken is het vereist dat het archiefstuk als één geheel wordt
 
behandeld, met de mogelijkheid elk van de onderdelen afzonderlijk te benaderen.
 
Na opname en na elke conversie of migratie moeten de authenticiteit, betrouwbaarheid, integriteit
 
en bruikbaarheid kunnen worden vastgesteld:
 
— van alle samenstellende onderdelen afzonderlijk;
 
— van het samengestelde archiefstuk.
 
|Er wordt tot op heden niet gewerkt met samengesteld archiefstukken. Derhalve is deze eis niet van toepassing.
 
 
 
Een samengesteld archiefstuk is bijvoorbeeld is een e-mail met bijlagen.
 
 
 
|-
 
|38
 
|Indien migratie binnen de gebruikte applicatie niet mogelijk is, behoren digitale bestanden te
 
kunnen worden gereedgemaakt voor tijdelijke export naar een ander systeem.
 
|Er wordt aan de eis wordt voldaan voor het converteren, is deze optie niet van toepassing.
 
 
 
|}
 
 
 
=== Volgen ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|39
 
|De volgende verblijfplaatsgegevens moeten handmatig of geautomatiseerd kunnen worden
 
vastgelegd:
 
— de unieke identificatie van het archiefstuk op het meest geëigende aggregatieniveau;
 
— datum en tijdstip van ‘verzenden naar’ / ‘ontvangen op’ een verblijfplaats;
 
— zowel de huidige verblijfplaats als vorige verblijfplaatsen;
 
OPMERKING In een digitale omgeving gaat het ook om de fysieke locatie, bijvoorbeeld offline opslag.
 
— datum van het veranderen van een verblijfplaats;
 
— de identificatie van de gebruiker binnen een bepaalde rol (indien aanwezig).
 
|Het zaaksysteem biedt een mogelijkheid voor het uitlenen van fysieke zaakdossier dmv een zaaktype
 
 
 
|-
 
|40
 
|Een uitleenadministratie behoort te kunnen worden gevoerd om iedere terbeschikkingstelling van
 
fysieke archiefstukken vast te leggen.
 
|Het zaaksysteem biedt een mogelijkheid voor het uitlenen van fysieke zaakdossier dmv een zaaktype
 
 
 
|}
 
 
 
 
 
 
 
 
 
 
 
=== Algemene functionele eisen ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|41
 
|Per gebruikersprofiel en/of rol moet kunnen worden bepaald welke metadata beschikbaar zijn voor
 
zoeken en/of raadplegen.
 
|Wanneer je rechten hebt op een zaaktype dan mag je alle gegevens van een zaak zien. Alle metadata is beschikbaar indien de gebruiker
 
 
 
|-
 
|42
 
|De gebruikersinterface moet ondersteunen:
 
— het zoeken en navigeren op de kenmerken van het classificatieschema en op alle
 
aggregatieniveaus;
 
— het selecteren en presenteren van archiefstukken of -bestanddelen op alle aggregatieniveaus.
 
|Het zaaksysteem biedt een uitgebreide functionaliteiten om te zoeken op zaken. Alle metadata die wordt opgeslagen bij een zaak, daar is op te zoeken.
 
 
 
|}
 
 
 
 
 
 
 
 
 
 
 
=== Zoekfuncties en functionaliteiten ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|43
 
|Het behoort mogelijk te zijn een zoekactie te activeren vanuit een willekeurig gebruikersscherm in
 
de applicatie.
 
|De interface is zo ontworpen dat je altijd een knop hebt vanwaar je een zoekopdracht kunt starten.
 
 
 
|-
 
|44
 
|De zoekfunctie moet alle gebruikers dezelfde interface bieden, in te richten op basis van
 
parameters, met uitzondering van specifieke rollen die aan een gebruikersprofiel kunnen zijn
 
toegekend.
 
|Zaken Zoeken is voor iedere gebruiker hetzelfde. Er zijn geen verschillende interfaces voor het zoeken.
 
 
 
|-
 
|45
 
|Ongeacht of het archiefbestanddeel digitaal is of niet, of online dan wel offline is opgeslagen, moet
 
zoeken mogelijk zijn op:
 
— contextuele metadata en/of
 
— (rubriek(en) van) een classificatieschema.
 
Het zoeken moet mogelijk zijn met afzonderlijke gegevens of met een combinatie van gegevens
 
en dit op elk aggregatieniveau.
 
|Het is mogelijk om een link op te nemen in het zaaktype van de uitleenadministartie. Deze link verwijst naar een bijv. een excelbestand waarin een overzicht wordt bijgehouden van de fysieke dossiers.
 
 
 
|-
 
|46
 
|Door middel van een enkele zoekopdracht moeten alle archiefbestanddelen op elk
 
aggregatieniveau en hun metadata kunnen worden teruggevonden, met inachtneming van
 
autorisaties.
 
|Door gebruik te maken van Zaken Zoeken worden alle zaken getoond waarop je zoekt, en je rechten hebt.
 
 
 
|-
 
|47
 
|Als wordt gezocht naar of gewerkt met een archiefstuk of -bestanddeel, dan moet binnen een rol
 
de mogelijkheid bestaan om gegevens over een bovengeschikt aggregatieniveau te vinden,
 
zonder het scherm af te sluiten of te moeten verlaten.
 
|Het zaaksysteem maakt gebruik van tabbladen. Alle informatie die er beschikbaar is van een zaak is te zien onder een van deze tabbladen.
 
 
 
|-
 
|48
 
|Tijdens het invoeren van een zoekvraag behoort het mogelijk te zijn door het intypen van (delen
 
van) de zoekterm automatisch te zoeken in een lijst met waarden die voor de desbetreffende
 
metadata-elementen is gedefinieerd.
 
|Het is niet nodig om de exacte waarde in te voeren bij een zoekopdracht. Het is mogelijk om delen van een woord op te geven.
 
 
 
|-
 
|49
 
|Digitale archiefbestanddelen moeten door meer gebruikers gelijktijdig kunnen worden
 
geraadpleegd.
 
|Het is mogelijk dat meerdere gebruikers gebruik maken van een zaakdossier.
 
 
 
|-
 
|50
 
|Binnen een bepaalde rol moet op elk van de metadata-elementen van een archiefbestanddeel op
 
elk aggregatieniveau kunnen worden gezocht.
 
|Het is mogelijk om te zoeken door middel van Zaken Zoeken.
 
 
 
|}
 
 
 
 
 
 
 
 
 
 
 
=== Presenteren ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|51
 
|Een archiefbestanddeel moet in één keer als een eenheid kunnen worden gepresenteerd waarbij
 
de gehele inhoud, inclusief de vastgelegde contextuele metadata, kan worden gelezen en/of
 
verzonden.
 
|De eenheid van een zaak wordt gepresenteerd door het digitale zaakdossier. Als een andere behandelaar de inhoud van de zaak wil inzien, kan dit worden gerealiseerd door het wijzigen van de behandelaar of het versturen van een bericht waarin de link van de zaak wordt opgenomen.
 
 
 
Wanneer externen toegang nodig hebben, kunnen deze een login krijgen en zien ze alleen de zaken waarbinnen ze rechten hebben.
 
 
 
|-
 
|52
 
|Alle archiefstukken moeten worden gepresenteerd met behoud van de vastgelegde essentiële
 
kenmerken van vorm, structuur en eventueel gedrag.
 
|Zaken kunnen worden opgeroepen zoals ze zijn geregistreerd. Ook documenten kunnen gewoon worden gebruikt. Deze worden geopend in de native applicatie.
 
 
 
|-
 
|53
 
|Alle vormen van archiefstukken moeten kunnen worden gepresenteerd onafhankelijk van de
 
toepassingsprogrammatuur en/of hardware waarmee de archiefstukken zijn gegenereerd.
 
OPMERKING Bijvoorbeeld via ‘viewers’ of met specifiek daarvoor benodigde programmatuur en/of
 
hardware, zoals bij audio, video en vormen van multimedia.
 
|Documenten die worden toegestaan zijn te bekijken met OpenOffice en een OpenPDF reader. Dit valt onder de ondersteuning van het zaaksysteem.
 
 
 
|-
 
|54
 
|Archiefbestanddelen behoren in verschillende volgorde te kunnen worden gepresenteerd, zoals:
 
— op classificatie, waarbij per gebruikersprofiel of per rol kan worden bepaald welk deel of welke
 
delen van het classificatieschema wordt of worden gepresenteerd;
 
— op meest gebruikte archiefbestanddelen, waarbij per gebruikersprofiel of per rol een lijst kan
 
worden aangemaakt met de door dat gebruikerprofiel of die rol meest gebruikte
 
archiefbestanddelen;
 
— op meest recent gebruikte archiefbestanddelen;
 
— op basis van nader te bepalen contextuele metadata, bijvoorbeeld op het type bedrijfsactiviteit,
 
de naam van de organisatie en/of de datum van opmaken, verzenden of ontvangen;
 
— op basis van de inhoud van het archiefstuk.
 
|Met behulp van Zaken Zoeken kunnen zoekopdrachten worden opgeslagen voor een specifieke gebruiker of rol. Hierin kan worden bepaald welke criteria van belang zijn.
 
 
 
|-
 
|55
 
|Als de organisatie gebruikmaakt van een dossierinventaris moet binnen een bepaalde rol een
 
dossierinventaris kunnen worden afdrukt.
 
|Binnen Zaken Zoeken is er de mogelijkheid om de resultaten te exporteren naar Excel, CSV of OpenOfficeCalc. Deze lijst kan desgewenst worden uitgeprint.
 
 
 
|-
 
|56
 
|Binnen een rol moeten archiefbestanddelen dan wel de tot een archiefbestanddeel behorende
 
archiefstukken en alle daarbij behorende metadata (in verschillende volgorde of rangschikking)
 
kunnen worden gepresenteerd, maar het moet ook mogelijk zijn om deze met nader
 
gespecificeerde metadata te presenteren.
 
|Binnen Zaken Zoeken is het mogelijk om een eigen kolomindeling te configureren. Hier kunnen alle kenmerken uit de ZTC worden geselecteerd en worden toegevoegd.
 
 
 
|-
 
|57
 
|Binnen een bepaalde rol moeten de gecontroleerde vocabulaires en/of thesauri kunnen worden
 
gepresenteerd.
 
|Bij het aanmaken van een nieuwe zaak is het mogelijk om dmv autocomplete een zaaktype op te zoeken. Daarnaast is het ook mogelijk om te zoeken op vooraf ingevulde trefwoorden.
 
 
 
Bij Zaken Zoeken is het mogelijk om op waarden te zoeken van kenmerken, zoals bij een meervoudige keuze.
 
 
 
|-
 
|58
 
|Een archiefbestanddeel dan wel een enkel archiefstuk behoort te kunnen worden gepubliceerd
 
(bijvoorbeeld op het intranet of een website), met door de organisatie te bepalen bijbehorende
 
metadata.
 
|Binnen een zaaktype of tijdens de behandeling van een zaak is het mogelijk om kenmerken en/of documenten te publiceren op de PIP.
 
 
 
|-
 
|59
 
|Het behoort mogelijk te zijn een extract van een archiefstuk te presenteren indien een bepaalde
 
rol niet gerechtigd is het eigenlijke archiefstuk te raadplegen.
 
|Dit kan worden opgelost door gebruik te maken van deelzaken. Een bepaalde behandelaar heeft rechten op de hoofdzaak, maar geen rechten op een deelzaak. Hierdoor is het mogelijk om bepaalde documenten en/of kenmerken te verbergen voor gebruikers. Indien er delen van documenten getoond moeten worden, dan kunnen documenten handmatig bewerkt worden en als een nieuwe versie in een (deel)zaak worden toegevoegd.
 
 
 
|}
 
 
 
=== Selecteren ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|60
 
|Aan de hand van criteria kan een reeks archiefbestanddelen worden geselecteerd.
 
De gehele reeks of een deel van de geselecteerde archiefbestanddelen moet kunnen worden
 
gemarkeerd voor verdere verwerking.
 
De verdere verwerking wordt uitgevoerd op individuele archiefstukken/archiefbestanddelen.
 
De verdere verwerking kan bestaan uit bijv. vernietigen, overdragen of exporteren.
 
|Het is mogelijk om met Zaken Zoeken een overzicht te maken van zaken die vernietigd of overgedragen moeten worden.
 
 
 
|-
 
|61
 
|Aan archiefstukken/archiefbestanddelen moeten metadata over de achtergronden van de
 
waardering en/of hoogte van de bewaartermijn kunnen worden toegevoegd.
 
|Binnen het modelleren van een zaaktype kunnen de bewaartermijnen worden aangegeven bij resultaten. De juiste bewaartermijnen worden ingevuld aan de hand van de Selectielijst. Deze wordt ingevuld bij de basisattributen. De lijst staat op deze wiki en binnen de zaaktypen voor vernietiging wordt hiernaar verwezen.
 
 
 
|-
 
|62
 
|Op elk aggregatieniveau moet op basis van criteria automatisch kunnen worden vastgelegd:
 
— de bewaar- of overdrachtstermijn die aan de daartoe behorende archiefstukken/
 
archiefbestanddelen is toegekend;
 
— het vervolgtraject na het verstrijken van de bewaar- of overdrachtstermijn: vernietigen,
 
overdragen of exporteren.
 
|Binnen het zaaktype geef je door middel van resultaten de bewaartermijnen aan. Nadat de bewaartermijn verlopen is, wordt de status van een zaak automatisch naar Te vernietigen of Overdragen gezet.
 
 
 
De uiterste vernietigingsdatum is te vinden binnen het zaakdossier.
 
 
 
|-
 
|63
 
|Aan een specifiek archiefstuk/archiefbestanddeel moet een waardering kunnen worden toegekend
 
die voorrang heeft op een waardering hoger in de hiërarchische structuur, inclusief de waardering
 
dat het niet mag worden vernietigd.
 
|Elke zaak (hoofdzaak of deelzaak) kan de de vernietigingsdatum handmatig worden gewijzigd.
 
 
 
|-
 
|64
 
|Indien aan archiefbestanddelen een nieuw classificatiekenmerk wordt gegeven, moet er de keuze
 
zijn om de daarbij behorende waardering en/of bewaartermijn over te nemen dan wel om de
 
oorspronkelijke te behouden.
 
|Binnen het zaaksysteem kan een zaaktype worden gewijzigd. Dit kan alleen maar bij zaken die in behandeling zijn. Bij een afgehandelde zaak, waarbij de bewaartermjinen worden ingesteld, kan het zaaktype niet meer worden gewijzigd.
 
 
 
|-
 
|65
 
|Binnen een bepaalde rol moet het mogelijk zijn de waardering en/of de bewaartermijn aan te
 
passen.
 
Wijzigingen moeten worden gedocumenteerd.
 
|Door middel van zaakacties is het mogelijk om de bewaartermijn van een zaak te wijzigen. Deze wijziging wordt opgenomen in de logfile.
 
 
 
|-
 
|66
 
|Van archiefstukken/archiefbestanddelen die niet zijn gewaardeerd, moet op elk gewenst
 
aggregatieniveau een overzicht kunnen worden gemaakt.
 
|Omdat alle zaken binnen een zaaktype vallen is het niet mogelijk dat zaken zonder zaaktype vallen.
 
 
 
|-
 
|67
 
|Inzake het beheer van termijnen en bewaarschema’s moeten ten minste de volgende rapportages
 
en analyses kunnen worden gegenereerd:
 
— een overzicht van alle aggregatieniveaus met een bepaalde waardering en/of bewaartermijn;
 
— een overzicht van de waarderingen en/of bewaartermijn(en) die zijn toegekend aan alle
 
archiefbestanddelen onder een bepaalde rubriek in de hiërarchie van het classificatieschema;
 
— een overzicht van de verschillende waarderingen en/of bewaartermijnen voor een archiefstuk
 
indien er van meer waarderingen en/of bewaartermijnen sprake is.
 
|Door gebruik te maken van Zaken Zoeken kan er een lijst worden genereerd waarbij de bewaartermijnen van zaken wordt getoond. Deze lijst kan worden gesorteerd op zaaktype en eventueel worden geexporteerd.
 
 
 
Het is niet mogelijk dat een zaak meerdere bewaartermijnen gelden voor een zaak.
 
 
 
|-
 
|68
 
|Een overzicht van bewaarschema('s) die van toepassing zijn op alle archiefbestanddelen, vanaf
 
een bepaald punt in de hiërarchie van ordening of het classificatieschema, behoort te kunnen
 
worden gepresenteerd.
 
|Met Zaken Zoeken kan je een overzicht presenteren waarbij de elementen worden geconfigureerd met kolommen. Desgwenst kan dit worden gesorteerd.
 
 
 
|-
 
|69
 
|De datum voor vernietigen of overdragen van een archiefstuk/archiefbestanddeel behoort
 
automatisch te kunnen worden berekend.
 
OPMERKING Dit geldt niet als vernietiging plaatsvindt op basis van noodvernietiging.
 
|Bij het instellen van een resultaat wordt de bewaartermijn gezet op een zaak.
 
 
 
|-
 
|70
 
|Van alle op basis van bewaarschema’s uit te voeren verwijderacties binnen een bepaalde periode
 
moet een overzicht kunnen worden gemaakt, zowel ten aanzien van nader gespecificeerde als ten
 
aanzien van bepaalde typen archiefstukken/archiefbestanddelen op elk aggregatieniveau.
 
|Met Zaken Zoeken kan je een overzicht maken waarin diverse filters kunnen worden gebruik. Bijvoorbeeld een zaaktype en/of kenmerken. Hierbij kan ook een specifieke periode worden geselecteerd.
 
 
 
|-
 
|71
 
|Het moet mogelijk zijn verwijderacties op het niveau van metadata-elementen aan te geven.
 
|Om te vernietigen kan gebruik worden gemaakt van een zaaktype opstellen vernietigingslijst. In dit zaaktype zijn kenmerken opgenomen om te waarborgen dat dit gebeurd is.
 
 
 
|}
 
 
 
 
 
 
 
 
 
 
 
=== Verwijderen ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|72
 
|Van archiefstukken/archiefbestanddelen die voor vernietigen, overdragen of exporteren in
 
aanmerking komen moet een overzicht kunnen worden gemaakt, voordat deze acties worden
 
gestart.
 
|Om te vernietigen kan gebruik worden gemaakt van een zaaktype opstellen vernietigingslijst. In dit zaaktype zijn kenmerken opgenomen om te waarborgen dat dit gebeurd is. Deelvernietigingslijsten kunnen worden opgestart waarin de lijsten mbv Zaken zoeken wordt toegevoegd.
 
 
 
|-
 
|73
 
|Op basis van de geldende regels en criteria moet het vernietigen, overdragen of exporteren
 
worden uitgevoerd, waarbij wordt aangegeven welke metadata erover moeten worden behouden.
 
|Dmv Zaken Zoeken is een exportbestand te maken. In dit overzicht kan een eigen kolomindeling worden gekozen aan de hand van de kenmerken (metadata). Deze lijst wordt opgenomen in het uitvoeren van het zaaktype 'vernietigen archiefbestanddelen'.
 
 
 
|-
 
|74
 
|Archiefstukken/archiefbestanddelen op elk aggregatieniveau moeten kunnen worden verwijderd
 
overeenkomstig de als metadata aangegeven waardering en/of bewaar- of overdrachtstermijn.
 
|Het is mogelijk om zaken te vernietigen binnen het zaaksysteem
 
 
 
|-
 
|75
 
|Bij overdragen of exporteren van archiefbestanddelen moeten de bijbehorende metadata worden
 
meegenomen.
 
OPMERKING Met inachtneming van eis 74.
 
|Het is mogelijk om een afgehandelde zaak te exporteren. Documenten worden in OpenOffice formaten geexporteerd (ODT). Alle kenmerken worden meegeleverd in een XML.
 
 
 
|-
 
|76
 
|Ter waarborging van de referentiële integriteit moet een waarschuwing worden gegeven wanneer
 
er een link of verwijzing bestaat tussen verschillende archiefbestanddelen waarvan één
 
archiefbestanddeel op het punt staat te worden vernietigd, overgedragen of geëxporteerd en het
 
andere niet.
 
|Het is voor gebruikers niet mogelijk om kenmerken te markeren die va belang zijn binnen een andere zaak. Het is dus niet mogelijk dat bepaalde kenmerken van een zaak nodig zijn bij een andere zaak. Als dat wel zo is, dan moet deze worden opgenomen in de andere zaak.
 
 
 
|-
 
|77
 
|Indien toch vernietiging, overdracht of export wordt uitgevoerd moet dit worden gedocumenteerd.
 
|Omdat punt 76 niet van toepassing is, vervalt deze eis.
 
 
 
|-
 
|78
 
|Archiefstukken/archiefbestanddelen waarvan de vernietigingsdatum is bereikt, moeten kunnen
 
worden vernietigd door het starten van een speciale functie waarbij per archiefstuk/
 
archiefbestanddeel (op het gewenste aggregatieniveau) om bevestiging wordt gevraagd, voordat
 
daadwerkelijke vernietiging plaatsvindt.
 
|Alle zaken die vernietigd worden, moeten worden aangevinkt. Het is bij het zaaktype vernietigingslijst niet mogelijk om automatisch de zaken te vernietigen. Dit is een handmtige actie die wordt uitgevoerd.
 
 
 
|-
 
|79
 
|Vernietigen van archiefstukken/archiefbestanddelen is niet mogelijk tenzij:
 
— het vernietigen is gebaseerd op een bewaarschema;
 
— het vernietigen is gebaseerd op de regels voor noodvernietiging.
 
|Omdat zaaktypen een bewaartermijn heeft die hoort bij de selectielijst (bewaarschema) kunnen deze niet zelf worden vernietigd.
 
 
 
Noodvernietiging is mogelijk door het uitvoeren van de [http://wiki.zaaksysteem.nl/images/c/cd/Noodvernietiging.png procudere noodvernietiging.]
 
 
 
|-
 
|80
 
|Vernietigen van archiefstukken/archiefbestanddelen moet zo gebeuren dat deze niet meer op
 
enigerlei wijze kunnen worden gereproduceerd.
 
|Nadat zaken zijn vernietigd, is het niet meer mogelijk voor de organisatie om vernietigde zaken te reproduceren. In de beschrijving van de vernietiging
 
 
 
|}
 
 
 
=== Eisen voor documenteren van gebeurtenissen en beheeractiviteiten ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|81
 
|Van toegelaten soorten beheeractiviteiten moet een gecontroleerde woordenlijst kunnen worden
 
vastgelegd.
 
|Deze eis wordt ingevuld doordat diverse beheeractiviteiten worden ingericht door middel van een zaaktype. Daarnaast is de lijst met geadviseerde beherprocessen te vinden op de wiki.
 
 
 
|-
 
|82
 
|Alle beheeractiviteiten met betrekking tot digitale bestanden, archiefbestanddelen, archiefstukken,
 
metadata en instrumenten voor informatie- en archiefmanagement moeten worden
 
gedocumenteerd, bij voorkeur geautomatiseerd op basis van rol en autorisatie. Daarbij moet
 
worden vastgelegd:
 
— de gebruikersidentificatie van de gebruiker binnen een bepaalde rol;
 
— de bevoegdheid, de rol en het mandaat voor de beheeractiviteit;
 
— het soort beheeractiviteit (bijvoorbeeld conversie);
 
— de relatie tot de objecten waarop de beheeractiviteit betrekking heeft of wordt uitgevoerd
 
(digitale bestanden, archiefbestanddelen, archiefstukken, metadata en instrumenten voor
 
informatie- en archiefmanagement);
 
— het resultaat van de beheeractiviteit;
 
— de datum en tijd van het uitvoeren van de beheeractiviteit.
 
|Bij het wijzigen van een zaaktype worden de wijzigingen opgeslagen in een logfile.
 
 
 
|-
 
|83
 
|Het moet mogelijk zijn gegevens m.b.t. beheeractiviteiten op begrijpelijke wijze te presenteren,
 
zodat:
 
— een specifieke gebeurtenis kan worden geïdentificeerd en gereconstrueerd;
 
— alle gerelateerde gegevens raadpleegbaar zijn, ook voor wie geen specifieke kennis van de
 
programmatuur heeft.
 
|Er is een eenvoudige interface gemaakt voor het doorzoeken van de logfiles van zaaktypen.
 
 
 
|-
 
|84
 
|— De applicatiebeheerder moet kunnen aangeven welke gegevens m.b.t. beheeractiviteiten
 
automatisch moeten worden opgeslagen alsmede waar de gegevens vandaan komen
 
(bijvoorbeeld uit een workflowsysteem of door het systeem gegenereerd).
 
— Iedere wijziging in de samenstelling van deze gegevens moet worden gedocumenteerd.
 
— De aangebrachte wijzigingen in de samenstelling van de beheergegevens mogen niet leiden
 
tot mutatie van de reeds opgeslagen gegevens over beheeractiviteiten.
 
|Wanneer er wijzigingen worden aangebracht binnen een zaaktype dan wordt er een nieuwe versie aangemaakt.
 
 
 
|-
 
|85
 
|Gegevens m.b.t. beheeractiviteiten moeten kunnen worden geëxporteerd, zonder dat eerder
 
opgeslagen gegevens worden gemuteerd.
 
|De logfile kan worden gedownload door de beheerder.
 
 
 
|-
 
|86
 
|Metadata t.b.v. beheeractiviteiten (o.a. functionaris/rol, naam, datum, activiteit) moeten
 
automatisch kunnen worden afgeleid van bestaande gegevens (bijvoorbeeld uit workflow- of
 
inloggegevens).
 
|Binnen het zaaktypebeheer wordt een audittrail bijgehouden. Hierin worden verschillende gegevens geregistreerd van de beheeracties.
 
 
 
|-
 
|87
 
|Van de gegevens over beheeractiviteiten moeten ten minste rapporten kunnen worden
 
vervaardigd inzake activiteiten verricht aan rubrieken van het classificatieschema, metadata en
 
archiefbestanddelen of archiefstukken, geordend:
 
— per rubriek van het classificatieschema, per metadata-element en per te bepalen
 
aggregatieniveau, archiefbestanddeel of archiefstuk;
 
— per gebruikersprofiel;
 
— per rol;
 
— op chronologische volgorde.
 
|Bij een logfile is het mogelijk dat je een filter toepast. De resultaten kunnen geexporteerd worden naar een txt bestand.
 
 
 
|-
 
|88
 
|Gegevens over beheeractiviteiten moeten ten minste zo lang worden bewaard als de
 
archiefbestanddelen, de instrumenten voor informatie- en archiefmanagement en de metadata
 
waarop de activiteiten betrekking hebben.
 
|Logfiles worden bewaard en niet vernietigd
 
 
 
|}
 
 
 
 
 
 
 
 
 
 
 
=== Metadatamanagement ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|89
 
|In het metadataschema moet kunnen worden vastgesteld welke metadata-elementen bij
 
registratie verplicht moeten worden ingevuld.
 
|Binnen het zaaktypebeheer is het mogelijk om bij een kenmerk aan te geven dat het verplicht is. Dit betekent dat een zaakregistratie niet kan worden afgerond tot het kenmerk is ingevuld.
 
 
 
|-
 
|90
 
|Het moet mogelijk zijn het geldende metadataschema en de daartoe behorende metadata
 
elementen te documenteren en te onderhouden (incl. toevoegen dan wel verwijderen ervan).
 
|Het onderhouden van zaaktypen kan d.m.v. het zaaktypebeheer. Het documenteren van het metadata-schema gebeurt via de audittrail van de zaaktypen.
 
 
 
|-
 
|91
 
|Er moet kunnen worden gedocumenteerd welke validatietabellen (zoals gecontroleerde
 
woordenlijsten, thesauri of classificatieschema’s) geldig zijn voor bepaalde metadata-elementen
 
inclusief mogelijke relaties naar een bewaarschema, beveiligingsniveaus enz.
 
|In een zaaktype staat geconfigureerd welke kenmerken, rechten en basisattributen een zaaktype heeft. In het zaaktypebeheer is het mogelijk om de relaties met deze objecten te bekijken.
 
 
 
|-
 
|92
 
|In het geval dat één of meer metadata-elementen uit het metadataschema worden vervangen of
 
toegevoegd, moet dit worden gedocumenteerd en moet in het eerste geval de relatie tussen de
 
archiefbestanddelen en de vervangen metadata-elementen bewaard blijven.
 
De relatie naar archiefbestanddelen die onder het regime van het oude metadataschema vallen
 
moet worden vastgehouden.
 
In geval van verwijderen of niet meer toepasselijk verklaren van een metadata-element uit een
 
metadata-schema moeten de reeds ingevulde waarden bij de archiefstukken behouden blijven.
 
|Binnen het ZTB wordt gebruik gemaakt van versiebeheer. Dit betekent dat een aangevraagde zaak van een ouder zaaktype alle metadata behoudt van dat zaaktype. Wijzigingen van een zaaktype worden gelogd.
 
 
 
|-
 
|93
 
|Metadata-elementen kunnen worden ingevuld:
 
— door middel van geautomatiseerde extractie;
 
— door invoer via het toetsenbord;
 
— met behulp van een gecontroleerde woordenlijst.
 
|Handmatig kenmerken wijzigen kan uiteraard. Het is ook mogelijk om door middel van een koppeling kenmerken in te vullen. Bijvoorbeeld de koppeling van BuitenBeter.
 
 
 
|-
 
|94
 
|Het moet mogelijk zijn aan metadata-elementen een standaard waarde te geven.
 
|Het is mogelijk om gebruik te maken van een voorinvulling bij het aanmaken van een kenmerk.
 
 
 
|-
 
|95
 
|Het moet niet mogelijk zijn het opslaan van metadata m.b.t. wijziging van autorisatieregels,
 
systeemparameters of logging-instellingen uit te schakelen.
 
|De logging-functionaliteit kan door geen enkele rol worden uitgeschakeld binnen het systeem. Daarbij is conform de overeenkomst niet toegestaand dat de leverancier ‘onder water’ de logfiles verwijderd of de functionaliteit van logging uitzet.
 
 
 
|-
 
|96
 
|Het moet mogelijk zijn regels m.b.t. de metadata-elementen in te voeren en te onderhouden.
 
|Het is mogelijk om regels te gebruiken binnen het zaaktypebeheer.
 
 
 
|-
 
|97
 
|Op basis van het geldende metadataschema en de geldende vertaaltabellen behoren metadata uit
 
andere systemen te kunnen worden geïmporteerd dan wel naar andere systemen te kunnen
 
worden geëxporteerd.
 
|Het is mogelijk om zaken te importeren middels de tussenkomst van de ontwikkelaar. Een voorbeeld is het importscript van de bouwvergunningen uit Corsa. De export kan worden gerealiseerd via de export.
 
 
 
|-
 
|98
 
|Het moet mogelijk zijn één overzicht te presenteren van alle gedefinieerde metadata voor één
 
archiefbestanddeel op elk aggregatieniveau.
 
|Bij het zaaktypebeheer is het mogelijk om alle metadata te bekijken en te bewerken. Het ‘openen’ van een zaaktype geeft dus het gewenste overzicht van alle kenmerken die bij een zaaktype horen.
 
 
 
|}
 
 
 
=== Autorisatie ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|99
 
|Alle gebruikerstaken of beheeractiviteiten moeten uitsluitend als rollen aan een gebruikerprofiel
 
kunnen worden toegekend. Deze gebruikersprofielen en rollen zijn vastgelegd in een
 
autorisatietabel (zie 6.8.3).
 
|Het zaaksysteem maakt gebruik van OpenLDAP. Hierbinnen is het mogelijk om met containers, rollen en gebruikers te werken. Deze rechten kunnen gebruikt worden in het zaaksysteem.
 
 
 
|-
 
|100
 
|Toegangsrechten voor archiefbestanddelen, beheeractiviteiten dan wel metadata moeten zijn
 
gebaseerd op het gebruikersprofiel.
 
|Aan de hand van de rechten in het zaaktype en standaard rechten ontvangt een bepaalde gebruiker zijn of haar rechten.
 
 
 
|-
 
|101
 
|Voor de applicatiebeheerder moet een apart gebruikersprofiel kunnen worden gedefinieerd.
 
Uitsluitend vanuit dit profiel kan de applicatiebeheerder rollen en gebruikersprofielen definiëren en
 
rollen toekennen aan gebruikers.
 
|De beheerder kan gebruik maken van Directory Studio of /medewerker
 
 
 
|-
 
|102
 
|De functionaliteit van een rol (per individu of groep) moet:
 
— de toegang kunnen beperken tot bepaalde archiefbestanddelen of archiefstukken (op elk
 
aggregatieniveau);
 
— de toegang kunnen beperken tot bepaalde rubrieken van de actuele classificatieschema’s;
 
— de toegang kunnen regelen in overeenstemming met toegekende autorisaties;
 
— bepaalde functionaliteiten kunnen beperken m.b.t. de beheerde objecten (digitale bestanden,
 
archiefbestanddelen, instrumenten voor informatie- en archiefmanagement);
 
— bepaalde activiteiten kunnen beperken m.b.t. metadata (bijvoorbeeld lezen, muteren en/of
 
verwijderen van bepaalde metadata bij registratie);
 
— een tijdslimiet kunnen toekennen aan de verleende toegangsrechten;
 
— de toegang kunnen weigeren vanaf een bepaalde datum (bijvoorbeeld wanneer een gebruiker
 
van organisatieonderdeel of organisatie verandert).
 
|De rol zaaksysteembeheer kan bij het zaaktypebeheer rechten verlenen op basis van de structuur uit de LDAP. Dit moet per zaaktype worden ingericht. Binnen de rechten van een zaaktype kun je kiezen tussen leesrechten, schrijfrechten en beheerrechten.
 
 
 
Het is niet mogelijk om op kenmerkniveau rechten uit te delen. Dit is vanuit de visie dat het veiliger is om rechten op zaakniveau te geven. Dit bevordert de samenwerking en verbetert de dienstverlening. Zaaksysteem.nl is van mening dit het oplossen van HR-problemen door middel van techniek zou zijn.
 
 
 
Dit wordt opgelost door een pocedure. OpenLDAP ondersteund de Attribute 'disabled' niet. Gebruikers moeten bij de lokale AD van de gemeente verplaatst worden naar een Container Disabled (of een andere container die niet wordt uitgelezen). Het zaaksysteem detecteerd dan dat de gebruiker is verplaatst en verwijderd de gebruiker. Gemeenten moeten hiervoor een procedure opstellen.
 
 
 
|-
 
|103
 
|Het gebruiken van hardwarematige sleutels ('smartcard', biometrische identificatie enz.) behoort te
 
worden ondersteund.
 
|Deze functionaliteit wordt niet ondersteund.
 
 
 
|-
 
|104
 
|De toegang moet worden geweigerd indien niet wordt beschikt over het juiste gebruikersprofiel
 
(bijvoorbeeld via gebruikersnaam en wachtwoord of anderszins).
 
|Zonder de juiste rechten vanuit de OpenLDAP wordt de toegang verboden. Een gebruiker ziet alleen hetgeen waartoe hij (of zij) toegang heeft.
 
 
 
|-
 
|105
 
|Als de applicatie actief is moet het mogelijk zijn, in het geval een gebruiker toegang vraagt tot, of
 
zoekt naar een archiefbestanddeel waartoe hij geen toegangsrechten heeft, één van de volgende
 
reacties te geven:
 
— het tonen van de titel en de metadata;
 
— het tonen van het identificatienummer of de identificatiecode;
 
— geen enkel gegeven of indicatie van het bestaan tonen.
 
|Een gebruiker mag alleen die objecten zien waartoe hij of zij rechten heeft.
 
 
 
|-
 
|106
 
|De gebruiker moet kunnen zien welk gebruikersprofiel hij heeft
 
OPMERKING Het gaat hier met name om de autorisatie met betrekking tot mogelijke beheeractiviteiten op
 
een archiefbestanddeel.
 
|In het overzicht van een behandelaar is te zien welke rollen iemand heeft.
 
 
 
|-
 
|107
 
|Een gebruiker behoort te kunnen bepalen welke andere gebruikers toegang krijgen tot
 
archiefbestanddelen en/of processen waarvoor deze gebruiker verantwoordelijk is.
 
|Een gebruiker kan zelf de behandelaar wijzigen. Wanneer dit een gebruiker is die geen rechten heeft, ontvangt hij voor deze specifieke zaak rechten omdat hij op behandelaar is gezet.
 
 
 
|-
 
|108
 
|Pogingen tot inbreuk op toegangsrechten moeten kunnen worden gedocumenteerd.
 
OPMERKING Het gaat met name om pogingen van gebruikers om toegang te krijgen tot
 
informatieobjecten of processen waartoe zij geen recht hebben. Gedocumenteerd wordt: wat, door wie,
 
wanneer en hoe.
 
|In de serverlogfiles worden alle pogingen tot betrekking tot ogeautoriseerde toegang tot het systeem, onderdelen of zaken bewaard. Op verzoek kan een kopie worden verstrekt van een (gedeelte) van de serverlogs.
 
 
 
Locatie serverlogs
 
 
 
|}
 
 
 
=== Ondersteunen van (workflow van) beheeractiviteiten ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|109
 
|De beheeractiviteiten behoren te kunnen worden ondersteund met functionaliteit voor workflow.
 
|Dit kan worden ingericht met zaaktypen. Voorbeeld hiervan is de vernietigingslijst.
 
 
 
|-
 
|110
 
|Het behoort mogelijk te zijn de status van de afhandeling, de bewerking en het gebruik van
 
archiefbestanddelen en digitale bestanden bij te houden en te overzien.
 
|Elke zaak heeft een status. Daarnaast is de voortgang te volgen d.m.v. faseringen.
 
 
 
|-
 
|111
 
|Het moet mogelijk zijn verschillende rapportages te definiëren met verschillende
 
presentatiemogelijkheden.
 
|Met Zaken zoeken is het mogelijk om verschillende rapportages te generen en te exporteren. In deze rapportages kan op nagenoeg alles worden gefilterd waarvan zaken zijn geregistreerd.
 
 
 
|-
 
|112
 
|Het moet mogelijk zijn (management)informatie te genereren die qua samenstelling en
 
presentatie(volgorde) kan worden aangepast en vervolgens kan worden gepresenteerd in
 
leesbare vorm en/of die kan worden geëxporteerd naar een andere applicatie (bijvoorbeeld een
 
tekstverwerkings- of spreadsheetapplicatie).
 
|Zoekresultaten kunnen worden geexporteerd naar Excel, CSV open een open formaat.
 
 
 
|-
 
|113
 
|Het behoort binnen een bepaalde rol mogelijk te zijn standaard rapportages op een in te stellen
 
tijdstip en/of met een bepaalde regelmaat uit te voeren.
 
|Het is mogelijk zoekopdrachten op te slaan, te delen en hierin een periode op te geven.
 
 
 
|-
 
|114
 
|Er behoort een standaard voorziening te zijn voor het willekeurig samenstellen van rapportages
 
op basis van zoekresultaten voor managementinformatie.
 
|Deze voorziening is aanwezig d.m.v. Zaken Zoeken.
 
 
 
|-
 
|115
 
|Het behoort mogelijk te zijn rapporten aan te maken met gegevens voor de applicatiebeheerder,
 
inzake:
 
— de mutaties binnen het classificatieschema over een bepaalde periode;
 
— het aantal gecreëerde, afgesloten of verwijderde archiefbestanddelen;
 
— archiefbestanddelen binnen het classificatieschema of onderdelen daarvan.
 
|Met het Logfile-apparaat wordt gedeeltelijk voldaan aan deze optie.
 
 
 
|-
 
|116
 
|De applicatiebeheerder moet alle (bij inrichting van de applicatie en daarna op wens van de
 
organisatie) ingestelde administratieve parameters, of een selectie daaruit, op het scherm kunnen
 
oproepen.
 
|Dit kan door gebruik te maken van het zaaktypebeheer. Hierin staan alle parameters van een zaaktype en kunnen worden opgeroepen.
 
 
 
|}
 
 
 
 
 
 
 
 
 
 
 
=== Documenteren van systeem waarin en/of waarmee archiefstukken worden beheerd ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|117
 
|Het moet mogelijk zijn gegevens vast te leggen over het systeem waarin en/of waarmee
 
archiefstukken worden beheerd, bij voorkeur door automatische extractie. Het gaat hierbij ten
 
minste om:
 
— de naam van de applicatie;
 
— het versienummer of een andere identificatie;
 
— een korte omschrijving van de aard van de applicatie;
 
— de datum sinds wanneer de applicatie wordt gebruikt;
 
— de datum waarop de applicatie niet meer wordt gebruikt;
 
— eventueel de leverancier;
 
— het type licentie;
 
— (verwijzing naar) beschikbare documentatie.
 
|Binnen de zaaktypecoltalogus bestaat er een systeemkenmerk uname waarin deze informatie kan worden getoond.
 
 
 
|-
 
|118
 
|Telkens indien de archiefstukken worden gemigreerd, bijvoorbeeld omdat een bestandsformaat
 
veroudert of is verouderd, behoren de gegevens over de nieuwe applicatie te worden vastgelegd,
 
zodat een historie ontstaat van applicaties waarmee archiefstukken zijn gemaakt en beheerd.
 
|Deze optie is niet van toepassing omdat het zaaksysteem het generieke systeem voor de organisatie is.
 
 
 
|-
 
|119
 
|De gegevens over de applicatie moeten kunnen worden geëxporteerd tegelijk met (eraan
 
gerelateerde) archiefstukken wanneer deze worden overgebracht naar een andere applicatie.
 
|Binnen exportfunctionaliteit worden de gegevens van de versie van het zaaksysteem meegeleverd.
 
 
 
|-
 
|120
 
|De volgende gegevens over het proces van verificatie van een digitale handtekening moeten ten
 
minste worden vastgelegd:
 
— het feit dat de waarde en status van de handtekening zijn gecontroleerd;
 
— de uitslag van de verificatie;
 
— de certificatiedienstverlener;
 
— de datum en tijd waarop verificatie heeft plaatsgevonden;
 
— indien aanwezig informatie over het certificaat.
 
|In het standaard zaaktype is een aantal checklistitems opgenomen die de verificatie van een digitale handtekening vastleggen.
 
 
 
|}
 
 
 
 
 
 
 
 
 
 
 
=== Authenticatie en encryptie ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|121
 
|Bij het opnemen van een versleuteld informatieobject moeten ten minste de volgende metadata
 
worden vastgelegd:
 
— het feit van de versleutelde doorzending;
 
— het type algoritme;
 
— het encryptieniveau dat is gebruikt.
 
|Bij zaaksysteem.nl is hanteert de visie dat documenten niet-versleuteld opgeslagen worden. Dit in het kader van de leesbaarheid over een langere periode. Door documenten versleuteld op te slaan, is niet te garanderen dat deze over 100 jaar nog gelezen kunnen worden. Door documenten niet-versleuteld op te slaan wordt de digitale duurzaamheid vergroot. Indien een behandelaar een versleuteld bestand ontvangt, moet de versleuteling worden verwijderd alvorens deze in het zaakdossier toe te voegen. Derhalve is deze eis niet van toepassing.
 
 
 
|-
 
|122
 
|Vanwege veiligheidsoverwegingen behoren archiefstukken versleuteld te kunnen worden
 
opgeslagen.
 
|Het is mogelijk om objecten op te slaan, dus ook gecodeerde objecten.
 
 
 
|-
 
|123
 
|Alle bij het desbetreffende bedrijfsproces gangbare encryptietechnologieën moeten kunnen
 
worden verwerkt.
 
OPMERKING Ook archivering is een bedrijfsproces; in het geval dat deze eisen worden toegepast op een
 
speciaal daarvoor bestemde recordsmanagementapplicatie (RMA) moeten alle binnen de organisatie
 
gangbare encryptietechnologieën kunnen worden ondersteund.
 
|Indien gewenst kan er koppeld worden met een externe applicatie die de encrypte en decryptie verzorgd.
 
 
 
|-
 
|124
 
|Alle bij het desbetreffende bedrijfsproces gangbare technologieën voor digitale handtekeningen
 
moeten kunnen worden ondersteund.
 
|Het zaaksysteem maakt gebruik van gangbare technologien doordat er met OpenSSL wordt gewerkt. Zo werkt het zaaksysteem met certificaten voor de communicatie met de webbrowser.
 
 
 
|-
 
|125
 
|Op het moment van opname van informatieobjecten behoren de waarde en status van een
 
digitale handtekening te kunnen worden gecontroleerd.
 
|In het standaard zaaktype is een aantal checklistitems opgenomen die de verificatie van een digitale handtekening vastleggen.
 
 
 
|-
 
|126
 
|Indien de digitale handtekening zelf wordt opgeslagen, behoren tevens te worden opgeslagen:
 
* een (digitaal) certificaat om de waarde en status van de handtekening te kunnen controleren;
 
* ieder bevestigend contrasign dat is toegevoegd door de certificatiedienstverlener, op zodanige wijze dat deze in combinatie met het archiefstuk kunnen worden opgevraagd zonder afbreuk te doen aan de kwaliteit van de publieke sleutel;
 
 
 
OPMERKING Dit kan alleen indien de hele validatieketen nog intact is.
 
|Dit is afhankelijk van de digitale handtekening die wordt gebruikt.
 
 
 
|-
 
|127
 
|Het behoort mogelijk te zijn een informatieobjectspecifiek en uniek watermerk aan een archiefstuk toe te kennen.
 
|Technisch is het mogelijk, maar dit wordt niet toegepast omdat dit afbreuk zou doen aan de autheticiteit van het archiefstuk.
 
 
 
|-
 
|128
 
|Eventuele encryptie of watermerk van een informatieobject moet kunnen worden verwijderd bij het opnemen, waarna toegang tot deze informatieobjecten kan worden beperkt tot een bepaald gebruikersprofiel of een bepaalde rol.
 
|Bij zaaksysteem.nl is hanteert de visie dat documenten niet-versleuteld opgeslagen worden. Dit in het kader van de leesbaarheid over een langere periode. Door documenten versleuteld op te slaan, is niet te garanderen dat deze over 100 jaar nog gelezen kunnen worden. Door documenten niet-versleuteld op te slaan wordt de digitale duurzaamheid vergroot. Indien een behandelaar een versleuteld bestand ontvangt, moet de versleuteling worden verwijderd alvorens deze in het zaakdossier toe te voegen. Derhalve is deze eis niet van toepassing.
 
 
 
|}
 
 
 
=== Selectieinstrumenten ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|129
 
|Het moet mogelijk zijn om onderhoud te plegen op de selectiebeslissing, zoals bijvoorbeeld
 
vastgelegd in een bewaarschema; bijvoorbeeld deze te wijzigen, aan te vullen of te verwijderen,
 
zonder de oude gegevens te verliezen.
 
OPMERKING 1 Voor overheidsorganen kan dit het gevolg zijn van toepassing van criteria voor
 
uitzondering van vernietiging m.b.t. voor vernietiging in aanmerking komende archiefstukken.
 
OPMERKING 2 Hieronder valt ook opschorting van verwijderen bijv. in geval van een rechtszaak.
 
|Dit is mogelijk door de vernietigingsdatum handmatig te wijzigen.
 
 
 
|-
 
|130
 
|Alle wijzigingen (inclusief verwijderen) moeten kunnen worden gedocumenteerd door de volgende
 
gegevens vast te leggen: door wie gedaan, met welke autorisatie (op basis van welke
 
bevoegdheid), wanneer, eventueel waarom en m.b.t. wat.
 
|Dit wordt opgelost doordat het vernietigingsproces wordt ondersteund met een zaaktype vernietigingslijst. Daarnaast is er op zaaktypeniveau een logfile beschikbaar.
 
 
 
|-
 
|131
 
|Het moet mogelijk zijn overzichten van de selectiecriteria en -beslissingen met de bijbehorende
 
onderbouwing samen te stellen en op het scherm te presenteren.
 
OPMERKING Bijvoorbeeld: een basisselectiedocument.
 
Daarbij moeten verschillende zoekcriteria kunnen worden ingesteld.
 
|In de wiki wordt de Selectielijst opgenomen die van toepassing zijn of zijn geweest.
 
 
 
|-
 
|132
 
|Het moet mogelijk zijn om een bewaarschema te importeren. ‘Mapping’ met het geldende
 
metadataschema moet daarbij mogelijk zijn.
 
|De geldende bewaartermijnen worden opgeslagen in een tabel die beschikbaar is in het zaaktypebeheer. Indien gewenst kan dit schema (semi) automatisch worden aangepast.
 
 
 
|-
 
|133
 
|Het moet mogelijk zijn criteria voor noodvernietiging vast te leggen.
 
OPMERKING Dit kan bijv. in een apart, speciaal ontworpen bewaarschema.
 
|De noodvernietiging is geregeld via een proces.
 
 
 
|}
 
 
 
 
 
 
 
 
 
 
 
=== Classificatieschema ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|134
 
|Het moet mogelijk zijn om meer dan één classificatieschema in te voeren, te documenteren, te
 
onderhouden en te gebruiken.
 
Elk classificatieschema moet worden voorzien van een datum en/of versienummer, alsmede de
 
status ervan.
 
Binnen een (door de organisatie te definiëren) domein mag slechts één classificatieschema
 
actueel zijn.
 
|Bij zaaksysteem.nl is gekozen voor de zaaktypecatalogus. Dit is het leidende classificatieschema. Het is standaard mogelijk om gebruik te maken van tevens de:
 
 
 
-  Selectielijst
 
-  Zaaktypecode
 
-  IV-3
 
 
 
Daarnaast is het mogelijk om met behulp van kenmerken andere classificatieschema’s toe te voegen.
 
 
 
|-
 
|135
 
|Elk classificatieschema moet zijn eigen identificerende metadata hebben (naam, periode van
 
gebruik).
 
|De identificerende metadata wordt op zaaktypeniveau georganiseerd. Per zaaktype is in de log te bekijken welke naam wordt gehanteerd en de periode van gebruik.
 
 
 
|-
 
|136
 
|De bestaande functionaliteit van het bij de organisatie in gebruik zijnde classificatieschema moet
 
volledig worden ondersteund, ongeacht het type classificatieschema.
 
|De zaaktypecatalogus is een classificatieschema bij alle gemeenten in gebruik.
 
 
 
|-
 
|137
 
|Het moet mogelijk zijn:
 
* een gedistribueerd classificatieschema te ondersteunen, dat ook over meer databases en systemen kan worden gehandhaafd en
 
* een koppeling te leggen naar een extern classificatieschema.
 
|Het zaaksysteem kan externe classificatieschema's inlezen en gebruiken. Enkele voorbeelden hiervan zijn de basisregistraties GBA, BAG en de KvK. De modellen hiervan zijn te vinden onder Systeemdocumentatie. Er zijn ook andere classificatieschema's zoals een Producten- en Dienstencatalogus in te lezen. Hiervoor wordt de standaard van MijnOverheid gehanteerd. Een ander voorbeeld is ook het kunnen inlezen van de Zaaktypecatalogus 1.0. De visie van het zaaksysteem is om zo min mogelijk gebruik te maken van externe distributielijsten omdat dit altijd gerealiseerd moet worden met een koppeling. Koppelingen zijn doorgaans duur in aanschaf en onderhoud.
 
 
 
|-
 
|138
 
|Het moet mogelijk zijn om binnen het classificatieschema ten minste twee soorten naamgeving
 
toe te passen voor rubrieken:
 
— een gestructureerd numeriek of alfanumeriek referentiekenmerk,
 
— een titel of beknopte beschrijving.
 
Beide vormen van naamgeving moeten afzonderlijk of samen kunnen worden toegepast. Indien
 
afzonderlijk toegepast moeten ze binnen het schema uniek zijn.
 
|Het is mogelijk om een mappenstructuur aan te brengen binnen de zaaktypecatalogus. Een organisatie kan zelf aangeven welke categorieen hier worden toegepast. Bijvoorbeeld een processenkaart of de generieke categorieen van de Gemma.
 
 
 
|-
 
|139
 
|Indien het classificatieschema hiërarchisch is gestructureerd, mag er geen beperking zijn aan het
 
aantal toe te kennen niveaus van het classificatieschema.
 
|Het is mogelijk om meerdere mappen aan te maken. Er is geen beperking. Het is wel aan te raden om dit tot een minimun te beperken.
 
 
 
|-
 
|140
 
|In het classificatieschema moeten op iedere gewenste plaats veranderingen kunnen worden
 
aangebracht, ongeacht het niveau en moeten onder willekeurig welke rubriek, nieuwe rubrieken
 
kunnen worden toegevoegd, waarbij selecties van archiefbestanddelen uit de desbetreffende
 
rubriek moeten kunnen worden opgenomen in één van de nieuwe rubrieken.
 
|Objecten worden toegevoegd op zaakniveau dus alleen bij een zaak. Het is niet mogelijk om binnen de mappenstructuur bijvoorbeeld documenten te plaatsen.
 
 
 
Het tweede gedeelte van de eis is niet van toepassing.
 
 
 
|-
 
|141
 
|Bij wijzigingen in het classificatieschema moet de consistentie binnen het schema alsmede tussen
 
het schema en de archiefbestanddelen gewaarborgd blijven. Bij het wijzigen van het
 
classificatieschema ontstaat een nieuwe versie.
 
|Bij het wijzigen van een zaaktype onstaat er een nieuwe versie, waardoor de consistentie niet beheerd hoeft te worden omdat er geen echte wijziging plaatsvindt.
 
 
 
|-
 
|142
 
|Als een nieuwe rubriek in een classificatieschema wordt opgenomen en als de codes van het
 
classificatieschema volgnummers zijn, moet automatisch het volgende vrije volgnummer kunnen
 
worden gegenereerd voor die positie binnen het classificatieschema.
 
|Deze eis is niet van toepassing omdat er geen volgnummers worden gehanteerd bij zaaktypen.
 
 
 
|-
 
|143
 
|Het behoort mogelijk te zijn rubrieken binnen de structuur van het classificatieschema te
 
verplaatsen, alsmede alle daartoe behorende (gezamenlijke of afzonderlijke) archiefbestanddelen,
 
onder de volgende voorwaarden.
 
— De archiefbestanddelen die vóór de verplaatsing tot een bepaalde rubriek behoorden, moeten
 
daartoe ook na het verplaatsen blijven behoren.
 
— Dergelijke verplaatsingen binnen een classificatieschema behoren automatisch te kunnen
 
worden gedocumenteerd (door wie, wanneer en verplaatsing vanuit welke rubriek).
 
OPMERKING Deze functionaliteit is bedoeld voor bijzondere situaties zoals bij reorganisaties of om
 
administratieve fouten te herstellen.
 
|Binnen de mappenstructuur is het mogelijk zaaktypen te verplaatsen. Dit houdt in dat de relatie met de map (id) wordt gewijzigd.
 
 
 
|-
 
|144
 
|Het behoort mogelijk te zijn een overzicht van het classificatieschema te maken.
 
|Alle kenmerken, sjablonen en zaaktypen zitten in de zaaktypecatalogus. Dit is direct het overzicht van het classificatieschema.
 
 
 
|}
 
 
 
=== Autorisatietabel ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|145
 
|Het moet mogelijk zijn om één en niet meer dan één autorisatietabel in te voeren, te documenteren, te gebruiken en te onderhouden.
 
|Het zaaksysteem maakt gebruik van RBS binnen OpenLDAP. Alle rollen zijn gedefinieerd binnen de structuur van OpenLDAP. De rollen (die hierin beheerd worden) kunnen worden ingezet binnen een zaaktype om rechten te verdelen.
 
 
 
|-
 
|146
 
|De autorisaties voor beheeractiviteiten worden toegekend per rol. Daarbij wordt gedocumenteerd:
 
* de benaming van de rol;
 
* de rechten dan wel beperkingen;
 
* de wijzigingen in de rechten;
 
* de datum van de wijziging;
 
* de periode waarin de rechten geldig zijn.
 
|In de wiki staat beschreven wat de standaard rollen zijn binnen het zaaksysteem. In dit overzicht staat beschreven:
 
-  Naam van de rol
 
-  Rechten
 
-  Wijziginen (eventueel)
 
-  Datum actief
 
-  Periode actief
 
 
 
|-
 
|147
 
|Alle gebruikers moeten een gebruikersprofiel hebben. Daarbij wordt gedocumenteerd:
 
— de gebruikersidentificatie;
 
— de rol(len)/functie(s) die de gebruiker vervult;
 
— een persoonsgebonden sleutel (informatie en/of kenmerken waarmee iedere gebruiker zich
 
uniek kan identificeren (zoals een wachtwoord));
 
— wijzigingen in rol(len) (wat, waarom, door wie, wanneer);
 
— de periode waarin de rol(len) door de gebruiker wordt/worden vervuld;
 
— de vervaldatum van het gebruikersprofiel.
 
|In het zaaksysteem worden geen gebruikers 'beheerd' omdat dit in de Active Directory (of een andere gebruikersregistratie) van de gemeente gebeurt. De gegevens van de gebruikers worden gekopieerd naar het zaaksysteem, waarna de beheerder van het zaaksysteem rollen kan toevoegen aan een specifieke gebruiker. Wordt een gebruiker verwijderd uit de Active Directory, dan wordt deze verwijderd uit de kopie (OpenLDAP) van het zaaksysteem. Indien het noodzakelijk is om het proces te volgen van de verwijdering van een gebruiker, dan zal dus ook de lokale logging gebruikt moeten worden. Bijvoorbeeld van Active Directory of een andere vorm van documentatie die door de gemeente wordt gebruikt.
 
 
 
|}
 
 
 
=== Beveiligingsniveau van archiefstukken en/of archiefbestandsdelen ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|148
 
|Beveiliging van archiefbestanddelen moet kunnen worden gerealiseerd op de volgende niveaus:
 
* rubrieken in het classificatieschema;
 
* archiefbestanddelen op elk aggregatieniveau;
 
* metadata.
 
|Beveiliging van zaken kunnen worden beveiligd op zaaktypeniveau. Binnen een zaaktype krijgt een gebruiker rechten. Er is dus maar een niveau. om die reden vindt de beveiliging dus ook maar op een niveau plaats.
 
 
 
|-
 
|149
 
|De verschillende beveiligingsniveaus gerelateerd aan archiefbestanddelen moeten in een logisch
 
(hiërarchisch) samenhangend beveiligingsmodel kunnen worden ondergebracht, waarin elk
 
niveau van deze hiërarchie door een afzonderlijk kenmerk wordt vertegenwoordigd.
 
|Het zaaksysteem maakt gebruik van een eenvoudig beveiligingsmodel:
 
 
 
*  Zaken raadplegen
 
*  Zaken wijzigen
 
*  Zaken beheren
 
 
 
|-
 
|150
 
|Het moet mogelijk zijn de beveiligingsniveaus van rubrieken in het classificatieschema, archiefbestanddelen en/of de bijbehorende metadata aan te passen.
 
|Autorisaties (rechten) kunnen worden gewijzigd in het zaaktypebeheer. Standaard heeft een gebruiker geen rechten op een zaaktype of een zaak. Deze rechten moeten worden ingesteld per zaaktype.
 
 
 
|-
 
|151
 
|Aan een rubriek mag geen lager beveiligingsniveau worden toegekend dan aan de naasthogere rubriek.
 
|Omdat de zaaktypecatalogus de enige rubriek is, zijn er geen andere niveaus. Deze eis is dus niet van toepassing.
 
 
 
|-
 
|152
 
|Aan een archiefstuk of archiefbestanddeel mag geen lager beveiligings(sub)niveau worden toegekend dan aan de rubriek of het archiefbestanddeel op het naasthogere aggregatieniveau.
 
 
 
OPMERKING: Hiertoe behoort ook de mogelijkheid dat binnen een archiefbestanddeel bepaalde
 
archiefstukken vertrouwelijk kunnen zijn.
 
|Omdat de zaaktypecatalogus de enige rubriek is, zijn er geen andere niveaus. Deze eis is dus niet van toepassing. Een zaak kan maar bij een zaaktype horen.
 
 
 
|-
 
|153
 
|Het behoort mogelijk te zijn de beveiligingsniveaus weer te geven die voor het geselecteerde item
 
(rubriek, archiefbestanddeel, archiefstuk en/of metadata ) zijn ingesteld, alsmede de
 
toegangsrechten binnen een bepaalde rol.
 
|Binnen het zaaktypebeheer kan de beheerder de rechten vinden van een zaaktype. omdat er maar een niveau is, zijn meerdere niveaus niet van toepassing.
 
 
 
|}
 
 
 
=== Gecontroleerde woordenlijsten ===
 
{| class="wikitable" border="1"
 
|-
 
! scope="col" width="200pt"| NR.
 
! scope="col" width="700pt"| Eis
 
! scope="col" width="700pt"| Reactie
 
 
 
|-
 
|154
 
|Het moet mogelijk zijn één of meer gecontroleerde woordenlijsten en/of thesauri in te voeren en te onderhouden.
 
|Het is mogelijk om trefwoorden op te geven bij een zaaktype. Hierop kan worden gezocht. Het maakt hierbij niet uit of gedeelte of het gehele woord wordt opgegeven.
 
 
 
|-
 
|155
 
|Binnen een bepaalde rol moet kunnen worden bepaald welke gegevenselementen van het metadataschema zullen worden gecontroleerd door gecontroleerde woordenlijsten of thesauri.
 
|Een zaaktypebeheer heeft de rechten om de trefwoorden op te geven. Daarnaast heeft hij of zij de rechten om zelf kenmerken aan te maken en kan hierbij kiezen voor een zelf te definieren dropdown, checkbox of radiobuttons.
 
 
 
|}
 

Versie van 24 jul 2013 om 04:04

Doorverwijzing naar: