einnsyn arbeidsdokument for jus og personvern, versjon 1.

Transkript

1 einnsyn arbeidsdokument for jus og personvern, versjon 1. Innhold 1. Innledning Prosjektet Et felles prosjekt mellom Difi og Oslo kommune arbeidsfordeling og målsettinger Kravspesifiseringsarbeidet Piloter og sammenhenger med andre prosjekt Historikk og overordnet fremdriftsplan Løsning Innledning Arkitektur Behandling av data i plattform vs. visning av data på nettsted Data fra produksjonssystem/innholdsleverandør Fullt Noark 5 datasett Publisering av fulltekstdokument overføring av lenker Kvalitetssikring og kontroll av data Eksport/overføring av data Endring og sletting av data Data fra andre kilder enn produksjonssystem/innholdsleverandør («beriking av data») Validering og konvertering til rett format Transport av data Visning, søk og utforming av nettsted Data i visning «Forhåndsklassifisering» Angivelse av kriterier for utvalg av dokument publisert i fulltekst Søk i data og merking av personnavn «Mitt einnsyn» - innlogging for ekstra funksjonalitet Behandling av innsynskrav Dokument til sluttbruker Personvern og informasjonssikkerhet Personopplysningsloven og forskriften Ny personvernforordning

2 5. einnsyn for kommuner og fylkeskommuner Rettslig regulering av forholdet mellom forvalter og innholdsleverandør Innledning einnsyn er et prosjekt for utvikling av nye tjenester for innsyn i offentlige dokumenter i stat, kommuner og fylkeskommuner. Difi og Oslo kommune samarbeider om prosjektet. Tjenestene skal være lansert ved årsskiftet 2017/2018. Dette notatet inngår i prosjektets arbeidspakke 13 - «juridiske avklaringer». Formålet med notatet er å fungere som et «arbeidsdokument» som ligger til grunn for arbeidet i arbeidspakken. Første versjon av notatet er ment å gi et helhetlig oversiktsbilde av prosjektet, løsningen og relevante tema for arbeidspakken. 1 Senere versjoner skal inneholde innspill fra for eksempel referansegruppen, og drøftelser og konklusjoner på de vesentlige rettslige spørsmålene. Endelig versjon av notatet skal leveres til prosjektet i løpet av november. Referansegruppen for jus og personvern består av Maria Edvardsen og Ole Knut Løstegaard fra Justisdepartementets lovavdeling, Knut Kaspersen fra Datatilsynet, Jon Berge Holden fra Difi, Helga Hjort fra Riksarkivet og Helene Sverdrup Sevre og Bodil Rake Lystrup fra Oslo kommune. På prosjektets nettsted, einnsyn.difi.no, kan en finne en del informasjon og dokumentasjon om prosjektet, løsningen mv. 2. Prosjektet 2.1. Et felles prosjekt mellom Difi og Oslo kommune arbeidsfordeling og målsettinger 2 einnsyn er et felles prosjekt mellom Difi og Oslo kommune (OK). Bakgrunnen for samarbeidet er at Difi og Oslo kommune, uavhengig av hverandre, hadde etablert egne og svært komplementere innsynsprosjekter i 2015: Difi med sitt e-innsynsprosjekt Offentlig Elektronisk Postjournal (OEP) 3 og Oslo kommune med sitt Søk I Politiske Saker-prosjekt (SIPS). 4 Partene signerte samarbeidsavtale den og har følgende avtalefestet visjon: «Ved årsskiftet 2017/2018 har Difi og Oslo kommune (OK) lansert tjenester for innsyn for henholdsvis stat og kommune. Tjenestene er utviklet i fellesskap og omfatter innsyn i politiske saker og øvrige styrer, råd og utvalg samt ordiner saksbehandling og korrespondanse. Løsningen er nyskapende med 1 Relevant informasjon for arbeidspakken ligger spredt rundt på forskjellige arbeidspakker og forskjellige dokument. Noe av formålet med notatet har vært å samle relevant informasjon på overordnet nivå. Mye innhold og tekst i dette notatet er derfor hentet direkte fra andre dokument og kilder i prosjektet. 2 Teksten i pkt. 2.1 er i all hovedsak hentet direkte fra samarbeidsavtalen mellom Difi og Oslo kommune, datert Dagens OEP har eksistert siden På grunn av enkelte utfordringer med skalerbarhet og sikkerhet i løsningen, bevilget KMD i 2014 midler til et forprosjekt for ny løsning. Satsningsforslag ble levert ved årsslutt 2014 og i oktober 2015 fikk Difi midler over statsbudsjettet til å lage ny løsning. 4 SIPS er en tjeneste levert fra Oslo kommune hvor det kan søkes frem saker, saksfremlegg og protokoller, som er behandlet i politiske utvalg (byrådet, bystyrets organer, bydelsutvalgene). Dagens søkeløsning fungerer dårlig, og det ble derfor etablert et prosjekt for å modernisere og gjøre løsningen mer brukervennlig. Samtidig skulle det utvikles et generelt konsept for innsyn som vil bli tilgjengeliggjort for alle virksomhetene i Oslo kommune. 2

