Noark 5
Standard for elektronisk arkiv

Ver 1.2
INNHOLD
1.5 Forholdet til nordisk standardiseringsarbeid 9
1.6 Forholdet til internasjonalt standardiseringsarbeid 10
2 Juridiske rammebetingelser 11
2.2 Forholdet til forvaltningens arkivfunksjon 11
2.4 Arkivloven med forskrifter 13
2.4.2 Arkiveringsplikt og arkivbegrensning 14
2.4.4 Kassasjon og sletting 15
2.6.1 eForvaltningsforskriften 16
2.8 Lov om elektronisk signatur 17
2.10 Beskyttelsesinstruksen 18
3 Noark 5: Nasjonal standard for arkivdanning 19
3.1 Bruksområder for Noark 5 19
3.2 Oppbygging av kravstrukturen i Noark 5 19
3.3 Overgang fra Noark-4 til Noark 5 21
3.5 Noark 5: Aktuell for privat og offentlig sektor 22
3.6 Arkivdanning som del av verdiskapningen 23
4.1.1 Noark 5 kjerne og Noark 5 komplett 25
4.1.4 Forholdet til Noark 4 og Moreq2 31
4.2.3 Klassifikasjonssystem og Klasse 44
4.2.6 Dokumentbeskrivelse og Dokumentobjekt 62
4.2.7 Fellesfunksjonalitet til arkivstrukturen 67
4.2.8.1 Generelle krav til dokumentfangst 73
4.2.8.2 Elektronisk dokumentutveksling 78
4.2.8.3 Migrering mellom Noark-løsninger 79
4.2.10 Bevaring og kassasjon 83
4.2.13 Administrasjon av kjernen 98
4.2.13.1 Sletting av versjoner, varianter og formater 100
4.3.1 Administrativ oppbygging 104
4.3.2 Brukeradministrasjon 105
4.3.2.1 Roller og tilknyttede rettigheter 106
4.3.5 Møte- og utvalgsbehandling 118
4.3.6 Rapportering og statistikker 121
4.3.6.4 Saksmappe- og dokumentoversikt 127
4.3.6.9 Liste for bortsetting, avlevering og overføring 134
4.3.7 Sikkerhet og tilgangsstyring 137
6 Saksbehandlingsløsninger 149
6.1 Krav til adresseregister i saksbehandlingsløsningen 149
6.2 Krav til saksoppfølging i saksbehandlingsløsningen 149
6.5 Saks- og dokumenthistorikk 153
7.1 Overordnet e-postfunksjonalitet 160
7.2 Ekspedering av e-post som saksdokument 163
7.3 Ekspedering av saksdokument per e-post 163
7.3.1 Ekspederingskontroll 165
7.3.2 Formatering av saksdokumenter sendt per e-post 166
7.4 Registrering av saksdokumenter mottatt per e-post 166
7.5 Send kopi av saksdokumenter per e-post 168
7.6 Sikkerhetshåndtering av e-post 168
7.6.1 Sikkerhetshåndtering av inn- og utgående e-post 169
7.6.1.1 Tidsstempling av e-post 170
7.6.1.2 Ikke-benekting ved bruk av e-post 170
7.6.2 Krav til konfidensialitet 171
7.6.3 Kryptering av e-post 171
7.6.4 Integritetssikring ved elektronisk signering 172
8 Møte- og utvalgsløsninger 174
8.1 Funksjonell beskrivelse 174
8.1.1 Begreper i møtebehandlingen 174
8.1.2 Informasjonselementer i møtebehandlingen 177
8.4 Utvidet møtebehandling 178
8.4.1 Administrere beslutningsorgan 179
8.4.5 Administrasjon av møtebehandlingen 182
9.1 Anbefalte statistikker 185
9.1.1 Behandlings- og restansestatistikk for journalposter 185
9.1.2 Restansestatistikk for saksmapper 187
9.1.3 Saksbehandlingstid for journalposter 188
9.1.4 Saksbehandlingstid for saksmapper 189
9.1.5 Antall journalførte journalposter over tid 190
9.1.6 Antall opprettede saksmapper over tid 191
9.1.7 Behandling av innsynsbegjæringer 191
9.3 Endringer i forhold til Noark-4 192
10 Brukeradministrasjonsløsninger 193
10.1 Administrativ oppbygging 193
10.2.2 Roller og tilknyttede rettigheter 196
10.2.3 Krav til brukers relasjon til rolle, administrativ enhet, journalenhet og arkivdel 199
11 Sikkerhets- og tilgangsløsninger 201
11.1 Formål og hovedprinsipper 201
11.1.1 Sikkerhetsfunksjoner versus sikkerhetsmål 201
11.1.2 Terminologi: Sikkerhetsfunksjoner og -egenskaper 202
11.2 Kontroll med tilgang til informasjon 202
11.2.1 Identifiserte brukere av løsningen 202
11.2.3 Tildeling og administrasjon av tilganger 210
11.3 Sikring av innsyn og tilgjengelighet 211
11.4 Sikring av elektronisk avsendte og mottatte dokumenter 212
12 Logg- og sporingsløsninger 214
12.1 Prinsipper for logging 214
12.1.1 Sporingsinformasjon i eksterne logger 214
12.1.2 Sporingsinformasjon som metadata eller som eget dokument i arkivet 215
12.1.4 Særskilte styrkekrav, uforanderlighet 215
12.2 Overordnede krav til sporingsinformasjon 216
12.3 Revisjon og etterprøving av tilgangskontrollen 217
12.4 Krav til sporingsinformasjon for ulike typer hendelser 219
Noark er en forkortelse for Norsk arkivstandard. Noark ble utarbeidet som en kravspesifikasjon for elektroniske journalsystemer i statsforvaltningen i 1984, og den etablerte seg raskt som de facto standard. Standarden ble videreutviklet med nye rapporter i 1987 (Noark-2) og 1994 (Noark-3). Videreutviklingen omfattet dels modernisering i tråd med den teknologiske utviklingen, dels utvidelser i systemenes informasjonsinnhold og funksjonalitet.
I 1995 ble det utarbeidet en tilsvarende kravspesifikasjon for kommunal sektor, Koark. Koark bygde på samme prinsipper som Noark, men hadde en del tillegg spesielt tilpasset kommunens behov, som f. eks. politisk saksbehandling.
Noark-4, som kom i 1999, inkluderte spesifikasjonene i Koark og ble en felles standard for offentlig forvaltning. Noark-4 førte standarden et langt skritt videre ved å spesifisere et fullstendig elektronisk arkivsystem, integrert med e-post og generelle saksbehandlingssystemer. Noark 5 viderefører prinsippene fra Noark-4.
Da arkivforskriften trådte i kraft 1. januar 1999, ble det obligatorisk for offentlig forvaltning å benytte et Noark-basert system, som Riksarkivaren har godkjent, for elektronisk journalføring. Fra og med 1. oktober 2002 er det bestemt gjennom Riksarkivarens forskrift, kapittel IX Elektronisk arkivering av saksdokumenter, at journalføring av elektroniske saksdokumenter som hovedregel skal skje i et system som følger kravene i Noark-standarden og er godkjent av Riksarkivaren. Dette gjelder enten man benytter et rent journal- og arkivsystem, eller om funksjoner for journalføring er integrert i et saksbehandlingssystem eller lignende. Ved elektronisk arkivering av saksdokumenter skal systemet tilfredsstille kravene til elektronisk arkivering i Noark-standarden, og være godkjent av Riksarkivaren for dette formålet.
Etter at Noark-4 kom i 1999, har det skjedd relativt store endringer på flere fronter; organisatorisk, arbeids- og samhandlingsmessig og teknologisk.
Det er mange årsaker til at arbeidet med Noark 5 ble påbegynt, men en av de viktigste faktorene var et sterkt påtrykk både fra forvaltningen og leverandørene for å få til gode løsninger for integreringen mellom Noark-baserte system og fagsystem.
Samtidig har det siden 1999 blitt utformet nasjonale og internasjonale standarder som har relevans for elektronisk journalføring og arkivering. Disse områdene er ikke i tilstrekkelig grad dekket i Noark-4.
Riksarkivaren så det derfor som nødvendig å etablere et prosjekt for å utarbeide en standard som dekker disse områdene opp til et nivå som sikrer at alle dokumenter og transaksjoner blir håndtert i tråd med arkivloven. Prosjektet ble etablert i september 2005.
Prosjektet har bestått av en styringsgruppe, en prosjektgruppe og flere referansergrupper.
Prosjektleder har vært Anne Mette Dørum, Riksarkivet
Styringsgruppen har bestått av:
Ivar Fonnes, Riksarkivet (leder)
Trond Sirevåg, Riksarkivet
Ingvar Engen, Kultur- og kirkedepartementet
Katarina de Brisis, Moderniseringsdepartementet (september 2005–september 2006)
Henrik Linnestad, Fornyings- og administrasjonsdepartementet (september 2006–mars 2007)
Christer Gundersen, Kommunenes sentralforbund (september 2005–september 2006) og Fornyings- og administrasjonsdepartementet (mars 2007–mai 2007)
Kristian Bergem, Fornyings- og administrasjonsdepartementet (fra mai 2007)
Line Richardsen, Kommunenes sentralforbund (fra september 2006)
Anne Mette Dørum (prosjektleder og sekretær i styringsgruppen)
Prosjektgruppen har bestått av:
Herbjørn Andresen, Avdeling for forvaltningsinformatikk, Universitetet i Oslo (fra november 2006),
Martin Bould, Riksarkivet (til november 2006)
Tor Anton Gaarder (fra januar 2007)
Jon Atle Haugen, Riksarkivet
Synnøve Hellevik, Riksarkivet (til februar 2008)
Øivind Kruse (fra januar 2007)
Anthony Lærdahl, Riksarkivet (til juni 2007)
Birgitte Olafsen, Riksarkivet (til desember 2006)
Petter Svendsen, Riksarkivet
Arbeidsgruppen som har arbeidet med kapitlet om møtebehandling har bestått av:
Kari Remseth, Interkommunalt arkiv Trøndelag (gruppens leder)
Elin Harder, Direktoratet for naturforvaltning.
Jan Tore Helle, Interkommunalt arkiv Hordaland.
Rolf Petter Waage, Interkommunalt arkiv Møre og Romsdal.
Astrid Øksenvåg, Kommunenes Sentralforbund.
Ståle Prestøy, Interkommunalt arkiv Trøndelag (gruppens sekretær)
Referansegruppen har bestått av mange aktører fra privat og offentlig sektor.
Konkrete problemstillinger knyttet til personvernspørsmål har vært diskutert med Datatilsynet ved behov. Tilsvarende har konkrete problemstillinger knyttet til sikkerhetsspørsmål vært diskutert med Nasjonal sikkerhetsmyndighet ved behov. Norsk presseforbund har også vært kontaktet ved behov.
En særlig takk rettes til innleid konsulent Paul Hoseth, Mesan AS som med stor tålmodighet og uvurderlig kompetanse har hjulpet prosjektet til å realisere visjonen om en Noark 5-kjerne.
Takkes skal også Heidi Einarsen, Riksarkivet, for en betydelig skriveinnsats i sluttspurten.
Noark-5 stiller krav til arkivstruktur, metadata og funksjonalitet, men ikke krav til hvordan dette faktisk skal løses i systemutviklingen. Noark-5 definerer derfor ikke et system, men legger til rette for ulike løsninger.
For deponering, avlevering og migrering er kravene sterkere. Obligatoriske metadata skal inngå i uttrekket, og utrekket skal ha en definert struktur.
Beskrivelse av rutiner eller hvordan forskjellige krav kan oppfylles, inngår ikke i standarden. Der det er nødvendig for forståelsen av kravene, er det likevel tatt inn en del innledende tekst foran kravtabellene. Alle gjeldende krav framgår av kravtabellene. Kravtabellene er satt opp på denne måten:
|
Krav nr. |
<hva det stilles krav til> |
Type |
Merknad |
|---|
Krav.nr.: Kravnummereringen er
inndelt i <kapittelnr> . <løpenummer innen kapittel>
(4.11 betyr f. eks. kapittel 4, krav nr 11).
<hva det stilles krav til>: Dette angir området det stilles krav til i tabellen
Type: Angir type krav. Her brukes:
O (Obligatorisk),
A (Anbefalt),
BO (Betinget obligatorisk hvis man ønsker å tilfredsstille et anbefalt krav) og
BA (Betinget anbefalt hvis man ønsker å tilfredsstille et anbefalt krav)
Merknad: Angir eventuelle merknader til kravet
Prosjektet har hele tiden holdt løpende kontakt med miljøer som arbeider med nasjonalt standardiseringsarbeid, så som Standardiseringsrådet, Semantikkregisteret for elektronisk samhandling (SERES), Koordineringsorganet for eForvaltning (KoeF) og arbeidene med åpne standarder samt elektronisk signatur og identifikasjon.
Flere norske arbeider er hensyntatt ved utforming av krav. Disse er bl.a.:
Kravspesifikasjon for PKI i offentlig sektor
ELMER 2 – Retningslinjer for brukergrensesnitt i offentlige skjemaer på Internett
Forslag til strategi for bruk av eID og e-signatur i offentlig sektor
St.meld. nr 17 (2006-2007) Eit informasjonssamfunn for alle
Felles IKT-arkitektur i offentlig sektor
Prosjektet har hatt interessante og givende utvekslinger av synspunkter og erfaringer med FESD-prosjektet (Fælles systemer til elektronisk sags- og dokumenthåndtering i den offentlige sektor) i Danmark. FESD-prosjektet har etablert en felles teknisk standard for arkiv- og saksbehandlingsystem, basert på Noark-4.
I Sverige har prosjektet Långsiktigt Digitalt Bevarande (LDB) være en viktig kilde til innspill ved utforming av Noark 5-kravene til avlevering.
Fra Finland har prosjektet hentet erfaringer fra Sähke-prosjektet, som er et prosjekt som bl.a. arbeider med langtidsbevaring av elektroniske dokumenter.
I arbeidet med Noark 5 er det tatt utgangspunkt i internasjonale standarder som er relevante. Dette er bl.a.:
ISO 15489-1
og 2: 2001 Information and documentation - Records management (Part
1: General, Part 2: Guidelines). Dette er en internasjonal
standard for arkivdanning.
MoReq - Model
Requirements for the management of electronic records
(EU-kommisjonen 2002). Dette er en EU-standard for
arkivdanning basert på ISO 15489. I februar 2008 kom MoReq2.
ISO 23081-1:
2004 Information and documentation - Records management processes -
Metadata for Records. Dette er en internasjonal standard for
internasjonal standard for metadata for arkivdokumenter.
ISO 14721:
2002 Reference Model for an Open Archival Information System (OAIS).
Dette er en ISO-standard for bevaring av arkiv.
Data
Dictionary for Preservation Metadata: Final Report of the PREMIS
Working Group (OCLC og RLG 2005). PREMIS står for
Preservation Metadata: Implementation Strategies. PREMIS Working
Group beskriver en modell - en kjerne av metadata – som kan
brukes til all digital bevaring, uavhengig av type dokumenter eller
bevaringsstrategier.
De internasjonale standardene for arkivdanning og arkivdepot er direkte knyttet til Noark 5 i den forstand at der kravene i standardene har hatt sterk relevans for norske forhold, har vi brukt kravene tilnærmet direkte oversatt. Der relevansen har vært svakere, har vi sørget for at kravformuleringene i Noark 5 har tatt hensyn til kravene så langt det har vært mulig, gitt spesielle hensyn knyttet til norsk forvaltningspraksis og rett.
Prosjektleder har i løpet av prosjektperioden deltatt i arbeidet med utviklingen av Moreq2, som deltaker i Editorial Board. For å sikre at Noark 5 er i tråd med MoReq2, har prosjektet i hovedsak forholdt seg til MoReq2 sine kravsett, etter hvert som de har blitt ferdige.
Flere av prosjektdeltakerne har deltatt i et internasjonalt utdanningsopplegg, som er en oppfølging av rapporten fra PREMIS Working Group.
Et journal- og arkivsystem må
være i tråd med de krav som stilles i lov og regelverk. I
dette kapitlet behandles de generelle lovkrav som et Noark 5-basert
system skal kunne etterleve. Med den generelle lovgivning forstås
her spesielt forvaltnings-, offentlighets-, arkiv-, og
personvernlovgivningen, men annen spesiell lovgivning kan også
komme til anvendelse.
Noark 5 skal understøtte at den
enkelte organisasjon smidig og effektivt kan ivareta den generelle
lovgivningen, men det er også viktig at organisasjonen er
oppmerksom på annen spesiell lovgivning som kan ha betydning
for arkivet. Annet regelverk kan berøre arkivmessige forhold,
og disse vil i visse sammenhenger ha konsekvenser for arkivarbeidet i
den offentlige forvaltning.
De mest sentrale juridiske rammebetingelsene for Noark 5-standarden finnes i følgende lov- og regelverk:
Lov av 4. desember 1992 nr. 126 om arkiv (arkivloven).
Forskrift av 11.desember 1998 nr 1193 om offentlige arkiver (arkivforskriften).
Forskrift av 1. desember 1999 nr. 1566 om utfyllende tekniske og arkivfaglige bestemmelser om behandling av offentlige arkiver (Riksarkivarens bestemmelser for offentlige arkiver)
Lov av 10. februar 1967 om behandlingsmåten i forvaltningssaker (forvaltningsloven)
Forskrift av 25. juni 2004 nr. 988 om elektronisk kommunikasjon med og i forvaltningen (eForvaltningsforskriften).
Lov av 19. mai 2006 nr. 16 om rett til innsyn i dokument i offentleg verksemd (offentleglova), som erstatter Lov av 19. september 1970 nr. 69 om offentlighet i forvaltningen (offentlighetsloven).
Lov av 14. april 2000 nr. 31 om behandling av personopplyninger (personopplysningsloven).
Forskrift av 15. desember 2000 nr. 1265 om behandling av personopplysninger (personopplysningsforskriften).
Lov av 15. juni 2001 nr. 81 om elektronisk signatur (esignaturloven).
Lov av 20. mars 1998 nr. 10 om forebyggende sikkerhetstjeneste (sikkerhetsloven).
Instruks av 17. mars 1972 nr. 3352 for behandling av dokumenter som trenger beskyttelse av andre grunner enn nevnt i sikkerhetsloven med forskrifter (beskyttelsesinstruksen)
Et arkivsystem er et redskap for å ivareta arkivfunksjonen til en virksomhet. For Noark dreier det seg i særlig grad om arkivfunksjonen i den offentlige forvaltning, og spesifikasjonene må derfor være tilpasset de rammer og krav som gjelder for denne.
Arkivfunksjonen i offentlig forvaltning består i å holde oversikt over dokumenter til
behandling (saksdokumenter), plassere dokumentene i deres behandlingsmessige
sammenheng (saker), fordele
dokumenter til behandlingsleddet, drive oppfølging overfor
behandlingsleddet, arkivere dokumenter som er behandlet, besvare
interne og eksterne forespørsler om behandlingsstatus og om
innhold i dokumenter, søke/hente fram dokumenter på
forespørsel, låne ut dokumenter eller distribuere kopier
etc. Videre skal det arkiverte materialet etter en del år
settes bort og senere avleveres til et arkivdepot som dokumentasjon
av den virksomhet hvor det i sin tid oppstod.
Journal- og arkivfunksjonaliteten skal være arbeidsredskap for alle deler av arkivfunksjonen. For organet som helhet vil ofte journal- og arkivfunksjonaliteten være integrert i et omkringliggende saksbehandlingssystem eller fagsystem. Journal- og arkivfunksjonaliteten skal dels benyttes til å registrere og arkivere dokumenter og annen informasjon, dels til å søke og hente fram denne informasjonen og distribuere den. Løsningen må naturligvis utformes slik at det best mulig dekker de oppgaver som inngår både i arkivfunksjonen og i organets samlede dokumenthåndtering. Samtidig må det tas hensyn til en del grunnleggende rammer som er gitt gjennom lov- og regelverk, herunder definisjonen av hva slags dokumenter arkivet skal omfatte. Og systemet må legge forholdene til rette for en tilfredsstillende kvalitetssikring i arkivfunksjonen.
Regelverket bidrar til å sikre
dokumentasjon av forvaltningens disposisjoner og vedtak, dels for
forvaltningsmessige og rettslige formål, dels for ettertidens
kunnskap og forskningsformål. Sentrale bestemmelser gjelder
plikten til å holde arkiv, organisering av arkivfunksjonen, hva
slags materiale som hører hjemme i arkivet, hva som skal
bevares for ettertiden og hvordan det skal oppbevares. Men det er
også gitt forholdsvis detaljerte bestemmelser om arkivrutiner,
bl.a. knyttet til dokumentbehandling, journalføring, utlån,
bortsetting av eldre materiale og avlevering til arkivdepot.
Det
er imidlertid ikke bare arkivregelverket og arkivloven som berører
arkivfunksjonene. Flere andre lover og bestemmelser må også
tas i betraktning. Det gjelder i særlig grad offentlighetsloven
som har betydning for journalføring, framlegging av
offentlig journal og skjerming av informasjon. Forvaltningsloven
gir generelle regler om saksbehandling, samt spesialiserte
bestemmelser om taushetsplikt og partsoffentlighet. Det er viktig å
være oppmerksom på eForvaltningsforskriften, som
er hjemlet i esignaturloven og forvaltningsloven. Denne forskriften
gir mer spesifikke regler om elektronisk kommunikasjon med og i
forvaltningen. Personopplysningsloven og forskriften til denne
(personopplysningsforskriften) regulerer behandling av
personopplysninger.
Det er også nødvendig å
ta i betraktning de skrevne og uskrevne regler som man legger i
begrepet god forvaltningsskikk. Dette omfatter stikkord som
likebehandling (presedens), fullstendig beslutningsgrunnlag, at
henvendelser til forvaltningen krever svar innen rimelig tid (jf.
restansekontroll) osv.
Av spesiell lovgivning kan nevnes
sikkerhetsloven og beskyttelsesinstruksen som gir
bestemmelser om informasjon som må beskyttes av hensyn til
rikets sikkerhet eller av andre grunner. En annen lov er
esignaturloven som sikrer bruk av kvalifisert elektronisk
signatur ved elektronisk kommunikasjon i forvaltningen.
Noark 5 skal støtte opp
under arkivfunksjoner som ligger innenfor regelverkets rammer, og den
skal unnlate å bygge inn funksjonalitet som ikke er tillatt.
Innenfor de ulike områdene er det i det følgende angitt
en rekke eksempler på krav som standarden skal oppfylle. Det
understrekes at disse eksemplene ikke uttømmende beskriver
lovkravene på de enkelte lovgivningsområde, men er ment
som illustrerende eksempler.
Forvaltningens arkivfunksjon har i
lang tid vært regulert gjennom et eget regelverk. Lov av 4.
desember 1992 nr. 126 om arkiv (arkivloven) trådte i kraft
1.januar 1999. Samtidig trådte forskrift av 11. desember 1998
nr. 1193 om offentlige arkiver (arkivforskriften) i kraft. Forskrift
av 1.desember 1999 nr 1566 om utfyllende tekniske og arkivfaglige
bestemmelser om behandling av offentlige arkiver (behandling av
offentlige arkiver) kom som et resultat av behovet for ytterligere
regulering blant annet for å regulere elektronisk arkivering av
arkivmateriale. Sammen utgjør arkivloven, arkivforskriften og
forskrift om behandling av offentlige arkiver kjernen i det
regelverket som regulerer håndtering av offentlige arkiver.
Arkivloven gir en
del overordnede og grunnleggende bestemmelser om arkiv og spesielt om
arkiv i offentlig forvaltning. Bestemmelsene gjelder, med få
unntak jf. arkivloven § 5, for all virksomhet som utøves
av den offentlige forvaltning.
Formålet med arkivloven
er å sikre arkiv som har betydelig kulturell eller
forskningsmessig verdi, eller som inneholder rettslige eller viktig
forvaltningsmessig informasjon, slik at disse kan bli tatt vare på
og gjort tilgjengelige for ettertiden, jf. arkivloven § 1.
Videre fastsetter arkivloven i § 6 at offentlige organ plikter å
ha arkiv, og at disse skal ordnes og innrettes slik at dokumentene er
sikret som informasjonskilder for samtid og ettertid.
Sammen med de utfyllende forskriftene representerer loven et helhetlig legalt rammeverk rundt alle arkivrelaterte spørsmål i offentlig forvaltning, helt fra dokumentet oppstår som ledd i den daglige virksomheten, via arkivbegrensning og avlevering av bevaringsverdig arkivmateriale til arkivdepot, og under oppbevaring og tilgjengeliggjøring for ettertiden.
For å sikre autentisk dokumentasjon er det viktig å etablere løsninger for en best mulig dokumentfangst, dvs. at dokumentene som skal arkiveres blir identifisert, ”fanget” og arkivert. I dette ligger at dokumentene blir tilknyttet metadata (registrert) og arkivert på en måte som sikrer at de kan finnes igjen i en uforandret form. Dokumentfangsten kan være alt fra manuell behandling av papirdokumenter til en helt automatisert prosess for elektroniske dokumenter.
Uansett er det dokumentfangsten som fører til arkiv, og det skal i utgangspunktet ikke være begrensninger i denne fangsten. Både ved etablering av selvbetjeningsløsninger for næringsliv og publikum og løsninger for saksbehandling og samhandling i eller mellom organ, vil det gi en stor effektiviseringsgevinst å bygge inn en automatisert dokumentfangst, dvs. funksjoner for å fange opp og fryse dokumenter. Ved å sikre god dokumentfangst, ivaretas både virksomhetens behov for å etablere løsninger for god kunnskapsforvaltning og beslutningsstøtte, parters rettssikkerhet, offentlighet i forvaltningen og framtidige kulturelle og forskningsmessige behov.
Arkivloven med forskrifter innebærer at det enkelte organ i utgangspunktet har en uttrykkelig arkiveringsplikt, det vil si plikt til å arkivere alle dokumenter som blir til som et ledd i den virksomheten organet driver, enten det er dokument som kommer inn til organet, eller et dokument som organet selv produserer. Dette følger av § 6 i arkivloven. Dokumentdefinisjonen i arkivloven er teknologinøytral og svært vid; et dokument defineres som en logisk avgrenset informasjonsmengde som er lagret på et medium for senere lesing, lytting, fremsyning eller overføring.
Unntatt fra arkiveringsplikten er de dokumentene som kommer inn under bestemmelsene om arkivbegrensning etter §§ 3-18 og 3-19 i arkivforskriften. Med arkivbegrensing menes at dokument som blir til som ledd i den virksomheten organet driver, men som verken er gjenstand for saksbehandling eller har verdi som dokumentasjon, blir holdt utenfor eller fjernet fra arkivet. Det enkelte organet skal gjennomføre arkivbegrensning løpende.
Arkivforskriften § 3-19 inneholder fem grupper av materiale som er omfattet av arkivbegrensingen, dvs. at det enten ikke skal arkiveres i det hele tatt, eller at det i etterkant skal fjernes fra arkivet dersom det først er arkivert. Legg likevel merke til at det i de fire første av disse gruppene er viktige unntak.
Gjennom arkivforskriften er det også
innført en journalføringsplikt for alle
offentlige organ. Plikten til å journalføre dokumenter
er innsnevret i forhold til plikten til å arkivere dokumenter.
Hvilke dokumenter som er omfattet av denne journalføringsplikten,
er fastsatt i arkivforskriften § 2-6 første ledd:
For det første er det et krav at dokumentet må regnes som et saksdokument for organet, slik det er definert i offentlighetslovgivningen. Et saksdokument for organet er dokument som er kommet inn til eller lagt frem for et organ, eller som organet selv har opprettet, og som gjelder ansvarsområdet eller virksomheten til organet. Et dokument er opprettet når det er sendt ut av organet. Hvis dette ikke skjer, regnes dokumentet som opprettet når det er ferdigstilt.
For det andre må dokument inngå i en korrespondanse, dvs. at det har kommer inn til eller blitt sendt ut fra organet.
For det tredje må dokumentet ha et substansielt innhold, dvs det må både være gjenstand for saksbehandling og ha verdi som dokumentasjon.
Når alle disse tre kriteriene er oppfylt, er det altså plikt til å journalføre dokumentet. Dokument som kommer inn under reglene om arkivbegrensing, skal derimot ikke journalføres. Utover dette er det i hovedsak opp til organets eget skjønn hva som eventuelt blir journalført.
Det er med andre ord dokumenter som har kommet inn til eller blitt sendt ut fra organet, som organet har plikt til å journalføre. Organinterne dokumenter journalføres hvis og når organet finner det tjenlig.
Med kassasjon menes at arkivmateriale som har vært gjenstand for saksbehandling eller hatt verdi som dokumentasjon, blir tatt ut av arkivet og slettet eller destruert.
I arkivloven § 9 bokstav c er det gitt bestemmelser om at arkivmateriale ikke kan kasseres med mindre det skjer med hjemmel i forskrifter eller etter særskilt samtykke fra Riksarkivaren. Kassasjonsforbudet i arkivloven går foran bestemmelser om kassasjon i eller i medhold av andre lover. Datatilsynet kan likevel treffe vedtak om sletting av personopplysninger med hjemmel i personopplysningsloven § 28. Men slik sletting kan først gjøres etter at det er innhentet uttalelse fra Riksarkivaren.
Materiale som kommer inn under bestemmelser om bevaring, kan ikke kasseres uten etter Riksarkivarens samtykke. Med bevaring menes at arkivmateriale blir oppbevart for framtida og avlevert til arkivdepot. I arkivforskriften § 3-20 er det satt opp spesifiserte bevaringspåbud
Kassasjon er en uopprettelig handling. Det må derfor ikke gjennomføres noen form for sletting eller annen kassasjon uten etter særlig grundig saksforberedelse, slik at en er helt sikker på at en ikke uforvarende kasserer materiale som skulle ha vært bevart.
Det understrekes at kassasjon ikke må forveksles med arkivbegrensning.
Den nye offentlighetsloven vil ha et utvidet virkeområde i forhold til offentlighetsloven av 1970. Dette betyr at det er flere typer virksomheter som skal følge den nye offentlighetsloven.
Formålet med loven er å legge til rette for at offentlige verksomheter er åpne og gjennomsiktig, for slik å styrke informasjons- og ytringsfriheten, den demokratiske deltakingen, rettssikkerheten for den enkelte, tilliten til det offentlige og kontrollen fra allmenheten. Loven skal også legge til rette for viderebruk av offentlig informasjon.
Lovens hovedregel er at saksdokument, journaler og lignende register for organet er åpne for innsyn hvis ikke annet følger av lov eller forskrift med hjemmel i lov. Alle kan kreve innsyn i saksdokument, journaler og lignende register til saksdokument, hos vedkommende organ.
Enhver kan også kreve innsyn i en sammenstilling av opplysninger som er elektronisk lagret i databasene til organet hvis sammenstillingen kan gjøres med enkle fremgangsmåter.
Organ som kommer inn under lovens virkeområde, har plikt til å føre journal etter reglene i arkivloven med forskrifter. Organ som fører elektronisk journal, skal gjøre journalen allment tilgjengelig på Internett på den måten som er fastsatt i forskriften til offentlighetsloven.
Dokumenter kan gjøres allment tilgjengelig på Internett, med unntak for opplysninger som er underlagt taushetsplikt i lov eller i medhold av lov.
Lov av 10.februar 1967 om behandlingsmåten i forvaltningssaker (forvaltningsloven) regulerer visse typer arkivmateriale gjennom bestemmelser om hvilke regler som gjelder for saksbehandling, og om hvilke rettigheter forvaltningsloven gir den enkelte.
Formålet med loven er å
regulere de rettigheter borgerne har når de er i kontakt med
offentlige instanser. Forvaltningsloven skal ivareta rettssikkerheten
til borgerne og sikre en betryggende saksbehandling. Loven er en
overordnet lov som tas i bruk i all saksbehandling, så lenge
ikke annen lov gjelder etter særlovgivning.
De fleste unntak etter offentlighetsloven på grunnlag av lovbestemt taushetsplikt har
hjemmel i forvaltningsloven §§ 13 til 13f. Partsinnsyn etter forvaltningsloven er regulert i §
18, som er hovedregelen om en persons rett til innsyn i dokumenter som gjelder en selv. I
tillegg har en rekke særlover lignende bestemmelser om rett til innsyn i egen sak.
Forskrift om elektronisk kommunikasjon med og i forvaltningen trådte i kraft 1.
juli 2002. Forskriften er blitt
revidert og forskrift om elektronisk kommunikasjon med og i
forvaltningen ble vedtatt den 1. juli.2004.
Formålet med
forskriften har vært å utarbeide et felles regelverk som
legger rammene for sikker og effektiv bruk av elektronsk
kommunikasjon med og i forvaltningen. Forskriften skal fremme
forutsigbarhet og fleksibilitet, samt legge til rette for samordning
av sikre og hensiktsmessige tekniske løsninger, herunder
e-signatur.
eForvaltningsforskriften inneholder bestemmelser som gir føringer for rutiner og prosedyrer knyttet til arkivdanningen. Kapittel 2 inneholder bl.a. bestemmelser om at enhver som henvender seg til et forvaltningsorgan i prinsippet kan benytte elektronisk kommunikasjon, at forvaltningsorganet skal gi bekreftelse på at henvendelsen er mottatt og hvordan krav om innsyns skal behandles. Kapitlet sier også noe om hvordan taushetsbelagte opplysninger og personopplysninger skal formidles og hvordan parter skal varsles om enkeltvedtak som er fattet. Kapittel 6 gir bestemmelser for forvaltningsorganets behandling av meldinger som er kryptert eller signert med elektronisk signatur. Særlig viktig her er § 26 som gir bestemmelser om arkivering av avansert elektronisk signatur mv.
Lov av 14. april 2000 nr. 31 om behandling av personopplyninger (personopplysningsloven) trådte i kraft 1. januar 2001. Loven erstatter personregisterloven fra 1978.
Loven omfatter behandling av personopplysninger med elektroniske hjelpemidler, og manuell behandling av personopplysninger som innebærer opprettelse av et personregister.
Formålet med loven er å beskytte den enkelte mot at personvernet blir krenket gjennom behandling av personopplysninger. Loven skal bidra til at personopplysninger blir behandlet i samsvar med grunnleggende personvernhensyn, herunder behovet for personlig integritet, privatlivets fred og tilstrekkelig kvalitet på personopplysninger.
Personopplysningsloven fokuserer på ”behandling av personopplysninger”. Begrepet angir dermed lovens saklige virkeområde. Loven gjelder ikke behandling av personopplysninger som den enkelte foretar for rent personlige eller andre private formål.
Behandling av personopplysninger innebærer enhver bruk av personopplysninger: innsamling, registrering, sammenstilling, lagring og utlevering eller en kombinasjon av disse.
Lov av 15. juni 2001 nr. 81 om elektronisk signatur (esignaturloven) trådte i kraft 1. juli 2001. Loven har til formål å legge til rette for at tilbydere av sertifikattjenester og produkter på det norske markedet oppfyller et bestemt høyere sikkerhetsnivå. Kravene til sikkerhet skal balanseres mellom forretningsmessige hensyn, forbrukerhensyn og samfunnsmessige hensyn.
En elektronisk signatur kan brukes som sikkerhet for at elektronisk overført informasjon ikke har blitt endret underveis, bekreftelse på hvem som sendte informasjonen og som sikkerhet for at avsender ikke skal kunne benekte at han sendte den. Disse funksjonene benevnes som sikring av integritet, autentisitet og ikke-benekting.
Elektronisk ID og elektronisk signatur er nødvendige forutsetninger for økt bruk av elektroniske tjenester som krever at kommunikasjonsparter identifiserer seg, binder seg til kommunikasjonens innhold på en måte som kan spores, eller som trenger konfidensialitetsbeskyttelse
Bruk av standardisert elektronisk signatur åpner for å digitalisere en mengde offentlige tjenester. Brukerne kan gjenbruke én og samme ID mot mange tjenester. Dette gir forenkling og økt effektivitet for den enkelte i samhandling med det offentlige.
Loven gir ikke en generell rett til å kommunisere elektronisk. Stilles det krav om underskrift vil alltid bruk av kvalifisert elektronisk signatur oppfylle et slikt krav, så fremt det er mulig å foreta handlingen elektronisk. Dette betyr at en slik elektronisk signatur gis samme rettsvirkning som en håndskreven signatur. Loven gir imidlertid adgang til å stille tilleggskrav ved kommunikasjon med og i forvaltningen.
Loven er en gjennomføring av EU-direktivet om en fellesskapsramme for elektroniske signaturer, og Noark 5 legger til rette for bruk av elektroniske signaturer.
Lov av 20. mars 1998 nr. 10 om
forebyggende sikkerhetstjeneste (sikkerhetsloven) trådte
i kraft 1. juli 2001. Loven erstatter sikkerhetsinstruksen og har et
eget kapittel om informasjonssikkerhet.
Formålet med
loven er ved forebyggende tiltak å trygge rikets sikkerhet og
vitale nasjonale sikkerhetsinteresser mot spionasje, sabotasje og
terrorhandlinger, og gjelder for hele forvaltningen. Loven skal
dessuten ivareta den enkeltes rettssikkerhet og trygge tilliten til
og forenkle kontrollen med tjenesten. Tiltakene skal implementeres i
stat, kommune og private virksomheter som loven gjelder for.
Det er utarbeidet forskrifter innen informasjonssikkerhet, personellsikkerhet, industrisikkerhet og sikkerhetsadministrasjon. For arkivmessig behandling av dokumenter gradert etter sikkerhetsloven, er det særlig forskrift om informasjonssikkerhet som er aktuell.
Instruks av 17. mars 1972 nr. 3352 for behandling av dokumenter som trenger beskyttelse av andre grunner enn nevnt i sikkerhetsloven med forskrifter (beskyttelsesinstruksen). Instruksen omfatter dokumenter uavhengig av mediet de er tilgjengelig på.
Beskyttelse av et dokument etter beskyttelsesinstruksen skal bare foretas når dokumentet kan unntas fra offentlighet i medhold av offentlighetsloven og skadevirkninger kan inntreffe.
Noark 5 skal kunne brukes for alle typer arkivdanning, uavhengig av teknologisk løsning og type organ. Alle aktiviteter som skaper dokumenter som det er viktig å sørge for at oppbevares og gjenfinnes i autentisk form, skal i prinsippet inngå i en løsning for arkivdanning. Dette er helt uavhengig av om dokumentene inngår i tradisjonell saksbehandling, hvor mange år de skal oppbevares eller om de skal avleveres til depotarkiv.
Derfor er Noark 5 skrevet med tanke på både offentlig og privat sektor, og organisasjoner som planlegger å anskaffe nytt system eller ønsker å vurdere det systemet de allerede
har innført. Selv om Noark-standarden er lovpålagt bare i offentlig sektor, bør standarden kunne brukes ved anskaffelser av løsninger for håndtering av arkivdokumenter også innenfor privat sektor.
Standarden er laget ut fra et helhetsperspektiv, med utgangspunkt i arkivets funksjon slik det framstår i en elektronisk omgivelse. Hovedfokus har hele tiden vært å etablere et kravsett som kan sikre at de løsningene som utvikles, fører til en forsvarlig håndtering av elektronisk arkiv.
Det er mange typer saksbehandling som tradisjonelt ikke har vært ført i journal, og innenfor arkivfaglig terminologi har dette vært kalt massesaksbehandling. Dette kan for eksempel være søknad om kommunal barnehageplass, søknad om utsettelse av periodisk kjøretøykontroll og innrapportering av ulike skjemabaserte opplysninger. Ettersom denne typen saker ofte utgjøres av store dokumentvolum, har man av ressursmessige årsaker valgt å ikke føre saksdokumentene i en journal, selv om de i hovedsak kommer inne under journalføringsplikten. Gjennom bruk av løsninger basert på kjernekravene i Noark 5, integrasjon med saksbehandlings- og skjemahåndteringssystem og automatisert journalføring, arkivering og fordeling av dokumenter, vil det være mulig å få kontroll over dokumenter i slike saker også. En forutsetning er at arkivfaglige krav og premisser må inn når system, prosesser og rutiner planlegges og spesifiseres.
Noark 5 er en teknologiuavhengig standard. Konkrete krav til teknologier, så som godkjente arkivformat for elektroniske dokumenter, er tatt ut av standarden og plassert i forskriftene til arkivloven. Kravsettene er teknologinøytrale, og de er ikke basert på eller utformet med tanke på bestemte teknologiske løsninger.
Et arkivdokument består av elementene innhold, struktur, kontekst og presentasjon. Innholdet finnes i ett eller flere elektroniske eller fysiske dokumenter som gjengir arkivdokumentets ”budskap”. Dokumentene skal oppbevares på en måte som gjør at framtidige brukere kan forstå både budskapet og sammenhengen (konteksten) budskapet inngår i. Dette impliserer at arkivdokumentet, i tillegg til sitt innhold, har informasjon (metadata) om innhold, kontekst og struktur.
Presentasjonen er avhengig av en kombinasjon av arkivdokumentets innhold, struktur og (for elektroniske arkivdokumenter) programvaren som arkivdokumentet er lagret i. Innholdet i et arkivdokument skal være uforanderlig og skjermet mot innsyn fra uautoriserte personer. Med uforanderlig menes at det skal være sikret mot endring og sletting (uhjemlet kassasjon). Arkivdokumentet med tilhørende metadata skal altså ”fryses” slik at det ikke kan endres. Det er viktig å knytte integritetssikring til arkivdokumenter, det vil si at eventuelle endringer kan oppdages. Kravet til lesbarhet (presentasjon) medfører at utseende og innhold skal kunne gjenskapes over tid.
Arkivdanning er kjernen i alle disipliner som betrakter saksdokumenter som del av virksomhetens samlede informasjonsressurser. Gjennom en systematisk og kontrollert arkivdanning, vil de arkiverte dokumentene beviselig være ekte, troverdige, gjenfinnbare og lesbare. Ved at dokumentene tilknyttes metadata og oppbevares i en uforanderlig form, er man sikret at det dokumentet man skal bruke, faktisk er identisk likt det dokumentet som opprinnelig ble utarbeidet eller mottatt.
Betraktningsmåten over gjelder ikke bare tradisjonell, korrespondansebasert saksbehandling slik den foregår for eksempel i departementene. Det er minst like viktig å dokumentere hva en virksomhet har mottatt og skapt av dokumenter også i de tilfellene det er mer eller mindre automatisert saksbehandling som foregår i spesialiserte fagsystem eller beslutnings(støtte)system.
Dokumentfangst, tilførsel av metadata og arkivering av dokumenter skal kunne gjøres i svært ulike omgivelser, fra virksomheter med til dels utstrakt automatisert saksbehandling og avansert saksbehandlingsstøtte, til virksomheter som har behov for håndtering av enkle postrutiner og arkivering av enkle filer. En av de aller enkleste formene for arkivdanning vil for eksempel være håndtering av fotografier i fotobokser ved passering av en bompengestasjon.
For å unngå å lage to sett av Noark 5; et kravsett til funksjonalitet for en arkivdanning som skal inngå i en hvilken som helst omgivelse og et kravsett til et komplett, frittstående system, spesifiserer Noark 5 tre lag eller nivå – krav til indre kjerne, krav til ytre kjerne og krav til komplett Noark 5.
Indre kjerne inneholder krav
til grunnleggende funksjonalitet for journalføring og
arkivering. Hovedfunksjonene ligger innen arkivstruktur, metadata og
krav til system som finnes i regelverk for arkiv. I tillegg ligger
det krav til de moduler som må inngå i kjernen, det vil
si datafangst, søking / fremhenting / vising, administrasjon
av kjernen, bevaring og kassasjon samt avlevering.
Kravene
til indre kjerne må være oppfylt for at systemet skal
kunne godkjennes som en
Noark 5-løsning.
Ytre kjerne definerer kjernens krav til eksterne, valgfrie moduler/systemer. For at kjernen skal fungere i et helhetlig arkivsystemmiljø, må kjernen stille noen krav til de aktuelle ”valgfrie” systemer som benyttes i miljøet. Mellom Noark 5 kjerne og omkringliggende system ligger det en ’gråsone’, som er Noark 5 sine krav til eksterne moduler / systemer.
Kravene til ytre kjerne er en del av Noark 5 kjerne, og må være oppfylt for at systemet skal kunne godkjennes som en Noark 5-løsning.
Komplett Noark 5 spesifiserer krav og anbefalinger til noen av de valgfrie fag- og administrasjonssystemer som vil inngå i en ”komplett” Noark 5-løsning, det vil si en løsning som ligger nært opp til dagens Noark-4-system. Dette er spesifikasjoner som berører noen gitte fagsystem, som inngår som del av en komplett Noark 5-løsning. Dette utgjør det ytterste laget av funksjonalitet i Noark 5. Kravene til de ytre fagsystemene er ikke en del av de obligatoriske kravene til Noark 5 kjerne.
De områdene hvor Noark 5 avviker fra Noark-4 omtales særskilt etter det enkelte kapitlet.
Noark 5 skal erstatte Noark-4 (som i sin tur erstattet Noark-3), men være bakoverkompatibel med Noark 4 i den betydningen at det skal være mulig å migrere arkiver fra systemer basert på den eldre standarden til den nye. Dette er det tatt hensyn til både når det gjelder oppbygningen av arkivstrukturen og metadataene som defineres. Et eksempel på dette er at enhetene arkiv og arkivdel fremdeles er beholdt i arkivstrukturen.
Forvaltningens saksdokumenter som lagres elektronisk, skal være knyttet til et journalføringssystem eller annet elektronisk system for registrering av dokumenter. Systemet skal styre all arkivering av og tilgang til saksdokumentene.
Journalføring av elektroniske saksdokumenter skal som hovedregel skje i et system som følger kravene i Noark og er godkjent av Riksarkivaren. Dette gjelder enten man benytter et rent journal- og arkivsystem, eller om funksjoner for journalføring er integrert i et saksbehandlingssystem eller lignende. Ved elektronisk arkivering av saksdokumenter må systemet tilfredsstille kravene til elektronisk arkivering i Noark og være godkjent av Riksarkivaren for dette formålet. Hvis systemet ikke tilfredsstiller kravene i Noark, skal forvaltningsorganet søke Riksarkivaren om dispensasjon. Dispensasjon skal være gitt før systemet kan tas i bruk.
Hvis saksdokumenter skal utveksles elektronisk i tilknytning til det elektroniske arkivet, bør systemet også tilfredsstille basiskravene til integrert e-post.
Hvis dokumenter skal signeres med elektronisk signatur, bør systemet også tilfredsstille basiskravene til integrert bruk av digital signatur i Noark.
Ved nyutvikling av system eller funksjonalitet for journalføring og arkivering skal utviklingen baseres på Noark 5, ikke på Noark-4. For fagsystem og andre system hvor det er behov for å etablere en avgrenset, rendyrket journal- og arkivfunksjonalitet, skal kjernekravene i Noark 5 være oppfylt. For de tilfeller der en Noark-4-leverandør ønsker å ”løse opp” systemet i forhold til de krav som stilles i Noark-4, skal det nye systemet / den nye versjonen av systemet som et minimum tilfredsstille kjernekravene i Noark 5.
Alle journal- og arkivsystem som brukes i forvaltningen, skal altså som en hovedregel tilfredsstille Noark-kravene og være godkjent av Riksarkivaren. Alle Noark 5-baserte løsninger skal derfor godkjennes av Riksarkivaren før de kan tas i bruk. Dette innbefatter i tillegg til ordinære hyllevareløsninger også:
Journal- og arkivfunksjonalitet i fagsystem, hvor organet selv utvikler løsningen
Journal- og arkivfunksjonalitet for fagsystem, hvor journal- og arkivfunksjonaliteten er utviklet som ”hyllevare”
Journal- og arkivfunksjonalitet som defineres som felleskomponent for et eller flere organ eller et eller flere system
Noark-4-system som ”omstøpes” til Noark 5-system, ettersom uttrekket for avleveringsformatet er vesentlig endret i Noark 5 i forhold til Noark-4
Forvaltningen vil ikke bli pålagt å gå over fra Noark-4-baserte til Noark 5-baserte system fra en bestemt dato. Riksarkivarens holdning er at forvaltningen til enhver tid må velge de innretninger for journalføring og arkivering som, innenfor arkivlovens rammer, er mest tjenlig for organet. I dette ligger at for visse forvaltnings- eller saksområder kan det fortsatt være hensiktsmessig med papirbasert journal og arkiv, mens andre har behov for å benytte fagsystem med funksjonalitet basert på kjernekravene i Noark 5.
Riksarkivaren vil sørge for kontinuerlig oppdatering og vedlikehold av Noark 5, i form av nye versjoner av standarden.
Mindre endringer i form av feilrettinger, harmonisering av krav som er motstridende, presisering av tekst og omformulering av tekst som kan misforstås eller feiltolkes vil komme fortløpende. Disse mellomversjonene vil beholde hovedversjonsnummeret, og ha fortløpende nummerering etter hovedversjonsnummeret. Noark 5 versjon 1.0 ble utgitt 4. juli 2008. Versjoner i løpet av høsten 2008 med feilrettinger mv. vil ha versjonsnummer 1.1, 1.2, 1.3 osv.
Større endringer hvor det er føyd til kravsett eller tekster er sterkt omarbeidet, vil publiseres med nye hovedversjonsnummer. Dette vil for eksempel skje ved at (deler av) kravsett som ikke er komplett i gjeldende versjon ferdigstilles, og at det kommer nye lover eller reguleringer som må speiles i Noark 5.
Nye hovedversjoner vil komme på faste tidspunkt; innen utgangen av 1. og 3. kvartal hvert år.
MoReq2 er en generell standard for ”electronic records management”. Den er ment å skulle dekke både store og små organisasjoner, offentlig og privat sektor, alle land i EU (og land utenfor EU). Dette betyr at MoReq er svært så generell. Den inneholder ikke krav knyttet til funksjoner for å ivareta lov- og regelverk (heller ikke for EU), ivareta landspesifikk forvaltningsskikk eller –tradisjon eller andre landspesifikke forhold. Dessuten er standarden bare på engelsk. I EU legges det vekt på at hvert land oversetter MoReq2 til sitt språk og utarbeider et ”kapittel null” som inneholder de landspesifikke kravene. Kravene i ”kapittel null” skal ikke være i motstrid til de øvrige kravene i MoReq2.
MoReq2 kommer ikke til å bli et EU-direktiv, den vil fortsatt bare være en anbefaling, og det enkelte EU-land må ta stilling til om og hvordan MoReq2 skal implementeres i landet.
I Norge har Riksarkivaren besluttet at det ikke er aktuelt at Noark-standarden erstattes av MoReq2. Men det har vært et mål å føre Noark 5 så nær opp til Moreq2 som mulig. Moreq2 er på en del områder mer avansert enn Noark, og inneholder en lang rekke krav som ikke har sin motsvarighet i Noark 5. Men de grunnleggende kravene er for en stor del felles, det samme gjelder arkivstrukturen og mange av metadataene. Det har vært et mål for arbeidet at Noark 5 ikke skal inneholde krav som er i strid med MoReq2.
Noark 5 er å betrakte som den offisielle, norske versjonen av MoReq2. Noark 5-kjerne er en teknisk og funksjonell implementering av de generelle kravene til en forsvarlig arkivering, slik de er formulert bl. a. i MoReq2 og i ISO 15489. Dette sikrer opprettholdt autentisitet og integritet over tid. Løsninger som baseres på Noark 5-kjerne, vil sørge for forsvarlig arkivering uavhengig av hvilke regler som gjelder for denne arkiveringen. Løsninger basert på Noark 5-kjerne burde derfor kunne tjene som ”electronic records management”-løsninger også for privat sektor i Norge.
Løsninger som baseres kun på ISO 15489 og MoReq vil ikke kunne aksepteres som Noark 5-kompatible. Arkivlovgivningen inneholder bestemmelser om at forvaltningsorgan som skal ta i bruk løsninger for elektronisk dokumenthåndtering (og arkivering) skal bruke Noark-baserte system som er godkjent av Riksarkivaren. Dette gjelder enten man benytter et rent journal- og arkivsystem, eller om funksjoner for journalføring er integrert i et saksbehandlingssystem eller lignende. Ved elektronisk arkivering av saksdokumenter må systemet tilfredsstille de spesifikke kravene til elektronisk arkivering i Noark-standarden og være godkjent av Riksarkivaren for dette formålet.
Å få orden på dokumenthåndteringen og arkivdanningen (”document management” og ”records management”) i en virksomhet betraktes mer og mer som en nødvendighet for å øke effektiviteten og verdiskapingen i virksomheten. I en elektronisk omgivelse kan systematisk og kontrollert ”records management” være enda vanskeligere enn i en papirbasert, ettersom det kan være umulig å vite om et dokument er endret eller hvilke av alle de versjonene som er lagret rundt omkring som er ”originalen”. Eller dokumentet kan rett og slett være slettet eller umulig å gjenskape.
For å sikre at dokumentet er autentisk med opprettholdt integritet, er det påkrevet å knytte autentiserende metadata til dokumentet. At et dokument er autentisk betyr at dokumentet er hva det gir seg ut for å være, for eksempel ved at identiteten til partene i en elektronisk kommunikasjon er riktig. At dokumentet har opprettholdt integritet betyr at data ikke har blitt endret eller ødelagt på en uautorisert måte eller pga. feil; det er altså en egenskap ved data som gjør det mulig å oppdage om data har blitt endret på en uautorisert måte eller pga. feil.
Med autentiserende metadata menes metadata som har til formål å understøtte dokumentets ektehet og troverdighet, bl.a. ved å gi mottaker opplysninger som kan nyttiggjøres ved kontroll av dokumentets innhold og avsender.
Det er viktig å være klar over at arkivdanning og dokumenthåndtering har ulike innretninger. MoReq definerer forskjellene slik:
|
Løsninger for dokumenthåndtering |
Løsninger for arkivdanning |
|
Tillater at dokumenter endres og/eller finnes i flere versjoner uten at det er kontroll på hvilken versjon som er den endelige |
Hindrer at arkivdokumenter endres, og har versjonskontroll |
|
Kan tillate at dokumentene slettes av dokumenteier |
Hindrer at dokumenter slettes uten at de er gjenstand for kontrollert, autorisert kassasjon |
|
Kan inneholde noe kontroll over hvor lenge et dokument skal oppbevares og om det kan slettes |
Rigorøs ”retention control”, det vil si løsningene skal ha funksjoner for å styre bevaring, migrasjon og kassasjon av arkivdokumenter iht. fastsatte planer. |
|
Kan inneholde strukturert dokumentlagring, som kan være brukerstyrt |
Skal inneholde en rigorøs arkivstruktur med hierarkisk klassifikasjonssystem, som vedlikeholdes av autorisert administrator |
|
Har som primær funksjon å støtte den daglige bruken av dokumenter i løpende saksbehandling |
Kan støtte den daglige bruken av dokumenter i løpende saksbehandling, men skal også være et sikkert og troverdig arkiv for arkivdokumenter. |
Løsninger for dokumenthåndtering kan altså i ettertid verken garantere at et dokument fortsatt kan gjenfinnes, at det er lesbart eller at det dokumentet som man finner, ikke er endret. Løsninger som er utviklet spesielt for arkivdanning, slik Noark-standarden legger til rette for, vil både kunne garantere at dokumentet kan gjenfinnes, at det er lesbart og at dokumentet er autentisk med opprettholdt integritet.
På lengre sikt vil systemarkitekturen også innen statlige virksomheter gå mot en mer tjenesteorientert arkitektur. Dette er en uttalt målsetting fra Fornyings- og administrasjonsdepartementet (FAD). Inndelingen av Noark 5 til en struktur der det er spesifisert en indre kjernefunksjonalitet for å ivareta god arkivhåndtering, med ’valgfrie’ systemer utenfor – integrert, for å ivareta de spesielle fagrelaterte behov for den enkelte virksomhet er et skritt i retning dette målet.
Som en innledning til dette kapitlet ligger dokumentasjon av kravstrukturen i Noark 5. Her er kjernebegrepet forklart og innholdet i de forskjellige lagene er definert.
S
< Noark 5 >

