Arkitekturprinsipper for Pasientreiser ANS

Størrelse: px
Begynne med side:

Download "Arkitekturprinsipper for Pasientreiser ANS"

Transkript

1 Arkitekturprinsipper for Pasientreiser ANS Side 1 av 48

2 Dokumentkontroll: Versjon 1.6 Dato Arkivreferanse 13/00076 Status Godkjent Dokumenteier David Låås, Pasientreiser ANS Godkjent av Marit Kobro, Administrerende direktør Pasientreiser ANS. Godkjent dato Versjonslogg: Dato Versjon Beskrivelse Forfatter Første versjon med overordnede områder for arkitekturprinsipper utarbeidet. David Låås Første versjon av dokumentet etter arbeidsmøte gjennomført 7.1. Kaare Knudsen Dokument oppdatert på alle områder. Kaare Knudsen Dokument oppdatert etter arbeidsmøte gjennomført Kaare Knudsen Dokument oversendt til gjennomlesing og kommentering internt i Greenbird. Kaare Knudsen Dokument oppdatert etter intern QA Greenbird og oversendt Pasientreiser ANS. Kaare Knudsen Endelig versjon levert av arbeidsgruppen (Greenbird og Pasientreiser ANS) Kaare Knudsen Dokument oppdatert og tilpasset Pasientreiser ANS for kapittel 1 8. David Låås Dokument oppdatert og tilpasset Pasientreiser ANS for resterende kapittel. David Låås Dokument oppdatert etter kommentarer fra systemforvaltning. David Låås Dokument ferdigstilt for distribusjon til ledergruppen i Pasientreiser ANS. David Låås Dokument gjennomgått i ledergruppen i Pasientreiser ANS David Låås Dokument godkjent David Låås Innhold publisert i Confluence David Låås Oppdatert beskrivelsen i forhold til DIFIs prosjektveiviser som prosjektmodell David Låås Oppdatert med beskrivelse av knytning mot overordnede arkitekturprinsipper og David Låås offentlige føringer Nytt arkitekturprinsipp "F16 - Eierskap til applikasjoner og komponenter". Nye David Låås kategorier for tilgjengelighet i "TI1 Tilgjengelighet i henhold til tjenesteavtale" Lagt til beskrivelse av NOARK5 i prinsipp F15 og I3. Lagt til beskrivelse av Normen i David Låås SI Lagt til beskrivelse av prinsippenes egenskaper i «Definisjon av arkitekturprinsipp» og ytterligere detaljer i forhold til knytning mot Nasjonal IKT sine arkitekturprinsipper. David Låås Side 2 av 48

3 Innhold 1. INNLEDNING BAKGRUNN FOR ARKITEKTURPRINSIPPENE KNYTNING MOT OVERORDNEDE ARKITEKTURPRINSIPPER OG OFFENTLIGE FØRINGER DEFINISJON AV ARKITEKTURPRINSIPP MÅLGRUPPE FOR ARKITEKTURPRINSIPPENE EIERSKAP TIL ARKITEKTURPRINSIPPENE ANVENDELSE AV ARKITEKTURPRINSIPPENE AVVIK FRA ARKITEKTURPRINSIPPENE PRINSIPPOMRÅDER VIRKSOMHETSPROSESSER P1 - STANDARDISERING AV MANUELLE OG AUTOMATISKE PROSESSER P2 - AUTOMATISERING AV PROSESSER P3 - SELVBETJENTE PROSESSER P4 - GJENBRUKBARE PROSESSER P5 - PROSESSTYRING OG -EIERSKAP P6 - STANDARDISERING AV PROSESSMODELLERING OG NOTASJON TJENESTEORIENTERING OG INFORMASJONSARKITEKTUR T01 - STRATEGI FOR TJENESTEORIENTERING TO2 IDENTIFISERING OG BRUK AV TJENESTER TO3 VIRKSOMHETSORIENTERTE TJENESTER TO4 GJENBRUKBARE TJENESTER TO5 STANDARDER FOR TJENESTER OG INTEGRASJONSLØSNINGER TO6 SENTRALT TJENESTEREGISTER TO7 TJENESTEDESIGN MED CONTRACT FIRST TO8 - FELLES INFORMASJONSMODELL TO9 - MASTERDATA EIERSKAP INTEROPERABILITET I1 - SEMANTISK, ORGANISATORISK OG TEKNISK INTEROPERABILITET I2 FELLES BEGREPSAPPARAT I3 BRUK AV STANDARDER I4 - VALG AV ÅPNE STANDARDER TILGJENGELIGHET TI1 TILGJENGELIGHET I HENHOLD TIL TJENESTEAVTALE TI2 - TILGJENGELIGHET FOR ELEKTRONISKE TJENESTER TI3 - UNIVERSELL UTFORMING TI4 - KANALER OG UAVHENGIGHET TI5 ROBUSTHET OG STABILITET TI6 OVERVÅKNING TI7 - SENTRAL MONITORERING TI8 - STRATEGI FOR OPPGRADERING AV PROGRAM- OG MASKINVARE SIKKERHET SI1 DEFINERT SIKKERHETSNIVÅ Side 3 av 48

4 6.2. SI2 IT-SIKKERHETSPOLITIKK SI3 - SPORBARHET SI4 INTEGRITET OG KONFIDENSIALITET SI5 AUTENTISERING OG AUTORISASJON SI6 LAGRING AV SENSITIVE DATA SI7 ANONYMISERING AV SENSITIVE DATA ÅPENHET Å1 SPORBAR BESLUTNINGSPROSESS MODIFISERBARHET F1 DOMENEDREVET DESIGN F2 RAMMEVERK F3 INGEN HARDKODING F4 LAGDELING AV APPLIKASJONER F5 GJENBRUK F6 INFRASTRUKTURUAVHENGIGHET OG PORTABILITET F7 SENTRAL LAGRING F8 - ENDRINGSDYKTIGHET F9 ARKITEKTURUTPRØVING FOR Å REDUSERE RISIKO F10 BATCHKOMPONENTER OG ONLINE TILGANG F11 - RAPPORTERING, STATISTIKK OG ANALYSE F12 - OPEN SOURCE F13 HYLLEVARE FRAMFOR SKREDDERSØM F14 - BEST-OF-BREED F15 LAGRING OG ARKIVERING AV DATA F16 EIERSKAP TIL APPLIKASJONER OG KOMPONENTER SKALERBARHET OG YTELSE SK1 TILPASSET BEHOV SK2 - SKALERINGSPLAN SK3 YTELSE BRUKSKVALITET B1 ENHETLIGE BRUKERFLATER B2 - GJENKJENNINGSNYTTE B3 - TILRETTELEGGING FOR ULIKE BRUKERGRUPPER B4 - ENHETLIG FEILHÅNDTERING TEST OG VEDLIKEHOLD TV1 VEDLIKEHOLDBARHET TV2 TESTBARHET TV3 FORVALTNING AV TESTDATA TV4 TJENESTEAVTALE FOR TESTMILJØER TV5 AUTOMATISERTE TESTER TV6 STANDARDISERE TESTMILJØ OG BYGGEMILJØ APPENDIKS TERMINOLOGI REFERANSER Side 4 av 48

5 Side 5 av 48

6 1. Innledning 1.1. Bakgrunn for arkitekturprinsippene I Pasientreiser ANS sin strategi for er et av hovedmålene standardiserte løsninger og konsolidering av teknisk infrastruktur for pasientreiseområdet. Et av de identifiserte tiltakene for å oppnå dette er at det etableres arkitekturprinsipper for å sikre god videreutvikling av teknologien. Målet med arkitekturprinsippene er at arkitektene i Pasientreiser ANS skal ha et verktøy å styre utviklingen i systemene etter for å sikre at løsninger som endres og etableres ikke avviker fra ønsket retning, samt å sikre en plattform og arkitektur som understøtter behovet. Dette dokumentet oppsummerer disse arkitekturprinsippene som understøtter Pasientreiser ANS sin strategi for dette området Knytning mot overordnede arkitekturprinsipper og offentlige føringer Regjeringen har ved fremleggelsen av Digitaliseringsprogrammet På nett med innbyggerne og St. meld nr. 19 ( ) - Ei forvaltning for demokrati og fellesskap, besluttet syv overordnede ITarkitekturprinsipper. Prinsippene skal fungere som et sett med felles retningslinjer for alt arbeid med IT i offentlig sektor. De skal bidra til at IT-løsningene henger godt sammen med virksomhetenes oppgaveløsing, og derved legge til rette for bedre og mer helhetlige digitale tjenester. Prinsippene skal legges til grunn ved etablering av nye IT-løsninger eller ved vesentlige ombygginger av eksisterende IT-løsninger. Difi har basert på dette etablert et sett med overordnede arkitekturprinsipper for offentlig sektor. Nasjonal IKT har etablert et sett med arkitekturprinsipper som gjelder for alle prosjekter og aktiviteter som ivolverer IKT i spesialisthelsetjenesten. De 9 prinsippene fra Nasjonal IKT er: Helhetlig tilnærming Prosessorientering Tjenesteorientering Interoperabilitet (evne til samhandling) Informasjonssikkerhet Tilgjengelighet Brukskvalitet Endringsevne Informasjonsforvaltning Mer informasjon om disse finnes i dokumentet "Prinsipper for virksomhetsarkitektur fra Nasjonal IKT v2.0", og på HelseWikien til Nasjonal IKT. Pasientreiser ANS har etablert et sett med spesifikke arkitekturprinsipper som gjelder innen pasientreiseområdet. De overordnede prinsippene fra DIFI og sektorspesifikke prinsipper fra Nasjonal IKT er lagt til grunn for etableringen. Prinsippene er utformet slik at de ikke skal være i motstrid med Side 6 av 48

7 prinsippene for offentlig sektor generelt, og helsesektoren spesielt, slik disse er formulert fra Difi og Nasjonal IKT. Følgende tabell viser sammenhengen mellom overordnede prinsipper fra DIFI, sektorspesifikke prinsipper fra Nasjonal IKT og Pasientreiser ANS sine domenespesifikke arkitekturprinsipper: Overordnede prinsipper (DIFI) Sektorspesifikke prinsipper (Nasjonal IKT) Pasientreiser ANS arkitekturprinsipper Tjenesteorientering Prosessorientering Tjenesteorientering Tjenesteorientering og informasjonsarkitektur Interoperabilitet Interoperabilitet Interoperabilitet Tilgjengelighet Tilgjengelighet Tilgjengelighet Sikkerhet Informasjonssikkerhet Sikkerhet Åpenhet Interoperabilitet Åpenhet Fleksibilitet Endringsevne Modifiserbarhet Test og vedlikehold Skalerbarhet Endringsevne Skalerbarhet og ytelse Helhetlig tilnærming Virksomhetsprosesser Brukskvalitet Brukskvalitet Informasjonsforvaltning Tjenesteorientering og informasjonsarkitektur 1.3. Definisjon av arkitekturprinsipp Et arkitekturprinsipp er definert som en regel eller retningslinje som skal ligge til grunn ved etablering eller endring av en arkitektur. Arkitekturprinsippene gir retningslinjer for hva som skal hensyntas og hvordan man analyserer, designer, utvikler og tester IT-løsninger, -komponenter og tjenester tilpasset det området arkitekturprinsippene er ment å skulle dekke. Prinsippene skal ha følgende egenskaper: Stabile - Prinsippene skal være stabile over lang tid, og ikke være knyttet til rammebetingelser som potensielt kan endres hurtig. Robuste Prinsippene skal være robuste, i den forstand at de skal gi konsistente og gode veiledninger både for enkle og komplekse arkitekturmessige utfordringer. Komplette Prinsippene skal dekke alle forhold knyttet til arkitekturmessige beslutninger. Konsistente - Prinsippene skal være innbyrdes konsistente. Det skal ikke være aspekter ved et prinsipp som står i direkte motsetning til intensjonen i et annet prinsipp. Samtidig må det være rom for tolkninger som gir nødvendig fleksibilitet. Forståelige - Prinsippene skal være forståelige for målgruppen, og det skal være tydelig hva som er formålet med prinsippet. Relevante Prinsippene skal være tilpasset de spørsmål som er relevante ved utforming av arkitektur. Overordnede Prinsippene skal gi overordnede retningslinjer, ikke detaljstyre. Side 7 av 48

