Helse Midt-Norge skal gjennomgå en omfattende transformasjon de kommende år. Helseplattformen vil utfordre dagens måte å produsere helsetjenester på. Virksomheten blir utfordret på å tilnærme seg en enda mer standardisert måte å jobbe på for å få de effekter som lå til grunn for beslutning om investering i prosjektet. Videre skal denne plattformen harmonere med nasjonalt standardisert løsning for AMK funksjonen og nytt sykehus skal bygges der det stilles store krav til effektiv produksjon av helsetjenester.

Arkitekturplanen vil være et rammeverk for en helhetlig tilnærming til utviklingsarbeid. Denne arkitekturplanen vil være en viktig del av en felles faglig plattform og gi føringer for alle som skal jobbe med små og store endringsreiser i HMN i tiden fremover.

1 Hva er virksomhetsarkitektur?

1.1 Introduksjon

Det er et stort behov i Helse Midt-Norge å etablere en felles tilnærming og metodikk for å kunne utvikle både organisasjon, prosesser og teknologi i en sammenheng for å nå strategiske mål. Strategiske mål er definert i Helse Midt-Norges overordnede strategi 2030. Hovedutfordringen er ikke å lage en arkitekturplan for hva slik tilnærming og arbeid skal omfatte. Utfordringen er å innføre en felles og ny måte å jobbe med dette på.

-I denne arkitekturplanen forsøker vi å synliggjøre hvordan virksomhetsarkitektur i praksis bidrar til å øke sjansene for å lykkes med de mange små og store endringsreisene i helsetjenesten.

Hensikten er å skape bedre forståelse hos beslutningstakere og helsepersonell på ulike nivå for hva det innebærer å jobbe på denne måten og gjøre det enklere å ta i bruk den «verktøykassen» som virksomhetsarkitektur bringer inn. Arkitekturplanen beskriver forslag til hvordan vi kan jobbe målrettet og systematisk med utvikling i Helse Midt-Norge.

Begrepet endringsreise brukes som en samlende betegnelse for innsatsområder for endring. Det omfatter hele prosessen fra nasjonale helsemyndigheter sine føringer til regional og lokal planlegging, gjennomføring og implementering av endringsprosesser og endringsaktiviteter i helsetjenesten.

1.2 Virksomhetsarkitektur som fagområde

Virksomhetsarkitektur er et begrep som for mange kan være fremmed. Begrepet arkitektur har imidlertid de fleste et forhold til. Den vanlige språklige forståelsen av begrepet arkitektur er knyttet til utforming av bygninger, og kjennetegnes av to ting:

det er en beskrivelse av et byggverk
det er prosess og virkemidler som fører frem til beskrivelsen av et byggverk

Virksomhetsarkitektur bør betraktes på samme måte, der faget er beskrivelse av virksomheter, i stedet for bygninger.

-Virksomhetsarkitektur beskriver hvordan virksomheten henger sammen, i dag og/eller i fremtid, når man ser på både organisasjon, prosesser og digital teknologi.

1.3 Hvilke gevinster kan virksomhetsarkitektur gi oss?

Helse- og omsorgstjenestene er en kompleks struktur med et stort antall samvirkende prosesser, mennesker og teknologi. Dette gjør det krevende å lykkes med mange små og store endringer som skal sikre et fremtidig bærekraftig helsevesen i Norge. En ting er å prioritere de riktige endringsreisene, en annen ting er å sikre god gjennomføring av disse slik at medisinske og driftsmessige gevinster faktisk blir realisert og nyttiggjort.

I dette kapitlet beskriver vi de viktigste gevinstene som bruk av virksomhetsarkitektur kan gi oss. Det er:

• Nødvendig oversikt og gjennomsiktighet

• Beskrivelser av sammenheng mellom organisasjon, prosesser og IKT

• Sikre samkjøring mellom nasjonalt, regionalt og lokalt nivå

• Verdi for alle som er involvert i eller berørt av endringer

I teksten nedenfor utdyper vi hva vi legger i disse punktene.

1.3.1 Nødvendig oversikt og gjennomsiktighet

Det er viktig å forstå og beskrive kompleksiteten innenfor helse- og omsorgstjenestene for å kunne vurdere behov for endring og virkning av endringer. Beskrivelser som bidrar til felles forståelse er en forutsetning for kommunikasjon, meningsutveksling, prioritering og faktabaserte beslutninger.

Virksomhetsarkitektur bidrar til å skape overblikk og håndtere endring i store og komplekse virksomheter. Virksomhetsarkitektur har metodikk og verktøy for å skape felles forståelse av helheten, av reelle behov og hvilke organisatoriske og teknologiske endringer som kreves. Dette gir gjennomsiktighet og gjør det lettere å prioritere og gjennomføre de riktige endringsreisene.

En vanlig utfordring er at endringsaktiviteter etableres og gjennomføres uten at virksomhetsarkitekturen er tilstrekkelig beskrevet og bearbeidet verken i beslutningsunderlag eller gjennomføring av endringen.

Virksomhetsarkitekturmetodikk sikrer at endringsarbeid

• -tar hensyn til helheten i dagens løsninger. Uten dette kan endringer bli suboptimale eller ineffektive for helheten, selv om f.eks. en applikasjon isolert sett forbedres.

• -tar hensyn til hvordan organisasjonen fungerer i dag. Hvis man ikke tilpasser selve organisasjonen samtidig som man innfører endringer så er det mindre sannsynlig at gevinstene blir realisert.

• -tar hensyn til prosesser i et ende-til-ende perspektiv. De verdiskapende prosessene går oftest på tvers av organisatoriske enheter. Dette utfordrer måten vi tenker utvikling på, men det utfordrer også måten vi styrer og leder virksomheten på.

Den optimale løsningen i slike situasjoner er å ta i bruk tjenestedesign, arkitektur- og virksomhetskompetanse, for å beskrive hvordan endringsaktiviten kan utvikles innenfor gjeldende eller en fremtidig beskrivelse av virksomheten. Samtidig vil man identifisere hva som er organisatoriske og teknologiske barrierer (avhengigheter) for å kunne lykkes i implementering av fremtidige løsninger(endringsprosesser).

I neste avsnitt belyses ytterligere hvordan virksomhetsarkitektur bygger sammenheng mellom organisasjon, prosesser og teknologi.

1.3.2 Beskrivelser av sammenheng mellom organisasjon, prosesser og teknologi

Hva er status i dag og hvordan fungerer det egentlig? Alt starter med innsikt og forståelse bygd på et solid og helhetlig grunnlag. Arkitekturpraksisen har verktøy for å gi gode og helhetlige situasjonsbeskrivelser av nåsituasjonen, avdekking av problemer, utfordringer og mangler, samt muligheter og alternativer for forbedringer og endringer.

Helse- og omsorgstjenestene har mange nivåer og arkitekturlag som skal fungere i en helhet. «Virksomhetskart[2]» bidrar til å skape nødvendig oversikt men også gjennomsiktighet. De bidrar til å styrke kommunikasjon og samhandling og er et verktøy for rolleutvikling og for å forankre og implementere nye arbeidsprosesser.

$Beskrivelse: H:\Arkitekturplan\Headspin\grafiske figurer\jpgs\figur1.jpg$
For å kunne beskrive sammenhengene mellom organisasjon, prosesser og teknologi, deles arkitekturbeskrivelsene inn i ulike lag, som kalles arkitekturdomener[3], som skissert i Feil! Fant ikke referansekilden., og beskrevet nedenfor.

Figur 1 Beskrivelser i ulike arkitekturdomener og sammenhengen mellom dem

Forretningsarkitektur
Beskrivelser av struktur og samspill mellom strategi, eksterne og interne krav, organisasjonen, funksjoner, virksomhetsprosesser og informasjonsbehov.

Informasjonsarkitektur

Beskrivelser av struktur og sammenhenger i virksomhetens sentrale informasjon, med fokus på informasjonstyper, kilder og flyten av informasjon, enten muntlig, skriftlig eller elektronisk.

Applikasjonsarkitektur
Beskrivelser av struktur og samspill mellom applikasjonene (IKT-løsningene), med fokus på hvordan disse tilbyr funksjonalitet for forretningsarkitekturen og håndterer informasjon og informasjonsflyt.

Teknologiarkitektur
Beskrivelse av struktur og samspill i plattform- og infrastrukturtjenestene, for eksempel beskrivelse av nettverk med dataservere, skrivere og lignende.

Sammenheng i og mellom arkitekturdomener

En viktig del av arbeidet med virksomhetsarkitektur er å sikre samsvar innen hvert domene, og mellom domener. En god virksomhetsarkitektur kan på den måten gi svar på sentrale spørsmål som for eksempel:

• Hvilke prosesser må vi endre hvis vi endrer en strategi eller et virksomhetsmål?

• Hvilken funksjonalitet trengs for å understøtte arbeidsprosessen i foretak/klinikk?

• Hvilke aktiviteter i vår arbeidsprosess kan vi endre fra manuell til automatisk med den nye funksjonaliteten som applikasjonen tilbyr?

• Hva fordres av teknologiske eller organisatoriske endringer for å lykkes med implementering av ønsket endringsprosess?

Arbeid med virksomhetsarkitektur gir mulighet til å få innsikter som besvarer spørsmål av typen over. Dette bidrar til god oversikt og bedre kontroll ved planlegging av endringsaktiviteter. Se vedlegg for mer om sammenhenger i og mellom arktitekturdomener.

1.3.3 Sikre samkjøring mellom nasjonalt, regionalt og lokalt nivå

Virksomhetsarkitekur skal sikre underlag for beslutninger og gjennomføring av strategiske prioriteringer og føringer. Slike prioriteringer foreligger både i helseforetakene, i helseregionene og på nasjonalt nivå[4] (nasjonale helsemyndigheter). I spesialisthelsetjenesten er det samspill mellom eksempelvis strategi, virksomhetsarkitektur og porteføljestyring på nasjonalt, regionalt og lokalt nivå.

Hvert helseforetak har ansvar for sine strategier og måten de blir implementert på innenfor rammene som gis av de regionale helseforetakene. Det stilles også krav om samhandling med sektoren for øvrig, med andre eksterne aktører og innbyggere.

Dette fører til:

• avhengighet til både regionale og nasjonale prioriteringer

• forpliktende deltakelse og/eller avhengighet til regionale og nasjonale programmer og prosjekter

• relasjoner til den regionale IKT-enheten (Hemit i HMN)

Samtidig skal det enkelte helseforetak utvikle sin virksomhet basert på lokale og regionale premisser og forhold, hvor det kan være store ulikheter i mål, planer og forutsetninger fra et helseforetak til et annet.

I virksomhetsarkitekturen inngår flere virkemidler for å sikre godt samspill mellom styringsnivåene og styringsområdene som her er skissert. Beskrivelser av disse finnes i vedlegg.

1.3.4 Verdi for alle som er involvert i endringer

I samarbeidet om utvikling av virksomheten og gjennomføring av endringer kan det oppstå utfordringer ved at ulike fagfolk har ulikt utgangspunkt og forståelse. Virksomhetsarkitektur skal bidra til å oppnå felles forståelse i samarbeidet.

Virksomhetsarkitektur må først og fremst gi verdi til helseforetakene og deres virksomhetsprosesser (herunder kliniske og administrative prosesser). Det er helseforetakene som utfører oppgavene spesialisthelsetjenesten har ansvar for. Virksomhetsarkitekturen må sett fra det enkelte foretaks side bidra til at deres strategi blir realisert.

Alle som er involvert i eller blir berørt av aktivitetene, har interesser i virksomhetsarkitektur, for eksempel helsepersonell, beslutningstakere, endrings-/prosjektledere og virksomhetsarkitekter/arkitekter.

Interessentene kan deles inn i fire hovedgrupper ut fra hovedinteresse i endringer og hvilken konkret verdi man kan få ut av virksomhetsarkitektur i arbeidshverdagen .

De som skal treffe beslutninger.

Ledere har behov for å få oversikt, se alternativer, og for å kunne vurdere muligheter og konsekvenser av en beslutning. Verdien av virksomhetsarkitektur er faktabasert beslutningsunderlag. Ledere har også behov for å sikre god gjennomføring av endringsaktiviteter.

De som skal utforme endringer

Eksempelvis organisasjonsutviklere/endringsledere, helsepersonell, linjeledere, virksomhetsarkitekter og andre som arbeider med målbeskrivelser, prosesser og arbeidsoppgaver. Verdien av virksomhetsarkitektur er beskrivelser på ulike nivå og med ulik detaljeringsgrad, av det man ønsker å oppnå gjennom endringer.

De som blir berørt av endringer

Eksempelvis helsepersonell og andre aktører i en endringsprosess som skal finne sted, inkludert interne og eksterne leverandører. Verdien av virksomhetsarkitektur er beskrivelser som bidrar til forståelse for endringen som skal gjennomføres, og mulighet til å påvirke beslutningene.

De som skal gjennomføre endringer

Eksempelvis linjeledere, organisasjonsutviklere/endringsledere, løsningsarkitekter, programvareleverandører og utviklere som arbeider med løsninger, fra overordnet til detaljert design. Verdien av virksomhetsarkitektur er beskrivelser og bedre forståelse for hvordan endringer skal gjennomføres.

1.4 Mål: Systematisk og strategisk bruk av virksomhetsarkitektur

I dag arbeides det systematisk med virksomhetsarkitektur primært i HMNs IT-organisasjon (Hemit). Hemit har det største fagmiljøet for virksomhetsarkitektur i spesialisthelsetjenesten i Midt-Norge. Helse Midt-Norge involverer virksomhetsarkitekter i mange store IKT-prosjekter.

Virksomhetsarkitektur er en måte å jobbe på som er tatt i bruk i et utvalg prosjekter, men det er fortsatt en lang vei å gå før en kan si at denne måten å jobbe på er standardisert i virksomheten.

For at HMN skal kunne ta ut gevinstene som virksomhetsarkitektur kan gi, er det nødvendig å etablere en praksis for virksomhetsarkitektur, dvs. beskrive hvordan HMN organiserer, styrer og gjennomfører arbeidet med virksomhetsarkitektur. Praksis for virksomhetsarkitektur forkortes til arkitekturpraksis.

2 Virksomhetsarkitektur i HMN - Arkitekturpraksis

Dette kapittelet fremmer forslag til organisering og innsatsområder (aktiviteter) for å kunne lykkes med en implementering av arkitekturpraksis i HMN som vil understøtte Helsetjenesten i Midt-Norge. Denne versjonen av Arkitekturplan er utarbeidet parallelt med at Helse Midt-Norge forbereder innføring av Helseplattformen. En framtidig revisjon av Arkitekturplan anbefales å ta høyde for å beskrive styring og organisering av arkitekturpraksis etter at styringsmodell er besluttet.

2.1 Hovedelementer i arkitekturpraksis

Figur 2 synliggjør hovedelementer i en arkitekturpraksis: en arkitekturfunksjon, styrende organer samt arkitekturbiblioteket.

Arkitekturfunksjonen utfører arkitekturtjenester og oppgaver som benyttes i for eksempel porteføljestyring, prosjekter og endringsarbeid i foretakene. Beslutningstakere i HMN styrer praksisen og utarbeider strategier. Beskrivelsene av virksomheten samles og tilgjengeliggjøres i et arkitekturbibliotek. Etablering av en arkitekturpraksis bidrar til at alle enkeltaktiviteter og prosjekter drar i samme retning blant annet gjennom gjenbruk og videreutvikling av løsninger og beskrivelser av løsningene i arkitekturbiblioteket.

$Beskrivelse: H:\Dokumenter\Gruppeleder Arkitektur\Arkitekturplan\Arkitekturpraksis.jpg$

Figur 2 Arkitekturpraksis, (TOGAF Architecture Capability Overview [5],oversatt og tilpasset til HMN)

Med operativ drift menes både aktiviteter innen HMN s kjerneområder og støtteaktiviteter, f.eks. driftsoppgaver som utføres av Hemit.

2.1.1 Arkitekturfunksjonen

Dette kapittelet beskriver hvilke tjenester og oppgaver som bør inngå i HMNs arkitekturfunksjon. Begrepet arkitekturfunksjon brukes om enheter og personell som leverer arkitekturtjenester til virksomheten i samspill med resten av organisasjonen innenfor det vi kaller for arkitekturpraksisen[6]. Arkitekturfunksjonen ivaretar samtidig utvikling og forvaltning av faget virksomhetsarkitektur.

Beskrivelsen som følger er uavhengig av hvor og hvordan arkitekturfunksjonen organiseres.

Tjenester (arbeidsoppgaver) som arkitekter utfører i samarbeid med de som gjennomfører endringer:

• Utarbeide beskrivelser av virksomheten (virksomhetsmodellering) etter behov i endringsprosessene, i henhold til arkitekturmetode.

• Sikre at alle endringer forholder seg til felles virksomhetskart[7], bidra til oppdatering og videreutvikling av virksomhetskartet.

For å kunne levere disse tjenestene må arkitekturfunksjonen også utføre følgende oppgaver:

Utføre rådgivning:

• Vurdere forslag til endringer som involverer IKT og deres samsvar med arkitekturprinsipper, strategier og målbilder.

• Gi høringssvar på nasjonale initiativ.

• Kompetanseheving innen virksomhetsarkitektur.

• Gi brukerstøtte til bruk av arkitekturbiblioteket.

• Detaljering av prinsipper, standarder og referansemodeller.

Utvikle og forvalte:

• Arkitekturbibliotek og verktøy.

• Arkitekturmetodikk

• Kompetanse og forståelse for arkitekturpraksis og perspektiver.

• Spesialiserte arkitekturoppgaver tildelt Helse Midt-Norge, for eksempel utarbeidelse av en gitt referansemodell eller nasjonalt ansvar for et område[2].

Være pådriver for å:

• Realisere nasjonale og regionale strategier.

• Løfte lokale prosjekter inn i en regional kontekst i samarbeid med porteføljestyrings-funksjonen.

• Løfte regionale prosjekter inn i en nasjonal kontekst i samarbeid med porteføljestyringsfunksjonen og direktoratet for eHelse.

Følgende oppgaver må ivaretas for å sikre god ledelse og utvikling av arkitekturpraksis:

• Styring av kompetanse
Sikre at ressursene som innehar roller i arkitekturfunksjonen har nødvendig kompetanse for å utføre oppgavene og tjenestene.

