Tiltak 12. Tiltak 12, Forprosjekt Nasjonal Arkitekturstrategi. Notat. Rapport. Versjon Åpen

Transkript

1 Tiltak 12 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi Ntat Rapprt Versjn Åpen

2 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi Innhldsfrtegnelse 1. INNLEDNING 5 Bakgrunn Målgruppe Presentasjn av prsjektgruppen Relasjn til andre tiltak Avgrensninger Dkumentets ppbygning Ordliste Oppsummering 9 2. KARTLEGGING AV DAGENS STATUS Bakgrunn Dagens løsninger Dagens integrasjnsløsninger Helse Nrd Helse Midt-Nrge Helse Sør Helse Vest Helse Øst Arkitektur Helse Nrd Helse Midt-Nrge Helse Sør Helse Vest Helse Øst Nasjnal arkitektur 18 Side 2 av 41

3 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi 2.5 Leverandørstatus KARTLEGGING AV UTVALGTE PROSESSER Akuttrg hs Sykehuset Buskerud GEVINSTOMRÅDER Innledning FELLES ARKITEKTUR I HELSE-NORGE Innledning Andre initiativ Sektrarkitektur Samhandling g integrasjn Infrmasjnsmdell Nasjnale standarder Sikkerhet PKI Data integritet Fellestjenester Begrensninger i lver, regler g pålegg Samrdnet presentasjn Prsess kntra system KONKLUSJON/ANBEFALING Innledning Prsjektgruppens anbefaling Arkitektur i et videre ffentlig perspektiv Mmenter sm bør belyses i et hvedprsjekt 37 Side 3 av 41

4 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi 6.3 Frvaltning Utøvelse av arkitekturstrategi Gjennmføring av hvedprsjekt Plan Risik Organisering Frankring Budsjett 41 Side 4 av 41

5 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi 1. Innledning Bakgrunn Helsefretakene preges av en relativt str spredning g sprik i systemprteføljen, ne gså kartlegging i denne rapprten viser. Dette er et resultat av mangel på kmplette/fullintegrerte løsninger, anskaffelser gjennmført på ulike tidspunkt g skiftende teknlgiske plattfrmer. De stre universitetssykehusene har i størst grad møtt utfrdringen med dårlig integrasjn g manglende bransjespesifikk systemarkitektur i g med sin størrelse g funksjnsbredde. Samtidig har de gså frtsatt de største utfrdringene. Utfrdringer sm nå i større grad vertas av de reginale helsefretakene i g med at det gjennmføres en mfattende standardisering av prteføljen i alle reginer. Etter helserefrmen har frhldet mellm kunder g leverandører innen helsetjenesten endret seg. Kundene er blitt større g etterlyser helhetlige løsninger sm kan utnyttes i reginalt perspektiv. Dette utfrdrer mindre leverandører sm har gde løsninger på spesifikke felt, men sm i arkitekturen blir hengende sm islerte øyer eller i beste fall løst i integrerte løsninger. En risikerer at disse vil miste ftfeste verfr leverandører med dårligere løsninger, men sm henger sammen med øvrige applikasjner. Utviklingstrekk i helsetjenesten i de neste 5 årene vil være preget av Helsefretakene frlater film g papir i dkumentasjn rundt pasient til frdel fr digitale løsninger Funksjnsdeling mellm helsefretak g helsereginer øker Endringshastigheten i helseinstitusjnene vil frtsatt øke Pasientene vil i økende grad utnytte fritt sykehusvalg g kreve mer innsyn i behandlingen Frtsatt press på å få en mer ksteffektiv pasientbehandling Utstrakt bruk av elektrnisk samhandling på tvers av helsefretak g mellm primærhelsetjenesten g spesialisthelsetjenesten Dette vil kreve It-løsninger Med høy grad av fleksibilitet fr å håndtere endringer i pasientsløyfer, arbeidsflyt g rganisasjn Sm er bygd med tanke på høyere endringshastigheter enn vi ser i dagens tilbud i markedet Sm kan skaleres fr vlumendringer under drift Sm kan håndtere endringer av funksjnalitet g ny funksjnalitet på en fleksibel måte g uten å hindre eksisterende løsningers kntinuerlige drift. Erfaringen i helsetjenesten sm i andre bransjer er at ingen enkeltleverandør kan greie å levere helheten alene. Og i helsevesenet er det sm i andre bransjer stre behv fr spesialistløsninger sm sameksisterer med hvedsystemene. Bransjespesifikke systemarkitekturer løser pp denne prblemstillingen g muliggjør helhetlige løsninger g utnytter løsninger på ulike deler fra frskjellige leverandører. Det skaper større fleksibilitet på å endre løsningen i takt med rganisasjn. Det vil gså gi mer enhetlige grensesnitt fr brukerne g minske endringskstnadene i frhld til disse. Stadig teknlgiutvikling g skifte av plattfrm er en særlig utfrdring i arbeidet med systemarkitektur fr helsefretakene. Dette krever tiltak, nye tanker fr løsninger i helse i sin helhet, sm gir større fleksibilitet g endringsmulighet. Dette krever en gjennmtenkt systemarkitektur sm et gdt fundament i etablering av nye løsninger i helsesektren. Manglende eller dårlige valg i en slik grunnmur vil påvirke mulighetene til å ppfylle de krav sm stilles til IT i helsesektren i tiden sm kmmer. Side 5 av 41

6 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi Nasjnal IKT er en gruppe sammensatt av medlemmer fra de 5 helsereginene samt helse departementet g helsedirektratet. Nasjnal IKT har iverksatt en rekke tiltak sm skal kartlegge ulike aspekter mhp. bruk av IT i helsesktren. Flere av tiltakene går på frbedret samhandling. Tiltak 12 har følgende tittel: Etablere en felles systemarkitektur fr helsefretakene sm grunnlag fr bedre samrdning g integrering av systemprteføljen I frbindelse med tiltak 12 ble det etablert et frprsjekt fr å kartlegge m det er grunnlag fr å etablere en slik felles systemarkitektur. Frprsjektet har kartlagt dagens status med fkus på: Systemer Leverandører Sikkerhet Integrasjner Samhandling Arkitektur Frprsjektet har kartlagt dagens systemprtefølje, hvrdan den benyttes g hvrdan den er integrert. Videre har frprsjektet sett på gevinstmråder m man etablerer bedre, integrerte g sikrere løsninger innen helse. Overrdnet systemarkitektur kan på mange måter sammenlignes med byplaner mens etablering av it-systemer kan sammenlignes med byggetegninger fr hvert enkelt hus. Før man starter bygging av et hus vil man alltid lage planer fr felles infrastruktur sm vei, vann, elektrisitet sv. Tilsvarende vil ingen bygge et hus uten å ha vurdert hvrdan huset skal bygges, hvrdan tmten skal utnyttes g hvrdan man skal kble seg til fellesressursene sm vann g vei. Frprsjektet g et evt. hvedprsjekt vil kunne sammenlignes med byplanen der felles infrastruktur g de stre linjer tegnes pp. 1.2 Målgruppe Dette dkumentets målgruppe er deltagere i Nasjnal IKT samt ledelsen g IT strateger i RHF g HF i Helse- Nrge. Rapprten vil gså være relevant fr de sm har ansvar fr IT løsninger fr øvrig i sektren g helsevesenet. Dkumentet er ment å gi veiledning i frhld til arkitekturprblemstillinger sm de enkelte står ver fr g være med å øke frståelsen fr prblemstillinger knyttet til arkitektur i dagens g framtidens it løsninger i Helse Nrge. 1.3 Presentasjn av prsjektgruppen Prsjektgruppen har bestått av følgende deltagere: Navn Per Olav Skjesl, Hemit Rannveig Wll, Hemit Bård Grødem, Hemit Hallgeir Lien, Sykehuset Buskerud Rger Schäffer, Ullevål Universitetssykehus Terje Jhannessen, Helse Bergen Bjørn Jacbsen, Nrdlandssykehuset HF Rlle Prsjektleder Prsjektdeltager Prsjektdeltager Prsjektdeltager Prsjektdeltager Prsjektdeltager Prsjektdeltager Side 6 av 41

