Med grunnlag i presentert forslag fra HK-data og Fredrikstad kommune, vil Visma gjerne komme med sine innspill og vurderinger.

Transkript

1 Tilbakemelding virksomhetsspesifikke metadata fra Visma Ref. ide-workshop tirsdag og fremlagt forslag for Virksomhetsspesifikke metadata for fagområdet PPT. Med grunnlag i presentert forslag fra HK-data og Fredrikstad kommune, vil Visma gjerne komme med sine innspill og vurderinger. Kriterier for arkivering av virksomhetsspesifikke metadata (VSMD) Visma stilte flere ganger under ide-workshop en spørsmål om hvilke kriterier som skal ligge til grunn for å etablere VSMD-data. Hvorfor skal de arkiveres, og til hvilket formål? Føler dette spørsmålet fortsatt er uavklart. Dersom man tenker seg modellen presentert i rapporten fra KDRS om å arkivere alle metadata som VSMD, mener Visma dette ikke er en god modell fordi: Vi får ikke en felles standardisert VSMD-modell, men en fagsystemavhengig modell Å arkivere alt vil medføre en veldig stor forvaltningsoppgave i ettertid, fordi metadata i fagsystemene endres fortløpende både med brukerønsker og myndighetskrav. VSMD-modellen må i tilfelle endres tilsvarende. Om man tenker seg at metadata ene skal være tilgjengelig for søk/lesing i Noark5-arkivkjerner og generelle sak-/arkivsystem vil man få en urealistisk stor tilpasningsjobb, og ikke minst forvaltningsjobb i etterkant når metadata endres/justeres. I dag praktiseres database-dump i SIARD2-format som supplement til Noark5, og Visma ser for seg at dette kan bli et mer standardisert supplement til Noark5-avlevering. Dersom et av hovedkriteriene for sektorspesifikke VSMD skal være søk/gjenfinning, så må vi sette noen krav til hvordan disse data ene skal presenteres i brukergrensesnittet til arkivet Skal de være søkbare i den aktive arkivdelen, altså for arkivtjenesten i daglig bruk Eller tenker vi at de skal ligge «skjulte» i det aktive arkivet, og bare berike den deponerte/avleverte delen av arkivet Arkade5 må uansett tilpasses de ulike sektorspesifikke VSMD modellene Basert på disse vurderingene og vurderinger fra de andre deltakerne i workshopen, bør vi klare å definere noen kriterier for etablering av VSMD sektorvis. Visma sine tanker er som følger: Som en start bør VSMD være på et minimumsnivå som er klart begrunnet hvorfor de er etablerte Dette vil gi mulighet for de ulike arkivleverandørene å kunne håndtere VSM sektorvis i sine egne løsninger 1

2 Behovet for VSMD bør vurderes (økes/minskes) som del av versjonshåndteringen av Noark5 Tillegg i Noark5 Standard Nye metadata for å hindre digitalt innsyn bør inngå i Noark5 standard og ikke ligge som VSMD. Dette fordi kontroll mot innsyn vil være gjeldende for alle fagområder. Vi må være forberedt på at gjennom sikker autentisering eksempelvis gjennom ID-porten så kan man få tilgang til egne mapper basert på klasse = fnr. Registreringer som da er merket med «Unndratt innsyn» må da skjermes fra innsyns-løsninger. Nye metadata under Registrering: Felt i fagløsning Metadata Noark 5 Verdi Merknad Unndratt innsyn Mxxs-UnndrattInnsyn = Ikke unndratt. 1= Unndratt. Begrunnelse Mxxx-UnndrattInnsynParagraf Tekst Eks: Forv. 18 eller 19 Visma sin vurderinger rundt VSMD Visma genererer arkiv knyttet til personrelaterte fagløsninger med en mappe-i-mappe struktur med personmappe/dossiermappe som øverste nivå (nivå 1) og med spesialisert saksmappe på underliggende nivå (nivå 2). Fordelen med en slik arkivstruktur er at vi lettere kan avlevere en person samlet (alle sakene) når personen avsluttes i fagløsningen. Eksempelet med begrepet «elevmappe» ble brukt under workshop en, og prinsippet blir det samme med mappe-i-mappe strukturen. Hver fagløsning (hver kunde) kobles mot arkiv/arkivdel i Noark5-arkivkjernen, med tilhørende klassifikasjonssystem der vi benytter fnr som objektbasert klassifikasjon (mappe nivå 1) og sakstypen på saken som funksjonsbasert klassifikasjon (mappe nivå 2). Mappe nivå 1 (person-/dossiermappe) Felt i Visma PPT Metadata Noark 5 Verdi Merknad Løpenr klient M003-MappeId Tall Samme identifikasjon på klientene i fagløsningen og i arkivkjernen Navn klient M020-Tittel M600-OpprettetDato Dato dossiermappe opprettet. Skjer automatisk når første arkivdanning skjer M601-OpprettetAv Navn saksbehandler i fagløsningen M602-AvsluttetDato Blir automatisk satt når klienten i fagløsningen avsluttes (ikke lenger aktiv) M603-AvsluttetAv Navn saksbehandler i fagløsningen som avsluttet klienten der VSMD Ingen pr dato 2

