Tjenesteorientert arkitektur i spesialisthelsetjenesten

Tjenesteorientert arkitektur i spesialisthelsetjenesten Hovedrapport redusert versjon Styringsdokument Dokumentnavn/Versjon: Tjenesteorientert_arkitektur_i_spesialisthelsetjenesten_hovedrapport_redusert_v1_0e.doc Revisjonshistorikk Dato Versjon Forfatter Beskrivelse 08.09.2008 1.0a Acando Oppdatert etter godkjennelse i styringsgruppen 12.09.2008 1.0b Fagforum for Lagt inn Forord arkitektur 19.09.2008 1.0d Acando Anbefalinger nummerert 13.10.2008 1.0e Fagforum for arkitektur Korrigert kryssreferanser 1

Forord, 12.09.2008 Nasjonal IKT gjennomførte i 2004/2005 et forprosjekt som anbefalte å etablere en felles systemarkitektur for spesialisthelsetjenesten. rosjektet ble startet opp 21.september 2007. Utarbeidelse av arkitekturen har fokusert på å dekke helheten mellom prosesser, tjenester, informasjonsstruktur, teknologi og standarder. Dette er den viktigste forutsetningen å skape IT-verktøy som utvikler seg i tråd med virksomhetens behov. Arkitekturen er nødvendig for å skape endringsevne, fleksibilitet og prosesstøttende IT - systemer som er tilpasset virksomheten. Arbeidet har vært gjennomført av NIKT fagforum for arkitektur med bistand fra Acando. Utarbeiding av de virksomhetsnære modellene (informasjonsmodell, prosesser og tjenester) er gjennomført med deltagelse av klinikere fra alle regioner. Teknologi og sikkerhet er utarbeidet av IT-teknisk personell fra regionene. Resultatet av arbeidet er dette styringsdokumentet som er en første utgave av arkitekturen og som skal gi føringer og rammer for utvikling av IT-porteføljen i spesialisthelsetjenesten. Fokus på helhet i arkitekturen har ført til stor bredde i hva som er behandlet. Dette mener vi er helt nødvendig og en naturlig konsekvens er at noen deler av arkitekturen ikke er komplett i første utgave. I fortsettelsen må arkitekturen videreutvikles og detaljeres som beskrevet i forvaltningskapittelet i dokumentet. rosessen har bidratt til større forståelse for de ulike regionenes behov og nødvendigheten av en felles arkitektur med felles styring. Det er bred enighet om at samarbeidet om felles arkitektur må videreføres. Resultatet er i tråd med mandatet og gir viktige rammer og føringer for spesialisthelsetjenesten. Det er viktig å fremskaffe en arkitektur som dekker hele sektoren siden samhandling ofte går på tvers av nivåene. Vi anbefaler at spesialisthelsetjenestens arkitektur brukes som utgangspunkt for å lage en helhetlig arkitektur for helsetjenesten og at et slikt arbeid blir iverksatt. Stor takk rettes til alle som har bidratt i arbeidsgrupper. Uten deres innsats hadde ikke dette vært mulig. NIKT fagforum for arkitektur er Olav Skjesol (leder), Hemit Andreas Brunvoll, Ullevål Universitetssykehus HF Axel Bull, Sykehuspartner Ronny Thomassen, Helse Nord IKT Terje Bremnes, Helse Vest IKT AS Torgny Neuman, Helse Vest IKT AS Torill Kristiansen, Hemit 2

Innholdsfortegnelse 1 Innledning og bakgrunn...4 1.1 Overordnet formål...4 1.2 Omfang og avgrensninger...5 2 Virksomhetsmål og -strategi...7 2.1 Funksjonsfordeling mellom helseforetakene og oppgavefordeling mellom nivåene 7 2.2 Bedre elektronisk samhandling...7 2.3 Fellestjenester...8 2.4 Effektiv ressursutnyttelse...8 2.5 Kvalitet på pasientbehandling...8 2.6 asientfokus...9 3 Hovedtrekk i foreslått arkitektur... 10 3.1... 11 3.2 Fra monolitter til tjenester... 11 3.3 Fellestjenester på forskjellig nivå... 11 3.4 Komponering av prosesser... 12 3.5 Rollestyrte arbeidsflater... 13 3.6 Tjenestebuss realisert... 14 3.7 Informasjonssikkerhet... 15 3.8 Fremtidens systemlandskap... 16 4 Arkitekturprinsipper... 19 4.1 Karakteristikk og kvalitet... 19 4.2 rinsipper... 19 4.3 Andre viktige designprinsipper... 25 5 Organisering, styring og videre arbeid... 27 5.1 Organisering... 27 5.2 Forvaltning og utvikling av arkitekturen... 30 5.3 Gradvis tilnærming til tjenesteorientert arkitektur... 31 5.4 Forslag til videre arbeid... 33 Vedlegg: Anbefalinger i arkitekturen... 39 Leserveiledning Alle lesere bør lese kapittel 1 til 5, dvs hele dette dokumentet. Kapittel 1 Innledning og bakgrunn presenterer utgangspunktet for arbeidet med arkitekturen. Kapittel 2 Virksomhetsmål og -strategi presenterer et uttrekk av virksomhetskrav og mål som påvirker arkitekturen. Kapittel 3 Hovedtrekk i foreslått arkitektur beskriver hovedelementene i arkitekturen. Kapittel 4 Arkitekturprinsipper presenterer prinsipper for foreslått arkitektur. Kapittel 5 Organisering, styring og videre arbeid beskriver forvaltning av arkitekturen samt Fullversjonen av rapporten har i tillegg til kapittel 1-5 disse kapitlene: Kapittel 6 Tjenester og tjenestemodeller beskriver overordnet tjenestene i spesialisthelsetjenesten som dekkes av arkitekturen.*) Kapittel 7 Informasjonsmodell beskriver de informasjonselementene som dekkes av arkitekturen og sammenhengen mellom disse. *) Kapittel 8 Klinisk arbeidsflate beskriver føringer og forslag til hvordan klinisk arbeidsflate skal etableres i spesialisthelsetjenesten. *) Kapittel 9 Teknologi og informasjonssikkerhet beskriver foreslått teknisk arkitektur. **) Kapittel 10 Referanser Kapittel 11 Vedlegg utdyper utvalgte emner Lesere med EJ og klinisk funksjonalitet i fokus bør konsentrere seg om kapitlene markert *) Lesere med IT fokus bør i tillegg konsentrere seg om kapittel markert **) 3