7 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi Snrre Meland, CnsultIT Prsjektdeltager (Prsessdriver) Prsjektet har hatt en styringsgruppe med følgende medlemmer: Navn Rlle Arild Pedersen Leder Helse Midt-Nrge Trunn Schanke Helse Sør Erik M. Hansen Helse Vest Stig Heyerdal Helse Øst Bjørn Nilsen Helse Nrd 1.4 Relasjn til andre tiltak Følgende tiltak behandler mråder sm har relasjn til tiltak 12: Tiltak 8 Etablere plan fr å implementere PKI i bred skala i sektren i løpet av planperiden. Har betydning fr hvrdan sikkerhet skal implementeres i en systemarkitektur. Tiltak 6 Etablere en nasjnal infrmasjnsstruktur fr pasientfrløpet (Frstudie). I utgangspunktet kan man si at det å etablere en gd systemarkitektur kan gjøres uavhengig av infrmasjnsmdell. Men når man skal utveksle data i en systemarkitektur mellm systemer støter man raskt på prblemer hvis infrmasjnselementene er veldig frskjellig definert. Det er en begrensning på hva sm er praktisk mulig å pakke inn i et integrasjnsgrensesnitt. I rapprten er det påpekt hvilke mråder hvr det er spesielt viktig at det benyttes standarder fr innhld / ppbygging av infrmasjnselementer. Tiltak 11 Utarbeide felles krav til funksjnalitet g innhld i EPJ-systemer i sykehus. Etablere gdkjenningsrdning (sees i sammenheng med tiltak 5.3) g tiltak 13 Utfrme krav til Elektrnisk Pasientjurnal innen ulike fagmråder i spesialisthelsetjenesten (Franalyse + Psykiatrien). Har betydning fr hvrdan systemarkitekturen er bygd pp fr å kunne realisere krav til funksjnalitet i EPJ systemene. Krdinering mellm tiltakene er delvis løst ved bruk av felles styringsgruppe samt direkte kntakt mellm tiltakene. Resultatene i frhld til dette er nkså begrenset siden det bare er tiltak 8 sm har vært i samme fase sm tiltak 12. I frhld til det videre arbeid så må en se disse tiltakene mer i sammenheng g finne en bedre måte å krdinere dem på. 1.5 Avgrensninger Systemarkitektur er et mfattende tema. I frprsjektet er det i str grad fkusert på kartlegging av dagens systemprtefølje g i hvilken grad de er integrert g hvrdan de er integrert. Det er kartlagt i hvilken grad reginene har en vedtatt teknlgi- g arkitekturstrategi. Prsesser der man ser muligheter fr gevinst ved tettere integrasjn g/eller sentral bruker g rllestyring er vurdert, men det er ikke gjennmført en dypere kartlegging av helsefretak eller kartlegging av frretningsprsesser. Gevinstmråder er vurdert, men man har ikke gjrt dype kst/nytte-analyser med beregning av størrelser. Side 7 av 41

8 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi 1.6 Dkumentets ppbygning Dkumentet har følgende ppbygning: Kap. 1 Innledning Kap. 2 Kartlegging av dagens tilstand Kap. 3 Kartlegging av utvalgte prsesser Kap. 4 Gevinstmråder Kap. 5 Felles arkitektur i Helse-Nrge, mråder berørt i frprsjektet Kap. 6 Knklusjn g anbefaling Vedlegg: 1 Status i Helse-Reginene 2 Leverandørkartlegging 3 Juridisk vurdering, berørte lver g frskrifter 4 Vurdering av standarder 1.7 Ordliste Tjenestebasert arkitektur Infrmasjnsarkitektur/Infrmasjnsmdell Frretningsarkitektur Arkitekturmdell fr it-løsninger der fkus er å tilgjengeliggjøre funksjnalitet fra delsystemer sm tjenester. Tjenestene benyttes da i nye løsninger der tjenester fra frsjellige delsystemer kmbineres g presenteres sømløst fr bruker. Tjenester er fte realisert sm web-tjenester (Web Services). Mdell sm viser viktigste data g hvilke systemer sm eier dem g hvrdan de hører sammen g hvrdan de benyttes. Prdukter, tjenester g prsesser sm synliggjør frretningsverdier. Side 8 av 41

9 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi 1.8 Oppsummering Bakgrunn Temaet arkitektur i prgramvaresystemer kan være et mfattende tema. Når man gså tar i betraktning at vi her snakker m 5 helsereginer sm hver har mange fretak med igjen frskjellige løsninger på variert teknlgiplattfrm har man et kmplekst bilde. Arkitektur vil være et viktig bidrag til å strukturere pp dette bildet. Arkitektur har mange fasetter, f. eks: Sikkerhet Integrasjn Teknlgi Standarder Infrmasjnsmdell m.fl. Kartleggingen av situasjnen i reginene viser at man har mange systemer med varierende grad av integrasjn. Mellm HF g på tvers av RHF er det i liten grad integrasjn. Karakteristisk fr dagens systemer er at de er lite åpne, består av tykke klienter med mye lgikk, egne brukerdatabaser sm krever separat innlgging g fkus kun på eget system. Vi har en situasjn der helsemedarbeideren må frhlde seg til mange systemer sm krever separat innlgging, der infrmasjn presenteres på vidt frsjellige måter g fr liten grad flyter mellm systemene. Samtidig ser vi at det vil være uhensiktsmessig å se på helsesektren sm kun RHF ene uten å ta hensyn til primærhelsetjenesten eller den kmmunale ssial- g helsetjenesten i et arkitekturperspektiv. Et pasientfrløp vil i de fleste tilfeller strekke seg ver alle de tre mrådene. Frprsjektet har derfr sett på systemarkitektur innen helsevesenet med fkus både på RHF ene g hele helsesektren. Anbefaling Mange av dagens utfrdringer vil kunne adresseres gjennm en felles systemarkitektur. Prsjektgruppen anbefaler at det kjøres et hvedprsjekt med mandat til å utarbeide en systemarkitektur fr samhandling i helsesektren. Eksterne ressurser bør benyttes fr å sikre kapasitet g kmpetanse til gjennmføringen. Følgende bør vurderes: Hvrdan skal arkitektur frankres slik at det er makt g myndighet til å gjennmføre en nasjnal arkitekturstrategi Etablering av arkitektrlle sentralt i hvert enkelt RHF. Etablering av verrdnede føringer fr sektren (sektrarkitektur). Disse må implementeres i reginale arkitekturstrategier (spesialisthelsetjenestearkitektur). En sektrarkitektur må se både utver sektren (nasjnale initiativ), på samhandling innen mråder i sektren g på samhandling mellm RHF. Et hvedprsjekt bør kjøres i regi av arkitekter i RHF ene. Invlvering av en arkitekturansvarlig i SHDir bør vurderes. Et hvedprsjekt bør knytte til seg ekstern kmpetanse i den grad det er behv fr det. Evt. bør det vurderes å sette hvedprsjektet ut på anbud. Et hvedprsjekt bør frene frretningsarkitektur med systemarkitektur, g det må ta innver seg krav til infrmasjnsmdell g sikkerhet (PKI etc). Side 9 av 41

