Tjenesteorientert arkitektur i spesialisthelsetjenesten

Transkript

1 Tjenesteorientert arkitektur i spesialisthelsetjenesten Hovedrapport kort versjon Nasjonal IKT

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

3 Forord, Nasjonal IKT gjennomførte i 2004/2005 et forprosjekt som anbefalte å etablere en felles systemarkitektur for spesialisthelsetjenesten. rosjektet ble startet opp 21.september 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

4 Innholdsfortegnelse 1 Innledning og bakgrunn Overordnet formål Omfang og avgrensninger Virksomhetsmål og -strategi Funksjonsfordeling mellom helseforetakene og oppgavefordeling mellom nivåene Bedre elektronisk samhandling Fellestjenester Effektiv ressursutnyttelse Kvalitet på pasientbehandling asientfokus Hovedtrekk i foreslått arkitektur Informasjonsharmonisering Fra monolitter til tjenester Fellestjenester på forskjellig nivå Komponering av prosesser Rollestyrte arbeidsflater Tjenestebuss realisert Informasjonssikkerhet Fremtidens systemlandskap Arkitekturprinsipper Karakteristikk og kvalitet rinsipper Andre viktige designprinsipper Organisering, styring og videre arbeid Organisering Forvaltning og utvikling av arkitekturen Gradvis tilnærming til tjenesteorientert arkitektur Forslag til videre arbeid Vedlegg: Anbefalinger i arkitekturen 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

5 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 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

6 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 ( ) 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

7 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

8 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

9 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

10 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

11 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

12 3.1 Informasjonsharmonisering 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

13 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

14 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

15 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

16 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

17 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

18 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. 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

19 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

20 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 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

21 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 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 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 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

22 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 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 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

23 4.2.4 Endringsevne og fleksibilitet Endringsevne i denne sammenheng handler om IT løsninger og deres evne til å støtte virksomhetsendringer. Bakgrunn Spesialisthelsetjenesten er i kontinuerlig endring, både på faglig og organisatorisk side. Arkitekturen må understøtte og legge til rette for slike endringer, og ikke virke som en begrensning for endring. Dette gjelder både sett i forhold til kostnader og kalendertid. Tilnærming i arkitekturen Ny arkitektur er tjenesteorientert. Dette betyr at funksjonalitet er inndelt i distinkte tjenester som på øverste nivå gjenspeiler virksomhetens tjenesteproduksjon. Arbeidsprosesser involverer flere tjenester og modelleres på toppen av tjenestene. Endring av en arbeidsprosess medfører kun endring av prosessmodellen, ikke selve tjenesten. Tilsvarende vil endret tjenesteproduksjon enten medføre endring av en tjeneste eller at en ny blir tilført. Ikke endring av alle tjenester. å denne måten isoleres effekten av endringer til kun der den er relevant. Andre implikasjoner/konsekvenser For å lykkes med tjenesteorientering er det svært viktig at tjenesteinndelingen blir noenlunde riktig, at tjenestene etableres på riktig nivå. Videre er harmonisering av informasjonsmodeller av stor betydning. I migreringsplanene er det lagt inn aktiviteter knyttet til etablering av fellestjenester. Det er også lagt inn en del tiltak for å sikre nasjonal tilpasning og implementering av HL7 versjon 3. Videre er den nye arkitekturfunksjonen i Norsk Helse IKT tillagt en rolle for aktiv medvirkning i tjenesteetablering gjennom sin kvalitetssikringsfunksjon og ansvar for forvaltning av overordnet arkitektur Leverandøruavhengighet Arkitekturen skal ivareta at det ikke oppstår spesielle bindinger til en eller flere leverandører. Med spesielle bindinger menes manglende valgfrihet av leverandører eller løsning/teknologi som kunne vært unngått med annen oppdeling av løsninger, teknologivalg, bruk av bransjestandarder eller avtaler. Bakgrunn Leverandøravhengighet er i seg selv uheldig i og med at valgfriheten reduseres. Det betyr ofte at maktforholdet mellom kunde og leverandør er skjevt, for stor leverandørmakt og for liten kundemakt. I mer ekstreme sammenhenger kan man også oppleve at kunde og leverandør ikke er enig om mål og strategi for en gitt løsning. Leverandøren kan være orientert mot å beholde sin posisjon, mens kunden er opptatt av økt valgfrihet. I sum betyr ofte dette at leverandøravhengighet er kostnadsdrivende og reduserer endringsevnen. Tilnærming i arkitekturen Den nye arkitekturen beskriver hvordan de store tunge fagsystemene skal brytes opp i tjenester som kan leveres av mange. Videre beskriver arkitekturen et konsept kalt tjenestebuss for å gjøre tjenester tilgjengelig. Arkitekturen setter krav til at denne bussen skal være levert av noen andre enn de som leverer tjenester. I praksis betyr dette en leverandør og at spesialisthelsetjenesten selv har ansvaret for å operasjonalisere konseptet, på nasjonalt, regionalt og lokalt nivå. Dette er foreslått for å unngå at en leverandør av tjenester skal kunne styre de tekniske rammebetingelsene for andre leverandører av tjenester. Arkitekturen anbefaler bruk av åpne standarder og åpen teknologi der det finnes, dette vil også redusere leverandørbindinger. Andre implikasjoner/konsekvenser Dialogen mellom fagmiljøene på leverandør- og kundesiden bør økes. I migreringsplanen ligger det derfor et forslag om etablering av et faglig fora. Videre må det lages retningslinjer for implementering av HL7 versjon 3 som bl.a. håndterer norske tilpasninger. Tjenestebusskonseptet må omsettes i kjørbar teknologi. Dette er forslått gjort på 22