8 1.4. Målgruppe for arkitekturprinsippene Målgruppen for dette dokumentet er i første rekke arkitektene hos Pasientreiser ANS der dokumentet fungerer som et verktøy og støtte ved utøvelse av arkitektrollen. I tillegg bør følgende grupper kjenne til arkitekturprinsippene for Pasientreiser ANS: Ledere Ledere i Pasientreiser ANS skal godkjenne arkitekturprinsippene og være kjent med disse. Prosjektledere Alle prosjektledere for prosjekter i regi av Pasientreiser ANS bør være kjent med arkitekturprinsippene og de føringer som disse gir for valg knyttet til arkitektur i prosjektet. Systemeiere Systemeiere bør kjenne arkitekturprinsippene ved utøvelse av systemeierskapet. Systemeiere samarbeider allerede i dag tett med arkitekter slik at arkitekturprinsippene ivaretas gjennom dette. Leverandører Eierskapet til endringer og valg som gjøres i forhold til arkitektur og teknologi skal være hos arkitektene i Pasientreiser ANS. Leverandører bør være kjent med Pasientreiser ANS sine arkitekturprinsipper slik at gjennomføring av endringer understøtter og følger de etablerte arkitekturprinsippene. Dette dokumentet inneholder en samling med arkitekturprinsipper tilpasset pasientreiseområdet på både overordnet og detaljert teknisk nivå. Denne formen er beholdt for å samle alle arkitekturprinsipper i et dokument. Det er ikke forventet at alle målgrupper kjenner detaljene tilknyttet alle prinsipper, men dette skal ivaretas av arkitektene i Pasientreiser ANS Eierskap til arkitekturprinsippene Arkitekturprinsippene og dokumentasjonen av disse eies og forvaltes av arkitektene i Pasientreiser ANS Anvendelse av arkitekturprinsippene For alle tjenester og løsninger skal det gjennomføres en løpende vurdering i forhold til anvendelse av arkitekturprinsippene. Ved all nyutvikling og ved alle større endringer som gjennomføres skal endringene vurderes mot arkitekturprinsippene. Aktiviteter: Fremtidige løsninger vurderes i forhold til hvordan disse støtter opp om arkitekturprinsippene i planleggingsfasen i prosjektet. Løpende vurdering av løsning under utvikling opp mot arkitekturprinsippene. Milepæler: Godkjennelse av løsningsarkitektur i beslutningspunkt BP3 - Beslutte prosjektgjennomføring. Periodemessig kvalitetsgjennomgang av arkitektur. Side 8 av 48

9 Prosjekter skal som et minimum evalueres mot gjeldende arkitekturprinsipper i planleggingsfasen i prosjektet før BP3 beslutning tas. Eventuelle avvik fra gjeldende arkitekturprinsipper skal forklares og dokumenteres som en del av grunnlaget for BP3 beslutning. For ytterligere detaljer knyttet til prosjektmodellen til Pasientreiser ANS se Avvik fra arkitekturprinsippene Alle avvik fra arkitekturprinsippene skal dokumenteres og konsekvensutredes. Dette gjelder avvik i forhold til avtaler, kravspesifikasjoner og løsningsbeskrivelser som utarbeides underveis i prosjekter og ved endringer i systemene. Som et minimum skal prosjekter dokumentere eventuelle avvik i forhold til arkitekturprinsippene i planleggingsfasen som inngår som grunnlag til BP3 beslutning. Brudd på arkitekturprinsipper som ikke er dokumentert som en del av arkitekturutredningen og godkjent samtidig med denne skal avklares med arkitekter Prinsippområder Prinsippene i dokumentet er gruppert i henhold til prinsippområdene i tabellen. Denne inndelingen inneholder alle prinsippområder som definert av DIFI, og i tillegg områdene vi mener bør dekkes og som p.t. ikke er dekket av Difi s overordnede arkitekturprinsipper. Prinsippområder Prosesser (P) Tjenesteorientering (TO) Interoperabilitet (I) Tilgjengelighet (TI) Sikkerhet (SI) Åpenhet (Å) Fleksibilitet (F) Skalerbarhet (SK) Brukskvalitet (B) Test og vedlikehold (TV) Side 9 av 48

10 2. Virksomhetsprosesser Virksomhetsprosesser eies og utføres av virksomheten. En virksomhetsprosess bidrar til leveranse av et produkt eller en tjeneste til en kunde. Målene ift. utvikling av fleksible, automatiske og selvbetjente prosesser på tvers av systemer er veldig tett knyttet til gevinstene virksomheten får ut av IT, og arkitekturprinsippene innenfor prosessarkitektur gir derfor en del implikasjoner for andre typer arkitekturprinsipper. Prinsipper: P1 - Standardisering av manuelle og automatiske prosesser P2 - Automatisering av prosesser P3 - Selvbetjente prosesser P4 - Gjenbrukbare prosesser P5 - Prosesstyring og -eierskap P6 - Standardisering av prosessmodellering og notasjon 2.1. P1 - Standardisering av manuelle og automatiske prosesser Automatiske og manuelle prosesser skal være standardisert og i størst mulig grad utføres og oppleves likt av alle brukere av systemet. En automatisk prosess 1) skal være likt implementert og konfigurert i alle systeminstanser og for alle brukere av samme rolle av denne prosessen. Med brukere menes både personer og andre systemer, både interne og eksterne. En manuelle prosess 2) skal ha samme integrasjon og logiske grensesnitt mot omkringliggende innganger og utganger i den totale prosessen. Det skal kun finnes én versjon av en prosess i produksjon. o Det kan finnes maksimalt to versjoner av en prosess i produksjon i kortere overgangsperioder. 1) En automatisk prosess er i sin helhet implementert og utført uten menneskelig interaksjon. 2) Med manuell prosess menes, i denne sammenhengen, en arbeidsflyt som enten krever menneskelig interaksjon underveis eller som delvis støttes av og er implementert i systemet. Sikre likebehandling av pasienter uavhengig av kontor. Forenkle samarbeid og erfaringsutveksling. Sørge for at prosessforbedringer blir implementert samtidig, likt og effektivt for alle. Forenklet opplæring. Teknologiske løsninger skal understøtte prinsippet om standardiserte og automatiske prosesser og ikke gi valgfrihet i gjennomføringen av en prosess. Tilrettelegge for lik konfigurasjon av systemene. Det forutsettes av virksomhetsprosessene på forhånd er definert på et funksjonelt nivå. Side 10 av 48

11 2.2. P2 - Automatisering av prosesser Prosesser som ikke krever menneskelig skjønn eller vurderinger skal søkes automatisert. Forenkle og effektivisere prosesser, både tekniske og funksjonelle. Bidrar til å standardisere arbeidsprosesser. Redusere muligheter for manuelle feil. Prosesser må først standardiseres og integreres med dagens prosess før disse kan automatiseres. Reduserer behovet for manuelle arbeidsoppgaver P3 - Selvbetjente prosesser Det skal legges til rette for selvbetjent interaksjon med Pasientreiser. Krav om refusjon, bestillinger, forespørsler om oversikt over egen saksgang skal kunne utføres av brukerne selv. I første rekke skal pasientene, men også andre brukere som er avhengig av tjenester og informasjon fra Pasientreiser gis anledning til å håndtere mest mulig selv. Pasienten bør kunne velge om informasjon om at vedtak foreligger, eller andre opplysninger, skal varsles elektronisk med for eksempel epost eller SMS. Løsningene skal være tilgjengelig eller lett kunne gjøres tilgjengelig på flere typer kanaler (se 12.1, Terminologi). Unngå manuelle oppgaver. o Unngå dobbel føring og arkivering, eksempelvis ren inntasting fra papirskjema, scanning av reiseregninger og lignende. Forenkle og effektivisere saksbehandling. Redusere saksbehandlings tid og kost. Bidra til større åpenhet og tjenesteyting (service) til pasienter, bl.a. ved at det gis bedre innsyn i saksbehandlingsgangen og beslutninger. Vil kreve økt sikkerhet og tilgangsstyring for systemene og løsningene. Fokus på brukervennlighet (usability) og tilgjengelighet overfor alle brukergrupper P4 - Gjenbrukbare prosesser Automatiske prosesser skal kunne gjenbrukes, for eksempel som tjenester, i andre prosesser. Side 11 av 48

12 Det skal legges til rette for at sentrale automatiske prosesser skal kunne gjøres tilgjengelig for gjenbruk. Det vil si de må være autonome, ha veldefinerte og logisk løst koplete grensesnitt. Prosessene bør være tenkt mest mulig helhetlig, det vil si håndtere flest mulig kjente aspekter innenfor sitt område, slik at ikke små variasjoner i for eksempel inngangskriterier gjør at prosessen ikke lenger er gjenbrukbar. Prosessene på virksomhetsnivå bygger på fellestjenester og opererer på entiteter fra felles informasjonsmodell. Prosessforbedringer deles bredt og øker kvaliteten raskere. Ved at prosessene benytter entiteter fra en felles informasjonsmodell for virksomheten vil en få en god oversikt over nødvendige integrasjoner og informasjonsavhengigheten innenfor virksomhetsområdet. Krever sentral styring og innsikt i hvordan prosesser defineres og utvikles. Det finnes en felles informasjonsmodell P5 - Prosesstyring og -eierskap Prosesser på virksomhetsnivå defineres, kontrolleres og eies av virksomheten, og er basert på deres behov. Det er viktig at prosessene er definert ut fra virksomhetens funksjonelle behov, og at det er de som bestemmer disse som har eierskap til hvordan prosessene fungerer. Det bør benyttes eller utvikles (defineres) et rammeverk for kontinuerlig forbedring av prosesser, gjennom iterativ modellering implementering, simulering, monitorering og optimalisering. Det vil for eksempel si at virksomheten gjennom tilbakemelding fra monitorering holdes oppdatert på status og hvordan endringer i prosessen påvirker viktige målepunkter (KPIer) slik at ytterligere optimalisering kan gjøres. Sikre riktig implementering av forretningslogikk. Sikre at hele organisasjonen er involvert, har eierskap til og bidrar til videreutvikling og kontinuerlig forbedring av virksomhetskritiske prosesser. Det må klart defineres mandat og eierskap til (overordnede) virksomhetsprosesser P6 - Standardisering av prosessmodellering og notasjon Prosessmodellering skal følge industristandard, BPMN (Business Process Modeling Notation). Sikre enhetlig begrepsforståelse og dokumentasjon av prosesser. Forenkle design og kvalitetssikring av prosesser. Side 12 av 48

13 Lette og effektivisere overgang fra design til implementering både i forhold til implementasjon av nye prosesser og ved endringer i eksisterende prosesser. Side 13 av 48

14 3. Tjenesteorientering og informasjonsarkitektur Tjenesteorientert arkitektur er et arkitekturkonsept for IT-løsninger som beskriver hvordan man lager, setter sammen eller benytter en forretningsprosess og hvordan løsningene kan synliggjøres som gjenbrukbare tjenester. Tjenesteorientert arkitektur er en måte å organisere og utnytte distribuert funksjonalitet på tvers av organisasjonen, som muliggjør gjenbruk av funksjonalitet og data fra ulike IT-løsninger. Informasjonsarkitekturen, en forutsetning for tjenesteorientering, beskriver de viktigste informasjonsentitetene som inngår i virksomheten, relasjoner mellom dem, og i hvilke system- eller domeneområder de hører hjemme. Denne danner grunnlaget for modellering av informasjonsflyt i prosesser og spesifisering av tjenester. Informasjonsarkitekturen er gjerne stabil over tid, med få endringer i det eksisterende, bortsett fra rene tillegg av nye entiteter og områder. Prinsipper: TO1 - Strategi for tjenesteorientering TO2 - Identifisering og bruk av tjenester TO3 - Virksomhetsorienterte tjenester TO4 - Gjenbrukbare tjenester TO5 - Standarder for tjenester og integrasjonsløsninger TO6 - Sentralt tjenesteregister TO7 - Tjenestedesign med contract first TO8 - Felles informasjonsmodell TO9 - Masterdata eierskap 3.1. T01 - Strategi for tjenesteorientering Tjenesteorientering skal vurderes der det er hensiktsmessig som en overordnet strategi for utvikling av funksjonalitet eller valg av applikasjoner. Forretningsorienterte tjenester skal benyttes når: o En applikasjon trenger å hente, oppdatere data eller bruke funksjonalitet i andre applikasjoner. o En applikasjon skal tilby funksjonalitet til eksterne systemer. Det velges en begrenset, lettvekts og trinnvis tilnærming til tjenesteorientering. Oppnå løs kobling mellom applikasjoner. Oppnå gjenbruk av funksjonalitet. Støtte fleksibel komposisjon av tjenester og prosesser. Finne et riktig nivå og arkitektur for tjenesteorientering tilpasset Pasientreisers behov i en mindre skala før videre innføring vurderes og endelig arkitektur fastsettes. Side 14 av 48