3 tanke på brukervennlighet, funksjonalitet og innhold. Sluttbruker opplever tilgang til Det Offentlige Norge gjennom deling av informasjon på tvers av offentlig sektor.» Begge parter skal ha fokus på å levere i henhold til de opprinnelige forpliktelsene, men måten å implementere på vil endres og omfanget vil utvides som et resultat av prosjektet. Partene har samordnet og harmonisert sine målbeskrivelser og arbeidspakker. Innad i prosjektet skilles det mellom plattform (Backend) og visning (Frontend). Med plattform menes infrastruktur for integrasjon med arkivsystemer, transformasjon og validering, berikingstjenester (f.eks. knytning til kart), database og søketjenester, samt grensesnitt for åpne data (åpent API) med tilhørende tilgangsstyring. Med visning menes presentasjonslaget (frontend) mot sluttbrukerne. Her skal funksjonalitet for innsyn og søk i journaler, saker og møter (som politiske møter) integreres. I utviklingen har Difi hovedansvar for plattform og Oslo kommune for visning. På overordnet nivå skal einnsyn/ny OEP ha fokus på 3 områder: Ny teknisk infrastruktur for automatisering av prosesser Forenklinger og forbedringer for dataeier/forvaltningen Forbedringer for brukerne innbyggere og presse/media De overordnede målsettingene til prosjektet er definert slik: 1. Fokus på sikkerhet i alle ledd 2. Automatisert eller løpende overføring av data til einnsyn 3. Publisering av dokument (tilgang til dokument) i tillegg til offentlig journal 4. Bedre og mer effektive funksjoner for arbeidet med innsynskrav 5. Kvalitetskontroll og kvalitetsheving av data Prosjektet har en samlet kostnadsramme på 34 mill. kroner (Difi 23, Oslo kommune 11). Prosjektet er delt inn i flere arbeidspakker, og det er etablert flere ulike referansegrupper. På einnsyn.difi.no ligger en del informasjon om arbeidspakkene og referansegruppene Kravspesifiseringsarbeidet Kravspesifikasjonen for ny løsning består totalt sett av epos, brukerhistorier og detaljkrav for utvikling. Epos og brukerhistorier utarbeides i arbeidspakke 1 «Behovskartlegging og kravspesifikasjon», før disse videresendes til arbeidspakkene for utvikling for utforming av detaljkrav. Arbeidet kan skisseres slik: 1. Utforming av epos: Epos er større funksjonelle tiltak/brukerhistorier på overordnet nivå. 2. Utforming av brukerhistorier: Detaljering av eposene. 3. Utforming av detaljkrav til utvikling. Utformes i arbeidspakkene for utvikling. For arbeidspakken for juridiske avklaringer, og tilhørende referansegruppe, vil det i all hovedsak være tilstrekkelig å holde seg til brukerhistoriene (dvs. nivå 2 i skissen over). Brukerhistoriene ligger på einnsyn.difi.no under arbeidspakke 1. 3