24 lokalt/regionalt nivå, der tjenesteproduksjonen er. Det må lages retningslinjer og krav for implementering av denne infrastrukturen slik at samhandling sikres (teknisk interoperabilitet) Gjenbruk av informasjon gjennom tjenester Informasjon er en felles ressurs og skal betraktes som delt og gjenbrukbar. I arkitekturen gjenbrukes ikke bare informasjon, men også tjenester. Deler av organisasjonen utveksler tjenester seg i mellom. Et laboratorium som analyserer en prøve tilbyr analysen som en tjeneste. Tjenesten inneholder både rekvisisjon (informasjon), prosess (som er skjult for de som bruker tjenesten) og resultat (informasjon). Altså deles ikke bare informasjon, men også funksjon. Bakgrunn Informasjon om det samme lagres i mange systemer uten at man har et klart forhold til hvor originalen befinner seg. Det finnes ofte ingen oversikt over hvor kopier befinner seg. Oppdatering av endret informasjon blir svært vanskelig. Dersom Meldingsløftet implementeres gjennom digitalisering av enda flere meldinger til/fra systemer forventes det å bidra til ennå større grad av informasjonsforvitring. Samme funksjon utøves av mange systemer og ofte også mange steder i organisasjonen. Fellestjenester finnes ikke, eller kan vanskelig benyttes fordi de er implementert i en spesiell sammenheng (kontekst). Tilnærming i arkitekturen Informasjon skal tilbys gjennom tjenester. Fellestjenester etableres der hvor to eller flere har behov. Det tas stilling til hvem som eier prosessen som en gitt fellestjeneste representerer. Eierskap til informasjon som kreves for at denne prosessen skal kunne gjennomføres ligger normalt der prosesseierskapet ligger. Eierskap til resultatet av en fellestjeneste kan eies av andre. For eksempel vil eierskapet til et prøvesvar og spesialistens vurdering ligge i forløpsjournalen, ikke i laboratorietjenesten. (Laboratorietjenesten vil imidlertid kunne eie data som er nødvendig for å gjennomføre tjenesten, bestilling/rekvisisjon, prøve, grunndata osv.) I den nye arkitekturen utøves samhandling ved hjelp av tjenester (tjenesteorientering), ikke oversendelse av informasjon (meldingsorientering). Tjenester etableres slik at behovet for meldingsutveksling reduseres autonome tjenester. Tjenester modelleres slik at de kan fungere uavhengig av sammenheng (kontekst), dermed oppnås økt gjenbruk. I arkitekturen vil intensjonene bak Meldingsløftet nås gjennom modellering av samhandlingsprosesser som er satt sammen av tjenester, ikke ved å sende dagens skjemaer i elektronisk form mellom organisasjonsenheter. I denne sammenheng er det imidlertid viktig å være klar over at arkitekturen ikke gis tilbakevirkende kraft, ingen løsninger som er laget skrives om alene fordi de bryter med prinsippene i ny arkitektur. Andre implikasjoner/konsekvenser I migreringsplanen er det lagt inn flere aktiviteter for å identifisere fellestjenester. Dette gjelder utvidelse og foredling av arkitekturens funksjonelle omfang og aktiviteten Etablere fellestjenester. Utover dette er det svært viktig at erfaringer fra prosjekter som bedriver tjenesteorientering bringes videre i organisasjonen. Her vil de respektive arkitekturfunksjonene på nasjonalt, regionalt og eventuelt lokalt nivå måtte bidra. Tjenesteorientering blir ikke til av seg selv Kontrollere teknologivariasjoner Variasjoner innen teknologiske valg skal kontrolleres for å minimere kostnader knyttet til kompetansespredning og drift. Teknologiplattformen er under kontinuerlig utvikling, formålet er å ivareta at teknologiske valg er i samsvar med utviklingsplan for plattformen. Bakgrunn 23