Noark 5 indre kjerne
Utgangspunkt for definering av krav til det indre laget i kjernen er identifisering og definering av de fundamentale funksjoner som må være tilstede for at kjernen skal fungere som en selvstendig ’tjeneste’ i et arkivsystemmiljø. Kjernen må – innenfor sitt domene – arkivering, kunne fungere alene og uten å være avhengig av utenforliggende funksjoner, programmer eller lignende for å gjøre sin definerte del av jobben.
Noark 5 ytre kjerne
For at den indre kjernen skal kunne fungere i et arkivsystemmiljø må det stilles en del krav til ’eksterne’ modulers funksjonalitet. Dette er krav formet ut fra arkivkjernens behov og kan defineres som det ytre laget i selve kjernen – kjernens krav mot eksterne systemer. Både det indre og ytre ’laget’ med krav i kjernen må oppfylles for at et system skal kunne godkjennes som et Noark 5 basert arkivsystem.
Noark 5 komplett
Det tredje ’laget’ med krav består av krav Noark 5 har til de frittstående moduler eller systemer som utgjør en komplett sak-, journal- og arkivløsning i et gitt brukermiljø. Dette er fag- og forsystemer som den enkelte virksomhet har behov for å bruke og som kan være levert av forskjellige leverandører. Sammen med Noark 5 kjerne (indre og ytre) utgjør dette Noark 5 komplett. Noark 5’s krav til de eksterne systemer eller moduler er ordnet i egne (selvstendige) kapitler.
Krav til moduler i Noark 5 indre kjerne
I
<
Kjerne 2 >
Kravene i den indre kjernen i Noark 5 består av den fundamentale arkivfunksjonaliteten, krav basert i lov og regelverk for forsvarlig arkivførsel, pluss en del viktige funksjonsområder for drift og forvaltning av kjernen. Skissen viser hvilke moduler som ligger i Noark 5’s indre kjerne.
Selve arkivområdet, inndelt i arkivstruktur og –regelverk, inneholder basiskravene for arkivering. I tillegg skal den indre kjernen inneholde modulene Datafangst, Søking/vising/fremhenting av data, Bevaring kassasjon, Avlevering samt en Administrasjonsmodul for kjernen,
Krav til moduler i Noark 5 ytre kjerne
Den ytre kjernen omfatter krav til eksterne (valgfrie) systemer. Noark 5’s kjerne er avhengig av å arbeide sammen med forskjellige forsystemer implementert etter den enkelte virksomhets eller leverandørs behov.
For at Noark 5 skal fungere i et helhetlig arkivsystemmiljø, må Noark 5 kunne integreres med de forsystemer / fagsystemer som må implementeres for å komplettere en journal- og arkivløsning.
<Noark 5>
I kjernens ytre del (den såkalte gråsonen) ligger Noark 5’s krav til disse eksterne, valgfrie systemer og/eller moduler basert i arkivområdets lov og regelverk.
Dette er systemer eller moduler som anses som frie løsninger i forhold til kjernen. Det vil si at leverandørene og kundene (brukerne) av Noark 5 fritt kan velge systemløsninger og integrere disse med Noark 5 kjernen så lenge de aktuelle løsningene tilfredstiller de krav kjernen stiller til en slik løsning.
Eksempel på forståelse av figuren:
Det er ikke ment at systemet for f.eks. ’Tilgang og sikkerhet’ må være en egen modul i Noark 5 kjernen, men Noark 5 kjernen har noen spesifikke krav til sikkerhet og tilgangskontroll som den eksterne systemløsningen for dette området må oppfylle.
Dette kapitlet legger således føringer og krav på de forskjellige fag- eller forsystemer som kan være frittstående systemer i forhold til Noark 5. Men disse kravene må anses som en del av Noark 5 kjernekrav og må oppfylles for at en systemløsning skal kunne godkjennes som en Noark 5-løsning.
Noark 5 komplett
Innen offentlige forvaltning kan behov og krav til fagsystemer være svært forskjellig fra organ til organ. I Noark 5 komplett ligger krav til funksjoner, innhold og bruk av eksterne systemløsninger som naturlig benyttes integrert med Noark 5 kjernefunksjonalitet. Dette vil dreie seg om selvstendige fagsystemer / fagmoduler som et organ fritt kan velge å innføre fra forskjellige leverandører. Det må være opp til det enkelte organ hvor hardt man ønsker å stå på disse kravene i forhold til den aktuelle leverandør av systemer.
Krav beskrevet i Noark 5 komplett er krav som mer har sin bakgrunn i god bruk (sett i forhold til journalføring og arkivering), samt rutine- og prosessbaserte krav til det aktuelle fagsystemet enn krav basert i konkret arkivrelatert lov- og regelverk.
<Noark 5>