• Koordinering av funksjonen
Koordinere ressursene slik at oppgaver og tjenester blir løst. Sørge for et velfungerende samarbeid mellom arkitekter på tvers av organisasjoner, prosjekter og oppgaver.

• Forvaltning av arkitekturstrategi/-plan
Utvikle og forvalte mål, strategi og tiltaksplan for arkitekturpraksisen i tråd med virksomhetens forventninger.

2.1.2 Arkitekturbibliotek

Arkitekturpraksien vil bidra til å samle alt relevant materiale i et arkitekturbibliotek. Relevant informasjon om de overordnede og underliggende prosesser kan raskt hentes fram og belyse hvilke bestanddeler som en endringsprosess vil ha avhengigheter til.

Når det inntreffer endringer i føringer eller rammevilkår vil man raskt kunne analysere hvilke prosesser som berøres av disse endringene og hvilke faktorer som de er avhengige av. Virksomheter som arbeider systematisk med virksomhetsarkitektur vil få et godt utarbeidet arkitekturbibliotek. Dette gjør at en kan arbeide effektivt med endringsprosesser og samtidig sikre god gjennomføringsevne.

2.2 Organisering av arkitekturpraksis

2.2.1 Arkitekturpraksis på nasjonalt, regionalt og lokalt nivå

Fram til og med 2019 har det i Nasjonal IKT eksistert en nasjonal arkitekturfunksjon som HMNs arkitekturfunksjon har forholdt seg til og samarbeidet med [2].

Pr. desember 2019 er det under avklaring hvordan nasjonal arkitekturfunksjon og samspillet mellom regionenes arktiekturfunksjon skal bli i framtiden.

$Beskrivelse: H:\Arkitekturplan\Headspin\grafiske figurer\jpgs\figur7.jpg$

Figur 3 Organisering av arkitekturfunksjonene fram til og med 2019

2.2.2 Viktige roller i arkitekturpraksis

Innføring av arkitekturpraksis forutsetter en hensiktsmessig organisering og utvikling av sentrale roller. I dette avsnittet vil vi gjøre rede for overordnede beskrivelser av roller, og sammenhengen mellom disse. Dette representerer et rammeverk ved organisering av arkitekturpraksis i de ulike regioner. Hver region må imidlertid tilpasse dette til sin egen organisatoriske kontekst. I neste avsnitt beskrives dagens regionale overordnede organisering av arkitekturpraksis i HMN.

En arkitekturpraksis opererer på et strategisk, taktisk og operativt nivå med tilhørende roller som vist i Figur 9.

$Beskrivelse: H:\Dokumenter\Gruppeleder Arkitektur\Arkitekturplan\Figur 8.jpg$

Figur 4 Arkitekturpraksisens nivå og roller

I den videre utviklingen av arkitekturpraksis vil ambisjonsnivået i første omgang være å nyttiggjøre eksisterende strukturer i HMN.

Rolle	Beskrivelse
Administrerende direktører	Administrerende direktør i RHF og hvert enkelt HF har ansvar for den overordnede virksomhetsarkitekturen i sitt foretak.
Styringsgruppe Digitalisering og standardisering (SDS)	Styringsgruppen fatter mange beslutninger som påvirker virksomhetsarkitekturen.
Porteføljekontor	Sekretæriat som lager beslutningsunderlag for SDS. Ansvar for porteføljestyring og programstyrer.
Programstyrer	Ansvarlig for å styre prosjekter innenfor sitt programområde og fatte beslutninger som påvirker virksomhetsarkitekturen.

I dagens styringssystem for digitalisering og standardisering, fattes det beslutinger som påvirker virksomhetsarkitekturen. Økt fokus på arkitektur vil gi bedre innsikt i konsekvenser for prosess, organisasjon og teknologi for de besluttende organer.

2.2.3 Organisering av arkitekturpraksisen i HMN

Målbilde for organisering av styringsfunksjonen for arkitekturpraksis i HMN

En innføring av arkitekturpraksis i HMN forutsetter etablering av en styringsfunksjon som tar beslutninger med hensyn til arkitektur på et strategisk nivå.

Den regionale styringsfunksjonen i HMN skal sikre at arkitekturpraksisen

• er organisert på en effektiv måte

• er forankret i hele Helse Midt-Norge

• samarbeider på en effektiv måte

• har nødvendig kompetanse og kapasitet for utøvelse av arkitekturpraksis

• har et tilfredsstillende samspill med interessentene

• tar strategiske beslutninger for arkitekturpraksis

• sørger for å etablere og overvåke måleparametre for arkitekturpraksis

Styringsfunksjonen bør sees i sammenheng med øvrig styringsstruktur i HMN.

Nedenfor vises forslag til roller i framtidig arkitekturpraksis i HMN.

Rolle	Beskrivelse
Arkitektureier	Er øverste ansvarlig for arkitekturpraksisen og har beslutningsmyndighet på et strategisk nivå. Dette gjelder typisk i forhold som angår praksisens mål, funksjon, mandat og virke, for eksempel ved beslutninger om arkitekturprinsipper og strategiske veivalg.
Arkitekturansvarlig	Arbeider på et strategisk nivå og innstiller til arkitektureier.
Regionalt arkitekturstyre	Utøver rollen som arkitekturansvarlig. Det er rådgivende til Arkitektureier, og skal ha evne og vilje til å være beslutningsdyktige innen sitt definerte ansvarsnivå og område, inkludert å: • Sikre effektiv og konsistent styring og implementasjon av arkitektur gjennom en velfungerende arkitekturpraksis • Sikre at arkitekturen er fleksibel for å imøtekomme endring i organisasjonsmessige krav og utnytte ny teknologi • Øke modenhetsnivået for arkitektur i organisasjonen • Løse uklarheter, problemer eller konflikter på et strategisk nivå, og eventuelt eskalere disse til Arkitektureier • Sikre at organisasjonen adopterer en arkitekturbasert utvikling
Arkitekturforvalter	Arkitekturforvalter er ansvarlig for avgjørelser på taktisk nivå, og kan eskalere til arkitekturansvarlig på strategisk nivå. Arkitekturforvalter har typisk et sørge-for-ansvar i tett dialog med regionale og lokale virksomhetsarkitekter.
Regionalt arkitekturkontor	Utøver rolle som arkitekturforvalter. Innstiller og rapporterer til Regionalt arkitekturstyre. Har det operative, utøvende ansvaret for arkitekturarbeid i Helse Midt-Norge.
Arkitekter	Dette er utøvende fagpersonell innen arkitektur. De kan ha ulike spesialområder innenfor arkitekturen. Noen arkitekter har typisk fokus på overordnede arbeidsprosesser og informasjonsflyt. Andre vil være tettere tilknyttet underliggende IT- og sikkerhetsarkitektur.

Forslag til organisering av regionalt arkitekturkontor i HMN

Regionalt arkitekturkontor har det operative, utøvende ansvaret for arkitekturarbeid i HMN. Arkitekturkontoret innstiller og rapporterer til regionalt arkitekturstyre.

Ved organisering av regionalt arkitekturkontor foreslås en modell som i første fase tar utgangspunkt i dagens arkitekturfunksjon ved Hemit. Etterhvert som det utvikles kompetanse i HF skal en utvide det regionale arkitekturkontoret med representanter fra HF. Disse personer vil fortsatt være ansatt i HF. Slik utvidelse vurderes som nødvendig i forhold til det langsiktige målet om å implementere arkitekturpraksis i HMN. Det er styringsfunksjonen som må vurdere hvordan en slik utvidelse skal foregå.

Det regionale arkitekturkontor skal ha rådgivende funksjon til HF på oppbygging av kompetanse og kapasitet på Virksomhetsarkitektur.

Faser

Målbilde for organisering av regionalt arkitekturpraksis anbefales realisert gjennom to hovedfaser.

Fase 1 er definert som en modningsfase for oppbygging av kompetanse og kapasitet for å utøve arkitekturpraksis i HF og i styringsfunksjonene. Dette skal styrke organisasjonens kapabilitet til å faktisk anvende metodikk, modeller og nyttiggjøre seg arkitekturbiblioteket i styring av egen virksomhet og i gjennomføring av endringsprosesser. Erfaring fra Helse Vest og Helse Sør Øst viser at slik modning og kapasitetsbygging er viktig for å kunne lykkes. Ved å definere en modningsfase gis det handlingsrom for å kunne øve seg på utøvelse av arkitekturpraksis i de ulike delene av virksomheten.

Fase 2 er en implementeringsfase. Dette gjelder en implementering av arkitekturpraksis i HF. En arkitekturpraksis er en kontinuerlig prosess der en hele tiden utvikler eget arkitekturbibliotek i samsvar med nye føringer, ny teknologi og nye prosesser. Helsetjenesten har en kompleks struktur med stadige endringsprosesser som skal beskrives og bli del av arkitekturbiblioteket.

2.3 Samspillet med virksomhetens kjerneprosesser

Å drive en virksomhet består grovt sett av tre overordnede prosesser: Styring, kontinuerlig forbedring gjennom endring og daglig drift. Feil! Fant ikke referansekilden. viser hvordan virksomhetsarkitektur innvirker på virksomhetenes overordnede prosesser; i strategisk planlegging og virksomhetsstyring, porteføljestyring, design/implementering, drift/forvaltning/linjeledelse, og samspillet mellom dem. Pilene i figuren angir aktuelle leveranser mellom prosessene.

De neste avsnittene beskriver de viktigste områdene for samspill mellom virksomhetsarkitektur og de øvrige prosessene.

$Beskrivelse: H:\Arkitekturplan\Headspin\grafiske figurer\jpgs\figur3.jpg$

Figur 5 Samspill mellom virksomhetsarkitektur og øvrige prosesser[8]

2.3.1 Samspill med strategisk planlegging

Strategier skal være overordnede med tydelige prioriteringer og føringer. Virksomhetsarkitektur brukes mye for å beskrive hvordan en skal nå målene. Ved bruk av arkitekturprinsipper, modeller og beskrivelser av virksomheten (veikart) kan man i det strategiske arbeidet etablere et godt beslutningsunderlag.

Samspill mellom strategisk planlegging og arkitekturpraksis vil resultere i et tydeligere målbilde med mellomsteg som det taktiske og operative arbeidet kan rettes mot. Følgende skisse illustrerer dette resultatet. $Beskrivelse: H:\Arkitekturplan\Headspin\grafiske figurer\jpgs\figur4.jpg$

Figur 6 Resultat av samspill med strategisk planlegging

Beskrivelse av nåsituasjon, mål og mellomsteg (tranisisjonsarkitektur) er typiske eksempler på arkitekturleveranser.

2.3.2 Arkitektur som integrert del av porteføljestyring

Porteføljestyringen skal sikre at programmene og prosjektene samlet sett oppfyller HMNs strategi og målsetninger innenfor de rammene som er gitt.

Det er viktig å få belyst hvilke resultater (gevinster) prosjektporteføljen forventes å gi for helseforetakene, hva som er faktiske resultat (gevinster) og hvilke forutsetninger (risiko, barrierer og drivere) som vil påvirke muligheten til å lykkes. Arkitekturfunksjonen beskriver modeller og veikart for nåsituasjon, målbilder og mellomsteg. En beskriver eller belyser helheten og skaper gjennomsiktighet fra strategier og mål til beskrivelser av nødvendige endringer fram til implementering i foretakene og uttak av gevinster. Dette bidrar til å synliggjøre konsekvenser av endringer og forsinkelser, avhengigheter, prosjektrisikoer og uventede situasjoner som har oppstått.

Porteføljestyring i HMN er illustrert som følger: $Beskrivelse: H:\Arkitekturplan\Headspin\grafiske figurer\jpgs\figur5.jpg$

Figur 7 Porteføljestyring i HMN[9]

Porteføljestyringen i HMN omfatter både strategisk og operativ porteføljestyring. Dette handler om å «Gjøre de riktige tingene», dvs prioritere riktige satsninger men også «Gjøre tingene riktig», dvs sikre god gjennomføring.

For å sikre at en «gjør de riktige tingene» kan virksomhetsarkitektur bidra til:

1. å forstå strategier, mål og handlingsplaner og initiere nødvendige prosjektforslag i tillegg til å motta og utrede prosjektforslag direkte fra virksomheten

2. kategorisere og prioritere prosjekter ut fra gitte kriterier

3. balansere porteføljen slik at den best mulig oppfyller strategien med tilgjengelige ressurser

4. planlegge porteføljen slik at gjennomføringen er realistisk.

For å sikre at en «Gjør tingene riktig» kan arkitekturfunksjonen bidra til:

1. Følge opp planer, risiko og ressurser for den samlede porteføljen, samt håndtere avvik og utforutsette hendelser

2. Følge opp gevinstrealisering

3. Håndtere interessenter

Arkitekturfunksjonen kan bidra med modeller og oversikter som forenkler porteføljestyringens oppgaver. Overordnede virksomhetsmodeller kan gi oversikt over prosjekter og aktiviteter som er igangsatt for å oppnå hvilke mål. Dette bidrar til å gi oversikt og innspill til å balansere og styre porteføljen. Porteføljestyringen skal også sikre at programmer og prosjekter er egnet til å nå et mellomsteg/delmål. Dette krever støtte fra arkitekturpraksisen (transisjonsarkitektur) som i større grad ser og kan kommunisere konsekvenser og muligheter ut fra et helhetlig perspektiv, og som er fokusert på mål, delmål (mellomsteg) og planer for å realisere disse.

HMNs porteføljestyring er etablert og beskrevet i form av organisering og prosesser der prioriteringsprosessen er den mest sentrale. Porteføljestyringen består av et antall programstyrer under SDS (HMNs HF og RHF direktører). Et regionalt porteføljekontor forbereder saker til SDS. Når programmer og prosjekter er startet, følger de program- eller prosjektmetodikk.

2.3.3 Samspill med prosjektgjennomføring og endringsprosesser

Prosjekter innenfor Digitalisering og standardisering skal gjennomføres i tråd med arkitekturpraksis.

Design og implementeringsfasen kan være en krevende fase i mange endringsprosesser. Dette handler om hvordan organisasjonen responderer på nytt løsningsdesign og måten denne skal implementeres på. Det er i denne fase viktig å skape omforent forståelse i organisasjonen om endringsprosessen. Arkitekturbeskrivelsene kan understøtte effektiv kommunikasjon og omforent forståelse gjennom tydelige målbilder og hvordan en håndterer de faktorer som vil påvirke endringsprosessen.

En endringsprosess vil ofte organiseres innenfor rammene av et prosjekt. Et prosjekt kan bestå av flere faser; fra idé, via planlegging, gjennomføring og avslutning til realisering. Feil! Fant ikke referansekilden. er et forslag til samspill mellom prosjektprosessen og arkitekturpraksisen. Arkitekturpraksisen skal bidra til et godt underlag for å beslutte planlegging av et prosjekt, gjennomføring av prosjektet, oppstart av avslutningsfasen, avslutning og realisering av prosjektet, jfr. beslutningspunktene B2-B6 i figuren.

Figur 8 Arkitekturpraksisens bidrag i prosjekter

I tillegg til virksomhets- og IT-arkitekter som bidrar direkte i prosjektet, skal ethvert prosjekt melde behov for gjennomgang av de planlagte leveransene til en kvalitetssikringsfunksjon. Gjennomgangene skal både gi innspill til leveransene og sikre at de er i samsvar med prinsipper og føringer (se kapittel 2.3). Kvalitetssikringsfunksjonen må inneha kompetanse på alle nivå i arkitekturen og vil bistå arkitekten(e) som inngår i prosjektet.

Prosjektene og kvalitetssikringsfunksjonen har mulighet til å avklare strategiske valg for arkitektur og eskalere uenigheter.

Gjennomgang i de ulike prosjektfasene er avhengig av at prosjektleder/arkitekt i prosjektet melder inn sak til behandling i arkitekturforum. For å formalisere dette må gjennomgang i kvalitetssikringsfunksjonen nedfelles i prosjektmetodikken.

2.3.4 Samspill med drift, forvaltning og linjeledelse

I forbindelse med ferdigstiling av prosjekter så skal etablert arkitketurdesign dokumenteres i respektive arkitekturbibliotek.

Forvaltning av arkitekturbeskrivelser vil også involvere de operasjonelle deler av virksomheten, dvs. linjeorganisasjonene i foretakene. Alle drifts- og forvaltningsoppgaver må utføres innenfor gitte rammer; mandat, strategiske føringer, lovpålagte krav og oppdragsdokumenter. Arkitekturpraksisen skal bidra til å sikre god sammenheng mellom rammevilkårene og drifts- og forvaltningsoppgavene.

I drifts-/forvaltningsorganisasjonene vil arkitekturbiblioteket være en viktig kilde for deres egne prosesser. En drifts-/forvaltningsorganisasjon kan også gi opphav til endringer som fører til at andre arkitekturprosesser settes i gang. For eksempel kan ny teknologi innen infrastruktur gi opphav til endringer som fører til at arkitekturfunksjonen involveres og medfører nye krav til IKT-løsningene.

Det er viktig med samspill med arkitekturpraksisen, slik at det til enhver tid er samsvar mellom beskrivelser og oppfatninger om nåsituasjonen, samt om målbildet og endringsplanene. Verdien av en arkitekturpraksis i virksomheten vil øke etter hvert som flere standardiserte arbeidsprosesser etableres og gjennomføres.

3 Overordnede prinsipper og føringer

For at Helse Midt-Norge skal kunne ivareta sin rolle som en viktig helseaktør i Midt-Norge må alle foretakene forholde seg til en rekke regionale og nasjonale føringer i form av strategier og andre styrende dokumenter. Disse føringene vil påvirke arkitekturen og måten vi implementerer endringer til arkitekturen. Føringene vil også kunne ha innvirkning på arkitekturpraksisen, da de kan legge føringer for beslutningsprosesser som det må tas hensyn til ved innføring av en praksis. En viktig del av slike føringer er spesialisthelsetjenesten sine arkitekturprinsipper som behandles mer utførlig senere i kapittelet. I tillegg til slike føringer, vil også lover og forskrifter påvirke måten vi utøver virksomhetsarkitektur på i HMN.

3.1 Nasjonale og regionale strategier og føringer

Det viktigste nasjonale dokumentet som gir overordnede føringer for HMN er oppdragsdokumentet som HMN får fra Helse- og omsorgsdepartementet. Oppdragsdokumentene inneholder krav fra Helse- og omsorgsdepartementet til de regionale helseforetakene om hvilke oppgaver som skal utføres i det påfølgende år.