25 Det er kostnadsdrivende å ivareta kompetanse og driftsmiljø for et stort antall ulike teknologiplattformer. En kontrollert prosess rundt strategi for innføring av nye og utfasing av gamle teknologier kan redusere kompleksitet og spisse kompetanse på færre teknologier. Tilnærming i arkitekturen Arkitekturen foreslår harmonisering av teknologi basert på åpne standarder og åpen teknologi der hvor dette er formålstjenelig. Videre foreslås harmonisering av teknologikomponenter på passende nivå. Et eksempel på dette er anbefalingen om at tjenestebuss konseptet fysisk implementeres på lokalt nivå, men basert på minimum en regional standard. Tilsvarende at IAM løsningen etableres basert på en teknologi valgt på nasjonalt nivå, men implementert lokalt. Andre implikasjoner/konsekvenser Det skal etableres teknologistrategier og planer på regionalt nivå som beskriver nåværende teknologiplattform og kriterier for utvikling av plattformen fremover. Innføring av nye teknologier sees i forhold til teknologistrategien. Det skal finnes en strategisk prosess for å fase ut gamle teknologier Kontrollere funksjonell redundans Gjenbruk av eksisterende funksjonalitet gjennom for eksempel tjenester er foretrukket fremfor utvikling av parallell funksjonalitet som benyttes kun av et begrenset sett med enheter innen virksomheten. Bakgrunn Duplisering av funksjonalitet er kostbart, og kan føre til inkonsistent bruk av informasjon og regler innenfor en virksomhet. Tilnærming i arkitekturen Ref. ovenfor om Gjenbruk av informasjon gjennom tjenester. Andre implikasjoner/konsekvenser Når et nytt eller endret funksjonelt behov oppstår, må det iverksettes en prosess for å identifisere om funksjonaliteten allerede eksisterer i porteføljen. Ansvaret for prosessen inngår som en del av ansvaret til arkitekturfunksjonen på dertil passende nivå. Enheter innen virksomheten skal ikke tillates å utvikle funksjonalitet som ene og alene er duplikater av funksjonalitet allerede implementert i virksomheten Horisontalt og vertikal konsolidering Begrepet konsolidering relateres i denne sammenheng til etablering av tjenester. Med horisontal konsolidering menes at man søker konsolidering i en prosess, for eksempel innenfor en region. Med vertikal konsolidering tenkes på at tjenester av samme type innenfor og på tvers av prosesser og organisasjoner ønskes konsolidert i fellestjenester, for eksempel på nasjonalt nivå. Bakgrunn Organisasjoner har lang erfaring fra prosessoptimalisering basert på forenkling og konsolidering av horisontale prosesser. Endring av rekkefølge, automatisering av delprosesser og endring av ansvarsforhold er brukte virkemidler. Vertikal konsolidering handler om å etablere fellesfunksjoner på tvers av virksomhetsområder. Økonomi og service funksjoner er eksempler på slik konsolidering. I en tjenesteorientert arkitektur benyttes dette tankesettet på oppgaver som gjøres gjentatte ganger i flere prosesser innenfor og på tvers av foretak. Eksempler er identifikasjon av person/pasient, autentisering av bruker, folkeregistertjenester, bruk av en mulig ny offentlig dødsfallsprosess, osv. Tilnærming i arkitekturen 24