15 Unngå eller fjerne spesialiserte punkt-til-punkt integrasjoner mellom ulike applikasjoner, og gå over til sentrale helhetlige og gjenbrukbare tjenester. En felles informasjonsmodell ligger til grunn for definisjon av tjenestene TO2 Identifisering og bruk av tjenester Identifisering av gjenbrukbare tjenester skal utføres i henhold til det fremtidige målbildet for virksomheten, ikke kun med tanke på førstkommende leveranse. Det skal benyttes en metodisk tilnærming for identifisering og bruk av tjenester. Dersom man velger å vente med å realisere identifisert gjenbrukbar funksjonalitet som en tjeneste, skal man likevel legge til rette for at dette kan gjøres i fremtiden. Oppnå helhetlige tjenester, og ikke fragmentert og delvis duplisert funksjonalitet. Oppnå en strukturert tjenesteoversikt. Oppnå mer grovkornede forretningsorienterte tjenester. Alltid analysere et helhetlig og framtidig behov, og ikke bare implementere en spesifikk løsning isolert TO3 Virksomhetsorienterte tjenester Tjenester skal være virksomhetsorienterte og i henhold til en felles informasjonsmodell. En tjeneste fokuserer på hva en konsument får eller oppnår, og ikke tekniske detaljer om oppgaven som utføres, hvilke system som kalles og hvor data fysisk lagres. Det skal være lett for virksomheten å forstå funksjonelt hva en tjeneste gjør. En tjeneste skal ha en veldefinert funksjon med en detaljeringsgrad (granularitet, størrelse, omfang) tilpasset virksomhetsprosessene tjenesten er ment å støtte. En tjeneste har gjerne ett sett med flere operasjoner. En tjeneste skal være logisk og teknisk løst koblet. Legge til rette for virksomhetsfokus isteden for teknologi- og systemfokus i implementasjonen av virksomhetsprosesser. Oppnå tjenester og prosesser som møter forretningssidens behov. Gi en enkel og standardisert integrasjon mellom tjenester og prosesser. Det må være etablert en felles informasjonsmodell som tjenestene baseres på. Side 15 av 48

16 3.4. TO4 Gjenbrukbare tjenester Tjenester skal implementeres med tanke på gjenbruk på tvers av applikasjoner og ut mot eksterne konsumenter. Sentrale fellestjenester skal utvikles med tanke på gjenbruk. Dette kan være tjenester som er utviklet internt eller integrerer mot eksterne tjenester og eksponerer disse for interne applikasjoner. o Eksempler på sentrale fellestjenester som er eksterne er personregisteret, GAB, frikortregister og utsendelse av sms og epost. o Eksempler på sentrale fellestjenester utviklet internt er håndtering av rekvisisjoner, med operasjoner for oppdatering og søk, og behandlingsstedsregister med tilhørende operasjoner. Funksjonalitet som skal eksponeres til eksterne systemer skal følge tjenesteorienterte prinsipper med fokus på granularitet og gjenbrukbarhet. Unngå fragmentert og duplisert kode. Øke og sikre kvalitet på kode ved implementering av mer gjennomtenkt, gjennomtestet og velprøvd (gjenbrukt) kode. Det må etableres et definert eierskap og ansvarsforhold til fellestjenestene mht. drift og forvaltning TO5 Standarder for tjenester og integrasjonsløsninger Nye systemer skal utvikles etter tjenesteorienterte prinsipper basert på vedtatte og standardiserte åpne teknologier og løsninger. Nye systemer eller applikasjoner bør støtte webservices. Integrasjon mellom komponenter og applikasjoner, fellestjenester og tjenester for eksterne konsumenter skal realiseres gjennom en sentral integrasjonsløsning. En mulighet er å realisere denne integrasjonen gjennom tjenester på en tjenestebuss (ESB). Det skal legges vekt på å velge delkomponenter som kan tilby funksjonalitet som tjenester via standardiserte grensesnitt. Utveksling av løsninger, konsepter og kompetanse på tvers av applikasjons- og domeneområder. Muligheten til å kunne utnytte kompetanse i developer communities. Sikre kvalitet, gjennom utprøvde løsninger som følger utbredte standarder. Forenkle integrasjonsutvikling over tid ved å sikre at kunnskap tilegnet i utvikling av en tjeneste kan benyttes til det fulle i utviklingen av den neste. Unngå leverandørbindinger. Side 16 av 48

17 Krever kompetanse og erfaring på tjenesteorientering, mellomvare og integrasjonsløsninger TO6 Sentralt tjenesteregister Tjenester skal katalogiseres og gjøres tilgjengelig gjennom et felles register. Tjenestespesifikasjon, WSDL og eksempler på bruk av tjenesten skal dokumenteres. Koblingene mellom grensesnitt og informasjonsmodellen skal dokumenteres. Avhengigheter til eksterne og interne tjenester, dvs. tjeneste konsumenter og produsenter skal dokumenteres. Tjenestene må kvalitetssikres og godkjennes. Status og livssyklus for tjenesten skal styres av Pasientreiser ANS. Det er lett å få oversikt over eksisterende tjenester, som bidrar til gjenbruk. Oversikt over tjenester fungerer som eksemplifisering av beste praksis. Registrerte tjenestekandidater bidrar til samordnet utvikling av framtidige tjenester. Sentralisering av informasjon om tjenester forbedrer dokumentasjon og dermed vedlikeholdet av tjenestene. Tjenesteregisteret bør være en integrert del av tjenestenes livssyklus, og dermed brukes aktivt i alle faser av en tjeneste, av arkitekter, ledere og utviklere TO7 Tjenestedesign med contract first Tjenester skal designes og utvikles etter contract first prinsippet. Design og utvikling starter med å definere grensesnittet for tjenesten først. o I motsetning til kode først der grensesnittet lages ut fra kode som kanskje i utgangpunktet ikke var ment å bli eksponert. Det viktigste i denne sammenheng er å ha kontroll på grensesnittet over tid, dvs. logisk/semantisk oppbygging og teknisk spesifikasjon. Sikre godt tjenesteorientert design: o Ved at fokus er på virksomhets tjenester og grensesnitt og ikke intern implementasjon. o Løskoblede tjenester med riktig granularitetsnivå. o Fremme gjenbruk. Sikre at ikke konsumenter påvirkes negativt av endringer i tjenesten når det ikke bevisst er gjort endringer i grensesnittet til denne TO8 - Felles informasjonsmodell Det skal etableres en felles informasjonsmodell for hele virksomhetsområdet. Side 17 av 48

18 Det lages en logisk konseptuell informasjonsmodell som deles inn i informasjonsdomener med de viktigste informasjonsentitetene og relasjonene mellom dem. Som et minimum skal informasjonsmodellen dekke entiteter som skal: o Eksponeres ut til eksterne konsumenter. o Gjenbrukes av interne systemer i sentraliserte tjenester og prosesser. Informasjonsmodellen inngår i prosesser, tjenester og applikasjoner. Den felles informasjonsmodellen kan bestå av generiske gjenbrukbare entiteter på tvers av domener, entiteter som eksponeres til eksterne konsumenter, og spesialiserte entiteter innenfor hvert domene. Informasjonsmodellen bør basere seg på relevante standarder der det finnes for tilsvarende domeneområder eller entiteter, for eksempel for Person i [4]. Sikre felles begrepsbruk og forståelse internt i virksomheten og i dialog med leverandører og framtidige brukere av tjenester fra Pasientreiser. Danner grunnlag for tjenestedefinering, spesielt for fellestjenester. Forenkle implementering av integrasjon mellom interne og eksterne systemer. Bidra til økt gjenbruk og mindre duplisering av funksjonalitet. Informasjonsmodellen må utvikles og oppdateres kontinuerlig slik at den fyller gjeldende og krav fra nye prosjekter. Det må innføres sterk sentral styring (governance) av informasjonsmodellen, slik at denne: o Holdes oppdatert og blir brukt. o Blir kommunisert og etterfulgt av leverandører. o Blir benyttet, kommunisert og overholdt i grensesnitt mot konsumenter av tjenester. Fellestjenester skal være basert på felles informasjonsmodell TO9 - Masterdata eierskap Det skal være definert et klart eierskap til alle entiteter i informasjonsmodellen. Det skal ikke være overlapp i eierskap til informasjonsentiteter som inngår i systemer eller tjenester. Dvs. det skal aldri være tvil om hvor data for en entitet vedlikeholdes og hvordan den oppdateres. Prosesser eller tjenester som endrer data skal sikre konsistent oppdatering av masterdata. Ideelt skal det finnes bare én vei for oppdatering av masterdata. Dette forenkler eventuell implementering av cache- eller replikeringsløsninger. Dette kravet til konsistens må imidlertid balanseres mot ofte motstridende hensyn til ytelse og tilgjengelighet. Samme data skal fortrinnsvis lagres ett sted. Der dette ikke er mulig av hensyn til ytelse, tilgjengelighet eller kostnader, skal en søke benytte rene replikerte data for lesing framfor synkroniseringsløsninger mellom datakilder. Sikre god datakvalitet og konsistens i data som benyttes på tvers av flere systemer. Unngå duplisering av data. Side 18 av 48

19 4. Interoperabilitet Interoperabilitet er den evne og det potensial forretningsprosessene med tilhørende IT-løsninger har til å utveksle data og dele informasjon. Prinsipper: I1 Semantisk, organisatorisk og teknisk interoperabilitet I2 Felles begrepsapparat I3 Bruk av standarder I4 - Valg av åpne standarder 4.1. I1 - Semantisk, organisatorisk og teknisk interoperabilitet Enhver IT-løsning som skal samhandle med en eller flere andre IT-løsninger skal designes for interoperabilitet. Interoperabilitet skal ivaretas på tre områder: Semantisk interoperabilitet skal oppnås ved felles begreps- og informasjonsmodeller innenfor det aktuelle området. Organisatorisk interoperabilitet skal oppnås gjennom samordning av arbeidsprosesser og endringer av organisatoriske forhold nødvendig for samhandling. Teknisk interoperabilitet skal oppnås blant annet ved å bruke forvaltningsstandarder fra Referansekatalog for offentlig virksomhet samt åpne standarder. Oppnå bedre samhandling og effektive arbeidsprosesser. Muliggjøre og lette integrasjon mellom ulike systemer. Redusere integrasjonskostnader I2 Felles begrepsapparat Begreper skal defineres konsistent på tvers av virksomheten med dokumenterte, omforente, tydelige og kommuniserte definisjoner. Begreper benyttet innen pasientreiseområdet skal dokumenteres og være kjent i organisasjonen. Dette for å sikre felles forståelse i organisasjonen. Begrepene bør være komplette, tydelige og nøyaktige. Unngå misforståelser og sikre effektiv kommunikasjonen. Side 19 av 48

20 4.3. I3 Bruk av standarder IT-løsninger eller tjenester som etableres skal være basert på vedtatte åpne standarder. Alle løsninger skal være basert på åpne standarder gitt at standarden har modenhet, utbredelse og en passende anvendelse. Enhver komponent i en tjeneste har et veldefinert grensesnitt basert på en åpen standard, f. eks SOAP. Tjenester for døgnåpen forvaltning og samhandling med andre etater skal følge standarder for offentlig sektor [3]. o Med vedtatte menes for eksempel førende prinsipper fra DIFI og National IKT, krav i NOARK5, Normen o.l. Unngå proprietære og fordyrende løsninger. Unngå unødige leverandørbindinger. Unngå avhengighet til lite tilgjengelig og potensielt kostbar spesialkompetanse. Referansekatalog for IT-standarder i offentlig sektor benyttes ved etablering av it-løsninger og tjenester. Det skal dokumenteres hvilke standarder fra referansekatalogen og hvilke åpne standarder utover dette som skal benyttes eller som er i bruk i Pasientreiser sine prosjekter I4 - Valg av åpne standarder Bruk av åpne vedtatte standarder skal prioriteres framfor proprietære løsninger på alle nivå og i alle teknologier. Sikre interoperabilitet i løsninger. Sikre godt utvalg av alternative løsninger slik at underliggende teknologier lettere kan byttes ut. Oppnå leverandøruavhengighet. Større tilgang til kompetanse i flere miljøer. Dette prinsippet er viktigst innenfor integrasjon, tjenesteutvikling og prosessimplementeringer, og mindre viktig innen for et avgrenset funksjonelt område, som gjerne dekkes av en best-of-breed applikasjon. Side 20 av 48