Helse- og omsorgsdepartementets oppdragsdokumenter til de regionale helseforetakene har to formål:

• Stille styringskrav til de regionale helseforetakene.

• Formelt stille midlene i Stortingets budsjettvedtak til deres disposisjon.

I tillegg til dette styrende dokumentet er det utarbeidet en Nasjonal strategi og plan for e-helse[10] som definerer overordnede mål for IKT-utviklingen i helse- og omsorgssektoren.

HMN tar hensyn til de nasjonale føringene og styringsdokumentene og utarbeider HMN spesifikke strategier og føringer. Til sammen utgjør dette føringer for virksomhetsarkitekturen i HMN. Figur 9 viser hvordan sammenhengen er mellom de viktigste dokumentene som påvirker virksomhetsarkitekturen og arkitekturpraksisen i HMN.

Figur 9 Forhold til andre dokumenter og premissgivere

Helse Midt-Norges Strategi 2030 (virksomhetsstrategi) og regional utviklingsplan er de viktigste overordnede dokumentene som påvirker utøvelsen av arkitekurpraksisen i HMN. Virksomhetsstrategien legger føringer for virksomhetsmålene som skal oppnås frem til 2030 og utviklingsplanen legger føringer for hva IKT skal bidra med for å nå disse målene.

Arkitekturplanen(denne) legger ytterligere føringer for hvordan HMN skal nå sine virksomhetsmål gjennom å beskrive metoder og praksis for å gjennomføre vedtatte tiltak.

En rekke lover og forskrifter vil også påvirke virksomhetsarkitekturen. En del av disse er behandlet i Sikkerhetsplanen for HMN. I tillegg må HMN generelt og arkitekturpraksisen spesielt, forholde seg til lover og forskrifter som gjelder for spesialisthelsetjenesten. En oversikt over styrende dokumenter m.m. for prosjekter finnes i dag på HMN Prosjektweb[11], nasjonale føringer m.m. hos Helsedirektoratets informasjonskanal ehelse.no og gjeldende lover/forskrifter på lovdata.no.

3.2 Arkitekturprinsipper

For å sikre gode og helhetlige endringsprosesser der IKT er involvert har Nasjonalt IKT (NIKT) nedfelt arkitekturprinsipper som gjelder for spesialisthelsetjenesten. Disse bygger på arkitekturprinsippene utarbeidet av Difi[12] for offentlig sektor. Alle som skal jobbe med virksomhetsarkitektur i HMN må kjenne til og anvende disse prinsippene. I tillegg kan det gjennom prosjekter og andre aktiviteter utvikles egne prinsipper som kan legges til grunn når en arbeider med virksomhetsarkitektur i HMN.

Dette kapitlet beskriver arkitekturprinsippene, bakgrunn og hvordan de skal følges, samt hvilke implikasjoner de får for arbeidet i Helse Midt-Norge. Mye av teksten som står i dette kapitlet er gjenbruk fra NIKT, dette er uthevet med referanse til nummerert prinsipp, NIKT 1-9. Prinsippene og hovedformål er hentet fra Nasjonal IKT sin HelseWiki[3].

Hovedformål med prinsippene

Spesialisthelsetjenesten har utformet felles prinsipper som er begrunnet som følger:

«Hovedformål med prinsippene er å

• understøtte de fire lovpålagte oppgavene til sykehusene (pasientbehandling, forskning, utdanning av helsepersonell, og opplæring av pasienter og pårørende) på en måte som ivaretar pasientsikkerheten

• definere retning for utvikling av virksomheten

• være styrende for alle prosjekter og aktiviteter som involverer IKT

• fungere som evalueringskriterier for foreslåtte endringer, og legges til grunn ved beslutninger knyttet til porteføljestyring og virksomhetsarkitektur

Prinsippene er utformet slik at de ikke skal være i motstrid med prinsippene for offentlig sektor generelt, og helsesektoren spesielt, slik disse er formulert fra Difi og Helsedirektoratet.»

Arkitekturprinsippene for spesialisthelsetjenesten er definert av NIKT og er som følger:

1. Helhetlig tilnærming

2. Prosessorientering

3. Tjenesteorientering

4. Interopabilitet (evne til samhandling)

5. Informasjonssikkerhet

6. Tilgjengelighet

7. Brukskvalitet

8. Endringsevne

9. Informasjonsforvaltning

Prinsippene beskrives mer detaljert i avsnittene under.

3.2.1 Helhetlig tilnærming

«Helhetlig tilnærming skal benyttes ved vurdering av behov, endringer, muligheter og løsninger. Dette innebærer å se på den totale nytteverdien for spesialisthelsetjenesten og sektoren for øvrig.»(NIKT 1)

Hva kan dette prinsippet bety for Helse Midt-Norge?

Helse Midt-Norge må etablere en arkitekturpraksis som beskrevet i IKT-strategien og i dette dokumentet for å sikre et tverrfaglig samarbeid i regionen og etablere et sterkere samarbeid mellom foretakene i regionen. Vi vil da få etablert flere regionale løsninger som ivaretar helhetstenkning og felles arbeidsprosesser.

Bakgrunn:

Prosesser, organisering og IKT-løsninger er ofte utformet for å dekke isolerte, lokale behov. Dette gjør det utfordrende å etablere et effektivt tverrfaglig samarbeid på tvers av organisatoriske grenser, og reduserer mulighetene til samhandling i og mellom prosesser og IKT-løsninger. Tverrfaglig samarbeid om f.eks. pasientforløp blir krevende, og IKT oppleves i mange tilfeller som ikke prosesstøttende.

Beslutninger tatt i et helhetlig og tverrfaglig perspektiv har større langsiktig verdi enn beslutninger tatt i et isolert, lokalt perspektiv. Systematisk helhetstenking i aktiviteter og prosjekter vil gi større total verdi for virksomhetene. Man vil oppnå mer effektiv samhandling, og IKT-løsninger vil i større grad være utformet for å understøtte dette.

Hvordan prinsippet skal følges:

Behov og endringer må sees i lys av nåsituasjon og planlagt utvikling. For eksempel skal endring i en prosess sees i sammenheng med tilstøtende prosesser. I tillegg må konsekvenser for bruk av informasjon, applikasjoner og teknologi vurderes.

Interessenter fra relevante fag- og tjenesteområder må delta i prioritering og utvikling av virksomhetens prosesser, tjenester og underliggende IKT-løsninger.

Prosjekter og organisasjoner må være beredt til å gi slipp på egne preferanser dersom det gir en større total nytteverdi.

Nasjonale føringer skal følges.

3.2.2 Prosessorientering

«Virksomhetene skal gjennom prosessorientering (pasientforløp, øvrige kjerneprosesser og støtteprosesser) realisere helhetlige og sammenhengende helsetjenester, og sikre at IKT-løsninger utformes for å understøtte prosessene»(NIKT 2)

Hva kan dette prinsippet bety for Helse Midt-Norge?

Ved gjennomføring av endringer, skal berørte prosesser beskrives i form av arbeidsprosesser. All prosesskartlegging i Helse Midt-Norge skal dokumenteres i Helse Midt-Norge sitt arkitekturverktøy/arkitekturbibliotek, som er Mega. Prosessene skal beskrives på en slik måte at de synliggjør informasjonsflyt og hvordan IKT-funksjonalitet blir tatt i bruk i prosessene.

Bakgrunn:

Prosessene binder sammen det virksomheten gjør for å skape verdi. Ved å ta utgangspunkt i prosessene ved utforming av IKT-løsninger, vil man oppnå bedre beslutnings- og prosesstøtte, til både enkeltoppgaver og samhandling.

Dette perspektivet vil også bidra til harmonisering og bruk av beste praksis i utvikling av prosesser og IKT-løsninger. Det vil kunne øke virksomhetenes totale verdiskaping og redusere kostnadene.

Hvordan prinsippet skal følges:

Virksomhetene skal ha oversikt over sine prosesser og hvordan disse henger sammen. Disse skal dokumenteres på en enhetlig og helhetlig måte som synliggjør informasjonsflyt og avhengigheter til understøttende IKT-løsninger.

Virksomhetene skal arbeide med kontinuerlig prosessforbedring for å optimalisere kvalitet og effektivitet, og forenkle og/eller automatisere samhandling og arbeidsoppgaver. Virksomheten skal sikre at egnede IKT-løsninger benyttes for å forbedre og understøtte prosesser i dag og fremover.

Prosesser skal ha en eier som er ansvarlig for dens ytelse.

Dokumenterte prosesser må legges til grunn for krav til IKT-leverandører for å sikre at disse arbeider aktivt for å utvikle IKT-løsninger som gir optimal støtte til spesialisthelsetjenestens prosesser.

3.2.3 Tjenesteorientering

«Tjenesteorientering skal legges til grunn ved utforming av virksomhetene og deres IKT-løsninger. Dette gjelder for alle domener av virksomhetsarkitekturen (forretning, informasjon, applikasjon, og teknologi).»(NIKT 3)

Hva kan dette prinsippet bety for Helse Midt-Norge?

IKT-løsninger som etableres i Helse Midt-Norge skal tilby «sin» funksjonalitet i form av tjenester. Det vil si at andre systemer kan få informasjon gjennom disse tjenestene hvis det er ønskelig. Prinsippet er viktig for å muliggjøre deling av informasjon på tvers i virksomheten og beskriver en måte å gjøre dette på.

Disse tjenestene skal kunne inngå som en del av en tjenesteplattform. Pr. i dag er dette operasjonalisert på Helse Midt-Norge sin integrasjonsplattform. Tjenester skal tilbys basert på standarder for å sikre interoperabilitet se kap 3.2.4.

Bakgrunn:

Tjenesteorientering er en tilnærming og en fremgangsmåte der informasjon og funksjoner defineres og leveres gjennom tjenester. Tjenester åpner for effektivisering gjennom gjenbruk i stedet for å utføre de samme eller lignende tjenester flere steder (av flere tjenesteytere eller IKT-løsninger).

Pasienten i fokus står sentralt i spesialisthelsetjenestens strategier, noe som krever endringer i tilnærming til pasient-behandling. I dette arbeidet vil tjeneste-orientering være et viktig virkemiddel. Tjenesteorientering understøtter og muliggjør funksjonsfordeling mellom sykehus, pasientens medvirkning til egen helsehjelp og helhetlige pasientforløp på tvers av enheter i sykehus, helseforetak og nivå.

IKT-løsninger uten en tjenesteorientert tilnærming fremstår ofte som isolerte og lukkede med sterke avhengigheter i den interne oppbygningen. Konsekvensene av slike løsninger er typisk kostbare og tidkrevende endringer, og duplisering av informasjon og funksjonalitet. Denne kompleksiteten gjør forvaltning av store systemporteføljer krevende.

Tjenesteorientering gir følgende effekter:

• Bidrar til å begrense duplisering av informasjon og funksjonalitet ved å gi grunnlag for felles tjenester, gjenbruk og sambruk.

• Ved å kombinere gjenbrukbare tjenester blir det enklere å tilby pasienten tjenester som er tilpasset det aktuelle forløp.

• Gjør det enklere å utforme og tilgjengeliggjøre publikumstjenester rettet mot pasienters og pårørendes medvirkning til helsehjelp. Gir økt endringsevne og stimulerer til konsolidering og standardisering av beslektede funksjoner i alle domener.

• Legger til rette for å redusere leverandør- og produktavhengigheter, ved at funksjonalitet enklere kan erstattes.

Hvordan prinsippet skal følges:

Følgende retningslinjer skal bidra til tjenesteorienterte løsninger:

• Nye tjenester skal utformes med tanke på gjenbruk og sambruk, og ved enhver endring skal det derfor vurderes hvorvidt eksisterende tjenester kan benyttes direkte eller etter en tilpasning/utvidelse.

• Prosesser og IKT-løsninger skal være i stand til å betjene alle med sammenfallende behov for en gitt tjeneste. Dette vil være kostnadseffektivt og blant annet bidra til standardisering.

• Tjenester skal bygges opp som komponenter der tjenestens virkemåte, sett utenfra, kun er kjent gjennom beskrivelse av tjenesten og veldefinerte grensesnitt.

• Det skal være mulig å endre en tjeneste med minimal innvirkning på andre tjenester (dvs. løs kopling).

• Ved nyutvikling, videreutvikling og anskaffelser skal gjenbruk/deling av funksjoner vurderes i de ulike IKT-løsningene og bruk av offentlige fellestjenester.

Tjenester kan være virksomhetsinterne, regionale eller nasjonale. Tjenester kan defineres på ulike detaljnivåer, og en tjeneste kan benytte seg av andre tjenester.

3.2.4 Interoperabilitet (evne til samhandling)

«Virksomhetene og deres IKT-løsninger skal utformes med sikte på interoperabilitet på organisatorisk, semantisk og teknisk nivå»(NIKT 4)

Hva kan dette prinsippet bety for Helse Midt-Norge?

Organisatorisk interoperabilitet eksisterer allerede internt i Helse Midt-Norge gjennom den etablerte samhandlingen både innad i foretakene og mellom foretakene. Når denne skal utvikles videre, for eksempel med kommunehelsetjenesten og offentlig forvaltning, bør det skje i regi av arkitekturpraksisen som beskrevet i kapittel 2 og med de virkemidler som skal benyttes for slike endringer.

Semantisk interoperabilitet. Meldingsutveksling og tjenester i IKT-løsningene i Helse Midt-Norge skal implementeres ved bruk av nasjonalt vedtatte innholdsstandarder (HL7, DICOM, KiTH-xml etc.), slik at samhandling med ulike systemer og applikasjoner enklere kan generaliseres og forvaltes.

Teknisk interoperabilitet er i HMN etablert på flere områder og skal sørge for at applikasjoner og systemer kan samspille på en enklere måte. For å understøtte dette skal elektronisk informasjonsutveksling implementeres på HMNs integrasjonsplattform, som p.t. er BizTalk Server 2010. Se 3.2.3. Integrasjonsplattformen tilbyr tjenester og mekanismer for å muliggjøre sikker utveksling av data på ulike måter ved ulikt behov. Eksempler på dette er:

• Publiserte webtjenester og webtjeneste standarder for synkron dataoverføring

• FTP, SFTP, MSMQ - Ulike protokoller for asynkron dataoverføring

• Mekanisme for korrelering og persistering av data

Andre eksempler på standarder som benyttes for å understøtte teknisk interoperabilitet er:

• PKI - Rammeverk for for utstedelse, administrasjon og bruk av digitale sertifikater

• Kerberos – Sikkerhetsprotokoll for autentisering av Windows brukere

• TCP/IP – Kommunikasjonsprotokoll

Bakgrunn:

Pasientforløp involverer mange aktører på ulike nivåer i helsesektoren. Informasjon må utveksles både mellom disse aktørene, med pasienten og med offentlige og private aktører utenfor helsesektoren. Innad i spesialisthelsetjenesten går mange pasientforløp på tvers av helseforetak og organisatoriske enheter, og informasjon må utveksles mellom mange IKT-løsninger.

Interoperabilitet skal bidra til at prosesser fungerer og rett informasjon er tilgjengelig på tvers av virksomheter og omsorgsnivåer.

Hvordan prinsippet skal følges:

Vi skiller mellom tre ulike former for interoperabilitet: organisatorisk, semantisk og teknisk.

Organisatorisk interoperabilitet er virksomhetenes evne til samhandling, og omfatter organisatoriske enheter innenfor spesialisthelsetjenesten, samt kommunale og private leverandører av helsetjenester. Organisatorisk interoperabilitet oppnås gjennom samordning av arbeidsprosesser og ved at øvrige organisatoriske forhold tilpasses en mest mulig effektiv samhandling. Dette inkluderer forretningsmodeller og regelverk.

Man skal ha fokus på etablering av eierskap til helhetlige prosesser heller enn IKT-løsninger.

Semantisk interoperabilitet er evne til samhandling basert på felles forståelse av informasjon som utveksles mellom aktører i prosesser og IKT-løsninger. Dette forutsetter felles begreper samt standarder for informasjonsinnhold og kodeverk. Internasjonale standarder skal brukes der de er tilgjengelig. Standardene legger føringer for hvordan både ustrukturert og strukturert informasjon skal registreres, slik at denne informasjonen har samme betydning for ulike aktører i sektoren. Semantisk interoperabilitet omfatter også beskrivelse og forankring av felles begrepsapparat for kommunikasjon mellom mennesker.

En av bærebjelkene i virksomhetsarkitekturen skal være en logisk informasjonsmodell som går på tvers av virksomhetsområder og fagdisipliner for å sikre felles forståelse av begreper og strukturer.

Hvis det avdekkes behov for nye standarder skal dette meldes inn til den aktør som har ansvar for standardisering innenfor det aktuelle området. Felles begrepsapparat for områder der det er behov for felles forståelse, på tvers av fagområder, må etableres og forankres.

Teknisk interoperabilitet er evne til samhandling mellom tekniske løsninger. Dette krever at etablerte tekniske standarder følges. Teknisk interoperabilitet skal ivaretas ved å følge gjeldende referansearkitekturer innenfor sektoren. Referansearkitekturen beskriver tekniske standarder og mekanismer for informasjonsutveksling/‐deling.

3.2.5 Informasjonssikkerhet

«Virksomhetene skal sikre informasjonens kvalitet, konfidensialitet, integritet, tilgjengelighet og sporbarhet.»(NIKT 5)

Hva kan dette prinsippet bety for Helse Midt-Norge?

Helse Midt-Norge må etablere IKT-løsninger der autentiseringsmekanismene baserer seg på pålogging basert på sertifikater (PKI), dvs. sterk autentisering. Videre må vi sørge for at autentisert bruker basert på sertifikat anvendes i alle løsninger der det lovmessig er krav om logging av aktivitet.

Helse Midt-Norge har vedtatt en Strategi for identitets- og tilgangsstyring. Denne skal følges og handlingsplanen som er utarbeidet i strategiarbeidet må fullføres.

Innbyggertjenestene skal, så langt det er mulig, bruke autentisering gjennom HelseNorge.no portalen.

En ny Sikkerhetsplan, som nevnt i Figur 9, vil erstatte sikkerhetsstrategien fra 2010. Sikkerhetsplanens visjon er «Sikker tilgang til riktig informasjon, for riktig person, til riktig tid, hvor som helst fra, med hva som helst.».

Sammen med prinsippene for deling av informasjon framfor registrering flere steder (tjenesteorientering) og standardiserte tjenester for informasjonsutveksling (interoperabilitet) sikres konfidensialitet, integritet, tilgjengelighet og sporbarhet.