26 Tankesettet bak tjenesteorientering er basert på at begge prinsipper benyttes, både vertikal og horisontal konsolidering av prosesser og tjenester. Etablering av fellestjenester er et eksempel på vertikal konsolidering. Arkitekturen legger opp til standardisering på BMN og bruk av BMS som teknologi for å få til modelldrevet prosessdesign. Dette vil på sikt bidra til optimalisering og konsolidering av prosesser innenfor spesialisthelsetjenesten. Arkitekturen omfatter prosessorienterte løsninger på tvers av tjenester, systemer og organisatoriske grenser, noe det er et stort behov for i spesialisthelsetjenesten. Andre implikasjoner/konsekvenser I migreringsplanene legges det opp til at det må jobbes videre med etablering av fellestjenester. Det må etableres arkitekturer på regionalt nivå, dette vil bidra til at prosessene dokumenteres og at arbeidet med optimalisering sett fra IT siden kan komme i gang. Det er også lagt inn en aktivitet for etablering av felles prosessdokumentasjon på nasjonalt nivå. Denne aktiviteten forventes å gi økt kunnskap om viktige prosesser i spesialisthelsetjenesten og økt gjenbruk på tvers av foretak. Arbeidet med standardisering av behandlingslinjer vil identifisere behov for fellestjenester som arkitekturen bør ivareta Modne standarder og teknologier IT-løsninger må benytte kommersielt vellykkete standarder og standardbaserte teknologier. rodukter og løsninger som baserer seg på industristandarder og åpne standarder skal foretrekkes. Tilpasninger til nasjonale eller lokale forhold bør unngås så langt det er mulig. Bakgrunn: Det finnes i dag et stort antall konkurrerende teknologier og standarder, som benyttes for implementering av IT-løsninger i helsesektoren. Spesialisthelsetjenesten i Norge er i stor grad avhengig av løsninger som tilbys i det internasjonale markedet, og er i seg selv ikke stor nok til å utvikle og vedlikeholde egne sett med standarder. For å redusere kostnader ved implementering av løsninger, skal arkitekturen basere seg på internasjonalt anerkjente standarder for informasjon og teknologi. Tilnærming i arkitekturen: Arkitekturen legger opp til å implementere løsninger og tjenester basert på industristandard teknologier som Web Services og HL7 versjon 3. Utvikling av nasjonale standarder nedprioriteres i forhold til å utvikle profiler og implementeringsguider for internasjonale standarder. Andre implikasjoner/konsekvenser: Økt fokus på internasjonale standarder blant norske leverandører. Redusert omfang av lokale tilpasninger og egenutvikling der det finnes etablerte standarder. Bedre samhandling mellom systemer. Redusert kompetansebehov for et potensielt stort antall standarder og teknologier. Bør medføre et arbeid for å identifisere levetid på standarder, og påfølgende migreringsarbeid mellom standarder eller versjoner av disse. I tilfeller der norske behov ikke er en del av internasjonale standard må det arbeides for å påvirke den internasjonale standarden. 4.3 Andre viktige designprinsipper I det følgende er listet en del designprinsipper som bør inngå i en nasjonal IKTstyringsmodell, ref. kapittel 5 Organisering, styring og videre arbeid. Det følger av innledningen i dette kapittelet at prinsippene for styring i og forvaltning av IKT i spesialisthelsetjenenesten vil kunne suppleres etter hvert ålitelighet, skalerbarhet og robusthet Arkitekturen skal ivareta virksomhetens krav til pålitelighet, robusthet og skalerbarhet i applikasjonsporteføljen. 25

27 Bakgrunn Med økende grad av digitalisering av spesialisthelsetjenestens prosesser er pålitelighet, skalerbarhet og robusthet av systemene stadig viktigere. Samtidig er det ressurskrevende å bygge alle systemer for katastrofesikret drift og således er det viktig å identifisere den enkelte tjenestes krav til pålitelighet, skalerbarhet og robusthet. Implikasjoner Tjenester skal kategoriseres i forhold til krav til pålitelighet, skalerbarhet og robusthet. Det skal finnes en entydig definisjon av krav til overnevnte Funksjonelt drevet endringsprosess Bakgrunn Endringer i arkitekturen skal følge endrete funksjonelle behov eller endrete strategier. Implikasjoner Det er behovet for funksjonelle endringer som fører til endringer i arkitekturen. Endringsprosess skal ikke iverksettes utelukkende som følge av endringer i tekniske muligheter. Virksomheten skal alltid involveres i endringsprosesser Effektiv endringshåndtering Bakgrunn Endringer i organisering, funksjonelle behov eller teknologiske muligheter kan medføre at målarkitekturen må gjennomgå en endringsprosess. Det kan også være funksjonelle områder som ikke er fullt ut dekket av målarkitekturen. For å unngå at prosjekter eller initiativ iverksetter aktiviteter som ikke er koordinert mot en målarkitektur må endringsbehov raskt behandles av arkitekturansvarlige. Implikasjoner Arkitekturen må være underlagt et opplegg for forvaltning og videreutvikling. Deler av dette er beskrevet nærmere i kapittelet om Organisering, styring og videre arbeid. ortefølje- og prosjektforvaltning må ta høyde for arkitekturforvaltning. 26