21 5. Tilgjengelighet Med tilgjengelighet for publikumstjenester menes at alle tjenester som realiseres ved hjelp av IT skal kunne brukes av innbygger/næringsliv når behovet er der både med hensyn til tidspunkt, bruksmåte og plassering. Med tilgjengelighet for internløsninger menes tilgjengelighet slik som reflektert i tjenesteavtalen for denne løsningen eller tjenesten. Prinsipper: TI1 - Tilgjengelighet i henhold til tjenesteavtale TI2 - Tilgjengelighet for elektroniske tjenester TI3 - Universell utforming TI4 - Kanaler og uavhengighet TI5 - Robusthet og stabilitet TI6 Overvåkning TI7 Sentral monitorering TI8 Strategi for oppgradering av program- og maskinvare 5.1. TI1 Tilgjengelighet i henhold til tjenesteavtale Enhver løsning eller tjeneste skal designes for tilgjengelighet som er i henhold til en avtalt tjenesteavtale. Krav om oppetid stiller krav til en robust arkitektur, riktige teknologivalg og en metodikk som sikrer at løsningene blir bygget i henhold til planlagt kvalitet fra starten av og kan ikke enkelt løses i ettertid. Tjenesteavtalen skal reflektere løsningens eller tjenestens anvendelse, bruksmønster og i hvor stor grad den er virksomhetskritisk. Selvbetjeningsløsninger rettet mot publikum skal ha tjenesteavtaler iht. prinsipper for døgnåpen forvaltning. Interne løsninger skal ha tjenesteavtaler som reflekterer graden av hvor virksomhetskritisk løsningen er. Eksempelvis opererer Pasientreiser med oppetidskrav (SLA) ovenfor PRK ene på 99,3 %. Nedetid omfatter per definisjon i Pasientreisers SLA også at responstiden overstiger en spesifisert maks responstid for tjenesten, og betyr ikke nødvendigvis at hele tjenesten er nede. Standardnivåer for SLA: Kategori SLA-nivå Forklaring til nivå Timer nedetid per måned ved dekning mandag til fredag 08:00 16:00 (med 260 virkedager i året og 2080 timer per år). Timer nedetid per måned ved dekning mandag til fredag 07:00 20:00 og lørdag/søndag 07:00 17:00 (med 365 dager og 4430 timer per år). Kritisk 99,9 % Høy tilgjengelighet, eks. PRIMO tjenester for borger. 0,2 timer 0,4 timer Side 21 av 48

22 For virksomhetskritiske tjenester som benyttes i selvbetjeningsløsninger. Høy 99,5 % For virksomhetskritiske løsninger som kun benyttes av «interne» brukere. 0,9 timer 1,8 timer Som for PRO og Nissy i gjeldende driftsavtale med NHN. Medium / Lav 99,0 % - 95,0 % Ikke kritiske tjenester. 1,7 timer 8,7 timer 3,7 timer 18,5 timer SLA-nivå angir den samlede SLA for tjenesten og ikke de enkelte komponenter. SLA-nivå gjelder kun innenfor dekningsperioden som avtales fra tjeneste til tjeneste. Før en tjeneste plasseres og avtales i en SLA-avtale skal arkitekter vurdere realismen i SLAnivået. Ved etablering av nye tjenester skal nivået tidlig avtales da dette gir føringer på infrastruktur og oppsett av løsningene. Sikre stabilitet, robusthet og oppetid for bruker av tjenesten. For å kunne måle nedetid basert på faktisk logget responstid på tjenester så må det defineres klart på hvilket lag responstiden måles. For eksempel kan denne begrenses til å måle svartid i tjenestelaget, eller den kan måles helt opp til GUI. For selvbetjeningsløsninger er det urealistisk å måle helt opp til GUI på grunn av begrensninger som ligger utenfor Pasientreisers kontroll, som dårlig internettkapasitet hos kunde, etc., så målinger på tjenestelagsnivå er i dette tilfellet mest realistisk. For at nedetid skal kunne beregnes er overvåkningsløsninger avhengig av å vite hva maksimal responstid for en tjeneste kan være slik at det kan trigges alarmer og logges avvik basert på dette TI2 - Tilgjengelighet for elektroniske tjenester Selvbetjeningsløsninger knyttet til Pasientreiser skal i utgangspunktet være tilgjengelig døgnet rundt. Selvbetjening døgnet rundt betyr imidlertid ikke saksbehandling 24/7, men mulighet for: o Å henvende seg til Pasientreiser ANS o Å få bekreftelse på mottatt henvendelse o Å få så mye informasjon som mulig om videre fremdrift o Mulighet for å sjekke status senere Ved anskaffelser og etablering av nye løsninger skal tilgjengelighet prioriteres. Dette gjelder ved anskaffelse av databasesystemer, applikasjonsplattformer, mellomvare og integrasjonsløsninger. Tilfredsstille brukeres behov og krav til døgnåpen forvaltning. Side 22 av 48

23 Brukere setter tilgjengelighet høyest blant ikke funksjonelle krav, dvs. at systemene er robuste og stabile. Det må planlegges hvordan brukeren skal få svar dersom tjenesten omfatter manuell saksbehandling. Det må komme klart frem av applikasjonen hva forventet responstid er for tjenester av denne typen TI3 - Universell utforming IT-tjenester som gjøres tilgjengelig for innbyggerne skal være tilgjengelig uansett funksjonsevne. Ved etablering av en tjeneste skal prinsippene for universell utforming benyttes. Dette sikrer tilgjengelighet for tjenester for alle uavhengig av funksjonsevne. Tjenestene skal være enkle å lokalisere når behovet er der. De skal være tilgjengelig i offentlige portaler eller der det anses naturlig for bruker å søke etter dem. Tjenestene bør designes for å være språkuavhengige (internasjonaliserbar i henhold til I18N), og eventuelt kunne språktilpasses den målgruppe tjenesten tilbys. Tilfredsstille krav om å ikke diskriminere basert på nedsatt funksjonsevne. Det er viktig at det tas høyde for dette prinsippet i forbindelse valg av rammeverk og kanaler slik at det ikke følger med noen tekniske begrensninger i forhold til å kunne tilfredsstille krav om universell utforming. Funksjonelle krav må gjennomgående ta høyde for universell utforming. Ikke minst må det tas hensyn til at applikasjonen må testes med tanke på at den ikke diskriminerer. Brukertest av selvbetjeningsløsninger bør omfatte representanter for alle aktuelle målgrupper TI4 - Kanaler og uavhengighet Tjenester rettet mot selvbetjeningsløsninger skal designes slik at de enkelt kan gjøres tilgjengelig i alle nødvendige kanaler. Forvaltningstjenester skal ha en forutsigbar utforming og tilbys på en slik måte at man ikke trenger å være avhengig av en bestemt kanal eller en type teknologi for å kunne nyttiggjøre seg dem elektronisk. Det må dog utføres en analyse av hva som er realistisk for nye kanaler så vel som en kost/nytte analyse ved vurdering av nye kanaler. Selvbetjeningsløsninger skal tilfredsstille kravene til tilgjengelighet. Side 23 av 48

24 Tilfredsstille brukeres og myndighetenes krav til tilgjengelighet til offentlig informasjon og selvbetjening. Mulighet til å tilgjengeliggjøre en tjeneste i flere ulike kanaler forutsetter løs kobling mellom presentasjon og tjenestelag slik at flere ulike klienter kan utvikles mot den samme tjenesten TI5 Robusthet og stabilitet Robusthet skal bygges inn i IT-løsningene ved design av løsningsarkitektur, informasjonsarkitektur og infrastruktur. Alle IT-løsninger må bygges slik at ikke bortfall av kritiske komponenter gjør at hele løsningen er utilgjengelig. Løsninger må designes slik at de er fleksible i forhold til kontrollerte og ukontrollerte avbrudd. o o Data må aldri gå tapt uten at bruker får tilbakemelding i forbindelse med lagring. Det er viktig at en melding er persistert slik at den ikke er tapt dersom mellomvare eller databasen blir utilgjengelig. Kritisk funksjonalitet realiseres gjennom løse (asynkrone) koblinger, replikering av data og redundans i infrastruktur. Fysisk implementering må utføres på en slik måte at eksisterende og potensielle behov for døgnkontinuerlig tilgjengelighet ivaretas. Stabilitet er det viktigste målet for Pasientreiser ANS systemer. Det må tilstrebes så lav nedetid som mulig. For eksempel ved bruk av mekanismer som hot deploy som gjør det mulig å produksjonssette endringer uten nedetid i systemet. Det må tas høyde for i testplanlegging at arkitekturen testes for robusthet der dette er relevant. Full redundans er kostbart. Det er derfor nødvendig å foreta en kost/nytte vurderinger i forhold til hvilke deler av systemet som er kritiske både i forhold til direkte kostnader til infrastrukturkomponenter og redundans TI6 Overvåkning Løsninger og komponenter må ha innebygd funksjonalitet for felles, sentralisert overvåking og logging gjennom hele prosesseringskjeden. Det skal være mulig å spore kilden til en feilsituasjon eller hendelse fra et sentralt overvåkningspunkt. Alle komponenter skal bygges opp slik at de kan logge feilmeldinger og hendelser på en enhetlig måte. Overvåkning må være en integrert del av driftsleverandørens løsninger. Side 24 av 48

25 Overvåkning må defineres på ulike nivå og hvem som har eierskap til aksjoner som skal tas knyttet til hendelser. Proaktiv overvåkning er mer kostnadseffektivt enn feilhåndtering i ettertid TI7 - Sentral monitorering Alle virksomhetskritiske løsninger skal overvåkes automatisk ved hjelp av overvåkningsverktøy med tanke på proaktiv oppfølging. Det må defineres hvilke nivå som skal monitoreres og avklares hvem som har ansvaret for hvert nivå. Ulike nivå av drift og overvåking er: o HW infrastruktur som servere, disker, DNS, FW, rutere o Server CPU, heap og disk o Applikasjonsovervåkning o Database, MQ-køer o Prosesser og tjenester Det skal knyttes driftsansvar og SLAer i en tjenesteavtale til det som overvåkes, for eksempel oppetid, administrasjon, kjørerutiner, driftssetting, osv. Det må være lett å hente ut status og statistikker for det som overvåkes. Overvåkingsresultatene er grunnlag for planlegging, styring, forbedringer og dimensjonering av driftsmiljøet, applikasjoner og tjenester. Det er nødvendig å følge med på hvordan applikasjoner, prosesser og tjenester fungerer over tid etter å ha blitt implementert, for å kunne igangsette forbedringer og kontinuerlig forbedre. Effektiv feilretting forutsetter oversikt over alle involverte komponenter fra presentasjon, mellomvare, integrasjonstjenester til backend systemer og database. Driftsavtaler skal detaljere og gi oversikt over hva som overvåkes og hvem som har ansvaret TI8 - Strategi for oppgradering av program- og maskinvare Det må etableres et forvaltningsregime omkring program- og maskinvare. Det skal finnes en plan for oppgraderinger. Sikre at en kjører på relevant og støttet (supportert) infrastruktur. Kunne optimalisere og planlegge utskiftinger over tid. Unngå uforutsette kostnader for utskiftinger. Side 25 av 48

26 Det må være dokumentert hvilken SW og HW som til enhver tid kjører. Side 26 av 48