Bakgrunn:

Virksomhetsarkitekturen skal understøtte at alle interessenter (medarbeidere, pasienter, pårørende og publikum) får tilgang til den informasjonen de trenger på en effektiv, hensiktsmessig og forsvarlig måte.

Informasjonssikkerhet skal bidra til å ivareta pasientsikkerhet ved blant annet å

• sikre pasientinformasjon mot uautorisert innsyn, uautoriserte endringer og bortfall av tilgang for behandlere i behandlingssituasjonen

• sikre uavviselighet (ikke-benekting) ved signering

• sikre sporbarhet av handlinger

• sikre at informasjon blir presentert uten risiko for feiltolkninger og misforståelser

Gjennom dette skal det sikres at personvernet til den enkelte pasient ivaretas.

Informasjonssikkerheten skal også ivareta helsepersonellets personvern ved blant annet å

• verne ansatte mot urettferdig mistanke og beskyldninger om misbruk av informasjon gjennom å sikre sporbarhet av handlinger

• verne ansatte mot urettferdig mistanke og beskyldninger om ansvar for avvik ved å sikre uavviselighet (ikke-benekting) ved signering

Hvordan prinsippet skal følges:

Prinsippet skal følges ved å

• verifisere at Norm for informasjonssikkerhet, samt øvrige relevante lover og forskrifter etterleves

• sørge for tilgangsmekanismer som gjør at kun personer med tjenstlig behov kan få tilgang til helse‐ og personopplysninger

• gjennomgå kontrollmekanismene for sikring av pasientinformasjon både med tanke på konfidensialitet, tilgjengelighet, integritet, sporbarhet og kvalitet

• verifisere at relevante hendelser vil bli registrert i henhold til gjeldende regelverk

• kontrollere at identitetshåndteringen, både for brukere internt i en virksomhet, mellom virksomheter og for eksterne brukere, er tilfredsstillende for aktuelle bruksområder

3.2.6 Tilgjengelighet

«Alle aktuelle brukergrupper skal ha tilgang til nødvendig funksjonalitet og informasjon i rett form til rett tid og på rett sted.»(NIKT 6)

Hva kan dette prinsippet bety for Helse Midt-Norge?

Tilgang til informasjon i IKT-løsninger i Helse Midt-Norge må være basert på definerte rollebeskrivelser. Dette for å sikre at riktige personer får tilgang til riktig og nødvendig informasjon.

Når det gjelder tilgjengelighet til informasjon til rett tid finnes det ulike grader av tilgjengelighet til systemene i HMN (tjenestenivå). Grad av tilgjengelighet reguleres i avtaler mellom foretakene og Hemit som driftsleverandør. Det stilles store krav til hvordan infrastruktur og andre basistjenester må være utformet for å tilfredsstille 24*7 tilgjengelighet. Alle løsninger og alle tjenester med tilhørende komponenter skal leveres ihht avtalt tjenestenivå.

Bakgrunn:

Innenfor sektoren skal tilgjengelighetsprinsippet, når det foreligger et legitimt behov, sikre tilgjengelighet til funksjonalitet og informasjon uavhengig av tid og sted.

På et overordnet nivå omhandler prinsippet fleksibel tjenestetilgang med tanke på tid, sted og medium (kanal). Tjenester skal være tilgjengelige når det er behov for dem, de skal være enkle å finne og være tilgjengelige for aktuelle brukergrupper.

Hvordan prinsippet skal følges:

Prinsippet skal følges ved å

• sikre at aktørene har tilgang til tjenester ut fra tjenstlig behov

• utforme funksjonalitet og informasjon slik at det er mulig å utlevere eller gi tilgang til relevante helseopplysninger hjemlet i lovverket

• verifisere at tjenester er robuste, konsekvenser av mangel på tilgjengelighet er vurdert, og tiltak er innarbeidet

3.2.7 Brukskvalitet

«Virksomhetenes IKT-løsninger skal utformes på en måte som sikrer effektivitet og en god brukeropplevelse»(NIKT 7)

Hva kan dette prinsippet bety for Helse Midt-Norge?

I Helse Midt-Norge skal veilederen for utforming av brukerdialogen, GUI guiden, brukes ved etablering av nye systemer, samt tas hensyn til ved endringer på dagens systemer. Gjennom arkitekturpraksisen skal man også sikre tilstrekkelig dialog mellom de som skal utforme systemene og de som skal bruke systemene.

Bakgrunn:

En god brukeropplevelse oppnås gjennom høy brukskvalitet. Høy brukskvalitet i en IKT-løsning kjennetegnes ved at den er intuitiv, effektiv, har få feil, er feiltolerant, stabil og brukermotiverende.

Brukervennlige grensesnitt er viktig, men ikke tilstrekkelig. Løsningen må være lett å lære, og det må være enkelt å huske hvordan den skal brukes. IKT-løsninger må være fleksible og kunne tilpasses ulike brukssituasjoner, både med tanke på effektiv arbeidsflyt, type brukere, mobilitet, og enheten som blir brukt.

Høy brukskvalitet er viktig for at brukerne skal oppleve at IKT-løsningen støtter arbeidsoppgavene.

Hvordan prinsippet skal følges:

Prinsippet skal følges ved at

• etablerte standarder for brukskvalitet følges

• prinsipper for universell utforming skal følges

• brukere er sentrale ved utforming av behov og krav

• metoder og prinsipper for brukertesting følges

• brukergrensesnitt tilpasses brukskonteksten, brukergruppen, og oppgaven som skal løses

3.2.8 Endringsevne

«Virksomhetenes organisering, prosesser, IKT-løsninger, informasjon og teknologi skal utformes på en slik måte at de kan understøtte endringer, og ikke virke som begrensninger for endringer»(NIKT 8)

Hva kan dette prinsippet bety for Helse Midt-Norge?

Helse Midt-Norge må etablere og implementere arkitekturpraksisen som er beskrevet i kapittel 2. Dette vil bidra til å oppnå større fleksibilitet og endringsevne. Ved et tettere samarbeid om felles løsninger og arbeidsprosesser, vil vi få bedre kontroll på endringsprosessene i HMN. Dessuten skal etablert porteføljeprosess videreutvikles og brukes som et virkemiddel for å oppnå målsettingene for Helse Midt-Norge, se kapittel Feil! Fant ikke referansekilden..

Bakgrunn:

Spesialisthelsetjenesten er i kontinuerlig endring, som følge av endringer i lover og forskrifter, teknologiske nyvinninger, ny medisinsk kunnskap og behandlingsmuligheter, samt nye måter å organisere arbeidet på. Endringsevne skal imøtekomme behov for å gjøre endringer raskt og effektivt og gi lavere livsykluskostnader for IKT-løsninger.

Prinsippet skal gi trygghet for at eksisterende løsninger skal kunne tilpasses endringene.

Endringsevne omfatter også skalerbarhet, dvs. evne til å imøtekomme nye krav til bruksomfang, bruksmønstre og bruksvolum. Dette gjelder både opp- og nedskalering. Manglende evne til skalering kan gi overbelastning av tjenester eller unødvendig høy bruk av ressurser for å opprettholde tjenestetilbudet.

Hvordan prinsippet skal følges:

Prinsippet skal følges ved å

• utforme løsninger og tjenester med tanke på størst mulig grad av fremtidig fleksibilitet og gjenbruk

• sikre organisatorisk endringsevne ved å etablere rutiner og prosedyrer for f.eks. samordnet bruk av kodeverk fra nasjonale felleskomponenter

• sikre at løsninger kan skaleres både i antall tjenester, antall tjenestebrukere og informasjonsmengde som skal behandles

• identifisere forventede endringer i kapasitetsbehov og planlegge i forhold til disse

3.2.9 Informasjonsforvaltning

«Informasjon er en kritisk ressurs for virksomhetene og skal forvaltes deretter.»(NIKT 9)

Hva kan dette prinsippet bety for Helse Midt-Norge?

Helse Midt-Norge må etablere informasjonseiere for alle kritiske informasjonsobjekter samt rutiner for forvaltning av disse. Dette for å sikre at denne informasjonen er korrekt og tilgjengelig. Det må utarbeides en informasjonsmodell som tydelig beskriver hvilke systemer som er kilde for de ulike informasjonsobjekter. Alle systemer og integrasjoner må deretter forholde seg til dette.

Bakgrunn:

Oppdatert, korrekt og komplett informasjon er grunnlaget for effektive prosesser, vurderinger og beslutninger. Det er avgjørende for spesialisthelsetjenestens evne til å levere helsetjenester av høy kvalitet, samt å utføre øvrige pålagte oppgaver.

Hvordan prinsippet skal følges:

• Informasjon forvaltes i henhold til interne og eksterne krav og retningslinjer.

• Kritiske informasjonsobjekter i virksomheten skal ha en informasjonseier som er ansvarlig for at prinsippene etterleves.

• Informasjonseier må ha nødvendig myndighet og ressurser til å forvalte informasjonen de er ansvarlige for

• Tydelige rutiner for forvaltning av informasjon må etableres

4 Videre arbeid

Arkitekturmetodikken må videreutvikles og må inneholde verktøy (maler, etc.) for:

• hvordan forretningsarkitektur skal beskrives

• hvordan informasjonsmodellene skal dokumenteres

• hvilke applikasjonsmodeller som tjener hvilke formål

• beskrivelse av teknologiarkitektur/-modeller og formål

Arkitekturveiledere må utarbeides. Disse må dekke arkitekturdomenene:

• forretning

For eksempel beskrive hvordan og når de overordnede modellene skal tas fram og benyttes.

• informasjon

For eksempel beskrive hvordan informasjonsmodellene skal tas fram og benyttes.

• applikasjon

For eksempel beskrive hvordan applikasjonsmodellene skal tas fram og benyttes (dvs. beskrive arkitekturleveranser, gjerne i lys av faseinndelingen i TOGAF).

• teknologi

For eksempel beskrive hvordan teknologiarkitekturen skal beskrives.

Andre tiltak:

• Arkitekturpraksis og -metodikk må innarbeides i alle prosesser som medfører endringer i virksomheten og som involverer IKT.

• Kravbeskrivelse(r) og/eller implementasjonsguide(r) for applikasjoner i virksomheten. For eksempel beskrive krav til autentisering og autorisasjon og hvordan disse tjenestene skal brukes.

• Kravbeskrivelse(r) og/eller implementasjonsguide(r) for teknologidomenet.

Referanser

[1] Lankhorst et al., (2009). Enterprise Architecture at Work. Second Edition, e-ISBN 978-3-642-01310-2. Springer. S. 3. Tilgjengelig fra http://link.springer.com/content/pdf/10.1007%2F978-3-642-01310-2.pdf, hentet 21.10.2015.

[2] Nasjonal IKT. Tiltak 42.2: Praksis for virksomhetsarkitektur i Nasjonal IKT. Versjon 1.0, 25.03.2014. Tilgjengelig fra http://www.nasjonalikt.no/?module=Files&action=File.getFile&ID=570

[3] Nasjonal IKT Fagforum Arkitektur sin Wiki. Tilgjengelig fra http://helsewiki-prod.cust.seria.no/wiki/, hentet 26.10.2015.

[4] Nasjonal IKT. Tiltak 12: Tjenesteorientert arkitektur i spesialisthelsetjenesten, hovedrapport. Versjon 1.0e, 13.10.2008. Tilgjengelig fra http://www.nasjonalikt.no/?module=Files&action=File.getFile&ID=370

Informasjonsmodell: http://helsewiki-prod.cust.seria.no/wiki/index.php/Informasjonsmodell

[5] Nasjonal IKT. Tiltak 42: Videreutvikling av spesialisthelsetjenestens virksomhetsarkitektur. Versjon 1, 31.12.2011. Tilgjengelig fra http://www.nasjonalikt.no/?module=Files&action=File.getFile&ID=436

[6] Helse- og omsorgsdepartementet. Forskrift om IKT-standarder i helse- og omsorgstjenesten. Lovdata. FOR-2015-07-01-853. Tilgjengelig fra https://lovdata.no/dokument/SF/forskrift/2015-07-01-853?q=IKT-standarder, hentet 14.10.2015.

[7] Direktoratet for e-helse. Referansekatalog over IKT-standarder i helse- og omsorgstjenesten. Høring 2015. Tilgjengelig fra https://ehelse.no/standarder-kodeverk-og-referansekatalog/referansekatalogen, hentet 14.10.2015.

[8] Direktoratet for e-helse (tidligere Helsedirektoratet). Standarder, kodeverk og referansekatalog. Tilgjengelig fra https://ehelse.no/Standarder-kodeverk-og-referansekatalog, hentet 14.10.2015.

[9] HL7 Norge. Velkommen til HL7 Norge. Tilgjengelig fra http://www.hl7.no/ , hentet 14.10.2015

[10] David Loshin, 2010. Master data management. (bok) Morgan Kaufmann.

[11] Rannveig Woll, 2012. Finnes forløp i helsedata? Master oppgave NTNU. Tilgjengelig fra http://urn.kb.se/resolve?urn=urn:nbn:no:ntnu:diva-20663

[12] Hemit, 2010. Teknologistrategi Helse Midt-Norge. Tilgjengelig fra Hemits EQS https://eqs.helse-midt.no/cgi-bin/document.pl?pid=hemit&DocumentID=1995#_Toc278265503

[13] Hemit, 2012. Strategi for identitets- og tilgangsstyring. Tilgjengelig fra Hemits EQS https://eqs.helse-midt.no/cgi-bin/document.pl?pid=hemit&DocumentID=2278

Figurliste

Figur 1 Beskrivelser i ulike arkitekturdomener og sammenhengen mellom dem... 9

Figur 2 Arkitekturpraksis, (TOGAF Architecture Capability Overview ,oversatt og tilpasset til HMN) 14

Figur 3 Organisering av arkitekturfunksjonene fram til og med 2019.. 17

Figur 4 Arkitekturpraksisens nivå og roller. 18

Figur 5 Samspill mellom virksomhetsarkitektur og øvrige prosesser. 22

Figur 6 Resultat av samspill med strategisk planlegging. 23

Figur 7 Porteføljestyring i HMN.. 24

Figur 8 Arkitekturpraksisens bidrag i prosjekter. 26

Figur 9 Forhold til andre dokumenter og premissgivere. 29

Figur 10 Kapabilitetsmodell for spesialisthelsetjenesten (Helse Vest). 49

Figur 11 Kapabilitetsmodell fra Helsedirektoratet, "en innbygger - en journal". 51

Figur 12 Prosessmodell - Innbyggersentrisk prosessmodell for helsetjenesten.. 53

Figur 13 Spesialisthelsetjenestens tjenestekatalog. 57

Figur 14 Ulike nivå av modeller i en informasjonsarkitektur og sammenhengen mellom dem... 61

Figur 15 Overordnet informasjonsmodell innen området pasientbehandling. 62

Figur 16 Dataentiteter innen området forskning. 63

Figur 17 Dataentiteter innen området utdanning av helsepersonell 63

Figur 18 Tabellen viser en mapping mellom informasjonsmodell og tjenestemodell 67

Figur 19 Applikasjonsmodell for spesialisthelsetjenesten(NIKT). 70

Figur 20 Applikasjonsmodell med applikasjoner i HMN.. 70

Figur 21 Eksempel på en logisk modell for tjenesteorientert arkitektur. 72

Figur 22 Eksempel på referansemodell fra det nasjonale DIS-prosjektet. 73

Figur 23 TOGAF TRM (Technical Reference Model). 76

Figur 24 Samsvar i og mellom arkitekturdomener. 79

Figur 25 Arkitekturarbeid i en endringsprosess. 81

Figur 26 Virksomhetsarkitekturens overordnede virkemidler på ulike styringsnivå. 82

5 Vedlegg

5.1 Beskrivelser av virksomheten

$Beskrivelse: H:\Arkitekturplan\Headspin\grafiske figurer\jpgs\figur1.jpg$ Det er en etablert praksis innen fagområdet virksomhetsarkitektur å beskrive virksomheten ut i fra fire arkitekturdomener:

• Forretningsdomenet[13] (virksomhetsdomenet)

• Informasjonsdomenet

• Applikasjonsdomenet

• Teknologidomenet

Se Feil! Fant ikke referansekilden. og kapittel Feil! Fant ikke referansekilden. for beskrivelse av hvert domene. Begrepene arkitekturdomene og arkitekturlag brukes synonymt.

Dette kapittelet henvender seg til lesere med en viss bakgrunn og forståelse for fagfeltet virksomhetsarkitektur. Kapittel 2 beskriver virksomhetsarkitektens tilnærming i en endringsprosess, og dette kapittelet sier noe om hvilke beskrivelser som er nødvendige, hvordan de deles inn, om ulike abstraksjonsnivå og hvilke modeller som finnes. Kapittel 5.6 utdyper sammenhengen mellom domene og kapittel 5.7 utdyper arkitekturpraksisen i en endringsprosess.

Krav til applikasjoner eller tekniske løsninger ved utvikling eller anskaffelse, inngår ikke i Arkitekturplanen.

5.2 Innledning

Arkitekturplanen benytter begrepet virksomhetsarkitektur både om resultat og om prosesser og virkemidler frem til et resultat. Prosesser og virkemidler inngår i arkitekturpraksisen og er beskrevet i foregående kapitler. Som beskrevet i kapittel Feil! Fant ikke referansekilden. omfatter virksomhetsarkitektur alle fire domener i virksomheten. Dette kapittelet omhandler hva slags beskrivelser som må utarbeides for hvert domene, både oversikter, detaljbeskrivelser og hvordan de er avhengig av hverandre. I beskrivelsene benyttes ofte modeller som en forenklet eller avgrenset representasjon av virkeligheten (abstraksjon). Et av virksomhetsarkitekturens verdibidrag er å se helhet og sikre konsistens, og samtidig bidra til standardisering og gjenbruk.

Sammenhengen mellom beskrivelser- og modeller i de ulike domenene er like viktige som beskrivelsene innen hvert domene. Ofte er det nødvendig med beskrivelser på alle domener for å kunne gjennomføre en endring i virksomheten som involverer bruk av IKT.

Ulike typer modeller i virksomhetsarkitekturen blir beskrevet under de respektive arkitekturdomenene.

Gjennom Helseplattformen, pågående program i HMN, vil det bli utarbeidet føringer for virksomhetsarkitekturen, i form av modeller og beskrivelser (designorienterte virkemidler). Eksempler er prosessmodeller, applikasjonslandskap og informasjonsmodeller.

