DATAFLYT MELLOM OFFENTLEGE VERKSEMDER OG EINNSYN MODELLAR, ANSVAR OG KONSEKVENSAR

Transkript

1 DATAFLYT MELLOM OFFENTLEGE VERKSEMDER OG EINNSYN MODELLAR, ANSVAR OG KONSEKVENSAR Gunnar Urtegaard, Øystein Høyum, Difi, med tillegg frå Gunnar Gustavsen, Oslo kommune

2 1 Innhold Mål med dette notatet... 3 OEP i dag... 4 Mål for einnsyn... 4 Sikkerheit... 5 Automatisert eller løpande overføring... 5 Publisering av dokument... 5 Betre funksjonar for innsynskrav... 6 Datafly mellom verksemd og einnsyn rollar og ansvar... 6 Kvalitet og kontroll... 6 Publisera eller gje tilgang til dokument... 6 Eksport av data frå produksjonsystem... 7 Validering og konvertering til rett format... 7 Transport av data Innsynskrav frå einnsyn... 8 Dokument til sluttbrukar... 8 Dataformat og validering... 9 Integrasjonspunktet sin rolle i einnsyn... 9 Data skal ekspederast til einnsyn Data skal sikrast Data skal til rett mottakar Dataflyt skisse av mogelege løysingar Alternativ 1 prioritert løysing Alternativ 0 - overgangsmodellen Konsekvensar for innhaldsleverandørane Verktøy innhaldsleverandørane brukar i dag Aktuelle mikrotenester i einnsyn Beriking Vidare dialog med innhaldsleverandørane og systemleverandørane Kartlegging Informasjon, utprøving og testing Pilotering og prototyping Plan for utrulling i Vedlegg 1, Meir om prosessar knytte til dataflyt

3 2