27 6. Sikkerhet IKT Sikkerhet betyr beskyttelse av tjenesten og dens informasjon basert på en vurdering av alle aspekter av sikring og skjerming av informasjon som en gitt informasjonsmengde krever. Prinsipper: SI1 - Definert sikkerhetsnivå SI2 - IT-sikkerhetspolitikk SI3 - Sporbarhet SI4 - Integritet og konfidensialitet SI5 - Autentisering SI6 - Lagring av sensitive data SI7 - Anonymisering av sensitive data 6.1. SI1 Definert sikkerhetsnivå Enhver tjeneste eller løsning som etableres skal defineres til et gitt sikkerhetsnivå basert på en risikoanalyse (klassifisering), og være konstruert på en slik måte at sikkerhetsnivået kan endres. Sikkerhetsprinsippet kan begrense andre prinsipper. I tilfeller hvor det skjer er det sikkerhetsprinsippet som skal settes først, da dette er avgjørende i forhold til tillit. Det forutsetter at det er utarbeidet en klassifisering og at denne klart viser hvor et eller flere andre prinsipp blir begrenset. Sørge for et riktig/tilstrekkelig og fornuftig sikkerhetsnivå tilpasset et godt vurdert trusselbilde og konsekvensanalyse. Gjøre det enkelt å konfigurere (endre) sikkerhetsinnstillinger. Pasientreiser behandler transaksjoner for totalt store beløp og sensitive pasient og personopplysninger. Unngå svindel og tap av tillit. Sette fokus på sikkerhet ved å gi dette prioritet framfor andre prinsipper dersom det er konflikt. Typiske konfliktområder kan være åpenhet og tilgjengelighet. Etablere god bevissthet rundt sikkerhet SI2 IT-sikkerhetspolitikk Gjeldende IT-sikkerhetspolitikk skal etterfølges. Den skal være tilgjengelig for alle som utfører arbeid for organisasjonen ved bruk av IT-ressurser. Gjeldende IT-sikkerhetspolicy skal følges. I denne sammenheng er Normen viktig å hensynta for systemene innen pasientreiseområdet. Normen skal bidra til å etablere mekanismer hvor virksomhetene kan ha gjensidig tillit til at øvrige virksomheters behandling av helse- og personopplysninger gjennomføres på et forsvarlig sikkerhetsnivå. Normen stiller krav som detaljerer og supplerer Side 27 av 48

28 gjeldende regelverk. Normen er imidlertid ikke heldekkende. Helseregisterloven, personopplysningsloven og øvrig regelverk stiller enkelte krav til behandling av helse- og personopplysninger utover det som er tema for Normen. Mer informasjon om Normen finnes på Sikre at sikkerhetsprinsipper blir gjort kjent og etterlevd SI3 - Sporbarhet Alle aktiviteter i IT-løsningene som genererer, endrer eller sletter informasjon, skal kunne spores til hvilken person som utførte handlingen. IT-løsningene skal ha mulighet for funksjonalitet som gir sikkerhet for at de som har sendt meldinger gjennom noen av løsningene ikke kan benekte eller avvise at det er de som har foretatt handlingen. Sporbarhetsinformasjonen må enkelt kunne slettes etter en konfigurerbar tidsperiode, eksempelvis etter 3 måneder. Det må bestemmes i forkant av utviklingsprosjekter hvilke retningslinjer som gjelder for hvilke type handlinger som skal være sporbare, hvor mye som logges, hvor ofte sporbarhetslogg skal aksesseres, hvordan informasjonen skal gjøres tilgjengelig og for hvem denne informasjonen skal være tilgjengelig. Det er en fordel at all type sporbarhetslogging gjøres på en standardisert måte på tvers av løsninger på lik linje med annen logging. Dvs. sporbarhetsinformasjon skal lagres på en standardisert form og være søkbar (minimum på bruker og tidsperiode), og kan med fordel lagres utenfor databasen for å gjøre sporbarhetsinformasjon lettere tilgjengelig når denne går på tvers av applikasjoner og tjenester. Sikre tillit til saksbehandling og beslutninger ved at det kan etterprøves at opplysninger blir håndtert riktig mht. konfidensialitet, habilitet og autorisasjon. Sporbarhetsinformasjonen kan brukes til å identifisere og korrigere systematiske feil. Forenkle og sikre håndteringen av og søk i sporingslogger. Brukerdatabase og autentiseringsløsning med personlig pålogging nødvendig for sporing SI4 Integritet og konfidensialitet IT-løsninger skal oppfylle krav til integritet og konfidensialitet. Det skal sikres at informasjon og informasjonsbehandling er fullstendig, nøyaktig og gyldig. Informasjon skal kun være tilgjengelig for den som er autorisert for den og den må beskyttes slik at den ikke kommer uvedkommende i hende. Side 28 av 48

29 Sikre at alle relevante opplysninger og hensyn aktivt tas stilling til. Begrense tilgangen til saksopplysninger til det som er relevant og nødvendig. Det kreves god kjennskap til gjeldende lover og regler og at det etableres retningslinjer i forhold til dette, for eksempel personopplysningsloven SI5 Autentisering og autorisasjon Alle IT løsninger skal benytte en sentral tjeneste for å gi bruker tilgang til ressurser og informasjon. Alle interne applikasjoner skal forholde seg til en sentral brukertjeneste der alt av informasjon om brukeren og tilknyttede roller er samlet. Det bør utarbeides generelle retningslinjer i forhold til autentisering og standardisering i forhold til hvordan tilgangskontroll skal implementeres i forkant av / i forbindelse med etablering av et helhetlig arkitekturmålbilde. Tjenester og applikasjoner skal designes med tanke på SSO (single-sign-on). Det skal tas høyde for at en bruker kan opptre med ulike roller i en applikasjon. Tilganger kan benyttes på flere nivåer; på tjenestenivå, på data/informasjonsnivå eller på presentasjonsnivå (GUI). Det bør tilstrebes at hver ansatt kun er registrert med en bruker i brukertjenesten og at bruker kan ha flere roller, fremfor å opprette flere brukere for ulike behov. Enklere administrasjon av tilgangskontroll på tvers av applikasjoner og tjenester. Samle mest mulig informasjon om brukeres tilganger på ett sted. Gir bedre oversikt og det er enklere å legge inn nye brukere, slette brukere og tilganger, samt for eksempel å åpne og for og begrense tilganger for brukere periodevis. Forenkle administrasjon av tilgangsrettigheter. Bidrar til reduserte kostnader for utviklingsprosjekter. Brukere skal ha tilgang til informasjon og funksjonalitet som er relevant for arbeidsoppgavene som skal utføres. Sikre at sensitiv informasjon kun kan ses og behandles av personer som har behov for det. Krav til en brukertjeneste må bestemmes og grensesnittet mot en slik tjeneste må være på plass i forkant av eller som del av etablering av en felles referansearkitektur. Dersom en bruker er tilknyttet mer enn en rolle som er relevant innenfor en applikasjon så må det tas stilling til om brukeren: o skal ha tilgang til all funksjonalitet som summen av alle rollene tilsier, eller o skal kunne velge hvilken rolle han/hun skal opptre som i applikasjonen SI6 Lagring av sensitive data Det skal defineres hva som er sensitive data og hvordan de skal behandles. Side 29 av 48

Arkitekturprinsipper i spesialisthelsetjenesten. Versjon 1.0 Sist oppdatert: 27. nov 2014

Arkitekturprinsipper i spesialisthelsetjenesten. Versjon 1.0 Sist oppdatert: 27. nov 2014 Arkitekturprinsipper i spesialisthelsetjenesten Versjon 1.0 Sist oppdatert: 27. nov 2014 Nasjonal IKTs Fagforum Arkitektur forvalter arkitekturen for spesialisthelsetjenesten Som en del av dette er det

Detaljer

Overordnede ITarkitekturprinsipper. sektor. Versjon 2.1 Direktoratet for forvaltning og IKT 17. september 2012

Overordnede ITarkitekturprinsipper. sektor. Versjon 2.1 Direktoratet for forvaltning og IKT 17. september 2012 Overordnede ITarkitekturprinsipper for offentlig sektor Versjon 2.1 Direktoratet for forvaltning og IKT 17. september 2012 Innhold Om prinsippene... 3 Tjenesteorientering... 5 Interoperabilitet... 6 Tilgjengelighet...

Detaljer

Arkitekturprinsipper for Trondheim kommune. Versjon 1.0

Arkitekturprinsipper for Trondheim kommune. Versjon 1.0 Arkitekturprinsipper for Versjon 1.0 Innhold Dokumentinformasjon... 3 Dokumentversjonshistorikk... 3 Kontaktperson vedr. bruk av prinsippene... 3 Innledning... 4 Formål og overordnet beskrivelse... 4 Nasjonale

Detaljer

Agenda. Mulige gevinster ved å samarbeide om løsninger. Tjenesteorientert arkitektur for UH sektoren. Kontekst for arkitekturarbeid

Agenda. Mulige gevinster ved å samarbeide om løsninger. Tjenesteorientert arkitektur for UH sektoren. Kontekst for arkitekturarbeid Arkitekturarbeide ved NTNU Carl-Fredrik Sørensen og Ole Langfeldt Arkitekter NTNU IT Agenda Kontekst for arkitekturarbeid IKT i UH-sektoren DIFI Arkitekturprinsipper Arkitektur i dag Trender i tiden Arkitektur

Detaljer

Innledning 1 Formål 2 Krav til prinsippenes egenskaper 2 Prinsippene 3

Innledning 1 Formål 2 Krav til prinsippenes egenskaper 2 Prinsippene 3 er for virksomhetsarkitektur fra Nasjonal IKT. (Erstatter versjon 1.0 fra 2010.) Innhold Innledning 1 Formål 2 Krav til prinsippenes egenskaper 2 ene 3 Helhetlig tilnærming 3 Prosessorientering 4 Tjenesteorientering

Detaljer

Digitaliseringsstrategi 2014-2029

Digitaliseringsstrategi 2014-2029 Digitaliseringsstrategi 2014-2029 Stavanger kommune Stavanger kommune skal gi innbyggerne og næringsliv et reelt digitalt førstevalg. Den digitale dialogen skal legge vekt på åpenhet og tilgjengelighet.

Detaljer

Sak 3/18 Sluttbehandling av Etablere enhetlig arkitekturrammeverk (ST 2.2) Skate-møtet 21.mars 2018

Sak 3/18 Sluttbehandling av Etablere enhetlig arkitekturrammeverk (ST 2.2) Skate-møtet 21.mars 2018 Sak 3/18 Sluttbehandling av Etablere enhetlig arkitekturrammeverk (ST 2.2) Skate-møtet 21.mars 2018 Mål og leveranser Økt evne til samhandling på tvers av offentlig sektor Mer deling av data Leveranser:

Detaljer

Tjenesteorientert arkitektur hvordan statistikkproduksjonen støttes og forbedres av en tilpasset IT arkitektur

Tjenesteorientert arkitektur hvordan statistikkproduksjonen støttes og forbedres av en tilpasset IT arkitektur 14. juni 2010 Tjenesteorientert arkitektur hvordan statistikkproduksjonen støttes og forbedres av en tilpasset IT arkitektur Lill Kristoffersen lill.kristoffersen@ssb.no Statistisk sentralbyrå IKT Abstract:

Detaljer

Felles arkitekturprinsipper for helse- og velferdsområdet

Felles arkitekturprinsipper for helse- og velferdsområdet Felles arkitekturprinsipper for helse- og velferdsområdet SSP Brukerforum Oslo 24.03.2011 www.kith.no Foredragsholder Hans-Olav Warholm Seniorrådgiver / fagansvarlig arkitektur og sikkerhet, KITH Hvorfor

Detaljer

INTERN. DSBs arkitekturprinsipper

INTERN. DSBs arkitekturprinsipper INTERN DSBs arkitekturprinsipper Direktoratet for samfunnssikkerhet og beredskap Side 2 av 15 Innholdsfortegnelse Arktitekturprinsipper formål og bakgrunn... 4 Tjenesteorientering... 5 Interoperabilitet...

Detaljer

Hva karakteriserer god arkitekturpraksis og hvorfor ble valgt arkitekturmetode benyttet?

Hva karakteriserer god arkitekturpraksis og hvorfor ble valgt arkitekturmetode benyttet? Hva karakteriserer god arkitekturpraksis og hvorfor ble valgt arkitekturmetode benyttet? HelsIT 2011 Roar Engen Leder for arkitekturseksjonen,teknologi og ehelse, Helse Sør-Øst RHF Medforfatter: Jarle

Detaljer

Hva kan Altinn gjøre for deg? NOKIOS, Trondheim 21.september 2011 Cat Holten Brønnøysundregistrene

Hva kan Altinn gjøre for deg? NOKIOS, Trondheim 21.september 2011 Cat Holten Brønnøysundregistrene Hva kan Altinn gjøre for deg? NOKIOS, Trondheim 21.september 2011 Cat Holten Brønnøysundregistrene Agenda Hva kan du bruke Altinn til? Viktig funksjonalitet Ikke funksjonelle fordeler Hva må du gjøre?