4 2.3. Piloter og sammenhenger med andre prosjekt einnsyn har enkelte sammenhenger med andre prosjekt, og en viktig del av prosjektet er pilotering av nye funksjoner og lignende. Under følger en oppsummering av vesentlige prosjekt og piloter. Meldingsutveksling internt i forvaltningen. 5 Det pågår et prosjekt i Difi for utvikling av ny referansearkitektur og løsning for meldingsutveksling internt i forvaltningen. Løsningen består av et felles generisk adresseregister som skal gjøres tilgjengelig for alle offentlige virksomheter, og et integrasjonspunkt (en komponent som kjører ute hos den enkelte virksomhet). Komponenten sender meldinger fra en virksomhet til integrasjonspunkt hos mottakende virksomhet. I tillegg består løsningen av komponenter som gjør det mulig for en sentralforvalter å for eksempel se at meldinger kommer frem mv. Difi samarbeider med ulike virksomheter for pilotering av løsningen, for eksempel samarbeider Difi nå med NVE om gjennomføring av en pilot der målet er å rulle ut en produksjonsversjon av meldingsutveksling mellom offentlige virksomheter, samt identifisere og prøve ut nye bruksområder for den underliggende referansearkitekturen. Data til einnsyn er en sentral del av piloten hos NVE. Tanken er å bruke meldingsutvekslingsløsningen for å utveksle data mellom innholdsleverandørene og einnsyn. Se nærmere under i punkt 3.1 og 3.5. Pilot for automatisk overføring av Noark-data til earkiv (mellomarkiv og depot) og einnsyn. Piloten gikk ut på å teste ut automatisk overføring av Noarkdata til mellomarkiv og deretter løpende overføring til Riksarkivet og einnsyn hos Difi. Både metadata og dokumentfiler som ikke har skjermingsrestriksjoner, ble overført til einnsyn. Alle filer, også de med restriksjoner, ble overført til Rikarkivet. I denne piloten var også beriking av Noark5-data et viktig mål, se notat fra Bouvet om dette. 6 «Barrierer mot meroffentlighet». Delprosjektet «Barrierer mot meroffentlighet» skal kort sagt bidra med metoder og prosesser for å forstå hvordan det skal bygges en god praksis, og utvikle kultur, tillit og arbeidsprosesser slik at dokument blir publisert i fulltekst og vi kan få ut gevinstpotensialet i einnsyn. Delprosjektet utføres av konsulentselskapet Making Waves i samarbeid med PA-Consulting på vegne av einnsyn-prosjektet Historikk og overordnet fremdriftsplan Kulepunktene under gir overordnet historikk og fremdriftsplan. 2014: KMD gir midler til forprosjekt 2014: Satsningsforslag sendt til KMD 2015 oktober: Difi får bevilget 13 millioner kroner gjennom statsbudsjettet november: Oppstart gjennomføringsfase 2016 april: Arkitektur besluttet 2016 juni: Samarbeidet etableres med Oslo Kommune. Felles utviklingsprosjekt. einnsyn stat og einnsyn kommune august: Plattformen klar til bruk med reelle data på plass 5 Se og for nærmere informasjon. 6 Se notatet «Idénotat beriking av journaldata i OEP» som Bouvet utarbeidet på oppdrag fra einnsynprosjektet. Notatet er tilgjengelig på nettstedet einnsyn.difi.no. 4

5 2016 desember: Søk i politiske saker i drift 2016 desember: Beta-versjon med basisfunksjoner av einnsyn ferdig for testing 2017 nye tjenester utvikles, og løsningen ferdigstilles for produksjon Prosjektet er nå inne i fase 2. Milepælsplanen for denne fasen er som følger; HMP juni: Møte med Riksarkivet - avklaringer Noark5-tjenestegrensesnittet, NOARK5, mm HMP 2 - medio august: Konvertering DKI plattformen HMP 3 - medio august: Plattform stabilisert med reelle data, Dokument og Møte, for test HMP 4 -medio september: API søk og detaljvisning møte og dokument HMP 5-medio oktober: enkel visning Møte HMP 6 -medio oktober: enkel visning Dokument HMP 7 -medio november: Beta vising Møte HMP 8 -medio desember: Beta visning Dokument HMP 9 -medio desember: Produksjon Møte for Bystyret, Byrådet 3. Løsning 3.1. Innledning Arkitektur Figuren under viser overordnet arkitektur for einnsyn og bruk av meldingsutvekslingsinfrastrukturen (se første kulepunkt i pkt. 2.3) for overføring av data mellom innholdsleverandører og einnsyn. Følgende figur viser en mer detaljert skisse over einnsyn: 5