10 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi Et hvedprsjekt bør vurdere m erfaringer fra andre land, Sverige, Danmark, Finland m.fl. kan gjøres gjeldende i Nrge. Det bør vurderes å samrdne hvedprsjektet med tiltak 6, 8 g 11/13. Spesielt tiltak 6, etablering av nasjnal infrmasjnsstruktur fr pasientfrløpet er vesentlig i frhld til å avklare samhandling mellm delsektrene. En nasjnal arkitektur bør trekker pp verrdnede føringer innen følgende mråder: Samhandling g integrasjn Publikumstjenester Nasjnale standarder Infrmasjnsmdell/felles begrepsapparat Infrmasjnbærerere mellm mråder i sektren Standardisert presentasjn av infrmasjnselementer Fellestjenester Sikkerhet Nasjnalt Reginalt Bruker g rller Dataintegritet PKI Relasjn til andre tiltak Systemarkitektur innenfr spesialisthelsetjenesten g innenfr helsesektren kan ikke gjennmføres uten samrdning med tiltakene 6, 8 g 11/13. 6 Fr å kunne lykkes med en systemarkitektur er det en frutsetning at man har kntrll på infrmasjnsgrunnlaget. En systemarkitektur må derfr utvikles bl.a. basert på en infrmasjnsmdell fr sektren, ikke bare fr spesialisthelsetjenesten. Mye av infrmasjnsgrunnlaget i et pasientfrløp burde vært brukt g gjenbrukt i de ulike deler av et pasientfrløp. Men på grunn av manglende standardisering av infrmasjnsgrunnlaget g manglende systemarkitektur er ikke dette gjennmførbart. Dette fører til at infrmasjn ikke blir tilgjengelig der den burde vært det i et pasientfrløp g at den i mange tilfeller blir reprdusert. 8 - PKI er en nøkkelkmpnent i frbindelse med sikring av kmmunikasjn mellm enheter g mt publikum. Det er derfr behv fr at det blir laget en standard fr en sikkerhetsarkitektur sm er tjenesterientert g sm alle systemer kan frhlde seg til. Sm et ledd i å gjøre denne funksjnell g sikker nk er det nødvendig med en bedding av PKI i sektren til alle sm er ansatt der. Man må derfr kmme videre i frhld til dette tiltak 8 med bredding utver virksmhetssertifikater. 11/13 - Tiltak 12 behandler ikke funksjnalitet spesielt, men det er en helt klar frutsetning at man har en gd g versiktlig systemarkitektur (sm er basert på en helhetlig infrmasjnsmdell) fr å kunne lykkes med å utvikle frbedret g ny funksjnalitet. Både kvalitetsmessig heving av funksjnaliteten g utviklingshastigheten er avhengig av dette. Med en arkitektur sm er felles fr sektren vil det gså være langt enklere å lage tjenester sm fr brukeren på brukerflatenivå ppfattes sm lik. Det vil gså være fullt mulig å tilby samme funksjnalitet uavhengig av mrådet man jbber innenfr i sektren. Frankring: Frankring g pplæring vil være en avgjørende suksessfaktr ved etablering av en sektrarkitektur. Både eksterne g interne intresenter må få en frståelse fr hva dette er g hva dette betyr fr den enkelte. Det bør derfr legges en egen pplærings/frankringsstrategi. I denne bør gså pplæring av interne bidragsytere, misjnering fr eksterne aktører, pressedekning g delaktighet i arbeidet sm fregår i regi av mderniseringsdepartementet inngå. Side 10 av 41

11 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi Budsjett: Et budsjett kan tidligst avklares når knklusjner fra tiltak 6, 8, 11 g 13 er tilgjengelig g rganisering av et hvedprsjekt er avklart. Side 11 av 41

12 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi 2. Kartlegging av dagens status 2.1 Bakgrunn Dagens reginale helsefretak er et resultat av de endringer sm er gjrt i strukturen i Helse-Nrge de siste årene. Sammenslåing av funksjner g knslidering av IT-systemer i reginene er i varierende grad gjennmført. Det er derfr str variasjn i hvilke systemer sm brukes, hvrdan de er integrert g hvilke sikkerhetsløsninger sm benyttes. Frprsjektet har gjrt en kartlegging av dagens løsninger. Fkus har vært dagens systemer, hvilke leverandører benyttes, hva er gjrt mht. integrasjn, sikkerhet med mer. Under er resultatet av kartleggingen summert pp, fr detaljer, se rapprt fr hvert helsefretak vedlagt. 2.2 Dagens løsninger Nedenfr er det angitt en tabell ver hvilke fretak sm bruker hvilke systemer. Merk at dette kun er en tabell ver de største systemene i fretakene g gir ikke et kmplett bilde av alle systemer i fretakene. SYSTEMNAVN Helse Øst Helse Sør Helse Vest Helse Midt Helse Nrd (NLSH) JOURNALSYSTEMER Dculive X X X X Infmedic Tekst (Classic) X X X IMx Tekst X X X Infmedix (Tekst/prfesjn) IMX Lege X X X X Dips X X X X Capsy X X PASIENTADM. HIS90 PAS PiMS X X Dips X X X X IMx Classic X X X Infmedix PAS X X X PasDc LABSYSTEMER HIS90 LAB X Netlab X X Swisslab X X Sympathy X X X X X X X Side 12 av 41

13 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi SYSTEMNAVN Helse Øst Helse Sør Helse Vest Helse Midt Helse Nrd (NLSH) Dculive PAIS X X X Prsang X X X FlexLab X X X Unilab Miclis X X Bldcraft X X Dips Classic Lab RØNTGENSYSTEMER Sectra RIS X X Sectra PACS X X Kdak PARIS X X X Kdak PACS X X Agfa RIS X X X Agfa IMPAX X X X Siemens MagicSAS X X Siemens PACS X X Dips RIS X X X Risk RIS X X Side 13 av 41