1 Innledning og bakgrunn Nasjonal IKT gjennomførte i årsskifte 2004/2005 et forprosjekt innen Nasjonal Arkitekturstrategi, tiltak 12, som anbefalte å sette i gang et arbeid for å få etablert en felles systemarkitektur for spesialisthelsetjenesten. å grunnlag av forprosjektrapporten, ble det utarbeidet et prosjektdirektiv for å få etablert en systemarkitektur for helsesektoren med hovedmål: 1. Etablere felles informasjonsmodell for spesialisthelsetjenesten. 2. Etablere krav til de viktigste fellestjenester i spesialisthelsetjenesten. 3. Etablere nasjonale føringer for bruk av teknologier knyttet til integrasjon og programvarearkitektur. 4. Etablere nasjonale føringer for portalløsninger i sektoren. 5. Lage forslag til organisering rundt videre forvaltning av nasjonal systemarkitektur Etablering av første versjon av arkitekturen for spesialisthelsetjenesten i dette dokumentet sammenfatter de fem hovedmålene. I definisjonen av arkitekturen er utgangpunktet tidshorisonten 2009-2015. Dette dokumentet er styringsdokumentet for arkitektur i spesialisthelsetjenesten, er grunnlaget for videre forvaltning av arkitekturen og setter føringer for IKT-arbeid i spesialisthelsetjenesten. Dokumentet er primært adressert til IKT-ledelse, IKT-arkitekter og andre som jobber med endring og utvikling i helsesektoren, men er nyttig lesning for andre som har interesse for emnet. Det er et mål at arkitekturen skal kunne benyttes i helsesektoren selv om den primært er adressert til spesialisthelsetjenesten. Ideelt sett bør arkitekturen være førende for alt arkitekturarbeid innen helsesektoren fremover. Arkitekturen danner premisser for leverandører av IT til helsesektoren. Med arkitektur menes en kombinasjon av modeller, løsninger og prinsipper til bruk ved etablering og utvikling av IKT løsninger som riktig understøtter brukernes behov. Et sentralt begrep i arkitekturen er tjenester. Med tjenester menes å tilføre verdi til noen eller noe, det innebærer at det finnes svært ulike tjenester, eks: IT tjenester og manuelle tjenester. Tjenester som utføres av IT løsninger kalles IT tjenester, andre tjenester som utføres av personer kalles manuelle. Interne og eksterne tjenester. Tjenester som utføres/leveres av egen organisasjon kalles interne tjenester, tjenester som utføres av andre kalles eksterne tjenester. Virksomhetstjenester og detaljtjenester. Virksomhetstjenester er tjenester på et høyt nivå som gjerne beskriver hva virksomheten leverer. Detaljtjenester er tjenester som gjør en mindre del i en større sammenheng. 1.1 Overordnet formål De overordnete formål med arkitekturen er: Effektivisere intern samhandling. Arkitekturen skal gi grunnlag for mer effektiv samhandling innen og mellom helseforetak spesielt og i helsesektoren generelt. Med mer effektiv menes at det skal være enklere å etablere og forvalte samhandling ved at den bl.a. følger gitte standarder for informasjonsinnhold og struktur, baseres på felles standarder og valg av teknologi og utøves gjennom tjenester og prosesser. Systeminndeling. Arkitekturen skal gi et forslag til overordnet inndeling i applikasjonsområder (gruppering av tjenester, funksjonalitet og data) for spesialisthelsetjenesten. 4

Grensesnittsstandard. Arkitekturen skal identifisere og anvende standarder for grensesnitt mellom løsninger. Der relevante standarder ikke eksisterer skal det etableres standarder for dette. Forhold til nasjonale føringer. Det skal vurderes konsekvenser av og for nasjonale føringer opp mot arkitekturen. Arbeidet med arkitekturen skal påvirke utvikling av felles nasjonale føringer. Eks: St.meld. nr. 17 (2006-2007) Eit informasjonssamfunn for alle, Samhandlingsarkitektur, Minside og Åpen kildekode. Input til leverandørstrategi. Arkitekturen skal kunne benyttes som underlag for valg og etablering av leverandørstrategier. Den skal være styrende for leverandørenes inndeling av systemer (tjenesteorientering og -inndeling) og systemenes tekniske oppbygging (arkitektur). Den skal også gi grunnlag for kriterier for valg av nye løsninger innen spesialisthelsetjenesten. Effekter Etablere fundament for samhandling i spesialisthelsetjenesten og mellom spesialisthelsetjenesten og andre aktører. Arkitekturen gir nødvendig støtte for samhandling for spesialisthelsetjenesten, innen et helseforetak og mellom helseforetak. Innføring av nasjonale og internasjonale standarder muliggjør samhandling med andre aktører både i innog utland. Høyere kvalitet på informasjon. Arkitekturen skal gi redusert risiko for manglende sammenheng mellom data i ulike løsninger. Bedre mulighet for å knytte informasjon om pasient fra ulike systemer sammen. Høyere kvalitet på tilgjengelig informasjon for pasient og for klinisk personell. Bedre beskrivelse av systemlandskap og tjenester. Ved en tydeligere beskrivelse av systemlandskap vil det bli enklere å gjøre anskaffelser tilpasset valgt arkitektur. Dette vil på sikt gjøre det enklere å samhandle på tvers av og innen foretak. Bedre for leverandørmarkedet. Ved en felles omforent arkitekturdefinisjon i spesialisthelsetjenesten vil det være enklere for ulike leverandører og forholde seg til helseforetakene og deres behov. Bedre økonomi og mer for pengene. Riktig teknologivalg kan redusere IT kostnadene (færre løsninger, færre teknologier og lavere driftskostnader). Integrasjonsstandarder bidrar til reduksjon av IT kostnadene, ved at kostnader tilkobling mellom systemer blir lavere. Fellestjenester som alle kan bruke vil bidra til reduksjon av IT kostnadene. 1.2 Omfang og avgrensninger Arkitekturen har fokus på behandlings- og pasientrelaterte prosesser. Fra Spesialisthelsetjenesteloven; 3-8. Sykehusenes oppgaver Sykehus skal særlig ivareta følgende oppgaver: 1. pasientbehandling, 2. utdanning av helsepersonell, 3. forskning, og 4. opplæring av pasienter og pårørende. Arkitekturen dekker i hovedsak pkt 1. og 2 og i mindre grad 3. og 4. Videre arbeid er påkrevd for at arkitekturen skal være dekkende for hele spesialisthelsetjenesten. 5

Figur 1 Inndeling av oppgaver i spesialist og primærhelsetjenesten (Kilde Helse og sosialdepartementet). Hovedfokus i arkitekturen er markert med grønn stiplet linje. Følgende avgrensinger er gjort i forhold til områder i arkitekturen: Nasjonale kvalitetsregistre Det pågår arbeid med felles løsning for nasjonale kvalitetsregistre, ref rapport: Felles teknisk løsning for regionalt eide nasjonale kvalitetsregistre og tekniske løsninger for dette, og beskrivelse av kvalitetsregistre er ikke vektlagt spesielt i dette dokumentet. Systemløsninger for kvalitetsregistre skal som andre IT løsninger i spesialisthelestjenesten forholde seg til arkitekturen. Nasjonale fellestjenester Det eksisterer (eller er under etablering) flere nasjonale fellestjenester, eksempler: eresept, HER (Helse-enhetsregisteret), asient transport. Konkret beskrivelse av disse inngår ikke i arkitekturen. Teknologi Teknologiområdet i arkitekturen har identifisert og dekker de viktigste elementer man mener det er riktig at det finnes overgripende føringer på i spesialisthelsetjenesten. Det er allikevel områder innen teknologi som ikke er berørt, eksempler: infrastruktur, kontorstøtte, databaser, etc. Informasjonssikkerhet Informasjonssikkerhet dekker elementer det er riktig at det finnes overgripende føringer på i spesialisthelsetjenesten i forhold til arkitekturen. Informasjonsmodell Informasjonsmodellen inneholder informasjonselementer hentet fra kjernevirksomheten og medisinske støtteprosesser. Informasjonsmodellen innholder ikke elementer fra administrative prosesser og andre støtteprosesser. Tjenestemodell Tjenestemodellen inneholder tjenester hentet fra kjernevirksomheten og medisinske støtteprosesser. Den innholder ikke elementer fra administrative prosesser og andre støtteprosesser. 6