6 einnsyn er basert på «mikrotjenestearkitektur». I dette ligger det at løsningen er bygget opp av mange små komponenter som jobber sammen, kontra en stor applikasjon. Dette gir større fleksibilitet ved endringer og oppgraderinger. En vil kunne gjøre oppdateringer på enkeltkomponentene separat og en trenger ikke nødvendigvis oppdatere hele løsningen Behandling av data i plattform vs. visning av data på nettsted Som det vil fremgå under, er det ønskelig å samle inn mer data enn det som er tilfellet med dagens løsning. Det betyr ikke nødvendigvis at mer data vil bli presentert for sluttbruker på nettstedet. I prosjektet skilles det mellom behandling av data i plattform og i visning: Behandling av data i plattform: En av grunnene til at en vil samle inn mer data, er at en ser på mulighetene til å i større grad analysere hva som blir levert, og på bakgrunn av resultatene fra analysene bygge bedre tjenester. Resultatet fra analysen kan også tilbys tilbake til innholdsleverandørene/arkivsystem, og på den måten gjøre de tryggere på kvaliteten til det som blir overført. En kan her se for seg at en for eksempel kan analysere seg frem til sannsynlige personnavn/personnummer og melde tilbake om dette ikke er merket korrekt. En kan også se på trender og melde tilbake om det blir levert dokument som burde ha vært sladdet eller som kan åpnes for innsyn i sin helhet. Ved at einnsyn skal ta statistikk om behandling av innsynskravene også fremover, gir det mulighet til å analysere også disse dataene. En ser for eksempel for seg at dersom det blir lagt ut kun metadata om et dokument, og statistikken viser at innsynskrav på dette dokumentet mest sannsynlig vil bli akseptert, vil en kunne gi tilbakemelding til innholdsleverandøren om at dette bør publiseres i fulltekst. 7 Visning: I visning kan journalposten presenteres. Videre kan data benyttes for å for eksempel forbedre søkefunksjonaliteten ved å legge til rette for «kontekstsøk». En kan eksempelvis gjennom å berike journaldata (se punkt 3.3) skape flere akser i informasjonen, f.eks. tid/hendelser, sted og organisasjon/person. Det betyr både at man kan få nye eller utvidete innganger til materialet eller at man kan «følge» korrespondanse/aktivitetene/sakene i forskjellige retninger. 8 Sluttbruker skal enkelt sagt eksempelvis kunne klikke på et geografisk område og få opp alle journalpostene knyttet til dette området Data fra produksjonssystem/innholdsleverandør Fullt Noark 5 datasett einnsyn vil bygge på et annet dataformat for overføring enn Noark 4 offentlig journal som blir brukt i dag. Formatet vil være på RDF format, der feltdefinisjonene er basert på Noark 5 arkivstruktur. einnsyn er basert på full arkivstruktur, og ikke bare på journalrapport. Dette fordi det er ønskelig å samle inn et bredere grunnlag enn det en har i dag. Det betyr ikke nødvendigvis at alle data skal vises 7 Teksten her er hentet direkte fra et dokument som er under utarbeidelse i prosjektet, og som heter «Dataflyt mellom offentlege verksemder og einnsyn. Modellar, ansvar og konsekvensar» (heretter Dataflytnotatet). Dokumentet vil bli gjort tilgjengelig så snart det er ferdigstilt. 8 Se pkt. 2.1 i notatet «Idénotat Beriking av journaldata i OEP». 9 Teksten i pkt er hentet fra Dataflytnotatet 6

7 til brukerne, men det kan for eksempel gi grunnlag for å bygge flere og bedre tjenester til brukerne enn i dag, se punkt For spørsmålet om hvilke data som skal vises til brukerne, se punkt Publisering av fulltekstdokument overføring av lenker I Difi rapporten om fulltekstpublisering av dokument i OEP 10 ble det anbefalt en løsning for fulltekstpublisering som innebærer automatisk overføring av lenker til OEP, se anbefalingen i rapportens punkt 9. Difi anbefaler at konklusjonen fra 2012 blir lagt til grunn for arbeidet med publisering av tekstdokument i einnsyn. Når alle dokumentene som skal publiseres er tydelig merket med Publiser til einnsyn, eller annet tydelig flagg, må de flyttes ut på en server som har tilgang fra Internett. Adresse eller stien (URL) til hvert dokument må inkluderes i de postene som skal overføres til einnsyn. Ansvaret for publisering av dokument, og at stien er rett og varig, ligger hos innholdsleverandørene Kvalitetssikring og kontroll av data Det er avgjørende at kun rett metadata og kun rette dokument blir eksportert til einnsyn. Dette må sikres gjennom gode rutiner og at metadata og dokument får tydelig merking for overføring eller ikke. Det kan være behov for egen statuskode for dokumentnivået som tydelig viser Publiser til einnsyn og at dette blir et obligatorisk felt som må fylles ut i forbindelse med saksbehandling eller registrering av innkommende saker/dokument. I en sak kan det være både offentlige og ikkeoffentlige dokument og vedlegg, noe som kan gjøre dette komplisert i en del sammenhenger. Løsningene for overføring av data til ny einnsyn må ikke øke risikoen for feilpublisering, men må ha som mål å redusere den. Ansvaret for denne fasen ligg fullt ut hos innholdsleverandørene. einnsyn vil vurdere om det skal lages mikrotjenester som kan understøtte dette arbeidet, se avsnittet om validering og kvalitetskontroll i punkt Eksport/overføring av data Overføring på objektnivå: Når metadata og dokument er merka på tydelig og sikker måte, kan overføringen til einnsyn skje. einnsyn ønsker at dette skjer på objektnivå. Det betyr at en og en journalpost med tilhørende overliggende og underliggende metadata i Noark-strukturen blir overført etter hvert som de blir tydelig merket med «Publiser til einnsyn» eller tilsvarende. Det er ikke til hinder for at virksomhetene og kan kontrollere grupper av journalposter før den enkelte overføringen starter. Ansvaret for eksport/overføring: Denne eksporten er virksomhetene sitt ansvar. Eksporten må naturlig skje i nært samarbeid med virksomhetens systemleverandør. einnsyn definerer formatet på det som skal eksporteres og tar mot og validerer på «utsiden». Ansvaret for denne fasen ligger på innholdsleverandørene i samarbeid med systemleverandørene. Automatisert eksport/overføring: Med automatisert eller løpende overføring av data, menes at de manuelle prosessene som blir utført i dag må vekk og erstattes av mer maskin- til maskinbaserte løsninger. Dette må skje på en slik måte at innholdsleverandørene sitt behov for god kontroll og styring ikke blir redusert, men heller styrkes. Det vil og være naturlig å sende/overføre enkeltposter 10 Rapporten er tilgjengelig her: 7