5.2.1 Arkitekturverktøy og arkitekturbibliotek

Helse Midt-Norge benytter Mega som arkitekturverktøy og arkitekturbibliotek. Arkitekturmodeller og -beskrivelser publiseres på intranettet i Brobygger’n[14] og er derfra tilgjengelig for alle ansatte i Helse Midt-Norge.

De andre helseregionene benytter andre arkitekturverktøy enn HMN. NIKT har pekt på behovet for en felles metamodell for å kunne utveksle modeller mellom regionene, men en slik er foreløpig ikke etablert. I nasjonale prosjekter for spesialisthelsetjenesten anbefaler NIKT at prosjektet velger det verktøyet blant de som brukes i helseregionene, som passer formålet best. Modeller fra ulike regioner og prosjekter kan derfor se forskjellig ut.

Arkitekturbiblioteket bygges opp gradvis, gjennom at prosjekter gjenbruker, forbedrer og tar fram nye arkitekturbeskrivelser og - modeller for deler av virksomheten. Dette danner grunnlag for standardisering, harmonisering, kommunikasjon og gjenbruk. Målet er at arkitekturbiblioteket skal ha tilstrekkelige beskrivelser av virksomheten til at det gir et godt utgangspunkt for å gjennomføre endringer. Det er utarbeidet en egen veileder for bruk av Mega[15].

Nasjonal IKTs Fagforum Arkitektur har etablert HelseWiki, deres egen WiKi for «(..) samhandling rundt virksomhetsarkitektur og retningslinjer for bruk av virksomhetsarkitektur(…)». I teksten refereres det til modeller og informasjon som kan finnes på HelseWiki, med lenker for direkte oppslag.

5.3 Forretning

Forretningsdomenet beskriver selve virksomheten(forretningen) i Helse Midt-Norge, dvs. inneholder beskrivelser av spesialisthelsetjenesten som utføres i Helse Midt-Norge.

Typiske beskrivelser i dette domenet er:

• hvilke kapabiliteter* som utføres i Helse Midt-Norge og i de ulike HF-ene, sykehusene, klinikkene og avdelingene

• hvilke helsetjenester som utføres i Helse Midt-Norge, mot innbygger og internt

• hvilke virksomhetsprosesser som HMN kjører

• hvordan HMN er organisert på ulike nivå

• hvem som utfører hvilke tjenester og prosesser

*En kapabilitet kan beskrives som følger[16]:

En kapabilitet er en evne et foretak innehar, må inneha eller benytter for å utføre sine oppgaver og oppnå sine mål.

Den beskriver hva et foretak må være i stand til for å skape verdi for kunder og interessenter, men gir ingen detaljer om hvordan oppnå dette.

En kapabilitet omfatter mennesker, prosesser, tjenester, informasjon og teknologi.

Ulike kapabiliteter samspiller typisk gjennom prosesser som går på tvers av disse.

5.3.1 Overordnede modeller

For å kunne gjennomføre endringer i en virksomhet, med minst mulig risiko for feil og uønskede virkninger, er det nødvendig å ha gode beskrivelser av virksomheten. Overordnede virksomhetsmodeller for forretningen er nyttige som et startpunkt for disse beskrivelsene og for å gi en rask innføring i hvilke oppgaver virksomheten utfører, på hvilken måte den utfører dem, og hvilke tjenester den tilbyr og benytter.

Virksomhetsmodellene er oversiktskart over virksomheten, med ulike formål (ulike perspektiver). Størst nytte har nasjonale, eller enda bedre internasjonale, virksomhetsmodeller. Nasjonale/internasjonale modeller gjør det enklere å sammenligne og diskutere på tvers, og det støtter også oppunder at helsetjenestene i Norge (og internasjonalt), på overordnet nivå, utfører de samme oppgavene og tilbyr de samme tjenestene.

Ofte har helsetjenesten selv, gjennom ulike organisasjonsutviklingsaktiviteter, kvalitetssikringsarbeid og IKT-prosjekter, utarbeidet beskrivelser av forretningen på detaljert nivå, for eksempel arbeidsflyt for et gitt område eller organisasjonskart for en klinikk, mens det mangler overordnede modeller.

Det kan være hensiktsmessig med følgende overordnede modeller som brukes til ulike formål:

1. Kapabilitetsmodell
Beskriver hvilke evner helsetjenesten må ha for å kunne utføre sine oppgaver.
Eksempel på bruksområder: Avdekke mangler i strategi. Bidra til å balansere prosjektportefølje mot strategi. Bidra til å avdekke mangler i applikasjonsportefølje. Beskrive omfang for anskaffelser (for eksempel hvilke kapabiliteter skal løsningen som anskaffes ha funksjonalitet for å understøtte). Se kapittel 5.3.1.1 for en beskrivelse av eksisterende kapabilitetsmodeller.

2. Prosessmodell
Beskriver hvilke prosesser som helsetjenesten og pasienten/innbyggeren inngår i og benytter. Kan benyttes som en inngangsport til hvordan helsetjenesten jobber.
Eksempel på bruksområder: Utgangspunkt for diskusjon rundt forbedring av prosesser, effektivisering av helsetjenestene og arbeidsflyten. Startpunkt og gruppering av mer detaljerte prosesser. Se kapittel 5.3.1.2 for en beskrivelse av eksisterende prosessmodell.

3. Tjenestemodell
Beskriver hvilke virksomhetsnære tjenester spesialisthelsetjenesten tilbyr og benytter (dvs. forretningstjenestene i spesialisthelsetjenesten). Eksempel på bruksområder: Gi oversikt over hvilke tjenester virksomheten tilbyr og benytter. Dette kan for eksempel være nyttig ved diskusjoner rundt funksjonsfordeling og spesialisering. Modellen kan også brukes til å vise sammenheng mellom forretningstjenester og IKT-tjenester/funksjonalitet. Se kapittel 5.3.1.3 for en beskrivelse av eksisterende tjenestemodell.

4. Organisasjonsmodeller og -kart
Typisk har alle deler av spesialisthelsetjenesten (HF, sykehus, klinikk, avdelinger) utarbeidet organisasjonskart som beskriver hvordan deres del av virksomheten er organisert. Dette er konkrete beskrivelser av virksomheten og ikke en overordnet modell. Det kan i enkelte tilfeller vært nyttig med en organisasjonsmodell over helsetjenesten på overordnet nivå, for eksempel for å etablere felles begrepsapparat for de ulike delene av organisasjonen og dermed forenkle kvalitetssikring, sammenligning og rapportering.

Internasjonalt fins det ikke mange overordnede modeller selv om for eksempel «The OpenGroup» har etablert et «HealthForum» som forventes å ta fram noen modeller. I tillegg har APQC, en amerikansk medlemsbasert benchmarking-organisasjon definert en prosessmodell primært for sykehus, «APQC Process Classification Framework - Healthcare Provider».

I Norge er det tatt fram noen modeller i ulike sammenhenger, men det er få omforente modeller. Etterfølgende kapitler omtaler hva som finnes av modeller som kan benyttes til ulike formål i HMN.

5.3.1.1 Kapabilitetsmodell

En kapabilitetsmodell beskriver alle kapabilitetene som en virksomhet innehar. Som det framgår av definisjonen av en kapabilitet, sier ikke kapabilitetsmodellen noe om hvordan helsetjenestene gjennomføres (prosesser) eller hvordan helsetjenesten er organisert (organisasjonskart).

I en kapabilitetsmodell er kapabilitetene gruppert i forhold til hvilken rolle de spiller i tjenesten.

Helse Vest (HV) har med utgangspunkt i en prosessmodell fra Helse Sør-Øst utarbeidet en kapabilitetsmodell for spesialisthelsetjenesten, se Figur 10. Den samme HSØ prosessmodellen har også vært utgangspunktet for HMNs prosessmodell som er beskrevet i kapittel 5.3.1.2. NIKT har en uttalt ambisjon om at denne modellen skal gjøres nasjonal for spesialisthelsetjenesten. HMN har benyttet HV-modellen i «Forprosjekt Pasientbehandling og samhandling», med deltagelse fra et stort antall klinikere, og fått bekreftet at den fungerer greit også for kommunehelsetjenesten.

Figur 10 Kapabilitetsmodell for spesialisthelsetjenesten (Helse Vest)[17]

Helsides figur finnes i Vedlegg.

Følgende grupper er definert i kapabilitetsmodellen i figuren over.

• Styring og retning: Disse kapabilitetene ivaretar interne og eksterne drivere, og gir retning for planlegging og endring, slik at utvikling av virksomheten skjer i tråd med driverne.

• Kjernevirksomhet: Disse kapabilitetene omhandler kjernen av virksomheten og omfatter pasientbehandling, forskning, utdanning og opplæring.

• Medisinsk service: Disse kapabilitetene er direkte understøttende og tett knyttet til kjernevirksomheten.

• Støtte: Disse kapabilitetene er ikke unike for sektoren eller kjernevirksomheten og skal sikre en stabil og velfungerende daglig drift.

Helsedirektoratet har i utredningen «En innbygger – en journal» videreutviklet kapabilitetsmodellen slik at den dekker hele helsetjenesten, dvs. både spesialist- og kommunehelsetjeneste, inkludert fastleger, se Figur 11 under. HMN programmet Helseplattformen har derfor valgt å bruke denne modellen for å beskrive omfang.

Figur 11 Kapabilitetsmodell fra Helsedirektoratet, "en innbygger - en journal"

Helsides figur finnes i Vedlegg.

Helse- og omsorgssektorens kapabilitetsmodell består av de samme fire hovedområdene som spesialisthelsetjenesten, og er nesten likt beskrevet:

• Styring og retning. Disse kapabilitetene responderer til interne og eksterne drivere, og gir rammer og retning for planlegging og endring slik at utvikling av helse- og omsorgstjenestene skjer innenfor og i tråd med disse.

• Kjernevirksomhet. Disse kapabilitetene er spesifikke for sektorens evne til å yte helsehjelp.

• Medisinsk service. Disse kapabilitetene er direkte muliggjørende for, og dermed tett knyttet til, kjernevirksomheten.

• Fasilitering. Disse kapabilitetene skal understøtte kjernevirksomheten og sikre en stabil og velfungerende daglig drift. Som det fremgår i de mer detaljerte beskrivelsene er enkelte kapabiliteter, som velferdsstøtte, plassert i denne grupperingen. Når det gjelder omsorgstjenester i kommunen er enkelte av disse kapabilitetene en del av primæroppgavene.

Detaljert beskrivelse av hver kapabilitet finnes i representasjonen av modellen i HMNs arkitekturbibliotek.

Modellen fra Helsedirektoratet, som inkluderer kommunehelsetjenesten, er tatt i bruk for Helseplattformen og er den prefererte modellen for HMN. Helse Vest modellen blir sannsynligvis felles modell for spesialisthelestjenesten.

5.3.1.2 Prosessmodell

En overordnet prosessmodell for spesialisthelsetjenesten gir en helhetlig oversikt over virksomhetens hovedoppgaver på et overordnet nivå. En slik modell fremstiller overordnede virksomhetsprosesser og fungerer som en inngangsport til hvordan virksomheten løser sine oppgaver, i form av beskrevne arbeidsprosesser.

Det finnes foreløpig ikke en felles nasjonal prosessmodell for spesialisthelsetjenesten, men et eksempel på en slik modell ble utviklet av HMN i «Forprosjekt pasientbehandling og samhandling». Denne modellen viser helsetjenestens hovedoppgaver (kjerneprosesser). I tillegg setter den innbyggeren i sentrum. For denne modellen er det tatt utgangspunkt i en prosessmodell utarbeidet av Helse Sør-Øst (HSØ). Deretter ble modellen tilpasset slik at den er dekkende for kommunehelsetjenesten.

Det overordnede målet med modellen (Figur 12) er å beskrive en helsetjeneste som gjør innbyggeren best mulig i stand til å ivareta egen helse og som medvirker til at innbyggeren blir en likeverdig og medvirkende aktør i de ulike prosessene mellom innbyggeren og helsetjenesten.

Modellen skiller ikke mellom ulike nivå i helsetjenesten (spesialist, primær), men beskriver en sømløs helsetjeneste der innbyggeren får dekket sine helsemessige behov, på det nivå behovet kan møtes. Den innbyggersentriske prosessmodellen er en syklisk modell der innbyggeren kan befinne seg hvor som helst i modellen, og i ulike prosesser samtidig. Innbyggeren kan for eksempel ivareta egen helse etter tidligere sykdom, samtidig som han er under utredning for en annen tilstand.

Den innbyggersentriske prosessmodellen viser hvordan vi ønsker å tilby helsetjenester i Midt-Norge. Den viser innbyggerens kontakt med helsetjenesten, basert på de behov han til enhver tid har, i forhold til egen helse. I tillegg viser modellen hvordan innbyggeren kan ivareta egen helse med eventuell støtte fra helsetjenesten.

Utredning Opprette kontakt mellom innbygger og helsetjenesten Ivareta helse Behandling

Figur 12 Prosessmodell - Innbyggersentrisk prosessmodell for helsetjenesten

Helsides figur finnes i Vedlegg.

Forklaring til modellen: I sirkelen er prosessene vist i prosesspar der innbyggerens prosess er vist i den innerste sirkelen, mens tilhørende prosess for helsetjenesten er vist i den ytterste sirkelen. For eksempel utgjør innbyggerens prosess «Kontakt helsetjeneste» et prosesspar sammen med helsetjenestens «Møt helsetjenestebehov». For å gjennomføre helsetjenestens prosesser trengs et ekstra sett med prosesser som er beskrevet i firkanten «Muliggjøre helsetjeneste». Disse prosessene har ikke et direkte grensesnitt mot innbyggerens prosesser. En lesbar versjon av prosessmodellen finnes på Brobygger’n, under Prosessoversikt[18].

Kontakt med helsetjenesten er delt i fire prosesspar og beskrevet som følger:

Prosess	Prosesspar og beskrivelse
Ivareta helse	Håndter egen helse/Forebygg sykdom og vedlikehold helse Innbyggeren har store muligheter til forebygging, rehabilitering og egenterapi som i dag i for liten grad blir utnyttet. Ved å følge veiledning fra helsetjenesten, egenmonitorering samt opprettholdelse av funksjon, skal innbyggeren sikre best mulig grunnlag for å kunne ivareta egen helse. Helsetjenesten skal støtte innbyggerne ved å monitorere og identifisere risiko for sykdom, samt tilby forebyggende helsearbeid både på individnivå og på befolkningsnivå.
Opprette kontakt mellom innbygger og helsetjenesten	Kontakt helsetjeneste/Møt helsetjenestebehov Her opprettes kontakt mellom innbygger og helsetjenesten grunnet et helsemessig behov. Innbyggeren skal på en enkel måte kunne etablere kontakt og presentere sine behov til helsetjenesten, som på sin side sammen med innbyggeren raskt skal kunne avklare behov, fastslå videre alternativer samt fastslå hvilket kompetansenivå innen helsetjenesten innbyggeren har behov for. Innbyggeren kan enten gå tilbake til egenomsorg, eller gå videre i modellen til utredning.
Utredning	Delta i utredning/Utred Innbyggeren deltar aktivt i utredning. Helsetjenesten vurderer årsak til helsetjenestebehov, basert på tilgjengelig kunnskap, og identifiserer mulige behandlingsalternativ. Sammen med innbyggeren velges og planlegges så videre behandling.
Behandling	Delta i behandling/Behandle Innbyggeren mottar valgt og planlagt behandling. Helsetjenesten gjennomfører behandlingen. Sammen med innbyggeren evalueres behandlingen og oppfølgning planlegges. Helsetjenesten skal evaluere sluttresultatet av behandlingen opp mot kunnskapsgrunnlaget, benyttet ved valg av behandling. Helsetjenesten skal gi veiledning slik at innbyggeren har godt grunnlag til å kunne ivareta egen helse.

Prosess

Prosesspar og beskrivelse

Ivareta helse

Håndter egen helse/Forebygg sykdom og vedlikehold helse

Innbyggeren har store muligheter til forebygging, rehabilitering og egenterapi som i dag i for liten grad blir utnyttet. Ved å følge veiledning fra helsetjenesten, egenmonitorering samt opprettholdelse av funksjon, skal innbyggeren sikre best mulig grunnlag for å kunne ivareta egen helse. Helsetjenesten skal støtte innbyggerne ved å monitorere og identifisere risiko for sykdom, samt tilby forebyggende helsearbeid både på individnivå og på befolkningsnivå.

Opprette kontakt mellom innbygger og helsetjenesten

Kontakt helsetjeneste/Møt helsetjenestebehov

Her opprettes kontakt mellom innbygger og helsetjenesten grunnet et helsemessig behov.

Innbyggeren skal på en enkel måte kunne etablere kontakt og presentere sine behov til helsetjenesten, som på sin side sammen med innbyggeren raskt skal kunne avklare behov, fastslå videre alternativer samt fastslå hvilket kompetansenivå innen helsetjenesten innbyggeren har behov for. Innbyggeren kan enten gå tilbake til egenomsorg, eller gå videre i modellen til utredning.

Utredning

Delta i utredning/Utred

Innbyggeren deltar aktivt i utredning. Helsetjenesten vurderer årsak til helsetjenestebehov, basert på tilgjengelig kunnskap, og identifiserer mulige behandlingsalternativ. Sammen med innbyggeren velges og planlegges så videre behandling.

Behandling

Delta i behandling/Behandle

Innbyggeren mottar valgt og planlagt behandling. Helsetjenesten gjennomfører behandlingen. Sammen med innbyggeren evalueres behandlingen og oppfølgning planlegges. Helsetjenesten skal evaluere sluttresultatet av behandlingen opp mot kunnskapsgrunnlaget, benyttet ved valg av behandling. Helsetjenesten skal gi veiledning slik at innbyggeren har godt grunnlag til å kunne ivareta egen helse.

For å muliggjøre og understøtte den innbyggersentriske prosessmodellen er følgende prosesser identifisert (ikke utfyllende):