3 Vurderinger av potensielle VSMD felt for Dossiermappe, Visma sine anbefaleringer: Felt i Visma PPT Beskrivelse VSMD? Begrunnelse Tilhørighet Distrikt, Skole (styrer tilgangsrettigheter) Nei Bør evt. dokumenteres i de arkiverte hendelsene pga proveniensprinsippet. Hver hendelse er dokumentert med saksbehandler, og Visma anser dette for å være mest viktig som arkivformål og bevaring for ettertiden. Adresse Historikk ved endring Nei Adresse vil fremkomme i korrespondansepartene til journalposten Navn Historikk ved endring Nei Endring logges i N5-endringslogg og avleveres ** Visma sin vurdering blir dermed at det ikke er behov for VSMD knyttet til dossiermapper Mappe nivå 2 (spesialisering saksmappe) Felt i Visma PPT Metadata Noark 5 Verdi Merknad Løpenr klient M003-MappeId Tall Samme identifikasjon på klientene i fagløsningen og i arkivkjernen Sakstype M020-Tittel Fra kodeverk I andre fagløsninger kan Tittel på saken være fritekst M600-OpprettetDato Dato saken arkiveres i fagløsningen. (skjer automatisk ved opprettelse sak) M601-OpprettetAv Navn saksbehandler i fagløsningen M602-AvsluttetDato Dato saken avsluttes i fagløsningen. M603-AvsluttetAv Navn saksbehandler i fagløsningen som avsluttet saken der Saksår M011-Saksår Årstall i dato Automatisk tildeling i fagløsningen Saksnr M012-Sakssekvensnr Teller innen årstall Automatisk tildeling i fagløsningen (starter på 1 ved nytt år) Saksdato M100-Saksdato Dato saken ble opprettet i fagløsningen Kunde/systemeier M305-AdministrativEnhet Tekst Hentes fra organisasjonsnivå saksbehandler tilhører i fagløsningene Saksbehandler M306-Saksansvarlig Tekst Hovedsaksbehandler for saken i fagløsningen Status M052-Saksstatus N5-obl.verdier Under behandling eller Avsluttet. (Utgår benyttes ikke, blir da avsluttet) VSMD Ingen pr dato Vurderinger av potensielle VSMD felt for Saksmappe, Visma sine anbefaleringer: Felt i Visma PPT Beskrivelse VSMD? Begrunnelse Saksnr-Ekstern? Som for HK Data må det vurderes hvordan eksterne saksnr fra eksterne sak- /arkivsystem skal tas vare på i de tilfeller de vil generere sin egen nr.serie Hovedkategori Fra koderegister (hovedvanske i PPT) Nei Vel være dokumentert i den inngående Henvisningen PP-tjenesten mottar, og hos de fleste vil Sakstypen speile hovedkategorien (hovedvansken). Ser ikke behov for at arkivtjenesten trenger å søke på hovedkategorier. Saksbehandlere har denne muligheten i produksjonssystemet (fagløsningen). Og ved innsyn i egen mappe for ettertiden vil hele mappen være interessant, ikke bare enkelte hovedkategorier. 3