2 Virksomhetsmål og -strategi Med bakgrunn i strategidokumentene til de regionale helseforetakene er det trukket fram en del virksomhetsmål og strategier som kan påvirke arkitekturen. Oversikten er ikke ment å være uttømmende, det finnes andre mål og strategier med potensiell effekt på arkitekturarbeidet. Imidlertid antas listen å være representativ med tanke på krav til arkitekturen. Noen krav som defineres av målene og strategiene er dokumentert nedenfor i tilknytning til hvert enkelt mål. Til hvert mål inngår en oppsummering av hvordan målet skal forstås. Innholdet i oppsummeringen er hentet fra strategidokumentene, men er formulert av arkitekturprosjektet. Følgende strategidokumenter er brukt som underlag: Mål 2008 for Helse Sør-Øst Strategi for utvikling av helsetilbudet fram mot 2010 Hovedrapport, Helse Midt-Norge Strategiplanen for Helse Vest fram mot 2020 Strategi for Helse Nord RHF 2.1 Funksjonsfordeling mellom helseforetakene og oppgavefordeling mellom nivåene Det er en klar trend innen spesialisthelsetjenesten at funksjonsfordelingen mellom foretakene blir tydeligere av tjenester øker. Standardisering ved at volumtjenester utføres på lik måte gjentatte ganger, og spesialisering ved at enkelte foretak utfører spesialfunksjoner. En annen trend er overføring av enkeltoppgaver fra spesialisthelsetjenesten til primærhelsetjenesten eller til nivået imellom. (distriktsmedisinske senter). Dette krever mer samhandling gjennom planlegging og informasjonsflyt med helsetjenesten i kommunene og mellom helseforetak (HF). Dette gir følgende krav til arkitekturen: Det må finnes tilgjengelig og konsistent pasientinformasjon innen og mellom foretak samt mellom spesialist- og primærhelsetjenesten. Spesielt gjelder dette for sykdomsforløp som går på tvers av foretak, regioner og nivåer. Det må etableres standarder for informasjonstilgang og utveksling av informasjon. Det må etableres sikker tilgang til informasjon basert på gjeldende lovverk, tilgangen må fungere på tvers av virksomheter, slik at informasjon kan deles. Det må finnes tjenester som ivaretar informasjonsflyten på tvers av foretak og på flere nivåer. Blant annet gjelder dette journaldata, pasientlogistikk og henvisninger og rekvisisjoner. Arkitekturen må være robust i forhold til endringer i myndighetskrav, virksomhetsstrategi og organisering. 2.2 Bedre elektronisk samhandling Mer effektiv elektronisk samhandling vil spare ressurser og gi bedre kvalitet på pasientbehandlingen. Økt elektronisk samhandling er aktuelt mellom systemer/løsninger innen og mellom helseforetak, samt mellom spesialist- og primærhelsetjenesten. Den elektroniske samhandlingen skal være sikker og i tråd med eksisterende lover og regler. Dette gir følgende krav til arkitekturen: Skal elektronisk samhandling være mulig må begreper og informasjonsstruktur harmoniseres på tvers av virksomheter (semantisk interoperabilitet). Det må etableres løsninger som gir sikker tilgang til samhandlingstjenester i hvert foretak. Det må settes krav til teknologi og grensesnitt slik at tjenesteutveksling kan foregå (teknisk interoperabilitet) 7

Det må være lett å lansere nye tjenester eller endre eksisterende tjenester uten at etablert samhandling går i stå. Informasjonssikkerhet må håndteres på tvers av foretak og regioner. Det kreves at foretakene har et bevisst forhold til partenes informasjonssikkerhetsløsninger og hvorvidt disse er til å stole på. Det må etableres støtte for prosesser som går på tvers av systemer innen et foretak, så vel som for prosesser som går på tvers av foretak. Fristhåndtering, optimalisering av flaskehalser og automatisering av delprosesser vil være elementer i etableringen av disse løsningene. 2.3 Fellestjenester Det er et stort uutnyttet potensial innenfor bruk av IKT i videreutvikling av helsetjenester. Like virksomhetstjenester er i dag implementert på forskjellige måter i ulike deler av helsetjenesten. I den grad de er støttet av IT er de ikke basert på felles informasjonskilder. Dette er kostnadskrevende og lite optimalt. Fellestjenester støttet av IT kan redusere kostnader og bidra til mer optimal tjenesteproduksjon. Dette gir følgende krav til arkitekturen: Fellestjenester må identifiseres og etableres Løsninger for tilgang til fellestjenester må finnes og disse må være tilstrekkelig sikret både med tanke på konfidensialitet, integritet og tilgjengelighet (virksomheten blir sårbar ved stort antall fellestjenester). Det må lages modeller for eierskap, drift og forvaltning av fellestjenester. Tilsvarende må det på sikt etableres finansierings- og prismodeller (dette behøver nødvendigvis ikke være en del av arkitekturen) Harmonisering av begreper og informasjonsstruktur er helt nødvendig for at slike tjenester skal kunne fungere. 2.4 Effektiv ressursutnyttelse Spesialisthelsetjenesten skal organiseres på en kostnadseffektiv måte, samtidig som krav til kvalitet, tilgjengelighet og utdanning og forskning ivaretas. Effektiv ressursutnyttelse er nødvendig i organisering av primær og støttefunksjoner. Bærekraftig utvikling over tid forutsetter bedre arbeidsdeling, ressurs- og kapasitetsutnyttelse og god økonomisk styring. rivate tjenestetilbud skal brukes på en forutsigbar og hensiktsmessig måte. Dette gir følgende krav til arkitekturen: Arkitekturen må gi støtte for prosessoptimalisering og automatisering Arkitekturen må gi støtte for måling av effektivitet og ressursutnyttelse. Løsninger som etableres bør være mest mulig uavhengige av organisering. Løsningene må bygges slik at konsekvenser fra organisasjonsendringer isoleres. Arkitekturen må bygges slik at den tillater gradvis implementering, f.eks. først der fordelen er stor og kostnadene begrenset. 2.5 Kvalitet på pasientbehandling Det er en trend at organisering i foretakene skal være orientert omkring pasientforløp blant annet for å sikre fokus på standardisering og effektivitet. God kvalitet i behandlings- forløpet og mer helsebringende tid i sykehus skal sikres. asientene skal ha tilgang til diagnostisering, behandling og omsorg av høy kvalitet. Dette gir følgende krav til arkitekturen: Foreslåtte løsninger må håndtere komplekse prosesser innenfor og på tvers av foretakene, for eksempel ved bruk av prosessmodellering og design. Det må lages løsninger og etableres prinsipper for kvalitetssikring av informasjon. Registrering og kvalitetssikring ved kilden, det vil si at informasjonen registreres kun 8