Muliggjøre helsetjeneste (støtteprosesser)
Distribuer kunnskap	Kunnskapsgrunnlaget for utøvelse av helsetjeneste er i kontinuerlig utvikling. For at helsetjenesten skal være kunnskapsbasert må kunnskap distribueres effektivt innen helsetjenesten og til innbyggeren.
Grunn-, videre- og etterutdanning av helsepersonell	Utøvelse av helsehjelp krever kompetanse hos helsepersonell. Kunnskapsgrunnlaget innen helsetjenesten er i stadig utvikling, og det stilles derfor krav til utdanning på alle nivå.
Levere kliniske støttefunksjoner	Utredning, behandling og oppfølgning av innbyggeren er avhengig av en rekke kliniske støttefunksjoner som billeddiagnostikk, klinisk kjemi, mikrobiologi og en lang rekke støttefag.
Utvikle ny kunnskap	En effektiv og kunnskapsbasert helsetjeneste skal være dynamisk og generere ny kunnskap basert på egen praksis og resultater.
Led helsetjenesteorganisasjoner	Helsetjenesten er sammensatt av ulike organisasjoner som alle krever ledelse.
Legg til rette for praktisk helsehjelp	Helsetjenesten representerer mange fagområder og helsepersonell. Mange innbyggere er i kontakt med helsetjeneste. Logistiske prosesser er derfor nødvendig for å ha en effektiv helsetjeneste. Dette gjelder planlegging av ressurser som rom, senger, diagnostisk utstyr og personell. Innbyggeren som har behov for helsetjeneste vil også kunne ha behov for transport og forflytning.

I utredningen «Én innbygger – én journal» har Helsedirektoratet utarbeidet en prosessmodell for hele helsetjenesten. Modellen ligger tett opptil HMNs prosessmodell. Se prosjektrapporten[19] for en beskrivelse av denne modellen.

5.3.1.3 Tjenestemodell

NIKT utarbeidet i 2008 en tjenestemodell for spesialisthelsetjenesten i «Tiltak 12 – Tjenesteorientert arkitektur for spesialisthelsetjenesten», Figur 13. Denne ble komplettert med tjenester for opplæring, utdanning og forskning gjennom «Tiltak 42, Videreutvikling av spesialisthelsetjenestens virksomhetsarkitektur». Grunnmodellen, Pasientbehandling, har ikke vært revidert siden 2008, og NIKT har erkjent at det er behov for revisjon, og vil sannsynligvis se dette i sammenheng med å etablere en felles kapabilitetsmodell for spesialisthelsetjenesten.

Figur 13 Spesialisthelsetjenestens tjenestekatalog

Lesbar og klikkbar versjon av tjenestekatalogen finnes på HelseWiki[20] under forretningsarkitektur/forretningstjenester. Beskrivelser for de enkelte tjenestene fås ved å klikke i modellen.

Hovedområdene innenfor pasientbehandling består av tre grupper med noe ulikt fokus. Kommunikasjonstjenester, Logistikk- og ressurshåndteringstjenester, og Informasjonslogistikktjenester handler i stor grad om å håndtere informasjon og den administrative siden av de pasientrettede prosessene i spesialisthelsetjenesten. Kommunikasjonstjenester «produserer» selv i liten grad innholdet av tjenesten, men benyttes for å presentere resultater og håndtere forespørsler til og fra andre tjenester. Tjenestene er ikke fysiske i den forstand at det utøves fysiske handlinger, men konsentrert rundt data og informasjonsutveksling.

Ikke-medisinske tjenester og Kliniske tjenester representerer de fysiske tjenestene som ytes av spesialisthelsetjenesten. Felles for disse tjenestene er at de i all hovedsak håndterer tjenestebestilling direkte. For eksempel skjer bestilling av en blodprøve direkte mot prøveanalyse, som igjen enten benytter prøvetakning (uavhengig av hvem som utfører denne) og merking, preparering og pakking for å få tilgang på blodet som skal analyseres. Imidlertid finnes det unntak, der tjenestene benytter ressurser som er så knappe at de må «rasjoneres». Dette gjelder typisk varige ressurser som for eksempel operasjonssaler, avansert medisinsk utstyr etc. Bestillingen må da behandles gjennom planlegging av ressurser.

Området for Fagstøtte inneholder de tjenestene som understøtter arbeidsprosessene i virksomheten og bidrar til å øke kvaliteten i øvrige tjenester.

Modellen viser i tillegg et område kalt «øvrige tjenester». Fokus i modellen har vært på kjernevirksomheten, pasientbehandling. Identifiserte tjenester i andre områder er lagt i «Øvrige tjenester».

5.3.1.4 Funksjonalitetskatalog

NIKT Fagforum Arkitektur har erkjent at det er behov for en felles funksjonalitetsmodell eller –katalog som beskriver hvilken funksjonalitet som er nødvendig for å understøtte helsetjenesten.

Formålet med en slik katalog/modell er blant annet:

- Felles begrepsapparat for funksjonalitet

- Avdekke funksjonell redundans i applikasjonsporteføljen

- Bidra til å identifisere og beskrive fremtidig IKT-støtte

- Understøtte anskaffelser regionalt og nasjonalt

Det pågår et analysearbeid i NIKT for å utarbeide en funksjonalitetskatalog for spesialisthelsetjenesten som forventes å bli tilgjengelig i første versjon i løpet av 2016.

HMN programmet Helseplattformen bidrar inn i arbeidet og ser på hvordan en slik katalog kan benyttes i programmet.

5.3.2 Standarder

Helse Midt-Norge skal forholde seg til internasjonale og nasjonale standarder som er vedtatt.

Standarder for beskrivelse av prosesser

Ved modellering av prosesser og tjenester er det en stor fordel med et felles språk (notasjon) for å sikre felles forståelse og muligheter for gjenbruk av prosesser og tjenester, både lokalt og nasjonalt. Det er også lagt vekt på at arkitekturbeskrivelsen skal være så fleksibel som mulig med hensyn til endringer, og et av virkemidlene for å oppnå dette er å innføre en standardisert notasjon som støtter modellering av tjenester og arbeidsflyt.

For å dokumentere og optimalisere virksomhetsprosesser og relaterte ressurser er det behov for et godt verktøy for prosessmodellering. Business Process Management Initiative (BPMI) i Object Management Group (OMG), et internasjonalt standardiseringsorgan for IT-bransjen, har utviklet Business Process Modeling Notation (BPMN) som er et grafisk modelleringsspråk for modellering av forretningsprosesser. Bruk av BPMN virksomhetsprosess diagram bidrar til å bedre kommunikasjonen mellom virksomhet og IT. BPMN er rettet mot brukere, leverandører og tjenesteleverandører som trenger å kommunisere virksomhetsprosesser på en standardisert måte. BPMN er anbefalt notasjon fra NIKT.

Les mer om prosesser i spesialisthelsetjenesten på HelseWiki[21].

Standarder som regulerer hvordan virksomheten operer

Det finnes standarder for hvordan virksomheten opererer, for eksempel for apotek- og laboratorievirksomhet som må tas hensyn til i arkitekturarbeidet[22]. Eksempel: NS-EN ISO 15189:2012 Medisinske laboratoriet – Krav til kvalitet og kompetanse.

I arkitekturarbeidet er det viktig å ha kjennskap til at det finnes nasjonale og regionale retningslinjer for standardiserte pasientforløp. Pakkeforløp kreft er eksempel på nasjonale standardiserte pasientforløp.

Føringer for pasientrettede portalløsninger

Nasjonale føringer er at Helsenorge.no skal være portal for elektroniske offentlige tjenester i helsesektoren, og for individrettede helsetjenester (for eksempel timebestilling).

5.3.3 Hvordan beskrive forretningsarkitekturen

Som nevnt tidligere er spesialisthelsetjenesten kompleks og det kan være variasjoner i måten man organiserer arbeidet på. Det vil være utfordrende og tidkrevende å utforme generiske prosesser som er gyldige (og gode) for alle deler av organisasjonen og for alle fagfelt. Når endringsarbeid settes i gang er det derfor nødvendig å finne riktig abstraksjonsnivå og riktig perspektiv for det arbeidet som skal gjøres. De arkitekturmodellene som utarbeides må relateres til de overordnede modellene.

Aktuelle beskrivelser av virksomhetsprosesser:

• En konseptuell eller generisk beskrivelse av en prosess på et høyt abstraksjonsnivå uten å ta med organisasjonen eller hvilke deler av organisasjonen som er involvert i prosessen.

• En detaljert beskrivelse av en arbeidsprosess ned til aktiviteter og hvilke roller i organisasjonen som utfører aktivitetene.

• En beskrivelse av en prosess hvor både eksterne og interne organisasjoner eller aktører en involvert.

• En detaljert beskrivelse av en arbeidsprosess beriket med behov for IKT-støtte (funksjonalitet) og informasjonsutveksling mellom aktivitetene.

• En detaljert beskrivelse av en arbeidsprosess beriket med hvilken applikasjon/IT-system som benyttes i aktivitetene.

Dette er kun eksempler og de nevnte elementene kan kombineres i samme beskrivelse. Det er heller ikke en uttømmende liste over elementer som kan være med i en prosessbeskrivelse. Det må arbeides videre med metodikk og veiledere.

Kobling mot de øvrige arkitekturdomenene (kun eksempler):

Applikasjon: Prosessbeskrivelser som viser hvilke funksjonaliteter det er behov for i prosessen kan sammenstilles med en arkitekturmodell som viser funksjonaliteten som tilbys av en applikasjon og vise

a) at en ny rolle eller del av organisasjonen trenger tilgang til en applikasjon

b) hvem som blir påvirket av en endring i en applikasjon

c) behov for endringer i en applikasjon hvis en prosess endres

Informasjon: Prosessbeskrivelser som viser informasjon som utveksles kan sammenstilles med informasjonsmodeller og vise

a) hvor informasjon blir brukt og eventuelt endret

b) hvilke prosesser eller deler av organisasjonen som blir berørt ved en endring av informasjonsmodellen

5.4 Informasjon

Informasjonsarkitektur er beskrivelsen av informasjon og sammenhengen mellom informasjon, informasjonskildene og forbrukerne av informasjon. Formålet med arkitekturen er å sikre god kvalitet og kostnadseffektiv informasjonsforvaltning på tvers av foretak, prosesser og systemer. Standardisering av informasjon, f.eks. gjennom felles grensesnitt og kodeverk, er en del av informasjonsarkitekturen, og er særlig viktig med tanke på samhandling både internt og eksternt.

I beskrivelsen av arkitekturen er det praktisk med deling på forskjellige abstraksjonsnivå, der man har enkle modeller rundt sentrale begrep på overordnet nivå, og mer detaljerte logiske og operasjonelle (fysiske) modeller for kravstilling, design og teknisk implementering.

Figur 14 illustrerer sammenhengen mellom de ulike nivåene av modeller i en informasjonsarkitektur.

Figur 14 Ulike nivå av modeller i en informasjonsarkitektur og sammenhengen mellom dem

Informasjonsmodellene kan fungere som bindeledd mellom modeller som beskriver virksomheten og applikasjonsmodeller med samme detaljeringsgrad. For eksempel kan modeller for arbeidsprosesser på et logisk nivå (forretning) vise informasjon som inngår i arbeidsflyten, mens applikasjonsmodeller viser informasjon som kommuniseres internt, i eller mellom applikasjoner. Applikasjonsmodeller kan også vise hvor informasjon lagres eller hvilken applikasjon som eier informasjonen. Ved å benytte standardiserte begrep og ved å se modeller i sammenheng er det mulig å sikre semantisk interoperabilitet.

Informasjonsmodeller på operasjonelt nivå (datamodell), brukes mest i sammenheng med implementering og beskriver for eksempel datafelter og relasjoner i en database eller et XML skjema i en integrasjonsløsning.

Les mer om informasjonsarkitektur på HelseWiki[23].

5.4.1 Overordnet informasjonsmodell

Nasjonal IKT har utarbeidet en overordnet informasjonsmodell for området pasientbehandling i spesialisthelsetjenesten. Denne modellen ble utviklet i forbindelse med prosjektet Tiltak 12, Tjenesteorientert arkitektur i spesialisthelsetjenesten, og ferdigstilt i 2008 [4].

Figur 15 Overordnet informasjonsmodell innen området pasientbehandling

Helsides figur finnes i Vedlegg.

NIKT har gjennom Tiltak 42, Videreutvikling av spesialisthelsetjenestens virksomhetsarkitektur[5], beskrevet overordnede tjeneste- og prosessmodeller for de øvrige områdene spesialisthelsetjenesten har oppgaver innenfor. Dette er forskning, utdanning av helsepersonell og opplæring av pasienter og pårørende. Det er ikke utarbeidet spesifikke informasjonsmodeller, men enkelte dataelementer og informasjonsflyt er beskrevet. Elementer fra informasjonsmodell for pasientbehandling er brukt, men modellene fra tiltak 12 og 42 er ikke knyttet sammen. Figur 16 og Figur 17 viser noen identifiserte entiteter.

Den overordnede informasjonsmodellen til spesialisthelsetjenesten kan brukes for å standardisere begrep.

Alle modeller og prosessbeskrivelser utarbeidet i tiltak 42 er tilgjengelig på HelseWiki[24].

Figur 16 Dataentiteter innen området forskning

Helsides figur finnes i Vedlegg.

Figur 17 Dataentiteter innen området utdanning av helsepersonell

Helsides figur finnes i Vedlegg.

5.4.2 Standarder

Standarder for å beskrive informasjonsmodeller

For å beskrive informasjonsmodeller og datamodeller benyttes gjerne ER-diagram (Entitet-Relasjon), spesielt på overordnet nivå. Dette for å beskrive konseptuelle modeller som viser relasjon mellom entiteter, men ikke tar med de enkelte informasjonsfelter (attributter). På detaljerte modeller brukes ofte UML (Unified Modeling Language) notasjon.

Les mer om informasjonsmodellering, teknikker og modeller på HelseWiki[25].

Referansekatalogen for e-helse

I henhold til Forskrift om IKT-standarder i helse- og omsorgstjenesten[6] skal Helse Midt-Norge benytte standarder som er etablert av Direktoratet for e-helse, og gjort tilgjengelig i en referansekatalog[7] i ehelse-portalen (ehelse.no).

Referansekatalogen omhandler bl.a. standarder for informasjonssikkerhet, kodeverk og terminologier og for elektronisk samhandling. Disse omfatter bl.a. helsefaglige kodeverk, teknisk/administrative kodeverk og terminologier som «(…) sikrer entydig bruk av begrep, relasjoner mellom begrep og koder for bruk i IKT-systemer.»[8].

Standarder for kodeverk og terminologi

Nasjonalt er arbeidet systematisert i databasen Volven[26]. Databasen skal gi en oversikt over og tilgang til helsetjenestens felles metadatagrunnlag, herunder kodeverk, klassifikasjoner, termer, begrepsdefinisjoner, datadefinisjoner med mer. Helsefaglige kodeverk omfatter klassifikasjon av sykdommer og beslektede helseproblemer (ICD-10), kirurgiske og medisinske prosedyrer (NCSP og NCMP), laboratoriekodeverk med mange flere. SNOMED CT og LOINC er andre internasjonale terminologier/ klassifikasjonssystemer.

Definisjonskatalog for den akuttmedisinske kjede (Andre utgave) er et eksempel på en samling av begrepsdefinisjoner fra Direktoratet for e-helse.

Standarder for informasjonsinnhold og elektronisk samhandling

Referansekatalogen for e-helse inneholder også standarder for innhold i og strukturering av EPJ-systemer og standarder for samhandling mellom forskjellige virksomheter innen helse- og omsorgstjenesten.

For samhandling mellom virksomheter hvor informasjon må utveksles uten å kunne deles, er arkitekturprinsippet interoperabilitet essensielt. Informasjonen som utveksles mellom IKT-system, må ha samme mening i alle systemene. Det kreves både teknisk standardisering, standardisering av informasjonsinnholdet og samordning av arbeidsprosesser, med mere.

Det er et skille mellom innholdsstandarder og kodeverksstandarder. NIKT besluttet i 2008 at det skal benyttes internasjonale innholdsstandarder på områder der slike finnes, men at nasjonale standarder og virksomhetsstandarder som er etablert av Direktoratet for e-helse eller spesialisthelsetjenesten og som allerede er i bruk, beholdes i en overgangsperiode. Internasjonale standardiseringsorganisasjoner er CEN[27], ISO[28] og HL7[29]. Direktoratet for e-helse baserer de norske standardene på et subsett av CEN standarder. Andre internasjonale innholdsstandarder for helse er HL7 versjon 2 og 3, CDA og FHIR versjon 2. Norske implementasjonsguider utvikles i regi av HL7 Norge som er en egen organisasjon. HL7 har som formål å «(…) fremme standardisert utveksling av klinisk, finansiell og administrativ informasjon mellom ulike helserelaterte informasjonssystemer, ved hjelp av internasjonale standarder fra HL7»[9]. OpenEHR[30] er en non-profit stiftelse med hovedfokus på interoperabilitet, i og mellom elektroniske pasientjournaler/systemer ved bruk av arketyper.

Les om modellsammenligning på HelseWiki[31].

Integrasjoner mellom IKT-løsninger som benyttes internt i foretakene er i hovedsak løst med proprietære grensesnitt. Ved behov for etablering av nye grensesnitt og integrasjonsløsninger i HMN og som ikke blir berørt av forskriften, er det et mål at de internasjonale standardene brukes. Dersom norsk implementasjonsguide for området ikke finnes, skal HMN ta initiativ til å utvikle slike og ta dem i bruk i integrasjonsløsningene. Eventuelle avvik fra bruk av standardene skal meldes til regionalt arkitekturkontor og dokumenteres.

5.4.3 Hvordan beskrive informasjonsarkitekturen

I alle prosesser for endringsaktiviteter som berører IKT i Helse Midt-Norge skal minst én av følgende aktiviteter inngå:

• Identifisere eksisterende informasjonsmodell(er) som skal benyttes

• Utvide eksisterende informasjonsmodell(er)

• Detaljere eksisterende informasjonsmodell(er)

I forbindelse med utforming av nye løsninger, vil utarbeidelse av en fysisk datamodell være en naturlig etterfølger og være basert på den logiske informasjonsmodellen.

For at en informasjonsmodell skal kunne gi mening, må begrepene som benyttes i modellen, være presise og gyldige, se 5.4.2 Standarder.

En informasjonsmodell utarbeidet for et spesifikt endringsarbeid viser et øyeblikksbilde av informasjonsbehovet. Det gir dermed ingen føringer for prosessflyt eller hvordan informasjon benyttes i en prosess eller tjeneste. En tjenestemodell beskriver sentrale tjenester og deres funksjonalitet, men gir ingen oversikt over informasjonsbehov.