14 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi 2.3 Dagens integrasjnsløsninger Et generelt bilde er at integrasjner i str grad frekmmer mt hvedsystemer. Integrasjn er i str grad basert på punkt til punkt integrasjner eller databasereplikering g i mindre grad gjennm standardiserte integrasjnsløsninger g grensesnitt Helse Nrd Mange av de kliniske applikasjnene er integrert. DIPS AS har et ferdig definert grensesnitt fr integrasjn. De fleste systemene integreres fr å kunne dele nøkkeldata (pasientpplysninger), men lagrer i sine egne prprietære databaser. I tillegg finnes det en del brkerløsninger levert av leverandørene selv eller av 3. part. Strt sett gde erfaringer med integrasjner gså etter versjnsppgraderinger. Brkerløsningene sm eksisterer fungerer gså strt sett greit, men her ppleves det fra tid til annen prblemer, spesielt ved versjnsppgraderinger. Løsningene har gså fte begrensede lgg- g alarmfunksjnalitet ne sm gjør at en ppdager driftsavbrudd først når en ppdager mangler ute hs sluttbruker. Når det gjelder samhandling med primærhelsetjenesten er det en del utfrdringer. Disse består i mangel på et enhetlig register ver helseenheter g helsepersnell, mangel på PKI-løsninger g uferdige applikasjner sm ikke støtter applikasjnskvittering ved levering Helse Midt-Nrge I dag er mange integrasjner implementert sm databaseintegrasjn eller mt prprietære integrasjnskmpnenter på klientsiden. Et eksempel på dette er integrasjn mt Et eksempel på dette er integrasjn mt det pasientadministrative systemet sm gjøres via PasLlink grensesnittet. Ekstern infrmasjnsutveksling fregår hvedsakelig via meldingsbrkeren Amtrix. Helse Midt-Nrge har en vedtatt integrasjnsstrategi. Essensen i denne er ønsket m å vri seg fra punkt til punkt integrasjner eller databaseintegrasjner ver til å utnytte en tjenestebasert arkitektur fr integrasjn. Alle systemer skal i henhld til strategien tilby sin funksjnalitet sm tjenester. Disse tjenestene kan benyttes direkte eller via integrasjnsprdukter sm Biztalk g lignende Helse Sør Helse Sør har ennå ikke utarbeidet en knkret strategiplan fr applikasjnsarkitektur. I tilbudsfrespørselen fr felles PAS/EPJ ble det utarbeidet en ønsket applikasjnsarkitektur sm ble benyttet sm referansearkitektur sm systemene ble vurdert pp i mt. Valget av Infmedix fra TietEnatr (TE) sm felles PAS/EPJ system vil være tneangivende fr integrasjnsplattfrmen i Helse Sør. Den meldingsbaserte integrasjnen vil baseres på TEs RS-mdul (Rekvisisjn g Svar), mens øvrig integrasjn vil baseres på web services bla gjennm TE-mdulen PasLink web services. Meldingsbasert integrasjn mt primærhelsetjenesten skjer hvedsaklig via integrasjnsmtren Amtrix. Sykehuspartner IKT sm er under etablering, vil etter hvert utarbeide en mer frmalisert integrasjnsstrategi fr Helse Sør Helse Vest Helse Vest har ikke utarbeidet en verrdnet integrasjns eller systemarkitektur. I etableringen av en reginal felles ikt enhet vil dette arbeidet være en viktig frutsetning fr å kunne frenkle g synkrnisere applikasjnsprteføljen. Fr de ulike applikasjnsmrådene er det vedtatt en strategi sm innebærer fellessystemer g migrasjn fr nen mråder, mens det fr andre mråder vil bli videreføring av dagens løsninger. Reginalt har man ulike integrasjnsløsninger basert på bla BizTalk g Amtrix. Disse benyttes både Side 14 av 41

15 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi ekstern g internt. I all hvedsak er integrasjnsløsningene meldingsbasert, g støtter infrmasjnsutveksling g i ne mindre grad infrmasjnsdeling. Integrasjnene er gså i hvedsak punkt til punkt rienterte, men en del løsninger basert på en hub & spke tilnærmet implementasjn Helse Øst Integrasjnsarbeid har tidligere vært utført innen hvert helsefretak g ikke sm et reginalt initiativ. Det enkelte HF har gjennmført integrasjner sm har vært relevante i ulike innføringsprsjekter. Generell satsning på integrasjnsarkitektur eller applikasjnsarkitekturer har vært fraværende brtsett fra ved Ullevål universitetssykehus (UUS). Ett viktig prinsipp fr integrasjn ved UUS, er gjenbruk av sentrale funksjnelle kmpnenter. Ett eksempel her er pasientregistrering. Denne kmpnenten er sentral i det pasientadministrative systemet, g i tillegg sømløst integrert i lab-system g RIS. Fr en del frmål benyttes meldingsutveksling, via en sentral enhet Amtrix /eller BizTalk (EAI Enterprise Applicatin Interface / message brker) sm integrasjnsmetde. Utveksling av infrmasjn (data) mellm systemene er i hvedsak filbasert (HL7 g Edifact, men etter hvert går man mer g mer mt XML). Side 15 av 41

16 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi 2.4 Arkitektur Innenfr de 5 helsereginene er det i varierende grad etablert arkitekturstrategier. Nen har etablerte strategier på fretaksnivå men ikke fr hele reginen, andre på reginalt nivå Helse Nrd Helse Nrd RHF har freløpig jbbet lite med en reginal systemarkitektur. Fretaket har imidlertid sett det nødvendig å gjøre en del strategiske valg når det gjelder rganisering, innkjøp g til en viss grad gså teknlgi. På disse mrådene gjennmføres i disse dager en hmgenisering g knslidering på rganiserings-, system-, teknlgi- g innkjøpssiden. I mangel av en ferdig arkitekturstrategi har fretaket sm plicy å i størst mulig grad velge åpne løsninger sm tas i bruk på tvers av de lkale fretak med en felles katalgtjeneste sm det naturlige frankringspunkt g basert på de teknlgiske plattfrmer fretaket har valgt. Pr. i dag finnes det kun en enkel prtalløsning sm inkluderer epst, intranett g tilgang til enkelte webbaserte systemer. I framtida ser vi fr ss de fleste applikasjner webifisert enten ved mskriving, utbytting eller ved bruk av terminalserverløsninger. Dette vil muliggjøre en reginal prtal hvr en bruker skal få tilgang til alle sine systemer g data. Sentralt i dette vil være en felles katalg. I Helse Nrd har fretakene ikke ensrettet sin infrastruktur, ne sm betyr at Helgelandssykehuset, Nrdlandsykehuset g Hålgalandssykehuset har edirectry på NetWare-plattfrm, mens UNN g Finnmarkssykehuset har AD på Windws 2000/2003-plattfrm. Det fregår reginale piltprsjekt sm vurderer et verbygg med en metakatalg basert på edirectry. Nrdlandssykehuset bruker edirectry med en enkel integrasjn med DIPS PAS, Jurnal, Pliklinikk, RIS sv. Tilgang til DIPS er pr. i dag rllebasert g fingranulert ned på det enkelte jurnalelement g aktualitet i frhld til fr eksempel planlagte kntakter med pasient. Andre kliniske g administrative systemer benytter i str grad intern tilgangskntrll Helse Midt-Nrge Helse Midt-Nrge har en vedtatt integrasjn g arkitekturstrategi. Stikkrd er: Integrasjn vha. Web Services Revitalisering av eksisterende systemer gjennm tilgjengeliggjøring i en tjenestebasert arkitektur Etablering av fellestjenester Etablering av autrisasjn g autentisering basert på bruk av AD. Opprettelse av et klustret driftsmiljø Sentralt i utarbeidelse av strategien har vært at man skal behlde dagens systemer, men gjøre de mer åpne fr standardisert integrasjn. Arbeidet har medført tett dialg med dagens leverandører. Alle nyanskaffelser følger denne arkitekturstrategien. HMN ønsker i løpet av 2005 å etablere et fast rammeverk fr nye applikasjner / tjenester i frm av et prtalrammeverk sm har en del fellestjenester, samt at man ønsker å samle flest mulige tjenester inn under en felles brukerprtal. Helse Midt-Nrge har i dag en infrastruktur sm i hvedsak består av Micrsft-baserte løsninger med en hvedvekt på Windws 2000 servere. Active Directry er i ferd med å rulles ut sm katalg. Helse Midt-Nrge har flere varianter av databaser, men nye løsninger skal kjøre på SQL Server i cluster. Alle data lagres i et Strage Area Netwrk (SAN). Fr nye tjenester er det definert en egen tjeneste sm skal håndtere tilgangskntrll. Side 16 av 41

