eInnsyn i 2017 – info til systemleverandørane
1 eInnsyn i 2017 – info til systemleverandørane Føremål Målet med dette notatet er: 1. 2. 3. 4. Å informera systemleverandørane om status i arbeidet med eInnsyn Dela oppdatert plan for 2017 med viktige milepælar Drøfta behov for samarbeid som eInnsyn ser med tanke på full utrulling og drift av eInnsyn Invitera til konkret dialog om praktisk utprøving 2017 Bakgrunn Kommunikasjonen mellom offentlege verksemder skal i størst mogeleg grad føregå digitalt. Det same skal kommunikasjon mellom offentlege verksemder og innbyggarar, næringsliv og private verksemder. Difi har ansvar for å utvikla nye OEP eller eInnsyn. Frå juni 2016 kom Oslo kommune med som ein sentral part i arbeidet med å utvikla eInnsyn. Gjennom samarbeidet med Oslo er eInnsyn utvida til og å kunna omfatta informasjon om den politiske handsaminga i kommunar og fylkeskommunar. Difi har og ansvar for prosjektet meldingsutveksling i offentleg sektor, sjå https://www.difi.no/artikkel/2016/03/referansearkitektur-meldingsutveksling Prosjektet meldingsutveksling utviklar infrastruktur som skal transportera meldingar på ein trygg og sikker måte mellom offentlege verksemder. Løysinga er basert på kommunikasjon mellom sokalla interasjonspunkt som vert installert både hjå avsendar og hjå mottakar. eInnsyn planlegg å leggja denne infrastrukturen til grunn når meldingar skal sendast mellom innhaldsleverandørar og den nye tenesta eInnsyn. Dette gjeld både informasjon som skal publiserast på eInnsyn og innsynskrav attende til innhaldsleverandøren. Meldingar mellom verksemdene og eInnsyn vil få eit stort omfang. I dagens OEP vert det lasta opp kring 10.000 nye journalpostar kvar dag frå 120 statlege verksemder. Overført til prinsippet om meldingar frå verksemdene til eInnsyn, vil det tilseia at det vil koma minst 10.000 meldingar til eInnsyn kvar dag når tenesta er på plass. I tillegg vil det koma informasjon frå kommunale sektor. Status for arbeidet med eInnsyn I september sende me ut notatet Dataflyt mellom offentlege verksemder og eInnsyn, modellar, ansvar og konsekvensar. Her gjorde me greie for status for prosjektet og korleis me ser føre oss at eInnsyn kan takast i bruk av verksemdene. Her omtalte me og ansvar og kva naturlege rollar innhaldsleverandørane, systemleverandørane og Difi vil ha i arbeidet med å realisera eInnsyn. Utviklinga av eInnsyn er no kome langt. Oslo kommune har gått i produksjon (beta) med søk i politiske saker no i desember 2016. sjå beta.einnsyn.no. På den delen av den samla løysinga som skal erstatta dagens OEP, vil me starta utprøving og testing frå januar 2017. 2 Hovudmilepælar for 2017 (eInnsyn/Ny OEP) Ny OEP skal etter planen i drift frå 1.1.2018 og for arbeidet med prosjektet eInnsyn er det definert fylgjande hovudmilepælar i 2017. Oppgåver Milepæl år-mnd Merknad 1 Plan forvaltning og support utarbeidd 2017-2 2 Basisfunksjonalitet eInnsyn ferdig utvikla og testa 2017-2 3 Integrasjonspunkt og eInnsyn klient ferdig testa og dokumentert 2017-2 Installasjon og test gjennomført i 4-8 verksemder i februar/mars 4 Forvaltning og support utrulling etablert 2017-3 Første del med tanke på utrulling i verksemdene som leverer til OEP 5 Prioriterte nye tenester utvikla og testa 2017-4 6 eInnsyn stat og eInnsyn kommune ferdig utvikla 2017-5 Utviklingsarbeidet vert avslutta. Forvaltning, stabilisering held fram 7 Kommunikasjon verksemder (120) etablert mot eInnsyn test 2017-8 Sikra at alle verksemdene får levert data til eInnsyn test 8 Kommunikasjon verksemder (120) etablert mot eInnsyn prod 2017-11 Sikra at alle verksemdene får levert data til eInnsyn prod 9 eInnsyn overlevert og sett i drift 2018-1 Dagens OEP vert avslutta 3 eInnsyn – ulike modellar for tilknyting Difi hentar i desse dagar inn ein del praktisk informasjon frå alle dei 120 verksemdene som leverer data til OEP. Det gjeld mellom anna kva sak/arkivsystem dei nyttar, kontaktperson i arbeidet med innføring av eInnsyn med meir. Dei 120 verksemdene skal i løpet av 2017 gradvis knytast opp mot ny løysing slik at alt ligg klart til overgangen ved årsskiftet 2017/2018. Difi har definert to ulike måtar å levera data til den nye løysinga på. Alternativ 0 Det me har kalla alternativ 0 vil vera ei overgangsordning i eit avgrensa tidsrom. Lengda på dette tidsrommet er ikkje definert enno. Alternativ 0 vil vera klart til utprøving i eit avgrensa tal verksemder i februar 2017. Deretter vil det verta rulla ut til alle verksemdene fram til august/september 2017. For å knyta seg til eInnsyn etter alternativ 0, må kvar verksemd gjera fylgjande: (Dette berører ikkje sak/arkivsystemet) 1. Filkatalog for data til eInnsyn må opprettast hjå kvar verksemd. 2. eInnsyn klient må lastast ned frå Difi og installerast på server hjå kvar verksemd 3. Integrasjonspunkt må lastast ned frå Difi og installerast saman med eInnsyn klient. Desse to komponentane kjem som ein ferdig installasjonspakke saman med dokumentasjon og oppsett. 4. Konfigurering. Komponentane må konfigurerast til å kommunisera med filkatalog eInnsyn, med kvarandre og med integrasjonspunkt for eInnsyn hjå Difi. Filer som vert lagde i filkatalog eInnsyn, vert handsama av eInnsyn klient etter definerte reglar og deretter vert 1 og 1 journalpost overført til eInnsyn hjå Difi via integrasjonspunkt og vert søkbar i eInnsyn. Figur: Enkel skisse for alternativ 0. Dette alternativet er den enklaste løysinga for å kunna levera data til eInnsyn. Verksemdene vil nytta same OEP-modul som dei brukar i dag til å henta ut data i rett format (Noark4 offentleg journal) og leggja det klart i definert filkatalog for data til eInnsyn. Alternativ 0 føreset ikkje endringar eller justeringar i sak/arkivsystem eller i dagens OEP-modul. 4 alternativ 0+ - inneheld og sti (URL) til publiserte dokument Me ynskjer og å drøfta ei mindre tilpassing av alternativ 0. Eit viktig mål for arbeidet med eInnsyn er å leggja til rette for at verksemdene kan kunna leggja ut/publisera dokument som dei vurderer som offentlege. Ein rapport frå Difi om dette i 2012 konkluderte med at ei lenkje som viser kvar slike dokumentet er å finna, på eigen nettstad eller andre stader, kan vera ein god måte å løysa dette på. Like etter at rapporten om fulltekstpublisering kom i 2012, gjorde Difi tilpassingar i OEP slik at sti til dokument kunne leggjast inn i OEP-basen direkte. Systemleverandørane byrja og å sjå på konkrete løysingar, men dette arbeidet stansa opp. Alternativ 0+ kan vera eit steg på vegen til målet om fulltekstpublisering. Løysinga er ikkje fullgod, men kan opna for at verksemdene kan byrja å prøva ut korleis arbeidet med å publisera dokument best kan leggjast opp. Alternativ 0+ føreset fylgjande: - Systemleverandørane må leggja til eit nytt felt i uttrekket til dagens OEP. I Noark-standarden er det lagt til rette for dette med feltet DOKBESKRIV.OJ->VE.FILREF. Her skal sti (url) til fila leggjast inn. Me ser føre oss at ein justerer modulen slik at det vert mogeleg å definera ein rotsti t.d www.difi.no/offentlege_dokument/...... Denne rotstien vert så lagt til som prefix på dokumentnavnet som ligg i arkivdatabasen (dokument001.pdf) Ein vil på denne måten greitt få generert opp dokumentsti til www.difi.no/offentlege_dokument/dokument001.pdf. Stien vert overført til eInnsyn og fungerer som vegvisar til publiserte dokument. Det må vera mogeleg for verksemdene å definera kva dokument som skal få lagt til sti (URL). Det naturlege vil vera å velja alle journalpostar som ikkje har skjerma informasjon i metadata eller i dokument. Dette kan tilpassast med å filtrera på kodar i metadataskjema. Verksemdene må og ha høve til å overstyra informasjon i sti-feltet dersom det er behov for det. Alternativ 0+ føreset ikkje endringar eller justeringar i sak/arkivsystem eller i dataformat, men eksporten til OEP må ta med eit ekstra felt. Alternativ 1 – ekspeder til eInnsyn Alternativ 1 er den løysinga som Difi meiner bør vera målet for alle verksemdene etter ei viss tid. I dette alternativet ser me føre oss at verksemdene ekspederer informasjon til eInnsyn som ein del av dagleg sakshandsaming eller dagleg arkivarbeid. Ein og ein post må kunna overførast til eInnsyn etter at innhaldet er kvalitetssikra av verksemdene. Med det meiner me at verksemdene har skjerma eller sladda all informasjon som ikkje er offentleg slik at det ikkje skjer feilpublisering av sensitiv informasjon. I alternativ 1 må og sti til dokumentlager leggjast med for alle journalpostar der dokument og vedlegg og kan publiserast. For journalpostar der det er metadata eller dokument som ikkje er offentlege, må det vera enkelt for brukarane å kunna be om innsyn etter gjeldande reglar. 5 Me ser føre oss at data til og frå eInnsyn i prinsippet blir handsama som ei melding, og data til eInnsyn berre vert ein meldingstype av fleire . Alternativ 1 krev tilpassingar i sak/arkivsystemet eller i modular for ekspedering av meldingar. Modul for å senda melding eller ekspedera melding må kunna støtta ein ny type melding som skal gå til eInnsyn. Ny mal for slik melding vil verta nærare definert. Formatet vil vera Noark5, JSONLD. Figur: Melding til eInnsyn vert ein av fleire typar meldingar. Det er oppretta eiga side på Github der sak/arkivleverandørane (og forsovidt alle andre) er inviterte til å koma med behov og innspel til dette arbeidet. https://difi.github.io/move-api/ Alle sak/arkiv leverandørane er også invitert inn på Slack, team Move-Beta, ein kanal for uformelle diskusjonar og erfaringsdeling knytta til etablering av meldingsutveksling internt i forvaltninga. Systemleveradørane har fått info gjennom workshop, webinar med meir om arbeidet med meldingsutveksling og dei er og involverte i pilotar . 6 Informasjon til eInnsyn, grøn – gul – raud I dialogen med referansegrupper og pilotar i eInnsyn, har arbeidet med å publisera dokument hatt stort fokus. Slik publisering er eit hovudmål med den nye ordninga, og det vil vera den største omlegginga frå dagens OEP til eInnsyn. Verksemdene er opptekne av at publisering av dokument skal skje gradvis og på ein trygg og sikker måte. Tilrådingane går i retning av å grovdela informasjon som vert skapt i sakarkiv/systema. Alle verksemder har ein del informasjon som utan atterhald kan publiserast som offentleg, grøn informasjon. På same vis vil dei og ha informasjon som klart skal merkast som ikkje offentleg, raud informasjon. Ein del informasjon vil vera i ei gråsona mellom desse to gruppene, gul informasjon. Utrullinga av eInnsyn vil ta omsyn til dette. Det er eit godt råd å byrja med det som utan tvil kan publiserast. Deretter kan verksemdene få erfaring og byggja etter kvart byggja god kompetanse på problemstillinga som knyter seg til publisering av dokument Her ynskjer me konkrete innspel frå systemleverandørane på korleis desse behova kan løysast på ein god måte. Kvalitetskontroll – skjerma data som ikkje er offentleg Då dagens OEP kom i 2010, utvikla systemleverandørane ein eigen modul for uttrekk av data i rett format. I denne modulen vart det og etter kvart bygd inn funksjonar og rutiner for kvalitetskontroll. Dette arbeidet vil ha stor nytte og ved overgang til eInnsyn. I dialogen med verksemdene har det koma fram ein del behov som må dekkast eller tilpassast. 1. Verksemdene må ha full kontroll på kva data som skal publiserast til eInnsyn og når det skal skje. Det vil sjølvsagt og gjelda dokument og eventuelle vedlegg til hovuddokument 2. Det må vera mogeleg, tidleg i arbeidet på enkelt vis, å kunna markera om ein journalpost kan ekspederast til eInnsyn eller ikkje. Ref grøn, gul og raud informasjon. Det som i første omgang vert sett til gul, må kunna takast fram att for ny vurdering. Innbyggarane har likevel rett til å be om innsyn i alle typar informasjon. 3. Det må vera høve til å ekspedera journalpostar med link til dokument løpande til eInnsyn 4. Verksemdene må ha fleksibilitet til å organisera arbeidet med kvalitetssikring slik dei sjølve finn best og mest praktisk Kanskje er det meste av dette på plass i dei løysingane sin er på marknaden i dag. Det er viktig at brukarane får ein felles ekspederingskanal for ulike typar meldingar. Eigenskapar ved meldingen avgjer automatisk korleis den skal handsamast og kven som er mottakar. Arbeidsflyt kan kanskje vera om lag slik: Klargjer for eInnsyn Gjer utvalg av kva som skal sendast Kvalitetssikre Ekspeder 7 Identifiser meldingstype Bygg melding Valider melding Avlever til integrasjonspunkt Kopling mellom metadata og dokumentlager Alternativa 0+ og 1 føreset at verksemdene kan publesera offentlege dokument på ein server dei disponerer og at stien til dokumenta vert lagd med datasettet til eInnsyn. Ein del verksemder har slike løysingar i dag og dei som ikkje har det må finna gode måtar å løysa dette på. Innsynskrav eInnsyn vil og leggja opp å senda alle innsynskrav som meldingar via integrasjonspunkt til rett verksemd. Det er meldt behov for at det vert sendt ein type status tilbake til eInnsyn og lagd på rett innsynskrav. Det kan vera Under handsaming, innvilga, avslege. Format Det er utarbeida eit nytt dataformat for meldingar som skal overførast til eInnsyn. Dette er basert på RDF og JSON-LD representasjonen av det. Dataformatet byggjer på Noark 5 og felta derifrå, så informasjonselementa og strukturen burde derfor vera godt kjend. Som omtalt i tidlegare notat så ynskjer me på sikt å samla inn meir informasjon ut i frå denne strukturen. Eit første steg er likevel å overføra same datasett som i dag, men på nytt format. Vidare dialog Difi ynskjer konkret dialog med systemleverandørane i det vidare arbeidet med å utvikla eInnsyn. Me vil tru at det i arbeidet med eInnsyn og meldingsutveksling ligg spanande utfordringar og muligheiter også for systemleverandørane. Arbeidet med å få konkrete og fullgode løysingar på plass vert til slutt ei sak mellom verksemdene og dei som leverer system med rett funksjonalitet. Kring midten av januar vil me ta kontakt for å avtale møte. Tema vil då vera informasjon om eInnsyn, drøfta konkrete løysingar, avtala utprøving og pilotering med meir. Kom gjerne med innspel til datoar som kan høva. Kontaktpersonar: Johannes Hunderi (johannes.hunderi@difi.no) Gunnar Urtegaared (gunnar.urtegaard@difi.no) Helsing Gunnar Urtegaard Fagdirektør/prosjektleiar eInnsyn
© Copyright 2024