en gang, på det punktet der informasjonen oppstår eller første gang er naturlig å registrere, er et slikt prinsipp. Økt tilgang til relevant og situasjonsbestemt informasjon blir viktig informasjonsmengdene blir større og det vil bli viktig å gjøre de riktige utvalgene og at arkitekturen støtter dette. Bedre og økt kommunikasjon med pasienten, og løsninger som bidrar til dette, kan gi økt opplevd kvalitet sett fra pasientens side. 2.6 asientfokus Foretakene vil i større grad organiseres rundt pasientforløpene og i mindre grad rundt profesjonene. Det er en stadig dreining mot involvering av pasienten og å sette pasienten i fokus. Dette gjøres blant annet ved at pasienten deltar i behandlingen på en annen måte enn tidligere, og ved at pasientens kunnskap benyttes i utforming av tjenestetilbudet. asientene skal oppleve sammenhengende helsetjenester på tvers av behandlingsnivå og avdelinger. Det skal gis god informasjon og opplæring og pasientene skal være aktive deltakere i egen behandling. asientene vil i økende grad utnytte fritt sykehusvalg og kreve mer innsyn i behandlingen. Dette gir følgende krav til arkitekturen: Det må etableres et gjennomarbeidet og gjennomgripende pasientbegrep (innhold og identifikasjon/identer) asientrettete tjenester prioriteres i forhold til andre tjenester. Nye løsninger må gi prosesstøtte i pasientforløpet, også på tvers av foretak. Tjenester for kommunikasjon mellom pasient og sykehus bør etableres, eksempler er timebok, egen journal osv. Figur 2 asientforløp og organisasjonssiloer (Kilde NOU3:2005, Fra stykkevis til helt) Et eksempel på en sentral utfordring man har i dag er organisasjonssiloene pasienter må passere i et typisk forløp. I prinsippet skal informasjonen følge pasienten, men i praksis er det organisasjonssiloene som etablerer og holder på informasjonen om pasienten. Å løse denne utfordringen krever endringer på mange nivåer og kanskje tilpasninger av lovverket. Arkitekturen skal være med på å gi føringer for og understøtte hvordan utfordringen kan løses. 9

3 Hovedtrekk i foreslått arkitektur Foreslått arkitektur er forankret i overordnede føringer og mål, noen av disse er gjengitt i kapittel 2. Videre har en rekke prinsipper vært førende for utarbeidelse av løsninger. Arkitekturen fremstår i hovedsak som løsningsbeskrivelser. I Figur 3 er sammenhengen mellom mål, strategier, føringer og arkitektur belyst. Figur 3 Virksomhetsforankring av arkitektur Arkitekturen er utformet i tre hoveddimensjoner, områder eller vinklinger; Tjenester: tjenester og prosesser Data: informasjon og informasjonsmodeller Infrastruktur: teknologi og infrastruktur I tillegg er informasjonssikkerhet håndtert som et gjennomgripende område, som har betydning for løsning av alle de tre ovenfor nevnte dimensjonene. Figur 4 Arkitekturdimensjoner - ulike synsvinkler I det følgende er hovedtrekkene i arkitekturen beskrevet. 10

3.1 Det er etablert en overordnet logisk informasjonsmodell som dekker utvalgte områder av spesialisthelsetjenesten. Modellen kan utvides til dekke hele spesialisthelsetjenesten og hele helsesektoren. Modellen er brutt ned i noen utvalgte submodeller som illustrerer spesielt viktige områder. Sentralt i modellen er definisjon av pasientbegrepet og hvordan dette henger sammen med forløp, tjenesteproduksjon og diagnostisering. Kobling mellom pasient/tjenester og ressurser er også modellert. HL7 versjon 3 etableres som standard i spesialisthelsetjenesten. Nasjonale tilpasninger, altså nasjonal implementering, legges til framtidig organisasjon for forvaltning av arkitekturen. Videre foreslås at alle eksisterende nasjonale standarder og varianter som dekkes av HL7 versjon 3 gradvis skal erstattes av HL7 implementeringen. Modellen vil være førende for implementering av nye løsinger eller krav til leverandører av løsninger. å sikt vil implementering av modellen bidra til felles forståelse og tolkning av sentrale informasjonselementer i spesialisthelsetjenesten. Effektiviseringsgevinster kan oppnås ved økt automatisering (fordrer felles forståelse av informasjon som flyter i en prosess), og bedre styring basert på gode og sammenlignbare styringsdata. 3.2 Fra monolitter til tjenester Dagens situasjon bærer preg av store og omfattende informasjonssystemer (monolitter) som er vanskelig å integrere. Manglende støtte for prosesser både internt i et foretak og på tvers av foretak er en naturlig konsekvens. Foreslått arkitektur bryter opp monolittene i mindre enheter som hver for seg dekker mindre funksjonelle områder, en virksomhetstjeneste en IT tjeneste. Eksempler på slike tjenester kan være: Mottak/utskrivning av pasient Booking av ressurs eller tjeneste(røntgen/lab/seng/kirurgi) Overgangen fra dagens systemlandskap til fremtidig landskap er foreslått i flere trinn, hvor første trinn innebærer krav til leverandørene om standardisering av grensesnitt og tilbud av tjenester i disse grensesnittene. Forventet effekt av disse forslagene er redusert leverandøravhengighet, økt kvalitet i pasientnære prosesser, større endringsevne, økt konkurranse og reduserte kostnader. Tjenester kan velges fra flere og vil kunne inngå i virksomhetsspesifikke og konfigurerbare prosesser. Videre forventes økt grad av samhandling mellom enhetene i spesialisthelsetjenesten ved at enheter kan spesialisere seg i utførelsen av enkelte tjenester som tilbys til andre enheter. I andre sammenhenger konsumeres tjenester i stedet for å utføre dem selv. 3.3 Fellestjenester på forskjellig nivå I dagens systemer finnes stor grad av overlapp, samme funksjon utføres i mange systemer og data lagres om det samme på flere steder. I den nye arkitekturen er dette løst ved etablering av fellestjenester på ulike nivåer. Fellestjenester for hele spesialisthelsetjenesten kalles nasjonale tjenester, på regionalt nivå regionale tjenester osv. Fellestjenester kan finnes helt ned til et gitt sykehus. Eksempler på fellestjenester er: Nasjonalt: asient identifikasjon, felles tilgangsstyring (autentisering) inklusive synkrone bruker identer, KI løsning for helse, felles tilgang til folkeregister og andre nasjonale register, Adresseregisteret (HER), IR-RESH. Regionale: felles tilgangsstyring (autentisering) for regionen 11