17 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi Helse Sør Helse Sør ennå ikke utarbeidet en knkret strategiplan fr IKT-arkitektur (infrastruktur, sikkerhet, infrmasjn g applikasjn). Sykehuspartner IKT vil sm ledd i etableringen, utarbeide en strategiplan i samarbeid med Helse Sør fr gdkjenning i Helse Sør. Det er ingen vedtatt infrastrukturarkitektur i Helse Sør. Likevel er HF ene relativt standardisert når det gjelder nettverksperativsystem g katalgtjeneste. De fleste har basert dette på Micrsft 200x g Active Directry, med unntak av Rikshspitalet g Sørlandet sykehus sm har Nvell NetWare g Nvell edirectry (Sørlandet sykehus har besluttet å migrere Arendal fra AD til edirectry) Helse Vest Helse Vest har ikke utarbeidet en verrdnet systemarkitektur sm sådan. Det arbeides aktivt med samrdning g knslidering av systemprteføljen, ved anskaffelser g systemskifter søkes i størst mulig grad fellesløsninger/fellessystem implementert. Bla har man valg leverandør fr et felles pas/epj system fr hele reginen, g implementeringsplaner i de ulike helsefretak er under utarbeidelse. Fr de ulike applikasjnsmrådene er det utarbeidet en strategi sm innebærer fellessystemer g migrasjn fr nen mråder, mens det fr andre mråder vil bli videreføring av dagens løsninger. Dagens systemarkitektur preges av str grad av fragmentering. Dg er fellesløsninger implementert både mellm g innenfr de ulike fretakene. I Helse Vest pågår det et arbeid fr å implementere en felles katalgtjeneste basert på AD. Helse Vest har utarbeidet g er i ferd med å implementere et sikkerhetsknsept med tilhørende sikkerhetsplicy g styringssystem fr sikkerhet. Helsefretakenes sikkerhetsbehv er grunnlag fr det sikkerhets-knsept sm er valgt. Sikkerhetsbehvet kan utledes av det akseptable risiknivå sm er fastlagt fr fretakene g ved gjennmføring av risikvurderinger. Sm utgangspunkt fr sikkerhetsknseptet presenteres Helse Vests infrmasjnssystem gjennm en lagdelt mdell med lagene: Fysisk, lgisk, basistjenester g tilpassede tjenester. Knseptet beskrives deretter ved å angi hvrdan tilgangskntrll ppnås gjennm å kmbinere virkemidler i de frskjellige lagene. Sikkerhetsknseptet mfatter beslutninger m hvilke virkemidler/ lag sm skal benyttes fr å kntrllere tilgang til hvilke pplysninger. Tilgangskntrll er basert på tildeling av rller til medarbeiderne i helsefretakene, g knytning av disse rllene til ressurser i infrmasjnssystemet. Metde fr tilgangskntrll presenteres gjennm beskrivelser av autentiseringsmtr, identitetslager g rlle- g tilgangsmtr. Valgt sikkerhetsknsept gir føringer fr utfrming av Helse Vests nettverk g knfigureringen av infrmasjnssystemet i det enkelte helsefretak. Dette fremgår av skisser av lgiske nett hs helsefretakene g fr Helse Vest sm helhet. Det arbeides målrettet fr å implementere sikkerhetsknseptet i alle deler av systemprteføljen Helse Øst I reginen har det ikke vært arbeidet systematisk med systemarkitekturer, men enkelte HF har gjennmført integrasjner sm har vært relevante i ulike innføringsprsjekter. Generell satsning på integrasjnsarkitekturer eller applikasjnsarkitekturer har vært fraværende brtsett fra ved Ullevål universitetssykehus. Arbeidet har her gså vært preget av en praktisk tilnærming g manglet mye av den metdiske tilnærming sm en ser at markedet både på kunde g leverandørsiden er mden fr. UUS har sm strategisk arkitekturmdell valgt en flerlags vertikal arkitektur, men gså en kmpnentarkitektur fr den hrisntale aksen (virksmhetskmpnenter/funksjnelle kmpnenter). Dette innebærer en tjenesterientert arkitektur. UUS har sm verrdnet strategi å unngå redundans (verflødighet) i funksjnalitet ved å bruke kmpnentteknlgi. COM (Cmpnent Object Mdell) g DCOM (Distributed COM) kmpnenter tidligere basert på ATL (Active Template Library), nå basert på Cm+ g Web-services. Side 17 av 41

18 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi Gjennm dette vil man kunne integrere på flere lag. Kmpnenter sm er i drift på Cm+ frutsettes brukt i fretningslageret på applikasjnsserverne g ikke lkalt på den enkelte PC Ett viktig prinsipp fr integrasjn er gjenbruk av sentrale funksjnelle kmpnenter. Ett eksempel her er pasientregistrering. Denne kmpnenten er sentral i det pasientadministrative systemet, g i tillegg sømløst integrert i lab-system g RIS. Fr en del frmål benyttes meldingsutveksling, via en sentral enhet Amtrix /eller BizTalk (EAI Enterprise Applicatin Interface / message brker) sm integrasjnsmetde. Utveksling av infrmasjn (data) mellm systemene er i hvedsak filbasert (HL7 g Edifact, men etter hvert går man mer g mer mt XML). Infrastrukturen i de ulike HF i Helse Øst er ne innbyrdes frskjellige, men følgende sikkerhetsprinsipper ligger til grunn fr de fleste; Sikkerhet mt eksterne følger prinsippene i Datatilsynets referansemdell med alle brukere i sikker sne Tilkblingssikkerhet krever styrket autentisering dersm ikke frbindelsen er fast Eksterne linjer krypteres Det er ikke en felles katalgtjeneste i reginen, men egne katalger fr hvert enkelt HF. Eksisterende katalger er i str grad basert på Active Directry. Følgende angir hvedprinsippene ved tilgangsregulering: PKI benyttes begrenset til virksmhetssertifikater fr å sikre tilkbling mt eksterne brukere/aktører. UUS håndterer sertifikater internt (intern CA). Tilgang til PAS/EPJ er regulert gjennm individuell tilgangskntrll med bruk av passrd. Det samme har andre fagapplikasjner (RIS/Pacs, lab-applikasjner, m.m.). Målet er å få på plass synkrnisering vha metakatalg Nasjnal arkitektur Mange systemer etableres gjennm nasjnale prsjekter. Så langt har disse vært etablert uten felles arkitekturiske føringer. Fram til nå har det vært vanlig å utveksle infrmasjn via meldinger sm sendes via en brker eller SMTP gateway. Eksempler på prsjekter sm bruker en slik utveksling er Henvisning/bking prsjekter g ELIN prsjektet. Skal en slik utvikling frtsette kmmer vi til å lage et mangfld av kpier av den samme infrmasjnen, antall meldinger kmmer til å mangedbles g mange av de systemer sm vi kjenner i dag kmmer til å få prblemer frdi de må håndtere langt større infrmasjnsmengder enn de i utgangspunktet er bygd fr. I frbindelse med en tjenesterientert arkitektur byr det seg nye muligheter når det gjelder måten å utveksle infrmasjn på. En bedre måte å tilgjengeliggjøre slike data på er å benytte dataene direkte i de systemer der de frefinnes (infrmasjnsdeling kntra infrmasjnsutveksling). Vi har her skissert en måte å gjøre dette på. En måte å tilgjengliggjøre infrmasjn på er gjennm en prtalløsning inn mt systemene. En slik løsning vil benytte tjenester sm ligger utenpå systemene fr å finne den infrmasjnen sm brukerne trenger. Infrmasjnen presenteres fr brukerne direkte via prtalløsningen. Et slikt system vil umiddelbart kvittere til brukerne m tjenesten sm er etterspurt er utført g m eventuelle feil. Brukerne kan gså få verført etterspurt infrmasjn til egen applikasjn eller få den tilsendt på andre måter via sms, e-pst etc. Kvitteringer i slike løsninger er ikke nødvendig, da alt skjer i sann tid. Eventuell infrmasjn sm brukeren vil ha tilbake, sendes da direkte til brukernes systemer. Eksempler på funksjnalitet sm er egnet fr denne type integrasjn er bking av timer på sykehus fra ekstern aktør g henvisninger/rekvisisjner mellm instanser i helsetjenesten. Det er viktig å understreke at denne tilnærmingen ikke er til hinder fr at de ulike brukerne kan hlde sine systemer ppdaterte dersm dette er ønskelig g nødvendig. En gjennmgående systemarkitektur åpner gså fr nye g mer interaktive samarbeidsmuligheter mellm de ulike brukerne av helseinfrmasjn. Man kan se fr seg dialg mellm legevakt g amk/vakthavende på Side 18 av 41