Alle tjenester i tjenestemodellen vil ha behov for tilgang til å se og/eller manipulere informasjon, noe som medfører to behov:

Oversikt over hvilke informasjonselement en gitt tjeneste skal ha tilgang til og hvilke rettigheter for manipulering av informasjon tjenesten må ha
Informasjonseierskap, det vil si at alle entiteter i informasjonsmodellen skal ha en, og kun en eier

Ved endringer i en tjeneste eller database kan en CRUD (create, read, update, delete) analyse benyttes til å beskrive hvilke tjenester som blir påvirket av endringer i datamodellen og vise versa. Et eksempel fra et spesifikt endringsarbeid vises i Figur 18.

Figur 18 Tabellen viser en mapping mellom informasjonsmodell og tjenestemodell

Kobling mot de øvrige arkitekturdomenene:

Forretning: Prosessbeskrivelser som viser informasjon som utveksles kan sammenstilles med informasjonsmodeller og vise

a) hvor informasjon blir brukt og eventuelt endret

b) hvilke prosesser eller deler av organisasjonen som blir berørt ved en endring av informasjonsmodellen

Applikasjon: Arkitekturmodeller som viser interaksjoner (informasjon som utveksles) kan sammenstilles med informasjonsmodeller. Slik kan det avdekkes hvilke applikasjoner som blir berørt hvis informasjonsmodellen eller en annen applikasjon det er avhengighet til, endres.

5.4.4 Masterdatahåndtering

Nasjonal IKT beskriver masterdata som operasjonelle, relativt stabile data som kan endres, og er kjernedata i en virksomhet. I tillegg beskrives det at masterdata er viktige substantiv i en virksomhet som vanligvis deles inn i fire grupperinger: mennesker, ting, steder og begrep.

Masterdata kan også innbefatte nøkkelinformasjon som benyttes av flere virksomheter eller sektorer. Derimot er ikke transaksjonsdata som for eksempel ordre, faktura, henvisning og epikrise definert som masterdata, men denne typen data er gjerne avhengig av masterdata for å være gyldig. Kilden til dataene kan være en virksomhet, en prosess eller et system. Systemet som skal forvalte dataene har ansvaret for at dataene er konsistente og oppdaterte til enhver tid. Andre (organisasjonsenheter, prosesser og systemer) som bruker og/eller forvalter dataene må forholde seg til mastersystemets regime for dataforvaltning.

Ledelse og forvaltning av masterdata (Master Data Management) er aktivitetene og infrastrukturen som sørger for at et mangfold av klienter kan få tilgang til nøyaktig, presis, konsistent og fullstendig masterdata[10].

Et eksempel på masterdata er «pasient». Pasient er et dataobjekt som f.eks. sier noe om hvem som har vært til behandling. Tjenesteartikkel kan være et annet masterdataelement som sier noe om hvilken behandling «pasient» har fått.

Masterdata er ofte hierarkisk oppbygd, og består av flere underobjekter. Masterdata kan bestå av andre masterdata. For eksempel består «pasient» av navn, adresse, personnummer osv. Adresse kan være et eget masterdataelement der eierskap ligger til Norsk Folkeregister, mens Pasientobjektet i seg selv er eid av pasientregisteret. Et eksempel på hierarkisk oppbygging er artikler, der en artikkel kan ligge under en annen artikkel.

For prosjekter som involverer IKT-løsninger er det viktig, tidlig i prosjektet, å kartlegge hvilke omgivelser løsningen skal forholde seg til. Dvs. andre systemer og løsninger internt i eget foretak, i helseregionen og hos øvrige aktører. Et hvert prosjekt hvor masterdata inngår som del av dataflyten og masterdata skal vedlikeholdes, er det viktig å ha fokus på at datakvalitet og datasikkerhet ivaretas fra tidlig i prosjektprosessen. Det er etablert en felles enhet for forvaltning som ligger under Helse Midt-Norge RHF. Hvilken forvaltningsmodell som skal etableres for dataobjektet, må vurderes ut fra masterdataenes tilhørighet og system. Det kan være en regional eller lokal modell.

Beslutninger om masterdata må gjennomgå en prosess for godkjenning, og skal dokumenteres på en standardisert måte i Arkitekturbiblioteket. Hva som skal dokumenteres og hvordan, må beskrives nærmere i arkitekturmetodikken.

Hvordan identifiseres et masterdataobjekt i ulike systemer det inngår i?

Masterdataperspektivet:

• Det er naturlig at arbeid med masterdata gjennomføres i flere runder med et overordnet blikk i starten og blir mer utdypende etterhvert som prosesser kartlegges og beskrives

• Masterdata må sees i et ende-til-ende perspektiv i forhold til en prosess

• Det må fokuseres på tilstøtende prosesser og systemer (for eksempel randsystemers kilder) til den prosessen som er i fokus/analyseres

• Det vil ofte være nødvendig å beskrive egne prinsipper for det enkelte prosjekt

Eksempel på prinsipper for masterdata fra HMN-LØ:

Nr	Anbefaling	Påkrevd/ Valgfri
29	Alle masterdata må være tilgjengelig via veldokumenterte grensesnitt slik at leverandører kan etablere tjenester som benytter seg av korrekte masterdata.	P
30	Arkitektur knyttet til hvordan masterdata skal tilgjengeliggjøres samt muligheter for lokale kopier og replikering for hver masterdatakilde må bestemmes	P
31	Det må etableres ansvar/eierskap til masterdata sammen med prosesser for effektivt vedlikehold/ajourhold av masterdata.	P
32	Det må også for hver kilde tas stilling til rettigheter for de som skal benytte kilden.	P
33	Arkitekturen må oppdateres/videreutvikles med tydelige og detaljerte retningslinjer for håndtering av de ulike masterdata som finnes.	P

Det er hensiktsmessig å etablere et eget dokument/leveranse for masterdata, i tidlige faser av prosjekter som skal behandle masterdata. Dokumentets hensikt vil være følgende:

Entydig beskrivelse for hvor masterdata blir mastret. Dette medfører mulighet for å se hvilke integrasjoner som er manuelle og automatiske. Det tilrettelegger for at prosjekter i program får et felles utgangspunkt
Entydig beskrivelse av hvert masterdataobjekt, objektets attributter og hva det blir brukt til
Identifisere og beskrive nødvendige beslutninger, når det gjelder masterdata, slik at beslutningsprosessen kan igangsettes
Nødvendige interessenter til ovennevnte beslutninger blir identifisert, slik at beslutningsprosess kan igangsettes

Les mer om masterdata på HelseWiki[32].

5.5 Applikasjon

Applikasjonsarkitekturen representerer alle applikasjoner som understøtter virksomheten. Applikasjonene representerer all tilgjengelig IKT funksjonalitet. For å få en oversikt over hvilken funksjonalitet som understøttes og hvor det mangler funksjonell støtte, er det formålstjenlig å bruke en modell som deler inn virksomheten i funksjonsområder og deretter plassere funksjonene i applikasjonene inn i denne modellen. Vi får da et bilde av hvilke områder virksomheten har god funksjonsdekning på og hvilke områder det mangler slik dekning. En kan da sette inn tiltak for å forbedre støtten på disse områdene. Dette er spesielt viktig i endringsarbeid på et strategisk nivå.

5.5.1 Overordnet applikasjonsmodell

De modellene som applikasjonslandskapet vil støtte seg på er applikasjonsmodell (Figur 19) og kapabilitetsmodell (Figur 10) for spesialisthelsetjenesten. Disse modellene antas å bli vedtatt som nasjonale standarder.

5.5.1.1 Applikasjonsmodellen

Applikasjonsmodellen angir applikasjonsdomener i spesialisthelsetjenesten. Eksempler på slike domener er PAS/EPJ, Kurve og Laboratorier.

Figur 19 Applikasjonsmodell for spesialisthelsetjenesten(NIKT)[33]

Applikasjonene plasseres inn i disse domenene. En applikasjon skal bare plasseres i ett domene, selv om den også kan dekke andre domener. Hovedregelen er at den skal plasseres i det domenet den er anskaffet til. Figur 20 viser applikasjonsmodellen med applikasjoner i HMN, men er ikke komplett.

Figur 20 Applikasjonsmodell med applikasjoner i HMN[34]

Modellen kan blant annet benyttes til følgende:

• Illustrere investeringsomfang og driftskostnader på nasjonalt, regionalt og HF nivå.

• Anskueliggjøre omfanget av systemoverlapp ved å fremstille antall systemer pr. region for hvert domene.

• Innrette program- og prosjektorganisering (f.eks. styringsgrupper) i henhold til domeneinndelingen.

• En fast «ramme» i dialog med helseforetak og myndigheter.

Kapabilitetsmodellen er en annen tilnærmingsmåte for å beskrive hvilke applikasjoner som understøtter hvilke kapabiliteter i virksomheten. Kapabilitetsmodellen for helsetjenesten deler virksomheten inn i virksomhetsområder, se 5.3.1.1, Figur 11.

Ved å plassere applikasjonene inn i modellen vil den kunne beskrive i hvilken grad HMN understøtter kapabilitetene ved hjelp av applikasjonene. Eksempler på kapabiliteter er: Vurdering av helsetilstand og Medikamentell behandling. Her vil en navngitt applikasjon kunne understøtte flere kapabiliteter og derfor opptre i flere virksomhetsområder.

Den mest anvendelige modellen vil en derfor få ved å dele alle applikasjoner opp i sine respektive funksjonsområder for deretter å innplassere de i modellen. Denne modellen vil da kunne brukes til å avdekke funksjonell redundans og områder der HMN har dårlig eller manglende systemstøtte.

Det jobbes nasjonalt med å ta frem en standard for funksjonsområder, slik at applikasjoner som er ment å skulle understøtte samme kapabiliteter vil kunne sammenlignes på funksjonelt grunnlag.

5.5.1.2 Tjenesteorientert arkitektur

Arkitekturprinsippet tjenesteorientering gir føringer for hvordan applikasjonene utformes og hvordan de skal fungere sammen. Figur 21 viser et eksempel på en logisk modell for tjenesteorientert arkitektur.

Figur 21 Eksempel på en logisk modell for tjenesteorientert arkitektur[35]

For at applikasjoner i en tjenesteorientert arkitektur skal fungere sammen, i for eksempel en portal (se øverst til høyre i tegningen), trengs det bl.a. mekanismer som sikrer at nye brukergrensesnitt som etableres (bygd på tjenester) følger felles standarder/retningslinjer. Eksisterende systemer må inngå i en helhet sammen med nye brukergrensesnitt.

5.5.1.3 Referansemodell for applikasjon

Gjennom regionenes samarbeid i NIKT og nasjonale prosjekter, kan det bli utarbeidet referansemodeller som er førende for hvordan applikasjonene eller en løsning i HMN skal bygges opp. Eksempel på en referansemodell for applikasjonsdomenet er samhandlingsmønstre for å understøtte digitale innbyggertjenester for spesialisthelsetjenesten, som vist i Figur 22. Referansemodeller brukes som et virkemiddel for å sikre samspill mellom styringsnivåene, dvs. nasjonalt og mellom regionene, i dette eksemplet. Referansemodeller kan utarbeides innen alle arkitekturdomenene, og finnes også i TOGAF. Se Vedlegg for ytterligere beskrivelse av virkemidler for å sikre godt samspill mellom styringsnivåene.

Figur 22 Eksempel på referansemodell fra det nasjonale DIS-prosjektet[36]

Modellen viser Samhandlingsmønstre for å understøtte digitale innbyggertjenester for spesialisthelsetjenesten.

Innbygger kan tilbys innsyn i sin helseinformasjon ved å motta dokumenter og informasjon fra helsevirksomheten som plasseres i en digital postkasse. Helsevirksomheten sender ut meddelelser som digitale brev til innbyggere. Dette kan være innkallingsbrev, epikriser, vedtak osv. Forsendelsen inneholder informasjon om mottaker og avsender og dokument med eventuelle vedlegg. Vanlige dokumentformater vil være PDF eller HTML, men det er krav om PDF for dokumenter som skal skrives ut. Privatpersoner har adgang til å reservere seg mot å få enkeltvedtak og andre viktige henvendelser digitalt. De som har inngått en avtale om digital postkasse mottar henvendelsen der, mens andre som har reservert seg eller ikke har inngått avtale mottar papirpost som sendes ut via utskrifts- og forsendelsestjenesten.

Les mer om applikasjonsarkitektur på HelseWiki [37].

5.5.2 Standarder

Generelt skal Helse Midt-Norge forholde seg til internasjonale og nasjonale standarder som er vedtatt. Helse Midt-Norge skal unngå å bruke proprietære grensesnitt for integrasjon med andre applikasjoner, da disse er dyre å vedlikeholde og vil vanskeliggjøre en effektiv samhandling med andre.

Referansekatalogen for e-helse

I kapittel 5.4 Informasjon, er det vist til referansekatalogen for e-helse standarder. Disse standardene påvirker spesielt grensesnitt for samhandling med eksterne aktører. Referansekatalogen for e-helse[7] inneholder også standarder for innhold i og strukturering av elektronisk journal, samt grunnleggende krav til EPJ-systemer.

Internasjonale og nasjonale standarder som er mest relevant for finnes her:

• IT-standarder for offentlig sektor[38]

• NIKTs informasjonsbase over standarder[39]

5.5.3 Hvordan beskrive applikasjonsarkitektur

Arkitektur i en IKT-løsning eller en enkeltapplikasjon

Arkitekturmodeller for applikasjoner utarbeides med ulike perspektiv eller formål. En applikasjon i denne sammenhengen kan være en enkelt applikasjon eller en IKT-løsning som består av flere komponenter/deler.

Det er formålet med endringsarbeidet (for eksempel et prosjekt) som avgjør hvilke arkitekturbeskrivelser som må utarbeides. Aktuelle perspektiv er:

• Beskriv omgivelsene til applikasjonen, også nasjonalt hvis relevant. Dvs. hvilke applikasjoner som har interaksjon med denne applikasjonen og som den er avhengig av.

• Beskriv tjenester og funksjonalitet som applikasjonen tilbyr og kobling mellom tjenestene og entitetene i datamodellen. Dvs. hvilken informasjon som benyttes.

• Beskriv applikasjonens interne arkitektur, på et tilstrekkelig detaljeringsnivå. Hvilke komponenter eller bestanddeler systemet består av og deres interaksjoner.

• Beskriv prosessene mellom tjenestene og deres operasjoner. For eksempel hva skjer når en bestemt «operasjon» i applikasjonen utføres, for eksempel sekvens av «hendelser».

• Beskriv informasjonen som brukes i applikasjonen, hvor den hentes fra og hvor den lagres.

• Å beskrive applikasjonsarkitekturen i lys av krav til drift og infrastruktur kan ofte være nødvendig for større applikasjoner/IKT-løsninger når disse skal testes og produksjonsettes. For eksempel hvis en applikasjon skal brukes både av en pasient/innbygger hjemmefra og av helsepersonell på sykehuset.

Kobling mot de øvrige arkitekturdomenene (kun eksempler):

Forretning: Arkitekturmodeller som viser funksjonaliteten som tilbys av en applikasjon kan sammenstilles med oversikt over funksjonalitet og slik avdekke overlappende funksjonalitet.

Informasjon: Arkitekturmodeller som viser interaksjoner (informasjon som utveksles) kan sammenstilles med informasjonsmodeller. Slik kan det avdekkes hvilke applikasjoner som blir berørt hvis informasjonsmodellen eller en annen applikasjon det er avhengighet til, endres.

Teknologi: Arkitekturmodeller som viser infrastrukturen den skal etableres i, kan for eksempel

a) sammenstilles med en modell over nettsegmenter og avdekke behov for brannmuråpninger før installasjon av løsningen

b) avdekke behov for ny teknologi (ny lagringsløsning, ny mellomvare etc.)

5.6 Teknologi

Teknologiarkitekturen representerer de generelle tjenestene og funksjonene som danner grunnlaget for utformingen av tjenestene på arkitekturdomenene over. Dette domenet er selve grunnmuren i inndelingen og det er veldig viktig at dette domenet tilbyr alle de tjenestene som kreves for å utforme en god funksjonell IKT-løsning.

5.6.1 Overordnet modell

Det er ikke bestemt nasjonalt hvilken modell som skal ligge til grunn for teknologiarkitekturen, og vi har derfor valgt å dele inn disse tjenestene etter TOGAF sin Technical Reference Model (TRM). TRM gir oss en modell og en klassifisering av disse generelle tjenestene, se Figur 23.

Denne modellen komplementerer applikasjonsmodellen beskrevet i kapittel 5.5.1, Figur 19. TRM er en referansemodell som kategoriserer det som understøtter «Business Applications plattforms». Dvs. alle basistjenestene som plattformene til systemene er avhengig av for å kunne fungere. Modellen beskriver en klassifisering og en terminologi som gir en sammenhengende beskrivelse av komponentene og en konseptuell struktur på et informasjonssystem. Når vi har befolket modellen med HMNs infrastrukturobjekter, vil vi kunne se hvor vi mangler støtte og hvilke tiltak som må gjøres for å kunne understøtte systemporteføljen best mulig. I tillegg gir den en god dokumentasjon over hva vi til enhver tid kan tilby av slike tjenester.

Figur 23 TOGAF TRM (Technical Reference Model)[40]

De grunnleggende kvalitetene(qualities) som er beskrevet i modellen, er forskjellige typer av kvalitetsindikatorer det bør tas hensyn til ved design av tjenestene. Kvalitetene er gruppert i 4 grupper: Tilgjengelighet, Sikkerhet, Brukervennlighet og Tilpasningsdyktighet.

Hver av gruppene er igjen delt opp i under-kvalitetsindikatorer. Ett eksempel er ytelse (som tilhører gruppen Tilgjengelighet) som er en kvalitet som gjør at tjenesten responderer innen rimelig tid.

5.6.2 Standard

Operasjonalisering av HMNs Teknologistrategi[12], Strategi for identitets- og tilgangsstyring[13] og Sikkerhetsplan[41] vil etablere de teknologitjenester som bl.a. er nødvendig for å kunne nå målene i regional utviklingsplan.

«Teknologistrategien har flere formål:

• Teknologistrategien skal dokumentere hvordan en understøtter helseregionens mål gjennom teknologiske virkemidler og peke på hvilken teknologi som skal velges i fremtiden for å gjøre dette.

• Teknologistrategien skal understøtte valg av systemer og oppsett av systemer.