Foretak: mottak/utskriving av pasienter Fellestjenester gjenbrukes på tvers i organisasjonen. Dermed oppnås ikke bare gjenbruk av data, men også gjenbruk av funksjonalitet. Reduserte kostnader, økt grad av standardisering og harmonisering og bedre datagrunnlag forventes som positive effekter av denne modellen. Videre åpner modellen for større frihet i forhold til hvem som skal utføre tjenester. En tjeneste skal være autonom og uavhengig av sine omgivelser (kontekst). Dersom den er det, kan den settes bort til den som tilbyr tjenesten til mest fordelaktige betingelser uten at det påvirker konsumentene av tjenesten. 3.4 Komponering av prosesser Riktig realisert tjenesteorientert arkitektur 1 gir store muligheter i frikobling av prosesslogikk fra tjenestelogikk. Tjenester konsumeres av prosesser i en flyt innenfor og på tvers av organisatoriske enheter. rosesser endres ofte, tjenester kommer til og erstattes (prosessene utvides/endres). I dag er prosesslogikk kodet inn i IT systemene, endring av en prosess medfører programmering. Det er mangelfull støtte for prosesser som går på tvers av systemene noe som er en typisk problemstilling i et pasientforløp. Styring og oppfølging av prosessene foregår manuelt, med kvalitetstap som mulig konsekvens, se Figur 5. Figur 5 Manuell prosessoppfølging Tjenester etablert på riktig nivå (med riktig omfang/ granularitet) vil kunne inngå i en eller flere prosesser. rosessene modelleres og kjøres i teknologi som er laget for dette formål tilnærmingen er ofte kalt modelldrevet prosessdesign. Endring av prosessene kan gjøres ved å endre modellene, ikke av en programmerer, men av de som har prosessansvaret. Konseptet er visualisert i Figur 6 nedenfor. Komponering av prosesser forutsetter at tjenestene og sammenhengen mellom disse er beskrevet, eksempler på dette er; dokumentasjon av standardiserte behandlingslinjer/pasientforløp. 1 Tjenesteorientert arkitektur er en software arkitektur der funksjonalitet er modellert rundt forretningsprosesser og leveres som gjenbrukbare tjenester. Tjenesteorientert arkitektur beskriver også IT infrastruktur som tillater applikasjoner å utveksle tjenester og data i en samhandlende forretningsprosess. En av målsettingene med tjenesteorientert arkitektur er løs kobling mellom tjenester og mellom tjenester og teknologi. Dermed isoleres effektene av endringer mest mulig. 12

Kjører i en BMS/prosessmotor WS EJ AS Funksjon WS Kjører i en tjenestebuss AI i applikasjon Kjører i en tjenestebuss Figur 6 Modelldrevet prosesstøtte Figur 6 viser en prosess som er modellert og kjører i en prosessmotor (forenklet uttrykk for Business rocess Management System - BMS). rosessen er bygget opp av automatiserte steg fra tjenester (WS) og funksjoner, for eksempel et skjermbilde i en applikasjon (Funk). Videre har prosessen en del manuelle steg uten IT støtte, dels i sekvens og dels i parallell. Den foreslåtte løsningen gir helt andre muligheter for automatisering og håndtering av prosesser på tvers av systemer. Dette fordrer dog at steg 2 i prinsippskissen til migrering, ref. kapittel 5.3, gjennomføres. De store systemleverandørene til spesialisthelsetjenesten må etablere og eksponerer tjenester i systemene tjenester som kan inngå i prosesser på tvers av enheter og systemer. Arkitekturen tillater en gradvis tilnærming frem mot modelldrevet prosess design. Dokumentering av prosessene i en felles notasjon (BMN er anbefalt) og manuell kobling mot tjenester og funksjoner i systemer er en god start. Effektene av den skisserte løsingen for håndtering av prosesser vil være tydelige og merkbare. Støtte for håndtering av frister, automatisering av deler av prosessene, bedre oversikt over flaskehalser samt kvalitetshevning på sentrale prosesser for eksempel i relasjon til pasientene er noen av de viktigste. Konseptet er for øvrig ikke nytt i helsesektoren, EJ fagforum har i en egen rapport rosesstøttende EJ systemer, undersøkt mulighetene ved denne tilnærmeringen og kommet frem til mange av de samme effektene. Den nye arkitekturen er nødvendig for å realisere løsningene beskrevet i dette dokumentet. 3.5 Rollestyrte arbeidsflater Brukere av IT systemer møter typisk ulike grensesnitt for hvert system, duplisering av funksjoner, innlogging flere ganger og manglende personalisering (alle ser de samme funksjonene og det samme grensesnittet). I den nye arkitekturen er noen av disse uønskede karakteristika, søkt løst ved konseptet rollestyrt arbeidsflate. Avhengig av rolle, dvs. hvilken funksjon du har i øyeblikket, tilbys tilpasset funksjonalitet i en homogen arbeidsflate. Fellesfunksjoner slik som pålogging, tilpassing til brukerutrustning (for eksempel mobil kontra fast, C kontra Web), håndtering av kontekst og default verdier løses i arbeidsflaten i stedet for hvert i enkelt system. I noen spesielle tilfeller, for eksempel for ACS, vil arbeidsflaten kun tilby inngang til systemet. Systemets spesielle behov i kommunikasjon med brukeren, løses best av systemet selv. 13

Det finnes etter hvert en rekke teknologier som er rettet mot å tilby dette konseptet, men ingen gjør det fullt ut og alene. Eksempler er portalteknologi, BMS enten alene eller sammen med portaler, leverandørspesifikke rammeverk. Den nye arkitekturen anbefaler ikke en enkelt teknologi eller teknologikategori, men fremhever at konseptet må baseres på standarder som for eksempel HL7 CCOW. Videre stilles det krav til funksjonalitet og teknologi. Rollestyrte arbeidsflater forventes å gi bedre muligheter for sammenstilling av informasjon, reduserte brukerterskler, mindre trøbbel og heft for brukeren, tilgang til informasjon der hvor brukeren er og i den situasjonen han trenger det. Det finnes effektiviseringsgevinster knyttet til lavere terskel for tilgang til IT og mer effektiv bruk av IT systemene. Teknologien muliggjør realisering av informasjonstilgang for pasienter. Arbeidsflater muliggjør gradvis tilnærming til arkitekturen og oppdeling av monolitter ved at tjenester kan tilgjengeliggjøres til bruker utenfor rammen av monolitt løsninger. 3.6 Tjenestebuss realisert I arkitekturen er tjenestebussen et sentralt konsept. Tjenestebussen er samlingen av funksjoner som er nødvendige for å få tjenester fra de ulike tjenestetilbydere til å spille sammen, og å ivareta fleksibilitet, informasjonssikkerhet og effektiv drift og forvaltning. Fysisk består den av, ESB (Enterprise Service Bus) og informasjonssikkerhetsprodukter og oppsett som er nødvendig for sikker eksekvering av tjenester. I Figur 7 fremgår det at bussen er ett felles standardisert rammeverk for kjøring av en enhets forskjellige tjenester, noen fra leverandør A noen fra leverandør B, representert ved forskjellige farger på tjenesten. Figur 7 Tjenestebuss for kjøring av tjenester fra mange leverandører Tjenestebussen er et felles logisk konsept, men den vil implementeres som flere fysiske instanser og kan også være basert på forskjellige teknologier i de ulike regionene/foretakene. De tjenester som skal benytte tjenestebussen skal overholde standarder gitt av tjenestebussen. Garantien for samhandling ligger i at bussen finnes og den følger visse standarder, ikke i at alle bruker lik teknologi. Dette er visualisert i Figur 8. 14