28 5 Organisering, styring og videre arbeid Arbeid med utvikling av arkitektur for spesialisthelsetjenesten er en kontinuerlig prosess i tråd med utvikling av tjenestetilbud og virksomheten for øvrig. Det vil si at det å jobbe med arkitektur ikke er noen selvstendig aktivitet, men en del av den totale virksomhetens aktivitet. Arkitekturen for spesialisthelsetjenesten er en delmengde av arkitektur for hele helsetjenesten. Det er derfor viktig at videreutvikling av arkitektur for spesialisthelsetjenesten forankres mot helsetjenesten som helhet. Det foreligger nå planer om etablering av en ny organisasjon, eid av de regionale helseforetakene, som skal ivareta IKT oppgaver på tvers av helseforetak i spesialisthelsetjenesten. Organisasjonen har foreløpig fått navnet Norsk Helse IKT. Dette er beskrevet i Nasjonal IKT: Langsiktig organisering av IKT-området. Det anbefales at forvaltningen av nasjonal arkitektur for spesialisthelsetjenesten legges til foreslått arkitekturfunksjon i Norsk Helse IKT (beskrevet i seksjonen nedenfor). rosesser og styringsmodeller for forvaltning av arkitektur på ulike nivåer i organisasjonen må etableres og følges opp og det bør innføres et rammeverk for videreutvikling og forvaltning av arkitekturen. 5.1 Organisering For å få til god implementering og forvaltning av arkitekturen er det viktig at man etablerer en organisasjon som er tett på det som skjer i virksomheten. Et stort antall prosesser i spesialisthelsetjenesten starter og slutter utenfor spesialisthelsetjenesten. Videre er samarbeidet mellom helseforetakene og sykehusene omfattende f.eks. i et konkret pasientforløp. Dette krever at arkitekturer må koordineres og synkroniseres på helsenivå, på tvers av regioner og innenfor hver region. Ansvaret for dette må forankres i organisasjonen slik at arkitekturer på ulikt nivå forankres på tilhørende nivå og at synkroniseringsansvar til enhver tid ligger på et overordnet nivå. Arkitekturfunksjonen innen Norsk Helse IKT bør i første omgang ta ansvar for arkitekturen i spesialisthelsetjenesten og grenseflatene opp mot denne. Internasjonale forpliktelser og nasjonale føringer Samhandling og felles grenseflater innen et gitt område - ex. justis eller helse. Lokal arkitektur basert på forretningskrav ved den enkelte institusjon Figur 10 Nivåer av arkitektur, ref. FAD De ulike nivåene i arkitekturen er illustrert i figuren og nærmere beskrevet i FAOS rapporten, Fornyings- og administrasjonsdepartementet, desember 2007: Felles IKT-arkitektur i Offentlig Sektor. 27