• Teknologistrategien skal synliggjøre teknologiske tjenester og relasjoner mellom disse.

For operasjonaliseringen av teknologistrategien etableres det en tiltaksoversikt som igjen danner basis for en handlingsplan. Denne handlingsplanen er det operasjonelle verktøyet for å prioritere, og koordinere strategiske initiativ.»

Dette sier NIKT om teknologiarkitektur på HelseWiki:

En tjenesteorientert arkitektur i spesialisthelsetjenesten fokuserer på samhandling og interoperabilitet langs flere dimensjoner. Data og funksjonalitet deles heller enn å dupliseres i mange systemer. Dette innebærer etablering og bruk av tjenester i og på tvers av virksomhetene i helsetjenesten og ut over denne.

For å realisere den tjenesteorienterte arkitekturen, er det blitt etablert en logisk modell, som beskriver hvordan det er tenkt at systemene skal samhandle ved hjelp av tjenester. I tillegg er det beskrevet et sett med foretrukne teknologistandarder, og identifisert behov for å detaljspesifisere disse i teknologiprofiler, ofte også kalt implementeringsguider. (…)[42]

5.6.3 Hvordan beskrive teknologiarkitektur

Som for applikasjonsarkitektur er det formålet med endringsarbeidet (prosjektet) som avgjør hva som skal beskrives og på hvilken måte. Det er til nå ikke beskrevet standard måter å utforme beskrivelsene på eller hva som skal inngå i arkitekturbeskrivelsene.

Aktuelle perspektiv for beskrivelsene er:

• En beskrivelse av teknologiarkitekturen som er nødvendig for å kunne installere og ta i bruk en IKT-løsning/system for å avdekke behov for ny teknologi eller endring i IKT-løsningen.

• En beskrivelse av teknologiarkitekturen for å kunne stille krav til leverandører ved nyanskaffelser eller endringer i eksisterende systemportefølje.

5.7 Sammenheng i og mellom arkitekturdomener

En viktig del av arbeidet med virksomhetsarkitektur er å sikre samsvar innen hvert domene, og mellom domener, noe Figur 24 illustrerer.

Å sikre samsvar innen hvert domene omfatter følgende:

• Forretningsarkitektur
Sikre at gjeldende strategi er effektivt implementert gjennom prosesser og strukturer.

• Applikasjonsarkitektur

Sikre at hensikten med de ulike applikasjonene er oppfylt gjennom applikasjonenes funksjoner og måten de er implementert på. Vurdere applikasjonene samlet, med hensyn til overlapp, underdekning og avhengigheter.

• Informasjonsarkitektur

Sikre samsvar mellom virksomhetens definisjon av informasjonselementer og logiske informasjonsmodeller, samt sikre at logiske informasjonsmodeller er implementert på en hensiktsmessig og effektiv måte.

• Teknologiarkitektur.

Sikre at prinsippene er anvendt i utforming av infrastruktur og installering av maskin- og programvarekomponenter.

Figur 24 Samsvar i og mellom arkitekturdomener

Å sikre samsvar mellom domener omfatter bl.a. følgende:

	Forretningsarkitektur
Informasjons-arkitektur	Sikre prosessenes bruk og tilgang til informasjon. Sikre informasjonens kvalitet, aktørenes ansvar for kvalitet, og mulighet til å påvirke kvalitet.	Informasjonsarkitektur
Applikasjons- Arkitektur	Ivareta prosessenes og funksjonenes behov for applikasjoner. Sikre forholdet mellom prosessenes krav og applikasjonenes egenskaper (kritikalitet, responstid, skalerbarhet, sanntid, etc.). Sikre virksomhetsmessige føringer og konsekvenser. Eksempler kan være å benytte standardsystemer, suiter, e.l.	Sikre at applikasjoner fremstiller informasjon i tråd med den logiske informasjonsmodellen. Sikre at applikasjoner har implementert representasjon, innhenting, sammenstilling, behandling og formidling av informasjon på en hensiktsmessig måte.	Applikasjonsarkitektur
Teknologi- Arkitektur	Sikre virksomhetsmessige føringer og konsekvenser, f.eks. • Teknologiske prinsipper, topologi og bruk av komponenter • Sikre hvorvidt teknologiske muligheter er utnyttet, f.eks. ved prosessutforming, konkurransestrategi, organisering, sikkerhet, mm.	Sikre at teknisk arkitektur er tilrettelagt for håndtering av informasjon.	Sikre at kravene til applikasjonene er ivaretatt i den tekniske arkitekturen (sikkerhet, robusthet, responstid, skalerbarhet, etc.)

Kartlegging, utforming av målbilder og sikring og vurdering av samsvar må gjøres i samarbeid med interessenter og fageksperter på de aktuelle områdene.

5.8 Arkitekturpraksis i en endringsprosess

Kapittel 2.2.3 beskriver arkitekturpraksisen i HMN og samspillet mellom øvrige prosesser. I dette kapitlet beskriver vi mer detaljert praksisen for virksomhetsarkitekturarbeidet i en endringsprosess.

Et eksempel på en fremgangsmåte er å:

1. Beskrive de overordnede virksomhetsprosessene og arbeidsprosessene

2. Beskrive hvilken informasjon og informasjonsflyt som er nødvendig for at prosessene skal fungere optimalt med minst mulig ressursbruk

3. Kartlegge hvilken funksjonalitet og hvilke applikasjoner som er nødvendig for å understøtte informasjonsflyten og tilgjengeliggjøre informasjonen

4. Analysere om det er mangler i funksjonalitet og hvilke endringer eller tillegg en trenger til applikasjonsporteføljen for å tilfredsstille informasjonsflyten

5. Analysere om det er mangler i funksjonalitet og hvilke endringer eller tillegg en trenger i arbeidsprosessen(e) for å tilfredsstille informasjonsflyten

I alt endringsarbeid er det viktig å identifisere hva formålet er, og å finne riktig abstraksjonsnivå og riktig perspektiv for det endringsarbeidet som skal gjøres. Arkitekturmodeller som beskrives må relateres til de overordnede modellene. Det er også viktig å utarbeide en interessentanalyse med aktuelle problemstillinger eller bekymringer for hver interessent.

Ved å velge ut og utvikle relevante arkitekturperspektiver vil en kunne demonstrere hvordan interessentene sine bekymringer blir tatt hånd om i forretningsarkitekturen. Dette skal gi en pekepinn på hvilke forretningsprosesser og organisatoriske prosesserer som bør beskrives, og på hvilket nivå. Vær oppmerksom på at det kan ligge føringer og beskrivelser av forretnings- og organisatoriske prosesser i kvalitetssystemet (EQS) som det må tas hensyn til. Vær bevisst på hvilken output en ønsker.

Kartlegging, utforming av målbilder og sikring og vurdering av samsvar må gjøres i samarbeid med interessenter og fageksperter på de aktuelle områdene.

Konkrete aktiviteter som kan bidra til å oppnå verdi for interessentene:

• Situasjonsbeskrivelse
for å analysere nåsituasjonen og avdekke problemer og mangler, samt se muligheter for endringer. Dette bidrar til en felles forståelse for nåsituasjonen og gir mulighet for å utvikle en strategi for fremtidig utvikling og endring av virksomheten.

• Utforming av målbilder
for å beskrive og argumentere for målbilder og utviklingen av virksomheten, samt belyse og vurdere ulike alternativer. Dette bidrar til en omforent forståelse som grunnlag for å velge det mest hensiktsmessige alternativet.

• Gapanalyse
til å identifisere viktige problemer, utfordringer, muligheter, etc., samt sørge for velbegrunnede, faktabaserte beslutninger som gjør det mulig å endre virksomheten fra dagens situasjon til ønsket målbilde.

• Taktisk planlegging
for å avgrense oppgaver og identifisere mellomsteg for gradvis endring av virksomheten mot målbildet (såkalt transisjonsarkitektur). Dette gjør realisering av strategiene mer håndterlig.

• Operasjonell planlegging
for å belyse retning for en portefølje av programmer og prosjekter, samt belyse sammenhengen mellom disse. Porteføljen skal ha som mål å realisere det nærmeste mellomsteget slik det er definert i taktisk planlegging.

• Utforming av løsningsarkitektur
for å utforme overordnet design for en løsning som skal realiseres og implementeres i et konkret prosjekt. Dette inkluderer valg av standardløsninger, pakker, tjenesteleverandører, etc. som vil utgjøre en del av løsning.

Til slutt må en sørge for at teknologivalgene understøtter applikasjonene slik at de er i stand til å levere ønsket funksjonalitet og informasjon.

Figur 25 er en enkel framstilling av prosessen for arkitekturarbeidet. Det er flere iterasjoner som pågår parallelt og underveis.

Figur 25 Arkitekturarbeid i en endringsprosess

Det er viktig å samarbeide med interessentene for å sikre at alle problemstillinger blir ivaretatt. Det er samtidig viktig å sjekke med overordnede arkitekturmodeller, referansearkitektur og andre føringer for å sikre at endringen går i riktig retning.

Virkemidler for å sikre godt samspill mellom styringsnivåene.

Arkitekturpraksisen kan benytte følgende overordnede virkemidler for å sikre et godt samspill mellom prosesser.

• Føringer for hvordan en virksomhet og dens IKT-løsninger skal fungere og utvikles er gitt av lover, forskrifter, normer, prinsipper, regler og retningslinjer. Et eksempel er spesialisthelsetjenestens arkitekturprinsipper. Føringene setter en del begrensninger, men gir samtidig en grad av frihet i å utforme virksomheten innenfor rammene. Slike virkemidler omtales som regulatoriske.

• Referansemodeller, standarder og veiledninger for design er konseptuelle beskrivelser, typisk på et overordnet nivå. Slike kalles gjerne referanseorienterte virkemidler og danner en bro mellom de regulatoriske og de designorienterte (se under).

• Modeller som beskriver virksomheten med dens egenskaper, elementer og sammenhenger, både i nåtid og fremtid, benyttes som grunnlag for beslutninger og implementeringer av strategier. Dette er f.eks. prosessmodeller, applikasjonslandskap, informasjonsmodeller, infrastrukturbeskrivelser og omtales som designorienterte virkemidler.

De tre overordnede virkemidlene kan knyttes til spesialisthelsetjenestens styringsnivåer.

Følgende figur illustrerer de overordnede virkemidlenes plass i de respektive styringsnivåene, hvor mørkere gråtone indikerer økt fokus.

Figur 26 Virksomhetsarkitekturens overordnede virkemidler på ulike styringsnivå

På lokalt nivå er man tett på linjeaktiviteter og realisering av strategier gjennom prosjektleveranser. Det er derfor naturlig at aktiviteter innen virksomhetsarkitektur her fokuserer på det designorienterte, og benytter de regulatoriske og referanseorienterte føringene som er etablert på nasjonalt og regionalt nivå.

Regional arkitekturpraksis er førende for helseforetakene gjennom referansemodeller, standarder og løsningsvalg. Dette er referanseorienterte virkemidler som beskrevet over. Regional arkitekturpraksis vil i tillegg ha en designorientert vinkling spesielt når behov og løsninger er regionale.

Arkitekturpraksisen på nasjonalt nivå må i hovedsak være regulatorisk ved at den beskriver og fortolker lover og forskrifter, overordnede prinsipper, regler og retningslinjer. I tillegg er den referanseorientert ved at det utarbeides felles, nasjonale konseptuelle beskrivelser.

5.9 Sentrale begrep

Sentralt i en arkitekturplan står begrepene virksomhetsarkitektur, arkitekturpraksis og arkitekturfunksjon.

Arkitekturplanen benytter virksomhetsarkitektur både om resultat, og om prosesser og virkemidler frem til et resultat. Vi tydeliggjør hva som menes når det er behov det. Begrepet arkitekturpraksis benyttes når det kun er snakk om prosesser og virkemidler.

Modell er også et begrep som står sentralt i virksomhetsarkitekturen. En modell er en forenklet eller avgrenset representasjon av virkeligheten (abstraksjon).

Figur 10 Kapabilitetsmodell for spesialisthelsetjenesten (Helse Vest)

Figur 11 Kapabilitetsmodell fra Helsedirektoratet, "en innbygger - en journal"

Figur 12 Prosessmodell - Innbyggersentrisk prosessmodell for helsetjenesten

Opprette kontakt mellom innbygger og helsetjenesten Ivareta helse Behandling Utredning

Figur 15 Overordnet informasjonsmodell innen området pasientbehandling

Figur 16 Dataentiteter innen området forskning

Figur 17 Dataentiteter innen området utdanning av helsepersonell

[1] Vedtatt november 2012

[2] Beskrivelser av sammenhenger i virksomheten.

[3] Etablert inndeling siden tidlig på 1990-tallet (Kilde: https://en.wikipedia.org/wiki/Enterprise_architecture_framework#Architecture_domain )

[4] Det nasjonale nivået består av Helsedirektoratet, Helse- og omsorgsdepartementet, og direktoratet for eHelse.

[5] Tilpasset og oversatt fra TOGAFs beskrivelse av Architecture Capability Overview (se http://pubs.opengroup.org/architecture/togaf91-doc/arch/chap02.html).

[6] Sikre at arkitekturleveranser er i tråd med visjon, strategier og krav (nasjonale, regionale og lokale). Sørge for at endringer er i samsvar med arkitekturprinsipper, retningslinjer, interne og eksterne krav. Sørge for arkitekturverktøy og en effektiv prosess for innmelding og oppfølging av endringsforslag og avvikshåndtering.

[7]Virksomhetskart gir oss oversikt over hvor «veiene» går, hvorfor vi gjør som vi gjør, hva som påvirkes av hva vi gjør og sammenhengen i det vi gjør.

[8] Bygd på og oversatt fra ITpreneurs Architecting the Family av Danny Greefhorst. Styring (Direct), Endring (Change), Drift (Operate)

[9] MoP ^TM – Management of Portfolios – porteføljemetodikken som HMN benytter

[10] Helsedirektoratet har etablert ehelse.no, en nasjonal informasjonskanal for utviklingen innen e-helse

[11] http://prosjektkontor.hemit.helsemn.no/default.aspx

[12] Direktoratet for forvaltning og IKT

[13] Forretningsarkitektur heter Business Architecture i TOGAF

[14]Brobygger’n - Sammenhengen mellom folk og IT, se http://mega/brobyggern/

[15] Mega veileder, tilgjengelig fra http://virksomhetsportal.helsemn.no/omrader/hemit/enhet/virksomhetsutvikling/arkitektur/mega

[16] Omarbeidet fra oversettelsen i “TOGAF 9.1 Translation Glossary: English – Norwegian”, §3.26 Capability, Open Group, Document Number C151

[17] Hentet fra Brobygger’n http://mega/brobyggern/pages/deb5e19e54ee4a4f.htm

[18] Lenke i Brobygger’n: http://mega/brobyggern/pages/f6e9f7675375611c.htm

[19] Ikke tilgjengelig/offentliggjort pr 22.01.2016

[20] http://helsewiki-prod.cust.seria.no/static/20130821

[21] http://helsewiki-prod.cust.seria.no/wiki/index.php/Tjenester_og_tjenestemodeller

[22] Finnes på Standard Norge (http://www.standard.no)

[23] http://helsewiki-prod.cust.seria.no/wiki/index.php/Informasjonsarkitektur

[24] http://helsewiki-prod.cust.seria.no/static/20130821/

[25] http://helsewiki-prod.cust.seria.no/wiki/index.php/Informasjonsarkitektur#Generelt_om_informasjonsmodellering.C2.A0

[26] www.volven.no

[27] CEN - European Committee for Standardization

[28] ISO - International Organization for Standardization

[29] HL7 - Health Level Seven International

[30] OpenEHR - The openEHR Foundation is a not-for-profit company, limited by guarantee, of University College London, UK.

[31] http://helsewiki-prod.cust.seria.no/wiki/index.php/Informasjonsarkitektur#Modellsammenligning.C2.A0

[32] http://helsewiki-prod.cust.seria.no/wiki/index.php/Masterdata

[33] Modellen er utviklet av NIKT. Her hentet fra Mega.

[34] Modellen er sist oppdatert 4.9.2015, hentet fra Mega.

[35] Hentet fra: http://helsewiki-prod.cust.seria.no/wiki/index.php/Teknologiarkitektur

[36] Lenke til original: http://www.nasjonalikt.no/filestore/Dokumenter/Prosjekter_og_tiltak/Sluttrapporter/Forprosjekt_DIS/VedleggG-Tekniskmlbilde-DIS.pdf

[37] HelseWiki: http://helsewiki-prod.cust.seria.no/wiki/index.php/Applikasjonsarkitektur

[38] Regjeringen.no - https://www.regjeringen.no/no/tema/statlig-forvaltning/ikt-politikk/referansekatalog-for-it-standarder-i-offentlig-sektor/id2354624/

[39] HelseWiki: http://helsewiki-prod.cust.seria.no/wiki/index.php/Arkitekturbibliotek#Informasjonsbase_over_standarder_.28Standards_Information_Base_.28SIB.29.29

[40] Original fra: http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap43.html

[41] Sikkerhetsplanen er under utarbeidelse.

[42] http://helsewiki-prod.cust.seria.no/wiki/index.php/Teknologiarkitektur

Forfatter:	Rannveig Woll (Arkitekt) Bård Grødem (Arkitekt) Bjørn Våga (Avdelingsleder) Stig Håvard Solum (Seksjonsleder) Ketil Thorvik (IT-spesialkonsulent) Anders Alfarnes (Prosjektleder)
Godkjent av:	Paul Gundersen (Direktør)
Dokumentadministrator:	Marianne Malkenes Aune (Seksjonsleder)
Dokument-ID:	1890
Gyldig fra:	29.04.2020
Revisjonsfrist:	29.04.2022

1.1 Introduksjon

1.3.2 Beskrivelser av sammenheng mellom organisasjon, prosesser og teknologi

2 Virksomhetsarkitektur i HMN - Arkitekturpraksis

5.3.1.4 Funksjonalitetskatalog

5.3.3 Hvordan beskrive forretningsarkitekturen

5.4.3 Hvordan beskrive informasjonsarkitekturen

5.5.1.1 Applikasjonsmodellen

5.5.1.2 Tjenesteorientert arkitektur

5.5.1.3 Referansemodell for applikasjon

5.5.3 Hvordan beskrive applikasjonsarkitektur

5.6.3 Hvordan beskrive teknologiarkitektur

Revisjonskommentar

Relaterte lenker

Vedlegg