Figur 8 Ulik implementering av tjenestebuss i foretak og regioner I arkitekturen er det foreslått at tjenestebussen etableres på basis av åpne teknologier og produkter. For å unngå leverandørbindinger anbefales det at tjenestebussen leveres av andre enn de som leverer systemene/tjenestene. Det kan være fristende å la leverandøren av for eksempel EJ systemet også være leverandør av tjenestebuss konseptet, dette frarådes altså sterkt. Årsaken er at tjenestebussen er den tekniske premissgiveren for alle tjenester, et rammeverk for å gjøre tjenester tilgjengelig. Det er lite ønskelig at dette rammeverket skal være under kontroll av en enkelt tjenesteleverandør. Den nye arkitekturen setter krav til bruk av gitte standarder for at samhandling skal bli teknisk mulig (teknisk interoperabilitet). De prefererte er Web Services standardene som administreres av OASIS og WSI (profil). Det skisserte tjenestebusskonseptet og implementering av dette forventes å gi store effekter på evnen til samhandling innenfor et foretak, på tvers av foretak og regioner og på nasjonalt nivå. Antall punkt til punkt integrasjoner i spesialisthelsetjenesten er allerede svært høyt og økende, kostnadene for vedlikehold og videreutvikling av disse er økende og vil på et tidspunkt overskride nytten av nye integrasjoner. Tjenestebusskonsept løser dette problemet og gir tilnærmet leverandøruavhengig integrasjon. 3.7 Informasjonssikkerhet Informasjonssikkerhet er stort og komplekst område i spesialisthelsetjenesten. Det er en forutsetning for å lykkes med implementering av IKT at informasjonssikkerheten er ivaretatt. Langt fra alt skal løses på arkitekturnivå, men det må lages et grunnlag som gjør det mulig å håndtere de ulike sikkerhetsaspektene der de hører hjemme. Med informasjonssikkerhet mener vi blant annet personopplysningsloven bestemmelser og Norm for informasjonssikkerhet for etablering av sikkerhetstiltak. I spesialisthelsetjenesten er kravene om tilgang til informasjon, basert på dynamisk endrede roller til helsepersonell, spesielt utfordrende. Kravene til håndtering og skjerming av pasientnære data likeså. Videre er det behov for en avklaring om foretakene fra ulike regioner kan se på hverandre som trusted partners. Dette er nok i stor grad avhengig av informasjonssikkerhetsløsningene og om de oppfattes som gode nok, men det er også avhengig av innsyn, gjennomsiktighet i praktisering av informasjonssikkerhetstiltak og sporing av hendelser. Tillit etableres ved at det gjennomføres en Risiko og Sårbarhetsanalyse (RoSanalyse) av en eventuell tilkobling mellom foretakene. Hvis tillit oppnås kan foretakene ha enklere tilgang til hverandres tjenester og informasjon, der tillit ikke kan oppnås vil foretakene måtte se på hverandre som eksterne parter. Noe som sannsynligvis vil gjøre deler av samhandlingen mer tungvint, men fortsatt gjennomførbar. 15

I den nye arkitekturen er det foreslått en felles løsning og teknologi for autentisering av brukere, krysskobling mellom brukerfunksjon og tilgang, og for rapportering av hendelser, dette vil løse utfordringene som nevnt over. Det er meningen at hver region idriftsetter sin(e) variant(er) av denne løsningen og at de selv står for bruken. Videre er planen at brukeridentiteter synkroniseres på tvers av hele spesialisthelsetjenesten. Dette fordrer at brukeridenten er unik og at det etableres en felles katalog for brukeridenter. Arkitekturen anbefaler at det etableres en felles KI infrastruktur til bruk for signering, kryptering og autentisering. Arkitekturen har ikke skissert noen spesielle løsninger for skjerming av informasjon, for eksempel i tilknytning til journaldata. Dette må håndteres på et senere stadium. I migreringsplanene er det skissert en del aktiviteter for å teste ut, verifisere og sette krav til felles informasjonssikkerhetsløsninger. Dette gjelder blant annet oppsett av soner for tjenesteutveksling, eller mer spesifikt konfigurering av kommunikasjons- og informasjonssikkerhetsteknologi for bruk av Web Services mellom foretak. Integritet er viktig side ved informasjonssikkerhetsløsninger. Den nye arkitekturen er orientert mot å ivareta transaksjonsintegritet og dataintegritet på flere måter. Web Services security standardene anbefales brukt, disse vil i stor grad sikre at integritet ivaretas når tjenester brukes, for eksempel i samhandling mellom foretak. Videre foreslår arkitekturen en overordnet informasjonsmodell som i noen grad bidrar til harmonisering av begreper innenfor spesialisthelsetjenesten. Denne effekten forsterkes kraftig ved anbefalingen om å benytte HL7 versjon 3 som standard for all informasjonsutveksling, i meldinger og tjenestegrensesnitt. Gjennom økt grad av informasjonsdeling og bruk av standarder for informasjonsutveksling vil integriteten øke. Felles krav til presentasjon av informasjon i klinisk arbeidsflate vil også bidra til dette. Fokus på harmoniserte informasjonsmodeller på tvers av virksomheter og etablering av standarder for informasjonsutveksling er helt sentrale virkemidler for å ivareta informasjonssikkerhetsprinsippet om integritet. Gode informasjonssikkerhetsløsninger er fundamentet for effektiv samhandling i spesialisthelsetjenesten. Uten gjennomgripende informasjonssikkerhetsfokus, på alle nivåer og områder, kan ikke den nye arkitekturen realiseres. Fortsatt fokus på informasjonssikkerhetsløsninger i alle migreringsaktiviteter er påkrevd. Se Vedlegg J: Forhold til lover og forskrifter for kort beskrivelse av hvordan arkitekturen forholder seg til relevante lover og forskrifter. 3.8 Fremtidens systemlandskap Typiske trekk ved dagens systemportefølje i en lang rekke virksomheter, inkludert spesialisthelsetjenesten, kjennetegnes ved: Store systemer med omfattende funksjonalitet og som vokser etter som tiden går. Omfattende overlapp mellom systemer hva gjelder funksjonalitet og håndtering av data. Leverandører med betydelig makt til å styre anvendelsen og utviklingen av informasjonsteknologi i virksomheten. Arkitekturen gir et annet framtidsbilde. Oppsplitting av systemer i mindre autonome enheter kalt tjenester som er nært koblet til virksomhetstjenester og -prosesser. Komponering av nye prosesser basert på gjenbrukbare tjenester. Utveksling av informasjon og utveksling av tjenester mellom organisatoriske enheter innenfor og på tvers av virksomheten. Leverandører som spesialiserer seg i gitte tjenesteområder, konkurranse mellom leverandører av samme tjenester, muligheter til å velge tjenester fra flere basert på krav til standardisering av grensesnitt. Den nye arkitekturen er tjenesteorientert. Dagens store monolitter, som AS og EJ, anbefales brutt opp. Systembegrep endrer betydning fra dagens fysiske kobling til 16