I de etterfølgende kapitlene ligger det krav til bruken av eksterne valgfrie løsninger som naturlig inngår som en del av en komplett Noark 5 arkivløsning.
De kravsatte systemene /modulene som inngår i Noark 5 komplett er system for:
saksbehandlingsløsning
e-Postløsning
løsning for møte- og utvalgsbehandling
logging- og sporingsløsning
sikkerhets- og tilgangsløsning
statistikk og rapporteringsløsning
brukeradministrasjonsløsning
Dette er utvidede krav i forhold til Noark 5 indre og ytre kjerne og vil være mer føringer enn krav som skal/må oppfylles for å oppnå en Noark 5 status på systemløsningen.
Noark 5 komplett
Det totale bildet av Noark 5 komplett kan fremstilles som i denne skissen.
Noark 5>
Arkivstrukturen kan vi gjerne kalle den indre ordningen av arkivet. Denne strukturen er hierarkisk med flere nivåer fra topp til bunn. Som en fellesbetegnelse på hovedklassene i disse nivåene brukes begrepet arkivenhet.
I et fysisk arkiv vil arkivstrukturen i høy grad gjenspeiles i papirdokumentenes sortering og fysiske oppstilling i omslag, mapper, arkivbokser, skap osv. I et elektronisk arkiv kan også dokumentene presenteres som om de ligger i mapper, og en hierarkisk arkivstruktur kan representeres ved at mapper ligger i andre mapper i flere nivåer.
Men i et elektronisk arkiv eksisterer selvfølgelig ikke mappene som fysiske enheter. Arkivstrukturen i et elektronisk arkiv er bare bygd opp av forskjellige metadata. Hver enhet i strukturen har sine bestemte metadata, og de forskjellige nivåene er også koblet sammen med metadata. Metadata er aggregert på flere nivåer, slik at metadata på øverste nivå vil være knyttet til alle dokumenter i arkivet, mens metadata på laveste nivå bare er knyttet til et enkeltdokument.
Elektronisk og fysisk arkiv
Det blir stadig mer vanlig at arkiver består av elektroniske dokumenter. Men mange virksomheter har fremdeles deler av sitt arkiv på papir. Noark 5 har fokus på elektronisk arkivering, men skal også kunne brukes for fysisk arkivering og for en blanding av elektronisk og fysisk arkiv.
Mange metadata er aktuelle både for elektronisk og fysisk arkiv, men det finnes også metadata som bare gjelder for den ene typen arkivering.
Forskjellige typer arkiver
Tradisjonelt er det arkivene etter den generelle saksbehandlingen – saksarkivene – som har vært innenfor arkivtjenestens ansvarsområde og dermed fått mest oppmerksomhet ved utforming av regelverk og standarder. Noark 4 rettet seg bare mot denne typen arkiver.
En viktig forskjell mellom Noark 4 og Noark 5 er at standarden nå skal kunne omfatte de fleste typer arkiver. Dersom den indre kjernen er integrert med et fagsystem, vil det i mange tilfeller ikke være nødvendig med full sakarkivfunksjonalitet. I en del tilfeller kan det også gjøre integrasjon vanskelig. Typisk for mange fagsystemer er spesialisert saksbehandling, hvor noen få aktiviteter gjentas etter faste rutiner. Antall dokumenter som mottas og produseres i slike fagsystemer kan ofte være svært høyt. I slike tilfeller kan det være behov for en enklere arkivstruktur og færre metadata enn det som er aktuelt ved sakarkiver.
Metadata betyr "data om data", og er informasjon som beskriver dokumentene i arkivet, både fysiske og elektroniske dokumenter. Dokumentene tilføres først og fremst metadata under dokumentfangst. Noe av dette vil skje manuelt, men mye skjer også automatisk. I enkelte fagsystemer kan nesten all fangst av metadata være automatisert. En del metadata skal fryses straks de er registrert, og etter at dokumentene er endelig arkivert skal de fleste metadata bare kunne endres av spesielt autoriserte brukere.
Metadata har flere viktige funksjoner. Det er metadataene som binder dokumentet til den konteksten det er skapt i. Uten metadata vil ikke et elektronisk dokument være autentisk, og vil dermed heller ikke ha noen bevisverdi. Med andre ord: uten metadata vil ikke dokumenter være arkivdokumenter - eller records. En annen viktig funksjon for metadata er å være framfinningsmiddel. Metadata vil også kunne styre tilgangen til dokumentene og skjerme andre metadata som ikke er offentlig tilgjengelig (f.eks. personnummer). Metadata kan også styre bevaring og kassasjon, dvs. en kontrollert sletting av alle dokumenter som har en begrenset oppbevaringstid.
Metadata for arkiv kan deles opp i forskjellige kategorier. Nedenfor følger et eksempel på en slik inndeling:
Unike identifikatorer
Informasjon om hvem som har arkivert ("fanget") dokumentet, og tilført ("registrert") metadata, samt når det skjedde
Metadata om struktur, dvs. informasjon om dokumentets form, og om dokumentets tilknytning til andre dokumenter og til de forskjellige nivåene i arkivstrukturen
Metadata om kontekst, dvs. hvilken funksjon, prosess og aktivitet som har skapt dokumentet, hvilke personer og virksomheter som har deltatt i denne aktiviteten, datoer for når dokumentet ble skapt, sendt, mottatt osv.
Metadata om innhold, f.eks. titler og beskrivelser
Metadata for gjenfinning, inkludert nøkkelord og indekstermer
Oppbevaringssted og format for fysiske dokumenter
Arkivansvar dersom et system deles av flere virksomheter
Tilgangsrettigheter og skjerming av informasjon
Bevarings- og kassasjonsbestemmelser
Metadata i Noark 5
I Noark 5 blir det definert metadata for alle nivåer i arkivstrukturen. Disse metadataene er nærmere spesifisert i et eget vedlegg, som en metadatakatalog. Mange av de samme metadataene vil opptre på forskjellige nivåer i arkivstrukturen, men de vil bare bli spesifisert én gang i katalogen.
Metadata i Noark 5 kan ikke sammenlignes med attributtlistene i Noark 4. Metadata utgjør på langt nær alle attributter som er nødvendig i en databaseløsning. Utgangspunktet for definisjonen av metadata har vært kravet til hva som skal inngå i et avleveringsuttrekk. Men det er også tatt hensyn til metadata som skal kunne utveksles elektronisk sammen med dokumenter, metadata som skal kunne deles ved integrasjon med fagsystemer, og metadata som skal kunne migreres til andre systemer sammen med tilhørende dokumenter.
Metadata blir navngitt på en entydig måte som er nærmere forklart i metadatakatalogen. Dette betyr ikke at attributtene i databasen skal bruke de samme navnene. Det er kun ved eksport og utveksling av data, f.eks. i XML-format, at metadatanavnene er obligatoriske.
Alle metadata behøver heller ikke være lagret som attributter (felter) i databasen, i en del tilfeller vil metadata genereres først når data eksporteres eller utveksles.
Metadata skal kunne arves fra en overordnet enhet til en underordnet, men dette betyr ikke at systemet selv nødvendigvis behøver å duplisere de tilsvarende attributtene.
Data som er lagret som bare ett attributt i databasen, kan eksporteres som flere forskjellige metadataelementer (eksempel: navn på avsender og mottaker kan lagres som ett attributt i databasen, men ved eksport er avsender og mottaker to forskjellige elementer).
Det er ikke noe krav at alle metadata i katalogen nødvendigvis må lagres i den indre kjernen. I en del løsninger er det mer hensiktmessig å lagre deler av metadata i fagsystemet. Men det er et krav at ved eksport eller utveksling skal alle obligatoriske metadata inngå i en felles struktur. Slike strukturer vil bl.a. bli beskrevet i form av XML skjema i Noark 5.
I dette kapitlet presenteres metadataelementer i et fastlagt skjema:
|
Nr. |
Navn |
Noark 4 |
Obligatorisk |
Forekomst |
Avleveres |
Nummeret henviser til nummer i metadatakatalogen
Navnet skal brukes ved eksport av metadata, f.eks. som XML-elementnavn
Obligatoriske metadata må alltid ha en verdi ved eksport eller utveksling. Betingede obligatoriske metadata, må ha en verdi ved gitte betingelser - f.eks. må avsluttetDato ha en verdi dersom enheten er avsluttet eller lukket. Valgfrie metadata kan være tomme, men det betyr ikke at disse nødvendigvis er mindre "viktige" enn de obligatoriske
Noen metadataelementer vil bare ha én verdi ved eksport og utveksling, mens andre kan ha flere
De fleste metadata skal inngå i avleveringsuttrekk, dersom feltet er tomt er det ikke obligatorisk ved avlevering
Kommentarer som gjelder bruk av metadata for den enkelte arkivenhet, følger under tabellene. En mer detaljert beskrivelse av de enkelte metadataelementer finnes i metadatakatalogen.
Noark 5 skal være bakoverkompatibel med Noark 4 i den betydningen at det skal være mulig å migrere arkiver fra systemer basert på den eldre standarden til den nye. Dette er det tatt hensyn til både når det gjelder oppbygningen av arkivstrukturen og metadataene som defineres. Et eksempel på dette er at enhetene arkiv og arkivdel fremdeles er beholdt i arkivstrukturen.
Samtidig har det vært et mål å føre Noark 5 så nær opp til Moreq2 som mulig. Moreq2 er på en del områder mer avansert enn Noark, og inneholder en lang rekke krav som ikke har sin motsvarighet i Noark 5. Men de grunnleggende kravene er for en stor del felles, det samme gjelder arkivstrukturen og mange av metadataene.
Innhold i den indre kjernen
Den indre kjernen skal inneholde virksomhetens arkiv, dvs. de arkivdokumenter som mottas eller produseres som følge av de aktiviteter virksomheten utøver.
Arkivdokumenter kommer inn i arkivet, dvs. arkiveres, gjennom dokumentfangst. Dokumentene skal organiseres i en arkivstruktur som viser sammenhengen mellom dokumentene. Dette innebærer at dokumenter må plasseres på riktig sted i arkivet. Når dokumenter arkiveres, skal de fryses for all videre redigering.
Dokumentfangst innebærer også at dokumentene tilføres metadata, dvs. informasjon om dokumentenes innhold, kontekst og struktur. En viktig funksjon til metadata er å opprettholde dokumentenes autentisitet over tid. Det må ikke være tvil om at et dokument er ekte, og at det er skapt av den som utgir seg for å ha skapt det.
Arkivstrukturen skal kunne administreres av de som har rettigheter til det. Det må f.eks. være mulig å flytte på dokumenter som er feilarkivert.
Dokumenter som er arkivert skal kunne gjenfinnes på en rask og sikker måte, og både dokumentene og sammenhengen de inngår i skal kunne presenteres på en oversiktelig måte for brukerne.
Den indre kjernen må også inneholde funksjoner for bevaring og kassasjon. En virksomhet har ikke behov for, eller lov til å ta vare på alle sine arkivdokumenter like lenge, og det må derfor være mulig å legge inn regler for når disse kan fjernes fra arkivet.
Arkivmyndighetene vil også fatte vedtak om at bestemte arkivdokumenter hos offentlige organer skal tas vare på i all framtid. Disse dokumentene må kunne avleveres til et arkivdepot.
I dette kapitlet ligger en beskrivelse av overordnet modell for arkivstrukturen i Noark 5.
Kapitlet inndeles i det fortløpende etter strukturmodellen, dvs at for hvert nivå i strukturen etableres det et tilhørende kapittel som dokumenterer strukturnivået med en egen delmodell og krav til denne.
I tillegg vil det i egne underkapitler bli beskrevet metadata for funksjonalitet som gjelder for alle nivåer i modellen.
Hovedmodell for arkivstrukturen
Modellene i Noark 5 er konseptuelle modeller som skal vise sammenhengen mellom forskjellige metadata, og mellom metadata og fysiske eller elektroniske dokumenter. De skal ikke tolkes som ufravikelige datamodeller tilsvarende de som er definert i de mer tekniske spesifikasjonene i Noark 4. De konseptuelle modellene i Noark 5 sier noe om hvordan informasjonen prinsipielt skal organiseres. De vil også være utgangspunktet for definisjonen av datastrukturer ved elektronisk kommunikasjon, integrasjon med andre systemer, migrering fra et system til et annet og for avlevering.
<ARKIVSTRUKTUR
NOARK 5>
Overordnet skisse1 av den konseptuelle modellen for Noark 5:
Nivåene for MAPPE og REGISTRERING er bygd ut ved hjelp av spesialisering av klassene.
Den arkivstrukturen som er skissert gjennom den konseptuelle modellen i dette kapitlet utgjør hovedstrukturen i Noark 5 og vil gjelde for de fleste ’sakarkiver’.
Forenklet struktur
I noen fagsystemer kan det være behov for en forenklet struktur i forhold til sakarkiver. Dersom det i et fagsystem (f.eks. et tegningsarkiv) ikke er noe behov for å gruppere registreringer i mapper, kan mappenivået utgå. Likeledes kan nivået dokumentbeskrivelse utgå dersom en registrering alltid kun består av ett eneste dokument, og dersom dette dokumentet ikke vil forekomme i andre registreringer.
Ordning av dokumentene i et klassifikasjonssystem er heller ikke obligatorisk for fagsystemer. Dersom klassifikasjonssystemet tas med, skal det likevel være mulig å utelate mappenivået. Dette betyr altså at registreringer kan knyttes direkte til en klasse.
Det understrekes at en slik forenklet struktur kun vil være aktuelt for noen få fagsystemer. Det må ikke forstås slik at klassifikasjonssystem, mapper og dokumentbeskrivelse kan utelates fra løsninger som er rettet mot sakarkiver. Mange fagystemer, f.eks. fagsystemer som inneholder korrespondanse, vil dessuten ha behov for samme fullstendige arkivstruktur som sakarkiver.
Hvis man ser på oppbyggingen av arkivstrukturen i de forskjellige konseptuelle modellene for hvert nivå i arkivstrukturen, vil man se at det ligger en forenklet struktur innebygd gjennom bruk av beskrankninger som ’enten/eller’. Dette gir mulighet til å etablere et arkiv uten å måtte bruke nivåene for Mappe og/eller Dokumentbeskrivelse.
F
<FORENKLET
STRUKTUR NOARK 5>
Definisjon av de enkelte nivå /arkivelementene ligger i de respektive kapitlene for arkivnivået.
|
Krav nr. |
Overordnede krav til arkivstrukturen |
Type |
Merknad |
|---|---|---|---|
|
|
For at et system skal kunne godkjennes etter Noark 5-standarden, må den konseptuelle modellen av arkivstrukturen og de funksjonelle muligheter den gir, kunne implementeres i det aktuelle systemets (fysiske) datastrukturer. |
O |
|
|
|
Arkivdokumenter som tilhører et sakarkiv skal inngå i en arkivstruktur som skal inneholde følgende arkivenheter: Arkiv, Arkivdel, Klassifikasjonssystem, Klasse, Mappe 1) , Registrering2), Dokumentbeskrivelse og Dokumentobjekt.
1)Mappe er en fellesbenevning for arkivenhetene: Basismappe inkl. utvidelsene Saksmappe og Møtemappe.
2)Registering er en fellebenevning for arkivenhetene: Forenklet registrering inkl. utvidelsene Basisregistrering, Journalpost og Møteregistrering. |
O |
|
|
|
Arkivdokumenter som ikke tilhører
et sakarkiv (eks. fagarkiv) kan inngå i en ’forenklet’
arkivstruktur som minimum skal kunne inneholde følgende
arkivenheter:
1)Registering er en fellebenevning for arkivenhetene: Forenklet registrering inkl. utvidelsene Basisregistrering, Journalpost og Møteregistrering. |
O |
|
|
|
Noark 5 skal ha tjenester/funksjoner for å lagre, gjenfinne, endre og slette data og utvalg1) av data i henhold til metadatabeskrivelsene i alle arkivenheter (se krav 4.2) og tilhørende klasser som er dokumentert i de konseptuelle modellene og metadatatabellene i Noark 5.
Mrk: Funksjonelle enkeltkrav i de forskjellige kapitlene kan overstyre dette kravet.
1)Med utvalg av data menes utvalg innenfor en fra-/til angivelse av obligatoriske metadata for aktuell arkivenhet. |
O |
|
|
|
En arkivenhet (se krav 4.2) skal kunne identifiseres entydig.
|
O |
|
Dette kapitlet omhandler krav til arkiv og arkivdeler. Det er delt opp i tre underliggende kapitler: Arkiv, Underarkiv og Arkivdel.
Forskjellige virksomheter vil ha forskjellig behov her. Moreq2 har ikke noe som tilsvarer arkiv og arkivdel, her er det klassifikasjonssystemet som håndterer all gruppering av dokumenter på de øverste nivåene. Men i Noark 5 må både arkiv og arkivdel være obligatorisk. Dette skyldes både hensynet til bakoverkompatibilitet med Noark 4, og at viktig funksjonalitet er knyttet til arkivdel.
K
<Konseptuell
modell Arkiv /Arkivdel>
Det er i enkelte tilfeller behov for et ekstra nivå mellom arkiv og arkivdel. Det er særlig for fysiske arkiver innenfor kommunesektoren at det er helt avgjørende å kunne dele opp arkiver i flere (fysiske) deler. Dette er løst ved å innføre såkalte underarkiv i den konseptuelle modellen. Underarkiv er en hierarkisk struktur innenfor arkivet og kan således defineres i flere nivåer. I praksis vil det vanligvis være ett nivå.
Arkiv
Et arkiv består av dokumenter som blir til som ledd i en virksomhet, dvs dokumenter som mottas eller produseres av en enkelt arkivskaper og samles som resultat av dennes virksomhet. En Noark-base kan omfatte ett eller flere arkiver.
Arkivdel
En vilkårlig definert del av et arkivet hvor alt materiale er inndelt og ordnet etter ett og samme ordningsprinsipp som primærnøkkel. Vil ofte være definert identisk med arkivserie, men behøver ikke være det.
Arkivskaper
En organisatorisk enhet eller en person som danner arkiv som ledd i sin virksomhet. En arkivskaper kan være et offentlig organ, en bedrift, en organisasjon, en institusjon, en stiftelse etc. eller en del av en slik enhet. Et offentlig organ kan være én arkivskaper og dermed ha ett arkiv (sentralarkiv), eller det kan ha flere arkivskapere (avdelinger, etater etc.) som skaper hver sitt arkiv (underarkiver).
Skjerming
Skjerming benyttes til å skjerme registrerte opplysninger eller enkeltdokumenter. Skjermingen
trer i kraft når en tilgangskode påføres den enkelte mappe, registrering eller det enkelte
dokument.
(Se eget kapittel: Sikkerhet og tilgangsstyring)
Bevaring og kassasjon
Koder som angir vedtak om kassasjon. Kassasjonsvedtak bestemmer hvilket arkivmateriale som skal fjernes fra arkivet, og tilintetgjøre dette.
(Se eget kapittel: Bevaring og kassasjon)
Klassifikasjonssystem
(se eget kapittel: Klassifikasjonssystem og Klasse)
Arkiv
Arkiv er det øverste nivået i arkivstrukturen. De fleste brukere vil bare ha behov for å opprette ett arkiv i sin Noark 5-løsning. Men det skal være mulig å opprette flere arkiver. Det kan være aktuelt dersom flere organer deler samme løsning. Det kan også være aktuelt dersom en hel etat deler samme løsning. Her kan da f.eks. hovedkontoret og hvert distriktskontor settes opp med hvert sitt arkiv. Men ved elektronisk arkivering er det heller ikke noe i veien for at hele etaten deler samme arkiv.
Arkivskaper
Tradisjonelt har et arkiv blitt definert etter organisasjon. Ett organ skaper ett arkiv, dvs. organet er arkivskaperen. Men elektronisk informasjonsteknologi har ført til at det blir stadig vanligere at flere arkivskapere sammen skaper ett arkiv. Arkivet vil da være definert etter funksjon, ikke organisasjon2.
I en Noark 5-løsning skal det altså være mulig å knytte en eller flere arkivskapere til et arkiv. Informasjon om arkivskapere er obligatorisk i avleveringsuttrekk.
Metadata for Arkiv
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M001 |
systemID |
Obligatorisk |
En |
Avleveres |
|
M020 |
tittel |
Obligatorisk |
En |
Avleveres |
|
M021 |
beskrivelse |
Valgfri |
En |
Avleveres |
|
M050 |
arkivstatus |
Valgfri |
En |
|
|
M300 |
dokumentmedium |
Valgfri |
En |
Avleveres |
|
M301 |
oppbevaringssted |
Valgfri |
Mange |
|
|
M600 |
opprettetDato |
Obligatorisk |
En |
Avleveres |
|
M601 |
opprettetAv |
Obligatorisk |
En |
Avleveres |
|
M602 |
avsluttetDato |
Bet. oblig. |
En |
Avleveres |
|
M603 |
avsluttetAv |
Bet. oblig. |
En |
Aleveres |
|
M200 |
referanseForelder |
Bet. oblig. |
En |
Avleveres |
|
M201 |
referanseBarn |
Obligatorisk |
Mange |
Avleveres |
Merknad
Refereransen til barn vil alltid gå til den arkivenheten som er direkte underordnet gjeldene arkivenhet. I dette tilfelle kan altså referanseBarn enten referere til et underarkiv eller et delarkiv.
Metadata for arkivskaper
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M006 |
arkivskaperID |
Obligatorisk |
En |
Avleveres |
|
M023 |
arkivskaperNavn |
Obligatorisk |
En |
Avleveres |
|
M021 |
beskrivelse |
Valgfri |
En |
Avleveres |
Merknad
Arkivskaper er obligatorisk, og kan forekomme en eller flere ganger i arkiv.
Krav til Arkiv
|
Krav nr. |
Strukturelle krav til Arkiv |
Type |
Merknad |
|---|---|---|---|
|
|
En Noark 5-løsning skal kunne bestå av ett eller flere selvstendige Arkiv. |
O |
|
|
|
Det skal være mulig å opprette ingen, ett eller flere Arkiv for en Arkivskaper (virksomhet) og det skal være mulig å angi at flere arkivskapere sammen skaper ett arkiv. |
O |
|
|
|
Et Arkiv skal bestå av en eller flere Arkivdeler og en Arkivdel skal inngå i (kun) ett Arkiv. |
O |
|
|
Krav nr. |
Funksjonelle krav til Arkiv |
Type |
Merknad |
|---|---|---|---|
|
|
Dersom Arkiv er registrert som ’avsluttet’, skal det ikke være mulig å legge til flere underliggende Arkivdel(er). |
O |
|
|
|
Når en tjeneste/funksjon sletter et helt Arkiv med alle underliggende nivå, skal dette logges. |
O |
|
|
|
Det skal ikke være mulig å endre dato for opprettelse av arkiv. |
O |
|
|
|
Det skal ikke være mulig å slette dato for opprettelse av arkiv. |
O |
|
|
|
Det skal ikke være mulig å slette dato for avslutning av arkiv. |
O |
|
|
|
Det bør være mulig å definere følgende statusverdier for arkiv:
|
O |
|
Ved fysisk arkivering kan ett organ ha plassert dokumentene på flere forskjellige steder, f.eks. knyttet til avdelingene som skaper dokumentene. Dette gjelder særlig for organer med komplekse strukturer som for eksempel kommunene. I en Noark 5-løsning skal det være mulig å dele arkiver opp i underarkiver for de brukere som har behov for det3.
Ved elektronisk arkivering er det neppe behov for underarkiv.
Underarkiv fremkommer i den konseptuelle modellen som en egenrelasjon i Arkiv. Det vil si at Arkiv kan bygges opp i et hierarki (eier-medlemstruktur). I de aller fleste tilfeller dreier dette seg om ett nivå som ligger mellom Arkiv og Arkivdel. Delarkiv er ikke obligatorisk i arkivstrukturen.
Metadata for Underarkiv
Se ’Metadata for Arkiv’
Krav til Underarkiv
|
Krav nr. |
Strukturelle krav til underarkiv |
Type |
Merknad |
|---|---|---|---|
|
|
Et Arkiv skal kunne inndeles i et hierarki (skissert i modellen ved bruk av egenrelasjon) av underarkiver.
Merknad: Det skal være mulig med ett eller flere nivåer under Arkiv, f.eks. for å representere fysiske delarkiver. Dette kan være aktuelt for virksomheter som har arkiver fysisk plassert på flere forskjellige steder. |
O |
|
|
Krav nr. |
Funksjonelle krav til Underarkiv |
Type |
Merknad |
|---|---|---|---|
|
|
Systemet skal ha en tjeneste/funksjon for å angi et Arkiv som Underarkiv til et Arkiv. |
O |
|
|
|
Et Underarkiv skal kun opprettes og endres gjennom Administrasjonssystemet for Noark 5. |
O |
|
Et arkiv skal kunne deles opp i arkivdeler når en har behov for å gruppere arkivet etter overordnede kriterier. De viktigste kriteriene for oppdeling i arkivdeler er:
Skille mellom aktivt arkiv og avsluttede arkivperioder. Viktige funksjoner i forbindelse med periodisering og produksjon av avleveringsuttrekk er knyttet til dette.
Skille mellom mapper (saker) som skal periodiseres etter forskjellige prinsipper. Mange ønsker f.eks. å beholde personalmapper i et aktiv arkiv så lenge en person er ansatt.
Skille mellom saker som er klassifisert etter forskjellige prinsipper. Dette er mest aktuelt ved fysisk arkivering hvor f.eks. saksmapper og personalmapper oppbevares på forskjellig sted. Ved elektronisk arkivering vil inndeling i forskjellige klassifikasjonssystemer ivareta dette behovet.
Skille mellom elektronisk arkiv og fysisk arkiv. Hovedregelen er at hele mapper enten skal være fysiske eller elektroniske. Men det kan gis dispensasjon fra denne regelen, slik at enkelte registreringer kan være fysiske og andre elektroniske i samme mappe. Dersom et stort vedlegg (f.eks. en trykksak) ikke er blitt skannet, kan også fysiske dokumenter forekomme sammen med elektroniske dokumenter i samme registrering (journalpost).
Skille mellom sakarkivet og andre typer arkiver, f.eks. arkiver tilknyttet fagsystemer. Noen vil ha behov for et klart skille mellom de administrative sakene og fagsakene. Det vil også være et behov for å skille ut møtedokumenter.
Skille mellom dokumenttyper som skal bevares og dokumenter som skal kasseres.
Metadata for Arkivdel
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M001 |
systemID |
Obligatorisk |
En |
Avleveres |
|
M020 |
tittel |
Obligatorisk |
En |
Avleveres |
|
M021 |
beskrivelse |
Valgfri |
En |
Avleveres |
|
M051 |
arkivdelstatus |
Bet. oblig. |
En |
|
|
M300 |
dokumentmedium |
Bet. oblig. |
En |
Avleveres |
|
M301 |
oppbevaringssted |
Valgfri |
Mange |
|
|
M600 |
opprettetDato |
Obligatorisk |
En |
Avleveres |
|
M601 |
opprettetAv |
Obligatgorisk |
En |
Avleveres |
|
M602 |
avsluttetDato |
Bet. oblig. |
En |
Avleveres |
|
M603 |
avsluttetAv |
Bet. oblig. |
En |
Avleveres |
|
M107 |
arkivperiodeStartDato |
Obligatorisk |
En |
Avleveres |
|
M108 |
arkivperiodeSluttDato |
Bet. oblig. |
En |
Avleveres |
|
M200 |
referanseForelder |
Obligatorisk |
En |
Avleveres |
|
M202 |
referanseForløper |
Bet. oblig. |
En |
Avleveres |
|
M203 |
referanseArvtaker |
Bet. oblig. |
En |
Avleveres |
|
M204 |
referanseKlassifikasjons system |
Bet. oblig. |
En |
Avleveres |
|
M205 |
referanseMappe |
Bet. oblig. |
Mange |
Avleveres |
|
M206 |
referanseRegistrering |
Bet. oblig. |
Mange |
Avleveres |
Merknad
referanseRegistrering vil forekomme sjelden, men kan være aktuell dersom arkivdelen f.eks. brukes til å skille fysisk og elektronisk arkiv.
Antall referanser til mappe kan bli svært høyt. Men når referansene går begge veier, dvs. både fra mappe til arkivdel og fra arkivdel til mappe, vil avleveringsuttrekket bli mer robust enn om referansene hadde gått bare en vei.
Referanse til registrering vil være aktuelt dersom arkivdel brukes til å styre bevarings- og kassasjonsvedtak for bestemte registreringstyper (dokumenttyper).
Krav til Arkivdel
|
Krav nr. |
Strukturelle krav til Arkivdel |
Type |
Merknad |
|---|---|---|---|
|
|
En Arkivdel kan ha registrert ingen eller ett preferert Klassifikasjonssystem og et Klassifikasjonssystem kan inngå i ingen, ett eller flere Arkivdel(er). |
O |
|
|
|
En Arkivdel kan ha registrert ingen eller en Skjerming og en Skjerming kan inngå i ingen, ett eller flere Arkivdel(er). |
O |
|
|
|
En Arkivdel kan ha registrert ingen eller en Kassasjon og bevaring og en Kassasjon og bevaring kan inngå i ingen, ett eller flere Arkivdel(er). |
O |
|
|
|
En Arkivdel kan ha tilknyttet (inneholde) ingen, en eller flere Mapper. |
O |
|
|
Krav nr. |
Funksjonelle krav til Arkivdel |
Type |
Merknad |
|---|---|---|---|
|
|
Når en tjeneste/funksjon sletter en Arkivdel, skal dette logges. |
O |
|
|
|
Det skal finnes en tjeneste/funksjon for å ajourholde primært Klassifikasjonssystem for en Arkivdel. (referanseKlassifikasjonssystem) |
O |
|
|
|
Dersom Arkivdel er registrert som avsluttet (avsluttetDato er satt) skal det ikke være mulig å legge til flere tilhørende Mapper eller Registreringer |
O |
|
|
|
En arkivdel skal inneholde informasjon om hvilken status arkivperioden har. Autoriserte brukere skal kunne endre statusverdier. Obligatoriske verdier er:
Andre verdier kan brukes ved behov. |
O |
|
|
|
En arkivdel skal inneholde dato for når arkivperioden starter. |
O |
|
|
|
En avsluttet arkivdel skal inneholde dato for når perioden ble avsluttet. |
BO |
|
|
|
En arkivdel skal inneholde informasjon om de tilhørende dokumentene er fysiske eller elektroniske. |
O |
|
Klassifikasjonssystem
Moderne arkivteori legger vekt på at klassifikasjonssystemet skal være funksjonsbasert. En virksomhet vil typisk utøve et bestemt antall funksjoner. Disse er ofte stabile over tid, men funksjoner kan overføres fra en virksomhet til en annen. Et eksempel på en slik overføring er når saksområder flytter fra et departement til et annet, noe som ofte skjer i forbindelse med et regjeringsskifte. En virksomhet vil vanligvis bare ha et fåtall hovedfunksjoner, men noen av disse kan deles opp i underfunksjoner.
Funksjoner kan deles inn i aktiviteter. I motsetning til en funksjon, har en aktivitet en begynnelse og en slutt. En aktivitet har også deltakere, og den fører til et resultat. Dersom en aktivitet stadig gjentar seg, tilhører den en prosess.
Aktiviteter kan ofte deles opp i forskjellige trinn. Dersom disse trinnene involverer to eller flere parter, snakker vi gjerne om en transaksjon. Det er transaksjoner som skaper arkivdokumenter (records).
Dette hierarkiet av funksjoner, underfunksjoner og aktiviteter skal gjenspeiles i et funksjonsbasert klassifikasjonssystem. Stort sett vil dette tilsvare det som kalles "emnebasert" klassifikasjon. Men det er litt feil å snakke om emne her. Et emne sier noe om hva et objekt inneholder, mens en funksjon sier noe om hvorfor et objekt har blitt til.
Det er mange grunner til å organisere et arkiv etter et funksjonsbasert klassifikasjonssystem:
Dokumenter som har blitt til som resultat av de samme aktivitetene blir knyttet sammen. Dette tilfører dokumentene viktig kontekstuell informasjon.
Gjenfinning av mapper og dokumenter forenkles.
Kan styre tilgangen til dokumentene. Bestemte klasser kan f.eks. inneholde dokumenter som må skjermes.
Kan være et utgangspunkt for bevaring og kassasjon. Det er i dag allment akseptert at kassasjonsvedtak bør baseres på virksomhetens funksjoner og aktiviteter, og ikke på dokumentenes innhold (makrokassasjon).
Den andre hovedtypen av klassifikasjonssystemer er objektbasert klassifikasjon. "Objektene" vil ofte være personer, men kan også være virksomheter, eiendommer o.l. I motsetning til funksjonsbaserte klassifikasjonssystemer, er objektbaserte systemer ofte flate - dvs. de består av bare ett nivå.
Klasse
Et klassifikasjonssystem er bygd opp av klasser. Ved funksjonsbasert (emnebasert) klassifikasjon vil klassene vanligvis inngå i et hierarki, hvor tre eller fire nivåer er det vanlige. I den konseptuelle modellen er undernivåene kalt underklasser, og fremkommer som en egenrelasjon i Klasse4.
ISO 15489 anbefaler at klassene beskriver organets funksjoner og aktiviteter (forretningsprosesser). Øverste nivå vil da typisk beskrive hovedfunksjonene, nivå to kan beskrive underfunksjoner og nivå tre prosessene (dvs. aktiviteter som stadig gjentas).
Klassene skal ha en egen identifikasjon som er unik innenfor klassifikasjonssystemet. Dette tilsvarer det som er kalt ordningsverdi eller arkivkode i Noark 4. Identifikasjoner fra overordnede klasser skal arves nedover i hierarkiet, slik at det er lett å si hvilket nivå en befinner seg på5.
Ved objektbasert klassifikasjon med bare ett nivå, kan identifikasjonen f.eks. være fødselsnummer eller gårds- og bruksnummer.
Det skal være mulig å klassifisere en saksmappe med mer enn en klasse, dvs. med en eller flere sekundære klassifikasjoner. Dette muliggjør da bruk av sekundære arkivkoder og mangefasettert klassifikasjon, f.eks. K-kodene som brukes i mange kommuner. I den konseptuelle modellen for Mappe er dette illustrert med en egen klasse. Men all arv av metadata kan kun gå gjennom den primære klassifikasjonen.
Klassene vil ofte legges inn før en Noark 5-løsning tas i bruk. Men det skal også være mulig for autoriserte brukere å opprette nye klasser. Det er særlig aktuelt ved objektbasert klassifikasjon. Klasser skal også kunne avsluttes, slik at det ikke lenger er mulig å knytte nye mapper til dem.
Arkiver uten klassifikasjon
Klassifikasjon skal være obligatorisk for sakarkiver. Men dersom den indre kjernen integreres med bestemte typer fagsystemer, bør det være mulig å opprette arkivstrukturer uten klasser og klassifikasjonssystemer. Det vil da kun være arkiv og arkivdel som strukturerer dokumentene på de øverste nivåene.
Konseptuell modell
for Klassifikasjonssystem <Konseptuell
modell for Klassifikasjonssystem / klasse>