4 Konklusjon Fra koderegister (konklusjon i saken) Nei Som for hovedkategori vil konklusjonen fremkomme med begrunnelse i den Sakkyndig vurderingen eller som annen dokumentasjon. Ser heller ikke behovet for arkivtjenesten å kunne søke på konklusjoner, og ved innsyn i ettertid vil dokumentene og hele mappen være interessante. ** Visma sin vurdering blir dermed at det ikke er behov for VSMD knyttet til saksmapper Sakspart gruppert inn i saksmappe? Blir ikke benyttet av Visma i dag med begrunnelse i at Korrespondansepartene i journalpost dokumenter hvem som har vært involvert i hver enkelt hendelse, og at Dossiermappen dokumentere hvem saken direkte gjelder for. Begrepet Sakspart er uklart definert og kanskje misbrukt i dag. Klipp fra Noark5: En part er den som en avgjørelse retter seg mot eller som saken ellers direkte gjelder. I Visma sin fagløsning for PPT er det fritt for å legge inn så mange man ønsker som Familie til klienten med definerte roller som mor, far, onkel etc. I tillegg kan man legge til Nettverk med personer som ikke er direkte i familie, eksempelvis med rolle Lærer, psykolog etc. Hvem og hvor mange av disse rollene skal evt. etableres som saksparter tilknyttet saksmappen må vurderes, også med tanke på GDPR og ikke lagre/arkivere mer enn man har bruk for til det formålet som skal dekkes En utfordring med «saksparter» tilknyttet saksmappen, er at «saksparter» endres over tid, og at ikke de samme «sakspartene» skal ha tilgang til de samme hendelsene i arkivet (ref. punktet lenger oppe med unndratt innsyn). Visma sin vurdering er derfor at ved arkivering fra fagsystem, så er begrepet saksparter tilknyttet saksmappen ikke så veldig relevant. Vurderingen kan være en annen for sak-/arkivsystem som ikke opererer med mapper på flere nivå. Det bør vurderes i fellesskap om «sakspart-informasjon» skal tilknyttes de enkelte hendelsene, eller om korrespondanseparter er nok dokumentasjon for hvem som har fått den aktuelle hendelsen. Registrering (benyttes for journalnotat i fagløsningen) Består i dag av Registrering, Dokumentbeskrivelse og Dokumentobjekt Er i dag tilknyttet en saksmappe (eller direkte på personen i våre gamle fagløsninger) Er i dag arkivert uten M004-RegistreringsId fordi Basisregistrering ikke inngår i dag i Registrering 4

5 Er et ønske om å kunne ta med M020-Tittel i Registrering slik at tittel på Journalnotatet kan vises i arkivet. I dag vises M020-Tittel kun i Dokumentbeskrivelse. Vurderinger av potensielle VSMD felt for Registering, Visma sine anbefaleringer: Felt i Visma PPT Beskrivelse VSMD? Begrunnelse Kategori Fra koderegister (tlf, hjemmebesøk etc.) Nei Arkiveres i dag som M083-Dokumenttype i Dokumentbeskrivelse. Bør holde. ** Visma sin vurdering blir dermed at det ikke er behov for VSMD knyttet til saksmapper Journalpost (benyttes for korrespondanse (inn/ut/internt) i fagløsningen) Består i dag av Registrering, Basisregistrering, Journalpost, Korrespondansepart(er), Dokumentbeskrivelse og Dokumentobjekt Vurderinger av potensielle VSMD felt for Journalpost, Visma sine anbefaleringer: Felt i Visma PPT Beskrivelse VSMD? Begrunnelse Part(er) Hentes fra fagløsningen: - klienten selv - familiemedlemmer på arkiveringstidspunkt? I tilfelle part(er) skal lagres på hver journalpost i tillegg til korrespondansepart(er), så må «aktive» parter hentes inn for hver arkivering. Tilpasning i fagløsningene må gjøres for å kunne merke aktuelle Unndratt innsyn for en eller flere av partene Må hentes fra fagløsningens postjournal (korrespondanse) familiemedlemmer som vil inngå som part i saken.? Må i tilfelle gjøres tilpasninger i fagløsningene der en kobler part mot unndratt innsyn (m/paragraf) for hver postregistrering. Vil være sterkt saksbehandleravhengig at riktig koblinger gjøres. En vurdering bør derfor gjøres om postjournal merket unndratt innsyn skal manuelt vurderes ved innsynsbegjæring, og dermed kan ligge som Noark5- standard metadata uten å være kolet til de ulike partene. ** Visma sin vurdering er at Korrespondanseparter er god nok dokumentasjon for hvem har fått tilsendt og dermed fått tilgang det som er arkivert. Etablering av Parter i tillegg vil bety merarbeid både under etablering og senere forvaltning, og i tillegg være en mulig feilkilde basert på hver enkelt saksbehandler sin vurdering. 5