29 Alternative organiseringer: 1. Fast ansatte arkitekter Arkitektfunksjonen er lokalisert ved en sentral enhet i helsesektoren. Dette kan være i Norsk Helse IKT som beskrevet i egen utredning, eller i for eksempel direktorat/ departement. Norsk Helse IKT er det naturlige valget for lokalisering av funksjonen hvis den skal ha ansvar for arkitekturen knyttet til spesialisthelsetjenesten. 2. Nettverksmodell Arkitekter er ansatt i lokale og/eller regionale foretak. Det opprettes et nettverksbasert forum forankret i en sentral aktør (Norsk Helse IKT eller Helsedirektoratet) som har ansvar for forvaltning av arkitekturen i spesialisthelsetjenesten. Arkitekter som skal delta i forumet oppnevnes med dedikert tid til nasjonalt arbeid. Disse kan oppnevnes på åremål eller etter andre kriterier. 3. Kombinasjon av 1 og 2 En kombinasjon med en fast organisering av et sekretariat og 2 3 arkitekter, samt et nettverk av arkitekter fra foretakene. Arkitektene fra foretakene og sentralt ansatte må være likeverdige medlemmer. Arkitektene fra foretakene må ha definert en %-del (30-50%) av sin stilling til dette arbeidet som finansieres gjennom den nye organisasjonen. Arkitekturfunksjonen bør ha kapasitet på 5-8 årsverk uavhengig av organisering. Dette kommer i tillegg til eksisterende arkitekturfunksjoner i HF / RHF. Det er viktig at den sentrale og de lokale arkitekturfunksjonene sees på som en samlet enhet arkitekturfaglig, og bidrar til at det finnes fora og metoder for koordinering og synkronisering på faglig nivå. Dette gjelder også for helsefaglige arkitekturproblemstillinger utover spesialisthelsetjenesten. Det anses som en fordel at det finnes arkitekter som har hele helsetjenesten som ansvarsområde. Fordeler Ulemper 1 Fast ansatte arkitekter Sentral styring av ressurser Sterkere styring av overgripende prosjekter Kan bygge sektorovergripende kompetanse Kontinuitet Fjerner seg fra foretakene som operative leverandører av helsetjenester Redusert forankring i foretakene Høy risiko for forvitring av (virksomhets)kompetanse pga avstand til kjernevirksomheten. 1a - I regi av Norsk Helse IKT Nærhet til strategisk arbeid i regionalt foretak Mangler formell beslutningsmyndighet utenfor spesialisthelsetjenesten. 1b - I regi av departement/ Har formell beslutningsmyndighet Ytterligere tap av nærhet til foretak Direktorat 2 Nettverksmodell Ivaretar nærhet til foretak Kan rullere kompetanse (åremålsmodell) 3 Kombinasjon av 1 og 2 Formalisere prosess. Sikre framdrift og noe forutsigbar kapasitet knyttet til arkitekturarbeid og deltagelse i prosjekter. (kan bli en stat i staten) Begrenset nasjonal beslutningsmyndighet. Avsatt tid til nasjonalt arbeid (inkl finansiering). Opplæring og metodikk Kan oppfatte seg selv som representanter for regioner/foretak i stedet for en autonom nasjonal gruppe Mer komplisert organisasjonsstruktur Kan oppfatte seg selv som representanter for regioner/foretak i stedet for en autonom nasjonal 28

30 Fordeler Ulemper Sikre forankring p.g.a. både faste gruppe ansatte og deltagere fra RHF/HF. Funksjonen må delta i viktige og/eller større prosjekter for anskaffelse av nye løsninger, virksomhetsutvikling hvor IT spiller en viktig rolle, større sykehusutbyggingsprosjekter og strategiarbeid i regi av HOD, HDir, RHF etc. Det siste er spesielt viktig for at man skal kunne være i forkant med arkitekturarbeidet slik at en oppnår de mål en ønsker. Arkitekturfunksjonen skal delta i styring av prosjekter (lokalt og regionalt) for å sikre at arkitekturmålsetningene blir vektlagt og fulgt opp i hele prosjektløpet. Arkitekturkrav må inn i prosjektplanene på lik linje med funksjonelle mål. Kompetansekrav: Arkitekturfunksjonen skal ha kompetanse på følgende områder Virksomhetskompetanse bred kompetanse på helsetjenesten i Norge arkitekter Modelleringskompetanse spesielt i forhold til vedlikehold av informasjons-, prosessog tjenestemodeller. Detaljeringsoppdrag kan settes ut, men for å kunne inneha det overordnede ansvaret, må organisasjonen besitte kompetanse på området Standardiseringskompetanse enheten skal ha ansvaret for standarder som skal benyttes i spesialisthelsetjenesten og på grenseflatene mot denne. Enheten må ha kompetanse på og følge opp utvikling av disse standardene, spesielt videreføring av de standardene som er anbefalt i arkitekturen. Enheten bør ikke utvikle standarder/ implementeringsguider i detalj, men benytte seg av eksisterende kompetansemiljø på dette. Teknologikompetanse spesielt innenfor teknologier for integrasjon av programvare, informasjonssikkerhet og systemarkitektur. En viktig forutsetning for å lykkes med en slik sentral funksjon, er at det også finnes personer med spesielt ansvar for lokal arkitektur i foretakene eller på regionsnivå. Dette for å sikre samspillet mellom det nasjonale nivået og det som de enkelte foretakene har av lokale tilpasninger til arkitekturen. Det bør også finnes noe tilsvarende innenfor primær- og kommunehelsetjenesten. Ansvarsområder Arkitekturfunksjonen tillegges følgende ansvarsområder: Utvikling og vedlikehold av arkitektur for spesialisthelsetjenesten og grensesnitt mot eksterne aktører. Utvikle og forvalte et arkitekturrammeverk basert på en eksisterende standard Faglig støtte i forbindelse med utarbeidelse og revisjon av migreringsplaner Kompetansetiltak for arkitekter i helseforetakene og gi et tilbud for arkitekter som jobber med arkitektur knyttet til helsesektoren Trendovervåkning i forhold til andre sektorer i Norge og internasjonalt. Standardisering av verktøy, modeller og notasjoner for beskrivelse av virksomhetsprosesser, informasjons og tjenestemodeller Deltagelse i internasjonale fora som jobber med standarder innenfor helse (HL7, IHE - Integrating the Healthcare Enterprise, etc.) Videreføring av NIKT fagforum for arkitektur sitt mandat Tett samarbeid med EJ fagforum og KITH knyttet til forvaltning av kodeverk Tett samarbeid med EJ fagforum og tilsvarende fora fra andre deler av virksomheten i forhold til å framskaffe og vedlikeholde virksomhetsmodeller Delta i kvalitetssikringen av at prosjekter følger den nye arkitekturen, proaktivt ved deltagelse i prosjektene og reaktivt ved revisjon på viktige milepæler. Håndtering av avvik knyttet til arkitektur. 29