Nøkkelord
Nøkkelord, stikkord eller nøkkelord for å gjenfinne dokumenter. Et nøkkelord sier noe om hva et objekt inneholder.
Bevaring og kassasjon
Koder som angir vedtak om kassasjon. Kassasjonsvedtak bestemmer hvilket arkivmateriale som skal fjernes fra arkivet, og tilintetgjøre dette.
(Se eget kapittel: Bevaring og kassasjon)
Klassifikasjonssystem
Klassifikasjonssystemet beskriver strukturen for mappene i én eller flere arkivdeler.
Klasse
Tabell over klasser tilhørende et klassifikasjonssystem. En klasse vil normalt bestå av en klasseID, som angir tillatte verdier i klassifikasjonssystemet og en klassetittel, som er en tekstlig beskrivelse av emnet.
Skjerming
Skjerming benyttes til å skjerme registrerte opplysninger eller enkeltdokumenter. Skjermingen
trer i kraft når en tilgangskode påføres den enkelte mappe, registrering eller det enkelte
dokument.
(Se eget kapittel: Sikkerhet og tilgangsstyring)
Metadata for Klassifikasjonssystem
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M001 |
systemID |
Obligatorisk |
En |
Avleveres |
|
M086 |
klassifikasjonstype |
Valgfri |
En |
Avleveres |
|
M020 |
tittel |
Obligatorisk |
En |
Avleveres |
|
M021 |
beskrivelse |
Valgfri |
En |
Avleveres |
|
M600 |
opprettetDato |
Obligatorisk |
En |
Avleveres |
|
M601 |
opprettetAv |
Obligatorisk |
En |
Avleveres |
|
M602 |
avsluttetDato |
Bet. oblig. |
En |
Avleveres |
|
M603 |
avsluttetAv |
Bet. oblig. |
En |
Avleveres |
|
M201 |
referanseBarn |
Obligatorisk |
Mange |
Avleveres |
Metadata for Klasse
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M001 |
systemID |
Obligatorisk |
En |
Avleveres |
|
M002 |
klasseID |
Obligatorisk |
En |
Avleveres |
|
M020 |
tittel |
Obligatorisk |
En |
Avleveres |
|
M021 |
beskrivelse |
Valgfri |
En |
Avleveres |
|
M023 |
nøkkelord |
Valgfri |
Mange |
Avleveres |
|
M600 |
opprettetDato |
Obligatorisk |
En |
Avleveres |
|
M601 |
opprettetAv |
Obligatorisk |
En |
Avleveres |
|
M602 |
avsluttetDato |
Bet. oblig. |
En |
Avleveres |
|
M603 |
avsluttetAv |
Bet. oblig. |
En |
Avleveres |
|
M200 |
referanseForelder |
Obligatorisk |
En |
Avleveres |
|
M201 |
referanseBarn |
Obligatorisk |
Mange |
Avleveres |
Krav til Klassifikasjonssystem og Klasse
|
Krav nr. |
Strukturelle krav |
Type |
Merknad |
|---|---|---|---|
|
|
Et Klassifikasjonssystem kan inndeles i ingen, en eller flere Klasser og en Klasse kan tilhøre kun ett Klassifikasjonssystem. |
O |
|
|
|
Et Klassifikasjonssystem kan inngå som preferert i ingen, en eller flere Arkivdeler |
O |
|
|
|
En Klasse kan inngå
i en hierarki av Klasser |
O |
|
|
|
En Klasse kan ha registrert ingen eller en Skjerming og en Skjerming kan inngå i ingen, en eller flere Klasser |
O |
|
|
|
En Klasse kan ha registrert ingen eller en Bevaring og kassasjon og en Bevaring og kassasjon kan inngå i ingen, en eller flere Klasser |
O |
|
|
|
En Klasse kan ha registrert ingen, ett eller flere Nøkkelord og et Nøkkelord skal kunne inngå i ingen, ett eller flere Klasser |
O |
|
|
|
Et Klasse kan inngå i ingen, en eller flere Mapper og en Mappe kan tilhøre kun en Klasse. |
O |
|
|
Krav nr. |
Funksjonelle krav |
Type |
Merknad |
|---|---|---|---|
|
|
Et klassifikasjonssystem skal kunne innregistreres basert på forskjellige klassifikasjonstyper.
Eksempel på verdier: Funksjonsbasert klassifikasjon / emnebasert klassifikasjon, frie-/kontrollerte nøkkelordlister, objektbasert klassifikasjon, hierarkisk klassifikasjon, (blanding av forskjellige typer) ... |
O |
|
|
|
Det skal være mulig å etablere hierarkiske klassifikasjonssystem for løsninger som inneholder saksdokumenter. Følgende er standard:
|
O |
|
|
|
Det bør være mulig å etablere fasetterte, hierarkiske klassifikasjonssystem for løsninger som inneholder saksdokumenter. Følgende er standard:
|
A |
|
|
|
Det skal være mulig å etablere endimensjonale klassifikasjonssystem. Følgende er standard:
|
O |
|
|
Krav nr. |
Funksjonelle krav til klasse |
Type |
Merknad |
|---|---|---|---|
|
|
Det skal finnes en tjeneste/funksjon for å ajourholde et hierarki av Klasser. |
O |
|
|
|
Det skal finnes en tjeneste/funksjon for å angi om en verdi av Klasse skal/skal ikke benyttes ved klassifikasjon av saker. |
O |
|
|
|
For at en Klasse skal kunne tilordnes en Mappe, må den ligge på nederste nivå i klassehierarkiet. |
O |
|
|
|
Dersom verdien i Klasse er registrert som avsluttet (avsluttetDato), skal det ikke være mulig å tilordne nye Mapper til Klassen. |
A |
|
|
|
opprettetDato, avsluttetDato og registrertAv bør kunne logges dersom klassifikasjonssystemet tillater at brukere opprettet og avslutter klasser innenfor systemet. |
O |
|
|
|
Dersom det er tillatt for brukere å opprette Klasser, skal navn på bruker (opprettet av) og dato for opprettelse logges. |
O |
|
I forhold til hovedstrukturen er mappenivået i modellen bygd ut ved hjelp av spesialisering. Derfor er navn på de konseptuelle klassene i dette nivået definert mer etter sitt bruksområde.
En mappe grupperer dokumenter som på en eller annen måte hører sammen. Helst bør dokumentene i en mappe utgjøre en instans (dvs. en utførelse) av en aktivitet, med en definert begynnelse og slutt. Et eksempel på dette er enkeltsaker i et sakarkiv. En slik sak kan f.eks. omhandle et spørsmål som er til behandling, og dokumentene i saken vil da utgjøre behandlingsforløpet for dette spørsmålet. Slike saker vil ofte starte med en søknad eller henvendelse utenfra, og ende med et vedtak.
Men av og til er det naturlig å gruppere dokumentene i en mappe etter andre kriterier. I noen tilfeller legges alle dokumenter som omhandler et objekt i én mappe, f.eks. personalmapper. Slike mapper kalles også dossiermapper. I andre tilfeller kan det være naturlig å legge alle dokumentene som tilhører samme prosess (dvs. gjentakelse av samme type aktivitet) i samme mappe. Dette vil ofte dreie seg om svært rutinemessige aktiviteter, hvor hver aktivitet kanskje bare skaper ett dokument. I sakarkiver er dette kjent som samlemapper eller samlesaker.
Måten innholdet i en mappe grupperes på, vil avhenge av klassifikasjonssystemet. En trenger kanskje ikke egne personalmapper dersom klassifikasjonssystemet er objektbasert. Dersom mappene grupperes på objekter eller prosesser, vil ofte klassifikasjonssystemet være på et overordnet nivå. Dokumentene som skapes i et bestemt prosjekt kan samles i en prosjektmappe (med undermapper), men det er sannsynligvis bedre å definere prosjektet i klassifikasjonssystemet og gruppere mappene etter instanser av aktiviteter.
Mapper skal ha en egen identifikasjon som er unik innenfor et og samme arkiv. Noark 5 stiller ingen krav til hvordan denne koden skal se ut. Når det gjelder saksmapper, anbefales det at en forsetter med samme mal som i tidligere versjoner av Noark-standarden - dvs. en kombinasjon av årstallet da mappen ble opprettet og et fortløpende seksjonsnummer innefor året, f.eks. 2008/12345.
Mappetyper
Noark 5 åpner for en fleksibel bruk av mapper. Grunnen til dette er at det skal være mulig å innpasse dokumenter som mottas og skapes i de fleste typer fagsystemer i den indre kjernen. Dette må i en del tilfeller gjøres på en enklere måte enn det som var mulig i Noark 4.
En sak i Noark 4 utgjør en bestemt mappetype i Noark 5. Dersom et system basert på Noark 5 bare skal brukes for sakarkiver, er det ikke noe i veien for å bruke begrepet "sak" i alle grensesnitt mot brukerne, på samme måte som en er vant til fra Noark 4. Men i denne standarden er mappe det generelle begrepet for arkivenheten på dette nivået.
(Mappe kan dessuten brukes som oversettelse av det tilsvarende begrepet i Moreq2 - File).
Basismappe
Utgangspunktet for alle mapper i Noark 5 er en basismappe. Denne inneholder de grunnleggende metadata som må være med som et minimum. Men det er heller ikke alle metadata i en basismappe som er obligatoriske. Metadata om bevaring/kassasjon og skjerming hører til i basismappen, men er ikke obligatoriske dersom det ikke foreligger bevarings- og kassasjonsvedtak, eller metadata ikke skal skjermes. En basismappe kan danne utgangspunkt for en mappe i et fagsystem. En del fagsystemer vil nok trenge ekstra metadata i tillegg til basismappen, men i denne versjonen av Noark 5 blir bare basismappen og saksmappen spesifisert.
Undermapper
Det skal være mulig å opprette et mappehierarki av undermapper (spesifisert som egenrelasjon i Baismappen). I de fleste tilfeller vil ett nivå med undermapper være nok, men Noark 5 åpner også for flere nivåer med slike mapper. Dette vil først og fremst være aktuelt for fagsystemer. Innholdet i undermapper vil vanligvis grupperes etter innhold, og ikke etter aktiviteter. Mange fagsystemer grupperer dokumenter etter type, f.eks. fakturaer, ordrer, korrespondanse osv. I en mappe med møtedokumenter, kan de f.eks. grupperes etter delegerte saker, referatsaker, interpellasjoner osv.
Arv fra en Klasse vil alltid gå til mappen på det øverste nivået.
Konseptuell modell
for Mappestrukturen <Konseptuell
modell for Mappenivået>