19 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi sykehus, hvr verføring av fr eksempel ekg etc. fra legevakten kan undersøkes av spesialist med det mål å behandle pasienten ved legevakten dersm det ikke er nødvendig å transprtere denne til sykehuset. Andre muligheter man kan se fr seg er delte skriveflater mellm samarbeidende helsepersnell etc. fr infrmasjn gjøres tilgjengelig fra de ulike tjenestene sm er implementert på tppen av eksisterende sykehussystemer. 2.5 Leverandørstatus Sammendraget baserer seg på svar fra 10 leverandører sm representerer større eller mindre systemer sm leveres til helsetjenesten, frtrinnsvis spesialisthelsetjenesten. Ca. 20 leverandører ble frespurt. I hvedsak ser leverandørene ut til å være svært markedsstyrt, spesielt i frhld til integrasjnsløsninger g mdularisering. Det er kundenes krav g behv sm er førende fr hva sm gjøres g hvrdan. Leverandørene er ikke førende på ny teknlgi, men følger gdt med på hva sm ellers skjer på teknlgisiden. Nye systemer sm er under utvikling følger nye trender g kundekrav i frhld til integrasjn g arkitektur. Spørsmål 1 Kan dere gi en krt beskrivelse av arkitektur / ppbygging av de applikasjner sm dere leverer til Helsefretak g primærhelsetjeneste. Legg gjerne ved skisser sm viser ppbyggingen av løsningen. Sammendrag av svar I hvedsak tradisjnell Windws klient/tjenerppbygging med database i bunnen. Nen få unixbaserte serverinstallasjner. 2 I hvr str grad er løsningen mdulær / kmpnent- / tjenestebasert? Legg gjerne ved skisser. 3 Er løsningen bygd pp slik at det er muligheter fr å benytte seg av deler av den / enkeltmduler? I tilfelle hvrdan g hva er det sm kan splittes ut. 4 Har applikasjnen et eget tilgangskntrllsystem g kan dere gi en beskrivelse av dette? 5 Hvis ja på sp. 4 hvilke rller / gruppeinndelinger pererer man med i sikkerhetssystemet (beskriv krt)? Ne mdulær-/kmpnentbasert ppbygging (COM). Kun et fåtall mduler kan brukes frittstående ikke vanlig praksis. I hvedsak basismduler sm kan påbygges. Nen få har mduler sm kan erstattes av andres mduler. Trend i retning av flere løsrevne mduler. Markedsstyrt. Tilgangskntrll er i fr de aller fleste applikasjnene bygd inn i egen database. Nyere systemer er mer fleksible g kan kmmunisere med eksterne tilgangssystemer eller erstattes helt. Avhenger av type system g hvilke persnellgrupper det mfatter. Større systemer har egen administrasjn g kan knfigureres. 6 Støtter applikasjnen Single Sign On (SSO)? Ja, strt sett iht s/netts, men ulikt hvr mye det er tatt i bruk av kunder. 7 Har applikasjnen muligheter til å frhlde seg til et eksternt tilgangskntrllsystem, f.eks. Active Directry. Beskriv eventuelt hvrdan? Kun et par leverandører pr. i dag, men flere er i gang i større eller mindre grad. 8 Har applikasjnen muligheter fr å frhlde seg til en ekstern rllemdell? I tilfelle hvrdan? 9 Hvilke integrasjnsgrensesnitt finnes i frhld til applikasjnen? 10 Hvis applikasjnen har integrasjnsgrensesnitt hvrdan er disse tilgjengeliggjrt (API, Web servicer, etc)? Nei, men 3 har planer fr det. Ulike syn på muligheter i frhld til systemene, avhenger av rikhet/granularitet. Ulike grensesnitt tilpasset andre system. Avhengig av hva "mastersystemene" tilbyr. De største systemene tilbyr egne grensesnitt. Størst utbredt er meldingsfrmidling (XML, EDIFACT m.fl.), ne COM-teknlgi. Nye teknikker fr videre utvikling nevnes, WS/.NET. Side 19 av 41

20 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi 11 Hvilke utviklingsverktøy er benyttet g er det planer m å gå ver til andre verktøy? 12 Hvilke planer er det fr applikasjnen videre i frhld til å utvikle den mt en tjenestebasert / kmpnentbasert arkitektur? 13 Hvilken erfaring har dere med integrasjnsløsninger g hvilke teknlgier er benyttet på de løsninger dere har erfaring med? MS-prdukter, Pwerbuilder, C++, Delphi, ne Java, flere planlegger vergang til.net. Db: MS SQL, Oracle (m/2 unntak). De fleste hevder å følge med på teknlgiutviklingen. Ulikt i frhld til type system sm leveres. Lev. av mindre systemer følger med på utvikling av "mastersystemene". Lev. av større systemer er mer bevisst på tjenesterientert arkitektur. Flere har bred erfaring med ulike teknlgier g mange prprietære løsninger, men ser trend mt COM eller WS g.net. Ny teknlgi frventes å gjøre integrasjn enklere g mindre sårbar ved vedlikehld g ppgraderinger. Det benyttes ulike teknlgier iht hvilke type systemer g type infrmasjn sm utveksles, eks. pas.inf. vs. lab.inf. 14 Tilfredsstiller applikasjnen jurnalfrskriften? Ja, i str grad. Det kan være nen unntak. Lab.inf.systemer er ikke underlagt frskriftene. Fr mer utførlig beskrivelse se vedlegg 2. Side 20 av 41