6 Kommentarer til HK Data og Evry sine innspill. Kommentarer merket med blått relatert til Visma sin løsning/behov. Klientsaker (objektarkiv) saksmappe Felt i HK data Metadata Noark 5 Verdi Merknad Persondata Det meste som tilhører persondata er mappet til noarkfelt Saknr sakeksternnøkkel? Tall (løpende, uten årstall) VSM saksmappe? Riksarkivet og Arkitektum diskuterer denne. Status Dynamisk felt. (Finner ikke i persondata HK oppvekst brukerveiledning, men er det nødvendig å ha med?) Nedtellingsfelt? M052 Saksstatus bør dekke behovet. Saken er avsluttet Hake (ja/nei) Nødvendig? Det vil alltid være nei når sak opprettes. Er det denne som skal oppdatere sak som avsluttet i arkiv? M602 AvsluttetDato bør dekke behovet. Klientsaker (objektarkiv) registrering Felt i HK data Metadata Noark 5 Verdi Merknad Vårt arbeid tittel Vårt arbeid En henvisning kan generere flere vårt arbeid (dersom person overføres til nytt år) I arkivsammenheng bør saken dekke behovet. En sak kan evt. gå over flere år, alt. at det opprettes ny sak dersom barnet eksempelvis går fra barneskolen til ungdomsskolen. Henv. mottatt dd.mm.åååå Brukes for å knytte henvisningen til vårt arbeid M600 Opprettet dato for den inngående registreringen. Startdato dd.mm.åååå M100 Saksdato. Skoleår 20XX/20XX? Ser ikke behovet for skoleår i arkivsammenheng. I fagløsingen ok. Ansvarlig 1 saksbehandler M306-Saksansvarlig for saksmappen. Ansvarlig 2 Ev. VSM saksmappe? Ansvarlig 1 og 2 som er ansvarlige for personen. Trinn Tekst? Ser ikke behov for trinn i arkivsammenheng. Slutt dato dd.mm.åååå M600 AvsluttetDato Skole/barnehage Tekst (navn)? Bør inngå som korrespondanseparter i journalposten 6

7 Kontakt Tekst (navn)? Bør inngå som korrespondanseparter i Journalposten Klientsaker (objektarkiv) - journalpost Felt i HK data Metadata Noark 5 Verdi Merknad Henvisning Henvendelsesdato dokumentetsdato mottattdato Ansvarlig saksbehandler = ansvarlig 1 fra vårt arbeid Kan forekomme flere ganger Hver henvisning vil ha sin inngående journalpost, og som regel hver sin sak Skole/barnehage? vil være dokumentert i henvisningsdokumentet: Nok til arkivformål. Resultat Fylles ut etter overføring av journalpost til arkiv. Egen jp? X?? - Inngående henvisning har normalt ikke resultat. Sluttdato? Saksmappen vil ha M602-AvsluttetDato Henvendende instans M087-Korrepondanseparttype = Avsender (inngående) Henviser Sakkyndig vurdering Kan forekomme flere ganger Hver sakkyndig vurdering vil ha sin utgående journalpost. Henv. mottatt Brukes for å telle de 90 dagene Anser dette til å være fagsystemrelatert, ikke for arkivformål. Påbegynt dato M100 Saksdato Ferdig dato Fylles ut etter overføring av journalpost til arkiv. M604 Arkivertdato Ansvarlig 1 Juridisk ansvarlig, ikke saksbehandler? vil være HK Data spesifikt Type (paragraf)? Sakkyndig vurdering utgår Nedtellingsfelt ikke viktig for ettertiden?? fagsystemrelatert, ikke til arkivformål Tilrådning Fylles ut etter overføring av journalpost til arkiv. Utgående journalpost arkiveres Tildelt «? Trinn? fagsystemrelatert? Skoleår? fagsystemrelatert? Skole? - fagsystemrelatert (tilhørighet hos Visma) 7

8 Systemsaker (sakarkiv) saksmappe (ikke vurdert av Visma i denne omgang) Felt i HK data Metadata Noark 5 Verdi Merknad Opprettet opprettetdato Avsluttet avsluttetdato? Navn tittel Flere instanser Ev. sakspart? (Kun navn struktur i så fall) Tema Ev. mappemerknad med ledetekst Tema? Initiert eksternt For skoleåret Ansvarlig saksansvarlig Ikke virksomhetsspesifikke metadata Systemsaker (sakarkiv) - registrering Vårt systemarbeid Startdato Usikker på om det er nødvendig (har opprettet dato saksmappe). Ansvarlig 1 saksbehandler Ansvarlig 2 Ansvarlig 3 Brukes ikke i Fredrikstad Kategori Trinn Ikke alltid aktuelt å fylle ut Klasse «Sluttdato avsluttetdato Signert av sendes med brev som virksomhetsspesifikke metadata Systemsaker (sakarkiv) - journalpost Det ser ikke ut til å være virksomhetsspesifikke metadata knyttet til journalposter i systemsaker. Metadata hentes fra brevjournal i HK oppvekst (hvis det er tilstrekkelig). 8

9 9