Saksmappe
I denne versjonen av Noark 5 er det i tillegg til Basismappe definert en spesialisering kalt Saksmappe, som tilsvarer en ’sak’ i Noark 4. Saksmappen skal inneholde metadata fra basismappen i tillegg til egne metadata. En saksmappe er bakoverkompatibel med en sak i Noark 4, men har en del nye metadata som er valgfrie. For saksarkiver er det obligatorisk å bruke en saksmappe.
Det er mulig å lage en rekke andre spesialiserte mappetyper med utgangspunkt i saksmappen. Mange av disse er kjent også fra systemer basert på Noark 4: ansettelsessak, byggesak, møte/utvalgssaker, delingssak, plansak, landbrukssak osv.
Noen av disse sakstypene vil trenge ekstra metadata og vil i de kommende versjoner av Noark 5 bli spesifisert som spesialiseringer av Basismappe.
Møtemappe
Modul for møtebehandling dekker en rekke funksjoner knyttet til saksbehandling i kollegiale organer som styrer, råd, utvalg m.v. Møtebehandling krever en del ekstra funksjonalitet og metadata (spesialisering av Basismappe) og dette er dokumentert i eget kapittel: Møte- og utvalgsbehandling.
Administrativ enhet
Organisatorisk enhet, f.eks. etat, avdeling, seksjon, sekretariat, sektoradministrasjon eller kontor. Alle Saksmapper i arkivmodulen bør knyttes opp mot en administrativ enhet.
(Se eget kapittel: Administrativ struktur).
Arkivdel
(Se eget kapittel: Arkiv og arkivdel).
Basismappe (Mappe)
I denne detaljerte skissen av den konseptuelle modellen for mappenivået, går vi bort fra det generelle ’mappe-begrepet’ og opererer med spesifikke navn/spesialiseringer av mappetypene.
Utgangspunktet for alle mapper i Noark 5 er en basismappe. En Mappe utgjør en Sak i Noark 4 og en File i Moreq 2. Basismappen inneholder de grunnleggende metadata som må være med som et minimum for å håndtere strukturen.
Bevaring og kassasjon
(Se eget kapittel: Bevaring og kassasjon).
Nøkkelord
Nøkkelord, stikkord eller nøkkelord for å gjenfinne dokumenter. Et nøkkelord sier noe om hva et objekt inneholder.
(Se eget kapittel: Nøkkelord).
Journalenhet
Journalenhet er navnet på den organisatoriske enheten som har ansvaret for organets journalføring. Andre navn som brukes er journalførende enhet. Etter hvert som digitale arkiv brer om seg, vil det kanskje bli mindre behov for å registrere journalenhet. Dette vil derfor ikke lenger være obligatorisk i Noark 5. Men det skal fremdeles være mulig å sette journalenhet på en mappe eller en registrering, og dette skal inngå som metadata ved avlevering.
Klasse
(Se eget kapittel: Klassifisering).
Sekundærklassering
Inneholder én eller flere dekkende arkivkoder eller ordningsverdier fra klassifikasjonssystemet (arkivnøkkelen) for et saksdokument.
Møtemappe
(Se eget kapittel: Møte- og utvalgsbehandling)
Forenklet registrering
(Se eget kapittel: Registrering).
Presedens
(Se eget kapittel under Saksbehandling: Presedens).
Sakspart
(Se eget kapittel under Saksbehandling: Sakspart).
Saksmappe
Saksmappe er en spesialisering av Basismappe. En Saksmappe inneholder metadata vedrørende saker.
Skjerming
(Se eget kapittel: Sikkerhet og tilgangskontroll (Skjerming))
Metadata for Basismappe
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M001 |
systemID |
Obligatorisk |
En |
Avleveres |
|
M003 |
mappeID |
Obligatorisk |
En |
Avleveres |
|
M080 |
mappetype |
Obligatorisk |
En |
Avleveres |
|
M020 |
tittel |
Obligatorisk |
En |
Avleveres |
|
M025 |
offentligTittel |
Bet. oblig. |
En |
Avleveres |
|
M021 |
beskrivelse |
Valgfri |
En |
Avleveres |
|
M022 |
nøkkelord |
Valgfri |
Mange |
Avleveres |
|
M300 |
dokumentmedium |
Valgfri |
En |
Avleveres |
|
M301 |
oppbevaringssted |
Valgfri |
En |
|
|
M600 |
opprettetDato |
Obligatorisk |
En |
Avleveres |
|
M601 |
opprettetAv |
Obligatorisk |
En |
Avleveres |
|
M602 |
avsluttetDato |
Bet. oblig. |
En |
Avleveres |
|
M603 |
avsluttetAv |
Bet. oblig. |
En |
Avleveres |
|
M200 |
referanseForelder |
Obligatorisk |
En |
Avleveres |
|
M201 |
referanseBarn |
Obligatorisk |
Mange |
Avleveres |
|
M208 |
referanseArkivdel |
Obligatorisk |
En |
Avleveres |
Merknad
Dette er metadata som er felles for alle mappetyper.
Metadata for Saksmappe
Saksmappe er en utvidelse av Basismappe slik at metadata for basismappe inngår i saksmappe, følgende metadata kommer i tillegg:
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M100 |
saksdato |
Obligatorisk |
En |
Avlevers |
|
M305 |
administrativEnhet |
Obligatorisk |
En |
Avleveres |
|
M306 |
saksansvarlig |
Obligatorisk |
En |
Avleveres |
|
M308 |
journalenhet |
Valgfri |
En |
Avleveres |
|
M052 |
saksstatus |
Bet. oblig. |
En |
|
|
M106 |
utlåntDato |
Valgfri |
En |
|
|
M309 |
utlåntTil |
Valgfri |
En |
|
|
M209 |
referanseSekundærKlassifikasjon |
Valgfri |
Mange |
Avleveres |
Metadata Sakspart
Sakspart er definert i eget kapittel; Se Saksbehandling, Sakspart
Krav til Mappestrukturen
Merknad: Når det skrives ’Mappe’ gjelder kravet for Basismappe samt alle spesialiseringer av Basismappe.
|
Krav nr. |
Strukturelle krav til Mappe / mappenivået |
Type |
Merknad |
|---|---|---|---|
|
|
En mappe skal kunne være av forskjellig type. Dette er i den konseptuelle modellen løst gjennom spesialisering. |
O |
|
|
|
En Basismappe skal tilhøre en arkivdel og en Arkivdel kan innehold ingen, en eller flere Basismapper. |
O |
|
|
|
En Basismappe skal være klassifisert med en Klasse og en Klasse kan klassifisere ingen, en eller flere Basismapper. |
O |
|
|
|
En Basismappe skal kunne tilhøre ingen eller en klassifisering (Klasse) og en Klasse kan inngå i ingen, en eller flere Basismapper. |
O |
|
|
|
En Basismappe bør kunne inngå i andre Basismapper i et hierarki. Disse er kalt undermapper. (skissert i modellen vha egenrelasjon). |
A |
|
|
|
Et Basismappe skal kunne bestå av ingen, en eller flere Registreringer og en Registrering kan inngå i (kun) en Basismappe. |
O |
|
|
|
Dersom en Basismappe er registrert som avsluttet (avsluttetDato) skal det ikke være mulig å legge flere Registreringer til Mappen. |
O |
|
Saksmappe
|
|
En Basismappe skal kunne utvides til en Saksmappe.
For et sakarkiv skal det kunne benyttes en spesialisert mappetype: Saksmappe. En spesialisert klasse kan betegnes som en utvidelse av hovedklassen. |
O |
|
|
|
En Saksmappe skal kunne identifiseres internt i systemet med en kombinasjon av saksår og et forløpende sekvensnummer for saksmappene innenfor året. |
O |
|
|
|
En Saksmappe skal kunne ha registrert ingen, en eller flere Sekundærklassering og en Sekundærklassering tilhører kun en Saksmappe og kun en Klasse. |
O |
|
|
|
En Saksmappe skal kunne ha registrert ingen eller en Journalenhet og en Journalenhet kan inngå i ingen, en eller flere Saksmapper. |
O |
|
|
|
En Saksmappe skal kunne ha registrert ingen eller en Administrativ enhet og en Administrativ enhet kan inngå i ingen, en eller flere Saksmapper. |
O |
|
|
|
En Saksmappe skal kunne inneha ingen, en eller flere Part I Sak og en Part I Sak skal alltid tilhøre en Saksmappe. |
O |
|
|
Krav nr. |
Funksjonelle krav til Mappe /mappenivået |
Type |
Merknad |
|---|---|---|---|
|
|
Dersom det er angitt et primært klassifikasjonssystem for Arkivdel, skal alle Mapper i arkivdelen ha verdier fra dette klassifikasjonssystemet som primær klasse. |
O |
|
|
|
Det skal finnes en tjeneste/funksjon for å ajourholde sekundærklassifikasjoner mot en Saksmappe (referanseSekundær Klassifikasjon) |
O |
|
|
|
Det skal finnes en tjeneste/funksjon for å ajourholde Journalenhet på en Saksmappe. |
O |
|
|
|
Det skal finnes en tjeneste/funksjon for å ajourholde Administrativ enhet på en Saksmappe. |
O |
|
|
|
Det skal finnes en tjeneste/funksjon for å ajourholde Sakspart i tilknytning til en Saksmappe. |
O |
|
|
|
Det skal finnes en tjeneste/funksjon for å legge opp og ajourholde undermapper for en Basismappe (mappehierarki). |
O |
|
Metadata Møtemappe
Møtemappe er definert i eget kapittel; Se Møte- og utvalgsbehandling.
En aktivitet kan deles opp i flere trinn som vi kaller transaksjoner. En transaksjon innebærer strengt tatt at minst to personer eller enheter må være involvert, og det vil kanskje ikke alltid være tilfelle. Vi bruker likevel begrepet transaksjon generelt for alle trinn en aktivitet kan deles opp i. Det er transaksjoner som genererer arkivdokumenter, og arkivdokumentet er dokumentasjon på at transaksjonen er utført.
Det er ikke slik at alle trinn i et aktivitetsforløp nødvendigvis behøver dokumenteres. I offentlig korrespondansebasert saksbehandling, vil typiske transaksjoner være: en søknad kommer inn, saksbehandler vurderer søknaden og skriver forslag til et vedtak, vedtaket godkjennes av leder og et svarbrev sendes ut. I slike tilfeller må i alle fall den første og siste transaksjonen dokumenteres. Det er som oftest nødvendig å dokumentere saksbehandlerens overveielser underveis til vedtaket.
Ved utviklingen av fagsystemer for standardisert saksbehandling, er det viktig at de forskjellige transaksjonene identifiseres og at de sentrale transaksjonene genererer dokumenter som kan fanges opp av den indre kjernen.
Registreringer skal ha en egen identifikasjon som er unik innenfor et og samme arkiv. Noark 5 stiller ingen krav til hvordan denne koden skal se ut. Når det gjelder journalposter, anbefales det at en forsetter med samme mal som i tidligere versjoner av Noark-standarden. Identifikasjonen fra mappenivået arves, og registreringene nummereres fortløpende innenfor mappen, f.eks. 2008/ 12345-1.
Registreringstyper
På samme måte som Noark 5 er fleksibel når det gjelder mappenivået, er standarden også fleksibel når det gjelder registreringsnivået. Det er ikke alle fagsystemer som trenger like mye metadata på dette siste nivået.
Basisregistrering
Det blir spesifisert en egen registreringstype kalt basisregistrering. Denne inneholder de grunnleggende metadata som må være med som et minimum i alle registreringer, og som kan brukes som et utgangspunkt for fagsystemer som ikke inneholder korrespondanse. Det er ikke alle metadata i en basisregistrering som er obligatoriske. Metadata om bevaring/kassasjon og skjerming hører til i basisregistrering, men er ikke obligatoriske dersom det ikke foreligger bevarings- og kassasjonsvedtak, eller metadata eller dokumenter ikke skal skjermes. En basismappe kan danne utgangspunkt for andre mappetyper for spesialiserte fagsystemer.
I fysiske sakarkiver har det vært vanlig å legge dokumenter som ikke er journalføringspliktige - men som likevel er arkivpliktige (ikke underlagt arkivbegrensning) - inn i saksomslaget uten at dette ble registrert i journalen. Tilsvarende funksjonalitet bør også være mulig i et elektronisk arkivsystem. Her må dokumentene nødvendigvis bli registrert, men dette skal skje på en automatisk måte og med minst mulig metadata. Denne typen dokumenter skal ikke kunne søkes fram etter innhold, og de skal heller ikke inngå i den ordinære identifikasjonen (nummereringen) av journalposter. Men de skal kunne inngå i avleveringsuttrekk dersom de er bevaringsverdige, og det må være mulig å skjerme dem internt. I Noark 4 ble dette kalt "loggede dokumenter". I Noark 5 spesifiseres dette som en egen registreringstype kalt forenklet registrering. En forenklet registrering inneholder enda færre metadata enn en basisregistrering.
Journalpost
En journalpost i Noark 4 utgjør en bestemt registreringstype i Noark 5. En journalpost representer en "innføring i journalen". Journalen er en kronologisk fortegnelse over inn- og utgående dokumenter, og eventuelt også interne dokumenter knyttet til saksbehandlingen. En registrering representer en generell "innføring" i alle typer arkivsystemer, også de som ikke inneholder korrespondansebaserte dokumenter.
Registreringstypen journalpost er obligatorisk for sakarkiver. Alle journalføringspliktige dokumenter i offentlig forvaltning skal registreres som journalposter og inngå i et sakarkiv.
Dersom et system basert på Noark 5 bare skal brukes for sakarkiver, er det ikke noe i veien for å fortsette og bruke begrepet "journalpost" i alle grensesnitt mot brukerne, på samme måte som en er vant til fra Noark 4. Men i denne standarden brukes registrering som en generell betegnelse på arkivenheter som dokumenter transaksjoner. (Dessuten er registrering beslektet med det tilsvarende begrepet i Moreq - Record).
Konseptuell modell
for Registreringsnivået <Konseptuell
modell for Registreringsnivået>