eksekverbar kode levert av en leverandør til forvaltning av et sett tjenester levert av en eller flere, men eiet av en prosessansvarlig i virksomheten. Tjenester er modellert i tjenesteområder, som angitt i Figur 9 Fremtidens systemlandskap, av ulik type. Tjenesteområdene representerer de sentrale virksomhetsprosessene og er gruppert i journaltjenester, kliniske tjenester, tjenester for ressursstyring og tjenester for pasientlogistikk. I tillegg vil det finnes et relativt stort antall spesialistsystemer som er nært koblet til (leveres sammen med) medisinsk utstyr. Benytter Utfører Benytter Figur 9 Fremtidens systemlandskap Fellestjenester finnes på flere nivåer; Interne for spesialisthelsetjenesten som pasientmottak eller utskrivning. Det vil også finnes interne IT tekniske tjenester som sporing, autentisering (IAM), føderering, kryptering osv. Det vil finnes fellestjenester for Helse-Norge som pasient ID, medikament registre og IR-RESH, HER. Legg også merke til at journaltjenestene eksponerer journaldata for pasienter gjennom fellestjenestene; Kjernejournal og Forløpsjournal. Tjenester eksternt for helsesektoren er eksemplifisert ved henvisning til folkeregistret, men det vil ventelig finnes et stort antall av disse om noen år. Effekten av en slik tilnærming er langt større fleksibilitet i valg av leverandør og løsning. Reduserte anskaffelseskostnader som følge av større konkurranse. Muligheter til å sette sammen støtte for nye eller endrede virksomhetsprosesser uten en stor leveranse og dertil tilhørende utrullingsprosess. Bedre støtte for virksomhetsprosesser innenfor og på tvers av virksomheten som følge av en arkitektur som er basert på utveksling av tjenester. Reduserte kostnader ved at funksjonelle behov løses kun en gang og representeres ved en tjeneste som gjenbrukes og mulighet for sparte utgifter til test, opplæring og implementering. En av de viktigste effektene overses ofte; En tjenesteorientert arkitektur er bygget for integrasjon. Hele hensikten med denne måten å bygge løsninger på er utveksling av tjenester gjennom prosesser, ref. også Figur 6. Behovet for utveksling av informasjon dekkes av tjenester og er standardisert i måten tjenestene leveres på grensesnittet. unkt til punkt integrasjon (mange til mange koblinger) erstattes av fellestjenester som leveres på en tjenestebuss, alternativt ved bruk av en virksomhetstjeneste (domene tjeneste) i en virksomhetsprosess. Behovet for integrasjon av systemer i spesialisthelsetjenesten er meget 17

stort og økende. unkt til punkt integrasjon er ikke løsningen på dette behovet, kostnadene til utvikling og vedlikehold forventes å eskalere. Tilnærming til en tjenesteorientert arkitektur, og et systemlandskap som beskrevet i dette kapittelet, er veien å gå om tilfredsstillende systemstøtte for sentrale virksomhetsbehov skal nås innenfor forsvarlige budsjettrammer. 18

4 Arkitekturprinsipper Virksomhetens omgivelser, visjon, mål og strategier er grunnleggende føringer for arkitekturen. Disse definerer mye av hensikten med arkitekturen, peker ut virksomhetsområder som skal støttes og setter føringer for valg av alternative løsninger. Lover, forskrifter og regler, på alle nivåer fra internasjonale via nasjonale til virksomhetsinterne, setter rammer for arkitekturen, løsningene må fungere innenfor disse rammene. Arkitekturprinsipper er regler for utarbeidelse av arkitekturen (ofte kalt designregler). Gode arkitekturprinsipper er relevante for virksomheten og søker å løse viktige utfordringer (endringsevne er for eksempel relevant for de fleste virksomheter i dag, men ikke for alle). rinsippene er av varig karakter. Hovedformål med prinsippene: eke ut retning slik at gode løsninger kan finnes Fungere som evalueringskriterier for foreslåtte løsninger Uttrykke verdien av arkitekturen for virksomheten Tydeliggjøre implikasjoner av arkitekturen for virksomheten ositive sideeffekter av prinsippene: Danne et rammeverk for å ta beslutninger innen porteføljeforvaltning og IT-arkitektur Det er et mål at prinsippene etter hvert skal dekke alle perspektiver ved utforming av løsninger. rinsippene vil dermed suppleres over tid som en del av forvaltningen av den nye arkitekturen. rinsippene gjelder for hele virksomheten som omhandles av arkitekturen. De skal være med å sikre at formålene for arkitekturen nås. Alle prosjekter som endrer systemporteføljen skal valideres mot prinsippene og avvik behandles. Nødvendige tiltak diskuteres/besluttes sammen med arkitekturfunksjonen på riktig nivå. 4.1 Karakteristikk og kvalitet Arkitekturprinsippene karakteriseres ved at de er: Stabile - rinsippene skal være stabile over lang tid, og ikke være knyttet til organisatoriske, systemmessige eller andre rammebetingelser, som potensielt kan endres hurtig. Robuste - rinsippene skal være gyldige, også for komplekse problemstillinger og gi en klar ledetråd i hvordan problemstillingen skal løses. Konsistente - Innbyrdes skal alle prinsippene være konsistente. Det skal ikke være aspekter ved et prinsipp som står i direkte motsetning til et annet prinsipp. Forståelige - rinsippene skal være raskt forståelige for organisasjonen, og det skal være tydelig hva som er formålet med prinsippet. 4.2 rinsipper 4.2.1 Helhetstenking heller enn suboptimalisering Helhetstenking innebærer å løfte blikket, vurdere omgivelser og se etter problemstillinger og løsninger i en større sammenheng. Riktig utført kan bruk av prinsippet medføre enkle (og gode) løsninger på flere problemer, heller enn omfattende (og dårlige) løsinger på ett enkelt problem. 19