8 til einnsyn i stedet for datasett for flere dager, slik som i dag til OEP. Det siste vil også gjøre det lettere å trekke tilbake eller oppdatere de postene som må rettes på eller endres på grunn av mangler, feil eller feilpublisering. Det vil og gjøre det lettere å kontrollere enkeltposter før de blir overført til einnsyn. Overgang fra opplasting av datasett til mer løpende overføring av enkeltposter er i hovedsak en teknisk endring og vil i liten grad påvirke arbeidet i virksomhetene. Arbeidet med å kvalitetssikre data om saker og journalposter kan i hovedsak utføres på same måte som i dag i virksomhetene, og de vil fremdeles ha full frihet til å organisere dette på samme måte som i dag eller gjøre endringer Endring og sletting av data I løsningen blir det lagt opp til at innholdsleverandørene skal kunne endre data som er publisert, fjerne dokument som er publisert i fulltekst, slette data som er publisert og at endringer av data blir loggført. Difi har mottatt innspill fra referansegrupper på at det er ønskelig å se hva som ble endret og hvordan. Hensikten er å se om det er gjort forsøk på å skjule informasjon. Det er også andre som har meldt om lignende. Finansdepartementet har meldt at det bør fremkomme en oversikt over endring på journalposten. I dag blir journalposter som re-publiseres oppfattet som «ny-publiserte», noe som kan være misvisende. Det er også mottatt innspill på at muligheten for endring og sletting ikke må gå ut over kvalitet- og kontrollarbeidet som blir gjort forut for publisering, for eksempel ved at en tar lettere på dette arbeidet. Dersom publisert data og dokument er nedlastet, vil endring og/eller sletting ha begrenset betydning. Prosjektet vurderer om funksjonaliteten for endring og sletting av data skal være tilstede både direkte i einnsyn og i sak- arkivsystemet, eller kun i sistnevnte. Et problem i dagens løsning er håndtering av «konflikter» mellom journalposter. Dette går kort sagt ut på at det blir overført en journalpost til OEP der saks- og dokumentnummer er identisk med en eksisterende journalpost, mens løpenummeret tilsier at det er en ny post. OEP kan da ikke avgjøre hva som skjer med posten. Prosjektet ser det videre som viktig å finne en løsning som hindrer konflikter Data fra andre kilder enn produksjonssystem/innholdsleverandør («beriking av data») einnsyn vil legge til rette for «beriking» (begrepene «beriking», «beriking av data» og «beriking av journaldata» behandles i prosjektet som synonyme begrep). Konsulentselskapet Bouvet fikk i oppdrag fra Difi, som en del av piloten sammen med Riksantikvaren og Riksarkivet, å utarbeide et idénotat om beriking av data i einnsyn. 11 I notatets punkt 2.1 er beriking definert slik: «Beriking av journaldata betyr i denne sammenhengen at man tilfører eksisterende data ytterligere informasjon for å gi dataene mer kontekst og betydning.» 11 Notatet ble levert den og er tilgjengelig på einnsyn.difi.no. 8