Metadata for Forenklet registrering
Dette er metadata som er felles for alle registreringstyper.
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M001 |
systemID |
Obligatorisk |
En |
Avleveres |
|
M081 |
registreringstype |
Obligatorisk |
En |
Avleveres |
|
M600 |
opprettetDato |
Obligatorisk |
En |
Avleveres |
|
M601 |
opprettetAv |
Obligatorisk |
En |
Avleveres |
|
M604 |
arkivertDato |
Obligatorisk |
En |
Avleveres |
|
M605 |
arkivertAv |
Obligatorisk |
En |
Avleveres |
|
M200 |
referanseForelder |
Obligatorisk |
En |
Avleveres |
|
M208 |
referanseArkivdel |
Bet. oblig. |
En |
Avleveres |
|
M207 |
referanseDokumentbeskrivelse |
Bet. oblig. |
Mange |
Avleveres |
|
M216 |
referanseDokumentobjekt |
Bet. oblig. |
Mange |
Avleveres |
Merknad
referanseDokumentbeskrivelse må brukes dersom registreringen består av mer en ett enkeltdokument.
ReferanseArkivdel kan brukes for å styre bevaring og kassasjon av bestemte registreringstyper.
ReferanseDokumentobjekt betyr at arkivenheten dokumentbeskrivelse utelates. En slik struktur er bare aktuelt i fagsystemer hvor alle registreringene kun består av ett dokument, og hvor et og samme dokument bare er knyttet til en registrering.
Tilleggsmetadata for basisregistrering
I tillegg til metadataene fra Forenklet registrering, skal en basisregistrering inneholde følgende:
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M004 |
registreringsID |
Obligatorisk |
En |
Avleveres |
|
M020 |
tittel |
Obligatorisk |
En |
Avleveres |
|
M025 |
offentligTittel |
Bet. oblig. |
En |
Avleveres |
|
M021 |
beskrivelse |
Valgfri |
En |
Avleveres |
|
M022 |
nøkkelord |
Valgfri |
Mange |
Avleveres |
|
M024 |
forfatter |
Obligatorisk |
Mange |
Avleveres |
|
M300 |
dokumentmedium |
Valgfri |
En |
Avleveres |
|
M301 |
oppbevaringssted |
Valgfri |
En |
|
Tilleggsmetadata for journalpost
I tillegg til metadata fra forenklet registrering og basisregistrering, skal en journalpost inneholde følgende:
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M009 |
løpenummer |
Obligatorisk |
En |
Avleveres |
|
M082 |
journalposttype |
Obligatorisk |
En |
Avleveres |
|
M053 |
journalstatus |
Bet. oblig. |
En |
|
|
M101 |
journaldato |
Obligatorisk |
En |
Avleveres |
|
M103 |
dokumentetsDato |
Valgfri |
En |
Avleveres |
|
M104 |
mottattDato |
Valgfri |
En |
Avleveres |
|
M105 |
sendtDato |
Valgfri |
En |
Avleveres |
|
M109 |
forfallsdato |
Valgfri |
En |
|
|
M110 |
offentlighetsvurdertDato |
Valgfri |
En |
|
|
M305 |
antallVedlegg |
Valgfri |
En |
Avleveres |
|
M106 |
utlåntDato |
Valgfri |
En |
|
|
M309 |
utlåntTil |
Valgfri |
En |
|
Metadata om Korrespondansepart
Metadata for korrespondansepart skal grupperes inn i metadata for journalpost. Korrespondansepart er obligatorisk, og kan forekomme en eller flere ganger i en journalpost.
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M087 |
korrespondanseparttype |
Obligatorisk |
En |
Avleveres |
|
M400 |
korrespondansepartNavn |
Obligatorisk |
En |
Avleveres |
|
M406 |
postadresse |
Valgfri |
En |
Avleveres |
|
M407 |
postnummer |
Valgfri |
En |
Avleveres |
|
M408 |
poststed |
Valgfri |
En |
Avleveres |
|
M409 |
utenlandsadresse |
Valgfri |
En |
Avleveres |
|
M410 |
epostadresse |
Valgfri |
En |
Avleveres |
|
M411 |
telefonnummer |
Valgfri |
En |
Avleveres |
|
M412 |
kontaktperson |
Valgfri |
En |
Avleveres |
Metadata for saksansvar
Metadata for saksansvar skal grupperes inn i metadata for journalpost. Ved organinterne dokumenter som skal følges opp, er det behov for å gruppere informasjon om saksansvar fordi det kan forekomme flere ganger. Saksansvar er obligatorisk, og kan altså forekomme en eller flere ganger i en journalpost.
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M305 |
administrativEnhet |
Obligatorisk |
En |
Avleveres |
|
M307 |
saksbehandler |
Obligatorisk |
En |
Avleveres |
|
M308 |
journalenhet |
Valgfri |
En |
Avleveres |
Metadata for avskrivning
Metadata for avskrivning inngår i metadata for journalpost.
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M614 |
avskrivningsdato |
Bet. oblig. |
En |
Avleveres |
|
M615 |
avskrevetAv |
Bet. oblig. |
En |
Avleveres |
|
M616 |
avskrivningsmåte |
Bet. oblig. |
En |
Avleveres |
|
M214 |
referanseAvskriverJournalpost |
Bet. oblig. |
En |
Avleveres |
|
M215 |
referanseAvskrivesAvJournalpost |
Bet. oblig. |
En |
Avleveres |
Metadata for elektronisk kommunikasjon
Metadata for elektronisk kommunikasjon inngår i metadata for journalpost
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M506 |
sikkerhetsnivåElektroniskSignatur |
Bet. oblig. |
En |
Avleveres |
|
M507 |
elektroniskSignaturVerifisert |
Bet. oblig. |
En |
Avleveres |
|
M619 |
verifisertDato |
Bet. oblig. |
En |
Avleveres |
|
M620 |
verfisertAv |
Bet. oblig. |
En |
Avleveres |
Metadata for Dokumentflyt er dokumentert i kapittel 6.6. Dokumentflyt
Krav til Registreringsnivået
|
Krav nr. |
Strukturelle krav til Registreringsnivået |
Type |
Merknad |
|---|---|---|---|
|
|
En Forenklet registrering skal kunne inndeles i forskjellige typer.
Merknad: Dette er i den konseptuelle modellen løst gjennom spesialisering, altså utvidelser for hver type. |
O |
|
|
|
Hvis Mappenivået er benyttet, skal en Forenklet registrering tilhøre (kun) en Basismappe og en Basismappe kan innehold ingen, en eller flere Forenklet registrering. |
O |
|
|
|
Hvis Mappenivået ikke er benyttet, skal Forenklet registrering tilhøre (kun) ett Delarkiv og ett Delarkiv kan innehold ingen, en eller flere Forenklet registrering.
Merknad: Dette er skissert i modellen ved hjelp av ENTEN / ELLER beskrakning. |
O |
|
|
|
Hvis Mappenivået ikke er benyttet, skal Forenklet registrering tilhøre kun en Klasse og en Klasse kan inngå i ingen, en eller flere Forenklet registrering.
Merknad: Dette er skissert i modellen ved hjelp av ENTEN / ELLER beskrakning. |
O |
|
|
|
En Forenklet registrering skal kunne inneholde ingen, en eller flere Dokumentbeskrivelser og en Dokumentbeskrivelse skal inngå i en eller flere Forenklet registrering. |
O |
|
|
|
En Forenklet registrering skal kunne utvides til en Basisregistrering. |
O |
|
|
|
En Basisregistrering skal kunne utvides til en Journalpost. |
O |
|
|
|
En journalpost skal kunne defineres til å være av forskjellig type (”Noark dokumenttype”). |
O |
|
|
|
En Journalpost skal ha registrert en Statusverdi og en Statusverdi skal kunne inngå i ingen, en eller flere Journalposter. |
O |
|
|
|
En Journalpost skal ha registrert en Saksansvar (Administrativ enhet og Journalenhet) og en Saksansvar skal kunne inngå i ingen, en eller flere Journalposter. |
O |
|
|
|
En Journalpost skal ha registrert en Korrespondansepart og en Korrespondansepart skal inngå i (kun) en Journalpost. |
O |
|
|
Krav nr. |
Funksjonelle krav til Registreringsnivået |
Type |
Merknad |
|---|---|---|---|
|
|
Det skal finnes en tjeneste/funksjon for å ajourholde Journalenhet på en Registrering (Journalpost). |
O |
|
|
|
Det skal finnes en tjeneste/funksjon for å ajourholde Administrativ enhet på en Registrering (Journalpost). |
O |
|
|
|
Det skal finnes en tjeneste/funksjon for å ajourholde Korrespondansepart på en Journalpost. |
O |
|
Dokumentbeskrivelse
Et dokument er et objekt som kan behandles som en enhet, uavhengig av hva det inneholder. For å understreke dette kan vi bruke begrepet enkeltdokument. En registrering som dokumenter en transaksjon, vil vanligvis bestå av bare ett enkeltdokument. Dokumentbeskrivelsen inneholder metadata for enkeltdokumenter.
Men i noen tilfeller kan registreringen bestå av flere dokumenter. Det vanligste er et hoveddokument med vedlegg, hvor hoveddokumentet og hvert av vedleggene utgjør hvert sitt enkeltdokument.
I brukergrensesnittet bør det være mulig å skjule nivået dokumentbeskrivelse. Fagsystemer som aldri vil inneholde registreringer med mer enn ett enkeltdokument behøver ikke nivået i det hele tatt. I modellen er dette løst ved å legge inn en direkte referanse mellom Registrering og Dokumentobjekt.
Kassasjon
Det skal være mulig å foreta bevaring og kassasjon også på dette nivået, f.eks. med utgangspunkt i dokumenttyper. Det skal også være mulig å skjerme enkeltdokumenter, f.eks. kan hoveddokumentet være offentlig, mens vedlegget skjermes.
Noark 4
I Noark 4 var det ikke tillatt at et dokument ble knyttet til flere journalposter som hoved-dokument (men det kunne være hoveddokument i en journalpost og vedlegg i en annen). Denne begrensningen er opphevet i Noark 5.
Dokumentobjekt
Dokumentobjekt er det laveste metadatanivået i arkivstrukturen. Et dokumentobjekt skal referere til en - og kun en - fil. Denne fila inneholder en byte stream som representerer et elektronisk dokument. Dersom dokumentet er arkivert i flere versjoner, må vi ha et dokumentobjekt for hver versjon. Hver versjon av dokumentet kan dessuten lagres i flere forskjellige formater, og da må det i tillegg opprettes egne dokumentobjekter for hvert format. I noen tilfeller kan det også være aktuelt å lage varianter av enkelte dokumenter. Den mest vanlige varianten vil være et "sladdet" dokument hvor taushetsbelagt informasjon er fjernet slik at varianten kan være offentlig tilgjengelig. Dokumentobjektet vil inneholde mer tekniske metadata enn de andre arkivenhetene.
Det som fremstår som et dokument (en avgrenset enhet) for brukerne, kan være lagret som flere filer i systemet. Et vanlig eksempel er et HTML-dokument med tilknyttet grafikk, hvor de enkelte grafikkelementene er lagret som separate filer. Det er fullt tillatt å lagre dokumenter på denne måten i en aktiv løsning basert på Noark 5. Men ved eksport for avlevering må det enkelte dokument (dvs. versjoner og varianter av dokumenter) være representert som en enkelt fil. Dette stiller krav til hvilke avleveringsformat som kan brukes.
Konseptuell modell for Dokumentbeskrivelse og Dokumentobjekt
<Konseptuell
modell for Dokumentbeskrivelse og Dokumentobjekt>
Metadata for Dokumentbeskrivelse
En dokumentbeskrivelse kan være knyttet til mer enn en registrering, og ved avlevering vil metadata bli duplisert for hver tilknytning.
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avlevere |
|
M001 |
systemID |
Obligatorisk |
En |
Avleveres |
|
M083 |
dokumenttype |
Obligatorisk |
En |
Avleveres |
|
M054 |
dokumentstatus |
Valgfri |
En |
|
|
M020 |
tittel |
Valgfri |
En |
Avleveres |
|
M021 |
beskrivelse |
Valgfri |
En |
Avleveres |
|
M024 |
forfatter |
Valgfri |
En |
Avleveres |
|
M600 |
opprettetDato |
Obligatorisk |
En |
Avleveres |
|
M601 |
opprettetAv |
Obligatorisk |
En |
Avleveres |
|
M300 |
dokumentmedium |
Valgfri |
En |
Avleveres |
|
M301 |
oppbevaringssted |
Valgfri |
En |
|
|
M216 |
referanseDokumentobjekt |
Obligatorisk |
Mange |
Avlevers |
Bevaring og kassasjon mangler i Noark 4 for dette nivået, men er tatt med her fordi kassasjon f.eks. bør kunne knyttes til dokumenttype.
Metadata for sletting av dokumenter
Metadata for sletting av dokumenter skal grupperes inn i metadata for dokumentbeskrivelse dersom sletting skyldes kassasjon. Ved sletting av versjoner, produksjonsformat og varianter skal metadata grupperes inn i metadata for dokumentbeskrivelse. (Dersom sletting også omfatter metadata, kan det grupperes inn som metadata for arkivdel. Alle arkivenheter som er underordnet arkivdelen, vil da være slettet. )
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M613 |
slettetDato |
Bet. oblig. |
En |
Avleveres |
|
M614 |
slettetAv |
Bet. oblig |
En |
Avleveres |
Dokumentlink
Metadata for tilknytning mellom Registrering og Dokumentobjekt. Fordi et dokument skal kunne knyttes til mer enn en registrering, er det nødvendig med følgende ekstra metadata. Ved avleveringsuttrekk vil disse metadata slås sammen med dokumentbeskrivelsen. Metadata for dokumentbeskrivelse vil i avleveringsuttrekket dupliseres for hver gang dokumentbeskrivelsen forekommer i uttrekket.
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M206 |
referanseRegistrering |
Obligatorisk |
En |
Avleveres |
|
M217 |
tilknyttetRegistreringSom |
Obligatorisk |
En |
Avleveres |
|
M007 |
dokumentnummer |
Obligatorisk |
En |
Avleveres |
|
M620 |
tilknyttetDato |
Obligatorisk |
En |
Avleveres |
|
M621 |
tilknyttetAv |
Obligatorisk |
En |
Avleveres |
Merknad
Her tas det ikke med noen referanse til dokumentbeskrivelsen. Men hvis tilknytningen mellom registrering og dokumentbeskrivelse realiseres med en egen tabell for dokumentlink i databasen, må selvfølgelig denne referansen tas med.
Metadata for Dokumentobjekt
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M001 |
systemID |
Obligatorisk |
En |
Avleveres |
|
M005 |
versjonsnummer |
Obligatorisk |
En |
Avleveres |
|
M700 |
variantformat |
Obligatorisk |
En |
Avleveres |
|
M701 |
format |
Obligatorisk |
En |
Avleveres |
|
M702 |
formatDetaljer |
Valgfri |
En |
Avleveres |
|
M600 |
opprettetDato |
|
|
|
|
M601 |
opprettetAv |
|
|
|
|
M207 |
referanseDokumentbeskrivelse |
Bet. oblig. |
En |
Avleveres |
|
M206 |
referanseRegistrering |
Bet. oblig. |
En |
Avleveres |
|
M218 |
referanseDokumentfil |
Obligatorisk |
En |
Avleveres |
|
M705 |
sjekksum |
Obligatorisk |
En |
Avleveres |
|
M706 |
sjekksumAlgoritme |
Obligatorisk |
En |
Avleveres |
|
M707 |
filstørrelse |
Obligatorisk |
En |
Avleveres |
Merknad
Referansen til registrering vil bare være aktuelt ved fagsystemer hvor en registrering alltid bare inneholder ett dokument, og hvor ett dokument bare kan være knyttet til en registrering.
Metadata for konvertering
Metadata for konvertering til godkjent arkivformat skal grupperes i metadata for dokumentobjekt.
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M615 |
konvertertDato |
Bet. oblig. |
En |
Avleveres |
|
M616 |
konvertertAv |
Bet. oblig |
En |
Avleveres |
|
M703 |
tidligereFormat |
Bet. oblig |
En |
Avleveres |
|
M704 |
tidligereFormatDetaljer |
Bet. oblig |
En |
Avleveres |
Krav til Dokumentbeskrivelse og Dokumentobjekt
|
Krav nr. |
Strukturelle krav til Dokumentnivået |
Type |
Merknad |
|
|---|---|---|---|---|
|
|
En Forenklet registrering skal kunne bestå av ingen, ett eller flere Dokumentbeskrivelser og en Dokumentbeskrivelse skal inngå i ett eller flere Forenklet registrering.
Disse registreringene kan være tilknyttet mapper som tilhører forskjellige arkivdeler og arkiver. |
O |
|
|
|
|
Dokumentbeskrivelse skal kunne inndeles i forskjellige typer.
Merknad: Dette er i den konseptuelle modellen løst gjennom spesialisering, altså utvidelser for hver type. |
O |
|
|
|
|
En Dokumentbeskrivelse skal ha ett eller flere Dokumentobjekt og et Dokumentobjekt kan inngå i ingen eller en Dokumentbeskrivelse. |
O |
|
|
|
|
Hvis Dokumentbeskrivelse ikke er benyttet, skal Dokumentobjekt tilhøre (kun) en Forenklet registrering og en Forenklet registrering kan innehold ingen, en eller flere Dokumentobjekt.
Merknad: Dette er skissert i modellen ved hjelp av ENTEN / ELLER beskrakning. |
O |
|
|
|
|
En dokumentbeskrivelse for et fysisk dokument (f.eks. papir) skal kunne ha referanse til oppbevaringssted for dokumentet. |
O |
|
|
|
|
Et Dokumentobjekt som er tilknyttet samme dokumentbeskrivelse skal kunne referere til forskjellige versjoner av dokumentet |
O |
|
|
|
|
Et Dokumentobjekt som er tilknyttet samme dokumentbeskrivelse skal kunne referere til forskjellige varianter av et dokument. |
O |
|
|
|
|
Et Dokumentobjekt som er tilknyttet samme dokumentbeskrivelse skal kunne referere til samme dokument lagret i forskjellig format. |
O |
|
|
|
Krav nr. |
Funksjonelle krav til Dokumentnivået |
Type |
Merknad |
|---|---|---|---|
|
|
Det skal finnes funksjoner som ved opprettelse av nytt dokument skal knytte dette til en Dokumentbeskrivelse. |
O |
|
|
|
Det skal være mulig å opprette en Dokumentbeskrivelse uten elektronisk dokument. |
O |
|
|
|
Det skal finnes en funksjon/tjeneste for å arkivere en eller flere versjoner/varianter/formater av et dokument. |
O |
|
|
|
Det skal ikke være mulig å slette et hoveddokument. |
O |
|
Det skal være mulig å føye ett eller flere nøkkelord til en klasse, en basismappe eller en basisregistrering. Nøkkelord må ikke blandes sammen med fasettert klassifikasjon basert på emneord. Mens klassifikasjonen skal gi informasjon om dokumentets kontekst (hvilken funksjon som har skapt dokumentet), skal nøkkelordene si noe om dokumentets innhold. Hensikten med nøkkelord er å forbedre søkemulighetene for en klasse, mappe eller registrering.
Konseptuell modell
for Nøkkelord <Konseptuell
modell for Nøkkelord>
Nøkkelord
Nøkkelord eller stikkord for å gjenfinne dokumenter. Et nøkkelord sier noe om hva et objekt inneholder.
Metadata for Nøkkelord
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avlevere |
|
M022 |
nøkkelord |
Obligatorisk |
En |
|
Krav til Nøkkelord
|
Krav nr. |
Strukturelle krav til Nøkkelord |
Type |
Merknad |
|---|---|---|---|
|
|
En Klasse skal kunne ha registrert ingen, ett eller flere Nøkkelord og et Nøkkelord skal kunne inngå i ingen, ett eller flere Klasser. |
O |
|
|
|
En Basismappe skal kunne ha registrert ingen, ett eller flere Nøkkelord og et Nøkkelord skal kunne inngå i ingen, ett eller flere Basismapper |
O |
|
|
|
En Basisregistrering skal kunne ha registrert ingen, ett eller flere Nøkkelord og et Nøkkelord skal kunne inngå i ingen, ett eller flere Basisregistreringer. |
O |
|
|
Krav nr. |
Funksjonelle krav til Nøkkelord |
Type |
Merknad |
|---|---|---|---|
|
|
Det skal finnes en tjeneste/funksjon for å knytte ett eller flere nøkkelord til klasser, mapper og registreringer (unntatt forenklet registrering). |
O |
|
Dette er en referanse på tvers av hierarkiet i arkivstrukturen. Referansen kan gå fra en mappe til en annen mappe, fra en registrering til en annen registrering, fra en mappe til en registrering og fra en registrering til en mappe.
Kryssreferansen vil også omfatte utvidede klasser (spesialiseringer). I og med at Kryssreferanser knyttes til Basismappe og Basis registrering, vil det si at Referanser også knyttes til alle utvidelsene (spesialiseringer) under disse (Saksmappe, Møtemappe og Journalpost, Møteregistrering).
Konseptuell modell for Kryssreferanser
<
Referanser i arkivstrukturen>
Metadata for kryssreferanse
Metadata for kryssreferanse skal grupperes inn i metadata for klasse, basismappe eller basisregistrering. Kryssreferanse er valgfritt, og kan forekomme en eller flere ganger
Referansen kan gå fra en klasse til en annen klasse, fra en mappe til en annen mappe, fra en registrering til en annen registrering, fra en mappe til en registrering og fra en registrering til en mappe. Kryssreferansen vil også omfatte spesialiseringer. En kryssreferanse kan derfor gå fra en møtemappe til en saksmappe.
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M219 |
referanseTilKlasse |
Valgfri |
En |
Avleveres |
|
M220 |
referanseFraKlasse |
Valgfri |
En |
Avleveres |
|
M210 |
referanseTilMappe |
Valgfri |
En |
Avleveres |
|
M211 |
referanseFraMappe |
Valgfri |
En |
Avleveres |
|
M212 |
referanseTilRegistrering |
Valgfri |
En |
Avleveres |
|
M213 |
referanseFraReferanse |
Valgfri |
En |
Avleveres |
Krav til Kryssreferanser
|
Krav nr. |
Strukturelle krav til Kryssreferanser |
Type |
Merknad |
|---|---|---|---|
|
|
Fra en Klasse skal det kunne refereres til en eller flere andre Klasser. |
O |
|
|
|
Til en Klasse skal det kunne refereres fra en eller flere andre Klasser. |
O |
|
|
|
Fra en Basismappe skal det kunne refereres til en eller flere andre Basismapper. |
O |
|
|
|
Til en Basismappe skal det kunne refereres fra en eller flere andre Basismapper. |
O |
|
|
|
Fra en Basismappe skal det kunne refereres til en eller flere Basisregistreringer. |
O |
|
|
|
Til en Basismappe skal det kunne refereres fra en eller flere andre Basisregistrering. |
O |
|
|
|
Fra en Basisregistrering skal det kunne refereres til en eller flere andre Basisregistreringer. |
O |
|
|
|
Til en Basisregistrering skal det kunne refereres fra en eller flere andre Basisregistreringer. |
O |
|
|
Krav nr. |
Funksjonelle krav til Kryssreferanser |
Type |
Merknad |
|---|---|---|---|
|
|
Det skal finnes en tjeneste/funksjon som kan lagre, gjenfinne, endre og slette en Kryssreferanse mellom:
eller til referanser mellom disse. |
O |
|
|
|
Det skal finnes en tjeneste/funksjon som kan lagre, gjenfinne, endre og slette en Kryssreferanse mellom:
|
O |
|
En eller flere merknader skal kunne knyttes til en basismappe, basisregistrering eller en dokumentbeskrivelse. Merknader skal brukes for å dokumentere spesielle forhold rundt saksbehandlingen og arkivering av dokumenter, og denne informasjonen skal tas med i avleveringsuttrekk.
Når det gjelder godkjenning av dokumenter på flyt, finnes det et eget metadataelement for merknader - se kapittel 6.6 Dokumentflyt.
Konseptuell modell for Merknader
<Merknader
i arkivstrukturen>
Metadata for Merknad
Metadata for merknad skal grupperes inn i metadata for basismappe, basisregistrering og dokumentbeskrivelse. Merknad er valgfritt, og kan forekomme en eller flere ganger.
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M310 |
merknadstekst |
Obligatorisk |
En |
Avleveres |
|
M084 |
merknadstype |
Valgfri |
En |
Avleveres |
|
M611 |
merknadsdato |
Obligatorisk |
En |
Avleveres |
|
M612 |
merknadRegistrertAv |
Obligatorisk |
En |
Avleveres |
Krav til Merknad i arkivstrukturen
|
Krav nr. |
Strukturelle krav til Merknader |
Type |
Merknad |
|---|---|---|---|
|
|
En Merknad skal inngå i (tilhøre) enten Basismappe, Basisregistrering eller Dokumentbeskrivelse.
Merknad: Dette er modellert med ’enten/eller-beskrankning i den konseptuelle modellen. |
O |
|
|
|
En Basismappe skal kunne ha tilknyttet ingen, en eller flere Merknader. |
O |
|
|
|
En Basisregistrering skal kunne ha tilknyttet ingen, en eller flere Merknader. |
O |
|
|
Krav nr. |
Funksjonelle krav til Merknader |
Type |
Merknad |
|---|---|---|---|
|
|
Det skal finnes en tjeneste/funksjon som kan registrere en Merknad til Basismappe eller Basisregistrering. |
O |
|
|
|
Dersom mer enn én merknad er knyttet til en Basismappe eller en Basisregistrering, må metadataene grupperes sammen ved eksport og utveksling. |
O |
|
|
|
Det bør være mulig å fritt definere typer merknader. |
A |
|
I dette kapitlet ligger Noark 5 kjernens krav til løsning for dokumentfangst og dokumentutveksling av arkivmateriale.
Elektroniske dokumenter som skapes eller mottas som ledd i saksbehandlingen, kan ha sin opprinnelse både i interne og eksterne kilder. De elektroniske dokumentene vil ha mange ulike formater, være produsert av forskjellige forfattere og kan enten være enkle filer eller sammensatte dokument.
Noen dokumenter er produsert internt i organisasjonen, som et ledd i saksbehandlingen. Andre er mottatt gjennom ulike kommunikasjonskanaler, som for eksempel e-post, telefaks, brevpost, sms og selvbetjeningsløsninger på Internett.
En løsning for fleksibel dokumentfangst er nødvendig for å håndtere dette. Og det skal være mulig å fange dokumenter helt uavhengig av dokumentets format. Vi ser for oss at det bl.a. vil være aktuelt å etablere løsninger for dokumentfangst av e-post, video, nettsider, innskannede dokumenter og lydfestinger.
I noen sammenhenger vil det også være aktuelt å fange andre typer dokumenter, så som blogger, komprimerte filer, elektroniske kalendere, data fra geografiske informasjonssystem, multimediedokumenter, dokumenter som inneholder lenker til andre dokumenter, øyeblikkelig meldingstjeneste (instant messaging), tekstmeldinger til mobiltelefon (sms), bilder til mobiltelefon (MMS) og wikis.
Struktur- og innholdsspesifikasjon (XML-schema) for generelle dokumentfangst kommer i en senere versjon av Noark 5.
|
Krav nr. |
Generelle krav til dokumentfangst |
Type |
Merknad |
|---|---|---|---|
|
|
Det skal finnes funksjonalitet for fangst av elektroniske dokumenter uavhengig av filformat, metoder for teknisk koding, kilder eller andre tekniske karakteristika. |
O |
|
|
|
Datafangsten skal skje på en slik måte at dokumentets innholdsintegritet blir opprettholdt. |
O |
|
|
|
Datafangsten bør skje på en slik måte at dokumentets utseende (layout integritet) blir opprettholdt |
A |
|
|
|
Det skal finnes funksjonalitet for helautomatisk dokumentfangst |
O |
|
|
|
Ved helautomatisk dokumentfangst skal det være mulig å tilknytte alle obligatoriske metadata til dokumentet |
O |
|
|
|
Ved helautomatisk dokumentfangst skal det være mulig å knytte dokumenter til et klassifikasjonssystem |
O |
|
|
|
Ved helautomatisk dokumentfangst skal det være mulig å knytte dokumenter til en eller flere mapper eller klasser i arkivstrukturen |
O |
|
|
|
Det skal ikke være noen begrensninger i antall dokumenter som kan bli knyttet til en klasse eller en mappe. |
O |
|
|
|
Det skal ikke være begrensninger i antall dokumenter som kan bli arkivert i løsningen. |
O |
|
|
|
Det skal finnes funksjoner for å sikre at alle komponenter i et sammensatt dokument fanges. |
O |
|
|
|
Det skal finnes funksjoner for å sikre at et sammensatt elektronisk dokument håndteres som en enhet, hvor relasjonen mellom komponentene og dokumentets indre struktur opprettholdes. |
O |
|
Krav til masseimport
Saksbehandling, dokumenthåndtering og dokumentutveksling gjør bruk av stadig nye kanaler. Arkivsystemene bør ikke være et hinder for effektivisering på disse områdene, samtidig som det er særdeles viktig at dokumenters autentisitet og integritet sikres. Masseimport skal gjøre det mulig å importere flere dokumenter inn til Noark 5-løsningen i én og samme sekvens.
Dokumenter kan komme i bolker til kjernen på mange måter, eksempelvis:
en masseimport fra en annen Noark-løsning.
en masseimport fra et dokumentlager.
en masseimport fra for eksempel et skanningssystem.
en masseimport fra mappene til et operativsystem.
En masseimport fra et nettsted
Noark 5 må ha mulighet til å akseptere disse, og må inkludere løsninger for å håndtere fangst og vedlikehold av innhold og struktur til de importerte dokumentene.
I en masseimport må kjernen fange samme informasjon som i en vanlig import, nemlig dokumentet og dets metadata.
Masseimport må håndtere unntak og feil. Dette kan være aktuelt f. eks. ved elektroniske høringer via web-tjener på Internett, dokumentproduksjon i samhandlingsrom, ”saksbehandling” med e-postsystemet som utvekslingskanal eller i andre tilfeller hvor en relativt omfattende dokumentbehandling har foregått uten at det har skjedd en arkivdanning samtidig. Eksempelvis kan Noark 5-løsningen tilby funksjonalitet hvor brukeren kan velge/markere filer som er lokalisert på en eller flere filservere, ftp-server eller lignende, for å importere dem. Brukeren skal enkelt kunne knytte filene til en mappe eller en registrering i en bestemt mappe. Alternativt kan masseimport håndteres ved f. eks. en søkemotor, hvor dokumentene fanges, tilknyttes metadata og importeres til en definert arkivenhet i en automatisert prosess.
Kravene til masseimport nedenfor er generelle, og de er uavhengige av verktøy og teknologi.
Masseimport utløst fra forsystemet
Ved masseimport utløst fra forsystem er det forsystemets ansvar å organisere de data og dokumenter som skal importeres og utvikle funksjonalitet som leser datagrunnlaget og sender disse over som integrasjonsmeldinger til Noark 5.
|
Krav nr. |
Krav til masseimport utløst fra et forsystem |
Type |
Merknad |
|---|---|---|---|
|
|
Masseimport utløst fra et forsystem skal levere integrasjonsmeldinger til Noark 5 basert på struktur- og innholdsspesifikasjon for dokumentfangst i Noark 5, når dette kommer på plass i en senere versjon. |
O |
|
Masseimport utløst fra Noark 5-kjerne
|
Krav nr. |
Krav til masseimport utløst fra Noark 5-kjerne |
Type |
Merknad |
|---|---|---|---|
|
|
Noark 5-løsningen skal inneholde masseimportfunksjonalitet som henter dokumenter fra en angitt plassering og knytte disse til klasser, mapper, registreringer eller dokumentbeskrivelser. |
O |
|
|
|
Ved masseimport skal det være mulig å velge om alle importerte dokumenter skal knyttes til én og samme arkivenhet på samme nivå i arkivstrukturen eller om hvert enkelt dokument skal knyttes til forskjellige arkivenheter i arkivstrukturen. |
O |
|
|
|
Ved masseimport skal det være mulig å knytte importerte dokumenter til en allerede eksisterende klase, mappe, registrering eller dokumentbeskrivelse . |
O |
|
|
|
Ved masseimport skal det være mulig å definere og utfylle metadatasettet for dokumentene som skal importeres, kun én gang. |
O |
|
|
|
Noark 5-kjernen bør ha automatikk for å fange dokumenter som er generert og overført fra andre system. |
A |
|
|
|
Noark 5-kjernen bør ha mulighet til å håndtere input kø ved masseimport.
Merknad: For håndtering av input køen kan det for eksempel være ønskelig å se køene, pause en eller flere køer, starte en eller alle køene på nytt, slette en kø. |
A |
|
|
|
Noark 5-kjernen bør kunne fange metadata knyttet til alle dokumentene som overføres, automatisk. Det bør være mulig å overstyre dette ved manglede eller feil metadata. |
A |
|
|
|
Ved automatisert masseimport, skal det være funksjonalitet for å validere metadata med tilhørende dokumenter automatisk, for å sikre opprettholdt dataintegritet. |
O |
|
|
|
Ved masseimport skal det være mulig å importere logginformasjon om de importerte dokumentene, og logginformasjonen skal inngå i importen som eget (egne) dokument. |
O |
|
|
|
Noark 5-løsningen skal ikke importere logginformasjonen på en slik måte at den blir en del av Noark 5-løsningens egen logginformasjon, importert logginformasjon må arkiveres separat, uavhengig av Noark 5-løsningens egne logger. |
O |
|
|
|
Det skal være definert en administratorrolle i Noark 5-løsningen som skal kunne definere at importerte arkiv, arkivdeler, klasser, mapper og registreringer automatisk skal settes som avsluttet etter importen.
Merknad: Ved fusjoneringer av to eller flere organisasjoner kan det være aktuelt å avslutte hele eller deler av organisasjonenes arkiver. |
O |
|
Elektroniske skjema for utfylling over Internett
Offentlig sektor er i ferd med å etablere elektroniske selvbetjeningsløsinger, hvor næringsliv og borgere skal kunne utføre og motta elektroniske tjenester døgnet rundt, i det vi kaller en døgnåpen elektronisk forvaltning. Et sentralt virkemiddel i en selvbetjeningsløsning er elektroniske skjema for utfylling over Internett.
Svardataene fra et elektronisk skjema er å betrakte som et dokument i arkivlovens forstand, og skal dermed håndteres som andre typer dokumenter som kommer inn til organet, dvs de skal normalt registreres og arkiveres. Både parter og publikum har rett til å kreve innsyn i opplysninger eller dokumenter i en sak som har kommet inn til forvaltningsorganet via elektroniske skjema. I prinsippet skal man da kunne se både selve svardataene og de omgivelsene bruker så da hun fylte ut skjemaet. For å sikre rettsvern og ettersporbarhet for den som har fylt ut det elektroniske skjemaet, skal det i ettertid være mulig å hente fram autentisk representasjon av inngitte data, innfelt i den skjemaversjonen som ble brukt ved utfylling av skjemaet.
Et elektronisk skjema for utfylling over Internett kan være statisk, slik at alle utfyllere presenteres for ledetekster, veiledningsinformasjon og svarfelter på samme måte, i et fast oppsett. For å kunne presentere et utfylt skjema av denne typen i ettertid, vil eksempelvis en pdf-fil kunne gi et fullstendig bilde av brukergrensesnittet i utfyllingssituasjonen. Men elektroniske skjemaer vil stadig oftere være laget som en dynamisk skjermdialog. Elektroniske skjema med dynamisk skjermdialog kjennetegnes ved at de har selvvalgte hjelpetekster som kan hentes fram til hvert enkelt spørsmål, sporvalg og utgråede enkeltspørsmål, hvor utfylleren ledes utenom sider eller spørsmål som har vist seg uaktuelle etter tidligere svar. Dette er anbefalinger i ELMER2-retningslinjene for offentlige nettskjemaer. Å presentere et utfylt skjema av denne typen i ettertid krever at fila med svardata kan hentes inn igjen i det opprinnelige brukermiljøet.
Relevante arkivdata i tilknytning til elektroniske skjemaløsninger kan være av tre typer i Noark-sammenheng:
Selve svardataene
Utfyllerens
registreringer i fritekstfelter og valg fra envalgs- og
flervalgslister. Viktig i Noark 5-sammenheng er f. eks. felter til
identifikasjon av avsender, søker og parter.
Transaksjonsopplysninger
Informasjon
om selve overføringen av data fra utfyllerens PC til
mottakersystemet. Viktig i Noark 5-sammenheng er tidspunkt for
overføringen til oppgaveinnhenter, som tilsvarer dato for
mottak av skjemaet.
Faste opplysninger for den
enkelte skjematypen
Dette er opplysninger som ikke er fylt ut
som svardata og ikke naturlig logges for transaksjoner. I Noark
5-sammenheng kan dette typisk være beskrivelse av
saksforholdet (saksmappen) eller dokumentet (journalposten), klasse,
saksbehandler, saksbehandlende enhet, unntak fra offentlighet og
opplysninger om bevaring/kassasjon.
I prinsippet kan skjemaløsningen legge til rette for fullstendig dokumentfangst av svardata fra elektroniske skjema og fullstendig, automatisk registrering, arkivering og til og med fordeling til saksbehandlende enhet eller person. Men det er altså skjemaløsningen som bestemmer hvilke spørsmål som stilles, og dermed hvilke svardata som kan anvendes automatisk og hvilke transaksjonsdata og faste opplysninger som følger med inn til organet.
|
Krav nr. |
Krav til Elektroniske skjema for utfylling over Internett |
Type |
Merknad |
|---|---|---|---|
|
|
Det bør finnes funksjonalitet for å hente inn både relevante svardata og transaksjonsopplysninger fra elektroniske skjemaer, og legge disse inn som mappe, registrering, dokumentbeskrivelse og dokument i en automatisert prosess. |
A |
|
|
|
Det skal være mulig å legge inn faste opplysninger for den enkelte skjematypen i tillegg til svardata og transaksjonsopplysninger |
O |
|
|
|
Det totale resultatdatasettet fra et elektronisk skjema skal lagres sammen med relevante transaksjonsopplysninger og faste opplysninger for skjematypen i et godkjent arkivformat. |
O |
|
|
|
Det skal være mulig å velge hvilke enkeltstående svardatafelter, transaksjonsopplysninger og faste opplysninger for et elektronisk skjema som skal integreres i Noark 5-kjerne. |
O |
|
|
|
Mottatte skjemadata skal arkiveres i form av en fullstendig kopi av svardata og utfyllingsmiljø i et godkjent arkivformat. |
O |
|
|
|
For dynamiske skjemaer bør informasjon om aktuell versjon av skjema og presentasjonsprogramvare lagres sammen med eller som del av resultatdatasettet, innfelt i den skjemaversjonen som ble brukt ved utfylling av skjemaet. |
A |
|
Med elektronisk dokumentutveksling menes i denne sammenhengen enkeltvis dokumentutveksling mellom (Noark)-løsninger som ledd i den ordinære saksbehandlingen.
Sikker elektronisk dokumentutveksling mellom ulike Noark-løsninger og mellom forskjellige samhandlende forvaltningsorgan er viktig for å kunne realisere målet om eForvaltning, effektivisere oversendelsen av dokumenter mellom organ og sørge for at de arkivfaglige kravene ivaretas.
Formålet med dette kravsettet er at ulike offentlige virksomheter skal kunne utveksle alle typer informasjon uavhengig av hverandres Noark-løsninger. Slik dokumentutveksling må både være enkel å bruke og ta høyde for uveksling også av sensitiv informasjon.
Struktur- og innholdsspesifikasjon (XML-schema) for dokumentutveksling kommer i en senere versjon av Noark 5.
|
Krav nr: |
Krav til elektronisk dokumentutveksling |
Type |
Merknad |
|---|---|---|---|
|
|
Det skal finnes funksjoner for sikker, automatisert dokumentutveksling mellom Noark-løsninger, basert på XML-schema for dokumentutveksling. |
O |
|
|
|
Det skal finnes funksjoner for å automatisk registrere mottatte saksdokument |
O |
|
|
|
Metadata for utgående og innkomne dokumenter sendt ved elektronisk meldingsutveksling skal som et minimum inneholde obligatoriske metadata |
O |
|
|
|
Ved elektronisk dokumentutveksling med sensitive opplysninger skal kryptering skje når meldingen blir sendt ut av det sikre nettet til virksomheten. Bare forhåndsdefinert mottaker skal kunne dekryptere. |
O |
|
|
|
Ved elektronisk dokumentutveksling skal sendingen være sikret mot uautorisert endring. |
O |
|
|
|
Ved elektronisk dokumentutveksling skal relevante logger kunne lagres i Noark- løsningen. |
O |
|
Med migrering menes i denne sammenheng flytting av komplette datasett fra en teknisk plattform til en annen (ny versjon eller ny løsning), hvor dataene i så stor grad som mulig skal være uendret etter at dataene er flyttet.
Informasjonen som er lagret i en Noark 5-løsning skal kunne eksporteres - eller trekkes
ut - til et systemuavhengig format. Eksporten skal omfatte både arkivstrukturen, metadata og eventuelt tilknyttede elektroniske dokumenter. Det skilles mellom to varianter av eksport - migreringsuttrekk og avleveringsuttrekk. Avleveringsuttrekk behandles i kapittel 4.2.12.
Migreringsuttrekk skal kunne brukes for migrering av data ved oppgradering til ny versjon av samme løsning, eller ved overgang til en annen Noark-løsning. Det bør også være mulig å overføre aktive arkivdeler fra ett system til et annet, f.eks. i forbindelse med organisasjonsendringer. Dette betyr at en Noark-løsning også må kunne importere data fra et migreringsuttrekk.
Migrering av data innebærer at en Noark-løsning både må kunne håndtere eksport og
import. En slik migrering kan være aktuell ved oppgradering til ny versjon. En bruker som går over til en ny Noark-løsning fra en annen leverandør, skal kunne overføre sine gamle data til den nye løsningen uten at det oppstår noen problemer. Det bør også være mulig å importere deler av data fra en løsning inn i en annen løsning som allerede er i bruk. Dette kan være aktuelt ved omorganiseringer hvor for eksempel deler av et organs ansvarsområde overføres til et annet organ.
Dersom en eller flere arkivdeler flyttes fra en løsning til en ennen vil det være behov for en avtale som regulerer det faktiske innholdet i migreringsuttrekket. Dette med
bakgrunn i eventuelle forskjeller mellom løsningene.
Struktur- og innholdsspesifikasjon (XML-schema) for migreringsuttrekket kommer i en senere versjon av Noark 5.
|
Krav nr: |
Krav til migrering mellom Noark-løsninger |
Type |
Merknad |
|---|---|---|---|
|
|
Data skal kunne migreres mellom Noark-løsninger. |
O |
|
|
|
Det skal være mulig å eksportere data fra en Noark-løsning, basert på struktur- og innholdsspesifikasjon for migreringsuttrekket slik det beskrives i XML-schema for migrering. |
O |
|
|
|
Det skal være mulig å importere data til en Noark-løsning fra en annen Noark-løsning eller en annen versjon av samme løsning, basert på struktur- og innholdsspesifikasjon for migreringsuttrekket slik det beskrives i XML-schema for migrering. |
O |
|
|
|
Det bør være mulig å migrere data fra deler av løsningen, f.eks. en arkivdel.
|
A |
|
|
|
Det skal være mulig å importere et fullstendig migreringsuttrekk fra en annen Noark-løsning. Importen skal ikke avbrytes selv om de dataene som importeres inneholder data som ikke er definert i mottakerløsningen. |
O |
|
|
|
Det bør være mulig å importere deler fra en annen Noark-løsning, f.eks. en arkivdel, inn i en løsning som allerede inneholder data.
|
A |
|
|
|
Det skal produseres en logg over alle metadataelementer og dokumenter som ikke kan importeres og over andre feil som eventuelt oppstår under importen. |
O |
|
|
|
Når det foretas en import skal det genereres en loggfil med informasjon om hvordan importen har gått, f.eks. antall metadataelementer og dokumenter. Loggfilen skal også inneholde en liste over alle metadataelementer og dokumenter som det ikke har vært mulig å importere. |
O |
|
Med gjenfinning menes den indre kjernens muligheter for å kunne levere de metadata og dokumenter som den ytre kjernen og Noark 5 komplett forespør, f.eks. når et søk initieres fra et fag- eller forsystem.
For at den ytre kjernen og
komplette løsninger skal kunne produsere lovpålagte og
ønskede rapporter og statistikker, er det nødvendig at
kjernen er tilrettelagt med tjenester eller funksjoner for
gjenfinning og logiske sammenstillinger av metadata. Offentlig
journal er et eksempel på en slik lovpålagt rapport.
Søking i metadata skjer ved søking i enkelte metadataelementer eller i en kombinasjon av metadataelementer, eller ved hjelp av fritekstsøk, f.eks. søking etter en gitt tekststreng i et sett av metadataelementer.
Gjenfinning av dokumenter skjer
typisk ved søking i dokumentenes metadata, f.eks. i
dokumentbeskrivelsemetadata. Hvis formatet legger til rette for det,
kan fritekstsøking gjennomføres i dokumenter.
Søkeresultat skal ta
hensyn til tilgangen til dokumentene i kjernen og til skjerming av
opplysninger.
|
Krav nr. |
Funksjonelle krav til Gjenfinning |
Type |
Merknad |
|---|---|---|---|
|
|
Det skal finnes tjenester/funksjoner for å gjenfinne/søke fram metadata. |
O |
|
|
|
Ved søking skal det være mulig å lage logiske sammenstillinger av metadata. |
O |
|
|
|
Ved søk i metadata skal det være mulig å benytte venstre- og høyretrunkering samt markering av ett eller flere tegn i søkekriteriene. |
O |
|
|
|
I metadataelementer som representerer datoer, skal det være mulig å søke på datointervaller. |
O |
|
|
|
I metadataelementer som representerer datoer, skal det være mulig å søke på perioder som ligger før eller etter en gitt dato. |
O |
|
|
|
Det skal være mulig å utføre fritekstsøk i metadata. |
O |
|
|
|
Ved fritekstsøk i metadata, skal det være mulig å søke kombinert på flere søkeord ved hjelp av boolske operatorer. |
O |
|
|
|
Det skal finnes tjenester/funksjoner for å gjenfinne/søke fram dokumenter. |
O |
|
|
|
Det skal være mulig å gjenfinne dokumenter ut fra dokumentmetadata. |
O |
|
|
|
Det skal være mulig å utføre fritekstsøk i et dokument hvis formatet legger til rette for det. |
O |
|
|
|
Søkeresultat skal avspeile aktuell tilgang. |
O |
|
|
|
Søkeresultat skal være nødvendig skjermet. |
O |
|
|
|
Det skal være mulighet for at store og små bokstaver kan behandles som ekvivalente ved søk. |
O |
|
|
|
Det bør finnes en tjeneste/funksjon for å avbryte søk som er satt i gang. |
A |
|
Kassasjon vil si at elektroniske dokumenter fjernes fra arkivstrukturen. Dersom dokumentet ikke er tilknyttet andre registreringer, innebærer en kassasjon også at dokumentet slettes helt fra Noark 5-løsningen. Kassasjon av fysiske dokumenter vil si at de plukkes ut fra stedet de oppbevares, og makuleres eller destrueres på en betryggende måte.
Antall mapper med tilhørende arkivdokumenter i et arkiv vil stadig vokse. Etter som tiden går, vil eldre mapper bli mer og mer uaktuelle for arkivskaperen. Rent generelt antas det at offentlige forvaltningsorganer ikke har noe administrativt behov for å ta vare på arkivmateriale som er eldre enn 30 år. Men det vil finnes materiale som må bevares lengre, og det vil finnes materiale som kan kasseres etter kortere tid. I en del tilfeller vil bevaringstiden være fastsatt i lover og regelverk. I henhold til regnskapslovgivningen kan regnskapsbilag kasseres allerede etter 10 år. Pasientjournaler derimot må oppbevares mye lenger, i opptil 10 år etter at en pasient er død. Visse typer helseinformasjon vil altså ha en administrativ levetid på over 100 år.
Riksarkivaren har myndighet til å fatte bevarings- og kassasjonsvedtak for offentlige arkiver. Det betyr at offentlige arkivskapere ikke fritt kan kassere sine dokumenter etter eget ønske. Et bevaringsvedtak innebærer at det aktuelle arkivmaterialet skal bevares for all framtid, og at det må overføres - eller avleveres - til et arkivdepot. Avlevering er beskrevet i kapittel 4.2.12.
Kassasjon av elektroniske dokumenter
Kassasjon er like aktuelt i elektroniske arkiver som i fysiske arkiver. Langtidsoppbevaring og administrasjon (f.eks. konvertering til nye formater) av store mengder elektroniske dokumenter medfører minst like store omkostninger som langtidslagring av fysiske dokumenter. Men økonomi er ikke den eneste grunnen til at en fortløpende og systematisk bør kassere alle dokumenter som ikke har noen bevaringsverdi - verken for arkivskaper eller arkivmyndighetene. Informasjonsflommen er overveldende i dagens samfunn, og jo mer unødvendig informasjon som tas vare på, jo vanskeligere kan det bli å søke fram og finne den informasjonen en virkelig trenger.
Kassasjon betyr ikke at en må gå inn og vurdere bevaringsverdien for hvert eneste dokument. For at kassasjon av elektroniske dokumenter skal være praktisk gjennomførbart, må en fastsette bevarings- og kassasjonskriterier på et overordnet plan - dvs. på et makronivå. Internasjonal arkivteori argumenterer for funksjonsbasert makrokassasjon. Det betyr at arkivdokumentenes bevaringsverdi avhenger av funksjonen eller aktiviteten som har skapt dokumentet - og ikke av selve innholdet i dokumentet. Også i Norge er det enighet om at funksjonsbasert kassasjon på makronivå kan være en viktig metode, selv om noen også hevder at en samtidig må ta hensyn til dokumentenes innhold.6
Konseptuell modell
for Bevaring og kassasjon <
Kassasjon i arkivstrukturen>