Detaljer

Altinn Utviklingsplan 2017

Altinn Utviklingsplan 2017 Altinn Utviklingsplan 2017 Endringer i denne versjon 20.01.2017. Kontaktperson: Andreas Rafaelsen Essensen («Hva er Altinn pr 2017?») Altinn er felleskomponent for tjenesteutvikling, autorisasjon og integrasjonstjenester.

Detaljer

Digitaliseringsstrategi

Digitaliseringsstrategi Digitaliseringsstrategi 2014-2029 Stavanger kommune skal gi innbyggerne og næringsliv et reelt digitalt førstevalg. Den digitale dialogen skal legge vekt på åpenhet og tilgjengelighet. Digitale verktøy

Detaljer

Saksframlegg. Styret Helseforetakenes senter for pasientreiser ANS 28/01/16. SAK NR 08-2016 Styringsindikatorer 2016

Saksframlegg. Styret Helseforetakenes senter for pasientreiser ANS 28/01/16. SAK NR 08-2016 Styringsindikatorer 2016 Saksframlegg Referanse Saksgang: Styre Møtedato Styret Helseforetakenes senter for pasientreiser ANS 28/01/16 SAK NR 08-2016 Styringsindikatorer 2016 Forslag til vedtak: Styret tar forslagene til styringsindikator

Detaljer

Digitaliseringsstrategi. - trygghet og tillit til teknologi

Digitaliseringsstrategi. - trygghet og tillit til teknologi - trygghet og tillit til teknologi Utkast til behandling i kommunestyret 18. oktober 2018 BAKGRUNN OG MÅL Digitaliseringsstrategien beskriver sentrale innsatsområder for å møte innbyggerne der de er, yte

Detaljer

Strategi for nasjonale felleskomponenter og -løsninger i offentlig sektor. Strategiperiode

Strategi for nasjonale felleskomponenter og -løsninger i offentlig sektor. Strategiperiode Dokumentasjon fra Skate Veikartarbeidet for nasjonale felleskomponenter og -løsninger i offentlig sektor periode 2016-2018 Versjon 1.0 17.11.15 for nasjonale felleskomponenter og løsninger i offentlig

Detaljer

Frank Sandersen, EVRY 3. April 2014. Avansert integrasjon Saksbehandling med ephorte som arkiv

Frank Sandersen, EVRY 3. April 2014. Avansert integrasjon Saksbehandling med ephorte som arkiv Frank Sandersen, EVRY 3. April 2014 Avansert integrasjon Saksbehandling med ephorte som arkiv Meg Småbarnspappa EVRY Porsgrunn Automasjonsingeniør Systemutvikler Integrajonsarkitekt Arkivfaglig 2 3 Søker

Detaljer

IKT. for helsetjenesten. 5 løsningsprinsipper for bedre samhandling

IKT. for helsetjenesten. 5 løsningsprinsipper for bedre samhandling IKT for helsetjenesten 5 løsningsprinsipper for bedre samhandling 1 Dette er en oppsummering av tiltak 12 i handlingsplan for Nasjonal IKT, «Tjenesteorientert arkitektur for spesialisthelsetjenesten».

Detaljer

Veikart Standardiseringsrådet

Veikart Standardiseringsrådet Veikart Standardiseringsrådet 17.03.2016 Kristian Bergem Direktoratet for forvaltning og IKT Avdeling for digital forvaltning Seksjon for nasjonal arkitektur Mål (endepunkt) Følgende mål er foreslått for

Detaljer

Digitaliseringsstrategi

Digitaliseringsstrategi Digitaliseringsstrategi 2014 2029 Innsatsområder Ansvar og roller Mål Brukerbehov Utfordringer Verdigrunnlag Digitaliseringsstrategien Stavanger kommune skal gi innbyggerne og næringsliv et reelt digitalt

Detaljer

HVEM ER JEG OG HVOR «BOR» JEG?

HVEM ER JEG OG HVOR «BOR» JEG? DISCLAIMER HVEM ER JEG OG HVOR «BOR» JEG? INFORMASJONSSIKKERHET Konfidensialitet Sikre at informasjon bare er tilgjengelig for de som skal ha tilgang Integritet Sikre informasjon mot utilsiktet eller

Detaljer

Saksframlegg Referanse

Saksframlegg Referanse Saksframlegg Referanse Saksgang: Styre Møtedato Styret Helseforetakenes senter for pasientreiser ANS 22/01/15 SAK NR 07-2015 Styringsindikatorer 2015 Forslag til vedtak: Styret tar forslagene til styringsindikator

Detaljer

ARK 2014 Arkitekturfaget - observasjon fra en tjenesteleverandør

ARK 2014 Arkitekturfaget - observasjon fra en tjenesteleverandør ARK 2014 Arkitekturfaget - observasjon fra en tjenesteleverandør www.steria.com Stein Aarum Leder for arkitekturfagområdet Steria www.steria.com Innhold Hva vi mener med arkitektur Vår viktigste rolle

Detaljer

Veikart for nasjonale felleskomponenter

Veikart for nasjonale felleskomponenter Sesjon 3A Veikart for nasjonale felleskomponenter Nokios 2014 30.10.14 vidar.holmane@difi.no Introduksjonen Felleskomponenter som tema 2006 2007 2008 2009 2010 2011 Hva det handler om Noen digitale tjenester

Detaljer

Tilbakemeldinger fra Skattedirektoratet v/sits på rapporten Metoder og standarder for tjenesteorientert arkitektur i offentlig sektor.

Tilbakemeldinger fra Skattedirektoratet v/sits på rapporten Metoder og standarder for tjenesteorientert arkitektur i offentlig sektor. Tilbakemeldinger fra Skattedirektoratet v/sits på rapporten Metoder og standarder for tjenesteorientert arkitektur i offentlig sektor. Generelle tilbakemeldinger som er diskutert i dokumentgjennomgangsmøte:

Detaljer

Høringssvar rapporten Felles IKT-arkitektur i offentlig sektor

Høringssvar rapporten Felles IKT-arkitektur i offentlig sektor Fornyings- og administrasjonsdepartementet postmottak@fad.dep.no Vår dato Vår referanse 18.09.08 2008/305 Deres dato Deres referanse 25.06.2008 200701034 Saksbehandler: MNL Høringssvar rapporten Felles

Detaljer

e-dialoger Framtidens eforvaltning eller.?

e-dialoger Framtidens eforvaltning eller.? 1 e-dialoger Framtidens eforvaltning eller.? NOKIOS 21. September 2011 Rune Gløersen Fagdirektør, IT og statistiske metoder Statistisk sentralbyrå 1 Utvikling i bruken av ALTINN SAM- HANDLE SAM- ORDNE

Detaljer

Styret Helseforetakenes senter for pasientreiser ANS 28./02/11. 1. Styret tar forslagene til styringsindikatorer og mål for 2011 til etterretning.

Styret Helseforetakenes senter for pasientreiser ANS 28./02/11. 1. Styret tar forslagene til styringsindikatorer og mål for 2011 til etterretning. Saksframlegg Referanse Saksgang: Styre Møtedato Styret Helseforetakenes senter for pasientreiser ANS 28./02/11 SAK NR 013-2011 Styringsindikatorer 2011 Forslag til vedtak: 1. Styret tar forslagene til

Detaljer

Med standarder som virkemiddel

Med standarder som virkemiddel Med standarder som virkemiddel Tristan Rolstad, leder Virksomhetsarkitektur Øystein Aanrud, virksomhetsarkitekt ekommune 2013 17.09.2013 Agenda Standardisering Interoperabilitet Standardisering og arkitektur

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Forord Kravspesifikasjonen skal gi en oversikt og forståelse over det planlagte systemets funksjonalitet. Dokumentet skal gi både utviklere og oppdragsgivere innblikk i hvordan og hva systemet skal levere.

Detaljer

Hvorfor bør det etableres en felles systemarkitektur for helseforetakene? Helse IT 2007 Per Olav Skjesol Avdelingsleder Anvendelse Hemit

Hvorfor bør det etableres en felles systemarkitektur for helseforetakene? Helse IT 2007 Per Olav Skjesol Avdelingsleder Anvendelse Hemit Hvorfor bør det etableres en felles systemarkitektur for helseforetakene? Helse IT 2007 Per Olav Skjesol Avdelingsleder Anvendelse Hemit Prosjektansvarlig Nasjonal IKT for arkitektur Innhold Hvorfor jobbe

Detaljer

Anbefalinger til Standardiseringsrådet vedrørende utredning av standarder for informasjonssikkerhet

Anbefalinger til Standardiseringsrådet vedrørende utredning av standarder for informasjonssikkerhet Anbefalinger til Standardiseringsrådet vedrørende utredning av standarder for informasjonssikkerhet Bakgrunn Utredningen av standarder for informasjonssikkerhet har kommet i gang med utgangspunkt i forprosjektet

Detaljer

3-1 Digitaliseringsstrategi

3-1 Digitaliseringsstrategi 3-1 Digitaliseringsstrategi 2017-2020 Digitaliseringsstrategi 2017-2020, forslag fra Regional rådmannsgruppe 3-1 Digitaliseringsstrategi Side 2 Innledning Digitaliseringen av samfunnet gir muligheter for

Detaljer

Styrende prinsipper for ny bransjeløsning. DIFA Forprosjekt

Styrende prinsipper for ny bransjeløsning. DIFA Forprosjekt Styrende prinsipper for ny bransjeløsning DIFA Forprosjekt Leveransens innhold DIFA forprosjekt har formulert styrende prinsipper for den nye bransjeløsningen. De styrende prinsippene gir retning og setter

Detaljer

STANDARDISERINGSRÅDETS ARBEID

STANDARDISERINGSRÅDETS ARBEID S ARBEID OLAF ØSTENSEN STATENS KARTVERK ANDRE BAKGRUNNSDOKUMENTER Arkitektur for elektronisk samhandling i offentlig sektor Bruk av åpne IT-standarder og åpen kildekode i offentlig sektor FAD OPPRETTER

Detaljer

STRATEGISK PLAN

STRATEGISK PLAN STRATEGISK PLAN 2010 2015 IT-AVDELINGEN UNIVERSITETET I BERGEN Brukerorientering Kvalitet Samarbeid Etikk SIDE 1 v. 1.00, 24. juni 2010 VISJON IT-avdelingen ved UiB skal produsere og levere IKT-tjenester

Detaljer

Samhandlingsplattform

Samhandlingsplattform Fra Samhandlingsarkitektur til Samhandlingsplattform HelsIT 2011 Radisson Blu Royal Garden Hotel, Trondheim Forfattere: Hans-Olav Warholm og Bjarte Aksnes www.kith.no Helt kort om oss Hans-Olav Warholm:

Detaljer

Samarbeid om IKT- løsninger og elektronisk samhandling

Samarbeid om IKT- løsninger og elektronisk samhandling Tjenesteavtale 9 Samarbeid om IKT- løsninger og elektronisk samhandling Samarbeid om IKT-løsninger og bruk av felles plattform lokalt er av stor betydning for å få til god samhandling. Enkel, rask og pålitelig

Detaljer

Digitaliseringsstrategi for Buskerud fylkeskommune. Revidert

Digitaliseringsstrategi for Buskerud fylkeskommune. Revidert Digitaliseringsstrategi for Buskerud fylkeskommune Revidert 2018-2020 Buskerud fylkeskommune Stab og kvalitetsavdelingen oktober 2017 Innhold 1. INNLEDNING... 3 2. GJENNOMFØRING... 4 3. SATSINGSOMRÅDER...

Detaljer

Request for information (RFI) Integrasjonsplattform

Request for information (RFI) Integrasjonsplattform Request for information (RFI) Integrasjonsplattform Trondheim kommune Trondheim kommune har initiert et prosjekt for å etablere en ny integrasjonsplattform TIP (Trondheim kommune Integrasjons Plattform).

Detaljer

Referansearkitektur sikkerhet

Referansearkitektur sikkerhet NAV IKT Styring/Arkitektur Referansearkitektur sikkerhet Senior sikkerhetsarkitekt Robert Knudsen Webinar Den Norske Dataforening 22. Mai 2013 Agenda Har vi felles forståelse og oversikt på sikkerhetsområdet?

Detaljer

Samarbeid om utvikling Integrasjonsarkitektur