21 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi 3. Kartlegging av utvalgte prsesser Om vi ser på tabellen i kap. 2.2 ser vi at en lang rekke systemer er invlvert i et pasientfrløp. Disse systemene er i variabel grad integrert, g vi kan slutte at integrasjnen er mfattende g fte kmpleks. I kap. 2.5 ser vi at det blant leverandørene av systemene er variabel grad av mdenhet mht. arkitektur g at de har valgt frskjellige strategier mht teknlgi. Tilsvarende kan vi slutte at dagens helsepersnell må frhlde seg til en lang rekke systemer med frskjellige brukergrensesnitt sm i liten grad er harmnisert med selve arbeidsprsessen. I mange stre virksmheter gså utenfr helsevesenet er det fkus på integrerte it-systemer sm skal støtte arbeidsprsessen g endringer i disse. Her kan nevnes Statkraft, Gjensidige, Justidepartmentet sv. En gjennmført nasjnal arkitekturstrategi vil kunne gjøre integrasjn mellm systemer enklere, rimeligere g raskere å implementere. Dermed vil man enklere g raskere kunne lage IT løsninger sm understøtter virksmhetene sine arbeidsprsesser. Frprsjektet har ikke utført analyser av arbeidsprsesser, men har sett etter prsessmdeller fra andre prsjekter. I eksemplet fra Sykehuset Buskerud sm er beskrevet nedenfr, ser vi at det i frbindelse med akuttmttak er en rekke systemer invlvert fr å kunne gjennmføre behandlingsprsessen. En ekstra utfrdring i dette bildet er gså frskjellige rganisasjner med eierskap til data sm gir lvmessige utfrdringer. At frskjellige fagkategrier er invlvert vil gså være en utfrdring med hensyn til hensiktsmessig presentasjn av data. 3.1 Akuttrg hs Sykehuset Buskerud Sykehuset Buskerud har kartlagt hvrdan et akuttmttak kan implementeres, hvilke funksjner g hvilke itsystemer sm er berørt. Akuttrgprsjektet har gjennmført en mfattende analyse av akuttfunksjnen ved Sykehuset Buskerud Målet med etablering av et akuttrg har vært å integrere AMK, legevakt g dagens akuttmttak ved sykehuset i en ny enhet fr å effektivisere ø-hjelp funksjnen ved sykehuset primært gjennm: En enhetlig behandling av all ø-hjelp Pasienter sm kan sendes hjem eller til kmmunal tjeneste siles ut med én gang uten å bli sendt innver i sykehuset Dersm pasienter skal innlegges, bestemmes diagnse tidlig slik at riktig pasientfrløp innver i sykehuset besluttes før videresending Side 21 av 41

22 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi AMK 113 Amb ulan se Mtta g registrere henvendelse Ø- hjelp? Videresende pasient til AT/LV Ja Utføre ppdrag Alvrlig skade? Alvrlig skade t pasient Akuttstue Frkrtelser AMIS Akutt Medisinsk InfrmasjnsSystem EPJ Elektrnisk Pasient Jurnal system EAJ Elektrnisk Ambulanse Jurnal AMM AkuttMttak Mdul Lege vakt Nei LV Be-handling LV eller innleg- Bestille prøver/rtg Behandle pasient Behandlet pasient Akut trg skra nke Mtta g registrere henv-/pasient IB LV/ Elektivt/ Akutt/ Ikke E A Vurdering av sykepleier Pasient til rett AT bd Operasjnsstue Akut trg bde r Elektivt? Ja Ingen behandling av pasient Pasient innlegges rett sted Medisinsk vurdering av pasient Diagnse Akuttpst Fastl ege Mtta g registrere pasient Akutt? Nei Behandle pasient Behandlet pasient Sengepst Infr masj nsfrv altni ng AMIS PAS/EPJ AMIS LVM PAS/EPJ AMIS EAJ EPJ AMIS AMM LV EPJ EPJ LV EPJ EPJ Lab/ RIS/ Pat/Mikr EPJ LV EPJ EPJ EPJ Figur 1 Prsessbeskrivelse fr akuttrg Ønsket situasjn fr Akuttrg Støtte fr arbeidsprsesser g pasientflyt Prsesskartet ver er ikke helt krrekt, men gir en gd indikasjn på prsessen i Akuttrget g de viktigste systemene sm er invlvert, g hvrdan disse kan være integrert (denne integrasjnen er kmpleks g krever en separat studie). Kritisk fr å ppnå Akuttrgets målsetting m bedret pasientflyt er at systemene sm støtter prsessen sørger fr at pasient- g jurnalinfrmasjn til enhver tid er tilgjengelig iht. pasientflyten. Dette medfører følgende krav til systemprteføljen Pasientadministrativ infrmasjn må kun registreres én gang i ett system i skranken g tilgjengeliggjøres til systemer senere i prsessen Systemer skal være i stand til å hente infrmasjn fra underliggende systemer dersm pasienten er registrert tidligere, fr eksempel sykehusets PAS, legevakt PAS g fastlege PAS Relevant jurnalinfrmasjn bør kunne verføres eller tilgjengeliggjøres fra tidligere ledd i prsessen, bla fra ambulanse, fastlege g legevakt Bking av ressurser (radilgi, klinisk kjemi, mikrbilgi, patlgi) må kunne gjøres av Akuttrgfunksjner (legevakt, akuttpst) direkte i de respektive spesialsystemer fra de respektive EPJ Svar fra venstående prøver sendes direkte til EPJ Sm vil ha følgende effekt Pasienten slipper dermed å ppgi samme infrmasjn flere ganger samtidig sm tid spares på fjerning av gjentagne aktiviteter Pasienten slipper å ppgi infrmasjn sm allerede finnes i systemet g aktiviteten går raskere Side 22 av 41