4 3 Mål med dette notatet Dagens versjon av offentlig elektronisk postjournal (OEP) skal erstattast med ny og meir moderne plattform. Samarbeidet som er innleia med Oslo kommune, har utvida prosjektet og målsetjinga til og å omfatta data frå Oslo kommune, særleg politiske saker. Målsetjinga opnar og for informasjon frå andre kommunar og fylkeskommunar. Dei opphavelege måla baserte på oppdraget frå KMD og frå Oslo kommune står likevel fast. Dei skal realiserast slik det vart omtalt opphaveleg, men då innanfor den nye råma. For å realisera måla er det tre hovudaktørar som må samarbeida tett: - Innhaldsleverandørane. 120 statlege verksemder leverer data til OEP i dag. Oslo kommune har som mål å knyta opp alle sine vel 50 ulike einingar til ei felles innsynsløysing. - Systemleverandørane. Informasjonen til OEP vert i dag i hovudsak produsert og kvalitetssikra i ulike sak/arkivløysingar og Software Innovation (P360 og DocuLive), Acos (Acos Websak) og Evry/Gecko (ephorte) har ein stor del av denne marknaden. Oslo kommune har valt Acos som sin leverandør av nytt felles sak/arkivsystem. - einnsynsprosjektet med Difi og Oslo kommune med felles ansvar for utvikling av ny, samla løysing. einnsyn har frå starten lagt stor vekt på å vera eit ope prosjekt som informerer godt, (sjå mellom anna einnsyn.difi.no og Målet med dette notatet er å gje så god og oppdatert informasjon som mogeleg, særleg til dei 120 innhaldsleverandørane og aktuelle verksemder i Oslo kommune, men og til systemleverandørane, sentrale brukargrupper og andre som er interesserte i arbeidet. Notatet skal drøftast i sentrale referansegrupper 20. og 21. september og skal deretter sendast ut til mellom anna alle dei 120 verksemdene som leverer innhald til OEP i dag. Temaet som notatet tek opp vil og verta sentralt på ein større konferanse om einnsyn som vert skipa til i Oslo 1. desember. Notatet fokuserer særleg på det som vil skje hjå innhaldsleverandørane og kva konsekvensar det kan ha. Notatet må lesast saman med notat om arkitekturen i einnsyn av Rune Kjørlaug, sjå vedlegg. Notatet er skrevet med utgangspunkt i fornying av OEP, men det felles einnsynsprosjektet mellom Difi og Oslo kommune har som mål at en ny løysing for visning av politiske saker på nett skal følgja same prinsippa og arkitektur som ny OEP. I det etterfølgjande er det derfor berre kommentert/lagt til tekst der det er ulikheiter mellom OEP og Søk i politiske saker (SIPS).

5 4 OEP i dag Dagens løysing byggjer på manuelle prosessar for å trekkja ut data, for å overføra data til OEP og for å handsama innsynskrav. Brukaren må i tillegg senda innsynskrav for alle dokument, også dei som klårt og tydeleg er offentlege dokument ut i frå innhaldet. Grunnen til det er at i dagens løysing vert ikkje sjølve dokumenta publiserte, berre metadata eller informasjon om dokumenta. Det er mogeleg å publisera lenker i dagens OEP, men på grunn av funksjonaliteten, er det lite brukt. I 2011, året etter at dagens OEP vart sett i drift, vart det gjort ei kartlegging av erfaringar. Viktige tilbakemeldingar frå sentrale interessentar og brukargrupper var: Innbyggjarane: Det går for lang tid å få dokument tilsende Arkivmedarbeidarar: Ønskjer meir effektiv handsaming av innsynskrav Leiarar i statlege verksemder: Treng eit system for å publisera dokument som er offentlege Alt året etter vart det utarbeidd ein rapport om publisering av fulltekstdokument i OEP. Konklusjonen var at dette burde ein gjera, og løysinga som vart tilrådd var at dei verksemdene som publiserer data til OEP, skulle publisera dokumenta på ein open nettstad og senda med ein permanent link i datasettet til OEP slik at brukarane kan finna og lesa dokumenta som ein del av den samla tenesta i OEP. SIPS publiserer i dag dokumenta som høyrer til politiske saker. Innsynsproblematikken er dermed redusert med den løysinga. Dei manuelle prosessane for å trekka ut data til SIPS, er heilt parallelle med uttrekk til dagens OEP. Mål for einnsyn Tilbakemeldingane frå 2011, saman med mange andre innspel, er no sentrale mål i arbeidet med ny OEP eller einnsyn. Målet med ny løysing er definert slik: 1. Fokus på sikkerheit i alle ledd

6 5 2. Automatisert eller løpande overføring av data til einnsyn 3. Publisering av dokument (tilgang til dokument) i tillegg til offentlig journal 4. Betre og meir effektive funksjonar for arbeidet med innsynskrav 5. Kvalitetskontroll og kvalitetsheving av data Løysinga som no vert utvikla må levera på desse måla, og aktuelle alternativ må vurderast på bakgrunn av i kva grad dei oppfyller desse måla på ein god måte. Sikkerheit Sikkerheit og skalering er viktige krav til ny løysing. Sikkerheit omfattar både informasjonssikkerheit knytt til prosessar hjå innhaldsleverandørar, sikkerheit knytt til overføring av data mellom verksemdene og einnsyn og sikkerheit knytt til alle sider ved utvikling og drift av ny teneste. Sikkerheit er sentralt i arbeidet med å utvikla ny løysinga. Automatisert eller løpande overføring Med automatisert eller løpande overføring av data meiner me at dei manuelle prosessane knytt til overføring som vert utførte i dag, må bort og erstattast av meir maskin- til maskinbaserte løysingar. Dette må skje på ein slik måte at innhaldsleverandørane sin behov for god kontroll og styring ikkje vert reduserte på noko vis, men dei må heller styrkjast. Det vil og vera naturleg å senda/overføra enkeltpostar til einnsyn i staden for datasett for fleire dagar, slik som i dag til OEP. Det siste vil og gjera det lettare å trekka tilbake eller oppdatera dei postane som må rettast på eller endrast på grunn av manglar, feil eller feilpublisering. Det vil og gjera det lettare å kontrollera enkeltpostar før dei vert overførte til OEP. Overgang frå opplasting av datasett til meir løpande overføring av enkeltpostar, er mellom anna ei teknisk endring, men kan og påverka arbeidet i verksemdene. SIPS vil kunne følgja dei same metodane for løpande overføring. Der vil det vera møtesekretærane for det enkelte utval som vil senda/overføra enkeltsaker til einnsyn, ikkje heile møte som ein gjer i dag. Publisering av dokument Publisering av dokument vil seia at dokument som vert vurdert som offentlege etter ei vurdering av sakshandsamar eller arkivpersonale, kan publiserast saman med publisering av tilknytt informasjon om saker og journalpostar (metadata). Med publisering meiner me ikkje overføring av dokumenta til einnsyn, men at dokumenta vert lagde ut på ein tilgjengeleg nettstad og at linken til dokumenta vert lagt med dei data som vert overførde til einnsyn. Korleis dette konkret skal løysast, vert opp til verksemdene i dialog med sine systemleverandørar. Det viktigaste er at einnsyn kan «peika» på dokumentet, slik at brukar blir send dit framfor å senda innsynskrav. Om ein vel å leggja dokumenta bak ein innloggingsmur, så er det opp til kvar enkelt verksemd. einnsyn har ikkje som mål å etablera dokumentlager der brukarane skal kunne lesa dokumenta som pdf eller i fulltekst. Overgang frå publisering av berre data om saker og journal til publisering av dokument er den største endringa ved overgang frå OEP til einnsyn. Det er mogeleg å publisera lenker til dokument i dagens OEP, men fåe har nytta denne funksjonen. På ei anna side er det fleire av dei som leverer data til OEP i dag som alt publiserer dokument og journal på eigne heimesider.

7 6 Kring halvparten av kommunane/fylkeskommunane publiserer dokument saman med journal/sak og mange har fleire har gjort dette i år. Dette har og ført til at systemleverandørane, som i hovudsak er dei same for stat og kommune, har utvikla gode og sikre løysingar for dette. Betre funksjonar for innsynskrav Det er behov for meir effektive funksjonar for sending og registrering av innsynskrav og det er behov for betre kontroll og oversyn på dette som kvitteringar, statistikk, oversyn over status med meir. Innsynskrav må kunna importerast på ein enkelt og oversiktleg måte i sak/arkivsystema, det må vera gode funksjonar for handsaming og det må vera gode løysingar for å laga statistikk og gode oversyn for både innhaldsleverandørane og dei som sender innsynskrav. Det er behov for å sjå prosessen med handsaming av innsynskrav i ein større samanheng, slik at ein kan effektivisera, samt få oversyn. Dette handlar om å laga meir effektiv sentral løysing, på same tid som ein legg til rette for at kvar verksemd får ein enklare prosess med innsynskrava. SIPS har ingen innsynsløysing i dag og vil kunna bruka same løysing som for OEP. Datafly mellom verksemd og einnsyn rollar og ansvar Med hovudmåla for einnsyn som overordna målbilete kan me grovt gruppera oppgåver og ansvar på denne måten. Kvalitet og kontroll. Det er avgjerande at berre rett metadata og berre link til rette dokument vert eksportert til einnsyn. Dette må sikrast gjennom gode rutinar og at metadata og dokument får tydeleg merking for overføring eller ikkje. Det kan vera trong for eigen statuskode for dokumentnivået (uavhengig av metadata) som tydeleg viser Publiser til einnsyn og at dette vert eit obligatorisk felt som må fyllast ut i samband med sakshandsaming eller registrering av innkomne saker/dokument. I ei sak kan det vera både off og uoff dokument og vedlegg så dette kan vera komplisert i ein del høve og det kan vera trong for ulike statuskodar og datoverdiar for når ting skal skje. Løysingane for overføring av data til ny einnsyn må ikkje auka risikoen for feilpublisering, men ha som mål redusera den. Ansvaret for denne fasen ligg likevel fullt ut hjå innhaldsleverandørane. einnsyn vil vurdera om det kan lagast mikrotenester som kan understøtta dette arbeidet, sjå avsnitt om mikrotenester seinare i dette notatet. Publisera eller gje tilgang til dokument. Når alle dokumenta som skal publiserast er tydeleg merka med Publiser til einnsyn eller anna tydeleg flagg, må dei flyttast ut på ein server som har tilgang frå Internett. Adressa eller stien (URL) til kvart dokument må inkluderast i dei postane som skal overførast til einnsyn. Ansvar for publisering av dokument og at stien er rett og varig, ligg hjå innhaldsleverandørane. Den tekniske løysinga for dette må dei finna i samarbeid med systemleverandørane. Rapporten frå 2012 om publisering av fulltekstdokument, konkluderer slik: Difi tilrår en løsning for fulltekstpublisering av dokumenter i OEP som innebærer automatisert overføring av lenker til OEP, se tilrådningen i kapittel 9. Løsningen er

8 7 nærmere beskrevet i kapittel 4.7. En slik løsning for fulltekstpublisering gir en praktisk mulighet for den sentrale statsforvaltningen til å publisere dokumenter til Internett. Dette vil også være nyttig for brukerne, da OEP brukes til å søke i de statlige virksomhetenes postjournaler og til å be om innsyn i dokumenter. OEP gir en mulighet for å søke på tvers av de offentlige virksomhetene i en stor mengde journalposter. Dersom det innføres en automatisert løsning for fulltekstpublisering av dokumenter, vil brukerne kunne få tilgang til flere dokumenter enn ved et søk på den enkelte virksomhets nettside. Difi vil tilrå at konklusjonen frå 2012 vert lagt til grunn for arbeidet med publisering av tekstdokument i einnsyn. Innhaldsleverandørane må difor, i samarbeid med sine systemleverandørar, finna fram til gode løysingar, og leggja med link til dokumenta når dei overfører data til einnsyn. Difi vil og nytta denne linken til å gjera forsøk med indeksering av innhaldet i offentlege dokument, for td å finna geografiske namn, stikkord, ordmønster med meir som kan nyttast til å byggja betre tenester for brukarane etter kvart og betre tenester for innhaldsleverandørane med tanke på informasjonssikkerheit. Slike tenester må ev støtta prosessane før publisering av dokument. SIPS har i dag kopier av dokumenta på eigen server tilgjengelig utanfor brannmurar, men vil følgja same prinsipp som for dokument i OEP. Eksport av data frå produksjonsystem. Når metadata og dokument er merka på tydeleg og sikker måte, kan overføringa til einnsyn skje. einnsyn ynskjer at det skjer på objektnivå. Det tyder at ein og ein journalpost med tilhøyrande metadata i Noark-strukturen vert overført etter kvart som dei vert tydeleg merka med «Publiser til einnsyn» eller tilsvarande. Det er ikkje til hinder for at verksemdene og kan kontrollera grupper av journalpostar før den enkeltvise overføring tek til. Denne eksporten er og verksemdene sitt ansvar og må naturleg nok skje i nært samarbeid verksemda sin systemleverandør. einnsyn definerer formatet på det som skal eksporterast og tek i mot og validerer på «utsida». Ansvar for denne fasen ligg soleis hjå innhaldsleverandørane i samarbeid med systemleverandørane. SIPS har behov ein variant her då informasjon om saka (Sakstittel) kan overførast så snart møte har fått ein status for offentliggjering. Tilhøyrande dokument vert berre overførde når dei har status som ferdigstilte/journalført. Grunnen til dette er at det er behov for å kunna vise kva saker som skal behandlast i eit møte før sakspapira er klare for offentliggjering. Validering og konvertering til rett format. Med validering meiner me at kvar post vert kontrollert før den vert overført vidare til einnsyn. Det kan vera at alle felt, som skal vera med, skal ha gyldige verdiar og i rett format. Dette skjer og i dagens OEP som vert validert opp mot krava til Noark4 offentleg journal. Her vil det verta laga eitt sett med praktiske reglar som einnsyn vil drøfta nærare med innhaldsleverandørane og systemleverandørane. Problemet i dagens OEP med konflikterande journalpostar kan vera eit anna døme på slik validering. Dersom postar validerer feil, vert det sendt melding om nett denne posten tilbake til innhaldsleverandør, og posten må rettast og overførast på nytt. einnsyn vil ha ansvar for å halda valideringsreglane oppdaterte. Sjølve programmet som validerer vil og bli utvikla av einnsyn. Det kan køyrast som ein frittståande komponent hjå kvar innhaldsleverandør eller det kan fungera tettare saman med eksportmodulane til sak/arkivsystema. Dette vil ein finna praktiske løysingar på i

9 8 samarbeid med sak/arkivleverandørane. Endringar i valideringsreglar må lastast ned frå einnsyn sin nettstad. Før vidare transport av data til einnsyn, vil og alle metadata knytt til journalpostar verta konverterte til rett format som er Noark5Json-LD. Målet må vera at data vert eksportert til einnsyn i dette formatet direkte frå sak/arkivsystema slik at konvertering kan utelatast. Transport av data. Validerte data skal overførast på ein trygg og sikker måte frå innhaldsleverandørane til einnsyn. Tanken her er å nytta rammeverket for meldingsutveksling i offentleg sektor, som byggjer på modellen med integrasjonspunkt. Det må installerast eit integrasjonspunkt hjå alle som vil levera data til einnsyn. Difi har ansvaret for dette og slik installasjon kan enkelt gjerast av IT-tenestene i verksemdene. Sjå og Innsynskrav frå einnsyn. Når data er publisert på einnsyn, vil brukarane på eiga hand kunna finna alle dokument som er publiserte som offentlege av verksemdene. Det kan vera så mykje som % av alle sakar/journalpostar, men dette vil variera frå verksemd til verksemd. Det vil uansett vera ein del dokument som brukaren må be om innsyn i. einnsyn vil laga gode funksjonar for at brukarane kan senda og halda oversyn over innsende krav om innsyn. Dette er etterlyst av fleire. Ein del av desse funksjonane er det naturleg å leggja til funksjonen «Mitt einnsyn». einnsyn er og ansvarleg for å senda krav om innsyn tilbake til verksemdene på ein sikker og trygg måte, og i eit format som verksemdene kan importera rett inn i sine sak/arkivsystem for handsaming og utsending av dokument. Løysinga med meldingsutveksling basert på integrasjonspunkt vil og vera aktuell her. Den siste fasen vil måtta løysast i samarbeid med systemleverandørane. Etter handsaming av innsynskrav, må opplysningar om handsaming og utfallet av handsaminga kunna senda statiske data tilbake til einnsyn for administrative føremål og for å letta oversyn for sluttbrukar. Dokument til sluttbrukar. Dette er de verksemdene som har ansvar for. Det må leggjast til rette for at brukarane kan be om dette på ulike måtar. Her kan epost, sikker digital post til innbyggar og andre løysingar vera aktuelt.

10 9 Dataformat og validering Målformatet som einnsyn vil byggja på, vil vera feltdefinisjonane i Noark5, og formatet vil RDF 1 format. Den nye løysinga for einnsyn, vil ha støtte for konvertering frå N4 xml og N5 xml til Noark5Json-LD. Me vil basera oss på full arkivstruktur, og ikkje berre journalrapport, fordi me ynskjer å samla inn eit breiare datagrunnlag enn ein har i dag. Det vil gje grunnlag for å byggja fleire og betre tenester til brukarane enn i dag. Det vil og gje grunnlag for beriking av data gjennom lenking til andre datasett som Einheitsregisteret, matrikkelen med meir. Det betyr ikkje at alle data som vert overførte, skal visast til brukarane. Ein må skilja klårt mellom data som vert overført til einnsyn si plattform og data som skal visast i den nye tenesta. I kva grad ei slik utviding krev endring 6 i offentlegforskrifta, er til drøfting i arbeidsgruppa for jus og personvern i einnsyn. Der sit representantar frå lovavdelinga i justisdepartementet, Riksarkivet, Datatilsynet, Oslo kommune og Difi. Det er og laga eige notat om aktuelle spørsmål som den gruppa skal drøfta (sjå einnsyn.difi.no). For å nytta RDF på ein god måte treng me unike id ar på alle element som vert levert ut. Fordi dagens datagrunnlag i stor grad er basert på identifikatorar som berre er unike innan kvart system eller datasett, så ser me føre oss å byggja opp nye unike, samansette id ar. Slike Id-ar skal bestå av: ID til innhaldsleverandør (organisasjonsnummer eller id-utstedt av Difi) ID for innhaldstype SystemID Oppretta dato Data til einnsyn vil verta validert i samsvar til SHACL 2 -reglar som Difi vil tilby. SHACL er ein komande standard for validering av rdf-data. Reglane vil koma som rdf (turtle) filer. Validering vil mellom anna skje mot relevante krav i gjeldane Noark-standard 5.4. Arbeidet som er gjort til no med fornying av SIPS, har vist at Noark-strukturen for metadata som er definert pr dato ikkje innheld nok data i forhold til behovet i ny løysing. Korleis dette skal løysast i einnsyn, må ein drøfta nærare med leverandørane av arkivløysningar og med Riksarkivet. Integrasjonspunktet sin rolle i einnsyn. I einnsyn skal data flyta mellom verksemde og einnsyn. I dette notatet tek me først og fremst føre oss dataflyten frå verksemdene til einnsyn, men kanalen vert tovegs. Data skal ekspederast til einnsyn, data skal sikrast og data skal fram til rett mottakar

11 10 Data skal ekspederast til einnsyn Skissa over viser hovudelementa i den nye løysinga. Data skal gjennom ein prosess hjå verksemda med kontroll, gjevast rett format og data skal ekspederast til einnsyn. einnsyn vil brukar modellen med integrasjonspunkt for å overføra data frå verksemd til einnsyn. Innføring av integrasjonspunkt hjå avsendande og mottakande vertsemd er ein viktig del av arkitekturen for meldingsutveksling i offentleg sektor. I einnsyn er dei 120 verksemdene avsendarar og Difi med einnsyn mottakar. Data skal sikrast

12 11 Det er svært viktig i ei teneste som einnsyn at brukarane kan ha tillit til tenesta. Data må sikrast på mange måtar. Det same gjeld for utveksling av meldingar mellom offentlege verksemder. einnsyn vil difor ta i bruk same teknologien og denne er i ferd med å verta utvikla som ein del av strukturen med integrasjonspunkt. Her ligg det funksjonar for kontroll, sikring og rutinar som sikrar at melding kjem til rett mottakar. Data skal til rett mottakar einnsyn vil nytta adressefunksjonane i integrasjonspunkta for å få meldingane fram og tilbake mellom einnsyn og rett verksemd. Dataflyt skisse av mogelege løysingar For å nå måla som er sette for einnsyn, kan ein tenkja seg litt ulike løysingar for kontroll og uttrekk hjå verksemdene. Det er viktig å dra nytte av det som vart gjort i 2010 då dagens OEP kom, og ein må dra nytte av det arbeidet som systemleverandørane har gjort i samarbeid med sine kundar som er svært kompetente verksemder i stat, fylka og kommunar. Alternativ 1 prioritert løysing

13 12 einnsyn må ha som mål å etablera ei løysing med direkte og trygg integrasjon mellom einnsyn og innhaldsleverandørane frå dag 1. Alternativ 1 slik det er skissert her, er den løysinga me vil tilrå. Arbeidet med kvalitet og kontroll av metadata og dokument hjå innhaldsleverandørane vil vera det same for dei to alternative løysingane me skisser under, men alternativ 1 vil gje trygg og sikker overføring, og redusera muligheiter for feil på verdikjeda. Løysinga føreset at det er etablert gode API hjå alle innhaldsleverandørane eller at systemleverandørane har eigne løysingar som kan ha tilstrekkeleg funksjonalitet. Eit alternativ på litt sikt kan vera å ta i bruk Noark-5 tenestegrensesnittet som no er klart frå Riksarkivet si side. I alternativ 1 vil ansvarspersonar ekspedera metadata direkte til einnsyn utan å gå vegen om uttrekk av datasett til xml-fil som så vert lagra og overført. Ein kan likevel kontrollera metadata som før, men systemet tek seg av overføringa post for post. Validering og konvertering kan integrast i ein eigen overføringsmodul eller den kan vera ein modul som samhandlar med tett med sak/arkivsystemet. Saks-/arkivsystemet vil ut i frå dette alternativet byggja opp eit rikare sett med metadata til kvar post basert på Noark5. Data går så vidare til einnsyn gjennom integrasjonspunktet for meldingsutveksling. Løysinga vil involvera systemleverandørane når det gjeld API/integrering og funksjonar i eksportmodulen. Det må lagast plan for utrulling, løysinga må prøvast ut i 2016 og 2017 slik at ein kjem fram til beste praksis her. einnsyn vil leggja opp til ein tett dialog vidare med innhaldsleverandørar og systemleverandørar. Fleire av dei funksjonane ein treng kan alt vera utvikla som løysing for kommunar og fylkeskommunar eller for statlege verksemder. einnsyn har og funne det rett å skissa på ein overgangsmodell for tilknyting i ein kort periode frå Alternativ 0 - overgangsmodellen

14 13 Dette alternativet er den enklaste løysinga som skal til for at me skal kunna erstatta dagens OEP med einnsyn. Ansvarspersonar i verksemdene kan nytta same eksportmodul som dei nyttar for eksport til OEP i dag. Xml-fil med metadata vert trekt ut frå arkivsystemet på same vis som i dag og lagra i lokal filkatalog. (I dag vert denne fila lasta opp til sentral OEP). Ein klient som Difi lagar, vil lesa filer i den lokale filkatalogen, validera og konvertera data. Resultat frå denne prosesseringa vil skrivast tilbake til filkatalogen som ei loggfil. Loggfila vil innhalda eventuelle valideringsmeldingar, men også rapport om prosesseringa, td kor mange journalpostar som vert sende vidare. Datapostar som ikkje validerer, vert ikkje overførde. Kva postar dette gjeld, vert meldt tilbake til dataleverandør. Datapostar som validerer, vert sende vidare til integrasjonspunktet for overføring til einnsyn og innlesing og indeksering i den nye løysinga. Denne løysinga har svak måloppnåing når det gjeld «Automatisert eller løpande overføring av data til einnsyn» og når det gjeld «Kvalitetskontroll og kvalitetsheving av data». Dataformatet som vert overført vil vera N4. Løysinga vil involvera systemleverandørane i liten grad. Det finst i dag ingen eksportmodul hjå leverandørane til Oslo kommune som leverer eit xml-format for politiske saker som er egna for dette formålet. Det me her har kalla overgangsmodellen, bør og innehalda sti til publiserte filer. Det vil medføra at dokument må vurderast for Publiser til einnsyn i samband med sakshandsaming eller registrering. Det vil vera ei omfattande endring. Elles vil denne overgangsmodellen medføra små endringar for verksemdene i høve til dagens praksis, men modellen vil og ha svak måloppnåing. Modellen vil berre verta nytta som del av ein fleksibel innfasingsprosess For alle alternativ: o o Løysing for publisering av dokument med dei fylgjene det får Installasjon av «Transport-klient»/Integrasjonspunkt hjå verksemdene For overgangsmodellen: o o o Installasjon av einnsyn-klient hjå dei som leverer data Oppsett av katalog som einnsyn-klient skal lese/skrive data til Tilgang for einnsyn-klient til å sende epost internt med innsynskrav (Det er epost som er definert som grensesnitt i dag) I prinsipp skal SIPS følgja same prosessane som omtalt over for OEP.

15 14 Konsekvensar for innhaldsleverandørane einnsyn har fått svært nyttige innspel gjennom dei referansegruppene der innhaldsleverandørane er representerte. Det er behov for avklaringar, presiseringar og analyse av konsekvensar no når me veit litt meir om den tekniske løysinga. Me har oppsummert spørsmåla frå innhaldsleverandørane under, og det er viktig å gje gode og konkrete svar på dette. Frå innhaldsleverandørane Automatisering, kva legg vi i det, o Forklare automatisk overføring, når vert det overført, kva vert overført, korleis startar automatikken o Kven styrer automatikken - verksemdene vil kunne kontrollere automatikken o Kva andre automatiserte prosessar er det snakk om o Kva legg vi i omgrepet validering Kvalitetssikring, o Korleis skal leverandørane kvalitetssikre, kva rutinar må endrast o Kvalitetssikring vs automatisering o Kan ein få tilpassa systemet til sine kvalitetssikringsrutinar o Kva med feilpublisering - må kunne endre straks o Ynske om malar for sladding i dokument, verktøy Fulltekstpublisering, o Korleis overføre dokument o Kvar vert dokumenta lagra («kvar skal dokumenta bo») o Vert det dobbeltarbeid - nokre publiserar allereie på eiga nettside Saksbehandlingssystem o Kva tilpasningar må gjerast i systema, oppgradering eller nye innstalleringar o Kven skal gjere dette og kor tid o Kva utgifter vert påført verksemdene o Vert det fortsatt levering på Noark standard o Vert det samme system hos alle innhaldsleverandørar, eller ulike system/tilpasningar o Kva arbeidsrutinar må endrast hos saksbehandlar og arkivar o Kva vil dette føre til av organisatoriske -, strukturelle - og prosessendringar Verktøy innhaldsleverandørane brukar i dag Før lanseringa av dagens OEP i 2010 vart det lagt ned mykje arbeid i å utvikla løysing for uttrekk av data i rett format, kvalitetssikring, merking av personnamn med meir. Dette vart utvikla som eit samarbeid mellom verksemdene og systemleverandørane. OEP var ikkje involvert i dette, men stilte berre krav om at uttrekket skulle tilfredstilla definert format. Systemleverandørane løyste dette på likt ulikt vis, men utvikla løysinga i tett dialog med utvalde kundar. Her vart det gjort eit verdfullt arbeid av både systemleverandørar og ikkje minst innhaldsleverandørane som definerte behov. Løysingane for kvalitetssikring og uttrekk vart løyst litt ulikt, men dette er funksjonalitet ein gjerne vil finna:

16 15 - Konfigurera uttrekkskomponenten med rett og oppdatert namn på arkivskapar/verksemd, BaseID, organisasjonsnummer og ev kommunenummer det det er aktuelt - Merka av om opplysningar om sakshandsamar skal vera med i uttrekket - Velja frå - og tildato for produksjon av uttrekk - Velja aktuelt ut-format - Velja kva avdelingar, arkiveiningar, arkivdeler som skal vera med til OEP eller utelatast frå uttrekket til OEP - Velja om interne notat skal vera i uttrekket - Velja korleis postane skal sorterast i fila som vert produsert - Ha funksjonar for merka av personnamn med <PNAVN>Namn</PNAVN> eller fjerna merking både i felt og i fritekst - Førehandsvisa uttrekket på tenlege måtar for å gjera det lett så sjå om noko er feil - Velja kvar den kvalitetssikra fila skal lagrast For SIPS er situasjonen heilt parallell; den enkelte systemleverandør har løyst eksportfunksjonaliteten på ulike måtar. Funksjonalitet ein finn er : - Konfigurera uttrekkskomponenten med rett og oppdatert namn på arkivskapar/verksemd, - Velja utval og møte for produksjon av uttrekk - Funksjonar for overføring av dokument til fillager utanfor brannmur Aktuelle mikrotenester i einnsyn. einnsyn har ikkje starta å utvikla slike tenester enno. Det vil først skje i første halvår 2017, men det er gjort ein del tankar om dette. Ein av grunnane til at ein vil samla inn meir data framover, er at ein ser på muligheitene til å analysera innhald og prosessar i større grad. He kan det finnast mønster og læring som einnsyn ynskjer å kunne tilby tilbake til innhaldsleverandørar/arkivsystem som støtte i arbeidet med kvalitetssikring av informasjon som skal publiserast. Ein kan her t.d sjå føre seg at ein kan analysere seg fram til sannsynlege personnamn/personnummer og melda tilbake dersom dette ikkje er merka korrekt. Eller ein kan sjå på trendar og melde tilbake om det vert levert dokument som burde ha vore sladda eller som mest truleg kunne opnast heilt. Ved at einnsyn skal ta imot informasjon om handsaming av innsynskrav i den nye løysinga, kan det gje muligheit til å gjera analyse på slike data og registera mønster som kan støtta arbeidet til verksemdene. Beriking Ved å ta i mot meir data enn berre det som er definert som offentleg journal, vil ein kunna lenka data i einnsyn med andre datakjelder og kunna sitja att med rikare datasett og dermed grunnlag for fleire og betre tenester. Rapport frå piloten saman med Riksarkivet og Riksantikvaren viser på ein god måte korleis dette kan gjerast.

17 16 Vidare dialog med innhaldsleverandørane og systemleverandørane Kartlegging einnsyn vil i månadskiftet september/oktober senda ut dette notatet til alle som i dag leverer innhald til OEP. Notatet har då vore drøfta i ulike referansegrupper og justert etter innspel derifrå. einnsyn vil og kartleggja status i verksemdene med tanke på systemløysingar, planar med meir. Dette vil vera nyttig informasjon for å byrja arbeidet med ein førebels plan for utrulling til verksemdene. Informasjon, utprøving og testing I løpet av september vil einnsyn ta kontakt med alle systemleverandørane. Innhaldet i dette notatet og i vedlegget vil verta drøfta, og det er ynskje om å få på plass konkrete avtalar om pilotering og utprøving med alle systemleverandørane i samarbeid med aktuelle verksemder dei har som kundar. Dette omfattar og verksemder i Oslo kommune. Pilotering og prototyping einnsyn ynskjer å få prøva ut alternativ 1 i samarbeid med systemleverandørane og utvalde verksemder. einnsyn har alt i gang ein pilot hjå NVE der utprøving av integrasjonspunkt som transportkanal er sentralt. Vidare utprøving av integrasjonspunkt er sentralt og naudsynt. einnsyn visning av politiske saker er under utvikling basert på gamle eksportuttrekk. Første versjon er planlagt sett i drift Videreutvikling av løysinga, inkludert nye funksjonar for uttrekk, er planlagt gjennomført i Plan for utrulling i 2017 Det vil vera naturleg å byrja skissa på opplegg for utrulling til verksemdene som leverer til OEP i dag alt hausten Basert på pilotering og utprøving vil ein hausta erfaring med god praksis. Det vil vera naturleg med gradvis utrulling gjennom hele 2017 og det må lagast opplegg og prioritering for dette.

18 17 Vedlegg 1, Meir om prosessar knytte til dataflyt. Punkt 1-3 i tabellen under, vil føregå hjå verksemdene. Punkt 3 til 21 vil skje i integrasjonspunkta eller i einnsyn. Sjå og skisser av dette tidlegare i notatet. Arbeidsprosess Ansvarleg Kommentar 1 Produsera informasjon (dokument) og metadata (basert på krava i Noark5) Avleverande verksemd, ref 120 verksemder som leverer til OEP. Tenestene som blir brukt til validering og kvalitetskontroll bør gjerast tilgjengeleg til den som opprettar innhaldet 2 Utføra kvalitetskontroll Avleverande verksemd. I dag manuelt, gjennom arkivet/andre. På sikt i større grad automatisert. Skifte frå dagens kvantitative kontroll til kvalitativ kontroll gjennom betre automatiske rutinar. 3 Mapping frå format hjå verksemde til einnsyn sitt format. Avleverande verksemd, anten gjennom standard programvare levert av Difi eller sin systemleverandør einnsyn må definera krav til format. Overgang til JSON-LD gir oss ein «fleksibel» kontainer med triplar som blir overført. I ein tidleg fasen kan dette skje gjennom å «berike» basert på journalpostid. 5 Ekspedera til integrasjonspunkt, må skje meir automatisert enn for tradisjonell meldingsutveksling mellom offentlege verksemder. Avleverande verksemd, anten gjennom standard programvare levert av Difi eller sin systemleverandør Overgang til hendelsesbasert arkitektur, der Difi leverer «mellomløysing» for å emulere denne for gamle løysingar. Tett dialog med systemleverandørar og arkivverket for å få denne tankegangen standardisert. 6 Mottak integrasjonspunkt Difi Nytt REST-basert grensesnitt i

19 18 integrasjonspunktet 7 Validera avsendar Avleverande verksemd Ha eit gyldig verksemdssertifikat. Validering skjer i integrasjonspunkt på sendarsida. 8 Validera mottakar Difi Ha eit gyldig verksemdssertifikat. Validering skjer i integrasjonspunkt. 9 Validera melding, struktur og semantikk Difi/arkivverket Validering opp mot formatstandard. Har behov for og å kunne vite kva data vi har mtp korleis dette kan visualiserast ut mot brukar 10 Sikra autentisitet Difi/Integrasjonspunkt Gjennom bruk av PKI 11 Sikra integritet Difi/Integrasjonspunkt Gjennom bruk av PKI 12 Sikra konfidensialitet Difi/Integrasjonspunkt Gjennom bruk av PKI 13 Adressering Difi/Integrasjonspunkt Gjennom bruk av adresseregister 14 Overføring til mottakar Difi/Integrasjonspunkt Mest sannsynleg CEF edelivery komponentar, i praksis direkte til Difi/eInnsyn. 15 Motta melding Difi/Integrasjonspunkt Integrasjonspunktet er tovegs 16 Dekryptera melding Difi/Integrasjonspunkt Same som over 17 Mottak earkiv/einnsyn Difi Same REST grensesnitt som på integrasjonspunktet. Deretter setter ein i gong handtering gjennom

20 19 mikrotjenestebasert plattform. 18 Logging og kvitteringsfunksjonar Difi Fortløpande logging av meldingar inn i «ELK» stack. Vi har ikkje tenkte gjennom dette punktet heilt enno, men det er fullt mogeleg å tilby «pakkespor» teneste, dvs at vi har eit loggspor heilt frå mottak i integrasjonspunktet til denne er tilgjengeleg i einnsyn. Strengt tatt ikkje behov for kvittering, då ein kan følgje status der. 19 Beriking Gjennom mikrotenester i einnsyn. Må skaffe oss tilgang til fellesregister som GAB mm 20 Registrera innsynskrav 21 Senda innsynskrav til verksemd