31 Finansiering / økonomiske midler Kostnader til selve driften av funksjonen bør inngå i organisasjon Norsk Helse IKT. I tillegg må man ha en finansiering av prosjekter som er nødvendige å gjennomføre. I første driftsår er det behov for ca 15 millioner og dette må øke etter hvert. Det er spesielt viktig at enheten er i stand til å identifisere og gjennomføre prosjekter knyttet til utforming av standarder og gjennomføring av standardiseringsprosjekter knyttet til migrering av systemporteføljen mot føringer i arkitekturen. Eksempler på dette kan være utvikling av standard tjenester for integrering av spesialistsystemer mot EJ. I arkitekturen er det flere elementer som vil tjene fellesskapets og/eller pasientens beste. Noen av elementer vil være for kostnadskrevende å få på plass for en aktør alene. Det vil være naturlig at den sentrale funksjonen identifiserer slike forhold og har økonomiske midler til å realisere adekvate løsninger. 5.2 Forvaltning og utvikling av arkitekturen Utviklingen av arkitekturen må sees i sammenheng med utviklingen av virksomheten. Dette er også forankret i arkitekturprinsippet Funksjonelt drevet endringsprosess. Figur 11 TOGAF rammeverket For å forvalte arkitekturen videre er det nødvendig å etablere spesialisthelsetjenestens metodikk, også kalt et arkitekturrammeverk. En slik metodikk som er internasjonalt anerkjent er TOGAF rammeverket, som er illustrert i figuren ovenfor. Den viser at de funksjonelle og virksomhetsmessige behovene er sentrale, men at det er gjensidig påvirkning av disse fra mange områder bl.a. eksisterende systemer og teknologi, vedtatte planer og nye løsninger og teknologier, deriblant trender. Typisk vil en endring i strategi for virksomheten kreve en vurdering av hvilke implikasjoner dette har for arkitekturen. Vurderingen vil identifisere om det er behov for endringer i 30