23 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi Infrmasjn sm er nyttig fr Akuttrget g fr videre behandling i sykehuset er tilgjengelig g kan nyttiggjøres. Dette vil gi bedre beslutningsunderlag g en sparer tid. Kliniske støtteressurser kan utnyttes ptimalt g tid spares på mer effektiv bkingprsess Svar g annen jurnalinfrmasjn jurnalføres direkte enten gjennm manuell input eller sm ekstrakt fra underliggende systemer. Dette fører igjen til at infrmasjnen blir raskt tilgjengelig. Man vil i str grad ha en kilde til alle infrmasjnselementer g fjerne dbbeltlagring g dbbel input av infrmasjn. Utfrdringer g frutsetninger En del av utfrdringene fr å kunne realisere en slik funksjn er knyttet til IT løsningene g hvrdan disse kmmuniserer / integreres med hverandre slik at man kan bygge en ttalløsning sm understøtter arbeidsprsessen. Fr å få til dette peker vi under på en del av de viktigste punktene. Brukeren autriserer g autentiserer seg en gang g det finnes et rammeverk sm hlder på denne identifiseringen slik at den kan gjenbrukes etter hvert sm brukeren skifter mellm de ulike systemene. Alle funksjner er fr brukeren tilgjengelig gjennm en prtal / skrivebrdsløsning hvr en kan skifte mellm funksjner uten å måtte søke fram pasienten mer enn en gang. Pasienten g infrmasjn knyttet til denne ligger i en cntext sm alle funksjner / applikasjner frhlder seg til. Alle underliggende funksjner har et grensesnitt sm gjør at man er i stand til å initiere dem i frhld til en bestemt pasient. Bestillinger / henvisninger til andre funksjner gjøres gjennm et brukergrensesnitt sm genererer bestillinger / henvisninger til de underliggende systemene uten at en trenger å gå inn i dem. Dette krever bl.a. at det finnes en standard fr hvrdan man utveksler en timebestilling mellm systemer g at alle systemer sm håndterer den type infrmasjn har en standardisert tjeneste fr å kunne sende g mtta slike. Etter hvert sm prsessen skrider fram vil det være behv fr å legge infrmasjn til pasientens jurnal. Dette gjøres enten frtløpende ved at man skriver rett inn i jurnalen eller at man fra de frskjellige fagsystemene avgir infrmasjn til jurnalen. Dette krever at man i de ulike systemene sm ikke er jurnalløsningen i seg selv er i stand til å kunne sammenfatte data fr så å avlevere dem. Videre vil dette kreve at jurnalløsninger har grensesnitt fr å kunne ta i mt slike data g at de andre løsningene har grensesnitt fr å kunne avgi slike data. Her bør en gså ha muligheter fr å sende / mtta pekere til infrmasjnen slik at en slipper dublering av data. Hvis man har standarder fr den type utveksling vil alle jurnalsystemer g systemer sm skal levere data til jurnalen være kmpatible g man unngår punkt til punkt integrasjn i hvert enkelt tilfelle. Fr å kunne sette sammen et brukergrensesnitt sm passer fr de ulike rller / persner sm er invlvert i en slik prsess kreves det at systemene er tjenesterientert g lagdelt. På den måten kan man enklere skru ting sammen i henhld til brukerne sine behv g samtidig behlde en knsistens på dataene i bunn (se fig under (HMN sin skisse til en tjenesterientert arkitektur)). Det vil gså gjøre det enklere å gjøre tilpasninger underveis uten å berøre fr stre deler av systemene. Vi har her ikke berørt prblematikk i frhld til dagens lvverk. Her ligger bl.a. utfrdringer i frhld til at det er flere juridiske enheter sm er inne i frløpet til pasienten g at spesielt infrmasjnsdeling g ppstart av alle systemer fra en felles brukerflate er prblematisk i frhld til det. Vi anser det sm frdelaktig at man i integrasjnene her benytter seg av tjenester g ikke meldingsutveksling fr å tilgjengeliggjøre g frmidle data. Side 23 av 41

24 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi 4. Gevinstmråder 4.1 Innledning Et mtiv fr å samrdne arkitektur i Helse-Nrge er mulighet fr å høste gevinster øknmisk, rganisasjnsmessig, klinisk, fr pasient g helse-medarbeider. Frprsjektet har ikke gjennmført en kst/nytte vurdering i tradisjnell frstand, vi har heller ikke funnet analyser fra andre prsjekt det har vært hensiktsmessig å gjenbruke. Vi har imidlertid analysert mulige gevinstmråder innenfr følgende mråder: Kvalitet g sikkerhet Integrasjn Utvikling Markedsutvikling Organisasjn Pasient Oversikt ver gevinstmråder: Gevinstmråder Beskrivelse Krt sikt Mellmlang sikt 2008 Lang sikt 2010 Kvalitet: Tilgjengelighet fr bruker: slippe å huske mange passrd, raskere tilgang Økt kvalitet i pasientbehandling Etablere standardiserte sikkerhetsløsninger (Standardiserte rller i en katalg, kblet til brukerinfrmasjn). Sikkerhetsadministrasjn (IDentity Management, IDM, Basert på rlledefinisjn). Kvalitet g sikkerhet Integrasjn Sikkerhet: Riktig data til riktig bruker, til riktig tid Samme sikkerhet i alle ledd Tilgjengelighet Elektrnisk samhandling mellm aktører i helsevesenet: internt i HF mellm reginer primær- g kmmunal ht andre aktører Ta i bruk Single Sign On (autentisert mt katalg/ldap, lkale bruker g rllemdeller i applikasjner) sm er basert på felles nasjnal PKI. Etablere verrdnet infrmasjnsmdell fr utvalgte bjekter (eks. pasient - demgrafi g kritisk infrmasjn, rekvirent, kdeverk). Identifisere g utvikle/velge standardiserte integrasjns-mekanismer Ta i bruk felles PKI-løsning (felles kmpnenter/api brukes i kliniske applikasjner). Lavere kstnader ved nye integrasjnsløsninger (i dag regnes 30 % økte driftskstnader pga integrasjner). Redusert data-redundans, integrer istedenfr repliker. Bedre kvalitet på infrmasjn. Ta i bruk standardiserte sikkerhetstjenester g felles brukerkatalg: tilgangskntrll, sperring av pasientinf, utveksling/deling av pasientinf. "Billigere" infrmasjnsutveksling pga felles arkitektur. Side 24 av 41

25 Tiltak 12, Frprsjekt Nasjnal Arkitekturstrategi Gevinstmråder Beskrivelse Krt sikt Mellmlang sikt 2008 Lang sikt 2010 (prsess, dkumentasjn, strategi, patterns, WS, HL7 med mer). Økt samhandling. Ta i bruk rllebasert persnlig arbeidsflate. Ta i bruk rllebasert arbeidsflate/desktp. Ta i bruk integrert arbeidsflate/prtal fr alle ønskelige funksjner. Utvikling Utvikling av kliniske løsninger fr bruk i helsevesenet. Overrdnet infrmasjnsmdell fr utvalgte tjenester. Utnytte nasjnale tjenester. Felles tjenesteutvikling. Muliggjøre evlusjnær IT-vekst i sammen med fag. Lavere risik fr å ikke kunne bytte Markedsutvikling Utvikling innenfr markedet fr kliniske støttesystemer. Tilgjengeliggjøre data fra enkeltsystemer til andre systemer. Økt knkurranse mellm leverandører (bedre vilkår fr nisjeleverandører). Oppmuntre til innvasjn i sterke fagmiljø. Muliggjør suksessiv kmpnentbasert ppgradering. Lettere å unngå leverandørbinding. Større grad av tilpasninger fremfr systemskifter. Kan "presse" leverandører mer pga en mer enhetlig hldning. Kjøp standardiserte tjenester sm frhlder seg til en standardisert arkitektur. Organisasjn Utvikling av kliniske fagmiljø i HF, RHF g primærhelsetjenesten. Bedre samhandling internt i HF. Bedre samhandling mellm HF-ene på tvers av reginer. Legge frhld til rette fr frskning med datamining. Muliggjør standardiserte prsesser. Muliggjør større grad av funksjnsfrdeling mellm HF/RHF. Større muligheter fr integrasjn mellm spesialistsystemer g EPJ. Raskere tilpasning av løsninger ifht arb.prsesser, unngå sementering av dagens prsesser. "Papirløst" sykehus. Papirfattig samhandling nasjnalt. Pasient Påvirkning av pasientens hverdag. Enhetlig infrastruktur g drift. Enklere utveksling av jurnalinfrmasjn. Pasientflyt = dataflyt Unngå å gjøre samme undersøkelse flere ganger. Økt kvalitet i behandling. Side 25 av 41