Metadata for Bevaring og Kassasjon
Metadata for bevaring og kassasjon skal grupperes inn i metadata for arkivdel, klasse, mappe, registrering og dokumentbeskrivelse. Metadata for bevaring og kassasjon er valgfritt, og kan forekomme en gang.
I Noark 4 har disse attributtene forskjellig navn avhengig av hvilket nivå i arkivstrukturen de er tilknyttet. Nedenfor er tatt med referanse til attributter på saksnivået.
Metadata om kassasjon
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M450 |
kassasjonsvedtak |
Bet. oblig. |
En |
Avleveres |
|
M453 |
kassasjonshjemmel |
Valgfri |
En |
Avleveres |
|
M451 |
bevaringstid |
Bet. oblig. |
En |
Avleveres |
|
M452 |
kassasjonsdato |
Bet. oblig. |
En |
Avleveres |
Et bevarings- og kassasjonsvedtak forteller hva som skal skje med dokumentene når bevaringstiden er nådd. Obligatoriske verdier er "Bevares", "Kasseres" og "Vurderes senere". Bevaringstiden kan typisk være 5, 10 eller 30 år. Kassasjonsdatoen beregnes automatisk på grunnlag av bevaringstiden. Bevaringstiden skal begynne å løpe fra tidspunktet når en saksmappe er avsluttet, men det skal også være mulig å fastsette andre regler for beregning av kassasjonsdato.
Funksjonsbasert kassasjon forutsetter at klassifikasjonssystemet beskriver virksomhetens funksjoner og aktiviteter. I Noark 5 skal det være mulig å sette bevarings- og kassasjonsvedtak på de enkelte klassene i et klassifikasjonssystem. Dette skal da automatisk kunne arves til alle mapper som tilordnes klassen.
Det skal også være mulig å sette bevarings- og kassasjonsvedtak på en arkivdel. Det betyr da at alle mapper i arkivdelen arver det samme vedtaket. Dersom arv skjer fra arkivdelen, skal det ikke samtidig være mulig med arv fra klassene. Bevarings- og kassasjonsvedtak for en hel arkivdel er først og fremst aktuelt ved enkelte fagsystemer som produserer såkalte "enstypeserier".
Arv skal kunne skje videre ned til registrerings- og dokumentbeskrivelsesnivå. Selv om kassasjon ofte omfatter hele mapper, skal det være mulig å bevare en eller flere av registreringene i mappen, og kassere resten.7
|
Krav nr. |
Strukturelle krav til Bevaring og kassasjon |
Type |
Merknad |
|---|---|---|---|
|
|
En Arkivdel skal kunne ha registrert ingen eller ett Kassasjonsvedtak og et Kassasjonsvedtak kan inngå i ingen, en eller flere Arkivdeler. |
O |
|
|
|
En Klasse skal kunne ha registrert ingen eller ett Kassasjonsvedtak og et Kassasjonsvedtak kan inngå i ingen, en eller flere Klasser. |
O |
|
|
|
En Basismappe skal kunne kunne ha registrert ingen eller ett Kassasjonsvedtak og et Kassasjonsvedtak kan inngå i ingen, en eller flere Basismapper. |
O |
|
|
|
En Forenklet registrering skal kunne ha registrert ingen eller ett Kassasjonsvedtak og et Kassasjonsvedtak kan inngå i ingen, en eller flere Forenklede registreringer. |
O |
|
|
|
En Dokumentbeskrivelse skal kunne ha registrert ingen eller ett Kassasjonsvedtak og et Kassasjonsvedtak kan inngå i ingen, en eller flere Dokumentbeskrivelser. |
O |
|
|
Krav nr. |
Funksjonelle krav til Bevaring og kassasjon |
Type |
Merknad |
|---|---|---|---|
|
|
Det skal finnes en tjeneste/funksjon for å ajourholde kassasjonsvedtak, kassasjonshjemmel og bevaringstid for en Klasse. |
O |
|
|
|
Metadata om bevaring og kassasjon på en Klasse skal kunne arves til Mappe, Dokumentbeskrivelse og Dokumentobjekt. |
O |
|
|
|
Det skal finnes en tjeneste/funksjon for å ajourholde kassasjonsvedtak, kassasjonshjemmel og bevaringstid for en Arkivdel. |
O |
|
|
|
Metadata om bevaring og kassasjon på en Arkivdel skal kunne arves til Mappe, Dokumentbeskrivelse og Dokumentobjekt. |
O |
|
|
|
Dersom arv av metadata om bevaring og kassasjon skal skje fra arkivdel, skal dette overstyre arv av metadata fra klassene. |
O |
|
|
|
Det skal finnes en tjeneste / funksjon for å registrere et kassasjonsvedtak for en Mappe, Registrering eller Dokumentbeskrivelse. Kassasjonsvedtaket skal bestå av følgende obligatoriske verdier:
Andre verdier kan legges til. |
O |
|
|
|
Det skal være mulig manuelt å registrere kassasjonsvedtak, kassasjonshjemmel og bevaringstid for en Mappe, Registrering eller Dokumentbeskrivelse. |
O |
|
|
|
Bevaringsdatoen for en Mappe, Registrering eller Dokumentbeskrivelse skal kunne beregnes automatisk på grunnlag av bevaringstid og datoen mappen ble avsluttet. |
O |
|
|
|
Andre regler for beregning av bevaringsdato bør kunne være mulig. |
A |
|
|
|
Bevaringsdato for en Mappe, Registrering eller Dokumentbeskrivelse skal også kunne registreres manuelt. Bevaringstid er da ikke obligatorisk. |
O |
|
|
|
Det skal være mulig å slå av funksjonen for arv fra klasser og arkivdeler, slik at metadata om bevaring og kassasjon ikke arves til underliggende mapper. |
O |
|
|
|
Det skal være mulig å angi at arv av metadata om bevaring og kassasjon også skal gå ned til registrering og dokumentbeskrivelse. |
O |
|
|
|
Metadata om bevaring og kassasjon som arves fra et arkivobjekt til alle underliggende arkivobjekter, skal kunne overskrives . |
O |
|
|
|
Hvis et arkivobjekt settes til kassasjon, for siden å settes tilbake til bevaring, må alle overliggende arkivobjekter (i rett stigende linje) i hierarkiet endres tilsvarende. |
O |
|
Kassasjon av dokumenttyper
Bevaring og kassasjon er altså i utgangpunktet knyttet til metadata som arves fra klassen, eller eventuelt arkivdelen, til alle underliggende mapper. I tillegg skal det også være mulig å foreta gjennomgående kassasjon av bestemte typer dokumenter. Derfor bør det også være mulig å knytte bevaring og kassasjon til registreringstyper, dokumenttyper eller andre egendefinerte typer.8
Kassasjon av dokumenttyper kan implementeres ved at bestemte registreringstyper eller dokumenttyper automatisk knyttes til en arkivdel som inneholder bevarings- og kassasjonsvedtaket for den bestemte typen. Dette vedtaket skal da arves til registreringen eller dokumentbeskrivelsen. Men det kan også være andre måter å implementere denne funksjonaliteten uten å bruke arkivdel.
|
Krav nr. |
Funksjonelle krav til Bevaring og kassasjon |
Type |
Merknad |
|---|---|---|---|
|
|
Det bør finnes en tjeneste/funksjon som automatisk knytter en bestemt type registreringer eller dokumentbeskrivelser til et bevarings- og kassasjonsvedtak. |
A |
|
|
|
Metadata om bevaring og kassasjon skal da arves til alle opprettede registreringer eller dokumentbeskrivelser av samme type. |
BO |
|
Oversikt over dokumenter som skal kasseres eller vurderes på ny
Før kassasjonen gjennomføres, skal det være mulig å få presentert en oversikt over dokumenter som skal kasseres. En slik oversikt skal inneholde de viktigste metadataene, inkludert alle metadata for bevaring og kassasjon. Fra denne oversikten skal det også være mulig å åpne selve dokumentet, slik at en kan få kontrollert dokumentinnholdet. Dersom oversikten inneholder dokumenter som ikke skal kasseres i denne omgang, skal det være mulig å endre metadata direkte fra oversikten. Oversikten skal kunne begrenses til å omfatte et utvalg dokumenter, f.eks. knyttet til en bestemt klasse.
På samme måte skal det være mulig å få presentert en oversikt over dokumenter som skal vurderes for bevaring og kassasjon på et senere tidspunkt. Dette er først og fremst aktuelt for arkivmateriale som dokumenterer enkeltpersoners eller virksomheters rettigheter, og hvor det er usikkert om dokumentasjonsbehovet er varig eller ikke. For andre typer materiale er det ikke ønskelig at muligheten for vurdering på et senere tidspunkt brukes. Også fra denne oversikten skal det være mulig å endre metadata direkte.
|
Krav nr. |
Funksjonelle krav til Bevaring og kassasjon |
Type |
Merknad |
|---|---|---|---|
|
|
Det skal være mulig å få presentert en oversikt over dokumenter som skal kasseres etter et bestemt tidspunkt. En slik oversikt skal kunne begrenses til et mindre utvalg dokumenter. |
O |
|
|
|
Det skal være mulig å få presentert en oversikt over dokumenter som skal vurderes på nytt for bevaring eller kassasjon etter et bestemt tidspunkt. En slik oversikt skal kunne begrenses til et mindre utvalg dokumenter. |
O |
|
|
|
Oversikten skal inneholde de viktigste metadata for dokumentene, inkludert metadata for bevaring og kassasjon. |
O |
|
|
|
Det skal være mulig å åpne et dokument for presentasjon av innhold direkte fra denne oversikten. |
O |
|
|
|
Autoriserte brukere skal kunne endre metadata for bevaring og kassasjon for de enkelte dokumenter direkte fra oversikten. |
O |
|
Sletting av dokumenter og metadata
Kriteriet for at et dokument skal kunne kasseres er at metadata for kassasjonsvedtak har verdien "Kasseres", og at dagens dato har passert bevaringsdatoen. Løsningen bør kontrollere at presedenssaker aldri tillates kassert.
Kassasjon av elektroniske dokumenter innebærer at referansen mellom metadata og dokumenter slettes, slik at dokumentene ikke lenger kan hentes fram ved hjelp av metadata. Dette skjer ved at all metadata om dokumentobjektet fjernes. Alle versjoner, varianter eller formater av dokumentet skal omfattes av kassasjonen. Dersom samme dokument (dokumentbeskrivelse) er knyttet til flere registreringer, må ikke dokumentet slettes fra filsystemet. Finnes det ingen slike tilknytning, skal også dokumentet slettes.
Kassasjon av dokumenter er altså en kritisk funksjon som mange vil kvie seg for å utføre. Det bør derfor være mulig å angre en kassasjon og gjenopprette tilknytningen til de kasserte dokumentene, jf. muligheten som operativsystemene har til å hente fram igjen dokumenter som er "kastet i papirkurven".
Selve funksjonen for å utføre kassasjon skal kunne begrenses til å omfatte utvalgte dokumenter, f.eks. alle dokumenter som tilhørere en bestemt klasse. Det skal være mulig å utføre kassasjonen som en automatisk prosess, men det skal også være mulig å be om å få spørsmål om kassasjon er aktuelt for hvert eneste dokument.
Kassasjon av dokumenter betyr ikke at metadata skal slettes. Når det gjelder sakarkiver i offentlig forvaltning, har arkivforskriften et bevaringspåbud for "journaldatabaser". Det betyr altså at metadata om kasserte dokumenter i utgangspunktet skal bevares, og avleveres til depot. Det skal likevel være mulig å angi at kassasjon også innebærer sletting av tilhørende metadata. Dette vil da være særlig aktuelt ved bestemte typer fagsystemer eller "enstypeserier". I slike tilfeller skal verken metadata eller dokumenter bevares.
|
Krav nr. |
Funksjonelle krav til Bevaring og kassasjon |
Type |
Merknad |
|---|---|---|---|
|
|
Det skal finnes en funksjon for å kassere alle dokumenter som har verdien "Kasseres" som kassasjonsvedtak, og hvor bevaringsdatoen er eldre enn dagens dato. En slik funksjon skal kunne begrenses til et mindre utvalg dokumenter. |
O |
|
|
|
Det skal ikke være mulig å sette kassasjonsvedtak "Kasseres" på en mappe som er registrert som presedenssak. |
O |
|
|
|
Kassasjonen skal kunne utføres automatisk for hele utvalget dokumenter, men det skal også være mulig å be om spørsmål om kassasjon skal utføres for hvert enkelt dokument. |
O |
|
|
|
Bare autoriserte brukere kan starte en funksjon for kassasjon av dokumenter. |
O |
|
|
|
Alle versjoner, varianter og formater av dokumentet skal omfattes av kassasjonen. |
O |
|
|
|
Kassasjon skal innebære at all metadata om dokumentobjektet slettes. Selve dokumentet skal slettes fra filsystemet dersom dokumentet (dokumentbeskrivelsen) ikke er knyttet til andre registreringer. |
O |
|
|
|
Funksjonen for kassasjon bør være i to trinn, slik at det i første omgang er mulig å gjenopprette de kasserte dokumentene. Endelig sletting av dokumentobjekt og dokument skal kunne skje på et senere tidspunkt. |
A |
|
|
|
Metadata om dokumentet ned til dokumentbeskrivelse, skal i utgangspunktet ikke slettes selv om dokumentet kasseres. |
O |
|
|
|
For hvert dokument som blir kassert, skal det på dokumentbeskrivelsesnivå logges dato for kassasjon og hvem som utførte kassasjonen. |
O |
|
|
|
Det skal være mulig å angi at både dokumentene og tilhørende metadata opp til mappenivå skal slettes når kassasjon utføres. |
O |
|
Ved fysisk arkivering har det ofte vært ønskelig å skille ut det eldste og mest uaktuelle materialet fra det som er i aktivt bruk. Dette ble gjerne plassert et sted hvor kostnadene for lagring var lavere enn der det aktive arkivet ble oppbevart. Det tradisjonelle begrepet for dette er bortsetting. Arkiver som er bortsatt, befinner seg fremdeles hos arkivskaper. Slike arkiver er i et mellomstadium, organet har fremdeles et behov for å hente fram dokumenter fra bortsettingsarkivet - men dette behovet vil ikke forekomme så ofte.
Det anbefales at bortsetting knyttes til faste, tidsavgrensede perioder kalt arkivperioder. En arkivperiode kan typisk være på 5 år, men både kortere og lengre perioder er fullt mulig. Ved fysisk arkivering innebærer periodisering både at dokumenter flyttes fra et oppbevaringssted til et annet, og at denne flyttingen fremgår av arkivstrukturen og metadataene som er knyttet til dokumentene.
Periodisering vil i mange tilfelle også være hensiktigmessig i et elektronisk arkiv. Her er det ikke hensynet til fysisk oppbevaringsplass som er det avgjørende, men behovet for oversikt og rask gjenfinning ved søk. Etter hvert som antall mapper vokser, vil det bli stadig mer upraktisk å ha eldre avsluttede mapper liggende sammen med de som ennå er åpne eller nettopp avsluttet. Derfor kan vi også ved elektronisk arkivering med fordel organisere arkivet i en aktiv periode, og en eller flere avsluttede perioder. Denne oppdelingen omfatter da altså både de elektroniske dokumentene og tilhørende metadata.
Prinsippene for periodisering som ble introdusert i Noark 4 skal videreføres i Noark 5. Her skilles det mellom to hovedtyper periodisering: skarpt periodeskille og skille ved overlappingsperiode.
Skarpt periodeskille vil si at alle åpne mapper (pågående saker) i en avsluttet periode må lukkes, og så opprettes på nytt i en ny periode (arvtakeren) ved neste registrering. Dette betyr altså at dokumenter som hører sammen vil befinne seg i to forskjellige mapper, og disse vil tilhøre hver sin periode. Disse mappene må derfor bindes sammen med en referanse. Skarpt periodeskille anbefales ikke ved elektronisk arkiv.
Periodisering med overlappingsperiode (også kalt "mykt" periodeskille) innebærer at dersom en mappe ikke er avsluttet ved periodens slutt, skal hele mappen - med alle tidligere registreringer - flyttes over til en ny, aktiv periode ved neste registrering. Denne overflyttingen skal skje automatisk så lenge overlappingsperioden varer. Ved overlappingsperiodens slutt vil de fleste aktive saker være overført til ny periode.
Rutinene for periodisering av forskjellige typer mapper vil bli nærmere omtalt i veiledningen. Her i standardenen vil bare krav til metadata og til nødvendig funksjonalitet for å gjennomføre forskjellige former for periodisering, bli beskrevet.
Arkivperiode og arkivdel
Ved periodisering spiller arkivdel en sentral rolle. Arkivdelene representerer forskjellige perioder, og det er mappenes tilhørighet til arkivdel som avgjør hvilken periode de befinner seg i. Arkivdelens arkivstatus gir informasjon om det dreier seg om en aktiv periode, overlappingsperiode eller avsluttet periode. Arkivdelene må dessuten ha en referanse seg i mellom, slik at en kan knytte sammen forløper og arvtaker. Arvtakeren må være tilknyttet samme klassifikasjonssystem som forløperen.
Dokumenter som skal periodiseres etter forskjellige prinsipper - f.eks. funksjonsordnede saksmapper som periodiseres ved overlappingsperiode og personalmapper som fortløpende periodiseres når de er uaktuelle - må tilhøre hver sin arkivdel. Flere arkivdeler kan altså være aktive på én gang, og de uaktuelle periodene kan utgjøre flere "generasjoner" med arkivperioder.
|
Krav nr. |
Strukturelle krav til Periodisering |
Type |
Merknad |
|---|---|---|---|
|
|
En arkivdel skal kunne inneholde en tekstlig beskrivelse av hvilke prinsipper den skal periodiseres etter. |
O |
|
|
|
En arkivdel skal inneholde referanser til eventuelle forløpere og arvtakere. |
O |
|
Funksjonalitet ved periodisering
En arkivdel som inneholder en aktiv periode, er åpen for all registrering. Nye mapper skal kunne knyttes til arkivdelen etter hvert som de opprettes.
En arkivdel som inneholder en avsluttet periode, er stengt for nye mapper, og mappene som allerede finnes skal være avsluttet. En avsluttet arkivdel er altså "frosset" for all ny tilvekst av mapper og dokumenter, og stort sett også for endring av metadata.
En arkivdel som inneholder en overlappingsperiode står i en mellomstilling. Nye mapper kan ikke tilknyttes, men eksisterende mapper kan fremdeles være åpne. Det tillates at det legges en ny registrering til en mappe i overlappingsperioden. Men løsningen skal da automatisk overføre hele denne mappen til arkivdelen som er arvtaker. Det betyr altså at hele mappen med alle registreringer og tilknyttede dokumenter skifter tilhørighet fra en arkivdel til en annen automatisk. Før statusen til overlappingsperioden settes til avsluttet, må det kontrolleres at det ikke finnes flere åpne mapper igjen. Dersom det er tilfelle, må mappene enten avsluttes eller overføres manuelt til arvtakeren. Det skal være mulig å overføre alle åpne mapper i en samlet, automatisert prosess.
Selv om det ikke er tillatt å knytte nye mapper til en avsluttet arkivdel, skal det være mulig å flytte avsluttede mapper til en slik arkivdel. Dersom det ikke benyttes overlappingsperiode, f.eks. i forbindelse med periodisering av personmapper, kan det være aktuelt å opprette en tom arkivdel med status som en avsluttet periode. Personmappene kan da flyttes hit fortløpende etter hvert som de blir uaktuelle.
Flytting av mapper til en avsluttet arkivdel kan skje manuelt, dvs. at en endrer tilknytningen til arkivdel for hver enkelt mappe. Men det bør også finnes en funksjon for å flytte en gruppe med mapper til en avsluttet arkivdel under ett. Dette kan f.eks. utføres for alle mapper som er søkt fram etter bestemte kriterier.
|
Krav nr. |
Funksjonelle krav til Periodisering |
Type |
Merknad |
|---|---|---|---|
|
|
Det skal være mulig å knytte nyopprettede mapper til en arkivdel som inneholder en aktiv arkivperiode. |
O |
|
|
|
En arkivdel som inneholder en overlappingsperiode, skal være sperret for tilføyelse av nyopprettede mapper. Men eksisterende mapper i en overlappingsperiode skal være åpne for nye registreringer. |
O |
|
|
|
Dersom en ny registrering føyes til en mappe som tilhører en arkivdel i overlappingsperiode, skal mappen automatisk overføres til arkivdelens arvtaker. |
O |
|
|
|
En arkivdel som inneholder en avsluttet arkivperiode, skal være sperret for tilføyelse av nye mapper. Alle mapper skal være lukket, slik at heller ingen registreringer og dokumenter kan føyes til. |
O |
|
|
|
Det bør være umulig å avslutte en arkivdel i overlappingsperiode dersom den fremdeles inneholder åpne mapper. |
A |
|
|
|
Det skal være mulig å få en oversikt over mapper som fremdeles er åpne i en overlappingsperiode. |
O |
|
|
|
Det skal være mulig å overføre åpne mapper fra en arkivdel i en overlappingsperiode til arkivdelens arvtaker. |
O |
|
|
|
Det skal være mulig å overføre i en samlet, automatisert prosess. |
O |
|
|
|
Det skal være mulig å flytte avsluttede mapper til en arkivdel som inneholder en avsluttet periode. |
O |
|
|
|
Det skal være mulig å flytte en gruppe av avsluttede mapper til en arkivdel som inneholder en avsluttet periode i en automatisert prosess. |
O |
|
|
|
Dersom dokumentene i en arkivdel er ikke-elektroniske (fysiske),skal det også være mulig å registrere oppbevaringssted. |
O |
|
En avlevering vil si en overføring av arkivmateriale fra arkivskaper til arkivdepot. Offentlige organer skal avlevere arkivmateriale som det er fattet bevaringsvedtak for. Hovedregelen er at materialet skal avleveres 25 år etter at det har oppstått, fordi en da regner med at det har gått ut av vanlig administrativt bruk. En avlevering innebærer at råderetten for materialet overføres fra arkivskaper til arkivdepot. Det er arkivdepotet som for fremtiden må vedlikeholde materialet, og gjøre det tilgjengelig for brukere.
Avlevering av fysiske arkiver innebærer en flytting fra et oppbevaringssted til et annet. Avlevering av elektronisk arkivmateriale vil si at det produseres et avleveringsuttrekk som består av metadata og dokumenter, og at en kopi av dette uttrekket sendes til arkivdepotet. I de fleste tilfeller vil elektronisk arkivmateriale først bli overført som deponering, og senere automatisk skifte status til avlevering når det er 25 år gammelt. Ved deponering ligger råderetten over materialet fortsatt hos arkivskaperen. Ved avlevering overtar arkivdepotet råderetten. Skillet mellom avlevering og deponering går utelukkende på denne råderetten, og dermed på ansvaret for all bruk av løsningen. De tekniske kravene og dokumentasjonskravene som stilles til avleveringsuttrekk, er imidlertid identiske ved deponering og avlevering.
Ordningen med deponering forut for avlevering er etablert for å sikre at avleveringsuttrekk blir fremstilt mens løsningene fortsatt er i operativ drift. Årsaken til at ikke også slike tidlige overføringer av materiale formaliseres som avleveringer, er at arkivskaperen fortsatt må ha ansvaret for å betjene seg selv og egne brukere. Arkivdepotet kan normalt ikke overta ansvaret for betjeningen av aktive løsninger. Arkivskaper kan altså ikke slette deponert materiale før det har fått status som avlevert.
Statusskiftet fra deponering til avlevering vil i normale tilfeller skje når den yngste delen av materialet er 25 år gammelt. Dersom avleveringsuttrekket består av årgangsfiler, kan dette skiftet skje suksessivt for hver enkelt årgang ved 25 års alder når forholdene ligger praktisk til rette for dette.
Ved overgangen fra deponering til avlevering kan det være tale om å fremstille og overføre et nytt avleveringsuttrekk. Dette vil være aktuelt dersom informasjonen i uttrekket er blitt korrigert i vedkommende produksjonssystem i deponeringsperioden, for eksempel ved at kassasjoner er gjennomført eller at det er foretatt endringer i skjermingen av metadata eller dokumenter. Fremstillingen av et datauttrekk for arkivering forutsettes imidlertid å være organisert slik at det bare omfatter avsluttede deler eller perioder fra vedkommende løsning.
Det er vedkommende arkivskapers ansvar å besvare henvendelser om materialet så lenge det oppbevares av arkivdepotet med status som deponert.
I dette kapitlet vil det ikke bli skilt mellom deponering og avlevering. Når vi her snakker om avlevering, omfatter det også deponering.
Metadata for avlevering
I forbindelse med at det produseres avleveringsuttrekk, skal det genereres metadata om dette som grupperes inn i metadata for arkivdel.
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M606 |
ansvarligEksport |
Obligatorisk |
En |
Avleveres |
|
M607 |
eksportertDato |
Obligatorisk |
En |
Avleveres |
|
M608 |
antallMapperEksportert |
Obligatorisk |
En |
Avleveres |
|
M609 |
antallRegistreringerEksportert |
Obligatorisk |
En |
Avleveres |
|
M610 |
antallDokumenterEksportert |
Obligatorisk |
En |
Avleveres |
Overordnede krav til avleveringsuttrekk
Overordnede krav til hvilke metadata et avleveringsuttrekk skal bestå av, og hvordan metadata og dokumenter skal organiseres i et slikt uttrekk, er definert i ISO 14571 OAIS (Open Archival System). Disse kravene vil også bli lagt til grunn for avleveringsuttrekk fra Noark 5. Det betyr at et avleveringsuttrekk skal utgjøre en Submission Information Package i henhold til OAIS. Det norske uttrykket for dette er informasjonspakke for avlevering.
Hvilke metadataelementer som skal tas med i et uttrekk vil gå fram av den konseptuelle modellen for Noark 5 og metadatakatalogen. Avleveringens struktur er definert i Arkivverkets XML skjema for avlevering fra Noark 5-kjerner, mens gyldige formater for dokumentene (arkivformater), er definert i Forskrift til arkivloven av 1. desember 1999 nr. 1566 om utfyllende tekniske og arkivfaglige bestemmelser om behandling av offentlige arkiver, kapittel VIII. Her finnes også andre krav til avleveringsuttrekk, bl.a. organisering av filer i uttrekket.
|
Krav nr. |
Overordnede krav til avleveringsuttrekk |
Type |
Merknad |
|---|---|---|---|
|
|
Det skal være mulig å produsere avleveringsuttrekk bestående av metadata og dokumenter. |
O |
|
|
|
Avleveringsuttrekket skal utgjøre en Submission Information Package, slik dette er definert i ISO 14571 OAIS. |
O |
|
|
|
Formatet til metadatadelen av avleveringsuttrekket skal være XML (XML 1.0). |
O |
|
|
|
Tegnsettet til metadatadelen av avleveringsuttrekket skal være UTF-8. |
O |
|
|
|
Metadataelementer som ikke har verdi, skal utelates fra avleveringsuttrekket. I uttrekket skal det med andre ord ikke forekomme tomme elementer med kun start- og slutt-tagg. |
O |
|
|
|
Strukturen og innholdet til metadatadelen av avleveringsuttrekket skal følge Arkivverkets XML Schema for avlevering fra Noark 5-kjerner (eget vedlegg). |
O |
|
|
|
Alfanumeriske verdier i avleveringsuttrekket skal representeres vha. XML Schema-datatypen string. |
O |
|
|
|
Datoer uten klokkeslett i avleveringsuttrekket skal representeres vha. XML Schema-datatypen date. |
O |
|
|
|
Datoer med klokkeslett i avleveringsuttrekket skal representeres vha. XML Schema-datatypen dateTime. |
O |
|
|
|
Format på dokumenter i avleveringsuttrekket skal være et av arkivformatene definert i Forskrift til arkivloven av 1. desember 1999 nr. 1566 om utfyllende tekniske og arkivfaglige bestemmelser om behandling av offentlige arkiver, kapittel VIII. |
O |
|
|
|
Organiseringen av filene i avleveringsuttrekket skal følge Forskrift til arkivloven av 1. desember 1999 nr. 1566 om utfyllende tekniske og arkivfaglige bestemmelser om behandling av offentlige arkiver, kapittel VIII. |
O |
|
Omfanget av et avleveringsuttrekk
Omfanget av et avleveringsuttrekk fra sakarkiver skal være bestemt av innholdet i en avsluttet arkivdel. Alle dokumenter og metadata som er knyttet til arkivdelen, skal inngå i uttrekket. Dersom dokumentene er fysiske, vil uttrekket bare bestå av metadata. Alle metadata som er merket med "Avleveres" i metadatatabellene skal tas med i uttrekket dersom de har en verdi - dvs. ikke er tomme. Også arkivenheter som ikke har dokumenter knyttet til seg skal inngå i uttrekket. Det gjelder f.eks. klasser som ikke inneholder mapper (ubrukte arkivkoder), og det gjelder mapper som utgår pga. feilregistrering eller flytting av registreringer til andre mapper.
Uttrekket skal bare inneholde dokumenter i arkivformat. Dersom dokumentet er arkivert med i flere versjoner, skal alle dokumentversjonene inngå. Det samme gjelder dersom dokumentet er arkivert i flere varianter.
Dokumenter som er kassert før uttrekket produseres, skal ikke være med. Men metadataene om disse dokumentene ned til dokumentbeskrivelsesnivået, skal være med.
Som et alternativ til uttrekk av hele arkivdeler, bør det også være mulig å produsere uttrekk på grunnlag av en startdato og en sluttdato, f.eks. opprettetDato for en mappe. Uttrekk med et omfang basert på alle registreringer innenfor et gitt tidsrom, er mest aktuelt for enkelte fagsystemer. Et slikt uttrekk vil da være uavhengig av tilhørighet til arkivdel.
|
|
Krav til omfanget av et avleveringsuttrekk |
Type |
Merknad |
|---|---|---|---|
|
|
Et avleveringsuttrekk fra et elektronisk sakarkiv skal bestå av alle metadata merket "Avleveres", samt av alle dokumenter i arkivformat i en avsluttet arkivdel. |
O |
|
|
|
Et avleveringsuttrekk fra et fysisk sakarkiv skal bestå av alle metadata merket "Avleveres" i en avsluttet arkivdel. |
O |
|
|
|
Alle arkiverte dokumentversjoner i den avsluttede arkivdelen skal inngå i uttrekket. |
O |
|
|
|
Alle arkiverte dokumentvarianter i den avsluttede arkivdelen skal inngå i uttrekket. |
O |
|
|
|
Dokumenter som er kassert når uttrekket produseres, skal ikke inngå. Men metadata om kasserte dokumenter ned til dokumentbeskrivelsesnivå, skal tas med. |
O |
|
|
|
Det bør være mulig å produsere et avleveringsuttrekk på grunnlag av en startdato og en sluttdato. |
A |
|
Krav til innholdet i en informasjonspakke for avlevering
OAIS grupperer innholdet i en informasjonspakke i fire hoveddeler:
Innholdsinformasjon (Content Information): Innholdet - eller budskapet - i selve dokumentene. Det er dokumentene som er gjenstand for bevaring, og de skal bevares med opprettholdt integritet og autentisitet. Oftest vil innholdsinformasjon være tekst, men kan også være tegninger, bilder, lyd eller video.
Bevaringsbeskrivende informasjon (Preservation Description Information). Den viktigste gruppen med metadata. Deles inn i følgende undergrupper:
Referanseinformasjon (Reference Information). Entydig identifikasjon av dokumentene og metadataene. Alle arkivenheter i skal identifiseres med en systemID.
Proveniensinformasjon (Provenance Information). Dokumentasjon om arkivdokumentenes opprinnelse, f.eks. hvilken arkivskaper som har skapt dem. Metadata knyttet til arkivenhetene arkiv og arkivdel inneholder slik informasjon.
Kontekstinformasjon (Context Information). Dokumentasjon av arkivdokumentenes tilknytning til omgivelsene. Eksempler på slik informasjon er tilknytningen til aktiviteten (prosessen) som har skapt dokumentet, når dokumentet ble skapt og hvem som har skapt det. Relasjoner mellom forskjellig arkivenheter, f. eks. hvilke arkivdokumenter som hører sammen under en felles mappe, er også kontekstinformasjon. Metadata om kontekst finnes i de fleste arkivenheter, men særlig i klasse, mappe og registrering .
Integritetsbevarende informasjon (Fixity Informasjon). Metadata som garanterer at dokumentets autentisitet og integritet er opprettholdt, dvs. at det er ekte og at det ikke har vært endret etter at det ble arkivert. Alle dokumenter skal påføres en sjekksum, og det skal også genereres en sjekksum for metadataene.
Pakkeinformasjon (Packaging Information). Dette er overordnet informasjon som binder sammen alle digitale objekter i pakken. Det viktigste her er referansen mellom metadataene og dokumentene.
Beskrivende informasjon (Descriptive Information). Dette er metadata som inngår i søke- og framfinningsmidler hos arkivskaperen (f.eks. i Asta-systemer), og som arkivdepotet selv føyer til etter avlevering. Disse metadataene vil ofte kunne trekkes ut av den bevaringsbeskrivende informasjonen, f.eks. navn på klassifikasjonsverdi eller mappebeskrivelse (”sakstittel”). I tillegg skal to rapporter inngå i et avleveringen: Løpende journal og offentlig journal. Arkivdepotet kan publisere disse som fremfinningsmiddel.
For at det skal være mulig å tolke digitale objekter (både dokumenter og metadata) trengs det dessuten representasjonsinformasjon (Representation Information). Dette kalles også tekniske metadata. Teknisk informasjon vil kunne være knyttet til dokumentobjektet, f.eks. informasjon om dokumentets format. Det er ikke tatt med mange tekniske metadata i Noark 5, da en går ut fra at mye vil være allment kjent og finnes dokumentert andre steder (Knowledge Base). Det gjelder f.eks. den detaljerte dokumentasjonen av de forskjellige dokumentformatene. Når det gjelder metadataene er strukturen på disse dokumentert som et XML-schema som følger som et eget vedlegg.
|
Krav nr. |
Krav til innholdet i en informasjonspakke |
Type |
Merknad |
|---|---|---|---|
|
|
Hvert dokument i arkivformat skal eksporteres som en fil i avleveringsuttrekket. Forskjellige dokumentversjoner og dokumentvarianter eksporteres som egne filer. |
O |
|
|
|
Til hvert dokument skal det finnes et dokumentobjekt som inneholder en entydig referanse til dokumentfila. |
O |
|
|
|
Dokumentobjektet skal inneholde en sjekksum som er generert på grunnlag av innholdet i det tilhørende dokumentet. Det skal også dokumenteres hvilken algoritme som ble brukt for å generere sjekksummen. |
O |
|
|
|
Det skal også genereres en sjekksum for alle metadata i avleveringsuttrekket. |
O |
|
|
|
Metadata for hele arkivstrukturen skal eksporteres som en fil. Dersom denne fila blir svært stor, åpner XML-schemaet for eksport som flere filer. |
O |
|
|
|
Endringsloggen skal eksporteres som en separat fil. |
O |
|
|
|
Offentlig journal (kap. 4.3.6.2) og løpende journal (ap. 4.3.6.3) skal inngå i avleveringen. Disse journalene skal selekteres innenfor samme tidsrom som arkivperiodeStartDato og arkivperiodeSluttDato i den avsluttede arkivdelen. |
O |
|
Sammenligning med avleveringsformatet i Noark-4
I Noark-4 skulle strukturerte data avleveres som tabelluttrekk i XML-format. Hver tabell - slik disse var spesifisert i den tekniske delen av kravspesifikasjonen - skulle eksporteres til hver sin fil. Tabell-uttrekkene skulle inneholde de aller fleste attributtene i Noark 4, det ble ikke skilt mellom metadata og systemdata. Antall tabelluttrekk ville variere fra løsning til løsning, og måten løsningen var implementert på. Kravspesifikasjonen i Noark 4 bestod av 95 tabeller, hvorav 39 av disse inneholdt obligatoriske attributter. En egen fil kalt NOARKIH.XML skulle dokumentere hvilke tabeller og hvilke attributter som var inkludert i uttrekkene. Dokumentene skulle eksporteres som enkeltfiler, og referansen mellom tabelluttrekkene og dokumentene skulle inngå som et attributt i tabellen DOKVERSJON.
Den overordnede tanken bak dette avleveringsformatet, var at data skulle kunne importeres inn i en løsning for tilgjengeliggjøring som var bygd opp rundt en lignende datamodell som den opprinnelige produksjonsløsningen. Men i praksis har dette vist seg vanskelig å gjennomføre, fordi tabelluttrekkene ofte inneholdt inkonsistente data som gjorde import umulig. En har derfor valgt å gå vekk fra tabelluttrekk i Noark 5.
Avleveringen inneholdt også en annen type eksport, såkalte rapportuttrekk. Rapportuttrekkene skulle omfatte de samme saker og journalposter som tabelluttrekkene, men være strukturert som hierarkiske (nøstede) XML-filer. Data skulle sorteres og sammenstilles på samme måte som en kan gjøre i en rapport (utskrift), derav navnet rapportuttrekk. I Noark-4 skulle to slike filer medfølge ved overføring til depot: Kronologisk (løpende) journal og Sak- og dokumentoversikt. Den samme informasjonen skulle altså overføres til depot i to forskjellige hovedformater, tabelluttrekk og rapportuttrekk. Det nye avleveringsformatet i Noark 5 bygger delvis på strukturen i Sak- og dokumentoversikt.
I dette kapitlet ligger Noark 5 kjernens krav til systemteknisk administrasjon av Noark 5 kjernen. Kravene skal legge til rette for at arkivansvarlige skal kunne administrere og ha kontroll på arkivet, arkivstrukturen og metadataene som hører til arkivenhetene i strukturen, dvs. legge inn grunnlagsdata som typer mapper og registreringer, og hvilke metadata utover de obligatoriske som skal kunne legges til disse.
Det skal også gi muligheter for feilretting utover det som ellers er tillatt etter reglene for endring og frysing av metadata og dokumenter i løsningen.
Løsningen må dessuten legge til rette for at administratorer har kontroll på arkivdokumentene og hvilke formater disse er lagret i. Det vil også si å kunne implementere vedtatte regler for når konvertering skal skje.
|
Krav nr. |
Krav til administrasjon av kjernen |
Type |
Merknad |
|---|---|---|---|
|
|
Det skal finnes en tjeneste/funksjon for å administrere kjernen |
O |
|
|
|
Det må kunne defineres minimum én bruker som er arkivadministrator, som kan logge seg eksplisitt på Noark 5 kjernen for å endre konfigurasjon og globale parametere |
O |
|
|
|
Det skal finnes en tjeneste/funksjon for å opprette, redigere og slette arkivenheter (arkiv, arkivdel, klassifikasjonssystem, klasse, mappe, registrering, dokumentbeskrivelse og dokumentobjekt) og tilknyttede metadata. Slike registreringer skal logges. |
O |
|
|
|
Et Arkiv og arkivets metadata skal kun opprettes gjennom Administratorfunksjonen for Noark 5 kjerne. |
O |
|
|
|
Et Underarkiv skal kun defineres og endres gjennom Administratorfunksjonen for Noark 5 kjerne. |
O |
|
|
|
En Arkivdel og arkivdelens metadata skal kun opprettes og endres gjennom Administratorfunksjonen for Noark 5 kjerne. |
O |
|
|
|
Det skal finnes en tjeneste/funksjon som gjør det mulig for arkivadministrator å gå utover de rollebaserte tilgangsbegrensninger som er definert i løsningen. |
O |
|
|
|
Det skal finnes en tjeneste/funksjon som gjør det mulig for arkivadministrator å angi hvilke dokumentformater som er definert som arkivformater |
O |
|
|
|
Det skal finnes en tjeneste/funksjon som gjør at arkivadministrator kan sette opp regler for når (hvilke statuser) arkivdokumenter skal konverteres til arkivformat |
O |
|
|
|
Det skal være mulig å parameterstyre om dokumenter skal konverteres til arkivformat når status på dokumentbeskrivelse settes til ’Dokumentet er ferdigstilt’. |
O |
|
|
|
Det bør være mulig å parameterstyre at status ’Dokumentet er ferdigstilt’ skal settes automatisk på Dokumentbeskrivelse ved andre statuser på Mappe eller Registrering |
A |
|
|
|
Det skal være mulig å parameterstyre om alle eller spesielt merkede versjoner skal konverteres til arkivformat. |
O |
|
|
|
Det skal finnes en tjeneste/funksjon og rapportering for filformattesting av dokumentene som er lagret i kjernen. Rapporten skal gi oversikt over hvilke mapper, registreringer og/eller dokumentbeskrivelser som ikke inneholder dokumenter lagret i godkjent arkivformat. |
O |
|
|
|
Det skal være mulig å parameterstyre at bare autoriserte enheter, roller eller personer skal ha rett til å arkivere en ny versjon av et dokument på en Registrering med status ekspedert, journalført eller avsluttet. |
O |
|
|
|
Det skal være mulig å parameterstyre at bare autoriserte roller, enheter og personer skal kunne slette inaktive versjoner, varianter og formater av et dokument |
O |
|
Metadata for endringslogg
Metadata for endringslogg skal avleveres som en egen fil. Disse metadataene skal altså ikke grupperes inn sammen med de øvrige metadata. Endringsloggen må derfor ha referanse til hvilken arkivenhet den tilhører, og hvilket metadataelement som er endret.
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avleveres |
|
M680 |
referanseArkivenhet |
Bet. oblig. |
En |
Avleveres |
|
M681 |
referanseMetadata |
Bet. oblig. |
En |
Avleveres |
|
M682 |
endretDato |
Bet. oblig. |
En |
Avleveres |
|
M683 |
endretAv |
Bet. oblig. |
En |
Avleveres |
|
M684 |
tidligereVerdi |
Bet. oblig. |
En |
Avleveres |
|
M685 |
nyVerdi |
Bet. oblig. |
En |
Avleveres |
Et viktig krav i Noark 5 er at arkiverte elektroniske dokumenter ikke skal kunne slettes. Kontrollert sletting skal bare kunne foretas av autoriserte brukere i forbindelse med kassasjon, se kap. 4.2.10 Bevaring og kassasjon.
Dessuten kan dokumenter slettes av autoriserte brukere dersom de er formelt avlevert til et arkivdepot, se kap. 4.2.12 Avlevering. Det understrekes at dette siste bare gjelder avleverte dokumenter, ikke dokumenter som bare er deponert til arkivdepotet.
Dersom et dokument er arkivert i mer enn én versjon, skal det være mulig å slette de eldre versjonene. Vanligvis er det bare den siste, ferdiggjorte versjon som skal arkiveres. Men det kan også være aktuelt å arkivere tidligere versjoner dersom disse har dokumentasjonsverdi. Det kan f.eks. være tilfelle dersom en leder har gjort vesentlige endringer i utkastet til en saksbehandler. Saksbehandlers utkast kan da arkiveres som en tidligere versjon av det ferdige dokumentet. Dette vil gi ekstra dokumentasjon om selve saksbehandlingsforløpet.
Dersom tidligere versjoner er blitt arkivert unødvendig, skal det være mulig å rydde opp på en effektiv måte. Slik opprydding skal alltid skje før det produseres et avleveringsuttrekk.
|
Krav nr. |
Krav til Sletting av dokumenter |
Type |
Merknad |
|---|---|---|---|
|
|
Autoriserte brukere skal kunne slette en arkivert inaktiv dokumentversjon. Den siste, endelige versjonen skal ikke kunne slettes. |
O |
|
|
|
Det skal være mulig å søke fram dokumenter som er arkivert i flere versjoner. |
O |
|
|
|
Det bør være mulig å utføre sletting av mange inaktive dokumentversjoner samtidig, f.eks. alle inaktive dokumentversjoner som funnet etter et søk. |
A |
|
|
|
Sletting av arkiverte inaktive dokumentversjoner skal logges. |
O |
|
Dersom det opprinnelige dokumentet har innhold som skal skjermes, kan det lages en variant hvor opplysninger som skal skjermes, er fjernet. På den måten kan dokumentet likevel offentliggjøres.
Slike varianter kan slettes dersom det ikke lenger er behov for dem. Det kan tenkes at det er aktuelt å avlevere dokumentvarianter, så sletting må vurderes i hvert enkelt tilfelle. Varianter som ikke er slettet når avleveringsuttrekket produseres, skal avleveres.
|
Krav nr. |
Krav til Sletting av dokumenter |
Type |
Merknad |
|---|---|---|---|
|
|
Autoriserte brukere skal kunne slette en arkivert dokumentvariant. Det opprinnelige dokumentet skal ikke kunne slettes. |
O |
|
|
|
Det skal være mulig å søke fram arkiverte dokumentvarianter. |
O |
|
|
|
Det bør være mulig å slette mange dokumentvarianter samtidig, f.eks. alle dokumentvarianter som er funnet etter et søk. |
A |
|
|
|
Sletting av arkiverte dokumentvarianter skal logges. |
O |
|
Alle dokumenter som skal avleveres, må være konvertert til arkivformat. Det opprinnelige produksjonsformatet kan da rutinemessig slettes. En del brukere vil nok velge å beholde produksjonsformatet inntil videre, f.eks. fordi de har behov for å gjenbruke tekst i et kontorstøtteverktøy. Hvor lenge dette er aktuelt, er opp til hver enkelt bruker. Det er ikke noe krav at produksjonsformatene må være slettet før avleveringsuttrekket produseres, fordi dette bare vil ta med dokumenter i arkivformat. Men mange brukere vil likevel ha et behov for å gå gjennom og slette eldre produksjonsformater på en effektiv måte.
|
Krav nr. |
Krav til Sletting av dokumenter |
Type |
Merknad |
|---|---|---|---|
|
|
Autoriserte brukere skal kunne slette et arkivert dokument i produksjonsformat dersom dokumentet er blitt konvertert til arkivformat. Dokumentet i arkivformat skal ikke kunne slettes. |
O |
|
|
|
Det skal være mulig å søke fram dokumenter arkivert i produksjonsformat. |
O |
|
|
|
Det bør være mulig å slette mange produksjonsformater samtidig, f.eks. alle produksjonsformater som er funnet etter et søk. |
A |
|
|
|
Sletting av arkiverte produksjonsformater skal logges. |
O |
|
Noark 5 kjerne krav til eksterne (valgfrie) løsninger
Noark 5 kjerne er avhengig av å virke sammen med forskjellige forsystemer implementert etter den enkelte virksomhets eller leverandørs behov.
For at Noark 5 skal fungere i et helhetlig arkivsystemmiljø, må Noark 5 kunne integreres med en del forsystemer/fagsystemer som må implementeres for å komplettere en journal- og arkivløsning.
Dette kapitlet legger således føringer og krav på de forskjellige fag- eller forsystemer som kan være frittstående løsninger i forhold til Noark 5. Disse kravene må anses som en del av Noark 5 kjernekrav og må oppfylles for at en systemløsning skal kunne godkjennes som en Noark 5-løsning.