32 informasjonsarkitektur, tjenestearkitektur, teknologiarkitektur etc, og i tillegg evaluere om teknologien har gitt nye muligheter for å støtte disse nye strategiene. Gjennom arbeidet med arkitekturen er det identifisert at nye strategier / oppdrag fra Helse- og omsorgsdepartementet, Helsedirektoratet, foretakene, nye behandlingsmåter, endret funksjonsfordeling, utvikling i medisin og ny teknologi er de områdene som påvirker arkitekturen i størst grad. For å kunne utvikle arkitekturen i tråd med endringer i virksomheten, må den gå gjennom flere steg i en syklus og syklusen må være repeterende. Det må defineres en styringsmodell for vedlikehold og videreutvikling av arkitekturen, dette drøftes under kapittel 5.1 Organisering. Figuren under eksemplifiserer sammenhengen mellom de forskjellige deler av arkitekturarbeidet og fordeling av ansvar. Figuren under er ment som et eksempel og det den illustrerer må utvikles videre av den nye arkitekturfunksjonen. Norske Helse IKT Styre Norsk Helse IKT Arkitektur HF/RHF Utarbeide mandat arkitektur - arbeid Utarbeide mandat arkitektur - arbeid Utarbeide felles retningslinjer/prin sipper for arkitektur (1) Godkjenne felles retningslinjer/ prinsipper for arkitektur Kartlegge baseline samhandlngsarktitektur Definere nasjonalt målbilde samhandlingsarkitektur for spes.helse Godkjenne nasjonalt målbilde samhandlingsarkitektur for spes.helse GA- analyse: Identifisere viktige prosjekter for samhandling Godkjenne lokalt målbilde VA Godkjenne roadmap samhandlings - prosjekter Godkjenne roadmap lokale prosjekter Sikre implementering i tr åd med arkitektur. HF/RHF Arkitektur Kartlegge baseline VA Definere lokalt målbilde VA -basert på NIKTs målbilde GA- analyse: Identifisere viktige lokale prosjekter Sikre implementering i tr åd med arkitektur. Beslutning Tid Utredning Figur 12 Arkitektur koordinering tverrsektorielt Den nye organisasjonen for arkitektur må vurdere innføring av et arkitekturrammeverk og eventuell verktøystøtte for dette. Aktiviteten er ligger i forslaget til migreringsplan nedenfor. 5.3 Gradvis tilnærming til tjenesteorientert arkitektur Tjenesteorientert arkitektur bygges stegvis og det er ikke nødvendig å gjøre alt til tjenester for å oppnå fordelene med ny arkitektur. Verdien for spesialisthelsetjenesten kommer gradvis etter hvert som stegene tas. Migreringsaktiviteter bør prioriteres ut fra måloppnåelse/effekt og kostnad. I Figur 13 skisseres en prinsipiell tilnærming til migreringsforløpet i flere steg. Ulike regioner og foretak kan være på forskjellige steg samtidig, og at et foretak kan gjennomføre aktiviteter som tilhører ulike steg på samme tid. Figuren skal altså ikke oppfattes som en plan 31

33 Figur 13 Gradvis/trinnvis tilnærming til tjenesteorientert arkitektur 1. Store monolitter av fagapplikasjoner som for eksempel AS og EJ. Flere av disse har ikke flerlags systemarkitektur. Tildels overlappende funksjonalitet mellom applikasjonene, samme funksjonen utføres i flere applikasjoner. I tillegg finnes det en lang rekke mindre applikasjoner som i sum utgjør den elektroniske pasientjournalen (EJ) og enda flere for å understøtte tjenester som leveres inn i behandlingsprosessene. Grensesnittene er dårlig utbygget og det koster å få til integrasjon med omkringliggende systemer. De fleste foretakene er på dette nivået i dag. 2. Fagsystemleverandørene tilbyr tjenester basert på Web Services fra sine applikasjoner. Fortrinnsvis ønsker man at grensesnittene følger internasjonale standarder. (Noen leverandører er allerede i ferd med å levere på dette nivået.) Samtidig saneres en del applikasjoner som utfører lik funksjonalitet. Noen regioner/foretak er delvis på dette nivået i dag. rinsipiell løsning er beskrevet i Vedlegg I sammen med kandidater til de tjenester som EJ/AS og tilknyttete løsninger er avhengige av for å få til god samhandling, eksempler: asientidentitet/demografiske pasientdata, Viktig medisinsk informasjon, Kontaktoversikt og diagnose, Forløpsinformasjon og historikk, Organisasjon, Ressursplanlegging. Man begynner å presentere funksjonalitet for tjenester i en felles klinisk arbeidsflate. 3. Tjenester fra fagsystemene, nye tjenester og fellestjenester tilbys på tjenestebuss. Harmonisering er godt i gang på informasjonsmodeller, tjenestegrensesnitt og teknologi. HL7 versjon 3 er for eksempel etablert som standard for all datautveksling. Overlappende funksjonalitet er i stor grad faset ut. Informasjonssikkerhetsutfordringene ved samhandling innenfor og på tvers av foretak er løst. 4. All funksjonalitet leveres og konsumeres som naturlig inndelte autonome tjenester. All redundant funksjonalitet er fjernet. Alle tjenestegrensesnitt er standardisert med bruk av internasjonale og nasjonale standarder på alle nivå. Begreper som applikasjon og system er visket litt bort og man sitter igjen med samling av tjenester som fleksibelt kan settes sammen på nye måter etter behov og etter endring i virksomheten. All funksjonalitet tilbys gjennom en brukerflate, tilpasset den enkelte brukers behov knyttet til situasjon og rolle og henger sammen med prosessene i virksomheten. Systemeiere er erstattet av prosessansvarlige i virksomheten. 32