9 I einnsyn benyttes begrepet beriking kun om de tilfeller der data tilføres, eller data lenkes til andre kilder enn innholdsleverandørene. For eksempel vil innsamling av fullt Noark 5 datasett ikke være beriking. Eventuell innhenting eller lenking til data fra Enhetsregisteret eller matrikkelen vil derimot være beriking. Formålet med beriking kan være å forbedre søkemulighetene i visning. Ved å berike journaldata kan man skape flere akser i informasjonen, f.eks. tid/hendelser, sted og organisasjon/person. Det betyr både at man kan få nye eller utvidete innganger til materialet eller at man kan «følge» korrespondanse/aktivitetene/sakene i forskjellige retninger. 12 Eksempelvis kan en innbygger som leter etter relevant offentlig informasjon, klikke på en virksomhet, eller et geografisk område, og få opp alle journalposter tilknyttet denne virksomheten eller stedet. Data som tilføres kan også benyttes i plattform for å analysere hva som blir levert. Resultatet fra analysen kan eksempelvis tilbys tilbake til innholdsleverandørene, slik at en for eksempel kan trygge kvaliteten på det som blir oversendt. Det å legge til rette for beriking er nødvendig sett opp mot Skates mål om at data skal skapes en gang, og forvaltes i en kilde, for så å kunne gjenbrukes, jf. idénotatet punkt 2.1 der følgende ble lagt til grunn: «En analyse av journaldata vil vise at datasettet inneholder informasjon som også finnes i Folkeregisteret og Enhetsregisteret. Noark-klassene Arkivskaper og Korrespondansepart vil inneholde informasjon om virksomheter og deres kontaktinformasjon som f.eks. adresse. Etter målsetningen til Skate skal informasjon skapes én gang, forvaltes i én kilde for så å kunne gjenbrukes. I denne sammenhengen betyr det, ideelt sett, at virksomhets- og stedsinformasjon skal forvaltes i henholdsvis Enhetsregisteret og Matrikkelen, og gjenbrukes i f.eks. sak- og arkivsystemer. Dette er en løsning som ikke er implementert i dagens løsning, men som kan være en mulighet i fremtidige løsninger.» Arbeidet med tilrettelegging for beriking ligger i arbeidspakke 7 «Innovasjon gjennom prøving og feiling, ved hjelp av piloter». I løpet av oktober skal det utarbeides en plan for beriking og kvalitetsheving av data, se milepæl 2 i nevnte arbeidspakke. Den tekniske løsningen som skal benyttes i einnsyn, er særlig godt lagt til rette for lenking av data Validering og konvertering til rett format 13 Med validering menes at hver post blir kontrollert før den blir overført videre til einnsyn. Det kan være at alle felt som skal være med, har gyldige verdier og i rett format. Her vil det være ett sett med regler som einnsyn vil drøfte nærmere med innholdsleverandørene og systemleverandørene. (I dagens OEP blir data validert mot definisjonen av Nark4 offentlig journal.) Dersom poster validerer feil, blir det sendt melding om akkurat denne posten tilbake til innholdsleverandør, og posten må rettes og overføres på nytt. einnsyn vil ha ansvar for valideringsreglene. Selve programmet som validerer vil og bli utvikla av einnsyn. Det kan kjøres som en frittstående komponent hos hver av innholdsleverandørene eller det kan integreres i eksportmodulene til sak- og arkivsystemene. Endringer i valideringsregler må en laste ned fra einnsyn sitt nettsted. Før videre transport av data til einnsyn, vil og alle poster bli konvertert til rett format som er Noark5 Json-LD. Målet må være at data blir eksportert i dette formatet direkte fra sak- og arkivsystema slik at konvertering kan utelates. 12 Jf. Idénotatets punkt 2.1 andre avsnitt. 13 Tekst hentet fra Dataflytnotatet 9

10 3.5. Transport av data 14 Validerte data skal overføres på en trygg og sikker måte fra innholdsleverandørene til einnsyn. Tanken er å bruke rammeverket for meldingsutveksling i offentlig sektor, som bygger på modellen med integrasjonspunkt. Det må installeres et integrasjonspunkt hos alle som vil levere data til einnsyn. Difi har ansvaret for dette og slik installasjon kan enkelt gjøres av IKT-tjenestene til virksomhetene. Sikker overføring betyr blant annet at avsender og mottaker bli verifisert ved kontroll av sertifikater, at meldingen bli sikret slik at en ivaretar autentisitet, integritet og konfidensialitet) 3.6. Visning, søk og utforming av nettsted Data i visning I offentlighetsforskriften 6 andre og tredje avsnitt er det definert hva som skal fremgå av journal som blir gjort tilgjengelig på internett: «Innhaldet i journalar som blir gjorde tilgjengelege på Internett, skal vere i samsvar med arkivforskrifta 2-7 fyrste ledd andre punktum. I tillegg skal journalen opplyse om kontaktpunkt for den enkelte sak hos det aktuelle organet. Når opplysningar ikkje er tekne med i offentleg journal, jf. arkivforskrifta 2-7 andre ledd, skal utelatinga og fullstendig unntaksheimel gå fram av journalen. Dersom det er teke avgjerd om at eit dokument heilt eller dels skal vere unnateke frå innsyn, kan journalen innehalde opplysning om dette i form av fullstendig unntaksheimel og med opplysning om unntaket gjeld heile eller delar av dokumentet. Opplysningar som er nemnde i 7 andre ledd, skal ikkje gå fram av offentleg elektronisk journal. Slike opplysningar skal heller ikkje gå fram av journal eller liknande register som eit organ som ikkje er omfatta av ordninga etter fyrste ledd gjer tilgjengeleg på Internett. Offentleg elektronisk journal for organ som er omfatta av ordninga etter fyrste ledd, skal innrettast slik at det ikkje skal vere mogleg å få treff på personnamn i innførslar i journalane som er eldre enn eit år.» I einnsyn-prosjektet er det lagt til grunn at det som et minimum skal vises de data som er nevnt i overnevnte bestemmelse. Som det fremgår ellers av notatet, kan det også bli aktuelt å vise andre data, for eksempel data fra Noark 5, matrikkelen og fra Enhetsregisteret. Sluttbruker skal eksempelvis kunne «bevege» seg rundt i hele Noark 5 strukturen, på jakt etter relevant dokumentasjon «Forhåndsklassifisering» Et tema som ofte kommer opp i forskjellige sammenhenger i einnsyn, er spørsmålet om «forhåndsklassifisering». Problemet ble beskrevet slik i pkt. 2.3 i Difi-rapporten om fulltekstpublisering: «Det følger videre av offentlighetsloven 29 første ledd første punktum, at organet som mottar innsynskravet skal vurdere dette konkret og sjølvstendig. Dette innebærer at vurderingen skal skje konkret for det aktuelle dokumentet på det tidspunktet innsynsspørsmålet blir avgjort. Forhåndsvurdering av om dokumenter skal unntas offentlighet (forhåndsklassifisering) skal som hovedregel ikke forekomme utenom i klare tilfeller. Bakgrunnen er at en slik vurdering kan binde opp virksomheten ved seinere innsynskrav, og på denne måten medføre at det ikke gjøres en konkret og sjølvstendig vurdering på tidspunktet innsynskravet kommer. Ut i fra dette er det viktig at et system for fulltekstpublisering ikke utformes slik at det begrenser innsynsretten, men fungerer ut i fra et 14 Tekst hentet fra Dataflytnotatet 10