Noark 5 legger opp til at administrering av organisasjonsstrukturen skal kunne utføres i eksterne løsninger. For å sikre en forsvarlig arkivering stiller allikevel kjernen visse krav til disse løsningene, og hvordan kjernen skal kunne forholde seg til dem.
Konseptuell modell
for Administrativ enhet <
Administrativ enhet>

Metadata for administrativ enhet
I Noark 5 blir ikke informasjon om administrativ oppbygning sett på som en del av arkivstrukturen. Slik informasjon trenger ikke å lagres i Noark 5-kjernen, og den skal heller ikke overføres til depot ved avlevering. Men dersom navn på ansvarlig enhet er registrert på en mappe eller en registrering (journalpost), skal dette inngå som metadata for disse arkivenhetene.
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avlever |
|
|
M583 |
administrativEnhetNavn |
Obligatorisk |
En |
|
|
|
M600 |
opprettetDato |
Obligatorisk |
En |
|
|
|
M601 |
opprettetAv |
Valgfri |
En |
|
|
|
M602 |
avsluttetDato |
Bet. oblig. |
En |
|
|
|
M584 |
administrativEnhetsstatus |
Valgfri |
En |
|
|
|
M585 |
referanseOverordnet Enhet |
Bet. oblig. |
En |
|
|
Krav til administrativ oppbygging
|
Krav nr. |
Kjernens krav til administrativ oppbygging |
Type |
Merknad |
|---|---|---|---|
|
|
Alle administrative enheter som skal ha tilgang til objekter i kjernen, skal være identifisert og gjenkjennes av kjernen. |
O |
|
|
|
En administrativ enhet som ikke lenger skal ha tilgang til objekter i kjernen, skal fortsatt være identifisert i kjernen, men med en status som indikerer at den er ”passiv”. |
O |
|
|
|
Det skal finnes en oversikt over hvilket eller hvilke tidsrom hver administrative enhet har vært aktiv. |
O |
|
Noark 5 legger opp til at administrasjon av brukerne av løsningen skal kunne utføres i eksterne system. For å sikre en forsvarlig arkivering stiller allikevel kjernen visse krav til disse systemene, og hvordan kjernen skal kunne forholde seg til dem.
Metadata for bruker
Metadata for bruker skal ikke avleveres, men skal kunne migreres mellom løsninger.
|
Nr. |
Navn |
Obligatorisk |
Forekomst |
Avlever |
|
M580 |
brukerNavn |
Obligatorisk |
En |
|
|
M581 |
brukerRolle |
Obligatorisk |
En |
|
|
M600 |
opprettetDato |
Obligatorisk |
En |
|
|
M601 |
opprettetAv |
Valgfri |
En |
|
|
M602 |
avsluttetDato |
Bet. oblig. |
En |
|
|
M582 |
brukerstatus |
Valgfri |
En |
|
Krav til brukeradministrasjon
|
Krav nr. |
Kjernens krav til brukeradministrasjon |
Type |
Merknad |
|---|---|---|---|
|
|
Alle brukere som skal ha tilgang til enheter i kjernen, skal være identifisert og gjenkjennes av kjernen. |
O |
|
|
|
Kjernen skal kunne gjenkjenne i hvilken administrativ sammenheng brukeren virker til enhver tid. |
O |
|
|
|
En bruker som ikke lenger skal ha tilgang til enheter i kjernen skal fortsatt være identifisert i kjernen, men med en status som indikerer at den er ”passiv” |
O |
|
|
|
Det skal finnes en oversikt over hvilket eller hvilke tidsrom hver bruker har vært aktiv. |
O |
|
Noark 5 legger opp til at det enkelte organ selv skal kunne definere hvilke roller og tilknyttede rettigheter brukerne av løsningen skal ha, innenfor de rammene som er satt av de generelle begrensningene i standarden mht. frysing av dokumenter og metadata. Generell administrasjon av de ulike rollene trenger ikke gjøres i kjernen. Fra kjernen stilles det kun krav om at det eksterne systemet skal ha en løsning for å administrere tilgang til kjernen.
Noark 5 kjerne har ikke noe eget definert brukergrensesnitt. All saksbehandling, herunder alle aktiviteter knyttet til arkivdanning som utføres av brukere av løsningen, må dermed utføres fra forsystem. For at arkivdanning skal kunne skje, og skje forsvarlig, må dermed kjernen stille visse krav til hvordan dette skal skje fra forsystemene.
I kapittel 4.2, om den indre kjernen, er det allerede gitt krav som legger til rette for at arkivdanning skal kunne finne sted. Dette er generelle krav som gjør det mulig å opprette mapper, registreringer, dokumentbeskrivelser, osv, og tilføre disse metadata. Dette kapitlet presiserer og avgrenser de generelle kravene, slik at kontrollert arkivdanning skal kunne finne sted fra ethvert forsystem.
Kravene til saksbehandling mot Noark 5-kjerne er altså minimumskrav. Leverandørene og brukere står fritt til å definere og utvikle funksjoner som går utover de obligatoriske kravene.
|
Krav nr. |
Funksjonelle krav til saksbehandling på mappenivå |
Type |
Merknad |
|---|---|---|---|
|
|
Det skal finnes en tjeneste/funksjon for å ajourholde utlån av en Saksmappe. |
O |
|
|
|
Det skal finnes en tjeneste/funksjon for å avslutte en Basismappe (dvs at avsluttetDato settes). |
O |
|
|
|
Det skal finnes en tjeneste/funksjon for å sette Status på en Saksmappe. |
O |
|
|
|
Følgende statusverdier er obligatorisk for Saksmappe:
|
O |
|
|
|
Følgende statusverdier er anbefalt for Saksmappe:
|
A |
|
|
|
Det skal ikke være mulig å avslutte en Saksmappe uten at det er angitt en primær klassifikasjon (Klasse). |
O |
|
|
|
Det skal ikke være mulig å avslutte en Saksmappe som inneholder Registreringer som ikke er avsluttet |
O |
|
|
|
Det skal ikke være mulig å avslutte en Saksmappe som inneholder Registreringer som ikke er avskrevet |
O |
|
|
|
Det skal ikke være mulig å avslutte en Saksmappe i en arkivdel for elektroniske dokumenter hvis den inneholder Registreringer som ikke er tilknyttet elektroniske dokumenter |
O |
|
|
|
Det skal ikke være mulig å avslutte en Saksmappe uten at alle hoveddokumenter på registreringene i mappen er lagret i arkivformat |
O |
|
|
|
Det skal ikke være mulig å avslutte en Saksmappe uten at alle restanser på Registreringer er avskrevet |
O |
|
|
|
Når statusen til en Saksmappe settes til avsluttet, skal det på mappenivå ikke være mulig å endre metadataene: |