Samarbeid om utvikling Integrasjonsarkitektur Kunnskap for en bedre verden IT for et bedre universitet Samarbeid om utvikling Integrasjonsarkitektur SUHS-konferansen 2014 Carl-Fredrik Sørensen IDI, NTNU Agenda Integrasjonsarkitektur Tjenesteorientering

Detaljer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesten Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesting Formell testing med hensyn til brukerbehov, krav, og forretningsprosesser som utføres for å avklare om et system oppfyller

Detaljer

Utfordring, tiltak og status:

Utfordring, tiltak og status: Utfordring, tiltak og status: Organisasjon, bemanning og kompetanse Komplisert og tidkrevende for systemeierskap å få et helhetlig bilde av både utfordringer og ansvarsområde, spesielt i forhold til NISSY.

Detaljer

Notat. Innhold. Utvikling og innføring av Visma Flyt Skole (VFS) Til: Kopi: Fra: Dato: 7. desember 2015. Sak: Fylkeskommunene

Notat. Innhold. Utvikling og innføring av Visma Flyt Skole (VFS) Til: Kopi: Fra: Dato: 7. desember 2015. Sak: Fylkeskommunene Notat Prosjekt: Til: Kopi: Fra: Utvikling og innføring av Visma Flyt Skole (VFS) Fylkeskommunene Prosjektledere Visma Flyt Skole Vigo IKS v/brynjulf Bøen, daglig leder Dato: 7. desember 2015 Sak: Status

Detaljer

Saksframlegg Referanse

Saksframlegg Referanse Saksframlegg Referanse Saksgang: Styre Møtedato Styret Helseforetakenes senter for pasientreiser ANS 10/03/14 SAK NR 19-2014 Styringsindikatorer 2014 Forslag til vedtak: Styret tar forslagene til styringsindikator

Detaljer

TESS Hose Management konseptet

TESS Hose Management konseptet TESS Hose Management konseptet TESS Hose Management (THM) er et svært fleksibelt og avansert risikobasert vedlikeholdssystem for slanger. THM er et komplett konsept for vedlikehold av fleksible slanger

Detaljer

MindIT sin visjon er å være en anerkjent og innovativ leverandør av teknologi og tjenester i den globale opplæringsbransjen

MindIT sin visjon er å være en anerkjent og innovativ leverandør av teknologi og tjenester i den globale opplæringsbransjen If you think education is expensive... try ignorance! MindIT sin visjon er å være en anerkjent og innovativ leverandør av teknologi og tjenester i den globale opplæringsbransjen Styrende verdier i MindIT:

Detaljer

Mandat. Regionalt program for Velferdsteknologi

Mandat. Regionalt program for Velferdsteknologi Mandat Regionalt program for Velferdsteknologi 2015-2017 Innhold 1 Innledning/bakgrunn 3 2 Nåsituasjon 3 3 Mål og rammer 4 4 Omfang og avgrensning 4 5Organisering 5 6 Ressursbruk 6 7 Beslutningspunkter

Detaljer

Ledersamling Øvre Eiker kommune 20.januar 2015. KS KommIT. Oslo 28.05.15

Ledersamling Øvre Eiker kommune 20.januar 2015. KS KommIT. Oslo 28.05.15 Tenke digitalt Jobbe nasjonalt Gjennomføre lokalt KS KommIT Oslo 28.05.15 Hovedoppgaver KommIT Effektmål Samordning i kommunesektoren (428 kommuner, 19 fylkeskommuner, 500+ foretak) Samordning stat/kommune

Detaljer

Strategi for Pasientreiser HF

Strategi for Pasientreiser HF Strategi 2017 2019 for Pasientreiser HF 1 Innhold side 1 Pasientens helsetjeneste 3 2 Overordnede føringer 4 2. 1 Stortingsmeldinger 4 2.2 Eiernes strategier 4 2.3 Pasientreiser HF sitt samfunnsoppdrag

Detaljer

Tiltaksplan digitalisering 2019

Tiltaksplan digitalisering 2019 Tiltaksplan digitalisering 2019 Kommunene i Kongsbergregionen etablerte våren 2015 en felles strategi for sitt digitaliseringssamarbeid for perioden 2015 2018. SuksIT som er kommunenes felles digitaliseringsorgan

Detaljer

Sporingssystem for senger

Sporingssystem for senger Sporingssystem for senger Del 2 K Bilag 1, Vedlegg 1 Arkitekturprinsipper i Helse Vest Saksnr. 2013/30 Innhold 1 FORMÅL... 3 2 DEFINISJONER... 4 3 NASJONALE PRINSIPPER... 5 3.1 DIREKTORATET FOR FORVALTNING

Detaljer

Fra monolitt og enevelde til tjenesteorientering og virksomhetsprioritering

Fra monolitt og enevelde til tjenesteorientering og virksomhetsprioritering Fra monolitt og enevelde til tjenesteorientering og virksomhetsprioritering Ny systemløsning i Lånekassen med nye arkitekturprinsipper og forvaltningsrutiner Nokios 16.Oktober 2008 Helge Lysaker Funksjonell

Detaljer

Konsekvensutredning av ELMER som obligatorisk forvaltningsstandard for innbyggerskjemaer. Beslutningssak i det 25. standardiseringsrådsmøte

Konsekvensutredning av ELMER som obligatorisk forvaltningsstandard for innbyggerskjemaer. Beslutningssak i det 25. standardiseringsrådsmøte Konsekvensutredning av ELMER som obligatorisk forvaltningsstandard for innbyggerskjemaer Beslutningssak i det 25. standardiseringsrådsmøte 22.11.10 Konsekvensutredning I rådsmøtet i juni ble det vurdert

Detaljer

Målbildet for digitalisering arkitektur

Målbildet for digitalisering arkitektur Målbildet for digitalisering arkitektur KOMMUNESEKTORENS ORGANISASJON The Norwegian Association of Local and Regional Authorities Innholdsfortegnelse 1. Hva målbildet betyr for kommunene... 3 1.1 Digital

Detaljer

Vedlegg til kravspesifikasjon ebyggesaksbehandling Standardiserte saksbehandlingsprosesser

Vedlegg til kravspesifikasjon ebyggesaksbehandling Standardiserte saksbehandlingsprosesser Vedlegg til kravspesifikasjon ebyggesaksbehandling Standardiserte saksbehandlingsprosesser Desember 2014 Innholdsfortegnelse 1. Innledning... 3 2. Standardiserte saksbehandlingsprosesser... 3 3. Eksempel

Detaljer

Løsningsarkitektur i og rundt Altinn. 31. august 2009 Wilfred Østgulen

Løsningsarkitektur i og rundt Altinn. 31. august 2009 Wilfred Østgulen Løsningsarkitektur i og rundt Altinn 31. august 2009 Wilfred Østgulen 1 Formål Formålet med presentasjonen er å gi dere et innblikk i hvordan vi har tenkt og jobbet med arkitektur i den nye Altinn-løsningen

Detaljer

Digitaliseringsstrategi Birkenes kommune Vedtatt av RLG Digitaliseringsstrategi for Birkenes kommune 1

Digitaliseringsstrategi Birkenes kommune Vedtatt av RLG Digitaliseringsstrategi for Birkenes kommune 1 Digitaliseringsstrategi Birkenes kommune 2021 Vedtatt av RLG 15.05.17 Digitaliseringsstrategi for Birkenes kommune 1 Innholdsfortegnelse 1.0 Digitaliseringsstrategi for Birkenes kommune... 3 1.1 Visjon

Detaljer

Anskaffelsesstrategi for Stavanger kommune

Anskaffelsesstrategi for Stavanger kommune Referanse: 13/5309 Anskaffelsesstrategi for Stavanger kommune «VERDISKAPENDE, INNOVATIVE OG BÆREKRAFTIGE ANSKAFFELSER» Målgruppen for dette dokument er politikere, ledere og personer som jobber med anskaffelser

Detaljer

Samordning av IKT i spesialisthelsetjenesten Status ny felles IKT-strategi

Samordning av IKT i spesialisthelsetjenesten Status ny felles IKT-strategi Samordning av IKT i spesialisthelsetjenesten Status ny felles IKT-strategi v/administrerende direktør i Nasjonal IKT HF, Gisle Fauskanger IKT-forum 2015 for medisinsk nødmeldetjeneste GISLE FAUSKANGER

Detaljer

Integrasjonsarkitektur

Integrasjonsarkitektur Integrasjonsarkitektur Integrasjonsarkitektur har arbeidsgruppen definert til å være hvordan dataene kommer inn i et system fra et annet system, altså fra maskin til maskin Arbeidet med integrasjonsarkitektur

Detaljer

Anbefaling om bruk av HL7 FHIR for datadeling

Anbefaling om bruk av HL7 FHIR for datadeling Anbefaling om bruk av HL7 FHIR for datadeling Retningslinje utgitt 03/2019 1 Publikasjonens tittel: Utgitt: 03/2019 Dokumenttype Retningslinje Utgitt av: Direktoratet for e-helse Kontakt: postmottak@ehelse.no

Detaljer

RETNINGSLINJE FOR SAMARBEID MELLOM..KOMMUNE OG ST. OLAVS HOSPITAL OM IKT- LØSNINGER OG ELEKTRONISK SAMHANDLING

RETNINGSLINJE FOR SAMARBEID MELLOM..KOMMUNE OG ST. OLAVS HOSPITAL OM IKT- LØSNINGER OG ELEKTRONISK SAMHANDLING RETNINGSLINJE FOR SAMARBEID MELLOM..KOMMUNE OG ST. OLAVS HOSPITAL OM IKT- LØSNINGER OG ELEKTRONISK SAMHANDLING Hjemlet i lov om kommunale helse- og omsorgstjenester av 14.6.2011 3-5 tredje ledd, 6-2 siste

Detaljer

Helsetjenestene på nett med helsenorge.no. Innbyggers tilgang til enkle og sikre digitale helsetjenester

Helsetjenestene på nett med helsenorge.no. Innbyggers tilgang til enkle og sikre digitale helsetjenester Helsetjenestene på nett med helsenorge.no Innbyggers tilgang til enkle og sikre digitale helsetjenester Helsenorge.no skal være den foretrukne portalen innen helse for befolkningen De sentrale målene er

Detaljer

Prinsipper for virksomhetsstyring i Oslo kommune

Prinsipper for virksomhetsstyring i Oslo kommune Oslo kommune Byrådsavdeling for finans Prosjekt virksomhetsstyring Prinsippnotat Prinsipper for virksomhetsstyring i Oslo kommune 22.09.2011 2 1. Innledning Prinsipper for virksomhetsstyring som presenteres

Detaljer

Parallellsesjon 1 hvordan lages EHF og hvordan kan du bidra?

Parallellsesjon 1 hvordan lages EHF og hvordan kan du bidra? Parallellsesjon 1 hvordan lages EHF og hvordan kan du bidra? Difi ANS prosessrammeverk og hvordan det brukes i utvikling av EHF Petter Vinje 13:30-13:50 Hvem Systemleverandører Oppdragsgivere Leverandører

Detaljer

SAKSFRAMLEGG. Forum: Skate Møtedato: 11.02.2015

SAKSFRAMLEGG. Forum: Skate Møtedato: 11.02.2015 SAKSFRAMLEGG Forum: Skate Møtedato: 11.02.2015 Sak under løpende rapportering og oppfølging Sak 02-2014. Veikart for nasjonale felleskomponenter. I dette møtet: Beslutningssak. Historikk/bakgrunn Skate

Detaljer

Fagutvalg for administrasjon, ledelse og kontorstøtte. Møte Videomøte

Fagutvalg for administrasjon, ledelse og kontorstøtte. Møte Videomøte Fagutvalg for administrasjon, ledelse og kontorstøtte Møte 1-2019 Videomøte 07.01.2019 Agenda 1. Godkjenning av referat 2. Orientering og tilbakemelding om møte 18.12.18 3. Siste versjon av initiativ.

Detaljer

FAOS 5 år etter hvor står vi?

FAOS 5 år etter hvor står vi? FAOS 5 år etter hvor står vi? Terje Grimstad, Karde AS FAOS - Felles Arkitektur for Offentlig Sektor Samhandlingsarena 8 Semicolon og NorStella Hos KS, mandag 16.9.2013 Bakgrunn i mandatet 13. juli 2007

Detaljer

Digitaliseringsstrategi for Buskerud fylkeskommune 2015-2017 Buskerud fylkeskommune Vedtatt av administrasjonsutvalget 14.