11 åpenhetsperspektiv, jf. grl. 100 sjette ledd om statlige myndigheters plikt til å tilrettelegge for en åpen og opplyst samtale.» Spørsmålet om forhåndsklassifisering er også omtalt i veilederen til offentlighetsloven (pkt. 5.4): «Slik unntaksvilkåra i mange av unntaksføresegnene i lova er utforma, vil tidsmomentet ofte ha noko å seie for om vilkåra for unntak er oppfylde. Tidsmomentet vil også etter omstenda innverke på meirinnsynsvurderinga etter 11, jf. punkt Organet skal mellom anna difor gjere ei konkret og sjølvstendig vurdering av alle innsynskrav det mottek, ut frå situasjonen på tidspunktet det blir teke stilling til kravet, jf. offentleglova 29 andre ledd fyrste punktum (sjå punkt 9.2). At det tidlegare har vore nekta innsyn er dermed ikkje avgjerande. Det avgjerande vil vere om unntaksvilkåra framleis er oppfylde, og eventuelt om det framleis ikkje er grunn til å utøve meirinnsyn. Såkalla førehandsklassifisering vil seie at det blir fastsett at det heilt eller delvis skal eller kan og bør gjerast unntak frå innsyn i dokument, utan at nokon har bede om innsyn. Dette skjer til dømes ved at dokument som blir sende ut eller mottekne, blir påstempla at det er gjort unntak frå innsyn for dei etter ei eller anna føresegn i lova. Dette skal som den klare hovudregel ikkje førekome. Bakgrunnen for dette er at slik klassifisering kan binde opp vurderingane hos organet når det seinare kjem krav om innsyn eller hos andre organ som mottek klassifiserte dokument. Førehandsklassifisering kan dermed motverke regelen om at eit organ som får eit innsynskrav skal gjere ei konkret og sjølvstendig vurdering av kravet, og at innsynsspørsmålet skal avgjerast ut frå situasjonen på tidspunktet då innsynskravet blir avgjort. Førehandsklassifisering bør berre finne stad for dokument eller opplysningar der det er klart at det ligg føre teieplikt eller der det er på reine at det kan gjerast unntak, og at det ikkje er aktuelt med meirinnsyn. Der det er sannsynleg at omstenda vil endre seg innan rimeleg tid, slik at unntaksbehovet vil bli mindre, bør ikkje førehandsklassifisering skje.» Prosjektet ser det som viktig at det gis god rettsinformasjon til sluttbruker, og at det kommuniseres på en tilstrekkelig klart måte at det kan begjæres innsyn i et dokument, selv om det for eksempel er journalført med hjemmel for unntak for innsyn, og selv om det ikke er fulltekstpublisert Angivelse av kriterier for utvalg av dokument publisert i fulltekst Av offentlighetsforskriften 7 siste avsnitt følger det at «Organ som gjer dokument tilgjengeleg for ålmenta på Internett, skal opplyse kva for kriterium som ligg til grunn for utvalet av dokument.» De ulike virksomhetene vil ha ulike kriterier, noe som gjør det vanskelig å gi generell informasjon som er treffende for alle. Prosjektet vil legge opp til at virksomhetene selv må kunne redigere tekst i sitt administrasjonsgrensesnitt, og at informasjonen må kunne vises spesifikt for hver virksomhet på nettstedet Søk i data og merking av personnavn Søk i metadata. einnsyn legger opp til at det, som et minimum, skal være mulig å søke på alle felt som er hjemlet i arkivforskriften 2-7. Det skal videre være mulig å sperre for søk i de enkelte innholdsleverandørene sine data, slik at en kan avgrense spredning mens feilretting foregår dersom sensitive data blir feilpublisert. Prosjektet vil legge opp til at det publiseres forklarende melding, slik at en unngår villfarelse om at det ikke finnes treff og informasjon. Søk i fulltekstdokument? Difi vil og se på mulighetene for å bruke linken til fulltekstdokument til å gjøre indeksering av innholdet i offentlige dokument, for å for eksempel finne geografiske navn, 11

