Tjenesteorientert arkitektur i spesialisthelsetjenesten

Transkript

1 Tjenesteorientert arkitektur i spesialisthelsetjenesten Hovedrapport full versjon Styringsdokument Dokumentnavn/Versjon: Tjenesteorientert_arkitektur_i_spesialisthelsetjenesten_hovedrapport_full_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

2 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

3 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 og standardisering Fra monolitter til tjenester Fellestjenester på forskjellig nivå Komponering av prosesser Rollestyrte arbeidsflater Tjenestebuss realisert gjennom åpen ESB og mellomvare 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 Tjenester og tjenestemodeller rosesser i spesialisthelsetjenesten Standarder for prosess og tjenestemodellering Tjenesteorientering og interoperabilitet Tjenesteinndeling Kommunikasjonstjenester Logistikk- og ressurshåndteringstjenester Informasjonslogistikktjenester Ikke-medisinske tjenester Kliniske tjenester Medisinsk service Fagstøtte Øvrige tjenester Beskrivelse i UML-diagrammer Tjenester sett fra spesialisthelsetjenesten Tjenester sett fra en behandlingsenhet Tjenester sett fra en laboratorieenhet Tjenester sett fra en bildediagnostikkenhet Dagens arkitektur, SOA og systemlandskap Informasjonsmodell Teoretisk og språklig forankring Begrepsapparat Generelt om informasjonsmodellering Teknikker og modeller Informasjonsmodell overordnet Kodeverk Modellsammenligning

4 7.8 Informasjonsmodell og tjenestemodell Masterdata - Master Data Management (MDM) Klinisk arbeidsflate Målbildet Klinisk arbeidsflate for aktører utenfor spesialisthelsetjenesten Brukergrensesnitt og kanaler asientrettede portalløsninger Krav og anbefalinger Teknologi og informasjonssikkerhet Implementering av tjenesteorientert arkitektur i spesialisthelsetjenesten Teknologistandarder for grensesnitt og informasjonssikkerhet Fri programvare Referanser Vedlegg Vedlegg A: Ordliste Vedlegg B: Oversikt over figurer Vedlegg C: Nasjonale fellestjenester Vedlegg D: Andre informasjonsmodeller Vedlegg E: Sammenligning informasjonsmodeller Vedlegg F: Utvalgte scenarioer/prosesseksempler Vedlegg G: Standard for kontekstbytte, HL7 CCOW Vedlegg H: Teknologistandarder Vedlegg I: Anbefaling på løsning på samhandlingsbehov Vedlegg J: Forhold til lover og forskrifter Vedlegg K: rosjektorganisering og arbeidsmetode Vedlegg L: Anbefalinger i arkitekturen Leserveiledning Alle lesere bør lese kapittel 1 til 5. 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 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 **) 4

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

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

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

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 og standardisering 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) 8

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 9

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

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

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

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