Digitaliseringsstrategi for Buskerud fylkeskommune 2015-2017 Buskerud fylkeskommune Vedtatt av administrasjonsutvalget 14. Digitaliseringsstrategi for Buskerud fylkeskommune 2015-2017 Buskerud fylkeskommune Vedtatt av administrasjonsutvalget 14.april 2015 Innhold 1. INNLEDNING... 3 2. GJENNOMFØRING... 4 3. SATSINGSOMRÅDER...

Detaljer

Bakgrunn. Kurset krever ingen spesielle forkunnskaper om modellering.

Bakgrunn. Kurset krever ingen spesielle forkunnskaper om modellering. Bakgrunn Modellering har lenge vært et kjent begrep innen systemutvikling. På 80-tallet ble metoder som Yourdon/Demarco og Gane&Sarson brukt for å lage dataflyt-diagrammer. Etter hvert ble disse integrert

Detaljer

Altinn for fagsystemleverandører

Altinn for fagsystemleverandører Altinn for fagsystemleverandører Altinndagen 29. august 2012 Rolf Jacobsen 1. Altinn plattformen 2. Viktigheten av system til system forståelse 3. Fellesløsninger 4. Pådrivere i videreutviklingen av Altinn

Detaljer

25B. Bruk av informasjons- og kommunikasjonsteknologi (IKT)

25B. Bruk av informasjons- og kommunikasjonsteknologi (IKT) 25B. Bruk av informasjons- og kommunikasjonsteknologi (IKT) Opplysninger om fylkeskommunen Fylkenr Fylkeskommunens navn Navn skjemaansvarlig Tlf nr E-post skjemaansvarlig Strategi 1 Har fylkeskommunen

Detaljer

3-1 DIGITALISERINGSSTRATEGI

3-1 DIGITALISERINGSSTRATEGI 3-1 DIGITALISERINGSSTRATEGI 2017-2020 GAUSDAL KOMMUNE LILLEHAMMER KOMMUNE ØYER KOMMUNE INNLEDNING Digitaliseringen av samfunnet gir muligheter for innovasjon, økt produktivitet og bedre kvalitet i både

Detaljer

KONTROLLSTRATEGI REISER UTEN REKVISISJON

KONTROLLSTRATEGI REISER UTEN REKVISISJON KONTROLLSTRATEGI REISER UTEN REKVISISJON Innhold 1. Formål...2 2. Krav og føringer til styring og kontroll...2 2.1. Pasientreiseforskriften 26 dokumentasjon og kontroll... 2 2.2. Forarbeidene; Høringsnotat

Detaljer

Oppsummering. Thomas Lohne Aanes Thomas Amble

Oppsummering. Thomas Lohne Aanes Thomas Amble Oppsummering Thomas Lohne Aanes Thomas Amble 14.11.04 Kapittel 2: Data Modell Mål: Data som skal brukes av applikasjonen blir spesifisert på en formell og likevel intuitiv måte. Resultat: Vi får et konseptuelt

Detaljer

Vedlegg 3 Tekniske krav til IKT-løsninger i Kongsbergregionen

Vedlegg 3 Tekniske krav til IKT-løsninger i Kongsbergregionen Vedlegg 3 Tekniske krav til IKT-løsninger i Kongsbergregionen av 25.01.14 Tilbyder bes fylle inn nødvendig informasjon i felter som inngår i dokumentets følgende deler/kapitler: 1. Arkitekturprinsipper

Detaljer

Svar på høringsutkast: Felles IKT-arkitektur i offentlig sektor (FAOS-rapporten)

Svar på høringsutkast: Felles IKT-arkitektur i offentlig sektor (FAOS-rapporten) Capgemini Norge AS Svar på høringsutkast: Felles IKT-arkitektur i offentlig sektor (FAOS-rapporten) Oslo, 25.09.2008 INNHOLDSFORTEGNELSE 1. CAPGEMINIS ANBEFALING...3 2. SVAR OG KOMMENTARER PÅ KAPTITLENE...4

Detaljer

Felles veikart for nasjonale felleskomponenter i regi av Skate. Digitaliseringskonferansen 2015 vidar.holmane@difi.no

Felles veikart for nasjonale felleskomponenter i regi av Skate. Digitaliseringskonferansen 2015 vidar.holmane@difi.no Felles veikart for nasjonale felleskomponenter i regi av Skate Digitaliseringskonferansen 2015 vidar.holmane@difi.no Difi skal aktivt bidra til realisering av og til en samordnet utvikling og tilrettelegging

Detaljer

Altinn, nye muligheter for samhandling og samspill i offentlig sektor. Hallstein Husand Programleder Altinn II Programmet NOKIOS 2009

Altinn, nye muligheter for samhandling og samspill i offentlig sektor. Hallstein Husand Programleder Altinn II Programmet NOKIOS 2009 Altinn, nye muligheter for samhandling og samspill i offentlig sektor Hallstein Husand Programleder Altinn II Programmet NOKIOS 2009 1 ALTINN II Nye muligheter for samhandling og samspill i offentlig sektor

Detaljer

Metode for identifikasjon av dokumentasjon. 8 Norske Arkivmøte,

Metode for identifikasjon av dokumentasjon. 8 Norske Arkivmøte, Metode for identifikasjon av dokumentasjon 8 Norske Arkivmøte, 09.04.2019. Agenda Bakgrunn Resultat - metoden Tilbakemeldinger Veien videre Hvordan lykkes med dette i praksis? Bakgrunn Samfunn i endring

Detaljer

Roller og ansvar ved deling av opplysninger

Roller og ansvar ved deling av opplysninger Roller og ansvar ved deling av opplysninger erfaringer fra NAV og Skatteetaten SKATE 5.12.18 Et felles mål om å gjøre informasjon mest mulig produktivt for samfunnet Digitaliseringen skyter fart stor vekst

Detaljer

Fra EA til DEA. Fra EA til DEA virksomhetsarkitektur

Fra EA til DEA. Fra EA til DEA virksomhetsarkitektur Fra EA til DEA Kristin Selvaag, konserndirektør IKT i NTE 7. juni 2012 Fra EA til DEA virksomhetsarkitektur 1. Hva er egentlig virksomhetsarkitektur? Hva skal vi formidle egentlig? 2. Bakteppe: Litt om

Detaljer

Synkron overføring - Digitalt skapt materiale fra kommunene. Petter B. Høiaas Rådgiver, IKA Kongsberg

Synkron overføring - Digitalt skapt materiale fra kommunene. Petter B. Høiaas Rådgiver, IKA Kongsberg Synkron overføring - Digitalt skapt materiale fra kommunene Petter B. Høiaas Rådgiver, IKA Kongsberg Hva er synkron overføring? «forenkle og effektivisere prosessene rundt arkivdanning i kommunal sektor»

Detaljer

Helse- og omsorgsdepartementet St.meld. nr Samhandlingsreformen

Helse- og omsorgsdepartementet St.meld. nr Samhandlingsreformen Vedlegg 8A Hva er Felles grunnmur Formålet med Felles grunnmur for digitale tjenester er å legge til rette for enkel og sikker samhandling på tvers av virksomheter og forvaltningsnivå. Sammenfallende behov

Detaljer

Technical Integration Architecture Teknisk integrasjonsarkitektur

Technical Integration Architecture Teknisk integrasjonsarkitektur Kap. 6 Technical Integration Architecture Studentpresentasjon av Cato Haukeland Oversikt Introduksjon -spesifikasjon Krav Beskrivelse Servicenivå Sikkerhet Plan Best practices Introduksjon Masterdokument

Detaljer

Hvordan kan en gjenbrukbar NOARK kjerne bidra til samhandling mellom forvaltningsnivåene?

Hvordan kan en gjenbrukbar NOARK kjerne bidra til samhandling mellom forvaltningsnivåene? Hvordan kan en gjenbrukbar NOARK kjerne bidra til samhandling mellom forvaltningsnivåene? Thomas Sødring Høyskolen i Oslo thomas.sodring@jbi.hio.no +47 99 57 04 72 NOKIOS Workshop NOARK 5 26. Oktober 2010

Detaljer

Tiltaksplan for oppfølging av revisjonsrapport om systemforvaltning i Pasientreiser ANS 29.08.2011

Tiltaksplan for oppfølging av revisjonsrapport om systemforvaltning i Pasientreiser ANS 29.08.2011 Tiltaksplan for oppfølging av revisjonsrapport om systemforvaltning i Pasientreiser ANS 29.08.2011 6.2.11 Gjennomgå avtaleverket for å få på plass databehandleravtaler med driftsleverandørene 6.2.7 Pasientreiser

Detaljer

Del 1. Infrastruktur. Figur 1.

Del 1. Infrastruktur. Figur 1. SIDE 1 AV 7 I Digital agenda for Norge (Meld. St. 27(2015-2016)) omtales det at forvaltningen skal gjenbruke informasjon. Gjenbruk av informasjon i forvaltningen kan være effektivt ved at forvaltningen

Detaljer

Saksframlegg Referanse

Saksframlegg Referanse Saksframlegg Referanse Saksgang: Styre Møtedato Styret Helseforetakenes senter for pasientreiser ANS 10/06/2015 SAK NR 36-2015 Resultater fra gjennomgang av internkontroll 1. halvår 2015 og plan for gjennomgang

Detaljer

Profesjonalisering av prosjektledelse

Profesjonalisering av prosjektledelse Profesjonalisering av prosjektledelse Ingar Brauti, RC Fornebu Consulting AS Software2013, IT-ledelse i fremtiden Onsdag 13. februar 2013 ingar.brauti@fornebuconsulting.com I fremtiden vil IT funksjonen

Detaljer

Metode for identifikasjon av dokumentasjon. Presentasjon i Skate

Metode for identifikasjon av dokumentasjon. Presentasjon i Skate Metode for identifikasjon av dokumentasjon Presentasjon i Skate 13.03.2019. Agenda Bakgrunn Hva er gjort i prosjektet Resultat Tilbakemeldinger Gevinster Veien videre Bakgrunn Samfunn i endring Informasjon

Detaljer

Semantikkregisteret for elektronisk samhandling (SERES): I hvilken grad er personvernet en hindring?

Semantikkregisteret for elektronisk samhandling (SERES): I hvilken grad er personvernet en hindring? Semantikkregisteret for elektronisk samhandling (SERES): I hvilken grad er personvernet en hindring? NOKIOS onsdag 15. oktober 2008 Ståle Rundberg Direktør Erik Fossum Info-stab Plan- og og utviklingsavdelingen

Detaljer

Planning & Forecasting. retning / ansvar / verdi

Planning & Forecasting. retning / ansvar / verdi Planning & Forecasting retning / ansvar / verdi RAV Norge AS Hvem er vi? Spesialister på løsninger innen: Business intelligence and analytics Data visualization and discovery Performance management 44

Detaljer

Presentasjon sikkerhetsforum Avdelingsdirektør Arne Lunde Uh-avdelingen KD

Presentasjon sikkerhetsforum Avdelingsdirektør Arne Lunde Uh-avdelingen KD Presentasjon sikkerhetsforum 2014 Avdelingsdirektør Arne Lunde Uh-avdelingen KD Agenda Regjeringens politikk Regulatoriske krav til etablering av tiltak for å sikre informasjonssikkerheten Risk management

Detaljer

DIGITALISERING AV KOMMUNAL SEKTOR

DIGITALISERING AV KOMMUNAL SEKTOR Felles informasjonsforvaltning i offentlig sektor Hvorfor trenger vi det, hva bør det omfatte og hvordan? Rune Sandland, Sjefsarkitekt Del 1 DIGITALISERING AV KOMMUNAL SEKTOR Tenke digitalt utvikle nasjonalt

Detaljer

Felles studieadministrativt tjenestesenter FSAT. Strategi 2016-2019

Felles studieadministrativt tjenestesenter FSAT. Strategi 2016-2019 Felles studieadministrativt tjenestesenter FSAT Strategi 2016-2019 Strategiske mål 1. FSAT skal være en profesjonell leverandør av tjenester og systemer av høy kvalitet til norske utdanningsinstitusjoner.

Detaljer

Ved avdelingsdirektør Tone Bringedal

Ved avdelingsdirektør Tone Bringedal Hvilke behov ser forvaltningen for samarbeid med IKT-bransjen og forskningsmiljøene? Ved avdelingsdirektør Tone Bringedal (tbr@difi.no) Workshop i regi av Ressursnettverket for eforvaltning IKT-politikken

Detaljer