12 stikkord, ordmønster med mer som kan brukes til å bygge bedre tjenester for brukerne etter hvert og bedre tjenester for innholdsleverandørene med tanke på informasjonssikkerhet. Merking av personnavn. Av Offentlighetsforskriften 6 siste setning fremgår det at «Offentleg elektronisk journal for organ som er omfatta av ordninga etter fyrste ledd, skal innrettast slik at det ikkje skal vere mogleg å få treff på personnamn i innførslar i journalane som er eldre enn eit år.» I einnsyn vil merkede personnavn bli gjort ikke-søkbare når 12 måneder er passert. Løsningen skal håndtere personnavn-taggen både i Noark 4 og Noark 5. einnsyn skal også etter hvert utvikle løsninger som vil støtte opp under automatisk identifisering av personnavn «Mitt einnsyn» - innlogging for ekstra funksjonalitet einnsyn vil legge opp til at brukerne kan ha «egen» side der en kan benytte ekstra funksjonalitet, samt ha en god oversikt over saker av interesse, status for innsendte innsynskrav med mer. Prosjektet ser det som viktig at det fortsatt er gode og reelle muligheter for anonym bruk, og at mulighetene for en personlig side ikke skal legge hindringer for dette Behandling av innsynskrav 15 Når data er publisert på einnsyn, vil brukerne på egen hånd finne alle dokument som er publisert som offentlig av virksomhetene. Det kan være så mye som % av alle saker/journalposter, men dette vil variere fra virksomhet til virksomhet. Det vil uansett være en del dokument som brukeren må be om innsyn i. einnsyn vil lage gode funksjoner for at brukerne kan sende og holde oversikt over innsendte krav om innsyn. En del av disse funksjonene er det naturlig å legge i funksjonen «Mitt einnsyn». einnsyn er ansvarlig for å sende krav om innsyn tilbake til virksomheten på en sikker og trygg måte, og i et format som virksomheten kan importere rett inn i sine sak- og arkivsystem for håndtering og utsending av dokument. Den siste fasen vil måtte løses i samarbeid med systemleverandørene. Etter behandlingen av innsynskrav, må opplysninger om resultatet av behandlingen kunne sendes tilbake til einnsyn for administrative formål og for å lette oversikten for sluttbruker Dokument til sluttbruker 16 Det er virksomhetene som har ansvar for dokumentet til sluttbruker. Det må legges til rette for at brukerne kan be om innsyn på ulike måter. Her kan e-post, sikker digital post og andre løsninger være aktuelt. 4. Personvern og informasjonssikkerhet 4.1. Personopplysningsloven og forskriften Det er sentralt at kravene i personopplysningsregelverket ivaretas, herunder for eksempel at grunnvilkårene for behandling er oppfylt og at det defineres tydelig hvem som til enhver tid er 15 Tekst hentet fra Dataflytdokumentet 16 Tekst hentet fra Dataflytdokumentet 12

13 behandlingsansvarlig og databehandler for behandlingen. I Difi rapporten om fulltekstpublisering ble følgende lagt til grunn på side 10: «Personopplysningslovens regler om informasjonssikkerhet ( 13) og internkontroll ( 14) kommer også til anvendelse ved publisering av fulltekstdokumenter til Internett. Systemet må derfor også være i samsvar med og legge til rette for at disse bestemmelsene etterleves. Det må på bakgrunn av dette vurderes om det er behov for å revidere eksisterende databehandleravtale mellom innholdsleverandørene og Difi som databehandler dersom det innføres en ny løsning for fulltekstpublisering, jf. personopplysningsloven 15.» 4.2. Ny personvernforordning Det må undersøkes om ny personvernforordning inneholder krav som en må ta hensyn til i ny løsning 5. einnsyn for kommuner og fylkeskommuner einnsyn vil legge til rette for at det kan mottas data fra kommuner og fylkeskommuner for de som ønsker dette, og i den sammenheng de rettslige rammebetingelsene for dette undersøkes, for eksempel om det for eksempel er behov for tilpassinger av regelverk eller lignende. 6. Rettslig regulering av forholdet mellom forvalter og innholdsleverandør En vil etter hvert se på og vurdere hvorvidt det er behov for å revidere samarbeidsavtalene som inngås med innholdsleverandørene. Det er i denne sammenheng viktig å se for eksempel på ansvarsfordeling for arbeidsprosesser. *** 13