Bakgrunn/relevans Spesialisthelsetjenesten kjennetegnes av en flora av IT systemer, hver enkelt rettet mot et funksjonelt behov. De store fagsystemene, EJ/AS, går andre veien og tilbyr mer funksjonalitet enn de burde. Begge deler er et resultat av manglende helhetstenkning. Tilnærming i arkitekturen Selve tilnærmingen til arkitekturarbeidet er basert på dette prinsippet. Helhetlige løsninger for hele spesialisthelsetjenesten trekkes frem og beskrives. En logisk informasjonsmodell for virksomhetsområdene som sørger for harmonisering av strukturer og informasjon på tvers, identifisering av fellestjenester for gjenbruk, oppsplitting av fagsystemene i autonome tjenester som samhandler, etablering av standarder og føringer på nasjonalt nivå med lokal implementering alle eksempler på anvendelse av prinsippet. Andre implikasjoner/konsekvenser Forvaltning av arkitekturen i form av videreutvikling, detaljering, implementering og styring av prosesser som kan påvirke arkitekturen blir viktig fremover. Uten dette forvitrer helhetstenkingen sammen med arkitekturen. Inngripen i og kvalitetssikring av prosjekter som realiserer nye løsninger i spesialisthelsetjenesten blir avgjørende for om man lykkes. Videre vil kompetanse på den nye arkitekturen, både kvalitativt og kvantitativt, være en nøkkelfaktor for suksess. 4.2.2 Interoperabilitet Interoperabilitet uttrykker to eller flere organisasjoner eller systemers evne til å utveksle og nyttiggjøre seg av hverandres tjenester og informasjon. Begrepet Interoperabilitet kan sees i flere dimensjoner; organisatorisk, semantisk og teknisk. Bakgrunn/relevans Interoperabilitet handler om evnen til samhandling, hvor godt man er i stand til å samhandle heller enn hvor mye man samhandler. I spesialisthelsetjenesten går mange pasientforløp på tvers av systemer, avdelinger og foretak. Samhandlingsbehovet er meget stort. 4.2.2.1 Organisatorisk interoperabilitet Med dette menes virksomhetenes evne til samhandling. Det er vanlig å legge organisatoriske forhold som påvirker evnen til utveksling av tjenester og informasjon under dette begrepet. Tilnærming i arkitekturen Den nye arkitekturen er tjenesteorientert, funksjonalitet splittes opp i virksomhetsnære tjenester og sys sammen i dynamiske prosesser. Dette er en av de viktigste byggesteinene i arkitekturen som underbygger evnen til organisatorisk interoperabilitet. Identifisering av fellestjenester og gjenbruk av disse blir også viktig for å følge dette prinsippet. Andre implikasjoner/konsekvenser I migreringsplanen er det definert aktiviteter for modellering av prosesser som går på tvers av organisasjonsenheter. Fokus på etablering av eierskap til prosesser heller enn systemer trekkes frem som viktig på sikt. Det må avklares om det kan etableres tillit mellom partnere i spesialisthelsetjeneste, for eksempel mellom foretak i ulike regioner. Hvis ikke dette lar seg gjøre må all kommunikasjon mellom regionene håndteres som om den var mellom eksterne parter. Dette er organisatorisk kompliserende og kan medføre redusert evne til samhandling. 4.2.2.2 Teknisk interoperabilitet Med teknisk interoperabilitet menes evne til utveksling av tjenester og data på teknisk side. Herunder ligger bruk av standarder, etablering av nettverk og kommunikasjonsløsninger, teknologi for integrasjon, informasjonssikkerhetsløsninger og mye mer. 20

Tilnærming i arkitekturen Det er lagt stor vekt på etablering av standarder på alle nivå der dette er relevant for samhandling. De viktigste på teknisk side er Web Services standardene. Tjenestebuss er et viktig konsept som er tatt frem for å gjøre tjenester tilgjengelig for gjenbruk. Det er skissert løsninger som støtter sikker kommunikasjon på flere plan, WS standardene, IAM (autentiseringsløsninger), kryptering og sonebasert tilgang til tjenester er noen eksempler. Andre implikasjoner/konsekvenser I migreringsplanen er det identifisert en del aktiviteter som må gjennomføres for å bygge opp under dette prinsippet. ilotprosjekt for utveksling av tjenester på tvers av regioner er ett som er nærliggende å trekke frem. 4.2.2.3 Semantisk interoperabilitet Med semantisk interoperabilitet menes evne til samhandling basert på felles forståelse av innholdet i informasjon som utveksles mellom systemer og i prosesser. Tilnærming i arkitekturen En av bærebjelkene i arkitekturen er en logisk informasjonsmodell som går på tvers av virksomhetsområder og fagdisipliner. Modellen er motivert i behovet for felles forståelse av begreper og strukturer. Denne informasjonsmodellen er harmonisert mot HL7 versjon 3 som også er anbefalt som standard i alle tjenestegrensesnitt, dvs. for all utveksling av informasjon. Videre er nasjonale varianter på sikt anbefalt avviklet. Andre implikasjoner/konsekvenser Deler av EJ standarden (del 3) berører sentrale områder knyttet til informasjon om behandling av pasienter i spesialisthelsetjenesten. Standarden må vurderes i lys av arkitekturens anbefaling om bruk av HL7 versjon 3. Detaljer i denne verifikasjonen gjenstår og er lagt inn som en aktivitet i migreringsplanen. 4.2.3 Forsvarlig tilgang til informasjon Arkitekturen skal understøtte at alle medarbeidere får tilgang til den informasjonen de trenger på en effektiv og hensiktsmessig måte. I dette ligger det også at man skal begrense tilgangen til informasjon som de ikke skal se. Alle informasjonselementer skal presenteres slik at det er lav risiko for feiltokninger og misforståelser. Bakgrunn Brukere av IT-systemer forholder seg til en stor mengde systemer og informasjon i disse. Arkitekturen må støtte at brukerne får tilgang til relevant informasjon raskt, basert på deres rettigheter, arbeidssituasjon og fullmakter. Tilnærming i arkitekturen Arkitekturen skisserer bruk av IAM (Identity and Access Management) løsninger for autentisering av brukere og teknologi for støtte at brukere logger seg på bare en gang (SSO Single Sign-On). En løsning for rollestyrte arbeidsflater er beskrevet. Arbeidsflaten skal for eksempel til enhver tid huske hvilken pasient brukeren jobber med (kontekst sensitiv). Informasjonssikkerhetsløsninger for tilgangskontroll basert på kobling mellom funksjon og rolle er også belyst. Krav til tilgangsstyring, redigering og sletting av journalinformasjon baseres på KITH EJ standardens del 2. Andre implikasjoner/konsekvenser Informasjonssikkerhetsløsninger for spesialisthelsetjenesten møter spesielt store utfordringer knyttet til at personell skifter funksjon veldig raskt og hyppig. Dette gjelder for eksempel leger som tar vakter for hverandre, I migreringsplanen er det beskrevet en aktivitet for å pilotere dette aspektet opp mot en IAM løsning. God håndtering av dette behovet er en kritisk suksessfaktor for løsningene for tilgangsstyring. 21